DO-254 Intro, Compliance: Free Tools/ Papers / Resources

DO-254 Introduction

Avionics hardware DO-254 clearly explained.

Read Excerpt Below, or Click Here To Download Full 10-20 Page Paper

DO-254 facts, myths, challenges, and successes described in this paper. DO-254 can be expensive, sometimes increasing hardware development/documentation costs by 150%. This DO-254 paper provides facts to hopefully reduce DO-254 costs by 20-50%.

DO-254 has been called “DO-178’s Little Sibling.” Like many little brothers and sisters worldwide however, the term “little” is often wrong and in a few areas the relationship itself is suspect …
The following provides an overview of DO-254 plus relevant differences with DO-178C.

DO-254, or more properly, “Design Assurance Guidance for Airborne Electronic Hardware,” was created as an obvious response to two simultaneous and related events:

Firmware was playing a larger role in avionics, with developers rapidly leveraging increased silicon-based complexity, and
The avionics firmware development process was unregulated, with certification performed after-the-fact at a high level

While embedded avionics software engineering made huge strides and inroads in the eighties and nineties, firmware development was considered an informally adjunct art form. But what is “firmware”? When does “soft” become “firm” become “hard”? Time for a review …

Twenty years ago, firmware was relegated to specialized functions within avionics as compared to its highly varied role today. There were multiple reasons early firmware was more limited in aviation:

Firmware development tools provided limited flexibility compared to software
Firmware was difficult to change once burned or loaded in silicon devices
Firmware was considered a less-desirable option than software due to a seemingly more difficult debugging and update process

While there was truth in each of the aforementioned reasons, smart engineers coupled with more capable development environments assured the evolution and adoption of firmware within avionics. In particular, great strides in Field-Programmable Gate Arrays (FPGA’s) brought such firmware to the forefront of aviation. With FPGA’s, all of the aforementioned restrictions on firmware adoption were dramatically reduced. FPGA’s increasingly have very modern development tools, were easy to update, and allowed for potential flexibility and execution speed advantages over software-based logic.

As a result of this evolution (or almost “revolution”) in silicon based logic, avionics developers increasingly exercised the choice of implementing logic via silicon- instead of software. However, DO-178 did not strictly apply to silicon based logic and there was no regulatory counterpart for such; thus silicon-based logic could potentially avoid the certification rigor associated with software, even though the logic may have a nearly identical purpose between software and silicon. Thus the need for DO-254: to ensure that logic developed specifically for avionics purposes underwent a similar development and certification regimen as if it had been implemented via software using DO-178…

DO-254 then covers Complex Electronic Hardware (CEH), e.g. hardware with embedded logic. DO-254 is:

A flexible framework for the development of airborne hardware containing avionics-specific logic.
Able to accommodate almost all types of hardware ranging from sensors, multiplexers, and switches to full-featured FPGA’s and ASIC’s.
A guideline which tries to cover a nearly infinite spectrum of applications thus lacks specificity for particular projects.

Like software, the term “airborne electronic hardware” from DO-254’s title is wide-ranging. At the beginning and end of the day, hardware is part of a system or more specifically an aviation eco-system. Therefore, DO-254 is normally preceded by a safety assessment per ARP4761 and an avionics system development process per ARP4754A. And the hardware itself will typically be required to undergo environmental testing via DO-160. Therefore, DO-254 is merely one link within the avionics certification chain. Avionics will be neither safe nor compliant without this safe foundation which precedes DO-254.

As previously noted, the DAL greatly affects process rigor applied to hardware via DO-254. The following graphic summarize key differences between the DALS for DO-25.

Key DAL Aspect Differences for DO-254: from AFuzion DO-254 Training

Again, in DO-254 especially, the DAL of the hardware is usually, but not always, the same as the System DAL. Why? The system contains hardware which is necessary to perform its functionality and that hardware is expected to directly correlate to the system’s contribution toward flight safety.

