Like the U.S. Interstate Highway System, air traffic control systems are based on 50-year old technologies, in the case of air traffic control, ground-based radars and voice communications over radio.

Ground-based radar antennas rotate 5 or 12 times per minute “pinging” aircraft every 12 seconds (or 5 seconds near airports). It is thus possible for aircraft to be miles away from where the controllers think they are. As a consequence, aircraft must be spaced 3-5 miles apart (horizontally).

Air traffic communications have not kept up with digital communications technology. Controllers still issue mundane commands like, “Descend to five thousand (feet),” “Fly heading 270 (fly due west),” and “Reduce speed to 180 (knots).” Furthermore, pilots rely on air traffic controllers to advise them of nearby aircraft.

Meanwhile, higher fuel expenses are motivating the aerospace industry and airlines to experiment with new technologies and procedures because more efficient flying means lower fuel burn, and fuel is the biggest or second largest expense for airlines.

In the United States, a large air cargo carrier uses Automatic Dependent Surveillance-Broadcast (ADS-B) to exchange GPS data with other aircraft in their fleet. Pilots can track the position and direction of similarly equipped aircraft, just like a marine radar on any passenger ship. This is especially useful every night when about one hundred aircraft converge on their hub airport in a narrow time window. Without the positional awareness made possible by ADS-B, disruptions, such as storms, cause traffic jams in the air, forcing them to fly in circles while waiting for their turn to land. With ADS-B units in the cockpit, pilots can space themselves prior to arrival, thus reducing congestion at the hub airport and saving fuel.

Over the Pacific Ocean, the ASPIRE (Asia Pacific Initiative to Reduce Emissions) is testing operational optimizations to burn less fuel on transpacific flights. ASPIRE flights are allowed to take advantage of every optimization during their oceanic flights, most importantly greater freedom to change their altitude and heading based on actually encountered atmospheric conditions, as opposed to conditions forecast hours before flight. This is enabled by precision navigation (GPS) and better air-ground communications. On a recent ASPIRE flight, a 747 flying from LAX to Singapore, via Narita, Japan burned 10,868 kg less fuel, while emitting 33,769 kg less CO2 (carbon dioxide).

Unmanned aerial vehicles (UAV) present new challenges to air traffic management (ATM). In Europe, the ATLANTIDA initiative (Application of Leading Technologies to Unmanned Aerial Vehicles for Research and Development in ATM) is tackling the challenge of applying Trajectory-Based Operations (TBO) to air traffic management (ATM) for Unmanned Aerial Vehicles (UAV). Instead of human air traffic controllers proactively controlling aircraft movements, which is especially challenging with unmanned vehicles, TBO takes aircraft trajectory data and computes optimal solutions and presents decisions to the air traffic controller. ATLANTIDA uses a net-centric service-oriented architecture along with a novel trajectory definition technology called Aircraft Intent Description Language (AIDL) to capture and distribute trajectory data, and has selected RTI Data Distribution Service for its implementation.

The benefits of better air traffic control and management are more efficient flying and lower fuel burn. Consequently emissions are lower. RTI is playing a role in the future of air traffic management and helping the world be a little greener.

Click here for more articles on DDS. Click here for whitepapers on DDS, including a link to the Embedded Market Forecasters study that finds DDS middleware from RTI improves ROI when compared with other alternatives.

This broad-based research provides the first independent quantification of the reduction in integration time, cost and risk you can expect from RTI Data Distribution Service. Findings include:

• Up to 45% Lower Total Cost of Development: The average cost of application development was substantial for projects using internally developed “Roll-Your-Own” (RYO) middleware ($1.61M) and most commercial solutions ($1.34M); however, projects using RTI middleware enjoyed much lower costs ($0.89M).
• Up to 47% Lower Cost Overrun: The average cost overrun was similar for projects using RYO (11.3%) and most commercial middleware (10.1%). Projects using RTI finished closest to expected cost (6.0%).
• Lower Testing Costs: In projects where the cost of testing was less than 30 percent of the total development cost, RYO (72.5%) showed an advantage over commercial (65.5%) middleware. Projects using RTI’s commercial middleware, however, had testing costs less than 30 percent of the total development cost 84.6% of the time.
• Greater Probability of Meeting Design Requirements: Final design outcomes using commercial middleware in general, and RTI in particular, were much closer to pre-design expectations than RYO developments for performance, functionality, features and schedule.

Visit EMF’s web site to download the full report for free:  Choosing between Commercial and ‘Roll Your Own’ Embedded Communication Integration Middleware.

NASA was RTI’s first customer.  In fact, NASA funded the research at the Stanford Aerospace Robotics Laboratory that spawned the technology that became RTI and the DDS standard.

The progress in the NASA program during that time is stunning.  In the 1990’s, robot controllers were clunky boxes with primitive sensors and no real connection off board.  It was a huge accomplishment just to wander around dragging a huge umbilical cord for power and control.  Today’s program connects impressive vision systems, planners, and controllers.  They can be controlled live or run nearly autonomously.  The computing system networks dozens of processors in ground stations and vehicles.  The stovepipe systems (and rivalries!) at the different research centers years ago gave way to common system architectures that allow efficient sharing of code, data, and research progress.  The robots can work independently for long periods in realistic environments.  The researchers can work together in shorter periods on realistic progress.  That’s the Way Things Should Be…

