In the complex software environments of both aircraft and ground station, many applications must communicate. Historically, developers built these as complex independent systems, connected over an equally complex data-link management system. Recently, both air and ground platforms have turned to standards-based messaging middleware with great success. Messaging middleware provides a “clean” interface to dataflow, greatly increases development ease, enables simpler system evolution and improves performance.

Unmanned Aerial Vehicles (UAVs) demand reliable communications with ground stations. Developers invest heavily in the data link; it has direct impact on the range, flight time and sensor feedback capabilities of the system. It is crucial to the competitive value and ultimate success of the platform. There are many technologies to provide data links. However, the data link provides just low-level physical transport and signaling, and just air-to-ground communications. For example, the Insitu (Boeing) ScanEagle UAV (Figure 1) runs DDS middleware as the backbone of the flight software.

With that in mind it’s useful to examine the potential of extending messaging into an end-to-end coherent architecture. With an end-to-end design, application developers can naturally access data on either end of the link, greatly simplifying distributed application design. Of course, it places much more stringent demands on the middleware, since it now must integrate the aircraft software, the ground station software and the data link between them. A tall order.

UAVs: A Challenging Environment

The software that drives UAVs can be very roughly divided into three obvious pieces: the aircraft avionics, the ground station and data link. These are very different environments with unique challenges.

Avionics and Ground Station Software: The deeply embedded UAV is a constrained environment, where power and weight limits impact every decision. UAVs must house a flight control computer, a sensor array, payload management and possibly weapons systems. These will likely be connected via a variety of system bus and network transports and may be supported by a real-time operating system (RTOS). Additionally, the software may be subject to safety certification standards, such as DO178B.

The ground station, by contrast, is more likely to resemble a high-powered ruggedized workstation. It usually runs a general-purpose operating system such as Linux or Windows, and includes a flight-operator interface, a data visualization/display computer that connects to the UAV payload, and increasingly an interface to a broader net-centric environment into which the UAV system is integrated. Both aircraft and ground station must have a data link controller to affect communications. In complex systems, the UAV may need to communicate with many ground stations, or even interact with other UAVs or manned aircraft.

The Data Link: The data link connects the UAV to the ground station. The data link signal has to contend with a wide range of communication problems, such as lost packets or connections, maximizing the use of limited bandwidth, and changes in ground station control authority.

In addition, there are several link types, each with its own unique set of performance, integrity and reliability requirements. Any messaging system built to run over each link type must meet the specific demands of that link. Low-level data link protocols, like Link 16 and the newer Link 22, do a good job of managing the fundamental connection. Depending on the design, the data link layer may mitigate some of the fundamental issues, such as signal reflection management. Fundamentally, however, the data link layer cannot present a view of the connection that completely hides reality, such as working over transient, lossy links. That level of service must be provided by a higher-level protocol

UAV Messaging

Of course, applications running in all three parts of the system must cooperate to accomplish the mission. With the wide range of requirements, physical transports and constraints, it is tempting to believe that only a set of very specifically developed and separately optimized communication methods will suffice. In fact, in the past, this is exactly the chosen path. Unfortunately, this path is indeed rocky, resulting in expensive, difficult-to-maintain software. A more ideal architecture would provide clean, powerful communications within and between components.

Many UAV and other defense application developers have turned to the open Data Distribution Service (DDS) standard, managed by the Object Management Group (OMG), for a messaging framework. Existing applications include UAV applications such as the Insitu Scan Eagle UAV and the General Atomics Predator UAV ground station (Figures 2a and 2b), as well as many other mission-critical communication applications such as the U.S. Air Force/Navy Common Link Integration Processing design. Of course DDS adoption goes well beyond UAVs. In fact, DDS is becoming the standard messaging communication in most military systems.

U.S. Navy programs that have designed DDS into their future include most surface ships (LHA, LPD, LCS, Aegis and the DDG 1000 destroyer series), weapon systems (SSDS, VLS), and many communication and C4ISR systems (CLIP, CEC, CNI). The Army’s huge Future Combat Systems (FCS) program heavily uses DDS, as do many airborne radar systems (AWACS, E2C). Several European and Asian designs also use DDS, including the Tacticos battle management system by Thales in France, and the FFX ship being developed in South Korea. Key applications within these systems include radar track management, communication management, cooperative engagement and sensor fusion.

DDS specifies a publish-subscribe (PS) model. DDS is most distinguished from previous communication standards by its strong Quality of Service (QoS) parameters. DDS QoS parameters specify the degree of coupling between participants, properties of the overall model, and real-time communication and delivery requirements on a per-data-stream basis. DDS service control includes deadlines for message delivery, bandwidth control, reliability model control, failover and backup specification, data filtering and more. It has proven flexibility to adapt to embedded environments, high-performance server and workstation integration, and use over both extremely fast and slow, lossy communication paths such as satellite links.

Simplifying UAV Design

Working systems demonstrate that DDS can successfully deliver the needed capabilities within ground and air systems. The question now is if DDS can serve as a link protocol and thus offer a complete system-wide messaging framework. Such a framework would open a new vista in system design. It could allow not only point-to-point data links, but also provide distribution capability in real time across the entire UAV system and out to the net-centric environment.

