Name That Plane

Preparation for UAS Entry into National Airspace

Manufacturing Group | October 8, 2012

September 2015 is the deadline for the FAA to fully integrate unmanned-aircraft systems (UASs) — including those intended for commercial use — into the National Airspace System (NAS).

Preparation for UAS Entry into National Airspace

This is the date by which the FAA must investigate the potential impacts of UASs in the NAS, and establish the associated guidance for their development, deployment and control. It is also the date by which existing and emerging UAS manufacturers must adopt the newly released guidance to establish the competitive advantage of being one of the first out of the gate.

Developing certifiable software and complex hardware for manned aircraft is a challenging and costly undertaking, since manufacturers must meet the rigors of released FAA guidance. Early indications suggest that the existing manned guidance will be extended to accommodate the unique considerations associated with UAS technology. Early accommodation of the emerging FAA UAS guidance can allow manufacturers to minimize cost and schedule necessary to develop within an FAA-regulated domain.

Early accommodation, however, is associated with daunting questions. What is the emerging guidance likely to entail? How much up-front accommodation can be confidently performed? What accommodations should be delayed until the guidance settles? In this paper, we provide recom-mendations on short- and medium-term low-cost, low-impact activities to better position UAS manufacturers for a timely adoption of the FAA UAS guidance.

INTRODUCTION
Flight operations in the NAS are regulated by the FAA. For manned flight, if the associated airborne or ground-based equipment includes software, the FAA has adopted RTCA DO 178C and DO-278A for the development and verification of acceptable (certifiable) airborne or ground-based products. For unmanned products, however, the playing field is not yet set. Although Congress has set the deadline for the FAA to fully integrate UASs into the NAS, the guidance by which the FAA will judge acceptability is still in process. However, indications are that the FAA will try to leverage as much as possible the existing guidance, modified as necessary to accommodate the differences between manned and unmanned flight.

DON’T EAT THE ELEPHANT WHOLE, BUT DO START EATING
There is no doubt that adopting formal aviation guidance for the development of airborne and ground-based software systems for unmanned-aircraft systems represents a considerable challenge to the emerging UAS industry. The questions for the potential UAS developer are how and — considering the unsettled nature of the FAA guidance — when to begin the transition to the guidance. An understanding of the existing manned-aircraft guidance and its anticipated ramifications on the UAS manufacturer are critical in understanding those activities that can be done immediately and at relatively low cost; versus those activities that are best postponed until the guidance has settled. Therefore, an informed gap analysis must be a priority and should be done, sooner rather than later, to form a solid basis on which to plan your transition to formal FAA-regulated software development.

Below, major elements of the existing guidance are examined, with a focus on areas that are best to consider up front, i.e., long-lead-time activities, as well as those activities that will result in costly downstream rework. Of course, the amount of activity will depend on whether a manufacturer has an existing product that must be migrated to the emerging guidance or is starting from a clean sheet.

THE SOFTWARE LIFECYCLE
A certifiable-software lifecycle is best viewed as a waterfall or series of waterfalls. In other words, requirements precede design, and design precedes code. These waterfalls can be arranged to support any manner of incremental software lifecycles, but the sequencing of events is critical to establish configured software artifacts with change control. The sequenced activities — requirements analysis, design and implementation — should have formal entrance criteria, which dictate when the next phase can be entered. All of this should be described in a set of plans, which lay out, in detail, the desired approach.

Although, ultimately UAS manufacturers must generate a full set of certifiable software plans to fully describe the software development methodology, this may not be the most efficient approach in simply positioning the organization for later adoption of FAA certifiable-software development guidance. Instead, understanding the basic control expected for developed software can establish a viable base from which later development can be leveraged.

Manufacturers with existing or in-development projects from which they intend to directly leverage development artifacts eventually will have to apply a waterfall on an ordered, controlled set of data. 
 
In other words, baselines must be established, reviewed and authorized in sequence for the following: system requirements, software requirements (high-level software requirements), software design (low-level requirements and software architecture), and finally source code.

Therefore, whether starting from existing artifacts or from a clean sheet, a manufacturer should set up baselines: configurations against which formal problem reporting is performed, to formally tie the documentation sequence together. In other words, the manufacturer should establish a process by which a change in a higher-level document can be formally tracked through the dependent downstream documentation.

