www.mentor.com TECHNICAL PUBLICATION Demystifying DO-254 Tom Dewey, Technical Marketing Engineer Design Creation and Synthesis Division Mentor Graphics Corporation March 2008
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
www.mentor.com
TECHNICAL PUBLICATION
Demystifying DO-254
Tom Dewey, Technical Marketing EngineerDesign Creation and Synthesis Division
Mentor Graphics CorporationMarch 2008
INTRODUCTIONInterest in DO-254 first occurred in Europe and hassince spread to the US commercial aircraft industry. Ifyou are being asked about your company’s DO-254direction and compliance, but have been overwhelmedwith information on the subject, then this article is foryou. This article presents DO-254 for the novice,boiling down the standard, reducing it to its essentialpoints so that you will be ready to respond withconfidence, as well as understand its potential impacton your products or services.
WHAT IS DO-254?DO-254 provides guidance for design assurance inairborne electronic hardware to ensure safefunction. It provides a framework ofconsiderations for certification across theentire engineering lifecycle — but does notspecify how to implement the standard.Thus, a cottage industry has formed toprovide training and consulting,complicating the novice’s task of gettingsmart quickly.
A few years back, the FAA issued AC 20-152 that stated DO-254 must be used forprogrammable hardware (they includedFPGAs as well as ASICs as programmable.At that point, the US commercial aircraftindustry took serious notice. Europe hasbeen involved in DO-254 even longer andtheir regulatory agencies apply a morerigorous treatment of the standard.
When you first take a look at the standarddocument you may be shocked to find howthin it is. After all, this standard is supposed to ensurethat no aircraft drops out of the sky due to electronichardware failure. Rather than provide detail, thestandard covers a lot of ground but at high, conceptuallevels. For example, the standard states “establish and
document your hardware design process.” Many bookshave been written on this topic alone and companieshave spent years defining and perfecting this process.
DO-254 does not sit in isolation; it complements awhole host of other standards and processes, such assafety and environmental impact assessments thatprovide complete guidance. But the focus of DO-254is solely on electronic hardware. As far as the standardis concerned, there only exists hardware and software(to which DO-178 applies). There is no middle ground(for example firmware). If the hardware is going intoanything that flies commercially, DO-254 likelyapplies.
Figure 1 shows the high-level process for selecting adesign assurance strategy.
Figure 1: Selecting Hardware Design Assurance Strategy
PAGE 2 www.mentor.com March 2007
Introduction Demystifying DO-254
The criticality or failure condition is determined usinga system safety assessment process described by thestandard. This process assigns a Level A to E todescribe the severity of a failure:
A. Catastrophic: failure prevents the safe flight andlanding of the aircraft, resulting in many fatalitiesincluding the crew. A Level A failure might occur 1in 1 billion flights.
B. Hazardous: failure significantly reduces flightsafety margins and the capability of the aircraft tofly, possibly resulting in fatal injuries but not to thecrew. A Level B failure might occur 1 in 10 millionflights.
C. Major: failure reduces flight safety margins andthe capability of the aircraft to the point wherepotential injuries could occur. A Level C failureshould might 1 in 100,000 flights.
D. Minor: failure does not significantly reduce aircraftsafety, resulting in potential discomfort topassengers or crew. A level D failure might occur 1in 100,000 flights.
E. No Effect: failure does not affect the operation ofthe aircraft.
While a major failure rate of 1 in 100,000 flightsmight sound scary, assuming an aircraft makes 4flights a day, 365 days a year, it would translate toonly one failure in over 68 years of flight.
It is important to assign the correct level to a potentialfailure, as it is very expensive to design and certifyhardware at a higher level. However, properclassification of a potential error is not alwaysobvious. For example, flight entertainment systemsmay not be viewed as flight critical or even as apotential source for fatalities, but in reality, a failure in
such a system has brought down an aircraft. TheSwissair 111 crash on September 2, 1998 was traced tothe in-flight entertainment system that caused arcingacross wires, setting fire to the cockpit ceiling (whichwas lined with flammable material). It is unlikely thatthe entertainment system would have been classifiedas a Level-A system.
The standard also differentiates the rigor of theprocesses based on whether the hardware is simple orcomplex:
• Simple: a set of comprehensive tests can be createdto exhaustively determine correct functionalityunder all operating conditions.
• Complex: if the hardware is not simple, it iscomplex.
Thus, the majority of FPGA and ASIC systems aretypically complex. A complex, Level-A system meansthat you must follow the maximum guidance fromDO-254.
The certification process for the standard adds costs tothe development process. If the process is efficientlyfollowed, the added cost should be 25% to 50% higherthan for the development of a non-compliant system.However, industry averages approach 100% inadditional cost — DO-254 compliance is a significantinvestment.
Developing the assurance strategy for Levels A or Bmeans applying one or more of the methods describedby the standard, including their associated analysistechniques. This task (along with the documentationthat goes with it) comprises the bulk of the standard.
For all levels, a design assurance approach documentis required for certification. This document is calledthe Plan for Hardware Aspects of Certification
March 2007 www.mentor.com PAGE 3
What is DO-254? Demystifying DO-254
(PHAC) and fundamentally documents the assurancestrategy. In addition, for Levels A to C, the fail-safeaspects of the system must be documented.
THE HARDWARE LIFECYCLEDO-254 fits the assurance process into a hardwarelifecycle (Figure 2). While the specification covers thislifecycle in broad-stroke concepts, it does not mandatethe actual process.
There are several key points about the hardwarelifecycle:
• The planning process is completed before anydevelopment on the design is performed.
• There are five key planning documents required forcertification that can all be included in the PHAC:design, validation, verification, configurationmanagement, and process assurance plans.
• Support processes are in place to monitorcorrectness for the project, including the PHAC.
• Transition criteria must be in place in order tomove from one key process to another.
• The lifecycle process can be iterative based onmodification and feedback between each of thethree major processes.
THE PLANNING PROCESSThe planning process is captured in one or more
documents that are reviewed for certification. Thisprocess defines how the hardware requirements traceto functionality and the process for proving assurance.The objectives of the planning process are:
• Define the lifecycle process used for hardwaredesign.
• Select and document any standards used in theproject and any expected deviations.
• Define and document the hardwaredevelopment and verification environment,including the tools used.• Define and document the hardware designassurance strategy.
DO-254 provides high-level guidance for theactivities that should used to meet the objectivesof the planning process. This process andschedules are documented in the PHAC.
Typically, a designated engineering representative(DER) can provide examples and help on the PHAC.The DER will typically audit this document along withthe other planning documents in the first phase ofcertification to determine compliance with DO-254.
THE DESIGN PROCESSAs expected, the majority of the standard applies tothe hardware design process (Figure 3).
The standard briefly discusses the system processes,but those are covered in more detail by otherstandards. For example, manufacturing processes areoutside of the standard. Interactions between theprocesses are iterative (if necessary).
REQUIREMENTS CAPTURERequirements capture and tracing are key to DO-254.The documents and processes used for requirementsare closely audited for certification. Many companiesuse tools to identify, record, and manage this process.
Figure 2: The Hardware Lifecycle
PAGE 4 www.mentor.com March 2007
Demystifying DO-254 The Hardware LIfecycle
DO-254 addresses hierarchical, high-level and derivedrequirements. A derived requirement is an additionalrequirement inferred from the hardware developmentprocess. For example:
• High-level requirement: the airspeed shall bewritten to the flight recorder every 5 seconds.
• Derived requirement: the WZX channel of theairspeed indicator shall be written to address 163 ofthe flight recorder RAM every 5 seconds.
The standard provides guidance for requirementscapture activities:
• All system requirements implemented in hardwareshould be documented. For example, architecture,test structures, interfaces, and power characteristics.
• Any safety requirements related to the hardwareshould be documented. For example, requirementsfor loss of function or damage.
• Design constraints should be identified. Forexample, standards and technology processes.
• Deriving requirements.• Design tolerances• Feeding back and monitoring requirement changes
and additions.
CONCEPTUAL DESIGNThe conceptual design process provides a high-levellook at the hardware so that reviewers can determine ifthe resulting implementation will meet the
requirements. These high-level descriptions could beblock diagrams, flowcharts, finite state machinebubble diagrams, or spreadsheets. The standardprovides guidance for conceptual design activities:
• Creation of the high-level description of thehardware.
• Major component identification and whether or notany functions of those components will not be used.If IP from a third party is used, extra work isrequired to establish assurance.
• Identification of reliability, test features, andmaintenance.
DETAILED DESIGNUsing the requirements and the conceptual design, thenext step is the detailed design process. The standardprovides guidance for detailed design activities:
• Writing of the HDL code for the design.• Implementing any architecture design techniques.• Designing in any necessary test features.• Assessing the impact on safety of any unused
functionality.• Identification of constraints or installation of the
hardware that if not met, could affect safety.
IMPLEMENTATIONUsing the detailed design data, the hardware device isproduced during the implementation process. Thus, thedevice implementation, assembly, and installation
March 2007 www.mentor.com PAGE 5
Figure 3: The Hardware Design Process
The Design Process Demystifying DO-254
processes are complete. The standard providesguidance for implementation:
• Procurement of parts• Building the device• Programming the device• Assembly• Inspection and test
PRODUCT TRANSITIONThe production transition process takes the completedhardware implementation and the verificationprocesses into production/manufacturing. Thisestablishes a baseline such that the hardware can beconsistently replicated. The standard providesguidance for product transition:
• Preparing manufacturing data from the configureddesign data.
• Checking manufacturing data for completeness.• Defining any manufacturing requirements related to
safety.• Acceptance testing.
Acceptance testing ensures that the manufacturedproduct is in compliance with key requirements. It isup to the team to choose which key requirementsshould be tested. The standard does provide guidanceon acceptance test criteria.
THE SUPPORT PROCESSESThe standard provides guidance on a set processes thatsupport the planning and design processes. Thesesupport processes include:
• Validation• Verification• Configuration Management• Process Assurance• Certification Liaison
VALIDATION PROCESSIn terms of DO-254, the validation process ensuresthat the derived hardware requirements are correct(rather than validation of system requirements). Not allderived requirements have to be validated. Specialattention is paid to those derived requirements relatingto safety. The standard provides guidance for thevalidation process:
• Identify all derived requirements needingvalidation.
• Validate each requirement by review, analysis, ortesting.
• Emphasis of the review, analysis, or testing shouldbe on safety.
• Document differences between expected and actualresults for pre-defined results. Otherwise, ensurethe results are consistent with the requirement.
• Evaluate derived requirements for completeness inthe context of the associated system requirements.
• Test requirements for ambiguity.• Trace derived requirements to the validation
activity and results.
VERIFICATION PROCESSThe verification process ensures that the hardwareimplementation matches the requirements. It is appliedto any level of the design hierarchy. The standardprovides guidance for the verification process:
• Identify requirements that require verification.• Verify each requirement by testing, simulation,
analyses, and reviews.• Perform verification coverage analysis. Essentially,
this means ensuring each requirement is verified byone of the verification techniques.
• Trace requirements to implementation and to theverification activity and results.
• Document the results.
PAGE 6 www.mentor.com March 2007
Demystifying DO-254 The Support Process
For both the validation and verification processes, thestandard provides guidance for testing and analysistasks. In addition, the standard provides guidance forrequirements and design reviews.
CONFIGURATION MANAGEMENT PROCESSThe configuration management process provides theability to replicate data or to restore data if necessary.This process also provides a controlled method formanaging changes and for archiving data. In thehardware world, this process is typically accomplishedwith the combination of enterprise systems, problemtracking, and version management software. The dataunder configuration management is typically anythingrequired for DO-254 certification. The types of objectsand the level of configuration management requireddepend on the criticality level of the design.
PROCESS ASSURANCEProcess assurance ensures that the hardware lifecycledata and processes comply with the planningdocuments (such as the PHAC). Typical activitiesinclude:
• Reviewing and tracking compliance with plans.• Identifying and documenting deviations from plans.• Determining if transition criteria have been met
between lifecycle stages.
CERTIFICATION LIAISON PROCESSThe certification liaison process provides forcommunication between the company creating thedesign and the certification representatives. Thisprocess is documented in the PHAC. The processtypically includes:
• The inputs and outputs of the planning process.• Negotiation points on compliance.• Design approach approval.• How data is to be approved.• Joint review points.
• The witnessing of tests by the certificationrepresentatives.
THE DATAData (or artifacts) are created throughout the designprocess. DO-254 auditors link this data t•requirements and plans in order to certify the system.The standard specifies general characteristics for alldata. The data should be:
• Unambiguous: a single interpretation.• Complete: all necessary requirements are present
along with the associated data.• Verifiable: there exists a means to determine if the
data is correct.• Consistent: no conflicting data exists.• Modifiable: data exists in a standard structure so
that changes can be made consistently without astructure change.
• Traceable: the origin of the data can be determined.
Arrangement, packaging, and storing the data are up tothe user, but the process must be documented in thePHAC. Figure 4 presents the artifacts for DO-254.
Some of the plans can be embedded within the PHAC(as Figure 4 indicates), or separate documents can becreated for them. The hardware accomplishmentsummary is the method of presenting compliance tothe PHAC to the certification representatives. Thestandard outlines the information that should becontained in this summary. It is good practice to workwith the certification contact to determine a template,examples, and what is expected in the summary. Thekey component of this document is a summarystatement as to compliance.
EDA TOOLSEDA tools are essential to hardware design and canplay a big role in helping to automate the DO-254methodology. When a human step of the standard is
March 2007 www.mentor.com PAGE 7
The Data Demystifying DO-254
replaced by a tool, that tool needs to by qualified usingthe process provided for by DO-254. Tools thatgenerate code have more rigorous qualification stepsthan tools that verify results.
Can an EDA tool be labeled as certified for DO-254similar to a Good Housekeeping™ seal? No, there isno such thing as a DO-254-certified EDA tool. Eachversion of a tool needs to be qualified in the context ofa particular project if required by the standard. Toolqualification is a complex subject best addressed in a
more focused paper. However, the ramifications ofusing any EDA tool in the DO-254 developmentprocess should be considered.
LEARNING MOREAs this paper is intended as an overview of thestandard, more information about the standard can befound at www.do254.com. Or the standard can beordered at www.rtca.org. An alternative is to talk toexpert customers that have been living the standard fora few years. They can offer amazing insight into the
PAGE 8 www.mentor.com March 2007
Figure 4: The artifacts of DO-254
Demystifying DO-254 EDA Tools
Corporate HeadquartersMentor Graphics Corporation8005 SW Boeckman RoadWilsonville, OR 97070-7777Phone: 503.685.7000Fax: 503.685.1204
Sales and Product InformationPhone: 800.547.3000
Silicon ValleyMentor Graphics Corporation1001 Ridder Park DriveSan Jose, California 95131 USAPhone: 408.436.1500Fax: 408.436.1501
North American Support CenterPhone: 800.547.4303
EuropeMentor GraphicsDeutschland GmbHArnulfstrasse 20180634 MunichGermanyPhone: +49.89.57096.0Fax: +49.89.57096.400
Pacific RimMentor Graphics (Taiwan)Room 1001, 10FInternational Trade BuildingNo. 333, Section 1, Keelung RoadTaipei, Taiwan, ROCPhone: 886.2.87252000Fax: 886.2.27576027
Japan Mentor Graphics Japan Co., Ltd.Gotenyama Garden7-35, Kita-Shinagawa 4-chomeShinagawa-Ku, Tokyo 140-0001 JapanPhone: 81.3.5488.3033Fax: 81.3.5488.3004
For more information, call us or visit: www.mentor.comCopyright 2008 Mentor Graphics Corporation. This document contains information that is proprietary to Mentor Graphics Corporation and maybe duplicated in whole or in part by the original recipient for internal business purposes only, provided that this entire notice appears in all copies. In accepting this document, the recipient agrees to make every reasonable effort to prevent unauthorized use of this information.
vagaries of compliance. Finally, stay tuned for morepapers on various interesting DO-254 topics from anEDA perspective by Mentor Graphics.
CONCLUSIONDO-254 provides a flexible framework for assuringhardware design, but actual implementation of thehigh-level concepts can be daunting. With anunderstanding of the basics, you probably realize thatyour company has many of the equivalent conceptsalready in practice. Many of your current assuranceprocesses may already relate to the standard. Inaddition, many of your partners and customers mayalready be working with the standard, or just startingout. Whatever the situation, together with yourpartners and tool vendors, you can seek advice,investigate tools to help the process, and get on theroad to being part of the DO-254 community.
MGC 03-08 TECH7900-w
Demystifying DO-254 Conclusion
Related Documents
