Middleware Offers Integration Framework for Dynamic UAV Applications

Unmanned Aerial Vehicles (UAVs) like the MQ-1 Predator have excelled in the theaters of war in which they have been deployed. However, the ability of those controlling the UAV to conceive of new missions for the Predator and other deployed UAVs in the field has led to the U.S. Air Force recognition that the fundamental architectural approach to development of complete Unmanned Aircraft Systems (UASs), including ground stations and other elements, has to put integration capability front and center as a key design issue.

Meeting Next-Generation Requirements

Raytheon has massively simplified the complex mission environment from a system designer’s perspective and eliminated the “stovepipe system” problem that the DoD identified as a significant bottleneck for future UAS deployments.

UASs will find themselves deployed in multi-mission situations where they have to seamlessly integrate their capability with a networked environment potentially comprising other UASs, ground/ sea systems, manned aircraft, and ground troops.

Simply stated, the challenge is that UAS designers will not know at the outset what new re-configuration components will be requested of their UAS platform, nor what missions the UAS will be required to perform over the course of its lifetime. In defense deployments, adaptability is key, as those using the UAS assets seek to meet an ever-changing and unpredictable battle environment. Whereas manned systems had adaptability built-in with the man in the loop, UASs have to have this adaptability built-in by initial design.

These initial design requirements will mandate physical constraints such as size, weight, payload, etc. of the UAS. But once deployed, the end users will conceive of all sorts of new payload requirements that were not anticipated at design time, as was seen with the deployment of the MQ-1 Predator. While meeting this requirement is somewhat achievable with a well-designed UAV internal network, the real challenge is that the UAV (most commonly used as a sensor platform) will also need to share its information and capabilities not just with its Ground Control Station (GCS), but directly with systems that have as yet not been conceived or deployed.

Today, the assumption is that the information flows down from the UAV to its own GCS, but in the future, it will need to integrate into UAV swarms or with other battlefield assets, sharing its information and perhaps utilizing information from these other assets to better perform its own mission. Any end-point must be able to communicate to any other end-point and meet the real-time needs of that specific communication channel, even when it runs over a combination of internal busses and RF or other long-range communication mechanisms. An end-point is not just the UAV or the GCS. It could be a configurable payload component of another battlefield asset; for example, a UAV infrared module providing target information for a manned aircraft or ground-based missile system.

Resilience has to be integral to the communication architecture. It would be clearly beneficial if a common messaging middleware implemented an approach that not only can withstand the loss of any node at any time, but can automatically switch in alternative information sources to those nodes that need specific critical data to fulfill their function.

UAVs are getting far more computing power built into them, and thus are potentially becoming more autonomous. However, increased levels of autonomy can only be realized with a communication infrastructure that is de-coupled from the historic concept that all data has to go through the GCS before it can be shared with other battlefield assets such as manned aircraft and ground troops. Just as a voice radio facilitates two pilots to directly coordinate their plan of action, two UAVs need similar capability to meet next-generation deployment adaptability. Every system or system component will need the ability to automatically “discover” other systems and their components that need its information, or can provide information that it needs to fulfill its mission. These superior capabilities can only be implemented by the use of a true peer-to-peer data oriented network model.

Data-Oriented Architecture

Subsystems such as payloads and mission- specific application software within a reconfigurable UAS may change, but each subsystem always knows what data it is capable of providing and under what terms. It will also know what data it needs and how it needs that data to be delivered in order to be able to successfully perform its function. Hence, every UAV and ground station is a combination of data providers (publishers) and data consumers (subscribers). In this concept, commands are considered just another form of data. Every payload option of a reconfigurable UAV can add to a dynamic and pervasive data model of the mission by signaling its inclusion to the mission environment, not just to the UAS.

By focusing on commonality of data requirements and capabilities between subsystems, we can achieve greater interoperability. Rather than creating a UAS where the integration problem of introducing it into the multi-mission environment is forced upon the recipient of the UAS, this data-oriented approach allows for a UAS to be defined in terms of its data and capabilities, and thus its contribution to the shared operational picture. In effect, the data definition becomes the integration language by which UAS developer and multi-mission force integrator can communicate. This design approach results in a high level of de-coupling between subsystems in a mission environment, thus supporting seamless reconfiguration, upgrades, and replacement of system components, including payloads and mission-specific application software. Leading companies in this sector such as Raytheon have already adopted this approach to massively simplify the complex mission environment from a system designer’s perspective and eliminate the “stovepipe system” problem that the DoD identified as a significant bottleneck for future UAS deployments (see figure).

Middleware Capability Requirement

Defining the data and the capability of a system to produce it, or consume it, does not provide a platform for system implementation. It requires a software middleware platform that supports the data-centric design approach and facilitates the communication of data in a mission-critical, real-time environment to turn the data into a dependable information capability.

