Implications for safety critical aerospace design

23 September 2009

The FPGA/ASIC requirements are captured from the overall system requirements

Gareth Williams offers an overview of aerospace requirements for safety critical design and how the move from analogue to digital has heightened the relevance of DO-254 certification for programmable logic.

Adherence to safety and the testing of components and systems is an important part of any electronics development and production process, yet safety critical design for military and civil aerospace applications is especially critical. It plays a pivotal role in ensuring aircraft stay in the air and avoiding failures which potentially put lives and missions at risk.

The aircraft certification process is, by design, a measured one that can take up to two years or more to complete. The military and civilian aerospace agencies have historically used different standards by which to ensure the safety of aircraft. A selection of such military standards include: ARP4754 (certification considerations for highly integrated or complex aircraft systems), MIL-HDBK-338B (Electronic Reliability Design Handbook), MIL-E-5400 (general specifications for aerospace electronic equipment), MIL-STD-882D (system safety program requirements) and Def Stan 00-56 (safety standards for defence) for the UK.

Civilian agencies have been operating a standard called DO-178B for software development since 1992 and DO-254 for hardware since 2000. In 2005, the FAA issued AC 20-152 stating that DO-254 must be used for programmable hardware. DO-254 is also known as EUROCAE ED-80 and was released by the Radio Technical Commission for Aeronautics. The NATO AQAP2110 and AQAP2210 standards are now becoming more widely used for military programmes, but many defence suppliers are looking to work to DO-254 and we will therefore concentrate on this standard for the rest of the article, as many engineers and managers are unsure how to get started on the DO-254 process.

The rise of DO-254
DO-254 provides guidance for design assurance of airborne electronic hardware, from conception through initial certification and subsequent post certification product improvements to ensure continued airworthiness. DO-254 defines objectives that must be met by avionics equipment manufacturers according to EASA and FAA guidelines.

Traditionally, instruments and control systems were analogue based. But as designs have moved into the digital domain, and especially more programmable with the use of FPGAs, there is now the elevated need to undertake designs using the DO-254 standard. As part of the aircraft certification process, a System Safety Assessment (SSA) is applied to the aircraft as a whole, and to all of its sub-systems. From this SSA, the Design Assurance Level (DAL) is derived.

DAL classification Failure Condition Description
A – Catastrophic Failure conditions that would prevent continued safe flight and landing, resulting in many fatalities.
B – Hazardous Failure conditions that would reduce the capability of the aircraft or the ability of the flight crew to cope with adverse operating conditions. There is likely to be a reduction in safety margins and possibly fatal injuries to a small number of occupants.
C – Major Failure conditions that would reduce the capability of the aircraft or the ability of the flight crew to cope with adverse operating conditions. There is likely to be a reduction in safety margins and discomfort to the occupants, possibly injuries.
D – Minor Failure conditions that would not significantly reduce aircraft safety and which would involve flight crew actions that are well within their capabilities. Minor failures may include a slight reduction in safety margins, a slight increase in workload, or some inconvenience to occupants.
E - No Effect Failure does not affect the operational capability of the aircraft or increase workload. Depending on the DAL level required by the system, the hardware has to be designed to meet these criteria. The higher order DAL levels require design methods such as redundancy and/or differing technologies in the solution to ensure there is no common cause of failure.

The hardware design life cycle is broken down by standard planning and support processes, requirements capture, conceptual design, detailed design, implementation and production transition. The support processes cover, amongst others, validation and verification (up to 50% of the overall project is typically taken up with this) and configuration management. The process is initiated by a planning phase. The guideline is to produce a Plan for Hardware Aspects for Compliance (PHAC). This document outlines the processes to be followed to ensure the given requirements are traced to functionality and validation results and the process for proving assurance. Amongst others such as the validation and verification plan, other planning documents are also required.

To achieve certification of the product, ‘artefacts’ must be produced to prove that the process covered in the PHAC has been carried out, through to the production transition, making sure that the design and manufacturing information gathered is sufficient for the product to be replicated. This information is contained in the Hardware Accomplishment Summary (HAS). Quoting from the standard: ‘The hardware traceablity establishes a correlation between the requirements, detailed design, implementation and verification data that facilitates configuration control, modification and verification of the hardware item.’ This can be carried out manually, but the requirements capture is often done with tools like IBM’s DOORS.

The process differs slightly in the USA compared with Europe, in that the FAA appoints Designated Engineering Representatives (DER) to work closely with the design teams and the DERs submit a recommendation for approval after compliance has been demonstrated by testing the hardware item in the end system. After approval that the hardware is DO-254 compliant, and the aircraft has achieved its type certificate and is fully certified, the DO-254 component is now DO-254 certified - but only in the context of this specific system and aircraft. This is why vendors of IP can only claim the products are ‘certifiable’ to DO-254 and not certified, as it is the designers responsibility to take that product through the certifying process.

FPGA/ASIC design flow
The hardware lifecycle diagram can also be expanded in detail to cover the FPGA/ASIC design flows. Again, the requirements that are to be carried out in the FPGA/ASIC need to be captured from the overall system requirements. From these requirements, two independent teams are used. One to generate the design and one to generate the test plan to verify the design. DO-254 stipulates that this must be carried out by independent teams. These requirements break down into an architectural design and then to a detailed system level design into RTL and, via synthesis tools, to produce the required netlist. As part of this design flow, the blocks at the subsystem level will be verified with their own testbenches to ensure correct functionality at the lower level.

Here the flows for the two technologies differ slightly. The FPGA flow goes through the vendor specific Place & Route (P&R) tool to produce the bitstream for device programming. At this point, full timing information can be fed back into post layout simulation. The device can then be programmed and tested in the lab.

For the ASIC flow, an additional step of generating the manufacturing test suite is performed, as this device will be unique. There are various methods of producing this, be it Scan Path or Automatic Test Patterns Generation. The P&R is then performed using the selected foundry’s libraries, which provides the post layout timing data to be used for the simulation, before the device is ‘taped out’ and the manufacturing process begins.

Implementing an optimised process that comprises methodologies and tools for successful FPGA development under DO-254 can reduce development costs and speed up the approval process. There are various tools available from vendors to assist in the process of designing for DO-254. Mentor Graphics provide a plethora of tools including HDL Designer for generating high level views of the design including aspects of code checking. ModelSim is their standard simulation tool that can be used on both FPGA and ASIC and Precision is their synthesis tool.

Because DO-254 is a high-level, process-oriented standard, responsibility for design assurance necessarily requires a team approach among designers and suppliers. As such, defence organisations should seek out team solutions and partnerships with suppliers in order to best meet the needs of their customers.

It can be seen from this very high level overview, that the needs of DO-254 put extra responsibility on the designing party to plan for the required assurance level, to prove this plan has been undertaken and that the test and analysis results are traced back to the initial requirements. This does make designing flight hardware take more time than for a non-critical project, but this is reassuringly so.

As one of the largest independent electronics design consultancies in Europe, Plextek has mature processes for outsourcing of engineering design to all levels of safety criticality and highly reliable applications. By following internationally recognised standards, such as DO-254 Plextek ensures that its deliverables are safe by design and is currently undertaking a flight hardware design project, on behalf of a customer, for an engine protection system. For safety critical software design, Plextek also partners with specialists Resource Engineering Projects, who undertake projects to DO-178B. Together Plextek and REP offer companies a complete safety critical systems design capability.

Gareth Williams is Director of the Digital Engineering Group at Plextek


Print this page | E-mail this page