However, because UAVs are designed for specific mission parameters, it is technically difficult to reconfigure UAV software systems when other missions take a higher priority.

By focusing first and foremost on data interfaces within and between software components along with the integration of those interfaces, UAV system designers can unlock software architectures from a specific technology. The primary objective is to design systems with an unprecedented level of flexibility while improving overall system reliability and sustainability.

Designing and building a UAV is one of the most difficult problems in engineering, and it is particularly challenging from a software systems perspective. As mission parameters change, often it is not possible to adapt software to perform well in changed operating environments.

By optimizing software performance, scalability, availability, reliability, security, interoperability and affordability, system designers can create a UAV that is adaptable to new mission parameters while remaining robust across the product lifecycle.

UAV architecture consists of a set of systems or systems-within-systems with potentially dozens of separate computers and associated subsystems—each processing within its own problem domain - with the need for real-time data communications and interaction with ground control.

Connectivity between systems and components is established using different networking technologies, including spotty wireless links as well as high-speed local-area networks (LANs).

This complexity, combined with the need for constant real-time data exchange between components and between the UAV and ground control, makes adaptation to new missions and roles problematic.

The primary use of a UAV system is to support and enable the mission payload with the necessary means of functioning and to collect and distribute the data from the payload to the end users on the ground. Likely an unmanned system will have complex problems to solve throughout its lifecycle.

What system designers need to aim for very early on is an architecture that can accommodate changes to the system and still retain the basic architecture principles mentioned above.

The key is to leverage existing technologies that abstract design away from a specific, hard-coded implementation. Such technologies have the ability to ease the overall design process while enabling the development of a more robust and flexible architecture. A primary abstraction involves the data interfaces between the various subsystems and components throughout the entire UAV system.

Basic UAV System Components
At the highest level, the UAV design can be segregated into three separate subsystems: the air system, the ground system and the tactical data link that provides real-time communication between the two.

Each of the three subsystems is technically complex, and combining them into a complete system increases the complexity exponentially. The real-time data streams cause rapid and unique interaction events between those systems that must be analyzed and responded to in a timely manner, even though the systems are almost always separated by distance and intermittent connectivity.

The mission-critical nature of UAV systems adds requirements that further complicate the design. Real-time data availability, processing and response are additional requirements, as are high-availability and reliability—all of which typically require complex redundancy management and careful tuning of all code components.

Further, UAVs are almost always designed for specific mission parameters and optimized for those missions. It is unlikely that a ground-imaging or data-collection UAV will be able to readily carry a weapons payload along with its own.

Because of the small size and limited power supply of a UAV, it is currently not easy to swap mission parameters and payloads without difficulty. Too many characteristics tend to be hardwired into the design and implementation to easily configure for multiple mission demands.

A Focus on Data Interfaces
The transmission of data between nodes and between subsystems in the UAV is possibly the most demanding engineering problem to address. For example, the navigation subsystem requires data, such as airspeed and directional gyro, from various instruments as well as the control surfaces.

The navigation system must make adjustments to course, altitude and speed and direct the control surfaces to respond in a way that implements those adjustments. Of course, data must be available in real time so that the movement of control surfaces is contiguous with speed, direction and altitude data.

Likewise, each of the major subsystems also requires multiple connections. For example, the navigation subsystem on board the vehicle must be able to provide data directly to ground-station instruments so the pilots remotely controlling the device have real-time feedback on aircraft position. In addition, a pilot's movement of controls in the ground station must result in immediate responses by airborne control surfaces.

The most common approach is to implement connectivity between processing components as a series of point-to-point, dedicated connections between those subsystems requiring predictable real-time communication.

A point-to-point connection guarantees a fast and predictable data-transfer time, which is a key component of overall response time. This architecture results in good overall performance. It is seemingly simplistic in concept and implementation.

However, the use of dedicated, point-to-point connections has two serious failings. First, though the connections look simple, when there are N different subsystems, establishing direct data connections between each of them results in N times N connections.

Though it is likely that direct connections between all subsystems are not required, such connections would still increase the complexity of highly interconnected systems to the point where cost and maintainability would be problematic.

For example, what level of engineering work would have to be accomplished if a new subsystem dependent on point-to-point connections had to be introduced at a later time?

Consider the later introduction of a logging subsystem that captures all real-time data traffic for off-line mission replay or analysis. The new logging subsystem would have to be connected to all or most existing subsystems.

Second, point-to-point connections do not take into account the need for redundancy in case of failure.

If the connection between the remote pilot on the ground and the control surfaces in the air fails, there could be a complete system failure -and subsequent UAV crash. Therefore, it is necessary to build redundancy into the architecture, which requires multiple direct communications pathways or routing from other subsystems.

Figure 1: Point-to-point architecture is suitable for simple component connections, but it becomes overly complex and brittle when supporting many components.

Figure 2: In complex systems, it is most efficient to provide for a

In either case, redundancy further adds to the complexity of the system. Much of this complexity would fall upon the software, which would have to handle failure detection, data recovery and rerouting.