In order to support the dynamic establishment of communication channels across any part of the system of systems that is necessary for the development of a configurable multi-mission UAS, each publisher and subscriber must be able to define exactly how they can deliver or how they need to receive data. This means that a Quality of Service (QoS) capability or requirement must be associated with each publisher or subscriber and each data set to address all the use cases and communication challenges that a real-time, mission-critical environment might demand:

  1. Command and control data, generally requiring high availability and integrity in its communication.
  2. Sensor data streams, generally requiring high throughput capabilities, and possibly streaming.
  3. Status, intelligence, mission, and supervisory data with varying degrees of availability and integrity requirements.

There are different communication and interoperability requirements for each data type, including response time, priority, reliability, volume of data, and stealth mode (one-way communication). Add in that each physical communication channel has differing characteristics in terms of latency, bandwidth, lossy nature of the communication, availability, and asymmetric bandwidth, and it quickly becomes clear that even with this simple breakdown of the communication and interoperability requirements, the matrix of pain for system-to-system integration rapidly becomes unmanageable, especially if addressed by considering each pointto- point communication requirement in any but the most simple, static design. What is needed is a software middleware layer that uses minimal network bandwidth to dynamically discover the data that is needed by its subsystem, and further, validates that the data can be delivered in a manner that meets its localized application requirements.

Once identified, the middleware needs to route the messages automatically to the standard required by the effective contract of service that is created between the data provider (publisher) and the data consumer (subscriber), and further, it must continuously monitor that the real-time service requirements between the two are being met. A simple example is real-time distribution of enhanced video data. Within the GCS, the enhanced video data can be sent using a reliable communication protocol from the processing node to the tactical display over the high-speed network in the GCS. If the same video data needs to be distributed to ground troops to provide beyond-line-of-sight capabilities, a very different communication protocol, which utilizes multicast and is unidirectional, is needed.

The middleware’s role is to ensure that communication channels are set up in the battlespace that meet the subscribers’ requirements. In our example, the middleware will dynamically set up two different interfaces or communication channels at the publisher of the enhanced video data: one used onboard the GCS, and one distributing data to the ground troops. The identity of the publisher is of no consequence to the subscribers, so the communication channel de-couples the sender and receiver. This approach massively simplifies an otherwise very complex communication infrastructure.

Open Standard Integration

There is an open standards real-time middleware environment, supported by the OMG (Object Management Group), that has already field-proven all these capabilities in systems such as the Predator MQ-1 ground station and the Boeing/Insitu Scaneagle, as well as many UGVs and UUVs. It is called the Data Distribution Service for Real-time Systems (DDS).

DDS is a true peer-to-peer publish-subscribe- based messaging middleware designed to meet mission-critical, realtime system integration and messaging requirements.

It has been mandated by the U.S. Navy in programs such as NESI (Net-Centric Enterprise Solutions for Interoperability) and Navy Open Architecture, as well as the Future Combat System SOSCOE (System of Systems Common Operating Environment). It delivers full interoperability not only because the middleware Application Programming Interface (API) is standard, but also because the on-the-wire protocol to support the messaging is an open published standard.

Adaptability of the Data Model

While the model we have defined facilitates integration between systems based on known data sets in a multi-mission context, over time, the set of battlefield assets will grow, adding new sensor and weapon payloads and complete UASs into the mission environment. This will create new data to be shared with systems that were deployed before knowledge of these new datasets existed. Taking the simple example of a system update of a 2D radar creating positional information, if we now add 3D positional information, how can the third-dimensional data be added to the data model without breaking the legacy systems using the 2D data? To address this issue, the integration framework must support runtime data-type evolution. An efficient implementation of a DDS-based integration framework utilizing this data model may even recognize that a subscriber that cannot use the third-dimensional information, thus minimizing bandwidth. Recognizing this need, extensions to the DDS standard that directly support at-runtime evolution of component interfaces is currently being worked on by the OMG.

Data-Centric Middleware

Interoperability between multi-vendor- developed UASs will depend on proven battle-hardened and tested standards. The ability to integrate their capabilities into a mission environment is critical, but just as important is the ability for the design model to adapt rapidly to dynamically changing requirements, and this has to be facilitated as a fundamental part of the system architecture. With a data-centric model, this capability can be designed into the architecture of each UAS and every component of its payload capability. DDS provides the middleware standard that enables UASs to be designed for dynamic integration into the mission environment. The OMG ensures that the solution is inter-operable by ensuring compliance at both the application level and the on-the-wire communication. Furthermore, it allows UAS designers to meet the Air Force next-generation UAS concept requirements, which in turn aligns with DoD’s more general vision for battlefield system development.

This article was written by Edwin de Jong, Director of Product Management and Strategy, for Real-Time Innovations, Inc., Sunnyvale, CA. For more information, Click Here