Building flexible architectures for configurable UAV systems - Embedded.com

Building flexible architectures for configurable UAV systems

Unmanned autonomous vehicles (UAVs) serve a critical need in a varietyof missions, including reconnaissance and search-and-destroy, as wellas outside the military in agriculture and forestry.

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

By focusing first and foremost on data interfaces within and betweensoftware components along with the integration of those interfaces, UAVsystem designers can unlock software architectures from a specifictechnology. The primary objective is to design systems with anunprecedented level of flexibility while improving overall systemreliability and sustainability.

Designing and building a UAV is one of the most difficult problemsin engineering, and it is particularly challenging from a softwaresystems perspective. As mission parameters change, often it is notpossible to adapt software to perform well in changed operatingenvironments.

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

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

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

This complexity, combined with the need for constant real-time dataexchange 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 missionpayload with the necessary means of functioning and to collect anddistribute the data from the payload to the end users on the ground.Likely an unmanned system will have complex problems to solvethroughout its lifecycle.

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

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

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

Each of the three subsystems is technically complex, and combiningthem into a complete system increases the complexity exponentially. Thereal-time data streams cause rapid and unique interaction eventsbetween those systems that must be analyzed and responded to in atimely manner, even though the systems are almost always separated bydistance and intermittent connectivity.

The mission-critical nature of UAV systems adds requirements thatfurther complicate the design. Real-time data availability, processingand response are additional requirements, as are high-availability andreliability—all of which typically require complex redundancymanagement and careful tuning of all code components.

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

Because of the small size and limited power supply of a UAV, it iscurrently not easy to swap mission parameters and payloads withoutdifficulty. Too many characteristics tend to be hardwired into thedesign and implementation to easily configure for multiple missiondemands.

A Focus on Data Interfaces
The transmission of data between nodes and between subsystems in theUAV is possibly the most demanding engineering problem to address. Forexample, the navigation subsystem requires data, such as airspeed anddirectional gyro, from various instruments as well as the controlsurfaces.

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

Likewise, each of the major subsystems also requires multipleconnections. For example, the navigation subsystem on board the vehiclemust be able to provide data directly to ground-station instruments sothe pilots remotely controlling the device have real-time feedback onaircraft position. In addition, a pilot's movement of controls in theground station must result in immediate responses by airborne controlsurfaces.

The most common approach is to implement connectivity betweenprocessing components as a series of point-to-point, dedicatedconnections between those subsystems requiring predictable real-timecommunication.

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

However, the use of dedicated, point-to-point connections has twoserious failings. First, though the connections look simple, when thereare N different subsystems, establishing direct data connectionsbetween each of them results in N times N connections.

Though it is likely that direct connections between all subsystemsare not required, such connections would still increase the complexityof highly interconnected systems to the point where cost andmaintainability would be problematic.

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

Consider the later introduction of a logging subsystem that capturesall real-time data traffic for off-line mission replay or analysis. Thenew logging subsystem would have to be connected to all or mostexisting subsystems.

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

If the connection between the remote pilot on the ground and thecontrol surfaces in the air fails, there could be a complete systemfailure -and subsequent UAV crash. Therefore, it is necessary to buildredundancy into the architecture, which requires multiple directcommunications pathways or routing from other subsystems.

Figure1: Point-to-point architecture is suitable for simple componentconnections, but it becomes overly complex and brittle when supportingmany components.
Figure2: In complex systems, it is most efficient to provide for a

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

It is certainly possible to design and build a UAV with multipledirect connections between processing and control subsystems and toimplement failover and other Quality-of-Service (QoS) features that aredistinct and customized to that vehicle.

However, the cost of doing so can be significant, and a customdesign using these characteristics will almost certainly negativelyimpact maintainability throughout the life of the vehicle.

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

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

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

DDS enables a resiliency of data necessary for fault toleranceacross the network. There are commercial implementations of the OMG DDSstandard that adhere to published specifications while also offeringhigh performance for specific distributed systems and applications.

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

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

This combination makes possible a robust data communicationsinfrastructure for a UAV. Consider a data-driven design based onabstracting data away from the code acting on it and placing the datain known locations on the network. Such an infrastructure has theadvantages of direct connections between subsystems—without thecorresponding disadvantages.

It is possible to think of the DDS infrastructure as a logicallyshared data bus where data producers and consumers post and requestdata. From the point of view of the system designer, the data busimplements the details of getting data from one component to another inreal time and with an acceptable QoS.

The design problem is abstracted to determining data needs forcomponents and determining the appropriate QoS. The DDS infrastructureacts as the data bus that transports the data from source to consumer.

Figure3: The DDS infrastructure manages the transport of data from onecomponent to the other.

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

Rather than passing data directly between hardwired subsystems, theDDS infrastructure enables subsystems and individual code components topublish – or post – data to a logical location on the network. Othersubsystems subscribe to that data.

In effect, the data distribution middleware makes the decisionsabout the mechanics of getting data from one location to the other. Theactual transmission of the data is managed by the middleware. Theapplication code only has to ensure that the data is published or thatthe data is subscribed to, rather than having to implement themechanism.

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

This alternative makes for large amounts of detailed code that mustalso be tuned for performance, an approach that is both time consumingand prone to error.

In contrast, configurable QoS is a primary advantage of the DDSstandard. In particular, QoS parameters – such as delivery modes,acknowledgement response time, durability and lease duration – arenecessary to make it possible to tune the software's performance andreliability to the underlying network technology.

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

Redundant data pathways are still required physically, but they neednot correspond to logical point-to-point connections betweensubsystems. In fact, it is highly unlikely that any such directconnections would be needed.

Rather, the network architecture can be designed to optimize QoScharacteristics such as latency, failover and data priority. Thephysical architecture of the network can be based on thesecharacteristics, leaving it to the middleware to publish data,subscribe to data and manage the overall flow of that data.

Real-Time System ArchitectureMaintenance
No single UAV design can successfully meet all of the possible missionrequirements for such vehicles. However, by applying a data-orientedarchitecture, a more flexible design results that can meet the needs ofa variety of missions because it has optimized the tradeoffs inherentin design.

A data-oriented architecture reduces complexity by abstractingimplementation details away from the code, letting developers writeless code to achieve a more robust solution.

The OMG DDS standard and its commercial implementations make itpossible to develop data-driven systems and software while alsopracticing abstraction. The result is less application code, improvedsystem responsiveness and the ability to meet more mission parametersin actual use.

Dr. Edwin de Jong is Director ofProduct Management and Strategy, Core Products at Real-TimeInnovations, Inc. He has more than 15 years experience in thearchitecture and design of large-scale distributed real-time systems inapplications such as C4I, radar, track management, multi-sensor datafusion, threat evaluation, weapon and sensor assignment, and simulationand training. Edwin holds a Ph.D. in mathematics and physics fromLeiden University, The Netherlands. Editor's Note: To learn more abouthigh-performance messaging middleware download the RTI Shapes Demo.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.