Intelligent Areospace: In safe hands: requirement-based testing for design assurance of complex, safety-critical components with high impacts of failure

Date: 2017/05/30Type: In the News

by Louie de Luna, DO-254 Program Manager, Aldec

Developed in the 1990s by the RTCA SC-180 committee, DO-254, Design Assurance Guidance for Airborne Electronic Hardware was published in the year 2000. In 2005, the Federal Aviation Administration (FAA) Advisory Circular (AC 20-152) recognized DO-254 as a means of compliance to the federal aviation regulations when complex custom micro-coded components are used in airborne systems.

The document’s style is very much objectives-based, in that it spends a great deal of time explaining what should be done. For example, any errors introduced into the design must be caught to ensure the end product will function as intended, rather than explaining how to meet the objectives. This style, and the fact that there are few, if any, examples within the document, have given DO-254 a great lease of life; important when one considers that work on the standard commenced well over 17 years ago. Look at what has happened in the electronics industry during that timeframe.

Today, the FAA recognizes the role electronic design automation (EDA) tools, used throughout the development life cycle of complex custom micro-coded components – such as ASICs, PLDs, and FPGAs – can play in demonstrating DO-254 compliance. In this respect, the EDA tools would be used for simulation, synthesis, place and route, and static timing analysis, for example. However, the FAA also recognizes that other forms of EDA tools – most notably those that push harder into the verification space and/or provide traceability – can provide further design assurance for components with high impacts of failure. Specifically, the FAA has defined five hardware Design Assurance Levels (DALs). Designers working on systems categorized as DAL A (catastrophic consequence of failure) and DAL B (hazardous/severe consequence) must be able to produce a great deal of documented and traceable verification data, compared to designers working on systems with less or no consequence of failure...