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.