Architecting unmanned systems: How suppliers can adapt to disruptive requirements changes

Story

April 15, 2015

David Barnett

Real Time Innovations (RTI)

Unmanned aircraft systems (UASs) are relatively new additions to the arsenal of weapons available to the military, and the technology is evolving rapidly. Beyond the normal course of advancing technology, additional factors are driving change in UAS development such as budget realities that necessitate the adoption of open architectures and increased UAS operation in civilian airspace that requires support of commercial safety standards. Also, software developers who wish to supply the military (or commercial clients) with UAS technology must quickly respond by adopting a new approach to the way they develop systems for unmanned aircraft. Not heeding these disruptive forces may leave suppliers out in the cold.

Technology embedded in unmanned aircraft systems includes many components such as processors, operating systems, communications infrastructure, and application software. These components are designed to enable unmanned air vehicles (UAVs), the airborne component of a UAS, to efficiently carry out a specific mission. Traditionally, each UAV design also requires a special-purpose ground control station (GCS). Components are typically redesigned for each new vehicle, and building UAVs that are readily adaptable to different mission objectives and parameters has proven to be difficult.

Winds of change

This will not be the case in next-generation UAS, which will include many-to-many relationships between GCSs and UAVs capable of supporting multiple mission objectives. The systems needed to deliver this multimission capability will include self-coordinating UAVs controlled by multiple GCSs, with UAVs and manned aircraft as well as space systems, all cooperating to meet a continuously changing set of mission criteria.

Visionary research papers from the Department of Defense (DoD) in the U.S., the Ministry of Defence (MOD) in the U.K., and government-industry consortia such as Future Airborne Capability Environment (FACE), UAS Control Segment (UCS), and Open Mission Systems (OMS) endeavor to define these requirements for UAS developers, including designing for a net-centric environment. Designers of UAVs and GCSs will have to ensure that every element of their capability is accessible to every other relevant participant in the net-centric environment.

Recognizing this new reality, the DoD laid out its plan for the evolution of the underlying technology needed for next-generation UAS in its “Unmanned Systems Roadmap 2007-2032.” The DoD vision has also been echoed in NATO forums and country-specific UAS initiatives. The Unmanned Systems Roadmap defined six goals, two of which are particularly relevant here:

Emphasize commonality to achieve greater interoperability among system controls, communications, data products, and data links on unmanned systems.
Foster the development of policies, standards, and procedures that enable safe and timely operations and the effective integration of manned and unmanned vehicles.

These are the disruptive forces transforming UAS development. Software developers and system designers will very soon, if not immediately, need to first support open architecture requirements, and also meet heightened safety-certification requirements for unmanned aircraft in commercial airspace.

Procurement strategy and the push to an open architecture model

By mandating, managing, and verifying interoperability and safety certification, the DoD is more closely aligning the defense market with the operation of open commercial markets. The most important commercial market benefit sought is market competition for subsystem supply. Defense procurement seeks to foster investment ahead of specified requirements, building agility into the procurement process to enable shorter update cycles and stay at the front of the technology race. Moreover, because military budgets have tightened, the DoD wants to drive down cost by encouraging design innovation and competition.

This approach represents a fundamental shift in procurement strategy. Existing DoD systems have typically been developed for a unique set of requirements by a single lead integrator with long lead times, resulting in platform-unique design limitations as well as barriers to competition within and across platforms. An interoperable open-architecture approach will mandate system integration and eliminate the traditional model of siloed development.

To be meaningfully interoperable within an open architecture, different systems built at different times, with different hardware, different software architectures, different technologies, and different uses of data must be readily and meaningfully integratable. The DoD has determined that the key to achieving this goal is to specify a common semantic data model. All data to be exchanged is rigorously defined, described, and documented.

The safety-certification imperative

In addition to meeting open architecture requirements, the DoD says, UAS developers must “enable safe and timely operations and the effective integration of manned and unmanned vehicles.” This requirement has broad implications beyond the military UAS.

The Federal Aviation Administration (FAA) is moving toward integration of UAVs, colloquially referred to as “drones,” into U.S. commercial airspace. International counterparts are considering similar steps. This integration of drones into national airspace presents new opportunities for UAS developers. A company that develops UAS for the military will certainly want to leverage its research and development investment to create similar products for the commercial market. To accomplish this, a company must address requirements for both military and commercial clients.

Safety has been a primary concern for the FAA, which follows the RTCA/DO-178C standard for software safety certification. These guidelines affect UAS developers by adding complexities and costs directly related to safety certification. DO-178C objectives dictate that code be developed with extraordinary attention paid to testability (Table 1). Code must be deterministic to enable repeatable test results.

Additionally, certification is expensive. For DO-178C, costs can range to as much as $100 per executable line of code (ELOC), depending on the certification level. These are only the costs for creating the certification evidence and do not include the costs for designing and writing the code. Since safety certification is costly and developing safety-certifiable software comes with its own unique challenges, mission-critical components must be developed with minimum line count, testability, and determinism as top-line requirements.

Table 1: DO-178C safety levels and certification requirements.

(Click graphic to zoom by 1.9x)

Leveraging DDS to achieve interoperability and safety certification

Fortunately, there is a proven approach to systems design that enables developers to achieve the requirements of open architecture and safety certifications for military and commercial UAS, while reducing development time, cost, and risk. That approach involves building components on DDS-compliant middleware.

DDS, or Data Distribution Service for Real-Time Systems, is a set of specifications standardized by the Object Management Group (OMG). At its core, DDS implements a real-time software data bus (Figure 1) based on a connectionless architecture. This architecture overcomes problems associated with point-to-point system integration, such as the inability to scale, interoperate, or evolve the architecture.

Figure 1: Data Distribution Service for Real-Time Systems (DDS) enables data producers to publish data to the infrastructure and allows data consumers to subscribe to data from the infrastructure.

(Click graphic to zoom by 1.9x)

DDS uses the publish-subscribe communications model to enable data producers to publish data to the infrastructure and allow data consumers to subscribe to data from this data infrastructure. In a DDS implementation, the data is abstracted away from the physical source and destination 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 is used in thousands of mission-critical applications and systems across many industries including aerospace, defense, healthcare, energy, automotive, and air traffic control. Since these systems tend to process high-volume and highly frequent updates, such as sensor information, accurate transmissions are critical. The implications of system failure are often severe, potentially leading to loss of property or even loss of life. The proven success of DDS makes it an excellent starting point for safety-critical applications such as UAS.

Use of DDS in UAS is standardized by open architecture guidance including FACE, UCS, and OMS. DDS implementations, including RTI Connext DDS Cert, are certifiable up to DO-178C Level A and include the process and testing artifacts required by the certification authority. This approach can save millions of dollars of certification cost by greatly reducing the amount of custom code that must be evaluated.

David Barnett is Vice President of Products and Markets at RTI, where he is responsible for product management and market development. He has 25 years of experience in distributed, real-time, and embedded systems. Barnett began his career at the Lawrence Livermore National Laboratory, designing distributed real-time applications. He has a BA in Computer Science from UC Berkeley. Readers can reach him via email: [email protected] or on Twitter @rtidavid.

RTI www.rti.com (408) 990-7400