Unmanned aircraft systems (UASs) operating in the National Airspace System (NAS) continue to proliferate. In response, the Federal Aviation Administration (FAA) is issuing regulatory changes that will affect policy regarding safety certification of unmanned aircraft - military and commercial - that travel in the NAS. These policy changes are ongoing and software and hardware designers need to stay abreast of the changes.

According to Federal Aviation Administration (FAA) estimates, by 2020 registrations of model-based sUAVs (classified as small UAVs) will be more than 2 million, while nonmodel sUAVs will number almost 500,000. The current FAA regulations under FAR 107 for small UAVs (under 55 pounds) do not require any special preauthorization if operating in daytime and under 400 feet in uncontrolled airspace. Recent FAA data also show an increasing desire to operate outside the limits imposed by FAR Part 107. In 2017, the FAA approved more than 1,600 waivers that affected one or more Part 107 criteria (such as daytime or line-of-sight operations) and almost 13,000 waivers for operations in controlled airspace.

While the waiver process can be onerous, it’s becoming clear that continued use of waivers will dampen innovation and growth. The challenge that lies ahead: How can the regulatory requirements and desire for innovation coexist with safe UAS traffic growth?

[Editor’s note: The term UAV refers to the actual aircraft while the term UAS refers to the aircraft, its payload, its ground station – essentially anything tied to the platform.]

UAV regulatory changes