Establishing the fundamental configuration control of the various artifacts in development can position the data for future certifiability, since it establishes a solid base against which controlled, traced requirements are flowed through the process into the implementing source code, and against which formal verification can be performed. Because most organizations working with software already have a source code repository, the impact of this element concerns establishing the process basics and enforcing the discipline to maintain control.

TRACEABILITY
In certifiable software, traceability is king. In development, bi-directional traceability must be established between the system and high-level software requirements, between the high-level software requirements and the low-level software requirements, and between the low-level software requirements and the code. This traceability helps ensure that the software implementation (the source code) completely fulfills the software responsibilities of the overall system. In addition, traceability between the requirements and verification test cases, and verification test cases and procedures must be established to ensure that the requirements are fully verified.

Typically, a commercial requirements management tool is used in certifiable-software development to establish traceability. Examples include IBM Rational RequisitePro or a more integrated Application Lifecycle Management (ALM) toolset, such as MKS Integrity . Adopting a requirements management tool and establishing traceability can be costly and require a great deal of time and effort, especially for those considering integrated ALMs toolset. Unfortunately, traceability performed after the fact is much more costly and error prone to boot. Therefore, to save time and cost, we highly recommend formally establishing and maintaining traceability as early as possible.

STANDARDS
FAA guidance in DO-178C/DO-278 for certifiable-software development details the need for standards to which requirements, design, and code must be developed; and against which they must be reviewed. The guidance for the contents of the standards describes basic software-industry best practices. They are not extensive. Early adoption of standards—for any software development, certifiable or not—is a good idea and, if applied rigorously, can reduce upstream volatility and downstream costs.

Therefore, we recommend establishing a minimal set of standards to apply to new or ongoing development. As a best practice, however, the standards must be kept minimal, since long, extensive standards can be unwieldy, are often ignored, and can lead to unnecessary costs. As such, we do not recommend adopting elaborate published standards, such as MISRA C as instituting the formal c-code development standard .

TECHNOLOGY
The technologies applied to certifiable-software development efforts for manned aircraft and the associated Communication, Navigation, Surveillance and Air Traffic Management (CNS/ATM) Systems are constrained by the associated guidance (DO 178C and DO 278A). With respect to UAS development, the airborne aircraft software development is expected to align more closely with
DO-178C, whereas ground-based stations will likely align more closely to DO-278A. To align with this guidance, two aspects of software technology must receive careful, early consideration:

1.    Object-Oriented Technology (OOT)
2.    Commercial Off-the Shelf (COTS) Software

OBJECT-ORIENTED TECHNOLOGY
A fundamental tenet of certifiable-software development concerns the critical importance of deterministic behavior of the software. The technologies employed in certifiable-software development must support verifiable deterministic behavior. Therefore, if an UAS manufacturer intends to use OOT, specific considerations related to OOT for use in certifiable-software development must be accommodated.

Currently, OOT reigns supreme in nearly all industry domains, except, however, in certifiable airborne applications. Surprisingly, OOT is only now taking a firm foothold in aviation, since certifiable software must be deterministic and OOT includes elements that can be problematic. Complexities such as hierarchical encapsulation, polymorphism, dynamic memory management, and virtualization must be addressed with respect to their uncontained effects on deterministic behavior. Often this results in limiting the OOT use to a subset of the associated language (e.g., C++), but other methods are available to contain its effects.

To provide guidance, the FAA has adopted the DO 178B supplement RTCA DO 332, Object-Oriented Technology and Related Techniques Supplement to DO-178C and DO-278A. Therefore, if OOT technologies are planned, studying the associated DO 332 guidance and establishing and migrating early to an accommodation strategy will be critical in avoiding downstream rework or, worse, starting from scratch from the design down.

COMMERCIAL OFF-THE-SHELF SOFTWARE
The second critical aspect of software technology concerns commercial off-the-shelf (COTS) software. For airborne software related to higher assurance levels, source code is necessary. This can have critical impacts on existing software development that often relies heavily on libraries for which no source is available. Unless the associated functionality can be partitioned to the lowest assurance levels, some painful rework is in store. Understanding this constraint and accommodating it early, can save considerable time and cost.

