A response to a prev
ious blog, which asked the following questions:
“How should NextGen perform information exchange? Specifically, how do we adopt a services-oriented approach to federating existing networks that accommodate transparent, timely, and safe exchange of authoritative data between all appropriate constituents of the National Airspace System (NAS)?”
The questions posed are about “how” – how to do information exchange, how to adopt a service-oriented approach. However, before diving into that, I suggest that “what” and “why” are just as important. What information is to be exchanged? Who is involved? What are the operational requirements? What policies must be accounted for? And, finally, is it worth the effort?
The astute reader may remark, “You’re in danger of missing the point. We need a big-picture solution that works for all cases, some we don’t even know about today. If we get bogged down in too many details, we’ll end up with a patchwork of near-term solutions that don’t scale.” It’s a valid concern. Still, without exploring some specifics, we can’t be sure that we’re solving even today’s problems, let alone tomorrow’s. Concepts of Operation, scenarios, use cases, etc. – and, specifically, the net-centric aspects of these – are an important part of working out the “what” and “why” details.
We need to do a tricky thing, which is to apply “top-down design” and “bottom-up design” in parallel. That is, we need to iterate between designing for the big picture and designing for the specific needs. When both those efforts meet in the middle, like railways converging from the east and the west, you can hope to have a good, total solution. At the “bottom-up” end, this approach requires selecting a manageable set of specific problems… a good topic for another day.
Having said all that, this would be a poor post if it didn’t make some attempt to address the questions as posed, so here goes.
A key element in working out the big-picture “how” is to reference well-accepted, mature standards to the maximum extent possible. There is no way that multiple federal organizations and industry partners are going to agree on a common vendor or platform (nor would this be beneficial at the macro-system level). Therefore, the best path to interoperability is for the partners to agree on standards that define compliant interfaces between them.
In fact, standards may become so critical to success that it becomes appropriate for NextGen as a collective group to apply pressure to move the necessary standards toward maturity. If we get stalled by insufficient standards for NextGen, the result will be a failure to interconnect, interoperate, and make progress, period. In other words, everyone loses, even vendors that might in other situations benefit from proprietary offerings, because it’s just not feasible that the entire NextGen space will buy into a proprietary solution. The investment timelines are too long, the partners too diverse.
I wouldn’t say that any applications are “easy,” but some are more straightforward than others. For example, exchanging weather information is relatively free of identity management and privacy concerns, and has relatively achievable QoS requirements (e.g., delay of a minute or two in updating a forecast seems acceptable). This combination of factors has permitted weather information exchanges to make quite impressive progress, thanks also of course to the efforts of many dedicated individuals. The JPDO Weather Working Group and associated programs have met most of their requirements for “infrastructure-level” standards (so far) by referencing existing industry standards such as XML, SOAP, and ebXML. (For weather, the “information level” is more interesting, bringing in organizations like OGC and standards like WXXM, but that’s a bit off-topic.)
Other applications, however, are likely to have more stringent information exchange requirements, for example: real-time traffic data, trajectory and airspace negotiations, emergency response coordination, etc. In such cases, it will be more challenging to identify (or develop) an acceptable set of infrastructure-level standards and agreements. Key areas are likely to include authentication/authorization, information assurance, infrastructure provisioning and monitoring, and quality of service. I’m sure this list is not complete. Even among standards, “the devil’s in the details.” What standards should be selected? In what areas are standards insufficient today? Exploring specific standards areas could be a productive next step.
Standards are a part of the solution. However, answering the questions posed will require many other aspects, large and small, to come together. Perhaps the most important step toward a complete answer is to continue building and resourcing a collaborative team focused on the challenge.
David Rinehart
Senior Systems Architect