However, this principle cannot always hold. For example, the author of this paper worked on one DO-254 project where the System was DAL B, the Software was DAL B and DAL D, but the FPGA was DAL C; in that case the FPGA was used to merely translate data packets which were checked both upstream and downstream via software. Such is the interesting thing about rules: for each one, an exception can be found.

Process Assurance is like Quality Assurance but with a larger scope including auditing of hardware suppliers and manufacturing transition processes. Process Assurance has five primary activities as depicted in the following diagram:

Process Assurance in DO-254 differs from software’sDO-178C quality assurance because hardware’s Process Assurance must audit hardware suppliers and ensure subsequent system manufacturing processes are documented, repeatable, and conform to plans. Since DO-254’s hardware’s Process Assurance has these two additional roles versus software’s Quality Assurance, it has the different name “Process Assurance”.

Scope of DO-254

DO-254 applies to most all avionics hardware, however more recent interpretations and application of DO-254 focus upon Complex electronic hardware as noted previously. Why? Because the Simple hardware is definable via black-box requirements and those requirements (and thus all the Simple functionality) can be tested at a black-box system level for example as already required under ARP4754A.

For Simple hardware, the significant additional cost of detailed planning, detailed design, and low-level verification activities prescribed by DO-254 provide little added-value hence are normally not required unless a specific certification authority deems them necessary in a particular instance, for example because ARP4754A was not otherwise applied. Therefore, the most common application of DO-254 is depicted in the figure below which also elucidates the scope of DO-178C:

DO-254’s Planning Process

Wise persons know “What gets planned, gets done”. Wiser avionics authorities know “What gets planned thoroughly can be assessed more thoroughly”. Accordingly, DO-254 requires a detailed planning process consisting of five Plans and four Standards:

