RTCA DO-254 (also known as EUROCAE ED-80), Design Assurance Guidance for Airborne Electronic Hardware,1 was prepared jointly by RTCA Special Committee 180 and EUROCAE Working Group 46, and was subsequently published by RTCA and EUROCAE in April 2000. These industry working groups were formed in the 1990s and took seven years to create DO-254.
DO-254 is not a technical manual, nor is it an engineering cookbook. It does not prescribe the design characteristics of electronic circuits or components, nor does it contain design standards. In fact, it contains virtually no technical information that an engineer can use to guide a circuit design. Instead, it provides guidance on the processes and methodologies that should be applied in the development and verification of electronic hardware to achieve an acceptable level of confidence that the end hardware functions correctly and will be in compliance with airworthiness requirements. While it can be argued that some aspects of a design can be influenced by the desire to facilitate the design and verification methodologies contained in DO-254, there are actually no design features that must or must not exist solely because of the need to comply with it.
The guidance in DO-254 represents industry consensus on the best practices that will ensure that electronic hardware is developed and verified in a way that is appropriate for its design assurance level (DAL)—often shortened to “Level”—and will ensure, to a realistic level, a safe and reliable product. The supporting processes defined in DO-254 (configuration management, process assurance, and validation/verification) are particularly effective in controlling the introduction of design errors as well as identifying errors that are inevitably introduced despite best efforts to the contrary. DO-254 describes the objectives for each phase of a typical electronic hardware development life cycle and describes the activities usually associated with the life cycle phase.
The genesis of DO-254 stems from concerns that as electronics technology rapidly evolved, enabling systems to become more complex and to host more functionality, proving that these systems were safe and reliable was becoming more and more difficult. Most of the electronic systems and programmable logic devices (PLDs) that are used on modern aircraft are well beyond our ability to prove safe through quantitative analysis, and in the absence of this avenue of design assurance, the only other viable means of establishing the necessary design assurance is to use structured and disciplined processes and methodologies during their development. The advantages of using this means are, first, that the processes and methodologies force designers to create a design in a logical and systematic (and therefore repeatable) manner, and second, they create a type of transparency in the design and its project by enforcing a high level of documentation and traceability that, while inconvenient on the surface, has repeatedly proven its worth over the long-term life of a design. Like them or not, the best practices in DO-254 can, particularly in the long run, be a project’s best friend.
The guidance in DO-254 was written to apply to all complex electronic hardware that performs safety-critical system functions. While DO-254 discusses PLDs, they are considered within the context of system and equipment development, and not necessarily as the only aspect of the system that should use the guidance in DO-254. When the Federal Aviation Administration (FAA) published its Advisory Circular (AC) 20-152,2 which approved DO-254 as an acceptable (but not the only) means of satisfying the Federal Aviation Regulations (FARs) for PLDs, it essentially reduced the application of DO-254’s guidance to a small subset of its original scope.
Narrowing the focus of DO-254 from the system level to the component level can be problematic due to the need to interpret and apply electronic system guidance to singular components within the system. Examples of potential problems include determining the scope of the life cycle data, determining how to interpret and apply DO-254 Table A-1 to PLD life cycle data, and sorting out which activities and aspects apply at the component level as opposed to the system level (such as acceptance tests, environmental tests, functional failure path analysis, and traceability to elements in the hardware implementation, none of which are entirely practical at the component level). There are also boundary issues that arise: much of DO-254’s overall effectiveness relies upon implementing all of its guidance to all levels of a system, which creates a seamless interconnection and flow of processes and data between all levels of the system (line replaceable unit [LRU], sub-assemblies, circuit card assemblies [CCA], and component [typically a PLD]). When one level of the system is singled out for the isolated application of DO-254, it loses this flow to the other levels, creating a discontinuity in both processes and data that can, if not properly anticipated, potentially render much of the design assurance activities ineffective or meaningless. Applying DO-254 only at the PLD level can be made to work through judicious interpretation and tailoring, but in the end the document is most easily comprehended and most effectively applied according to the perspective for which it was conceived and written, and ultimately for which it was intended to be applied, in other words throughout the entire system.
DO-254 defines five levels for the design assurance of airborne electronic systems. These five design assurance levels are defined as levels A through E, where A is the most stringent and E is the least. These five levels correspond to the five classifications of failure conditions defined in the regulatory materials that govern the certification of airborne systems and equipment.
Table 1.1 identifies the five hazard classifications and maps them to their corresponding design assurance level, the required probability of failure per flight hour for equipment of each level, and a description of the hazard. The hazard classifications are described with respect to the effect that a failure of the system or equipment will have on the aircraft, its occupants, its safety margins, and the ability of its crew to deal with adverse operating conditions. The most severe classification is catastrophic (level A), indicating that a failure of level A equipment will, for all practical purposes, result in a catastrophic hull loss of the aircraft. The least severe is no effect, indicating that a failure will affect neither the aircraft’s operational capabilities nor the workload of its crew.
Design Assurance Level and Hazard Classification
Failure Classification |
Hardware Design Assurance Level |
Probability of Failure per Flight Hour |
Hazard Description |
Catastrophic |
Level A |
10−9 |
Prevents continued safe flight and landing. |
Hazardous/Severe-Major |
Level B |
10−7 |
• Serious or fatal injuries to small number of occupants. • Reduces aircraft capabilities or crew’s ability to deal with adverse operating conditions. • Higher crew workload. • Large reduction in safety margins. |
Major |
Level C |
10−5 |
• Possible injuries to occupants. • Reduces aircraft capabilities or crew’s ability to deal with adverse operating conditions. • Increase in crew workload. • Significant reduction in safety margins. |
Minor |
Level D |
10−3 |
• Possible inconvenience to occupants. • Reduces aircraft capabilities or crew’s ability to deal with adverse operating conditions. • Slight increase in crew workload. • Slight reduction in safety margins. |
None |
Level E |
N/A |
• No effect on operational capabilities. • No crew workload impact. |
In DO-254 the design assurance level also determines the objectives of, and amount of rigor in, the development process, the type and quantities of artifacts from the development effort that must be preserved, the level of independence that must be maintained when conducting the development activities, and the amount and type of verification that must be performed on the design.
The guidance in the main body of DO-254 (chapters 1 through 11) is written for electronic hardware of design assurance level C. DO-254 accommodates the higher design assurance levels (A and B) through the application of its Appendix B, which contains additional verification-related activities that are intended to provide the extra measure of assurance that is appropriate for equipment that requires per-hour failure probabilities less than 10−7. Equipment with a design assurance level of C or D must comply with chapters 1 through 11 of DO-254, and levels A and B must comply with chapters 1 through 11 and Appendix B.
It is worth noting that the inherent failure probability of semiconductor components is typically no better than 10−5 to 10−6. Or in other words, the inherent reliability limitations of semiconductor devices prevents the electronic hardware from achieving the failure probabilities required for level A or B systems, and therefore the development guidance in DO-254 will not by itself result in a design with the requisite level A or B reliability. The requisite reliability, however, can be achieved at the system level through the architectural mitigation techniques described in SAE ARP47543 or SAE ARP4754A,4 even though the hardware itself is limited to the approximate failure rate for level C hardware.
Since the design process cannot create hardware that is able by itself to satisfy the requisite failure rate for level A or B systems, the only remaining avenue of design assurance for those higher levels is to employ additional verification-related techniques to ensure that every design error is detected and removed, thereby assuring that the hardware will achieve its maximum potential reliability. DO-254 Appendix B, which focuses on the verification-related techniques that ensure that every function in the design is fully identified and tested, is applied to level A and B hardware to ensure, as well as possible, that all design errors are detected and removed.
DO-178B,5 Software Considerations in Airborne Systems and Equipment Certification, was published and adopted years before electronic hardware was required to comply with DO-254. DO-178B’s head start had two rather curious effects on electronic hardware development. First, there was a temptation for equipment manufacturers to move their system functionality from software to hardware because of the significant increase in time and effort (both perceived and actual) that DO-178B imposed on software development. The idea, of course, was that if equipment functionality could be moved to electronic hardware it would not have to be subjected to the expensive and difficult design assurance processes in DO-178B. The second effect is that the terminology, concepts, and processes from DO-178B became so well established in the airborne design assurance community that it still heavily influences how DO-254 is applied and implemented for hardware. While it may seem obvious that hardware and software are fundamentally different, and therefore should be treated differently for the purposes of design assurance, this seemingly elemental observation has at times been overwhelmed by the sheer inertia of DO-178B’s influence.
So how do DO-254 and DO-178B (or DO-178C6) compare? And are the differences all that significant? Since both documents provide guidance on development processes, there are bound to be significant similarities in their content and philosophy. In fact, from the high level perspective they are quite similar in their approaches and fundamental concepts. The similarities can be summarized as follows:
• Their safety background and basis are the same.
• Both rely on process and design assurance.
• Both use life cycle phases to govern development.
• Both use the integral processes of process assurance (quality assurance for software), configuration management, and verification.
• Verification is requirements-based.
• Both include tool qualification.
So in a broad sense the two documents are very similar. However, when examining the details of their design assurance concepts and processes, a number of differences emerge, some of them dramatic enough that trying to apply DO-178 concepts to hardware development will not result in the desired design assurance. The differences between DO-254 and DO-178 (and to some extent between hardware and software) are embedded in the details, and are listed in Table 1.2.
Differences between DO-254 and DO-178B/C
Topic |
DO-254 Hardware |
DO-178B/C Software |
Environmental tests |
Required |
Not applicable |
Part wear out |
Need to consider |
N/A |
White box testing |
Test points and simulation |
Can perform with emulator and/or symbolic debugger |
Implementation |
Hardware and components |
Machine code within hardware components |
Debugging |
Device pin level |
Assembler level |
Robustness testing |
Optional or project dependent |
Required |
Object oriented considerations |
Not applicable |
Ada95, C++, Java |
Objectives for compliance |
Defined in sections 4.1, 5.1.1, 5.2.1, 5.3.1, 5.4.1, 5.5.1, 6.1.1, 6.2.1, 7.1, 8.1 |
Annex A Tables |
Applicability |
LRU, CCA, PLD, any complex electronic hardware |
Software only |
Tool qualification |
Tool qualification not required for elemental analysis tools |
Tool qualification required for structural coverage analysis tools |
Independence |
Broad brush stroke approach in Appendix A |
Specific objectives depending on software level |
Simulation |
May need second independent simulation; difficult to use same test procedures in simulations and in-circuit hardware tests |
Easy to use the same test cases on simulation and on target hardware |
Coverage analysis |
Elemental analysis not specific about coverage criteria definition |
Modified Condition/Decision Coverage defined for Level A Decision coverage defined for Level B Statement coverage defined for Level C |
Verification |
Test coverage of requirements, coverage of elements for Levels A and B |
Test coverage of high-level and low-level requirements, structural coverage and test coverage of data and control coupling |
Definition of derived requirement |
Design decision; may or may not have a parent requirement |
Glossary—almost the same as DO-254 Usage in Section 5—no parent requirement |
Simple |
Exhaustive input testing and reduced documentation allowed |
Not applicable |
Design approach |
For PLDs, hardware description language describes how the physical hardware in the PLD will be configured For other electronic hardware, graphical entry such as schematic diagrams |
Procedural language that describes a sequence of steps |
Processing |
For PLDs, parallel simultaneous implementation of hardware design language (HDL); functionality is implemented concurrently |
Instructions execute in sequence |
Validation |
Derived requirements are validated to ensure they are correct and complete |
Not in the scope of software—derived requirements must be justified but are not validated |
Means of application |
Written for Level C with additional measures for Levels A and B |
Written for Level A with reductions in objectives, activities, and artifacts for Levels B through D |
While some of the differences may seem trivial or inconsequential, others are significant and can result in serious consequences if DO-178 is allowed to influence how DO-254 is applied to hardware. All of the differences should be carefully considered and understood to pre-empt any confusion or misunderstandings when applying DO-254. In general, software definitions, techniques, and processes should not be used with hardware.
Perhaps the most insidious, confusing, and persistent of the differences is the definition of a derived requirement. DO-178B’s long dominance of the design assurance field has resulted in a strong tendency, especially among people who have a software background or who are used to the language of DO-178B, to assume that the DO-254 definition is the same as the one found in DO-178B, or more commonly, that the DO-178B definition is universal and therefore applies to hardware as well as software. However, while the glossaries in both documents define a derived requirement as an additional requirement that results from the design process and which (may or) may not be directly traceable to a higher level requirement, Section 5.0 of DO-178B narrows the definition of a derived requirement to a requirement that does not directly trace to a higher level requirement. The definition in DO-178B Section 5.0 has superseded the glossary definition and has, again due to the long-time dominance of DO-178B, been treated as the more or less universal definition of a derived requirement. This is unfortunate from a number of perspectives, a significant one being that the processes (particularly the validation process) in DO-254 are designed to work with the DO-254 definition, and as will be described in more detail later, problems can arise if the DO-178B definition is indiscriminately used with the processes in DO-254.
The guidance in DO-254 covers a variety of topics including:
• Hardware standards
• Hardware design life cycle data
• Additional design assurance techniques for design assurance level (DAL) A and B functions
• Previously developed hardware
• Tool assessment and qualification
• Use of commercial off-the-shelf (COTS) components
• Product service experience
• Hardware safety assessment
• Design assurance strategy, including consideration for DAL A and B functions
• Planning process
• Requirements capture
• Conceptual design
• Detailed design
• Implementation
• Production transition
• Validation process
• Verification process including tests and reviews
• Configuration management
• Process assurance
• Certification liaison and proposed means of compliance
DO-254 ties together several key aspects of equipment development and compliance issues that would be otherwise difficult to achieve for complex and/or highly integrated devices and/or systems. These aspects are:
• Use of design assurance in lieu of quantitative analysis of failures
• Use of requirements to capture the aspects of aircraft functions performed by complex electronic hardware
• Use of review, analysis, and test to satisfy compliance to the FARs through verification
DO-254 contains eleven sections (or chapters) and four appendices. Table 1.3 identifies the sections and appendices and summarizes their topic areas.
The sections of DO-254 and their relationships are shown in Figure 1.1.
Section 1 introduces DO-254 and describes its scope and applicability, and defines certain keywords such as “should,” “may,” and “hardware item.” It is worth noting here that DO-254 does not define nor use the word “shall,” which is commonly used to identify mandatory practices or requirements. This is appropriate given DO-254’s role as guidance rather than requirements. Even AC 20-152 does not mandate compliance to DO-254 by stating that compliance to DO-254 is an acceptable, but not the only, means of complying with the FARs. Novices in the certification industry are quick to latch onto this point and object that DO-254 is just guidance, not requirements, and that the FAA does not make compliance to it mandatory. This is normally stated in the hope of sidestepping DO-254, but in realistic terms, any means of compliance other than DO-254 could be much more difficult and expensive to implement, even in the unlikely event that the certification authorities approve it.
DO-254 Section 1 also states that DO-254 does not attempt to define the nature or identity of “firmware,” but does state that firmware should be classified as either hardware or software and then addressed appropriately through DO-254 or DO-178 as applicable. To persons who are inexperienced in the business of hardware description languages and PLD design, it is common for an HDL’s resemblance to software to prompt them to try to classify it as such. However, those who are more experienced with firmware realize that HDLs, while similar to software code in appearance, are fundamentally different and have more in common with, and thus should be classified and treated as, hardware. Subjecting an HDL design to the software processes in DO-178B or DO-178C would present a host of problems, and for some processes would prove to be impractical if not impossible.
One aspect of DO-254 Section 1 that attracts a great deal of interest is the introduction of the concept of “simple” versus “complex” hardware, especially the last paragraph of Section 1.6, which states that simple hardware items do not need extensive documentation and can comply with DO-254 with reduced overhead. For virtually all equipment suppliers, the idea of simple hardware, and the reduced effort associated with it, is immensely attractive, and is immediately embraced as a possible means of avoiding full compliance to DO-254. This desire to avoid the cost and schedule impact of DO-254 is often so strong that equipment suppliers will go to great lengths to classify their hardware as simple even when it really is not. The fact that DO-254 does not provide a quantifiable definition of the “comprehensive combination” of tests and analyses that must be performed on simple hardware just exacerbates the situation and provides the necessary ambiguity to inspire these efforts to thwart DO-254. However, FAA Order 8110.1057 addresses the complexity issue and provides specific guidance on what constitutes the necessary comprehensive combination of tests for simple hardware, the result being that for anything other than truly simple hardware, the simple hardware approach will be either impractical or more expensive than treating the hardware as complex and complying with all of DO-254. In fact, 8110.105’s verification guidance for simple hardware can be used in reverse to provide guidance on the definition of a simple device: if it is realistic or even possible to comprehensively test a hardware item according to the guidance in 8110.105, then the hardware can be correctly classified as simple.
DO-254 Section 2 describes how the processes, activities, hardware, and other data from DO-254 interface to the overall certification process. Information flow between hardware and system, and between hardware and software, is briefly discussed. Section 2 also discusses the system safety process and identifies the design assurance levels and their characteristics, as well as hardware safety assessment considerations.
Summary of Contents of DO-254
Section |
Title |
Topics |
1 |
Introduction |
Purpose/Scope, relationship to other documents, related documents, how to use DO-254, complexity, alternative methods, overview |
2 |
System Aspects of Hardware Design Assurance |
Information flow, system safety assessment processes, hardware safety assessment |
3 |
Hardware Design Life Cycle |
Life cycle processes, transition criteria |
4 |
Planning Process |
Planning process objectives and activities |
5 |
Hardware Design Processes |
Design process phases, objectives, and activities |
6 |
Validation and Verification Process |
Validation process, objectives, and activities Verification process, objectives, and activities Validation and verification methods |
7 |
Configuration Management Process |
Configuration management objectives and activities Data control categories |
8 |
Process Assurance |
Process assurance objectives and activities |
9 |
Certification Liaison Process |
Means of compliance and planning Substantiating compliance |
10 |
Hardware Design Life Cycle Data |
Plans, standards, design data, validation/verification data, acceptance test criteria, problem reports, configuration management (CM) records, process assurance records, Hardware Accomplishment Summary (HAS) |
11 |
Additional Considerations |
Previously developed hardware, COTS components, product service experience, tool assessment and qualification |
Appendix A |
Modulation of Hardware Life Cycle Data Based on Hardware Design Assurance Level |
Life cycle data, independence |
Appendix B |
Design Assurance Considerations for Level A and B Functions |
Functional failure path analysis (FFPA), architectural mitigation, product service experience, advanced verification methods |
Appendix C |
Glossary of Terms |
Definitions of relevant terminology |
Appendix D |
Acronyms |
Definitions of acronyms |
FIGURE 1.1 (See Color Insert.) Structure of DO-254
DO-254 Section 3 contains a very brief discussion of the hardware design life cycle and the transition criteria that govern the movement of the life cycle from one phase or process to the next. This section identifies the life cycle processes as being the planning process, the design process, and the supporting processes. The supporting processes are further identified as being validation, verification, configuration management, process assurance, and certification liaison.
DO-254 Section 4 describes the objectives and activities of the planning process, which is the first of the design life cycle processes. Six hardware management plans and four standards are defined for hardware development: the Plan for Hardware Aspects of Certification (PHAC), Hardware Design Plan (HDP), Hardware Validation Plan (HVP), Hardware Verification Plan (HVP), Hardware Configuration Management Plan (HCMP), Hardware Process Assurance Plan (HPAP), Requirements Standards, Hardware Design Standards, Validation and Verification Standards, and Hardware Archive Standards. Table 1.4 lists these plans and standards, where in DO-254 their contents are described, and which of the DO-254 objectives are satisfied by them.
DO-254 Section 5 describes the objectives and activities of the hardware design process. This section describes a generic design process consisting of five phases: Requirements Capture, Conceptual Design, Detailed Design, Implementation, and Production Transition. An organization’s design process does not have to be the same as this process, but it should be able to satisfy all of the Section 5 objectives.
DO-254 Sections 6 through 9 describe each of the supporting processes. The objectives and activities of the validation and verification processes are described in Section 6, configuration management in Section 7, process assurance in Section 8, and certification liaison in Section 9.
DO-254 Section 6 covers the objectives and activities of the validation and verification supporting processes. Validation is the process of ensuring that derived requirements are correct and complete, and verification is the process of ensuring that the final product meets its requirements.
DO-254 Section 7 addresses the objectives and activities of the configuration management supporting process. It includes configuration items, configuration identification, baselines, problem reporting, change control, and archiving.
DO-254 Section 8 is about the process assurance supporting process, and covers its objectives and activities such as process assurance reviews and audits.
Hardware Management Plans
Plan |
Content Described in DO-254 Section |
Objective Satisfied |
Plan for Hardware Aspects of Certification (PHAC) |
10.1.1 |
4.1-1, 2, 3, 4 |
Hardware Design Plan |
10.1.2 |
4.1-1, 2, 3, 4 |
Hardware Validation Plan |
10.1.3 |
4.1-1, 2, 3, 4 6.1.1-1 |
Hardware Verification Plan |
10.1.4 |
4.1-1, 2, 3, 4 6.2.1-1 |
Hardware Configuration Management Plan |
10.1.5 |
4.1-1, 2, 3, 4 7.1-3 |
Hardware Process Assurance Plan |
10.1.6 |
4.1-1, 2, 4 8.1-1, 2, 3 |
Requirements Standards |
10.2.1 |
4.1-2 |
Hardware Design Standards |
10.2.2 |
4.1-2 |
Validation and Verification Standards |
10.2.3 |
4.1-2 |
Hardware Archive Standards |
10.2.4 |
4.1-2; 5.5.1-1; 7.1-1, 2 |
DO-254 Section 9 discusses the certification liaison supporting process, including means of compliance, planning, and how to substantiate compliance.
DO-254 Section 10 describes the content of each type of hardware life cycle data, especially the hardware management plans (PHAC, HDP, HVP, HCMP, HPAP), standards, hardware design data, verification data, and the Hardware Accomplishment Summary.
DO-254 Section 11 includes the “Additional Considerations,” or in other words everything that is left over. Its contents include previously developed hardware (PDH), COTS components, product service experience, and tool assessment and qualification.
DO-254 Appendix A includes a table of all hardware life cycle data items and correlates them to their hardware control category, which in turn defines which configuration management processes and methods must be used to manage them. It also includes a definition of independence.
DO-254 Appendix B contains various verification-related techniques that must be applied with level A and B hardware. The techniques include functional failure path analysis, architectural mitigation, product service experience, and advanced verification techniques (elemental analysis, safety-specific analysis, and formal methods).
Among organizations that are getting into the business of DO-254 programs, two common questions are, “What do I have to do to comply with DO-254?” and “How much will DO-254 cost?”
Compliance is obviously the simpler question to answer, and the answer is to simply adopt (and adapt to) the industry best practices in DO-254. These are summarized as follows:
• Establish a structured design process that meets the objectives defined in DO-254
• Well-defined phases with realistic entry and exit criteria
• Built-in peer reviews
• Do the front-end work (requirements, traceability, plans, analysis, research, etc.) conscientiously and at the proper time
• Honor and observe the design process (do not ignore or bypass it, even during a crisis)
• Learn how to write well-formed requirements
• Emphasize the use of functional requirements rather than design description (implementation) requirements
• Write them early
• Understand what a derived requirement is
• Learn how to document validation and traceability data as part of requirements capture
• Establish high integrity validation and verification processes and methods, including:
• An independent peer review process for levels A and B
• Peer reviews of data and documents
• Requirement reviews to validate derived requirements
• Learn how to conduct requirements-based verification
• Learn how to write effective and optimized test cases
• Learn how to conduct robustness verification
• Simulations—functional and post-layout timing (or static timing analysis)
• Elemental analysis—code coverage
• Hardware test—in the actual flight hardware
• Acquire tools to support verification
• Establish a configuration management infrastructure, including:
• Problem reporting
• Document/data control
• Document/data release
• Backups/archives
• Refresh of backup media
• Retention of data for life of use of the equipment
• Retention of tools and test equipment for life of use of the equipment
• Establish a component management process—be prepared for parts obsolescence
• Establish a process assurance role or department
• Perform audits, review
• Track deviations
• Audit transition criteria
• Be prepared for audits of off-shore or subcontracted work
• May need a sub-supplier management plan
• May need on-site stage of involvement (SOI) audits
• Close coordination with configuration management and control of data
• Close coordination with process assurance
• Technical oversight
• Interface with customer and/or airframer
• Establish and interpret requirements
• Interface with certification authority
• FAA and/or designee
• SOI audits
• Organize vast amounts of data
• Write lots of documentation and reports
• Cultural changes
• Use the CM system
• Use change control
• Comply with processes—no more informal engineering
• Transparency
• Accountability
• Learn new rules for component selection
• Settle for less than the leading edge technology
• Embrace more tried and true technology, tools, methods
• New is ok, but may require more verification or justification
Obviously the list seems long, but for most companies, compliance might require adaptation (or not) but should never be impossible. Changing the engineering culture—if it is needed, since some companies have already discovered the benefits of using the best practices in DO-254—is often the hardest part of complying with DO-254, but with time it can be done.
The second question is somewhat dependent on the answer to the first one and is considerably harder to answer, mainly because there simply is not a good quantifiable answer to it. Some people try to attach a percentage escalation factor to a project, for example adding on 30 percent to a project’s non-DO-254 cost to account for DO-254 compliance, but in reality the cost is going to be determined by a company’s DO-254 “gap” (how much its existing processes fall short of DO-254) and how agreeable the company and its personnel are to changing their ways and learning new tricks, i.e., how willing they are to close that gap. A company whose processes are reasonably consistent with DO-254 can conceivably incur significant additional costs simply because its personnel resist DO-254 rather than embrace it. Likewise, a company that has little or none of the DO-254 infrastructure can conceivably comply with DO-254 with minimal inconvenience and cost if the company and its people are open to learning and using the processes in it. The amount of discomfort and cost associated with DO-254 is almost entirely self-determined, and the lesson that “the most expensive path to DO-254 compliance is the one that tries to go around it” can be a difficult and expensive one to learn.
For convenience, references to DO-178B and DO-178C in this book will simply use DO-178 when the discussion applies equally to both versions of DO-178. The reference to DO-178B will be used when reference to the earlier version is intended. Similarly, references to SAE ARP4754 and SAE ARP4754A will use ARP4754 when the discussion applies equally to both versions of ARP4754.
1. RTCA DO-254, Design Assurance Guidance for Airborne Electronic Hardware, RTCA Inc., Washington, D. C., 2000. This document is also known as EUROCAE ED-80.
2. Advisory Circular Number 20-152, RTCA, INC., DOCUMENT RTCA/DO-254, DESIGN ASSURANCE GUIDANCE FOR AIRBORNE ELECTRONIC HARDWARE, Federal Aviation Administration, June 2005.
3. SAE ARP4754, Certification Considerations for Highly-Integrated or Complex Aircraft Systems, Warrendale, PA: SAE, 1996.
4. SAE ARP4754A, Guidelines for Development of Civil Aircraft and Systems, Warrendale, PA: SAE, 2010.
5. RTCA DO-178B, Software Considerations in Airborne Systems and Equipment Certification, RTCA Inc., Washington, D.C., 1992. This document is also known as EUROCAE ED-12B.
6. RTCA DO-178C, Software Considerations in Airborne Systems and Equipment Certification, RTCA Inc., Washington, D.C., 2011. This document is also known as EUROCAE ED-12C.
7. Order 8110.105 CHG 1, Simple and Complex Electronic Hardware Approval Guidance, Federal Aviation Administration, dated September 23, 2009.
1. The Federal Aviation Administration Web page: www.faa.gov
2. The RTCA Web page: www.rtca.org
3. The SAE Web page: www.sae.org
4. EASA Web page: www.easa.europa.eu
5. FAA Regulatory and Guidance Library (RGL) Web page: rgl.faa.gov
6. CAST Position Papers Web page: www.faa.gov/aircraft/air_cert/design_approvals/air_software/cast/cast_papers/