Of course, the networking technology has also made great progress.  The middleware grew from a specialized data server to a general-purpose international standard.  From our research beginnings, RTI now claims hundreds of designs in a dozen industries, including many real-world mission-critical, 24×7 applications.  We are not alone; the DDS standard is backed by multiple vendors in a growing, competitive market.  That’s also the Way Things Should Be.

Anyway, I’m glad we could be some small part of this program.  I want to congratulate NASA on its decades of progress towards the vision of enabling capable, cost effective exploration of our universe.  The sky may be the limit.  It’s refreshing to see and work with those who know it’s the lower one.

With the maturity and broad adoption of DDS, we are seeing a couple of trends.

• DDS is being used in larger and more geographically disperse systems
• Customers are moving to second-generation DDS based systems
• Users are integrating multiple systems that already deploy DDS as their underlying integration bus

To support these efforts, RTI recently introduced RTI Routing Service. RTI Routing Service provides a flexible solution for scaling DDS systems and for integrating disparate DDS applications. This includes:

• Applications that cannot directly communicate because they run on different networks (LAN and WAN), use different transport protocols (e.g., shared memory, IPv4 and IPv6), or are members of different security domains
• Applications that natively use different DDS data types, such as new and legacy applications, individual systems within a System of Systems, and applications that support different Communities of Interest (COI)

To learn how RTI Routing Service significantly reduces the costs of real-time system integration, upgrades and of implementing Cross-Domain Solutions (CDS), visit RTI’s web site or watch this video demonstration.

Many developers suffer from confusion with respect to the differences between mutexes and semaphores. Michael Barr of Netrino provides solid information in his article Mutexes and Semaphores Demystified. My summary: mutexes protect shared resources by enforcing mutual exclusion; semaphores should be used for signaling across tasks.

Niall Cooling of Feabhas provides a longer discussion in two parts:

1. Mutex vs. Semaphores – Part 1: Semaphores
2. Mutex vs. Semaphores – Part 2: The Mutex

Cooling focuses especially on the problems that arise when developers use semaphores where they should rather use mutexes. In particular, he discusses accidental lock release, various causes of deadlock, and priority inversion. (The latter is of special interest to developers of real-time software.)

Although semaphores and mutexes are critical concurrency-control structures, the APIs to use them unfortunately differ from platform to platform with respect to both form and function. At the end of his Part 2, Cooling briefly summarizes some of the differences between the semaphore and mutex APIs of several operating systems. This section will be of interest to anyone developing systems that will be ported across very different platforms. Chris Simmonds goes into more depth, with respect to Linux in particular, in his article Mutex mutandis: understanding mutex types and attributes posted on The Inner Penguin.

One of the really powerful things about DDS is that it brings to distributed systems the same kind of type safety that you’ll find in local applications. In addition to reducing errors, this deep knowledge of data types can improve performance and resource usage by reducing the number of data copies in the system and easing integration with other field- and type-aware technologies, including relational databases and even Microsoft Excel.

But as systems evolve over time, type definitions can evolve too, and it’s important that applications that are already deployed don’t break as the types used by new applications change. It’s also desirable to ease the development of infrastructure or cross-cutting components — like tools, recorders, generic data routing and transformation facilities, and others — that shouldn’t be tied to specific data types. DDS users have been solving these problems in a variety of ways for some time, and some implementations address them already, but it’s time for a standardized solution.

To that end, the OMG is working on a new specification, Extensible and Dynamic Topic Types for DDS, that will provide additional capabilities for the following:

• A clarified and extended type system that incorporates keys and extensibility as first-class concepts
• An API for the definition of new data types at run-time without code generation
• A reflective API for the construction, inspection, and manipulation of data samples based on dynamic type definitions
• The ability to define data types declaratively using not only OMG IDL but XML and XML Schema (XSD) as well for easier integration with enterprise systems

The proposed specification will be discussed at the OMG Technical Meeting next month and some outstanding open issues addressed. I expect the proposal to be voted on and approved at a subsequent meeting not far in the future.

If your organization is an OMG member, you can access the in-progress specification proposal documents yourself.

I don’t know a thing about cars, so it seemed to me that there was a flaw in this plan.

“What if,” I asked, feeling like a jerk already, “it turns out that my [part] isn’t broken after all, and the problem is caused by something else? Then I’ll have a brand new [part] on my hands that’s of no use to me.”

The mechanic looked frustrated. “Well, I could run an electrical test first. We charge $35 for that. Do you want me to do it that way?”

I resisted the urge to retort, “You’re the mechanic; you tell me!”

The thing is, he really wanted me to pay him for a part, and I really wanted to pay him to make my car work. If I’d been an expert myself, and knew in detail what my problem was, and how to fix it, I would have been very happy to buy a part. I bought one in any case and crossed my fingers — I got lucky this time. But next time, I’ll be looking for someone else to help me, someone more able to speak to me in my language.

