Read our FAA SWIM getting started guide, a high-level implementation overview of the FAA’s SWIM program, for IT executives and analysts …
The FAA’s System Wide Information Management (SWIM) Program is an information system created to support the goals of the NextGen program.
“SWIM facilitates the data sharing requirements for NextGen, providing the digital data-sharing backbone of NextGen. SWIM enables increased common situational awareness and improved NAS agility to deliver the right information to the right people at the right time. This information-sharing platform offers a single point of access for aviation data, with producers of data publishing it once and users accessing the information they need through a single connection.” – FAA.gov
From a product development and IT perspective, SWIM affords the aviation industry the capability to produce and receive real-time aviation data for entire the National Airpsace System. It is not a single product, or a single website, or traditional “feed” system you might be familiar with such as RSS.
Instead, SWIM is a robust system for handling the immense amount of data generated every minute by the FAA, ATC and the airlines: flight plans, clearances, weather forecasts, terminal information and more.
Once the SWIM on-boarding process is complete, your organization have access to real-time, relevant aeronautical, flight, and weather information.
How To Get Started
Everything you need to know about the program can be found on the FAA SWIM site, specifically in the SWIM External Consumer Brief PDF. It’s approximately 30 pages and covers the timeline of events in good detail. Once you are assigned a point-of-contact, or POC, at the FAA you will be working with that individual closely, via email, for the duration of your involvement with SWIM.
After the initial paperwork is done and approved, you will (among other things) be provided documentation to connect to the R&D network and access to NSRR which is the document repository for all things SWIM related (think of it like a Sharepoint site). This is where the official docs live and is updated often – this is the canonical source of documentation and will be relied upon heavily for the JMS client development phase.
It is not unreasonable for the entire on-boarding process, from introductory email to running in production, to take ~ 6 months or more. The enablement team on the SWIM-side requires time to prepare and authorize your account(s) along with the other administrivia.
In addition, you and your IT/development team will need ample time to establish network connectivity, build client software and go through testing. The on-boarding process is not something you should anticipate to wrap up in a few Agile sprints.
SWIM Technical Requirements
From a technical standpoint, you should be familiar with the following terms and topics:
- IP networks, subnets, and enterprise-grade site-to-site VPN tunnel implementation + IPSec
- Message queues, specifically JMS (Java Messaging System), XML parsing
- Change management along with traditional IT and software development best practices
Perhaps one of the most involved IT steps of the onboarding process is establishing VPN connectivity to the proper FAA network(s). This is not a client-side VPN you are probably more used to with software you install to get on your companies or clients’ networks while traveling. A site-to-site VPN relies on a VPN gateway to establish secure communication between two sides, rather than client side software.
You should expect engagement with your network operations team to establish requirements and set up the proper hardware.
If a hardware appliance is not desired, some open source software exists that will work, such as OpenSwan. In fact, Route 3 Software used OpenSwan in lieu of a hardware site-to-site VPN solution and we have not had any problems. Relying on a software VPN solution has allowed us to provision our SWIM environment entirely in the cloud with minimal upfront investment.
A few more technical notes for the VPN (source: FTI NBPS User Guide):
- The FAA provides no hardware or software to support VPNs
- Your VPN connectivity must comply with the following IPSec settings:
- Encryption: AES-256
- Authentication: SHA-1
- IPSec / IKE Authentication: Pre-shared secret and digital certificate
- IKE: Version 1
- IKE phase 1: Diffie-Hellman group 5
- Perfect Forward Secrecy (PFS): Diffie-Hellman group 1
- Pre-shared secret key (to be exchanged at the time of VPN establishment)
Understanding the Non-Prod and Prod Environments
You’ll receive more details on the entire onboarding process from your POC, including expected timelines. From a high-level, the IT environment progression looks like the following:
R&D is where all non-production JMS client work should be developed against. This is the first environment you are authorized to connect to after the initial paperwork and VPN configuration and is available to you at all times, even after completing qualification testing and promoting to Ops. The data available in this environment is delayed 5 minutes, which the exception of the SFDPS feed which has a 1 week delay.
FNTB, or FTI National Test Bed, is an environment that exists for the FAA team to perform qualification tests against your code.
Once you are satisfied with your JMS client code and functionality, the next required step is to connect to the FNTB domain. With your JMS client code running, you and the FAA will ensure that your client code has connectivity, is able to recieve messages via NEMS, and performs satisfactorily during failover testing.
Connectivity to the FNTB does not last long, only for the duration of the testing. You will coordinate a date/time for the cutover with the FAA to migrate from R&D to FNTB. This is not a “staging” environment per se, or an environment considered “pre-prod”, it is only for the required testing to be completed. You can expect to be moved back to R&D once the testing is completed.
Ops is the production environment for the SWIM program. Similarly to the FNTB phase, your POC will help coordinate and schedule a cutover. At this point you should feel confident in your JMS client, logging and operational capability.
SWIM JMS Client Development
As part of the starting kit available on the NSRR, you’ll find a sample JMS client along with the necessary documentation to get the client up and running. This test client, the NEMS Topic Client, provides an excellent reference for setting up JMS connectivity and working with Solace.
While this client code is great for verifying connectivity and gaining an introductory-level of understanding in Solace connectivity and asynchronous message handling, you are likely seeking to build your own client or otherwise integrate the SWIM data to an existing platform.
The Java Message Service (JMS) API is a Java-specific middleware standard for sending messages between two or more applications. It allows application components based on the Java EE to send/receive messages. Similar to other messaging platforms, it allows the communication between different services of an application to be loosely coupled and asynchronous.
Before starting development on a custom SWIM client, a good understanding of JMS will help in planning project scope and architecture. The Solace developer portal contains a plethora of information to learn more about JMS message queues, interopability, available API/SDKs, etc.
Consuming JMS Headers, Properties and Content
A key component of your JMS message handling will be the parsing of different components or “sections” of data or metadata that make up a standard JMS message. The three components are a message header, message properties, and the message body.
The JMS Header section contains predefined fields that contain string values that are used internally between a JMS client/producer to identify and route messages. These are fixed metadata fields you’ll find in all JMS implementations. In the SWIM program you will typically inspect the message header for troubleshooting connections between your application and the producer, as well as reading the JMSMessageID, which is a GUID that uniquely identifies this particular message.
The JMSMessageID is useful for recording for additional troubleshooting/message reference and if you plan to include a persistence layer with your program architecture. Again, most of the header values describe aspects of the connection and JMS settings between client and producer and typically don’t require much inspection.
The JMS Properties of a message is where you will see more metadata about the message that are producer-supplied and not the JMS-standard fixed header fields. This is where message publishers, such as the FAA, add metadata of their own, separate from the fixed Header section.
You will be frequently reading data from the JMS message properties during application development as many key pieces of information are stored there.
For example, from the STDDS SMES ASDE-X message (Source: NAS-JMSDD-4307-003 SMES JMSDD Rev A.pdf)
When parsing SWIM JMS messages, you will likely utilize the getStringProperty() method to inspect message types, as defined in the service documentation. In this pseudo-code example below, we are checking to see if the message type is “SE”, for surface event or “AT”, which is an ASDEX message. The message is passed to different handler functions depending upon which type of message is being parsed.
Per the above Table 4, you can see that we could also inspect/parse other message properties such as airport or TRACON value. Remember that these property fields are unique to the feed(s) you are connecting to. In the SFPDS feed, the some properties have different names, for example “FDPS_MessageType” instead of “msgType” as found in STDDS. All of the property fields are documented in the appropriate NSRR JMS Description Document.
Expected JMS Message Size, Storage and Throughput
Each message from the queue varies in size (when on disk) depending on amount of content stored in the message. Most messages are just one or two kilobytes in size but will reach > 10kb in size depending on the service and message type. SFDPS messages which contain batched one-minute updates of en route flight plans have substantially more data and include data for multiple flights.
A batched SFDPS message would be considerably larger than a single STDDS ASDE-X position update.
Messaging is effectively ephemeral (short lived); file size should not be of particular concern to most FAA SWIM implementations if messages are parsed, processed, and discarded without any persistence.
SWIM JMS message size might be a consideration for size on disk, when saving JMS message contents to a disk in a text/XML format. We bring attention to SWIM message size as that is often a question our clients and partners have regarding volume and amount of data if you anticipate storing message content in some sort of block or object storage.
Interopability with Amazon AWS SQS (Simple Queue Service)
If your SWIM consumer architecture involves the AWS platform, you may have looked at utilizing Amazon’s Simple Queue Server, SQS. Route 3 Software has utilized SQS as an intermediary message queue for building JMS playback test harnesses for testing our SWIM consumers. SQS supports JMS publishing/receiving but there are a few things to know about compatibility.
When using SQS for JMS message playback, the JMSMessageId will be overwritten by SQS during message re-construction. If having the original JMSMessageId is important, consider writing that to another message attribute to ensure the value exists end-to-end.
Another important limitation of AWS SQS JMS is the maximum of 10 message attributes. You cannot copy all metadata from a SWIM message to a SQS message as you will encounter an error with the SQS library if you exceed the maximum number. It is recommend that only copy JMS message properties that are desirable for your SQS project and ignore the unused values.
It’s an exciting time to be an FAA SWIM consumer. By pairing SWIM capabilities with an advanced, cloud-first infrastructure, your organization can achieve operational improvements, develop innovation solutions, and achieve NextGen operational goals. Looking forward, SWIM’s capabilities are evolving and more NAS programs will be added to SWIM in the coming years. Operationally, SWIM provides an unparalleled amount NAS data which is delivered reliably and efficiently. For all SWIM consumers, a robust and well-planned IT architecture is paramount to success.
Route 3 Software is excited to continue leading the way in helping organisations make the most of their SWIM IT investment. Contact us to get started on your SWIM implementation.