It is certainly possible to design and build a UAV with multiple direct connections between processing and control subsystems and to implement failover and other Quality-of-Service (QoS) features that are distinct and customized to that vehicle.

However, the cost of doing so can be significant, and a custom design using these characteristics will almost certainly negatively impact maintainability throughout the life of the vehicle.

DDS: A Flexible Data-Oriented Architecture
A more flexible, scalable and adaptable approach is using a middleware technology called Data Distribution Service. It has been defined as a standard for network middleware with the Object Management Group (OMG) and officially termed the Data Distribution Service for Real-Time Systems (DDS) standard.

This standard provides for the use of a publish-subscribe communication model that enables data producers to autonomously publish data to a smart-data infrastructure and allows data consumers to subscribe to data from this data infrastructure.

The data is abstracted away from the source and made accessible to any application that subscribes to it, independent of the source's location and the specific link technology that transports the data.

DDS enables a resiliency of data necessary for fault tolerance across the network. There are commercial implementations of the OMG DDS standard that adhere to published specifications while also offering high performance for specific distributed systems and applications.

The standard also supports a high-performance real-time response for data exchange, as well as QoS parameters such as reliability, durability, deadline, priority and data ownership. By adjusting QoS parameters, system and application software developers will be able to ensure that the transmission and reception of data meets the unique needs of each system and application.

The rich QoS parameter set makes it possible to implement DDS on a wide range of processors and networks, including those that are embedded. Commercial off-the-shelf (COTS) systems that have implemented the OMG DDS standard have been used in a growing number of defense systems projects with success.

This combination makes possible a robust data communications infrastructure for a UAV. Consider a data-driven design based on abstracting data away from the code acting on it and placing the data in known locations on the network. Such an infrastructure has the advantages of direct connections between subsystems—without the corresponding disadvantages.

It is possible to think of the DDS infrastructure as a logically shared data bus where data producers and consumers post and request data. From the point of view of the system designer, the data bus implements the details of getting data from one component to another in real time and with an acceptable QoS.

The design problem is abstracted to determining data needs for components and determining the appropriate QoS. The DDS infrastructure acts as the data bus that transports the data from source to consumer.

Figure 3: The DDS infrastructure manages the transport of data from one component to the other.

How does a data-oriented architecture address the need for direct interconnections between individual subsystems? Actually, it provides the same end result, albeit by a different method.

Rather than passing data directly between hardwired subsystems, the DDS infrastructure enables subsystems and individual code components to publish - or post - data to a logical location on the network. Other subsystems subscribe to that data.

In effect, the data distribution middleware makes the decisions about the mechanics of getting data from one location to the other. The actual transmission of the data is managed by the middleware. The application code only has to ensure that the data is published or that the data is subscribed to, rather than having to implement the mechanism.

Could it be simpler and more straightforward to code data transfer via direct connections? In that case, it would be necessary to design and code for not only the physical data transmission, but also response-time tolerances, failover and other QoS characteristics.

This alternative makes for large amounts of detailed code that must also be tuned for performance, an approach that is both time consuming and prone to error.

In contrast, configurable QoS is a primary advantage of the DDS standard. In particular, QoS parameters - such as delivery modes, acknowledgement response time, durability and lease duration - are necessary to make it possible to tune the software's performance and reliability to the underlying network technology.

Specific properties of low-bandwidth, unreliable wireless links as well as high-speed interconnects can be addressed in this way using a single communications infrastructure. Ideally, QoS would be matched to the latency and bandwidth requirements of each data stream to deliver data where it is needed, when it is needed.

Redundant data pathways are still required physically, but they need not correspond to logical point-to-point connections between subsystems. In fact, it is highly unlikely that any such direct connections would be needed.

Rather, the network architecture can be designed to optimize QoS characteristics such as latency, failover and data priority. The physical architecture of the network can be based on these characteristics, leaving it to the middleware to publish data, subscribe to data and manage the overall flow of that data.

Real-Time System Architecture Maintenance
No single UAV design can successfully meet all of the possible mission requirements for such vehicles. However, by applying a data-oriented architecture, a more flexible design results that can meet the needs of a variety of missions because it has optimized the tradeoffs inherent in design.

A data-oriented architecture reduces complexity by abstracting implementation details away from the code, letting developers write less code to achieve a more robust solution.

The OMG DDS standard and its commercial implementations make it possible to develop data-driven systems and software while also practicing abstraction. The result is less application code, improved system responsiveness and the ability to meet more mission parameters in actual use.

Dr. Edwin de Jong is Director of Product Management and Strategy, Core Products at Real-Time Innovations, Inc. He has more than 15 years experience in the architecture and design of large-scale distributed real-time systems in applications such as C4I, radar, track management, multi-sensor data fusion, threat evaluation, weapon and sensor assignment, and simulation and training. Edwin holds a Ph.D. in mathematics and physics from Leiden University, The Netherlands. Editor's Note: To learn more about high-performance messaging middleware download the RTI Shapes Demo.