The DO-254 Plan for Hardware Aspects of Certification (PHAC) is the foundational planning document of an avionics hardware system. (For information on AFuzion’s DO-254 Templates and checklists, click here: https://afuzion.com/plans-checklists/#do-254-plan-templates)

The DO-254 PHAC provides an overview of the avionics system’s hardware, safety criteria with respect to DAL, and planned certification activities as noted in the following figure from AFuzion’s DO-254 training classes:

A good way to understand the application of DO-254’s four standards is to consider that DO-254 itself covers the more objective (measurable) aspects of the hardware development lifecycle, whereas certain aspects are more subjective yet equally important. Those subjective areas are hardware requirements, hardware design, hardware archival, and hardware V&V. Since each avionics project must have its own processes and assessment criteria for these subjective areas, such are specified within the four project-specific Standards thus making these “subjective” aspects “objective” for each project.

While most of the aviation guidelines are self-contained, DO-254 is unique: because it was originally intended to address all non-software aspects of a system, and there was very little complex hardware logic, numerous adjunct documents were continually added to address the evolving hardware landscape. This historical DO-254 evolution is summarized in the following graphic excerpted from AFuzion’s DO-254 training:

A common question on DO-254 projects is “Does hardware need both high-level and low-level requirements like DO-178C’s software?” The basic answer is “No – hardware only has one level of requirements, but has two levels of design: conceptual design then detailed design”. However, smart practitioners will understand the providing low-level requirements prior to implementing software reduces the number cause of software defects: assumptions.

Similarly, hardware logic developers would be well-advised to similarly ensure their single level of hardware requirements was sufficiently detailed. The official hardware versus software requirements/design depiction is shown in the following graphic (see AFuzion’s advanced DO-254 Training, Day 2, for details):

DO-254 (Hardware) versus DO-178C (Software) Requirement/Design Process Flow

Another common question when applied DO-254 to silicon-based logic is “Does DO-254 require logic reviews similar to DO-178C’s software code reviews?” The quick answer is “Yes”. The following figure depicts the necessary inputs and outputs to a hardware logic review. Note the ‘transitions” from pre-to-post-logic review which are performed by engineers and audited by hardware Process Assurance.

Summarizing DO-254

To summarize the DO-254 ecosystem:

DO-254 is a flexible framework for the development of airborne hardware containing avionics-specific functionality.
DO-254 is able to accommodate almost all types of hardware ranging from sensors, multiplexers, switches, and aggregated simple silicon devices, in addition to full-featured FPGA’s and ASIC’s.
DO-254 is a guideline which tries to cover a nearly infinite spectrum of hardware varieties thus lacks specificity for particular projects.

Like software, the term “airborne electronic hardware” from DO-254’s title is wide-ranging. At the beginning and end of the day, hardware is part of a system or more specifically an aviation eco-system. Therefore, for civil aviation DO-254 is preceded by a safety assessment per ARP4761/A and an avionics system development process per ARP4754A; military aviation is gradually adopting a similar (in some cases identical) safety/systems process for DO-254 military adoption. And DO-254 applicable hardware itself will typically be required to undergo environmental testing via DO-160.

Therefore, DO-254 is merely one link within the avionics certification ecosystem. Avionics hardware cannot be provably safe nor compliant without this ARP4761/A and ARP4754A safety/systems foundation which precedes DO-254.

The DO-254 process employs detailed project-specific planning followed by continual assessments and process feedback loops to ensure defined hardware development processes specified in those Plans and Standards are followed. For an overly simplistic view of the DO-254 lifecycle process (without depicting requisite feedback loops, changes, reviews, etc.), this author’s opinion is that the following comprises an optimal DO-254 engineering development lifecycle:

Figure: Optimal DO-254 Hardware Engineering Path per AFuzion

DO-254 has specific objectives based upon that hardware’s DAL. There are five DALs associated with airborne avionics systems, noted as level A through E, with level A being the most stringent. For software, under DO-178C, the differences between levels are greater than they are under DO-254 and each software DAL has distinctly discrete Objectives ranging from 26 objectives for DAL D to 71 objectives for DAL A.

Overly simplified, DO-254 levels A and B are nearly identical with strict criteria applied to the engineering processes associated with each line of hardware logic; levels C and D are less rigorous and focus upon hardware black-box requirements/testing and lack consideration of hardware logic development and test. Level E requires no additional hardware design certification under DO-254.

(For additional avionics test tool information, see http://certegic.com/aviation-development-information/verification-tools/). The rigor applied to planning, development, and correctness of the hardware is directly associated with its DAL, often referred to as “criticality level.” These five levels with increasing rigor from Level E to the most stringent Level A, are depicted below:

DO-254 Engineering “Independence” per Development Assurance Level.
Note Quality/Process Assurance must always be independent)

Common DO-254 Mistakes

DO-254 has been subsequently modified, however DO-254A is not expected until at least 2025. However, DO-254 has been modified by AC 20-152, CAST-27, EASA SWCEH CM-001, and AMC 20-152. To get a full understanding of DO-254’s evolution and application in the real world, DO-254 training information is provided here.

Also, free mini DO-254 training videos are available here.

Most DO-254 practitioners find their first DO-254 project incurs a 50-60% cost and schedule increase. However, the following top 10 DO-254 Mistakes are responsible for most DO-254 cost increases (download the entire free AFuzion DO-254 Paper to read further).

DO-254 is often called “DO-178C’s Little Brother” and unfortunately it does bear too much resemblance to software. And you all know hardware development is virtually identical to software, surely? Not at all, and therein lies the source of the most significant mistakes with DO-254: thinking DO-178 processes fully and equally apply.

DO-254 is truly subjective, vague, and software-centric; yet avionics certification typically requires conformance combined with proven high quality and reliability. DO-254’s success is elusive and complaints abound from both sides of the certification aisle from suppliers and certifying agencies. This implies for the applicant a very tight monitoring and depth control on the procurement process, in particular when procuring commercial-off-the–shelf avionics.

In truth, DO-254 is rarely cost-effective in its first usage. However, the competitive landscape of avionics, both commercial and military, is just that: competitive and focused upon long-term cost effectiveness, long equipment lifetime, and continual safety. Therefore, the goal is to achieve DO-254 compliance while meeting (and hopefully surpassing) the competition. Such success requires achieving certification via the most expedient and productive path possible, while avoiding any major mistakes.

Remember, bad luck is not the cause of mistakes, just as those same mistakes are not prevented through good luck. Mistakes are the result of a lack of understanding, planning, and neglecting to apply DO-254’s true intent. As a famous golfer (not quite as famous as Mr. Carson Mandic) once said after a particularly spectacular tournament win, “Me, Lucky? Hmmm … Luck is interesting: I’ve found that the more I practice, the luckier I become!” With this Whitepaper, it is hoped that your own “luck” increases with your successful DO-254 practice.

Mistake # 13: Failing to consider all of DO-254 as an “Integrated Eco-System”

DO-254 requires users to consider the larger ecosystem including Safety, Systems, Software, and multiple other guidelines which need to be considered for avionics as depicted below. In particular, ARP4761A and ARP4754A, Safety and Systems respectively, must be continuously applied throughout the hardware engineering lifecycle.

Figure: DO-254 Integrated Ecosystem (from AFuzion’s DO-254 Training)

Mistake #12: Failure to Understand and Apply CAST-27

DO-254 seemingly requires mandatory application to circuit cards, Line Replaceable Unites (LRU’s), and DAL D systems. However, DO-254 was informally “revised” by the cross-Atlantic North American / European coordination group known as “Certification Authorities Software Team” “(CAST). (Note: while seemingly a software-only group, there is not a similar hardware group so CAST also delves into hardware).

The CAST group authored an official memo named CAST-27 which clarifies numerous aspects of DO-254. If you are working with DO-254, (and why wouldn’t you be if you’re reading this now), then it is incumbent upon yourself to review and apply CAST-27; this important memo reduces the work of DO-254 certification in numerous areas and thus is mandatory to save time and reduce costs.

Mistake #11: Insufficient PHAC

The PHAC (Plan for Hardware Aspects of Certification) is the cornerstone document for every avionics certification. Each system requires its own PHAC and there may be additional PHACs for various hardware components within the system. The PHAC is one of the few DO-254 required hardware documents (there are over two dozen required for each project) that must be submitted to and approved by the certification authorities (FAA for civil aircraft, military for defense-related aircraft).

The PHAC should clearly state all certification rationale, tools and tool qualification strategies, COTS hardware, high level system architecture, scope of DO-254 per that architecture, criticality level justification, responsibilities, and schedule aspects. In addition, the producer should obtain approval prior to meaningful additional hardware development work or be willing to stomach substantial certification risk in the absence thereof.

For a detailed DO-254 PHAC Review Checklist, see: https://afuzion.com/plans-checklists/#do-254-plan-templates and the 10-page AFuzion PHAC Review Checklist figure below:

PHAC Review Checklist: Page 1 of 10

Mistake #10: Poor Management Visibility & Manual Reviews

DO-254 requires adherence to 50+ major objectives and reviews of dozens of process steps, documents, and artifacts. Yet “management” rarely has visibility into the true project or review status. The answer? Automate the review process via approved FAA-compliant DO-254 checklists and also automate the project management process with a DO-254 specific project tracking tool. Keep metrics based upon reviews and audits and introduce corrective feedbacks to improve engineer’s skills and performance; DO-254 affords this opportunity for improvement.

Mistake #9: Missing “No Unwarranted Changes” CM Step

DO-254 requires strong hardware configuration management (CM). While not required, virtually all successful avionics projects utilize a commercial CM tool. These tools range from overly simple and minimally useful, to overly complex, burdensome, and expensive.

However, they all have one attribute in common: none checks or enforces DO-254’s requirement that the hardware defect correction process ensures that no unwarranted changes are made during the correction of a defect. What are unwarranted changes? Any change not specifically associated with, or cited, in the corresponding problem report. How are unwarranted changes prevented? Manually, via the reviewer (preferably independent; independence is required for the higher criticality levels of DO-254).

The reviewer should merely compare “before vs. after” (with the assistance of an electronic “diff” comparing the digital items (requirements, source logic, tests, etc.) and ensuring that the only changes made directly pertain to the problem or anomaly described in the corresponding problem report.

Mistake #8: Lack of Automated Testing

Testing is a key aspect of DO-254, particularly the onerous “element analysis” which assesses test coverage of all internal, white-box logic elements. And testing is the ultimate assessment of implementation versus requirements. It is common for projects to expend more hours on hardware testing than on hardware logic implementation. Whereas hardware logic implementation is (or should be) given the full benefit of modern hardware tools, testing is often an afterthought with very little consideration given in advance to tools to meet DO-254 test objectives.

Quality does not inherently improve via testing; instead, quality is assessed via testing and then the hardware can be improved with proper test feedback mechanisms and confidence of process adequacy itself. Testing will be performed dozens, and potentially hundreds, of times on the same items over the many-years life of the hardware and covering many evolutions. And the best regression-test strategy is to retest as much of the hardware as possible, automatically. Thus, testing should be automated for all but the simplest of products.

Mistake #7: Lack of Path Coverage Capture During Functional Tests

Structural coverage (commonly denoted as “path coverage”) is required to an increasing degree for Level C, B, and A hardware. (Path coverage is not required for Level D, and no DO-254 process steps are required for Level E). However, path coverage is usually sought and obtained after the other forms of required DO-254 testing are achieved. This is extremely inefficient and unnecessary. Instead, the hardware environment and test suite should be considered in advance and path coverage obtained during black-box testing of requirements (e.g. “functional testing”).

Remember, DO-254 development and testing vary greatly per DO-254 DAL. The following figure from AFuzion’s DO-254 Training depicts the key DO-254 activity difference per Development Assurance Level (DAL):

Figure: Key DO-254 Activities per DAL (Criticality Level)

Mistake #6: Excessive Logic Iterations

It is normal for a new project to evolve hardware logic via multiple iterations. However, most projects greatly exceed any reasonable number of iterations because the hardware development is viewed as an iterative process instead of an engineering process. Hardware creation does not necessarily imply hardware engineering; however it should.

Excessive logic iterations result from one or more of the following deficiencies: insufficient requirement detail, insufficient hardware development standards, and insufficient checklists. DO-254 standards and checklists are available from a variety of sources. Perform a Google search on “DO-254” for more information.

A common gap in DO-254 for Complex Electronic Hardware (CEH) with embedded logic is weak logic reviews; a proper review must be shown to meet DO-254’s transition criteria, meaning the six required inputs to, for example, a logic review are all fully utilized for all logic reviews. Engineers (the “Reviewer”) must use all these review inputs which must be specified in the HVVP and then Process Assurance audits affirm that this process is followed by the verification engineer. (For more information on DO-254 Gap Analysis plus a one-minute video, see here: https://afuzion.com/gap-analysis/ ).

Remember, DO-254 traceability should be as shown in the following DO-254 Traceability Figure:

(For the remaining Top 5 Mistakes of DO-254 PDF, please download the remaining DO-254 PDF whitepaper).

AMC 20-152A is mandatory for DO-254 beginning 2021, which replaces AC 20-152, CAST-27 and EASA CM SWCEH-001. The following figure summarizes key deltas for A(M)C 20-152A as excerpted from AFuzion’s DO-254 Training and detailed in the complete whitepaper (download this whitepaper Do-254 PDF via the link below):

Figure: DO-254’s AMC 20-152A Synopsis:

For a brief introductory technical 1-hour instructional video on DO-254, view at the following link: https://www.youtube.com/watch?v=Xd_8YHKpWvQ (DO-254 Introduction Video Tutorial – 1 Hour)

DO-254 requires five DO-254 Plans, four DO-254 Standards, and 20+ DO-254 checklists. Most companies (over 150 companies and 9,000 engineers worldwide) use AFuzion’s DO-254 Planning templates, DO-254 standards templates, and DO-254 checklist templates described below. Once acquired from AFuzion and customized on the first project, your DO-254 project will retain the expertise to create, customize and re-use as appropriate on future DO-254 projects. Note that the DO-254 Planning documents (five documents) can be purchased in either Template form or “Initial Draft” form. The Template form option provides the basic templates which you then modify to create an initial draft. The Initial Draft option provides for AFuzion to first create initial drafts of all five planning documents using the same template, but adding the customer’s basic product information to create an initial draft; the customer then must finalize this initial draft to create the first versions of these five planning documents.

DO-254 Plans and Checklist Templates cover all phases of the system’s software project lifecycle and are developed with DO-254 in mind. The users of these templates would need to have some basic understanding of DO-178C, such as attendance at AFuzion DO-254 training (see here: https://afuzion.com/public-training-webinars-2/)

AFuzion’s DO-254 Process and Checklist Templates provide the basis for developing and certifying Hardware per the guidance of RTCA DO-254.

DO-254 requires planning documents and hardware lifecycle documents for requirements, design, implementation, and verification. Using DO-254 provided templates for these documents greatly eases their preparation and approval. For an added fee, AFuzion can even develop draft documents for planning your entire DO-254 certification effort.

DO-254 also requires reviews, audits and proof thereof. The best “proof” is detailed and complete checklists covering the primary hardware lifecycle activities and artifacts. Using AFuzion’s DO-178C and DO-254 provided checklists ensures that you have an appropriate framework for successfully developing and certifying your system.

Documenting DO-254 Compliance

Once acquired from AFuzion and customized on the first project, your DO-254 project will retain the expertise to create, customize and re-use as appropriate on future DO-254 projects. Note that the DO-254 Planning documents (five documents) can be purchased in either Template form or “Initial Draft” form.

The Template form option provides the basic templates which you then modify to create an initial draft. The Initial Draft option provides for AFuzion to first create initial drafts of all five planning documents using the same template, but adding the customer’s basic product information to create an initial draft; the customer then must finalize this initial draft to create the first versions of these five planning documents.

AFuzion’s DO-254 Plans and Checklist Templates cover all phases of the system’s Hardware project lifecycle, and are developed with DO-254 in mind. The users of these templates would need to have some basic understanding of DO-254, such as attendance at AFuzion DO-254 training or reading the Avionics Certification book principally written by AFuzion’s founder, Vance Hilderman.

These templates and checklists also help in getting organizations to the goal of higher SEI CMM/CMMI ratings (preferably Level 3 – 4+). Usage of AFuzion process templates and checklists are intended to maximize the probability of project success and quality.

The regulatory agencies require that most airborne commercial systems operating within commercial airspace comply with DO-178C and DO-254 (details can be found in the regulatory website). The planning and processes for systems lifecycle are required for any DO-178C and DO-254 project and those processes must be defined before initiating that phase and followed during that phase.

Although Checklists are not formally required by DO-178C and DO-254, your regulatory agencies will require that you prove conformance to DO-18C and DO-254 according to your approved processes; this conformance is very difficult to achieve and prove without checklists. In fact, nearly all DO-178C and DO-254 projects use checklists for reviews and proof of such.

AFuzion Process Templates are meant to provide the proper framework for customization to meet the system process requirements of DO-254. Although there is no perfect process for all programs, there are unique areas of each individual project. Each project will vary somewhat in how it chooses to define, implement, or augment the AFuzion process Templates. Factors to consider include project Design Assurance Levels, complexity, and expertise of staff, development methodology, tools/environment, and technology. The AFuzion process Templates provide the basic elements of an avionics project compliant with DO-178C and DO-254.

Further, AFuzion can customize and tailor these processes by the appropriate amount as an outflow of the gap analysis process, upon request as part of the optional first draft delivery. If there are items in the checklists that are not applicable to your program, they could simple be answered with “N/A”. It is also recommended that the checklists be placed under your project’s configuration management (CM) system to ensure checklist integrity.

Independent reviews are always preferable to reviews done by the developer. It should be noted that the checklists should be widely distributed to all personnel developing any avionics lifecycle item, prior to that person beginning such initiation. Thus, the checklist serves as a “report card” whereby the originator’s success is measured. When the originator understands what the independent verification reviewer will be evaluating the related hardware artifact for, the originator will more productively attain checklist compliance during development of that artifact. This applies to requirements, design, implementation, test, etc. The level of “independence for verification” required by DO-178C and DO-254 varies according to Design Assurance level (Level A through E).

DO-254 Plan & Checklist Templates Provided by AFuzion

Plan for Hardware Aspects of Certification Template
Hardware Process Assurance Plan Template
Hardware Configuration Management Plan Template
Hardware Development Plan Template
Hardware Verification & Validation Plan Template
Hardware Requirements Standards Template
Hardware Design Standards Template
Hardware VHDL Coding Standards Template
Hardware Verification & Validation Standards Template
Hardware Archive Standards Template
Hardware Configuration Index Environment Configuration Index
Hardware Electronic Component Management Plan Template
Hardware Accomplishment Summary Template

AFuzion’s DO-254 Checklist Templates

Plan for Hardware Aspects of Certification Checklist
Hardware Process Assurance Plan Checklist
Hardware Configuration Management Plan Checklist
Hardware Development Plan Checklist
Hardware Verification & Validation Plan Checklist
Hardware Development Standards Checklist
Computer Installation & Assembly Checklist
Hardware Configuration Index Checklist
Hardware Requirements Document Checklist
Hardware Design Document Checklist
Hardware Interface Control Data Checklist
Hardware Implementation Checklist
Hardware Test Cases & Procedures Checklist
Hardware Test Results Checklist
Hardware Verification Analysis Checklist
Hardware Traceability Checklist
Hardware Accomplishment Summary Checklist

Note: The above materials are best used by well-trained DO-254 engineers. AFuzion provides world-class DO-254 training and has trained more persons than all other trainers in the world combined. More info available here: https://afuzion.com/training/. In addition, AFuzion provides DO-254 Gap Analysis services, with over 170 DO-254 Gap Analysis provided to 135+ clients worldwide. More info here: https://afuzion.com/gap-analysis/.

Final Considerations

DO-254 was recently modified yet again by AMC 20-152A (also known as A(M)C 20-152A; this interim DO-254 update postpones the update to DO-254A for several more years. AMC 20-152A is the joint FAA / EASA harmonization to replace AC 20-152A, CAST-27, and the EASA SWCEH Certification Memos. AMC 20-152 clarifies numerous aspects of DO-254 as shown in the following figure extracted from AFuzion’s DO-254 / AMC 20-152A Training, titled “ Understanding AMC 20-152A”:

Figure Understanding AMC 20-152A (new for DO-254 in 2021-2022)

For a copy of AMC 20-152A pdf, simply email info@afuzion.com with “AMC 20-152A PDF” in the subject line. For AMC 20-152A training, see AFuzion’s DO-254 Training where AMC 20-152A is more fully discussed in detail; DO-254 / AMC 20-152A training details here: https://afuzion.com/public-training-webinars-2/

Via AMC 20-152A, there are new DO-254 related rules for SEH: Simple Electronics Hardware classification. (Download the full DO-254 Introduction paper via the link below for the full details). These new DO-254 SEH rules per AMC 20-152A are summarized in the following Figure:

AMC 20-152A: Assessing whether a device should be classified as simple:

Simplicity of the functions and their number,
Number of interfaces,
Simplicity of data/signal processing or transfer functions,
Independence of functions/blocks/stages.

Additional criteria specific to digital designs include:

Whether the design is synchronous or asynchronous,
The number of independent clocks,
The number of state machines, number of states, and state transitions per state machine,
The independence between the state machines.

Figure: AMC 20-152A Simple Electronic Hardware Classification

The advantages of Simple hardware per AMC 20-152A are numerous as summarized in the following slide extracted from AFuzion’s AMC 20-152A training:

Figure: Synopsis of Simple Devices per AMC 20-152A and DO-254

Figure: DO-254 Typical System FDAL Levels

Avionics hardware assessment to DO-254 has numerous potential flavors as depicted in the DO-254 Terminology figure below:

Figure: DO-254 Terminology – DO-254 Certification, Certifiability, Compliance & Qualification

To download the remaining 11+ pages of this technical DO-254 Introduction whitepaper, please download below:

DO-254 Intro, Compliance: Free Tools/ Papers / Resources