In 2012, the FAA was given a congressional mandate to streamline the aircraft certification process (https://www.faa.gov/news/updates/?newsId=73201). The FAA has already rewritten regulations under FAR Part 23 (for aircraft less than 12,000 pounds), which enabled aircraft and equipment makers to be more efficient. The agency also reached agreements with foreign regulators on improving the efficiency of reciprocal approvals. In addition, the FAA reorganized itself last year from geographical domains into functional domains. These changes have resulted in a more efficient approval process and allowed for more innovation while retaining or improving a focus on safety.

Now the FAA is taking the bolder step of streamlining the process of software and complex hardware certification (a current work in progress). This latest initiative involves getting away from the prescriptive guidance in RTCA/DO-178 and DO-254 and instead using more general guidance called Overarching Properties (OP). The Overarching Properties initiative, according to the FAA, seeks to provide flexibility and efficiency in the certification process across multiple levels of aircraft system design and disciplines. The FAA’s rationale is that certification policy has consistently lagged behind technology and innovation. By providing a more general framework for software and complex hardware approval, designers are free to choose how they will show compliance. Nowhere will this be more important than in the design and approval of unmanned aircraft systems.

The FAA held an Unmanned Aircraft Systems symposium in March 2018, which drew more than 900 attendees. “The message of this whole conference is: The FAA is open for business,” said Derek Kan, undersecretary for policy at the U.S. Department of Transportation. The symposium was composed of a cross-section of government, industry, and innovators discussing regulations and research with the goal of safely integrating UAS into the NAS. The FAA’s key objectives: To facilitate integration of UAS into the NAS (called UAS Traffic Management) and ensure safety, security, and privacy.

The symposium focus showed that the FAA is moving away from its prescriptive standards to a method of performance-based compliance for UASs; the new approach focuses on air vehicles, pilots, and airspace. The most pressing issue is airspace. Today, private and commercial air traffic is managed mostly by humans, with the help of computers and radar. Given the expected growth in the number of UAVs, however, it would be impractical to manage these aircraft with humans in the loop. Instead, UAS Traffic Management (UTM) will enable automated identification, routing approval, log books, conflict resolution, and more for all UAVs. The FAA emphasis appears to be on getting the airspace integration addressed first, with the goal of passing regulations within the next two years.

UAS design characteristics

Virtually every UAS developer today is enabled by agile development, low barriers to entry, new methods of design, and short time to market, but they have limited experience in designing safety-critical systems. In contrast, most conventional military and commercial equipment designers are driven by a methodical (e.g, DO-178-driven) development process, high barriers to entry, conventional tooling, long lead times, and a wealth of experience in complying with regulations. Attempting to “retrofit” the prescriptive methods of DO-178 or DO-254 on UASs would be impractical due to a number of economic and technical factors including time, cost, code size, use of model-based design, code generation, and use of open source software, among other factors.

UAS designers are more apt to test and verify their systems using simulation platforms as well as flight testing. Conventional requirements-based or unit-based tests may not be done, especially in the prototype phases. Today, most of these vehicles operate either outside the controlled NAS or with a waiver. However, once these vehicles wish to fly at night, over populated areas, or beyond visual line of sight, additional verification methods will be required. (Figure 1.) The FAA recognizes that creation of technology-independent assurance techniques may be the best way to enable certification of UAS equipment in the NAS. If one considers that autonomous vehicles (both air and land) will soon become learning systems, new techniques and methods not addressed in DO-178 or ISO 26262 will before long be required to verify such capabilities.

Figure 1: Unmanned aircraft systems that wish to fly at night, over populated areas, or beyond visual line of sight require additional testing and verification.

Other acceptable means of software compliance

The software running inside most of the UASs produced to date have no formal certification pedigree. In the parlance of DO-178, it’s all “Level E” software, meaning that any failure conditions will have no effect on safety. Of course, there are use cases of UASs, provided appropriate measures are taken, where software failures will have no effect on safety. However, if the use cases are expanded to include heavier vehicles, flights over populated areas, or beyond-line-of-sight operations, all of the software can no longer be considered Level E. A safety analysis may determine that some of the software running on the UAS compute platform may require certification to Design Assurance Level (DAL) B or A depending on the outcome of given failure conditions.

Since UAS designers may use agile methods of development, employ model-based design to generate control software, or use novel tools or technologies, application of DO-178 reverse-engineering methods may prove impractical. Moreover, UAS designers rely more on open source software (e.g., Linux) and have large code bases. In such cases, the FAA’s risk-based approach to certification compliance can help.

Overarching Properties initiative

The Overarching Properties initiative touted by the FAA is still under construction and formal policy for this approach may not occur until 2020 or later depending on the outcome of pilot projects and input from foreign regulators. The approach is that all safety-critical systems possess three inherent properties:

INTENT: The defined intended behavior is correct and complete with respect to the desired behavior
CORRECTNESS: The implementation is correct with respect to its defined intended behavior, under foreseeable operating conditions
ACCEPTABILITY: Any part of the implementation that is not required by the defined intended behavior has no unacceptable safety impact

In these three properties, one can see the FAA’s risk-based approach to certification as well as no mention of specifics of DO-178 or DO-254. Each property has defined evaluation criteria so auditors have a way to approve designs and these criteria are structured in a similar way for each property. Each has a planning activity, coverage criteria, resulting evidence, and overall process assurance. One can view the properties and evaluation criteria as an abstraction of DO-178 and DO-254 requirements without any prescriptive description of objectives, inputs, outputs, or resulting documentation. Each vendor decides how their processes, tools, and technology can satisfy the properties and evaluation criteria.

For the Intent property, the currently defined evaluation criteria are:

Planning activities

Define the Desired Intended Behavior (DIB)
Identify input space, observable behavior, failure conditions
- Coverage of the DIB under applicable input and failure conditions
- Evidence – Data required by planned activities
- Process assurance – Independent assessment, data under configuration management (CM) control, evidence of assessment retained
- Interaction with safety assessment process – Assign DALs, confirm DIB is consistent with safety assessment process assumptions, and address failure conditions

For the Correctness property, the currently defined evaluation criteria are:

Planning activities

Evaluate possible error sources, address error prevention/detection
Describe how each (development) tier is shown to be correct against a higher tier or the DIB
Describe how the implementation is shown to be correct against each higher tier or the DIB
- Coverage – Of the DIB and its implementation under applicable input and failure conditions
- Evidence – Data required by planned activities
- Process assurance – Independent assessment, data under CM control, evidence of assessment retained
- Interaction with safety assessment process – Assign DALs, confirm DIB is consistent with safety assessment process assumptions, and address failure conditions
- Verification environment
- Differences and justification for verification environments used other than the final environment
- Suitability for the aspect (i.e., timing, stack usage, etc.) being verified is justified
- Manufacturing, repair, operations, and continued airworthiness
- Ensure design data allows the implementation to be consistently replicated
- Ensure design data allows the production of appropriate Instructions for Continued Airworthiness (ICA)
- Identify support instructions or limitations affecting operations or installation

For the Acceptability property, the currently defined evaluation criteria are:

Planning activities

Define the means to identify additions in the implementation
How confidence is obtained for the additions in the implementation including interaction with the safety assessment process
- Coverage
1. Identification of all additions in the implementation (whether used or not used)
2. Impact of the additions in the implementation (No unacceptable impact on safety)
3. Mitigation means used to constrain the implementation and evidence they are effective
  - Evidence – Data required by planned activities
  - Process assurance – independent assessment, data under configuration management control, evidence of assessment retained
  - Interaction with safety assessment process
  1. Ensure that any functionality in the implementation not required to satisfy the DIB has no unacceptable safety impact
  2. Ensure that any remaining issues or defects have no unacceptable safety impact

A way forward

It’s clear that the approach with OP is to avoid the prescriptive verification objectives and techniques used in DO-178 or DO-254. There is no mention of topics such as tool qualification, “code coverage,” or guidance on the removal of dead or deactivated code. However, the concept of requirements and decomposition come through in the evaluation criteria, so verification will focus on the intended behavior and achieving the required level of safety. The intent isn’t to make it radically different from the conventional ways of verifying software, but rather to allow for more flexibility in how it’s verified.

DO-178 was updated in 2011, while DO-254 was published in 2000; given how rapidly software technology has evolved over the last decade, these standards will soon fall out of favor with developers, especially if they have to apply a new technique or technology. Admittedly, one can always use an alternative means of compliance with the FAA and other regulators, but having another acceptable means of compliance will make it more inviting.

With OPs, technologies such as learning systems would have a framework for approval, whereas DO-178 might not allow for that. Once the OPs are fully approved and published (and made into an acceptable means of compliance) UAS designers can combine this approach with conventional systems safety assessments (e.g., ARP 4761) or newer methodologies such as STPA (http://sunnyday.mit.edu/STPA-Primer-v0.pdf) to show compliance with federal regulations.

Joe Wlad has over 30 years’ experience in aircraft, systems, and software certification and is an experienced FAA Designated Engineering Representative. Since 1999, he has been involved in development, test, and certification of many commercial operating systems. He has coauthored patents on GPS integrity algorithms and led the certification of the first military GPS receiver to FAA standards. At Verocel, Joe is responsible for the strategic direction of both products and services across all markets served by the company. He holds a B.S. in Aerospace Engineering from the University of Buffalo and an MBA from Santa Clara University. Readers may reach the author at [email protected].

Verocel www.verocel.com