I’m sure there’s an analogy to software in there somewhere.

Recording Data

The simplest case of persisting data in a distributed system is recording the data to a file system. This can be done locally for each node, or centrally on a “recording” node. Each system setup solves different problems. Persisting local state on each node allows you to recover from a local crash by reading that state during recovery. Recording all the data on a centralized node allows you to query the entire set of data recorded (not just the subset any node would see) to find patterns or anomalies, or do a post-mortem on a system failure.

Locally each RTI Data Distribution Service publisher or subscriber keeps samples in queues. To allow for local persistence a mirror of these in-memory queues can be kept on disk. After a crash the publishers and subscribers can then be created with the same state as they had before the crash.

Centrally you can run RTI Recorder that can be configured to subscribe to interesting data (or all data for that matter) and write it to a file system. This data can then be queried either in real-time or during off-peak hours. As an aside RTI Data Distribution Service and RTI Recorder have countless flight hours on mission critical systems!

Connecting the Distributed System to an Enterprise Database

In some cases simply having the data on a file system is not enough — the full power of an enterprise database is needed. At RTI we have solved this by having RTI Real-Time Connect for ODBC enabled databases. Now you can use RTI Data Distribution Service to implement a distributed database, or utilize a database for your persistent storage needs. This allows you to use any tool or query you are familiar with to work with a distributed set of data. The possibilities are literally endless!

No matter what the use-case — recovery, logging, post-mortem analysis or database integration — persisting real-time distributed data is here to stay. The challenge is persisting the data with minimal intrusiveness on the real-time aspects of the system. At RTI we work hard to make that happen.

With this deluge of information, because of the gap between the large volume of data produced and people’s ability to process the information, operators may even be less informed than before. For the information to be processed correctly, it needs to be integrated and interpreted correctly. In addition, the system must provide the operator with the information in a way that is usable cognitively and physically. The system should be designed in such a way so as to support the operator under dynamic operational constraints. This is what Situational Awareness is about — about knowing what important things are going around you.

At the basic level, Situational Awareness (SA) is about determining what information is relevant and how to collect that information. The next level extends SA’s capabilities by understanding that information. This includes how people combine, interpret, store, and retain information. This also includes how information is integrated from multiple sources. In addition to integrating and classifying the information, it is also important to determine how important that information is.

How much of situational awareness in enough? While it is important to have as much information as possible, it is imperative that more information does not come at the cost of processing (comprehending) information that is classified as being more important. The next level –“level 3” — deals with acting on the information. This also includes forecasting future events, and providing recommendations on how to react to such events. The way in which the operator directs her attention in acquiring and processing information fundamentally impacts situational awareness.

Time is a critical ingredient in achieving situational awareness – how much time is available until a specific event occurs or some action must be taken, using time to correlate multiple events of interest. Space is another aspect – correlating events of interest within a space. Lastly, real-world situations are dynamic – they keep changing. So it is important to incorporate the rate at which the information is being updated in the design of a SA system.

Ultimately, the role of building an SA system is for enabling operators to make the correct decisions in a timely manner. It is entirely possible for the operator to have a perfect SA system and still make an incorrect decision. This could be due to poor strategies, tactics or training, among other reasons. So it imperative to have, where possible, a linking between recognizing a situation and taking a decision based on that recognition. Of particular importance is the technique of pattern-matching to recognize information belonging to a known class of situations. With experience, the pattern-recognition/action-selection sequence can become automated and reduce demands on the operator.

To summarize, SA is about creating a model where the system state is captured, including creating an understanding how that state is affected by projected events. A good SA model integrates relevant information from multiple sources, determines the relative importance of different events, and projects the state of the system based on events. This also implies that, to build a system that is situation aware, the model must be accurate and must have the ability to be updated to reflect the current events.

With the technologies available from Real-Time Innovations (RTI), application developers can build an open, standards-based platform that can be used to collect, integrate, and analyze the information required for building a situational aware model for monitoring the enterprise health of a network. This framework will integrate with third-party sensors and probes (using algorithms for sensor fusion) for the accumulation of information and will leverage the  latest advances in groupware applications for providing situational awareness to the operator and enabling them to make distributed decisions in a cooperative manner.

With RTI Data Distribution Service, we can address the following needs of situation-aware applications:

• Enable integration of heterogeneous sensors, across domains and networks
• Provide dynamic, evolvable and type-safe data representation & encapsulation
• Provide minimally-intrusive, efficient, scalable, and real-times-aware collected-data distribution
• Evaluate advances in Service Oriented Architecture (SOA) for enabling integration of information from multiple sources
• Conduct post-attack analysis to determine new patterns for future threat detection

In addition, with complimentary RTI technologies like  Complex Event Processing (CEP), RTI can address the following needs:

• Provide event correlation, through time and space, from multiple sensors
• Apply algorithms from sensor fusion when multiple sensors are observing the same situation
• Determine what data to collect to fight through a cyber conflict, how to protect the security of the network, and how to provide autonomic response to attacks including reconfiguration, recovery, and reconstitution while allowing mission-critical systems to continue to function

For more information on building a situation-aware model using RTI, contact info@rti.com.