A number of certifiable COTS real-time operating systems (RTOSs) are on the market, (e.g., LynxOS-178 RTOS). These operating systems have been developed to the DO-178B guidelines and certification packages are available. These operating systems can be quite expensive, and the certification packages, sold separately, more so. As a result, manufacturers of simple systems opt for simple homegrown task managers. In either event, we recommend addressing the intended operating system early. It is difficult, however, to recommend full migration to a commercial RTOS, especially for smaller UASs, until the FAA guidance settles more. Instead, adopting a layered architecture that can more easily accommodate a future migration may be the most effective, lowest-risk path forward.

The guidance for CNS/ATM systems, DO-278A, provides for a more flexible approach with respect to COTS software. For the ground-based component of a UAS, the guidance calls for a COTS Software Integrity Assurance Case, a formal justification for the inclusion of COTS software based on planned accommodation techniques, such as integrity monitoring and COTS software safe subsets through data integrity checking. In other words, the applicant must make the case that the COTS software, e.g., the workstation operating system, is appropriately limited in its ability to effect the safety of the UAS.

Therefore, an early understanding the UAS existing or planned reliance on COTS, along with the generation of a strategy by which the COTS is eliminated or accommodated into the certifiable development strategy must be a high priority. This strategy will likely include immediate actions and course corrections to avoid excessive downstream costs.

Verification & Verification of Verification
Verification in the certifiable-software development domain includes reviews, analyses, and tests. Depending on the assurance level assigned to the UAS software systems, independence can be required for these activities. Therefore, our first recommendation associated with verification is to perform verification activities with independence (simply put, an individual cannot verify their own work). Not only does this prepare the UAS manufacturer for the worse case in rigor, it provides for more effective identification of errors, lower downstream rework, and reduced overall costs.

In certifiable-software development, it is not sufficient to simply verify the software; the test and analysis activities themselves must be verified, i.e., verification of verification. This is done through two specific verification activities: requirements coverage analysis and structural coverage analysis. The requirements coverage analysis ensures that the body of tests and analyses robustly exercises the software requirements with requirements-based tests. This is generally evidenced by a review of the requirements to test-case traceability. Therefore, as testing is developed, the requirements manage-ment tool should be used to establish the associated traceability. The review of this traceability, however, can be postponed until the regulatory dust settles.

In contrast, the structural coverage analysis verifies that the body of tests and analyses cover the software code, with the rigor applied depending on the software assurance level. This analysis is typically performed with commercially available tool sets, such as the VectorCAST tool suite. As with the requirements management tools, structural-coverage tools can be pricey. Likewise, as with certifiable RTOSs, an expensive qualification package will be necessary.

Therefore, until the FAA guidance is better established, adopting a structural-coverage-analysis tool is not advisable. We do, however, recommend that manufactures begin researching structural-coverage-analysis tools for their processor and compiler, as well as planning, in detail, the associated verification environments. Note that this is not a simple task limited to tool selection. Establishing the hardware and software hooks to ensure testability to the extent required by certifiable-software development can be quite challenging, should not be underestimated, and should begin as soon as possible.

SUMMARY AND CONCLUSION
Developing and modifying certifiable software for unmanned aircraft will be a challenging and costly undertaking, as manufacturers will have to meet the rigors of not-yet-released FAA guidance. Since the existing manned guidance will likely be extended for the unique UAS technology considerations, key areas on which UAS manufacturers should focus can be identified to allow early accommodation of the emerging guidance. Although manufacturers should be careful not to eat the certifiability elephant whole, they must not delay in proactively positioning their development processes. These activities can, with relatively low risk, effectively and efficiently prepare UAS manufacturers for their eventual adoption of the released FAA guidance, shortening time to market and lowering overall costs.

ABOUT FOLIAGE
Foliage Inc., a product development company, partners with companies to address the business and technical challenges inherent in developing complex software-intensive systems. Providing a full complement of engineering and consulting services aligned to business needs and applied over the entire product lifecycle, Foliage enables companies to accelerate development and drive more predictability and productivity into their businesses.

Foliage leverages over 20 years of experience partnering with leading companies in the Medical and Life Sciences, Aerospace and Defense, and Industrial Equipment industries. Working with Foliage, our customers gain the critical insights necessary to develop products with a difference, and to deliver the products their customers want, when they want them.

Foliage is based in Burlington, MA with additional offices in California, the Netherlands, and India.

For more information, visit foliage.com
168 Middlesex Turnpike, Burlington, MA 01803   781.993.5500
 

You May Also Like

comments powered by Disqus