Application developers on both the aircraft and ground station could directly subscribe to needed information, insulating current and future designs from changes in the data link protocol or applications on either end. Data “discovery” could simplify initial connection, as well as connection management such as backup channel use, switching ground station control and “area of interest” management. The data-centric view offers potential for full-system connectivity.

Of course, this vision requires a strong dose of reality. DDS is proven as a distributed messaging environment without the challenges of a data link. Let’s take a look at three of these challenges and how DDS could address them: link fallback, power conservation and multi-station handoff.

Example: Link Fallback

The most fundamental issue between the UAV and ground station is that the data link is lossy and transient. These effects should not require management by an application like the flight controller. Therefore, the messaging layer should hide and resolve problems such as lost or out-of-order packets from the application layer. For example, commands sent from the ground station to the UAV flight computer usually require confirmed result feedback to the ground station.

DDS provides consistent, configurable reliability and delivery on top of any type of reliable or unreliable transport. The middleware thus abstracts the handling of these issues so that applications become modular without specific code for handling reliability and delivery. Application code only needs to configure the level of QoS required for their particular data streams.

For example, with DDS, the application could define this publisher/subscriber relationship as “Reliable.” This tells DDS to select a reliable packet model (one of several options) on top of the transport to deal with lost packets. Despite the automatic reliability, the application may still want to control detection and response when the link fails. Setting the QoS of Durability = Transient_Local with a further qualifier N for the amount of historic messages to keep, directs DDS to keep the last N messages stored locally in memory; this message data is then available for an application re-synch after re-establishment of a lost connection. The flight computer application may also want to define what time duration of link loss constitutes a link failure from its point of view. If so, the “Liveliness” lease duration can be set to this acceptable link down-time (for example 5 seconds), or even modified dynamically to account for mission events, such as intentionally going out of communication for a few minutes.

DDS also allows applications to be notified, and therefore respond, whenever events occur that violate the reliability (or other QoS) settings. Thus, it can deliver both transparent reliability, or application control, or any combination between.

These QoS configuration options demonstrate the flexibility of DDS to be adapted to some of the real-time message issues in a UAV data link. It also shows how DDS allows an application the ability to define its real-time constraints in terms familiar to the application developer. DDS automatically executes against those constraints and validates that both the subscriber and publisher, and by implication the physical transport, can meet those requirements, reporting back to the application when those real-time communication objectives are not met.

Example: Power Conservation

Power conservation is paramount within the UAV system. Minimizing the amount of data transmission off-vehicle can greatly help reduce power consumption. One benefit of publish-subscribe is easy connectivity. Unfortunately, this also encourages expensive transmission.

To mitigate this, DDS provides additional data-filtering capabilities. For instance, the UAV can set filters limiting the rate of reception of commands, limit receipt of situational data to that in its area of operation, or select which ground sources it will accept. DDS will then eliminate any unneeded data instances from the data link. The same holds true for the opposite direction; the ground station can filter data from the UAV before transmission across the data link. These filters are dynamically changeable to accommodate changes in mission operations. Grouping is also available; a QoS called PARTITION divides the network into subsets, saving transmissions between uninterested parties. The result is a dynamically self-optimizing data link that only sends relevant data to/from the UAV, therefore reducing unnecessary power consumption.

Example: Multi-Station Handoff

Because it supports automatic discovery and easy transfer of connections, publish/subscribe helps deal with one of the fundamental challenges of the UAV System design: the transfer of control of the UAV between ground stations. With DDS, a UAV application subscriber can ‘listen’ to multiple ground station ‘command’ publishers. Every publisher can be assigned a ‘strength’. If a ‘command’ subscriber in the UAV receives messages from several ground stations, the application will only receive the ‘command’ from the strongest publisher.

To explicitly manage transfer of control of a UAV from one ground station to another, the currently active ground station ‘command’ publisher could await notification from the UAV that it was receiving a satisfactory validated stream from another ‘command’ publisher. A ground station can take control by increasing its strength, automatically superseding the current controller. This capability also provides failover; if a publishing ground station goes dark or a data link fails, the next-lowest strength station or backup data link will automatically get control. This is of course simplified, but is illustrative of the potential.

Data Link: The Critical Glue

The data link is the critical glue that integrates a successful UAV system design. Ultimately, evolving from a series of specialized links into an end-to-end messaging framework promises much more flexible, powerful integration. The fundamental benefit of quality-of-service publish-subscribe messaging is that the complexity of determining who is sending “what data over which transport when” becomes transparent to the application. This effectively decouples the system, making the application code far more portable and reusable. Management of data sources, transport selection and data stream filtering is automatic. This results in an intelligent communication architecture that reconfigures based on mission scenarios.

This offers obvious benefit, but is it practical today? The DDS standard is proven in many mission-critical military applications and successful UAV vehicles and ground stations. As it evolves to encompass more platforms and to integrate more systems, it becomes viable to consider it for UAV ground-air integration.

Real-Time Innovations
Sunnyvale, CA.
(408) 990-7400.
[www.rti.com].