RTC Magazine

Embedded systems are no longer self-contained boxes of electronics and firmware. Many of them now have to interact with the rest of the world. They have to cooperate with each other, and in turn provide information to upstream systems so that other embedded systems, human operators and even the general public can see what is going on.

You can see this effect in a new generation of traffic-control systems. Data from traffic sensors does not just control how traffic lights and active road signs operate in real time. The same information is used to provide an overview of what is happening across a city to operators in a control center and fed to public information kiosks around the city to let people know what their journey will be like. It may even be streamed to drivers in their cars. This is the structure of a new class of “system of systems” and it requires a fresh design perspective to address the realities of integrating components from multiple independent providers.

Service-Oriented Architecture (SOA) has emerged as an effective paradigm in the enterprise computing space for addressing integration of software components. How do we utilize the SOA guiding principles of reuse, granularity, modularity, composability, componentization, interoperability and standards compliance to the design of embedded and real-time systems to achieve similar business benefits? What are the fundamental underlying principles that we can utilize to integrate embedded systems with enterprise systems, while optimizing end-to-end real-time performance? Can this be done without magnifying the ongoing operational and administrative costs?

We address these concerns by introducing the framework of “Data-Oriented Architecture,” which can be viewed as a SOA for real-time development and end-to-end integration of disparate independently developed software components. The data-oriented architecture framework results in “loosely coupled” software components with data-oriented interfaces that can be seamlessly integrated using a high-performance standards-based communication middleware infrastructure, such as the Data Distribution Service (DDS).

A Real-Time System-of-Systems Scenario

The air traffic control example of Figure 1 involves a variety of disparate systems that must seamlessly operate as a whole. On the “edge” is a real-time avionics system inside the aircraft, which may communicate with a control tower. The data flowing in this system is typically at high rates and is time-critical. Violating timing constraints could result in the failure of the aircraft or jeopardize life or safety.

The control tower is yet another independent real-time system, monitoring various aircraft in the region, coordinating their traffic flow and generating alarms to highlight unusual conditions. The data flowing in this system is time-sensitive for proper local and wide-area system operation, although it may be a bit more tolerant of occasional delays.

In our simplified example, the control tower communicates with the airport enterprise information system. The enterprise information system keeps track of historical information, flight status and so on and may communicate with multiple control towers and other enterprise information systems. The enterprise system is not in the time-critical path and therefore can be much more tolerant of delays on arrival of data. This enterprise system is responsible for synthesizing a composite “dashboard” view, such as passenger information, flight arrival and departure status.

Key Integration Challenges

Such a system of systems must effectively deal with various issues. The information crosses trust boundaries, where each system is controlled and managed independently, and involves social, political and business considerations. The quantitative and qualitative differences in the data exchange, performance and real-time requirements across the disparate systems must be dealt with. For example, an edge system often carries time-critical data at high rates, some of which must eventually trickle into an enterprise system. Also, the architecture involves different technology stacks, design models and component life cycles. Many of these systems have different components evolving at different rates and being upgraded independently.

By their very nature, the systems under consideration are loosely coupled—minimal assumptions can be made about the interface between two interacting systems. The integration should be robust to independent changes on either side of an interface. Ideally, changes in one side should not force changes on the other side. This implies that the interface should contain only the invariants that describe the interaction between the two systems. As behavior is implemented by each independent system, the interface between them must not include any system-specific state or behavior. Therefore, the essential invariant is the information exchange between the two systems (Figure 2).