+------------+---------------------------------------------------------+
| ![](media/ | **Conducting**                                          |
| image1.png |                                                         |
| ){width="2 | **Airborne Electronic**                                 |
| .786805555 |                                                         |
| 5555555in" | **Hardware Reviews\                                     |
| heigh      | \                                                       |
| t="7.5in"} | Job Aid**                                               |
|            |                                                         |
| !          | **Aircraft Certification Service**                      |
| [](media/i |                                                         |
| mage2.jpeg | **Rev. - February 28, 2008**                            |
| ){width="1 |                                                         |
| .174305555 |                                                         |
| 5555555in" |                                                         |
| height="1. |                                                         |
| 0777777777 |                                                         |
| 777777in"} |                                                         |
+------------+---------------------------------------------------------+

######## Contents

[Acronyms 1](#acronyms)

[Part 1 -- Overview of the Airborne electronic Hardware Review
3](#part-1-overview-of-the-airborne-electronic-hardware-review)

[Purpose 3](#purpose)

[Job Aid Layout 5](#job-aid-layout)

[Determining Level of Involvement 13](#determining-level-of-involvement)

[The Review Team 13](#the-review-team)

[Part 2 -- Hardware Review Tasks 14](#part-2-hardware-review-tasks)

[Overview of Common Tasks 14](#overview-of-common-tasks)

[TASK 1: Preparing for the Hardware Review
16](#task-1-preparing-for-the-hardware-review)

[TASK 2: Performing the Hardware Review and Documenting Compliances,
Findings, and Observations
19](#task-2-performing-the-hardware-review-and-documenting-compliances-findings-and-observations)

[TASK 3: Preparing and Conducting Exit Briefing
22](#task-3-preparing-and-conducting-exit-briefing)

[TASK 4: Conducting Follow-up Activities
24](#task-4-conducting-follow-up-activities)

[Part 3 - Activities for Each Stage of Involvement
26](#part-3---activities-for-each-stage-of-involvement)

[3.1 Activities for Stage of Involvement #1 -- PLANNING REVIEW
27](#activities-for-stage-of-involvement-1-planning-review)

[Purpose 27](#purpose-1)

[When Review Occurs 27](#when-review-occurs)

[Data Reviewed Prior to Review 27](#data-reviewed-prior-to-review)

[Data Reviewed at Review 27](#data-reviewed-at-review)

[Number of Days Required 28](#number-of-days-required)

[Evaluation Activities and Questions
28](#evaluation-activities-and-questions)

[Instructions 28](#instructions)

[3.2 Activities for Stage of Involvement #2 -- DESIGN REVIEW
41](#activities-for-stage-of-involvement-2-design-review)

[Purpose 41](#purpose-2)

[When Review Occurs 41](#when-review-occurs-1)

[Data Reviewed Prior to [R]{.smallcaps}eview
41](#data-reviewed-prior-to-review-1)

[Data Reviewed at Review 41](#data-reviewed-at-review-1)

[Number of Days Required 41](#number-of-days-required-1)

[Evaluation Activities and Questions
42](#evaluation-activities-and-questions-1)

[Instructions 42](#instructions-1)

[3.3 Activities for Stage of Involvement #3 -- VALIDATION AND
VERIFICATION REVIEW
47](#activities-for-stage-of-involvement-3-validation-and-verification-review)

[Purpose 47](#purpose-3)

[When Review Occurs 47](#when-review-occurs-2)

[Data Reviewed Prior to Review 47](#data-reviewed-prior-to-review-2)

[Data Reviewed at Review 48](#data-reviewed-at-review-2)

[Number of Days Required 48](#number-of-days-required-2)

[Evaluation Activities and Questions
48](#evaluation-activities-and-questions-2)

[Instructions 48](#instructions-2)

[3.4 Activities for Stage of Involvement #4 -- FINAL REVIEW
55](#activities-for-stage-of-involvement-4-final-review)

[Purpose 55](#purpose-4)

[When to Perform 55](#when-to-perform)

[Data to Review Prior to the Review
55](#data-to-review-prior-to-the-review)

> [Data to Review at the Review 55](#data-to-review-at-the-review)
>
> [Number of Days 55](#number-of-days)
>
> [Evaluation Activities and Questions
> 56](#evaluation-activities-and-questions-3)
>
> [Instructions 56](#instructions-3)
>
> [Part 4 - Summarizing Compliances, Findings, and Observations for each
> DO-254 Objective
> 58](#part-4---summarizing-compliances-findings-and-observations-for-each-do-254-objective)
>
> [Appendix A -- Alternate Approach for Recording
> Compliances/Findings/Observation
> 65](#appendix-a-alternate-approach-for-recording-compliancesfindingsobservation)
>
> [Appendix B -- DO-254 Objectives Summary
> 66](#appendix-b-do-254-objectives-summary)
>
> [Appendix C -- Frequently Asked Questions
> 75](#appendix-c-frequently-asked-questions)

######## Tables

> [Table 1. Stakeholders in the Hardware Review Process
> 6](#__RefHeading___Toc191963517)
>
> [Table 2. On-Site/Desk Review Summary 9](#__RefHeading___Toc191963518)
>
> [Table 3. Delegation of Hardware Reviews
> 10](#__RefHeading___Toc191963519)
>
> [Table 4. Overview of Stages of Involvement
> 11](#__RefHeading___Toc191963520)
>
> [Table 5. SOI #1 Evaluation Activities
> 29](#__RefHeading___Toc191963521)
>
> [Table 6. SOI#2 Evaluation Activities
> 43](#__RefHeading___Toc191963522)
>
> [Table 7. SOI #3 Evaluation Activities
> 49](#__RefHeading___Toc191963523)
>
> [Table 8. SOI #4 Evaluation Activities
> 57](#__RefHeading___Toc191963524)
>
> [Table 9. Documenting Review Compliances/Findings/Observations (C/F/O)
> 59](#__RefHeading___Toc191963525)
>
> [Table A1. Alternate Method for Documenting Review
> Compliances/Findings/Observations 65](#__RefHeading___Toc191963526)
>
> [Table B1. Hardware Planning Process 66](#__RefHeading___Toc191963527)
>
> [Table B2. Hardware Design Process 68](#__RefHeading___Toc191963528)
>
> [Table B3. Validation and Verification Processes
> 71](#__RefHeading___Toc191963529)
>
> [Table B4. Configuration Management and Process Assurance Processes
> 73](#__RefHeading___Toc191963530)

# Acronyms

ACO Aircraft Certification Office

ASE Aviation Safety Engineer

ASE-HW Aviation Safety Engineer-Hardware

ASE-SW Aviation Safety Engineer-Software

ASI Aviation Safety Inspector

ASTC Amended Supplemental Type Certificate

ATC Amended Type Certificate

C/F/O Compliances/Findings/Observations

CEH Complex Electronic Hardware

CM Configuration Management

COTS Commercial Off-The-Shelf

CRI Certification Review Item

CSTA Chief Scientific and Technical Advisor

DAR Designated Airworthiness Representative

DER Designated Engineering Representative

DMIR Designated Manufacturing Inspection Representative

ENG Engineering

FAA Federal Aviation Administration

FFPA Functional Failure Path Analysis

HAS Hardware Accomplishment Summary

HC1 Hardware Control Category 1

HC2 Hardware Control Category 2

HCMP Hardware Configuration Management Plan

HDL Hardware Description Language

HDP Hardware Design Plan

HPAP Hardware Process Assurance Plan

HQ Headquarters

HVP Hardware Validation/Verification Plan

HW Hardware

I/O Input/Output

NA Not Applicable

PA Process Assurance

PA/CM Process Assurance/Configuration Management

PDH Previously Developed Hardware

PHAC Plan for Hardware Aspects of Certification

POC Point of Contact

PI Principal Inspector

RTCA RTCA, Inc. (formerly Radio Technical Commission for Aeronautics)

RTL Register Transfer Language (commercial brand name)

SEH Simple Electronic Hardware

SOI Stage of Involvement

SOIs Stages of Involvement

SSA System Safety Assessment

> STC Supplemental Type Certificate
>
> TC Type Certificate
>
> TS Technical Specialist
>
> TSOA Technical Standard Order Authorization

+-----------------+----------------------------------------------------+
| # P             |                                                    |
| art 1 -- Overvi |                                                    |
| ew of the Airbo |                                                    |
| rne electronic  |                                                    |
| Hardware Review |                                                    |
+-----------------+----------------------------------------------------+
| ### Purpose     | This Job Aid assists certification authorities,    |
|                 | designees (including organization delegations),    |
|                 | and applicants in performing airborne electronic   |
|                 | hardware reviews (which will be referred to as     |
|                 | "hardware reviews" for the remainder of this       |
|                 | document). The purpose of the hardware review is   |
|                 | to assess whether or not the airborne electronic   |
|                 | hardware complies with airworthiness requirements  |
|                 | and the proposed means of compliance (i.e.,        |
|                 | RTCA/DO-254).                                      |
|                 |                                                    |
|                 | This Job Aid should be used as a reference tool    |
|                 | during the review process. It is **not** intended  |
|                 | to be used as a checklist and is **not** all       |
|                 | inclusive of all possible situations that need to  |
|                 | be reviewed. Nor is the Job Aid intended to        |
|                 | replace DO-254. Rather, it should be used in       |
|                 | conjunction with DO-254. Likewise, this Job Aid    |
|                 | may include questions that are not appropriate for |
|                 | the specific project being evaluated. Reviewers    |
|                 | should keep in mind that each project has some     |
|                 | unique characteristics and should use the Job Aid  |
|                 | as it best fits the specific situation. This Job   |
|                 | Aid only addresses the hardware review prior to    |
|                 | certification/authorization for the following      |
|                 | processes: Type Certificate (TC), Supplemental     |
|                 | Type Certificate (STC), Amended Type Certificate   |
|                 | (ATC), Amended STC (ASTC) or Technical Standard    |
|                 | Order Authorization (TSOA).                        |
|                 |                                                    |
|                 | Additionally, this Job Aid includes review         |
|                 | questions where the connection between these       |
|                 | questions and the referenced DO-254 objectives may |
|                 | not be immediately obvious. However, these types   |
|                 | of questions may be instrumental in helping a      |
|                 | reviewer determine compliance for the hardware in  |
|                 | the context of the system in which that hardware   |
|                 | resides.                                           |
|                 |                                                    |
|                 | Examples of issues that these questions may        |
|                 | address include:                                   |
|                 |                                                    |
|                 | -   Concerns regarding the use of the hardware as  |
|                 |     part of the overall system, e.g., whether the  |
|                 |     system still meets the requirements of the     |
|                 |     system safety assessment due to derived        |
|                 |     hardware requirements.                         |
|                 |                                                    |
|                 | -   Compliance of the hardware and the processes   |
|                 |     used to develop and verify that hardware to    |
|                 |     FAA policy, issue papers, and non-U.S.         |
|                 |     certification authorities' position papers.    |
|                 |                                                    |
|                 | -   Integration issues, such as board level        |
|                 |     integration and hardware/software integration  |
|                 |     concerns.                                      |
|                 |                                                    |
|                 | For example, integration testing is a primary      |
|                 | concern when that level of testing is used to show |
|                 | compliance to DO-254 for individual hardware       |
|                 | components. Hardware/software integration testing  |
|                 | is important, as many of the individual complex    |
|                 | hardware components may have been developed to     |
|                 | perform functions traditionally performed in       |
|                 | software run on the main system processor.         |
|                 | Examples of this include complex input/output      |
|                 | functions, monitoring and safety protections, such |
|                 | as a memory management unit. Thus, the hardware    |
|                 | being reviewed may be very tightly coupled to the  |
|                 | software design. Additionally, the reviewer will   |
|                 | need to be aware of any applicable policy when     |
|                 | reviewing any hardware project, including that     |
|                 | from non-U.S. certification authorities, such as   |
|                 | EASA. The FAA may be finding compliance for a      |
|                 | non-U.S. certification authority, and therefore    |
|                 | will need to be aware of the policy and position   |
|                 | papers that apply.                                 |
|                 |                                                    |
|                 | For the purposes of this Job Aid, **Compliance**,  |
|                 | **Finding**, and **Observation** are defined as    |
|                 | follows:                                           |
|                 |                                                    |
|                 | -   A **Compliance** is the satisfaction of a      |
|                 |     DO-254 objective (and the related guidance     |
|                 |     contained in the text of DO-254);              |
|                 |                                                    |
|                 | -   A **Finding** is identification of             |
|                 |     non-compliance to a DO-254 objective (and the  |
|                 |     related guidance contained in the text of      |
|                 |     DO-254);                                       |
|                 |                                                    |
|                 | -   An **Observation** is identification of a      |
|                 |     potential process improvement.                 |
+-----------------+----------------------------------------------------+
| ###             |                                                    |
+-----------------+----------------------------------------------------+
|                 | The Job Aid will assist the hardware reviewer to   |
|                 | do the following:                                  |
|                 |                                                    |
|                 | Perform tasks associated with conducting a         |
|                 | hardware review.                                   |
|                 |                                                    |
|                 | Document Compliances, Findings and Observations.   |
|                 |                                                    |
|                 | Link review Compliances, Findings and Observations |
|                 | to DO-254 objectives.                              |
+-----------------+----------------------------------------------------+
| ###             | This Job Aid addresses:                            |
|  Job Aid Layout |                                                    |
|                 | -   Tasks to be performed before, during, and      |
|                 |     after a hardware review (Part 2).              |
|                 |                                                    |
|                 | -   Activities and questions to be considered      |
|                 |     during a review (Part 3).                      |
|                 |                                                    |
|                 | -   An approach to the Findings and Observations   |
|                 |     to DO-254 objectives (Part 4).                 |
+-----------------+----------------------------------------------------+
| Stakeholders in | Below is a high-level description of the role of   |
| the Hardware    | the key players/ stakeholders in the hardware      |
| Review Process  | review process.                                    |
+-----------------+----------------------------------------------------+

[]{#__RefHeading___Toc191963517 .anchor}Table 1. Stakeholders in the
Hardware Review Process

+------------------+---------------------------------------------------+
| **Stakeholders** | **Primary Role in Hardware Review**               |
+==================+===================================================+
| Aviation Safety  | Responsible for the hardware approval on the      |
| Engineer         | project being reviewed.                           |
| Hardware         |                                                   |
| (ASE-HW)         | Serves as the review team leader and is           |
|                  | responsible for coordination,                     |
|                  |                                                   |
|                  | scheduling and other review activities.           |
|                  |                                                   |
|                  | Reviews the technical aspects of the hardware     |
|                  | design process.                                   |
+------------------+---------------------------------------------------+
| Aviation Safety  | Works in propulsion, avionics/electrical systems, |
| Engineer (ASE)   | or mechanical systems with responsibility for     |
|                  | approval of the overall system whose hardware is  |
|                  | being reviewed.                                   |
|                  |                                                   |
|                  | May not have hardware expertise, but is familiar  |
|                  | with the system requirements, safety aspects, and |
|                  | system performance expectations.                  |
|                  |                                                   |
|                  | -   May accompany the hardware review team to     |
|                  |     provide a tie to the systems aspects of the   |
|                  |     project and to review requirements.           |
|                  |                                                   |
|                  | -   Needs to be informed of status on hardware,   |
|                  |     software, and safety issues.                  |
+------------------+---------------------------------------------------+
| Aviation Safety  | Responsible for, or involved in, the software     |
| Engineer         | approval on the project being reviewed.           |
| Software         |                                                   |
| (ASE-SW)         | Understands the issues regarding hardware to      |
|                  | software integration.                             |
|                  |                                                   |
|                  | May accompany the hardware review team to provide |
|                  | a tie to the software aspects of the project and  |
|                  | to review requirements.                           |
+------------------+---------------------------------------------------+
| Aviation Safety  | Principal inspector for the applicant being       |
| Inspector (ASI)  | evaluated.                                        |
|                  |                                                   |
|                  | Performs conformity inspections on the hardware.  |
+------------------+---------------------------------------------------+

+------------------+---------------------------------------------------+
| Flight Test      | Evaluates the aircraft or the system installed on |
| Engineer/Pilot   | the aircraft by performing system demonstrations, |
|                  | simulations, and aircraft ground and flight       |
|                  | tests.                                            |
|                  |                                                   |
|                  | -   Evaluates the system performance on the       |
|                  |     aircraft and identifies any safety,           |
|                  |     operational, or performance concerns.         |
|                  |                                                   |
|                  |     Needs to be informed of status on hardware    |
|                  |     issues.                                       |
+------------------+---------------------------------------------------+
| Chief Scientific | Serves as a technical consultant on novel or      |
| & Technical      | unique projects that require expert review and    |
| Advisor (CSTA)   | input, as needed.                                 |
+------------------+---------------------------------------------------+
| Technical        | Serves as a technical expert and a resource for   |
| Specialist (TS)  | the ASE-HW and ASI-HW during the hardware review  |
|                  | process.                                          |
|                  |                                                   |
|                  | May serve as a link between the ASE-HW and the    |
|                  | CSTA.                                             |
+------------------+---------------------------------------------------+
| Project Manager  | Responsible for schedule and oversight of the     |
|                  | overall project.                                  |
+------------------+---------------------------------------------------+
| Directorate      | Involved in any situations that could affect      |
| Hardware         | Directorate policy, issue papers or special       |
| Personnel        | conditions for novel technology.                  |
|                  |                                                   |
|                  | Provides technical expertise, when needed.        |
+------------------+---------------------------------------------------+
| Headquarters     | Involved in projects that require changes or      |
| (HQ) Hardware    | additions to national hardware policy.            |
| Personnel        |                                                   |
|                  | Serve as technical experts during the hardware    |
|                  | review, as needed.                                |
+------------------+---------------------------------------------------+
| Designated       | Works on behalf of the FAA to review hardware     |
| Engineering      | projects.                                         |
| Representative   |                                                   |
| (DER)            | Acts as part of the review team.                  |
|                  |                                                   |
|                  | Often performs review prior to the FAA review to  |
|                  | make preliminary compliance findings and to       |
|                  | resolve any issues.                               |
+------------------+---------------------------------------------------+
| Designated       | Works on behalf of the FAA to perform hardware    |
| Manufacturing    | conformities.                                     |
| Inspection       |                                                   |
| Representative   |                                                   |
| (DMIR),          |                                                   |
| Designated       |                                                   |
| Airwothiness     |                                                   |
| Representative   |                                                   |
| (DARs)           |                                                   |
+------------------+---------------------------------------------------+

+------------------+---------------------------------------------------+
| Applicant        | Applies for Type Certificate, Supplemental Type   |
|                  | Certificate, Amended Type Certificate, Amended    |
|                  | Supplemental Type Certificate or Technical        |
|                  | Standard Order Authorization.                     |
|                  |                                                   |
|                  | Responsible for the hardware compliance. May or   |
|                  | may not be the hardware developer.                |
|                  |                                                   |
|                  | Oversees hardware developer, if applicable.       |
|                  |                                                   |
|                  | Attends on-site hardware review. **Note**: If the |
|                  | applicant is not the hardware developer, the      |
|                  | applicant's hardware Process Assurance (PA) and   |
|                  | hardware Configuration Management (CM) personnel, |
|                  | systems engineer, and other team members should   |
|                  | be present at on-site reviews.                    |
+------------------+---------------------------------------------------+
| Hardware         | -   Includes applicant and/or developer of the    |
| Developer        |     hardware to be installed on an aircraft. (May |
|                  |     be supplier to applicant.)                    |
|                  |                                                   |
|                  | -   Members of hardware developer team include:   |
|                  |     hardware program manager, hardware engineers, |
|                  |     hardware designers, hardware PA personnel,    |
|                  |     hardware CM personnel, etc.                   |
+------------------+---------------------------------------------------+
|                  |                                                   |
+------------------+---------------------------------------------------+
| Review Types     | There are two types of reviews used to determine  |
|                  | if an applicant's hardware design complies with   |
|                  | DO-254 objectives: (1) on-site review and (2)     |
|                  | desk review. Applicants or developers may also    |
|                  | perform self-assessment reviews (for example,     |
|                  | through their hardware PA organization). The      |
|                  | table below provides a brief description of each  |
|                  | type of review, when each type is appropriate,    |
|                  | and the advantages/disadvantages of each. This    |
|                  | Job Aid addresses both the on-site and desk       |
|                  | reviews.                                          |
+------------------+---------------------------------------------------+

[]{#__RefHeading___Toc191963518 .anchor}Table 2. On-Site/Desk Review
Summary

+---------------------+-----------------------+------------------------+
| *                   | **When Appropriate**  | **Advantages/\         |
| *Type/Description** |                       | Disadvantages**        |
+---------------------+-----------------------+------------------------+
| **On-Site Review:** | Highly critical       | **Advantages:**        |
|                     | systems.              |                        |
| Review appropriate  |                       | Access to development  |
| phases of the       | New system being      | personnel.             |
| hardware design     | developed.            |                        |
| process.            |                       | More in-depth review.  |
|                     | First-time applicants |                        |
| -   Conducted by    | or first-time users   | Higher confidence in   |
|     team at the     | of DO-254.            | safety aspects.        |
|     hardware        |                       |                        |
|     developer's     | Applicant             | Complete access to     |
|     facility.       | inexperienced in      | data.                  |
|     (**Note:**      | developing and/or     |                        |
|     Applicant's     | overseeing hardware.  | Helps perform designee |
|     designees       |                       | performance            |
|     should be       | Applicants with       | evaluation.            |
|     present).       | history of poor       |                        |
|                     | design processes.     | **Disadvantages:**     |
|                     |                       |                        |
|                     | New/unique hardware,  | Budget and time        |
|                     | design, verification  | considerations.        |
|                     | and/or manufacturing  |                        |
|                     | concepts.             |                        |
|                     |                       |                        |
|                     | When a system         |                        |
|                     | demonstrates multiple |                        |
|                     | problems during       |                        |
|                     | systems and           |                        |
|                     | flight-testing.       |                        |
|                     |                       |                        |
|                     | Major changes in the  |                        |
|                     | environment (e.g.,    |                        |
|                     | personnel, tools,     |                        |
|                     | methods).             |                        |
|                     |                       |                        |
|                     | -   At request of     |                        |
|                     |     designee.         |                        |
|                     |                       |                        |
|                     | -   FAA oversight of  |                        |
|                     |     a designee is     |                        |
|                     |     needed.           |                        |
+---------------------+-----------------------+------------------------+
| **Desk Review:**    | Changes to current    | **Advantages:**        |
|                     | FAA-approved          |                        |
| Review appropriate  | hardware.             | Not as disruptive to   |
| life cycle data.    |                       | the hardware           |
|                     | Less critical         | developer's schedule.  |
| Conducted by team   | systems.              |                        |
| at FAA or           |                       | -   Budget and time    |
| applicant's         | Experienced companies |     considerations     |
| facility.           | with a good history.  |                        |
|                     |                       | **Disadvantages:**     |
| -   Little or no    |                       |                        |
|     involvement by  |                       | Many companies do not  |
|     the hardware    |                       | allow data to be       |
|     developer.      |                       | viewed without their   |
|                     |                       | presence.              |
|                     |                       |                        |
|                     |                       | Cannot ask direct      |
|                     |                       | questions\             |
|                     |                       | of hardware            |
|                     |                       | developers.            |
|                     |                       |                        |
|                     |                       | May require large      |
|                     |                       | shipment of data.      |
|                     |                       |                        |
|                     |                       | -   May postpone       |
|                     |                       |     closure of         |
|                     |                       |     questions and      |
|                     |                       |     issues due to      |
|                     |                       |     remote             |
|                     |                       |     communication.     |
+---------------------+-----------------------+------------------------+

The use of designees for hardware reviews is encouraged, when
appropriate. Table 3 outlines when the delegation of a review is
appropriate and some of the advantages/disadvantages of delegation.

[]{#__RefHeading___Toc191963519 .anchor}Table 3. Delegation of Hardware
Reviews

+----------------------------------+-----------------------------------+
| **When Appropriate**             | **Advantages/Disadvantages**      |
+----------------------------------+-----------------------------------+
| Demonstrated good proven "track  | **Advantages:**                   |
| record" with proper              |                                   |
| authorization.                   | -   May be familiar with          |
|                                  |     applicant's processes and     |
| For all systems **without**      |     data organization.            |
| unique hardware characteristics. |                                   |
|                                  | -   Can spend more time on-site   |
| When there are no issues that    |     and can monitor the processes |
| have policy implications         |     throughout the design.        |
| (Directorate or Headquarters).   |                                   |
|                                  | -   May be able to support        |
|                                  |     schedule better than FAA      |
|                                  |     employees.                    |
|                                  |                                   |
|                                  | **Disadvantages:**                |
|                                  |                                   |
|                                  | May have company bias.            |
|                                  |                                   |
|                                  | May be pressured to "cut corners" |
|                                  | when schedules are slipping.      |
+----------------------------------+-----------------------------------+

The hardware review may be used for the evaluation and subsequent
approval of hardware data within the TC, ATC, STC, ASTC and TSO
processes.

The purpose of the hardware review is to assess whether or not the
airborne electronic hardware complies with airworthiness requirements
and the proposed means of compliance (assumed to be RTCA/DO-254). To
assess compliance, there are typically four Stages of FAA Involvement
throughout the hardware life cycle of a project. The four Stages of
Involvement (SOIs) are listed below and overviewed in Table 4:

1.  Planning review;

2.  Design review;

3.  Validation and Verification review

4.  Final review.

For each Stage of Involvement (SOI) the following information is
provided: a brief description of the SOI, required data, related DO-254
objectives used as evaluation criteria, and related Job Aid Sections.

Reviews may be combined or delegated to an authorized designee, as the
project requires. If the FAA elects not to perform four reviews, it is
strongly encouraged that designees perform on-site reviews and/or the
applicant conducts internal compliance reviews using the approach
outlined in this Job Aid.

For some projects, more than four reviews may be warranted. For example,
more than four reviews may be appropriate for a large project with many
sub-systems or a project with many problems.

[]{#__RefHeading___Toc191963520 .anchor}Table 4. Overview of Stages of
Involvement

+----------+---------------+---------------------+---------+---------+
| **Stage  | **            | **Data Required**   | **      | **      |
| of       | Description** |                     | Related | Related |
| Invol    |               |                     | DO-254  | Job Aid |
| vement** |               |                     | Obj     | Se      |
|          |               |                     | ectives | ction** |
|          |               |                     | refe    |         |
|          |               |                     | rence** |         |
+==========+===============+=====================+=========+=========+
| 1        | **Planning    | Plan for Hardware   | 4.1(1)  | Section |
|          | review**      | Aspects of          |         | 3.1 -   |
|          |               | Certification       | 4.1(2)  | Act     |
|          | Assure plans  | (PHAC)              |         | ivities |
|          | meet DO-254   |                     | 4.1(3)  | for SOI |
|          | objectives.   | Hardware            |         | #1      |
|          |               | Validation/         | 4.1(4)  |         |
|          | Assure that   | Verification Plan   |         |         |
|          | the processes | (HVP)               |         |         |
|          | described in  |                     |         |         |
|          | the           | Hardware Design     |         |         |
|          | applicant's   | Plan (HDP)          |         |         |
|          | plans meet    |                     |         |         |
|          | the           | Hardware            |         |         |
|          | objectives of | Configuration       |         |         |
|          | DO-254.       | Management Plan     |         |         |
|          |               | (HCMP)              |         |         |
|          | Obtain        |                     |         |         |
|          | agreement     | Hardware Process    |         |         |
|          | between FAA   | Assurance Plan      |         |         |
|          | and applicant | (HPAP)              |         |         |
|          | on the plans. |                     |         |         |
|          |               | Hardware Design     |         |         |
|          |               | Standards           |         |         |
|          |               |                     |         |         |
|          |               | Safety assessment   |         |         |
+----------+---------------+---------------------+---------+---------+
| 2        | **Design      | Hardware Design     | 5       | Section |
|          | review**      | Standards           | .1.1(1) | 3.2 -   |
|          |               |                     |         | Act     |
|          | Assess        | Hardware            | 5       | ivities |
|          | i             | Requirements        | .1.1(2) | for SOI |
|          | mplementation |                     |         | #2      |
|          | of plans and  | Hardware Design     | 5       |         |
|          | standards in  | Description         | .1.1(3) |         |
|          | the hardware  | (**Note:** Hardware |         |         |
|          | life cycle    | Design Description  | 5       |         |
|          | data.         | refers to data      | .2.1(1) |         |
|          |               | described in        |         |         |
|          | Assess and    | DO-254, section     | 5       |         |
|          | agree to plan | 10.3.2 and          | .2.1(2) |         |
|          | changes.      | subsections,        |         |         |
|          |               | particularly        | 5       |         |
|          | Assure life   | section 10.3.2.1.)  | .2.1(3) |         |
|          | cycle data    |                     |         |         |
|          | meets DO-254  | Detailed Design     | 5       |         |
|          | objectives.   | Data (e.g., HDL,    | .3.1(1) |         |
|          |               | schematics)         |         |         |
|          |               |                     | 5       |         |
|          |               | Problem Reports     | .3.1(2) |         |
|          |               |                     |         |         |
|          |               | Hardware            | 5       |         |
|          |               | Configuration       | .3.1(3) |         |
|          |               | Management Records  |         |         |
|          |               |                     | 5       |         |
|          |               | Hardware Process    | .4.1(1) |         |
|          |               | Assurance Records   |         |         |
|          |               |                     | 5       |         |
|          |               |                     | .4.1(2) |         |
|          |               |                     |         |         |
|          |               |                     | 5       |         |
|          |               |                     | .4.1(3) |         |
|          |               |                     |         |         |
|          |               |                     | 5       |         |
|          |               |                     | .4.1(4) |         |
|          |               |                     |         |         |
|          |               |                     | 5       |         |
|          |               |                     | .5.1(1) |         |
|          |               |                     |         |         |
|          |               |                     | 5       |         |
|          |               |                     | .5.1(2) |         |
|          |               |                     |         |         |
|          |               |                     | 5       |         |
|          |               |                     | .5.1(3) |         |
|          |               |                     |         |         |
|          |               |                     | 5       |         |
|          |               |                     | .5.1(4) |         |
|          |               |                     |         |         |
|          |               |                     | 7.1(1)  |         |
|          |               |                     |         |         |
|          |               |                     | 7.1(2)  |         |
|          |               |                     |         |         |
|          |               |                     | 7.1(3)  |         |
|          |               |                     |         |         |
|          |               |                     | 8.1(1)  |         |
|          |               |                     |         |         |
|          |               |                     | 8.1(2)  |         |
|          |               |                     |         |         |
|          |               |                     | 8.1(3)  |         |
+----------+---------------+---------------------+---------+---------+
| 3        | **Validation  | Hardware            | 6       | Section |
|          | and           | Requirements        | .1.1(1) | 3.3 -   |
|          | Verification  |                     |         | Act     |
|          | review**      | Hardware Design     | 6       | ivities |
|          |               | Description         | .1.1(2) | for SOI |
|          | Assess        |                     |         | #3      |
|          | i             | Detailed Design     | 6       |         |
|          | mplementation | Data (e.g., HDL,    | .1.1(3) |         |
|          | of            | schematics)         |         |         |
|          | verification  |                     | 6       |         |
|          | and test      | Hardware            | .2.1(1) |         |
|          | plans and     | Verification Cases  |         |         |
|          | procedures.   | and Procedures      | 6       |         |
|          |               | (**Note:** Hardware | .2.1(2) |         |
|          | Check         | Verification Cases  |         |         |
|          | completion of | and Procedures      | 6       |         |
|          | all           | refer to data       | .2.1(3) |         |
|          | associated CM | described in        |         |         |
|          | and Process   | Do-254, sections    | 6       |         |
|          | Assurance     | 10.4.2 and 10.4.4.) | .2.1(4) |         |
|          | tasks.        |                     |         |         |
|          |               | Hardware            | 7.1(1)  |         |
|          | Ensure        | Verification        |         |         |
|          | hardware      | Results (**Note**:  | 7.1(2)  |         |
|          | requirements  | Hardware            |         |         |
|          | are verified. | Verification        | 7.1(3)  |         |
|          |               | Results refer to    |         |         |
|          | Ensure        | data described in   | 8.1(1)  |         |
|          | validation    | Do-254, sections    |         |         |
|          | and           | 10.4.3 and 10.4.5.) | 8.1(2)  |         |
|          | verification  |                     |         |         |
|          | activity      | Problem Reports     | 8.1(3)  |         |
|          | satisfied     |                     |         |         |
|          | requirements  | Hardware            |         |         |
|          | in DO-254.    | Configuration       |         |         |
|          |               | Records             |         |         |
|          |               |                     |         |         |
|          |               | Hardware Process    |         |         |
|          |               | Assurance Records   |         |         |
|          |               |                     |         |         |
|          |               | Hardware Conformity |         |         |
|          |               | Records             |         |         |
+----------+---------------+---------------------+---------+---------+
| 4        | **Final       | Hardware Life Cycle | All     | Section |
|          | review**      | Environment         |         | 3.4 -   |
|          |               | Configuration       |         | Act     |
|          | Assures final | documentation       |         | ivities |
|          | hardware      |                     |         | for SOI |
|          | product meets | Hardware            |         | #4      |
|          | DO-254        | Configuration       |         |         |
|          | objectives    | documentation       |         |         |
|          | and is ready  |                     |         |         |
|          | for           | Problem Reports     |         |         |
|          | c             |                     |         |         |
|          | ertification. | Hardware            |         |         |
|          |               | Accomplish-ment     |         |         |
|          | Address any   | Summary (HAS)       |         |         |
|          | open items.   |                     |         |         |
+----------+---------------+---------------------+---------+---------+

+------------------+---------------------------------------------------+
| ###              | As early as possible in the project, the FAA      |
|                  | should estimate the required level of             |
| ###              | involvement. The process for determining and      |
| Determining Leve | documenting the FAA level of involvement is       |
| l of Involvement | described in Chapter 3 of Order 8110.CEH\*. Early |
|                  | in the project, the FAA should evaluate such      |
|                  | things as: the applicant's experience, the        |
|                  | history of the applicant, the quantity and        |
|                  | experience of designee support, the novelty/      |
|                  | uniqueness of the project, and the project        |
|                  | criticality. Based on this early evaluation, the  |
|                  | FAA will determine if the level of involvement is |
|                  | high, medium, or low. The level of FAA            |
|                  | involvement will dictate the number of hardware   |
|                  | reviews, the stages of involvement, and the       |
|                  | nature of the review (i.e., desk or on-site).     |
|                  |                                                   |
|                  | For example, for a highly critical system being   |
|                  | developed by a company who has never used DO-254, |
|                  | the level of FAA involvement would likely be high |
|                  | and on-site hardware reviews would be performed   |
|                  | at all Stages of Involvement.                     |
|                  |                                                   |
|                  | The FAA's involvement should be determined and    |
|                  | documented as early as possible in the project.   |
|                  |                                                   |
|                  | \*Order 8110.CEH will cover aspects of both       |
|                  | Complex and Simple Custom Micro-Coded Devices,    |
|                  | also referred to as CEH (Complex Electronic       |
|                  | Hardware devices) and SEH (Simple Electronic      |
|                  | Hardware devices). This Order has not been        |
|                  | published at the time of initial publication of   |
|                  | this Job Aid, and therefore cannot be referred to |
|                  | by a specific Order number or title.              |
+------------------+---------------------------------------------------+

+------------------+---------------------------------------------------+
| ###              | It is recommended that reviews be performed using |
|  The Review Team | a team of two to four people. A team can          |
|                  | typically perform a higher quality review than an |
|                  | individual and can reduce the amount of time      |
|                  | required to perform the review. The review team   |
|                  | will typically divide responsibilities. Depending |
|                  | on the size of the team, there should be at least |
|                  | one team member that will focus on design and/or  |
|                  | validation/verification data, and another team    |
|                  | member that will focus on process assurance and   |
|                  | configuration management processes. In addition   |
|                  | to the hardware engineers, there may be one or    |
|                  | more non-hardware engineers (e.g., software       |
|                  | engineers, systems specialists) as part of the    |
|                  | team to oversee the systems, safety, and          |
|                  | application aspects of the project. Throughout    |
|                  | this Job Aid, the areas of responsibility will be |
|                  | highlighted. Additional team members may be a     |
|                  | Chief Scientific and Technical Advisor, Technical |
|                  | Specialist, Directorate personnel, Headquarters   |
|                  | personnel, or international certification         |
|                  | authorities, as required or as available.         |
+------------------+---------------------------------------------------+

+-----------------------------------------------------------------------+
| # Part 2 -- Hardware Review Tasks                                     |
+-----------------------------------------------------------------------+

+------------------+---------------------------------------------------+
| ### Overview     | Regardless of the Stage(s) of Involvement for the |
|  of Common Tasks | hardware review, the following four tasks will be |
|                  | done for each review:                             |
|                  |                                                   |
|                  | 1.  Preparing for the review;                     |
|                  |                                                   |
|                  | 2.  Performing the review (referencing the        |
|                  |     appropriate Job Aid tables and documenting    |
|                  |     the review findings and observations);        |
|                  |                                                   |
|                  | 3.  Preparing and delivering an exit briefing of  |
|                  |     the review; and                               |
|                  |                                                   |
|                  | 4.  Conducting follow-up activities (e.g.,        |
|                  |     prepare a report, assess if another review is |
|                  |     required or if final compliance has been      |
|                  |     demonstrated).                                |
|                  |                                                   |
|                  | The following pages give a detailed description   |
|                  | of the four tasks performed by the review team in |
|                  | conducting a hardware review. The person(s)       |
|                  | responsible for each task is listed next to the   |
|                  | task. The "team leader" is the ASE-HW or designee |
|                  | responsible for leading the review. The "team" is |
|                  | typically comprised of ASE-HWs, designees, and    |
|                  | others, as needed.                                |
|                  |                                                   |
|                  | Once the SOI has been established, refer to the   |
|                  | appropriate Activities/Questions for Stage of     |
|                  | Involvement in Part 3. The Part 3 tables provide  |
|                  | guidance as to what kinds of questions to ask to  |
|                  | ensure that the DO-254 objectives are met. If     |
|                  | there is more than one SOI combined in a review,  |
|                  | more than one set of tables will be referenced    |
|                  | (e.g., if the reviews combine SOI #1 and SOI #2,  |
|                  | tables for both SOIs would be used).              |
|                  |                                                   |
|                  | The table in Part 4 of this Job Aid shows a       |
|                  | method of capturing the results of a hardware     |
|                  | review and allows the review team to record a     |
|                  | Compliance, Finding or Observation for each       |
|                  | DO-254 objective. There are several things to     |
|                  | keep in mind when answering the questions of the  |
|                  | tables in Part 3 and filling out the table in     |
|                  | Part 4. The review team must be very clear and    |
|                  | meticulous when documenting a Finding of          |
|                  | non-compliance to a DO-254 objective. The Finding |
|                  | must be able to be documented in such as way that |
|                  | **clearly identifies which DO-254 objective the   |
|                  | non-compliance is against and why the item in     |
|                  | non-compliant**. This will assist the hardware    |
|                  | developer and/or applicant in understanding       |
|                  | exactly what needs to be corrected in order to    |
|                  | bring the item into compliance.                   |
+------------------+---------------------------------------------------+
| ###              | An answer of "no" to any particular question      |
|                  | listed in a Part 3 table does not automatically   |
|                  | mean that an item is non-compliant. For example,  |
|                  | a question such as "Is each test case and         |
|                  | procedure appropriately commented?" should not,   |
|                  | in most cases, result in a Finding of             |
|                  | non-compliance to DO-254 objectives. At most, a   |
|                  | "No" answer to that question should be an         |
|                  | Observation. Each question in the Part 3 tables,  |
|                  | and the answer to each question, must be assessed |
|                  | in the overall context and scope of the review    |
|                  | before deciding upon the classification of the    |
|                  | answer. Because compliance to DO-254 is one       |
|                  | acceptable means of showing compliance to the     |
|                  | regulations, a Finding of non-compliance to       |
|                  | DO-254, by extension, means non-compliance to     |
|                  | those CFR paragraphs. Care must be taken to avoid |
|                  | unnecessary disagreements between the hardware    |
|                  | review team and the company being reviewed about  |
|                  | Findings of non-compliance.                       |
|                  |                                                   |
|                  | Whatever documentation method is chosen, remember |
|                  | certification is determined based on evidence of  |
|                  | compliance. Be clear that you show evidence of    |
|                  | correct implementation of the guidance and not    |
|                  | only evidence of non-compliances that were fixed. |
|                  | Documentation should be thorough enough such that |
|                  | compliance activities can be repeated, if         |
|                  | necessary, in support of the result.              |
+------------------+---------------------------------------------------+
| ###              | The Tasks and Activities/Questions outlined       |
|                  | emphasize the on-site hardware review. However,   |
|                  | the same types of activities are appropriate for  |
|                  | a desk review. The desk review would require a    |
|                  | different type of notification letter and access  |
|                  | to the applicant's personnel might be limited to  |
|                  | telephone calls. But the remainder of the         |
|                  | activities is very similar. Places where the desk |
|                  | review differs from the on-site review are        |
|                  | highlighted at the end of each task.              |
+------------------+---------------------------------------------------+

###  [TASK 1: Preparing for the Hardware Review]{.underline}

The purpose of this task is to prepare for the hardware review by
assembling the review team, notifying the applicant of the review,
coordinating delivery of materials, and preparing all team members for
the hardware review.

#### Step 1: Coordinate with the certification team (Team Leader)

1.1 Inform the project manager of the plans to conduct a hardware review
and discuss all concerns (e.g., issue papers, project impact).

1.2 Coordinate with and obtain necessary information from ASEs and
Flight Test certification team members. **Note**: It may be beneficial
to have systems and software ASEs on the hardware review team.

1.3 Inform Principal Inspector of intentions and coordinate any
concerns.

1.4 If the hardware review is to be performed at a hardware developer's
facility located in another cognizant Aircraft Certification Office's
(ACO) area of responsibility, contact the appropriate ACO engineer for
coordination. The other ACO engineer(s) may desire to be part of the
review team in order to carry out routine oversight roles.

1.5 Address any non-US certification concerns with the FAA certification
team and the international certification team, if appropriate.

#### Step 2: Organize the review team (team leader)

2.1 Determine the members of the review team, based on project needs.

-   Team should consist of at least one engineering team member (ENG)
    and one process assurance/configuration management (PA/CM) team
    member.

-   Designees assigned to the project should be involved as part of the
    review team.

-   Aviation Safety Engineer (ASE), Principal Inspector (PI), Chief
    Scientific and Technical Advisor (CSTA), Technical Specialist (TS),
    Directorate software personnel, or Headquarters (HQ) software
    personnel may be part of the team, as needed.

    2.2 Coordinate a date for the review with the applicant and team
    members.

#### Step 3: send a notification letter to the applicant at least one month prior to the review (Team Leader) {#step-3-send-a-notification-letter-to-the-applicant-at-least-one-month-prior-to-the-review-team-leader .unnumbered}

3.1 The notification letter should inform the applicant of the: (1)
purpose of the review;\
(2) proposed agenda; (3) data to be reviewed during the review; and (4)
data to be sent to the review team members prior to the review.

-   If the review combines Stages of Involvement, the contents of the
    agendas may be combined.

#### Step 4: Coordinate with review team members (team leader) {#step-4-coordinate-with-review-team-members-team-leader .unnumbered}

4.1 Assure that all review team members have copies of the Plan for
Hardware Aspects of Certification (PHAC), Hardware Design Plan (HDP),
Hardware Validation/Verification Plan (HVP), Hardware Configuration
Management Plan (HCMP), Hardware Process Assurance Plan (HPAP), and any
other appropriate documentation at least two weeks prior to the review.

**Note**: While these may not be the final copies of the plans since
they may change throughout the design process, the documents should be
under configuration control.

4.2 Assign responsibilities to team members:

-   All team members should review all plans and prepare a list of
    questions/concerns on those plans to clarify with the applicant at
    the review.

-   The ENG team member(s) focuses on the hardware design processes,
    including the validation and verification activities.

-   The PA/CM team member(s) focus on the PA and CM processes.

-   If CSTA, TS, Directorate, or HQ personnel are to be involved in the
    review, communicate the area where their expertise is needed, so
    that they can prepare and perform any necessary research prior to
    the review.

    4.3 All team members should review the activities/questions for the
    appropriate SOIs (as listed in the Job Aid).

#### Step 5: Meet with all team members prior to the hardware review to discuss individual responsibilities (Team) {#step-5-meet-with-all-team-members-prior-to-the-hardware-review-to-discuss-individual-responsibilities-team .unnumbered}

5.1 This is typically a short meeting the evening or morning prior to
the review. The purpose of this meeting is for all of the team members
to be introduced, get a feel for any "issues" at the company to be
reviewed, answer any last minute questions, and discuss any questions
raised during preliminary review of documents.

**Note:** In some cases, a telecom works for this pre-review discussion;
particularly when the team is spread over geographical distances.

**Special Considerations for the Desk Review**

-   When notifying the applicant of the review, make arrangements for
    when and where data should be sent. Also, specify the number of
    copies needed.

-   Establish a Point of Contact (POC) at applicant's facility in case
    questions arise during the desk review.

-   Consider setting up a telecon or webcast with the applicant at the
    end of each day or keep a log of questions to fax the applicant
    since in-person interviews won't be possible.

### [TASK 2: Performing the Hardware Review and Documenting Compliances, Findings, and Observations]{.underline} {#task-2-performing-the-hardware-review-and-documenting-compliances-findings-and-observations .unnumbered}

The purpose of this task is to conduct all activities necessary to
complete the review; document compliances, findings, and observations;
and determine next steps.

#### Step 1: Conduct entry brief with applicant and FAA Team (team leader) {#step-1-conduct-entry-brief-with-applicant-and-faa-team-team-leader .unnumbered}

1.1 Introduce the review team members.

1.2 State the purpose of the review (summarize from the notification
letter).

1.3 Review the agenda with the applicant and the appropriate personnel
that need to be at each stage of the review.

1.4 Strive to create a good working partnership.

#### Step 2: Present overview of applicant's system, hardware, and design process (Applicant and Team) {#step-2-present-overview-of-applicants-system-hardware-and-design-process-applicant-and-team .unnumbered}

2.1 Applicant presents program overview, description of the hardware to
include its functions, system architecture; failure modes, hardware
design assurance level, safety monitoring and protection mechanisms, and
system and software interfaces, overall design organization structure
and Findings/Observations from internal reviews.

**Note:** The review team should take care that a significant portion of
the time allotted for the review is not taken up by the applicant's
overview. This could result in a situation that is sometimes referred to
as "compliance finding by presentation". Adequate time must be left for
the review team to examine actual artifacts and data.

2.2 During the applicant's presentation, the FAA review team focuses on
those issues/processes compatible with their expertise. For example:

-   ENG team member focuses on the hardware design process (and related
    validation and verification activities) and technical issues.

-   PA/CM team member focuses on implementation of PA and CM processes.

-   The depth of the applicant's overview will depend on the SOI and
    whether or not the review team is familiar with the process (e.g.,
    if this is a second review with the same team, the presentation may
    only be a memory jogger).

    2.3 The review team assures that the applicant's presentation
    provides adequate information to give insight into the company's
    processes and procedures.

-   The review team members ask as many questions as needed to
    understand the project being reviewed.

    2.4 The applicant's overview is generally limited in time to allow
    for adequate time to review data. **Note:** The team leader should
    work to keep the review on schedule.

#### Step 3: Review applicant's hardware data and interview the appropriate personnel (Team) {#step-3-review-applicants-hardware-data-and-interview-the-appropriate-personnel-team .unnumbered}

3.1 Part 3 of this Job Aid provides a summary of activities to be
performed and questions to be answered during a review. The particular
SOI being reviewed dictates which table is referenced. If the review is
a combination of SOIs, multiple SOI Evaluation Activities tables (e.g.
Table 5, 6, 7, 8) from Part 3 should be used.

3.2 The activities/questions outlined in Part 3 are a guide. There may
need to be more or less activities/questions, depending on the nature of
the project. Also, the sequence of activities/questions is flexible. The
goal of the Job Aid is to provide a standardized approach for getting
started. This includes sufficient guidance to cover most situations.
Each hardware project will have unique aspects that are impossible to
capture in a Job Aid. If there is anything that is not understood during
the review, the review team should question the applicant further.

#### Step 4: Document the hardware review compliances, findings, and observations (Team) {#step-4-document-the-hardware-review-compliances-findings-and-observations-team .unnumbered}

4.1 Document the Compliances, Findings, and Observations in detail.
(Compliance indicates that the objective is satisfied; a Finding
indicates non-compliance to a DO-254 objective; and an Observation
identifies process improvement.) Throughout the review, each team member
should take notes on what documents (number, revision level, date) were
reviewed, what threads were traced, areas of concern or non-compliance
to DO-254 objectives, discussions with applicant, and any other
significant issues.

The review Compliances, Findings, and Observations are included in the
exit briefing and final report and must be documented in enough detail
that they could be found again in another review (i.e., reviews must be
repeatable).

#### Step 5: Meet at the end of each day to assess progress, summarize and document compliances, findings, and observations, and plan for the next day (Team) {#step-5-meet-at-the-end-of-each-day-to-assess-progress-summarize-and-document-compliances-findings-and-observations-and-plan-for-the-next-day-team .unnumbered}

5.1 The team leader should keep a list of Compliances, Findings, and
Observations based on input from team members. (Team Leader)

5.2 Team members should discuss any concerns, questions, etc. (Team)

5.3 The team should plan activities for the next day. (Team)

**Note:** The "end-of-the-day" meeting should be held in privacy to
discuss issues openly (i.e., this meeting typically excludes the
development team). Designees should be involved in the "end-of-day"
meetings. During these meetings, the team may consider starting the
DO-254 Compliances/Findings/Observations table, if time permits. (This
will save time required for follow-up activities.)

**Special Considerations for the Desk Review**

-   The entry brief and any interim meetings to assess progress would
    only be a discussion among the review team members since the review
    is not on-site.

-   The applicant would not present the program overview---this
    information will be obtained by reading documents.

-   It will not be possible to interview personnel; however, you may
    want to keep a list of questions to fax or e-mail to the applicant
    or discuss via telephone.

### [TASK 3: Preparing and Conducting Exit Briefing]{.underline} {#task-3-preparing-and-conducting-exit-briefing .unnumbered}

The purpose of this task is to summarize Compliances, Findings, and
Observations and to share them with the applicant. The exit briefing
addresses all issues related to DO-254 compliance, other related issues,
and next steps.

#### Step 1: Prepare for the briefing by having a review team meeting (Team) {#step-1-prepare-for-the-briefing-by-having-a-review-team-meeting-team .unnumbered}

1.1 Discuss Compliances/Findings/Observations and agree on recommended
action.

1.2 Present individual team member Compliances, Findings, and
Observations and agree on how to debrief the applicant.

1.3 Summarize individual team member Compliances, Findings, and
Observations in sufficient detail for incorporation into the report.

1.4 Prepare summary of issues based on "end-of-day" meetings.

1.5 Organize presentation order for the exit briefing and agree on who
will present. (Sometimes the team leader will brief all
Compliances/Findings/Observations. Sometimes individual team members
will brief their particular Compliances/Findings/Observations.)

#### Step 2: Present exit briefing (Team) {#step-2-present-exit-briefing-team .unnumbered}

2.1 Provide introduction to exit briefing. (Team Leader)

-   Thank the applicant for the cooperation extended.

-   Be attentive to the applicant's organizational environment and its
    concerns and issues.

-   Present information in an objective, positive manner.

-   Give an overview of the review's purpose and briefing content.

-   Compliment/thank designees, applicant, hardware developer, as
    appropriate.

2.2 Present Compliances, Findings, and Observations in relationship to
DO-254 objectives. (Team or Team Leader, as appropriate) **Note**: Some
review teams, in addition to Findings and Observations, also use action
items as a way to capture the results of their review. This is an
acceptable approach IF action items are used appropriately. Action items
should not be used as a means of avoiding documentation of Findings of
non-compliance. Non-compliance to DO-254 objectives should be
categorized as Findings. Action items should be limited in nature, such
as requests for additional/ clarifying information or to schedule the
date of a future SOI.

2.3 Summarize all issues that may be relevant to certification and
compliance. (Team Leader)

2.4 Summarize any future action that must be taken to complete the
project (e.g., another review may be required to determine progress or
the designees may need to perform an in-house review). (Team Leader)

5.  Inform applicant that a report will be prepared by the FAA and sent
    with a letter to summarize and document Findings, Observations, etc.
    (Team Leader)

**Special Considerations for the Desk Review**

-   A briefing or summary of the review should still be prepared;
    however, the delivery may be via telecon, webcast, or written
    report.

### [TASK 4: Conducting Follow-up Activities]{.underline} {#task-4-conducting-follow-up-activities .unnumbered}

The purpose of this task is to perform follow-up activities after the
review. This may include telecons or additional reviews with the
applicant. A report of the hardware review compliances, findings, and
observations is prepared, coordinated, and sent to the applicant.

#### Step 1: Prepare report (Team Leader) {#step-1-prepare-report-team-leader .unnumbered}

1.1 Based on the team members' inputs at the review, prepare a report on
the results of the review:

-   Summarize all data reviewed.

-   Include a description of the difference between **Finding** and
    **Observation**.

-   Summarize compliances/findings/observations, e.g., in "Summary of
    Compliances/Findings/Observations" tables found in Part 4.

    1.2 Coordinate the report with review team members.

-   Complete no later than one week after the review so that a timely
    response is given to applicants.

-   Work portions of the report at "end-of-day" meetings.

-   Prepare report depth and length as appropriate to the situation.

#### Step 2: Coordinate preliminary findings and observations with applicant (Team) {#step-2-coordinate-preliminary-findings-and-observations-with-applicant-team .unnumbered}

2.1 Provide a draft report to the applicant requesting they identify and
respond to issues on which they do not agree.

2.2 Reconcile discrepancies with the applicant (via telecon, e-mail,
etc.).

2.3 Modify the report, as appropriate.

#### Step 3: Determine future activities (Team Leader) {#step-3-determine-future-activities-team-leader .unnumbered}

3.1 Determine if there will be a need for another review.

3.2 Identify activities that the applicant must address to show
compliance.

3.3 If project is being reviewed by an organization delegation,
determine if there is any need to communicate with any FAA personnel.

3.4 Determine if issue papers need to be drafted.

#### Step 4: Prepare a letter to the applicant and submit final report (Team Leader) {#step-4-prepare-a-letter-to-the-applicant-and-submit-final-report-team-leader .unnumbered}

4.1 Address certification and non-compliance issues in the letter.

4.2 Attach the review report and summary on non-compliance Findings.

4.3 Describe future steps required by the applicant.

4.4 Summarize future activities/expectation/plans (e.g., is a follow-up
review required? Should designees perform reviews?)

-   Place a copy of the letter in the project file.

#### Step 5: Coordinate with Certification Team (Team) {#step-5-coordinate-with-certification-team-team .unnumbered}

5.1 Discuss appropriate issues with the Project Manager, other
engineers, flight test, Principal Inspector, other managers, etc. for
the certification project.

5.2 Create issue papers, special conditions, etc. with the assistance of
CSTAs, TSs, Directorate personnel, HQ personnel, as appropriate.

5.3 Address any non-US certification issues, such as the creation of
Certification Review Items (CRI), reporting on review activities, joint
validation issues, etc.

**Special Considerations for the Desk Review**

-   Since the applicant was not present during the review and did not
    have a chance to address concerns, it is important to set up a
    telecon, webcast, or meeting to address all issues and questions
    prior to the submittal of the report.

##  {#section-4 .unnumbered}

+------------------+---------------------------------------------------+
| # Pa             |                                                   |
| rt 3 - Activitie |                                                   |
| s for Each Stage |                                                   |
|  of Involvement  |                                                   |
| {#part-3---activ |                                                   |
| ities-for-each-s |                                                   |
| tage-of-involvem |                                                   |
| ent .unnumbered} |                                                   |
+------------------+---------------------------------------------------+
| ### []           | []{.mark}                                         |
| {.mark} {#sectio |                                                   |
| n-5 .unnumbered} | The following pages highlight the activities and  |
|                  | questions to be performed by the hardware review  |
|                  | team at each SOI. These activities/questions may  |
|                  | vary slightly for a desk review (e.g., you won't  |
|                  | be able to interview developers for the desk      |
|                  | review).                                          |
|                  |                                                   |
|                  | As emphasized before, these activities/questions  |
|                  | are only to be used as a guide. Different         |
|                  | situations may require the deletion or addition   |
|                  | of activities/questions. For example, you may     |
|                  | combine two SOIs, add questions, or delete        |
|                  | activities.                                       |
|                  |                                                   |
|                  | Each SOI has a table summarizing the activities   |
|                  | and questions that support that activity, with a  |
|                  | tie to the relevant DO-254 objectives. Review     |
|                  | teams typically divide the activities and         |
|                  | questions among team members, as appropriate.     |
+------------------+---------------------------------------------------+

## 3.1 Activities for Stage of Involvement #1 -- PLANNING REVIEW {#activities-for-stage-of-involvement-1-planning-review .unnumbered}

+------------------+---------------------------------------------------+
| ###              | -   To assess the interfaces with the system      |
| Purpose {#purpos |     development process, software development     |
| e-1 .unnumbered} |     process, and system safety assessment         |
|                  |     process; to review the system architecture;   |
|                  |     to assess the assigned hardware levels; and   |
|                  |     to determine the appropriateness of any       |
|                  |     system and hardware safety features and       |
|                  |     safety monitoring hardware and protection     |
|                  |     mechanisms for supporting systems             |
|                  |     reliability, integrity, safety,               |
|                  |     functionality, performance, and operability   |
|                  |     requirements (safety objectives).             |
|                  |                                                   |
|                  | -   To assess the applicant's plans and standards |
|                  |     in relationship to identified hardware level, |
|                  |     safety features, and safety-related hardware  |
|                  |     requirements.                                 |
|                  |                                                   |
|                  | -   To ensure that plans and standards meet       |
|                  |     objectives identified in DO-254, and that the |
|                  |     hardware will comply with other applicable    |
|                  |     hardware policy and guidance.                 |
|                  |                                                   |
|                  | -   To assess that, when the applicant follows    |
|                  |     their plans, they will meet all applicable    |
|                  |     DO-254 objectives and other applicable        |
|                  |     hardware policy or guidance.                  |
+------------------+---------------------------------------------------+
| ### Wh           | Shortly after completion of the hardware planning |
| en Review Occurs | process, or any other necessary point. Plans and  |
|                  | standards may not be fully completed; however,    |
|                  | they should be fairly mature prior to the review  |
|                  | and under configuration control.                  |
+------------------+---------------------------------------------------+
| #                | Plan for Hardware Aspects of Certification        |
| ## Data Reviewed | (PHAC), Hardware Verification/Validation Plan     |
|  Prior to Review | (HVP), Hardware Design Plan (HDP), Hardware       |
|                  | Configuration Management Plan (HCMP), Hardware    |
|                  | Process Assurance Plan (HPAP), tool qualification |
|                  | plans, and other data, as applicable.             |
+------------------+---------------------------------------------------+
| ### Data Re      | PHAC, HVP, HDP, HCMP or HPAP, tool qualification  |
| viewed at Review | plans as applicable, findings/observations/issues |
|                  | from pre-review activities (highly recommended)   |
|                  | by designees/applicants/developers, hardware      |
|                  | design standards, safety assessment, system       |
|                  | architecture, hardware level justification,       |
|                  | safety features, company policy and work          |
|                  | instructions referenced in the plans and          |
|                  | standards, and other data deemed necessary.       |
+------------------+---------------------------------------------------+
| ### Number       | 1-3 days                                          |
| of Days Required |                                                   |
+------------------+---------------------------------------------------+
| ### Eva          | Table 5 provides typical activities and questions |
| luation Activiti | for SOI #1.                                       |
| es and Questions |                                                   |
+------------------+---------------------------------------------------+
| ### Instructions | -   There are eight major evaluation activities   |
|                  |     for Stage of Involvement #1: Planning Review. |
|                  |                                                   |
|                  | -   Review the questions for each activity in     |
|                  |     relationship to its corresponding DO-254      |
|                  |     objective and hardware level.                 |
+------------------+---------------------------------------------------+

[]{#__RefHeading___Toc191963521 .anchor}Table 5. SOI #1 Evaluation
Activities

+-------+---------------------------------------------+----------------+
| *     | **SOI #1 Evaluation Activity/Question**     | **Related      |
| *Item |                                             | DO-254         |
| \#**  |                                             | objective(s)** |
+=======+=============================================+================+
| **    | **Review all plans (PHAC, HCMP, HPAP, HDP,  |                |
| 1.1** | HVP, tool qualification plans, etc.) and    |                |
|       | standards. Based on your review of all the  |                |
|       | plans, consider the following questions:**  |                |
+-------+---------------------------------------------+----------------+
| 1.1.1 | Has the planning data been signed and put   | -              |
|       | under CM (HC1 or HC2 as appropriate for the |   4.1(1,2,3,4) |
|       | hardware level)? Verify there is objective  |                |
|       | evidence of coordination (e.g., authorized  | -   7.1(1,2,3) |
|       | signatures) from all organizations          |                |
|       | controlled and affected by the hardware     |                |
|       | plans and standards.                        |                |
+-------+---------------------------------------------+----------------+
| 1.1.2 | Are plans, standards, design and            | -   4.1(1,2,3) |
|       | verification environments cited complete,   |                |
|       | clear, and consistent (e.g., can the design |                |
|       | and verification engineers follow them)?    |                |
+-------+---------------------------------------------+----------------+
| 1.1.3 | Do the plans and standards address the      | -              |
|       | content as specified in DO-254 section 10   |   4.1(1,2,3,4) |
|       | (i.e., sections 10.1.1 through 10.1.6)?     |                |
|       |                                             |                |
|       | [Note]{.underline}: The plans and standards |                |
|       | are not required to be packaged as          |                |
|       | identified in 10.1.1 through 10.1.6;        |                |
|       | however, the items specified in 10.1.1      |                |
|       | through 10.1.6 should be documented         |                |
|       | somewhere in the plans and standards.       |                |
+-------+---------------------------------------------+----------------+
| 1.1.4 | Do the plans and standards address the      | -   4.1(1)     |
|       | hardware change process and procedures      |                |
|       | modifying the hardware and tools (if tools  | -   7.1(3)     |
|       | are used)?                                  |                |
+-------+---------------------------------------------+----------------+
| 1.1.5 | Are all hardware tools identified in the    | -              |
|       | plans and does the tool assessment provide  |   4.1(1,2,3,4) |
|       | rationale included for why each does or     |                |
|       | does not need to be qualified?              |                |
+-------+---------------------------------------------+----------------+
| 1.1.6 | Are the inputs, activities, transition      | -   4.1(1)     |
|       | criteria, and outputs specified for each    |                |
|       | process (including identification of        |                |
|       | sequencing and feedback mechanisms)?        |                |
+-------+---------------------------------------------+----------------+
| 1.1.7 | Are the proposed design methods defined and | -   4.1(1,4)   |
|       | explained (including identification and     |                |
|       | rationale of the proposed validation and    |                |
|       | verification methods)?                      |                |
+-------+---------------------------------------------+----------------+
| 1.1.8 | Is there evidence that appropriate planning | -              |
|       | process activities have been adequately     |   4.1(1,2,3,4) |
|       | performed to meet the planning process      |                |
|       | objectives will be met? (Refer to section   |                |
|       | 4.2 of DO-254)                              |                |
+-------+---------------------------------------------+----------------+
| 1.1.9 | If the plans and standards are followed,    | -   All        |
|       | would this ensure that all applicable       |     objectives |
|       | DO-254 objectives are met (i.e., do the     |                |
|       | plans and standards address how each of the |                |
|       | applicable DO-254 objectives will be        |                |
|       | satisfied)?                                 |                |
+-------+---------------------------------------------+----------------+
| 1     | Are the interfaces and communication        | -   4.1(1,3)   |
| .1.10 | channels with the hardware design processes |                |
|       | addressed in the plans and well defined?    |                |
|       | Evaluate processes for flow down of system  |                |
|       | requirements (functional, performance,      |                |
|       | operational, safety-related, and system     |                |
|       | architecture safety features) and for       |                |
|       | clarifying ambiguous system requirements.   |                |
|       | Determine if the hardware verification      |                |
|       | process will be claiming "formal test       |                |
|       | credit" for testing conducted by the system |                |
|       | verification and validation processes. If   |                |
|       | so, then what kind of credit, and how much  |                |
|       | credit will be granted?                     |                |
+-------+---------------------------------------------+----------------+
| 1     | Are the interfaces and communication        | -   4.1(1,3)   |
| .1.11 | channels with the system safety assessment  |                |
|       | process addressed in the plans and well     |                |
|       | defined? Evaluate the flow down of          |                |
|       | safety-related requirements and safety      |                |
|       | objectives from the system safety           |                |
|       | assessment (SSA) process to the hardware    |                |
|       | processes, and the feedback of derived      |                |
|       | requirements to the SSA process for         |                |
|       | evaluation.                                 |                |
+-------+---------------------------------------------+----------------+
| 1     | Are the interfaces and communication        | -   4.1(1,3)   |
| .1.12 | channels with applicable hardware design    |                |
|       | and verification processes addressed in the |                |
|       | plans and well defined? Evaluate the        |                |
|       | processes for documenting and communicating |                |
|       | hardware dependencies and interactions with |                |
|       | the system software and its development and |                |
|       | verification processes, and for software    |                |
|       | dependencies on the hardware and its design |                |
|       | and verification processes. Determine the   |                |
|       | process used to convey safety features      |                |
|       | (e.g., monitors, built in test, memory      |                |
|       | management unit, I/O device, processor      |                |
|       | features (cache, registers, priorities,     |                |
|       | schedulers, supervisor/user modes, etc.))   |                |
|       | and software changes affecting the hardware |                |
|       | processes, and how the hardware processes   |                |
|       | will address them.                          |                |
+-------+---------------------------------------------+----------------+
| 1     | Are there unique additional considerations  | -   4.1(4)     |
| .1.13 | associated with the project (unique         |                |
|       | alternative means or methods of compliance, |                |
|       | unique approaches to design, verification,  |                |
|       | CM, PA), proposals that don't comply with   |                |
|       | FAA national or Directorate policy or issue |                |
|       | papers, etc.? If so:                        |                |
|       |                                             |                |
|       | -   Have national or directorate hardware   |                |
|       |     and systems personnel reviewed and      |                |
|       |     approved any unique additional          |                |
|       |     considerations?                         |                |
|       |                                             |                |
|       | -   Is rationale for acceptance or          |                |
|       |     rejection of developer/applicant's      |                |
|       |     proposals well documented?              |                |
+-------+---------------------------------------------+----------------+
| 1     | Are issue papers or national/directorate    | -   4.1(4)     |
| .1.14 | policy required for any of the additional   |                |
|       | considerations? If so, do the plans and     |                |
|       | standards address how compliance with the   |                |
|       | issue papers and/or national/directorate    |                |
|       | policy will be achieved?                    |                |
+-------+---------------------------------------------+----------------+
| 1     | Have all foreign certification issues       | -   4.1(4)     |
| .1.15 | (e.g., certification review items,          |                |
|       | certification action items, review          |                |
|       | findings/issues/actions, etc.) been         |                |
|       | addressed (if a joint certification or      |                |
|       | validation project)? Additionally, do the   |                |
|       | plans and standards address how the foreign |                |
|       | certification authority issues and concerns |                |
|       | will be addressed?                          |                |
+-------+---------------------------------------------+----------------+
| 1     | Are the means of compliance of the hardware | -   4.1(4)     |
| .1.16 | design assurance objectives defined and are |                |
|       | they commensurate with the design assurance |                |
|       | level(s)?                                   |                |
+-------+---------------------------------------------+----------------+
| **    | **Determine if additional considerations    |                |
| 1.2** | defined in Section 11 of DO-254 have been   |                |
|       | documented and addressed in the plans.      |                |
|       | Consider the following questions:**         |                |
+-------+---------------------------------------------+----------------+
| 1.2.1 | Are such items as previously developed      | -              |
|       | hardware, commercial-off-the shelf (COTS)   |   4.1(1,2,3,4) |
|       | hardware or COTS Intellectual Property,     |                |
|       | field-loadable logic, option-selectable     |                |
|       | hardware, product service experience,       |                |
|       | alternative methods of compliance, etc.     |                |
|       | identified and addressed in the plans?      |                |
+-------+---------------------------------------------+----------------+
| 1.2.2 | If the developer plans on using previously  | -              |
|       | developed hardware (PDH) for the current    |   4.1(1,2,3,4) |
|       | design, consider the following questions:   |                |
|       |                                             |                |
|       | -   If PDH from legacy systems is intended  |                |
|       |     to be used, does the service experience |                |
|       |     of the system support reuse of its      |                |
|       |     hardware?                               |                |
|       |                                             |                |
|       | -   Are there any airworthiness directives, |                |
|       |     service bulletins, in-work National     |                |
|       |     Transportation Safety Board safety      |                |
|       |     recommendations, or unresolved problem  |                |
|       |     reports with safety, functional,        |                |
|       |     performance, operational or maintenance |                |
|       |     issues for the legacy system or any     |                |
|       |     proposed PDH?                           |                |
|       |                                             |                |
|       | -   Does the PDH have a satisfactory        |                |
|       |     service experience?                     |                |
|       |                                             |                |
|       | -   Does the developer intend to make any   |                |
|       |     modifications to PDH? Are plans and     |                |
|       |     processes defined for managing,         |                |
|       |     controlling, and verifying those        |                |
|       |     changes (in compliance with DO-254      |                |
|       |     section 11.3, 11.3.1-11.3.3)?           |                |
|       |                                             |                |
|       | -   Is the PDH or legacy hardware used in   |                |
|       |     an identical manner and executed on the |                |
|       |     same system hardware and in the same    |                |
|       |     environment as its previous uses?       |                |
|       |                                             |                |
|       | -   Was the PDH previously approved to      |                |
|       |     DO-254?                                 |                |
+-------+---------------------------------------------+----------------+
| 1.2.3 | Verify that hardware tools are identified   | -              |
|       | and explained in the plans. Consider the    |   4.1(1,2,3,4) |
|       | following questions:                        |                |
|       |                                             |                |
|       | -   Do the plans provide rationale for why  |                |
|       |     tools do or do not need to be qualified |                |
|       |     (e.g., was the tool assessment and      |                |
|       |     qualification process in section 11.4.1 |                |
|       |     discussed in the plans)?                |                |
|       |                                             |                |
|       | -   Is service experience claimed for the   |                |
|       |     use of any tool? If so, has the tool    |                |
|       |     changed or is it being used in the same |                |
|       |     way as previously used? Does the        |                |
|       |     documented tool service experience      |                |
|       |     justify and support the intended use    |                |
|       |     for the current design?                 |                |
+-------+---------------------------------------------+----------------+
| 1.2.4 | Are tools to be qualified supported with a  | -              |
|       | tool qualification plan (either in the PHAC |   4.1(1,2,3,4) |
|       | or in a separate document)? Verify that     |                |
|       | tools are properly categorized into design  |                |
|       | or verification or multi-function tools.    |                |
|       | Verify that the plan for assessment and     |                |
|       | qualification of tools is documented and    |                |
|       | adequate for the specified tool use.        |                |
|       |                                             |                |
|       | **Note:** Section 11.4 of DO-254 provides   |                |
|       | specific guidelines regarding tool          |                |
|       | qualification.                              |                |
+-------+---------------------------------------------+----------------+
| 1.2.5 | Is reverse engineering being planned for    | -              |
|       | any PDH? If so:                             |   4.1(1,2,3,4) |
|       |                                             |                |
|       | 1.  Has the rationale for reverse           |                |
|       |     engineering been documented and         |                |
|       |     adequately justified to the             |                |
|       |     certification authority (typically in   |                |
|       |     the "additional considerations" section |                |
|       |     of the PHAC)?                           |                |
|       |                                             |                |
|       | 2.  Has the reverse engineering effort been |                |
|       |     planned (in the PHAC and other plans)?  |                |
|       |                                             |                |
|       | 3.  Are processes and procedures well       |                |
|       |     defined?                                |                |
|       |                                             |                |
|       | 4.  Is the reverse engineering life cycle   |                |
|       |     documented?                             |                |
|       |                                             |                |
|       | 5.  Does the reverse engineering approach   |                |
|       |     meet DO-254 objectives?                 |                |
|       |                                             |                |
|       | 6.  How will the requirements be created?   |                |
|       |     Is the plan adequate?                   |                |
|       |                                             |                |
|       | 7.  Do transition criteria and traceability |                |
|       |     exist? Are they adequate?               |                |
|       |                                             |                |
|       | **Note:** See CAST-18, Reverse Engineering  |                |
|       | in Certification Projects, for specific     |                |
|       | certification concerns regarding reverse    |                |
|       | engineering. In some cases, an issue paper  |                |
|       | may be required, if the plans do not        |                |
|       | address the DO-254 objectives compliance.   |                |
|       | Available at:                               |                |
|       | <http://www.faa.gov/aircraft/ai             |                |
|       | r_cert/design_approvals/air_software/cast/> |                |
+-------+---------------------------------------------+----------------+
| **    | **Review PHAC and consider the following    |                |
| 1.3** | questions:**                                |                |
+-------+---------------------------------------------+----------------+
| 1.3.1 | Does the PHAC adequately address the        | -              |
|       | proposed contents described in DO-254,      |   4.1(1,2,3,4) |
|       | Section 10.1.1? If not, where are the       |                |
|       | contents documented?                        |                |
|       |                                             |                |
|       | **Note:** If it is documented in another    |                |
|       | planning document, that document will need  |                |
|       | to be evaluated before the PHAC can be      |                |
|       | approved. Also, that data item should be    |                |
|       | configuration controlled to the same HC1    |                |
|       | level as the PHAC.                          |                |
+-------+---------------------------------------------+----------------+
| 1.3.2 | Does the PHAC address the following         | -              |
|       | questions regarding changes to plans and    |   4.1(1,2,3,4) |
|       | standards:                                  |                |
|       |                                             | -   7.1(1,2,3) |
|       | -   Is a process in place to address        |                |
|       |     changes to plans and standards that may |                |
|       |     occur throughout the design process?    |                |
|       |                                             |                |
|       | -   Are there plans and processes to        |                |
|       |     address any deviations to plans and     |                |
|       |     standards?                              |                |
|       |                                             |                |
|       | -   Do the deviations require justification |                |
|       |     and rationale for why they are          |                |
|       |     acceptable for this project?            |                |
|       |                                             |                |
|       | -   Will applicable aspects of the hardware |                |
|       |     plans, standards and procedures be      |                |
|       |     conveyed to any sub-tier suppliers of   |                |
|       |     components of the system and            |                |
|       |     subcontractors to ensure their          |                |
|       |     compliance to the approved plans,       |                |
|       |     standards and procedures?               |                |
|       |                                             |                |
|       | -   Are the plans and standards under       |                |
|       |     change control?                         |                |
+-------+---------------------------------------------+----------------+
| 1.3.3 | Does the hardware level proposed in the     | -   4.1(4)     |
|       | PHAC support the system safety assessment   |                |
|       | adequately? If the hardware level is lower  |                |
|       | than what the system safety assessment      |                |
|       | suggests, is there adequate justification   |                |
|       | (e.g., through FFPA, system architecture,   |                |
|       | safety feature, redundancy, fail safe       |                |
|       | design techniques, partitioning as          |                |
|       | described in Appendix B of DO-254)?         |                |
|       |                                             |                |
|       | **Note:** This determination will likely    |                |
|       | require input from the systems engineer.    |                |
+-------+---------------------------------------------+----------------+
| 1.3.4 | Does the PHAC address the additional and    | -   4.1(4)     |
|       | applicable considerations described in      |                |
|       | Appendix B of DO-254?                       |                |
+-------+---------------------------------------------+----------------+
| 1.3.5 | Does the PHAC define independence and       | -   4.1(4)     |
|       | describe the method for independence        |                |
|       | required for Level A and B hardware?        |                |
+-------+---------------------------------------------+----------------+
| **    | **Review HDP and consider the following     |                |
| 1.4** | questions:**                                |                |
+-------+---------------------------------------------+----------------+
| 1.4.1 | If the HDP is followed, will the applicable | -   4.1(1)     |
|       | DO-254 design processes objectives be met?  |                |
|       |                                             | -              |
|       |                                             |   5.1.1(1,2,3) |
|       |                                             |                |
|       |                                             | -              |
|       |                                             |   5.2.1(1,2,3) |
|       |                                             |                |
|       |                                             | -              |
|       |                                             |   5.3.1(1,2,3) |
|       |                                             |                |
|       |                                             | -              |
|       |                                             |   5.4.1(1,2,3) |
|       |                                             |                |
|       |                                             | -              |
|       |                                             |   5.5.1(1,2,3) |
+-------+---------------------------------------------+----------------+
| 1.4.2 | Does the HDP adequately address the         | -              |
|       | proposed contents described in DO-254,      |   4.1(1,2,3,4) |
|       | Section 10.1.2? If not, are the contents    |                |
|       | included in another plan?                   |                |
+-------+---------------------------------------------+----------------+
| 1.4.3 | Are the hardware design processes defined   | -   4.1(1)     |
|       | in sufficient detail to ensure proper       |                |
|       | implementation of the hardware life cycle   |                |
|       | processes and model proposed for the        |                |
|       | project? Are transition criteria clear and  |                |
|       | enforceable?                                |                |
+-------+---------------------------------------------+----------------+
| 1.4.4 | Will applicable aspects of the HDP,         | -   4.1(1,2,3) |
|       | development environment, standards and      |                |
|       | processes be conveyed to any sub-tier       |                |
|       | suppliers of components of the system and   |                |
|       | subcontractors to ensure their compliance   |                |
|       | to the approved plans, standards, and       |                |
|       | procedures?                                 |                |
+-------+---------------------------------------------+----------------+
| 1.4.5 | Has the hardware development environment    | -   4.1(2,3)   |
|       | been adequately defined (e.g.,              |                |
|       | documentation tools, requirements           |                |
|       | definition and capture tools, traceability  |                |
|       | tools, design tools (including              |                |
|       | architecture, derived requirements          |                |
|       | definition and capture tools, HDL coding    |                |
|       | tools, integration tools, development host  |                |
|       | computer environment, tools to ensure       |                |
|       | protection of baselined hardware life cycle |                |
|       | data such as configuration management and   |                |
|       | control tools, access privileges, etc.)?    |                |
|       | Additionally:                               |                |
|       |                                             |                |
|       | -   Are tool users' guides, restrictions,   |                |
|       |     and limitations available and known by  |                |
|       |     the hardware developers using them?     |                |
|       |                                             |                |
|       | -   Do any of the tools support enforcement |                |
|       |     of the hardware description languages   |                |
|       |     (HDL) standards, transition criteria,   |                |
|       |     data baselining and approval process,   |                |
|       |     etc.? For example: (1) does the HDL     |                |
|       |     code editor tool or compiler enforces   |                |
|       |     any coding rules, restrictions, or      |                |
|       |     limitations? (2) does the document      |                |
|       |     control (CM system) enforce access      |                |
|       |     privileges to data and ensure no        |                |
|       |     unauthorized changes to baselined data? |                |
+-------+---------------------------------------------+----------------+
| 1.4.6 | What kind of synthesis tool is being        | -   4.1(3)     |
|       | proposed? Does the applicant have           |                |
|       | experience with the synthesis tool? Have    |                |
|       | the synthesis tool's options and            |                |
|       | optimization been identified? Have the      |                |
|       | errata sheets, vendor problem notices       |                |
|       | bulletins, or vendor problem reports for    |                |
|       | the synthesis tool been reviewed and        |                |
|       | analyzed for safety impact on the operation |                |
|       | of the tool? If safety impacts have been    |                |
|       | identified, then have the mitigations been  |                |
|       | implemented and documented for the          |                |
|       | synthesis tool?                             |                |
|       |                                             |                |
|       | **Note:** Changes to synthesis tool's       |                |
|       | options and optimization may invalidate     |                |
|       | previous tests and coverage analysis.       |                |
+-------+---------------------------------------------+----------------+
| 1.4.7 | Are HDL coding and design standards         | -   4.1(2)     |
|       | defined?                                    |                |
|       |                                             |                |
|       | **Note:** Some HDL constructs may produce   |                |
|       | non-deterministic results and therefore may |                |
|       | not meet the objectives of DO-254.          |                |
+-------+---------------------------------------------+----------------+
| **    | **Review the HCMP and consider the          |                |
| 1.5** | following questions:**                      |                |
+-------+---------------------------------------------+----------------+
| 1.5.1 | If the HCMP is followed, will the           | -   4.1(1)     |
|       | applicable DO-254 configuration management  |                |
|       | objectives be satisfied?                    | -   7.1(1,2,3) |
+-------+---------------------------------------------+----------------+
| 1.5.2 | Does the HCMP adequately address the        | -              |
|       | proposed contents described in DO-254,      |   4.1(1,2,3,4) |
|       | Section 10.1.5?                             |                |
+-------+---------------------------------------------+----------------+
| 1.5.3 | Will applicable aspects of the HCMP,        | -   4.1(1,2,3) |
|       | environment, tools, training and procedures |                |
|       | be conveyed to any sub-tier suppliers of    |                |
|       | components of the system and subcontractors |                |
|       | to ensure their compliance to the approved  |                |
|       | plans, standards and procedures?            |                |
+-------+---------------------------------------------+----------------+
| **    | **Review the HPAP and consider the          |                |
| 1.6** | following questions:**                      |                |
+-------+---------------------------------------------+----------------+
| 1.6.1 | If the HPAP is followed, will the process   | -   4.1(1)     |
|       | assurance objectives be satisfied?          |                |
|       |                                             | -   8.1(1,2,3) |
+-------+---------------------------------------------+----------------+
| 1.6.2 | Does the HPAP adequately address the        | -   4.1(1,2,3) |
|       | proposed contents described in DO-254,      |                |
|       | Section 10.1.6? If not, are the contents    |                |
|       | included in another plan?                   |                |
+-------+---------------------------------------------+----------------+
| 1.6.3 | Is hardware PA independent from the         | -   8.1(1,2,3) |
|       | development organization to a sufficient    |                |
|       | degree to ensure that PA has the autonomy   |                |
|       | and authority to ensure PA audit findings,  |                |
|       | actions, and deficiencies will be           |                |
|       | corrected?                                  |                |
+-------+---------------------------------------------+----------------+
| 1.6.4 | Are there any deviations proposed for this  | -   7.1(3)     |
|       | project from the PA plans and procedures?   |                |
|       | If so, are those deviations identified and  | -   8.1(3)     |
|       | justified?                                  |                |
+-------+---------------------------------------------+----------------+
| 1.6.5 | Are the transition criteria,                | -   4.1(1)     |
|       | interrelationships, and sequences among     |                |
|       | process properly and adequately defined,    | -   8.1(1)     |
|       | and are they capable of being audited to    |                |
|       | ensure process compliance?                  |                |
+-------+---------------------------------------------+----------------+
| 1.6.6 | Are there defined procedures for how PA     | -   4.1(1)     |
|       | audit findings, actions, and observed       |                |
|       | deficiencies will be corrected for the      |                |
|       | project?                                    |                |
+-------+---------------------------------------------+----------------+
| 1.6.7 | Is the PA findings process a separate       | -   4.1(1)     |
|       | process or does it use different tools for  |                |
|       | issues resolution than the development      |                |
|       | organization (i.e., how are the PA and      |                |
|       | development team problems reported)?        |                |
+-------+---------------------------------------------+----------------+
| 1.6.8 | Are the criteria for PA involvement         | -   4.1(1)     |
|       | (sampling, attending reviews, evaluation,   |                |
|       | conducting process compliance audits,       |                |
|       | witnessing tests, "conforming"              |                |
|       | environments, etc.) defined to ensure that  |                |
|       | life cycle objectives are met?              |                |
|       |                                             |                |
|       | **Note:** Criteria for involvement may be   |                |
|       | dependent on the hardware level or novelty  |                |
|       | of the product being developed.             |                |
+-------+---------------------------------------------+----------------+
| 1.6.9 | Has a person or organization responsible    | -   8.1(1,2,3) |
|       | for each documented PA process and activity |                |
|       | been identified?                            |                |
+-------+---------------------------------------------+----------------+
| 1     | Will applicable aspects of the HPAP,        | -   4.1(1,2,3) |
| .6.10 | environment, tools, training, and           |                |
|       | procedures be conveyed to any sub-tier      |                |
|       | suppliers of components of the system and   |                |
|       | subcontractors to ensure their compliance   |                |
|       | to the approved plans, standards, and       |                |
|       | procedures?                                 |                |
+-------+---------------------------------------------+----------------+
| **    | **Review the HVP (Validation/Verification)  |                |
| 1.7** | and consider the following questions:**     |                |
+-------+---------------------------------------------+----------------+
| 1.7.1 | If HVP is followed, will DO-254 validation  | -   4.1(1)     |
|       | and verification objectives be met?         |                |
|       |                                             | -              |
|       |                                             |   6.1.1(1,2,3) |
|       |                                             |                |
|       |                                             | -              |
|       |                                             |   6.2.1(1,2,3) |
+-------+---------------------------------------------+----------------+
| 1.7.2 | Does the HVP adequately address the         | -   4.1(1,2,3) |
|       | proposed contents described in DO-254,      |                |
|       | Section 10.1.3 & 10.1.4? If not, are the    |                |
|       | contents included in another plan?          |                |
+-------+---------------------------------------------+----------------+
| 1.7.3 | Will applicable aspects of the HVP plan,    | -   4.1(1,2,3) |
|       | environment, tools, training and procedures |                |
|       | be conveyed to any sub-tier suppliers of    |                |
|       | components of the system and subcontractors |                |
|       | to ensure their compliance to the approved  |                |
|       | plans, standards, and procedures?           |                |
+-------+---------------------------------------------+----------------+
| 1.7.4 | Does the HVP describe how independence will | -   4.1(1)     |
|       | be achieved, when required?                 |                |
+-------+---------------------------------------------+----------------+
| 1.7.5 | Does the HVP describe the verification      | -   4.1(1,2,3) |
|       | method used for each hardware verification  |                |
|       | activity? Specifically:                     |                |
|       |                                             |                |
|       | -   Are methods, checklists, tools and      |                |
|       |     procedures described for conducting     |                |
|       |     reviews of hardware requirements,       |                |
|       |     design, coding, and integration?        |                |
|       |                                             |                |
|       | -   Are methods, checklists, tools and      |                |
|       |     procedures described for conducting     |                |
|       |     analyses of traceability, change        |                |
|       |     impact, timing, verification coverage,  |                |
|       |     normal range coverage, robustness test  |                |
|       |     coverage, etc.?                         |                |
|       |                                             |                |
|       | > **Note:** Robustness testing does not     |                |
|       | > appear as an objective for DO-254, but    |                |
|       | > its application has shown to be effective |                |
|       | > for other domains (e.g., software).       |                |
|       |                                             |                |
|       | -   Are methods, checklists, tools and      |                |
|       |     procedures described for conducting     |                |
|       |     reviews of test plans, test procedures, |                |
|       |     test cases, and test results?           |                |
|       |                                             |                |
|       | -   Are methods, checklists, tools and      |                |
|       |     procedures described for conducting     |                |
|       |     testing of hardware requirements,       |                |
|       |     hardware derived requirements, hardware |                |
|       |     integration, hardware-software          |                |
|       |     integration, normal range, and          |                |
|       |     robustness?                             |                |
|       |                                             |                |
|       | -   If hardware verification test credit    |                |
|       |     will be claimed for testing conducted   |                |
|       |     on system benches, laboratory,          |                |
|       |     integrated system facilities, do the    |                |
|       |     plans and procedures describe how those |                |
|       |     activities will be conducted and        |                |
|       |     hardware test results and coverage      |                |
|       |     analyses documented?                    |                |
|       |                                             |                |
|       | -   Is there a well-defined process and     |                |
|       |     procedure for ensuring that             |                |
|       |     deficiencies detected during the        |                |
|       |     testing process will be conveyed to and |                |
|       |     corrected by the hardware design        |                |
|       |     process and team?                       |                |
+-------+---------------------------------------------+----------------+
| 1.7.6 | Does the HVP adequately describe the        | -   4.1(1,2,3) |
|       | verification environment (e.g., tools, test |                |
|       | equipment, etc.)? Consider the following    |                |
|       | questions:                                  |                |
|       |                                             |                |
|       | -   Are there any automated tools? If so,   |                |
|       |     do any of the tools need to be          |                |
|       |     qualified?                              |                |
|       |                                             |                |
|       | -   Is there any overlap between various    |                |
|       |     kinds of testing (e.g., overlap of      |                |
|       |     system and hardware requirements-based  |                |
|       |     testing)?                               |                |
|       |                                             |                |
|       | -   Is the division of the testing task     |                |
|       |     between suppliers and sub-contract      |                |
|       |     suppliers adequately addressed and      |                |
|       |     controlled?                             |                |
+-------+---------------------------------------------+----------------+
| 1.7.7 | Are verification plans, including test      | -   4.1(1,2,3) |
|       | plans, and procedures conveyed to suppliers |                |
|       | and sub-contractors to ensure their         |                |
|       | activities and results will comply with the |                |
|       | approved plans and procedures?              |                |
+-------+---------------------------------------------+----------------+
| 1.7.8 | Does the HVP describe methods for test case | -   4.1(1,2,3) |
|       | selection? Does the HVP specify how each    |                |
|       | requirement will be tested (e.g., hardware  |                |
|       | component test, board level/hardware        |                |
|       | integration test, hardware/software         |                |
|       | integration test)?                          |                |
+-------+---------------------------------------------+----------------+
| 1.7.9 | Does the HVP or procedures specify who is   | -   4.1(1)     |
|       | allowed to perform verification tasks?      |                |
+-------+---------------------------------------------+----------------+
| 1     | If verification tools are used, has the     | -   4.1(1,3)   |
| .7.10 | tool assessment process as described in     |                |
|       | section 11.4 of DO-254 been followed?       |                |
|       |                                             |                |
|       | **Note:** See section 11.4 of DO-254 for    |                |
|       | more information on tool assessment and     |                |
|       | qualification process.                      |                |
+-------+---------------------------------------------+----------------+
| **    | **Review the hardware design standards and  |                |
| 1.8** | consider the following questions:**         |                |
+-------+---------------------------------------------+----------------+
| 1.8.1 | Are the hardware design standards           | -   4.1(2)     |
|       | (Requirements Standards, Hardware Design    |                |
|       | Standards, Validation and Verification      |                |
|       | Standards, and Hardware Archive Standards)  |                |
|       | identified and well defined?                |                |
+-------+---------------------------------------------+----------------+
| 1.8.2 | Are the hardware design standards           | -   4.1(2)     |
|       | consistent with the plans and do they       |                |
|       | support implementation of the plans?        |                |
+-------+---------------------------------------------+----------------+
| 1.8.3 | Will the hardware design standards support  | -   4.1(2,4)   |
|       | the proposed hardware level(s) and          |                |
|       | hardware's compliance with DO-254           |                |
|       | objectives?                                 |                |
+-------+---------------------------------------------+----------------+
| 1.8.4 | Have standards been verified for each       | -              |
|       | defined hardware life cycle process? Are    |   4.1(1,2,3,4) |
|       | the standards adequate to support the       |                |
|       | hardware level?                             |                |
+-------+---------------------------------------------+----------------+
| 1.8.5 | Have standards been described in detail to  | -              |
|       | support the planning process objectives     |   4.1(1,2,3,4) |
|       | (see sections 10.2.1, 10.2.2, 10.2.3 and    |                |
|       | 10.2.4)?                                    |                |
+-------+---------------------------------------------+----------------+
| 1.8.6 | If HDL or another hardware design language  | -   4.1(2)     |
|       | is used, have coding standards been         |                |
|       | verified to ensure that any constructs are  |                |
|       | not permitted which would invalidate the    |                |
|       | assumptions about the safety levels (e.g.,  |                |
|       | non-determinism)?                           |                |
+-------+---------------------------------------------+----------------+
| 1.8.7 | Have the hardware design standards been     | -   4.1(2)     |
|       | verified to ensure that there are           |                |
|       | limitations, prohibitions, and constraints  |                |
|       | to not permit the use of design and code    |                |
|       | features that are not deterministic and not |                |
|       | verifiable?                                 |                |
+-------+---------------------------------------------+----------------+
| 1.8.8 | What HDL is being used?                     | -   4.1(1,2,3) |
|       |                                             |                |
|       | 1.  Does the applicant have experience with |                |
|       |     the language?                           |                |
|       |                                             |                |
|       | 2.  Does the HDL have any features or       |                |
|       |     capabilities that may be difficult to   |                |
|       |     verify? Has the applicant or developer  |                |
|       |     imposed any prohibitions or             |                |
|       |     restrictions on the use of these        |                |
|       |     features in the coding standards and/or |                |
|       |     review checklists? Does the             |                |
|       |     applicant/developer have plans and      |                |
|       |     procedures established for how these    |                |
|       |     features will be verified?              |                |
|       |                                             |                |
|       | 3.  What features of the HDL support or     |                |
|       |     hinder real-time implementation and     |                |
|       |     verification?                           |                |
|       |                                             |                |
|       | 4.  Are any HDL problems documented and     |                |
|       |     addressed?                              |                |
|       |                                             |                |
|       | 5.  Has a safe sub-set of the HDL been      |                |
|       |     selected? How will it be verified that  |                |
|       |     that safe sub-set was adhered to (e.g., |                |
|       |     code reviews, checklists, testing,      |                |
|       |     etc.)?                                  |                |
|       |                                             |                |
|       | 6.  What are common errors of the HDL? Do   |                |
|       |     coding standards protect against these  |                |
|       |     errors?                                 |                |
+-------+---------------------------------------------+----------------+

## 3.2 Activities for Stage of Involvement #2 -- DESIGN REVIEW {#activities-for-stage-of-involvement-2-design-review .unnumbered}

+------------------+---------------------------------------------------+
| ###              | -   Assess effective implementation of            |
| Purpose {#purpos |     applicant's plans and standards through       |
| e-2 .unnumbered} |     examination of hardware life cycle data.      |
|                  |                                                   |
|                  | -   Assess and agree to any changes in the plans. |
|                  |                                                   |
|                  | -   Assure that hardware life cycle data meets    |
|                  |     DO-254 objectives.                            |
+------------------+---------------------------------------------------+
| ### When R       | When the hardware design is sufficiently mature   |
| eview Occurs {#w | to support ongoing hardware change without        |
| hen-review-occur | degrading safety or architecture, or when deemed  |
| s-1 .unnumbered} | necessary. Some things that should be in place    |
|                  | prior to this review are:                         |
+------------------+---------------------------------------------------+
| ###  {#sectio    | -   Hardware requirements are documented,         |
| n-6 .unnumbered} |     reviewed, and traceable to system             |
|                  |     requirements.                                 |
|                  |                                                   |
|                  | -   Detailed Design Data (e.g., HDL, RTL,         |
|                  |     schematic capture, C) implements, and is      |
|                  |     traceable to, the hardware requirements and   |
|                  |     has been reviewed.                            |
+------------------+---------------------------------------------------+
| ### Data Revie   | Report from Stage of Involvement #1 (SOI #1);     |
| wed Prior to [R] | open items from\                                  |
| {.smallcaps}evie | SOI #1; and all plans (PHAC, HVP                  |
| w {#data-reviewe | (Validation/Verification), HDP, HCMP, HPAP (as a  |
| d-prior-to-revie | refresher after SOI #1 or to review changes to    |
| w-1 .unnumbered} | plans since SOI #1)).                             |
+------------------+---------------------------------------------------+
| ###              | Standards for Hardware Requirements, Design, and  |
| Data Reviewed at | Code; Hardware Requirements; Hardware Design      |
|  Review {#data-r | Description; Detailed Design Data; Hardware       |
| eviewed-at-revie | Validation and Verification Results; Problem      |
| w-1 .unnumbered} | Reports; Hardware CM Records; Hardware Quality    |
|                  | Assurance Records; Trace Matrix/Tool; and         |
|                  | Designees' findings/observations from pre-review  |
|                  | activities.                                       |
+------------------+---------------------------------------------------+
| ###              | 1-3 days                                          |
| Number of Days R |                                                   |
| equired {#number |                                                   |
| -of-days-require |                                                   |
| d-1 .unnumbered} |                                                   |
+------------------+---------------------------------------------------+
| ### Evaluati     | During Stage of Involvement #2 (SOI #2), a trace  |
| on Activities an | matrix or similar traceability tool should be     |
| d Questions {#ev | used to perform one or two top-down traces (from  |
| aluation-activit | system requirements to hardware requirements to   |
| ies-and-question | design description to detailed design to test     |
| s-1 .unnumbered} | cases) and one or two bottom-up traces (from      |
|                  | detailed design to design description to hardware |
|                  | requirements to systems requirements) in each of  |
|                  | the major sub-systems. The traces should be       |
|                  | performed in different areas (e.g., display,      |
|                  | interface, core logic, built-in test). Table 6    |
|                  | provides typical activities and questions for SOI |
|                  | #2.                                               |
+------------------+---------------------------------------------------+
| ### Instructio   | -   There are six major evaluation activities for |
| ns {#instruction |     Stage of Involvement #2: Design Review.       |
| s-1 .unnumbered} |                                                   |
|                  | -   Review the questions for each activity in     |
|                  |     relationship to its corresponding DO-254      |
|                  |     objective and hardware level.                 |
+------------------+---------------------------------------------------+

[]{#__RefHeading___Toc191963522 .anchor}Table 6. SOI#2 Evaluation
Activities

+-------+--------------------------------------------+----------------+
| *     | **SOI #2 Evaluation Activity/Question**    | **Related      |
| *Item |                                            | DO-254         |
| \#**  |                                            | objective(s)** |
+=======+============================================+================+
| **    | **Review status from SOI #1.**             |                |
| 2.1** |                                            |                |
+-------+--------------------------------------------+----------------+
| 2.1.1 | Have all issues and Findings from SOI #1   | -              |
|       | been satisfactorily addressed? If not,     |   4.1(1,2,3,4) |
|       | then has justification or rationale been   |                |
|       | given?                                     |                |
+-------+--------------------------------------------+----------------+
| **    | **Review the requirements capture process. |                |
| 2.2** | Consider the following questions:**        |                |
+-------+--------------------------------------------+----------------+
| 2.2.1 | Are the hardware requirements under HC1    | -   7.1(1,2,3) |
|       | configuration control?                     |                |
+-------+--------------------------------------------+----------------+
| 2.2.2 | Have the hardware requirements been        | -   8.1(2)     |
|       | reviewed in accordance with the hardware   |                |
|       | validation/verification plans?             |                |
+-------+--------------------------------------------+----------------+
| 2.2.3 | Are all hardware and derived               | -              |
|       | requirement(s) associated with each        |   5.1.1(1,2,3) |
|       | selected system level requirement (i.e.,   |                |
|       | identify threads between system and        | -   6.1.1(1)   |
|       | hardware requirements) clearly identified? |                |
|       |                                            | -   6.2.1(2)   |
|       | **Note:** Use of a design trace            |                |
|       | matrix/tool may prove to be helpful.       |                |
+-------+--------------------------------------------+----------------+
| 2.2.4 | If independence is required for the        | -   Appendix A |
|       | hardware level, is the person doing the    |                |
|       | verification different than the one        | -   6.2.1(3)   |
|       | responsible for developing the             |                |
|       | requirement(s)?                            |                |
+-------+--------------------------------------------+----------------+
| >     | > Is each requirement (including derived)  | -              |
| 2.2.5 | > uniquely identified (i.e., each          |   5.1.1(1,2,3) |
|       | > requirement number is truly only one     |                |
|       | > requirement)?                            | -   7.1(1)     |
+-------+--------------------------------------------+----------------+
| >     | > Are the requirements (including derived) | -              |
| 2.2.6 | > unambiguous? Does the requirement have   |   5.1.1(1,2,3) |
|       | > the same meaning to all participants     |                |
|       | > (acquirer, systems engineer, hardware    | -   6.1.1(1)   |
|       | > developers, and users)?                  |                |
+-------+--------------------------------------------+----------------+
| >     | > Are requirements (including derived)     | -              |
| 2.2.7 | > consistent (e.g., terminology            |   5.1.1(1,2,3) |
|       | > attributes, data definitions)?           |                |
|       |                                            | -   6.1.1(1)   |
+-------+--------------------------------------------+----------------+
| >     | > Are hardware requirements (that trace    | -              |
| 2.2.8 | > back to that system level requirement)   |   5.1.1(1,2,3) |
|       | > accurate? That is, if all these          |                |
|       | > requirements are met, would the          |                |
|       | > associated system level requirement be   |                |
|       | > satisfied? If not, determine if there    |                |
|       | > are additional hardware requirements     |                |
|       | > that if implemented, the combination of  |                |
|       | > software and hardware requirements would |                |
|       | > satisfy the corresponding requirement.   |                |
+-------+--------------------------------------------+----------------+
| >     | > Are the requirements (including derived) | -              |
| 2.2.9 | > complete? Are there any "To Be           |   5.1.1(1,2,3) |
|       | > Determined" items in the requirements    |                |
|       | > data?                                    | -   6.1.1(1)   |
+-------+--------------------------------------------+----------------+
| > 2   | > Is each requirement verifiable through   | -   6.2.1(2,3) |
| .2.10 | > testing, inspection, or analysis?        |                |
|       | >                                          |                |
|       | > **Note:** Timing, sizing, and            |                |
|       | > partitioning requirements are generally  |                |
|       | > supported through analysis.              |                |
+-------+--------------------------------------------+----------------+
| > 2   | > Does each requirement conform to         | -   4.1(2)     |
| .2.11 | > applicable standards as defined in the   |                |
|       | > developer's hardware requirement         | -   5.2.1(1)   |
|       | > standards?                               |                |
|       |                                            | -   5.3.1(1)   |
+-------+--------------------------------------------+----------------+
| > 2   | > If previous requirement verification     | -   6.2.1(1)   |
| .2.12 | > results are being used to verify the     |                |
|       | > current design (e.g., a "gold            |                |
|       | > standard"), have the objectives for each |                |
|       | > selected requirement(s) been previously  |                |
|       | > verified?                                |                |
+-------+--------------------------------------------+----------------+
| > 2   | > Are there inconsistencies between the    | -   8.1(2)     |
| .2.13 | > requirements reviewed and the hardware   |                |
|       | > design plans?                            |                |
+-------+--------------------------------------------+----------------+
| > 2   | > Do any interviews with the hardware      | -   8.1(1,2)   |
| .2.14 | > developers indicate that the plans were  |                |
|       | > not followed for requirements capture?   |                |
+-------+--------------------------------------------+----------------+
| > 2   | > Are derived requirements used accurately | -   5.1.1(2)   |
| .2.15 | > and consistently?                        |                |
+-------+--------------------------------------------+----------------+
| > 2   | > Have the derived requirements been fed   | -   5.1.1(2)   |
| .2.16 | > back to the safety assessment and/or     |                |
|       | > other appropriate processes?             |                |
+-------+--------------------------------------------+----------------+
| > 2   | > Have errors and omissions in the         | -   5.1.1(3)   |
| .2.17 | > hardware requirements been provided to   |                |
|       | > the system development process for       |                |
|       | > resolution?                              |                |
+-------+--------------------------------------------+----------------+
| > **  | > **Review the hardware conceptual design  |                |
| 2.3** | > process. Consider the following          |                |
|       | > questions:**                             |                |
+-------+--------------------------------------------+----------------+
| >     | > Does the conceptual design data          | -   5.2.1(1)   |
| 2.3.1 | > (including identification of major       |                |
|       | > components, reliability and maintenance  |                |
|       | > test features) adequately describe the   |                |
|       | > hardware item's architecture and         |                |
|       | > functional design?                       |                |
|       | >                                          |                |
|       | > **Note:** Refer to 10.3.2.1 of DO-254.   |                |
+-------+--------------------------------------------+----------------+
| >     | > Is the conceptual design data under the  | -   7.1(1,2,3) |
| 2.3.2 | > appropriate configuration control?       |                |
+-------+--------------------------------------------+----------------+
| >     | > Is the conceptual design data traceable  | -   6.2.1(2)   |
| 2.3.3 | > to the hardware requirements?            |                |
+-------+--------------------------------------------+----------------+
| >     | > Have the derived requirements, including | -   5.2.1(2)   |
| 2.3.4 | > any interface definitions, identified in |                |
|       | > the conceptual design process been fed   |                |
|       | > back to the requirements capture         |                |
|       | > process?                                 |                |
+-------+--------------------------------------------+----------------+
| >     | > Have requirement omissions and errors    | -   5.2.1(3)   |
| 2.3.5 | > been fed back to the appropriate process |                |
|       | > for resolution?                          |                |
+-------+--------------------------------------------+----------------+
| > **  | > **Review the detailed design process.    |                |
| 2.4** | > Consider the following questions:**      |                |
+-------+--------------------------------------------+----------------+
| >     | > Is the detailed design data (including   | -   5.3.1(1)   |
| 2.4.1 | > top-level drawings, assembly drawings,   |                |
|       | > interface control drawings,              |                |
|       | > hardware/software interface data, and    |                |
|       | > any applicable architectural mitigation  |                |
|       | > data such as safety monitors,            |                |
|       | > dissimilarity, fault tolerant and test   |                |
|       | > features) sufficient to implement the    |                |
|       | > hardware item consistent with its        |                |
|       | > requirements?                            |                |
|       | >                                          |                |
|       | > **Note:** See 10.3.2.2 of DO-254.        |                |
+-------+--------------------------------------------+----------------+
| >     | > Is the detailed design data traceable to | -   6.2.1(2)   |
| 2.4.2 | > the conceptual design and hardware       |                |
|       | > requirements?                            |                |
+-------+--------------------------------------------+----------------+
| >     | > Have the derived requirements, including | -   5.3.1(2)   |
| 2.4.3 | > any interface definitions, identified in |                |
|       | > the conceptual design process been fed   |                |
|       | > back to the requirements capture         |                |
|       | > process?                                 |                |
+-------+--------------------------------------------+----------------+
| >     | > Have requirement omissions and errors    | -   5.3.1(3)   |
| 2.4.4 | > been fed back to the appropriate process |                |
|       | > for resolution? Is there a person or     |                |
|       | > organization whose responsibilities      |                |
|       | > ensure that any safety implications from |                |
|       | > these omissions and errors have been     |                |
|       | > properly addressed?                      |                |
+-------+--------------------------------------------+----------------+
| > **  | > **Review the hardware implementation     |                |
| 2.5** | > process. Consider the following          |                |
|       | > questions:**                             |                |
+-------+--------------------------------------------+----------------+
| >     | > Was the hardware item, which implements  | -   5.4.1(1)   |
| 2.5.1 | > the detailed design, produced using      |                |
|       | > representative manufacturing processes   |                |
|       | > (where practical)?                       |                |
+-------+--------------------------------------------+----------------+
| >     | > Are the hardware item implementation,    | -   5.4.1(2)   |
| 2.5.2 | > assembly, and installation data          |                |
|       | > complete?                                |                |
+-------+--------------------------------------------+----------------+
| >     | > Is the hardware item implementation      | -   6.2.1(2)   |
| 2.5.3 | > traceable to the detailed design data?   |                |
+-------+--------------------------------------------+----------------+
| >     | > Have the derived requirements (generated | -   5.4.1(3)   |
| 2.5.4 | > by the implementation process) been fed  |                |
|       | > back to the detailed design process or   |                |
|       | > other appropriate processes?             |                |
+-------+--------------------------------------------+----------------+
| >     | > Have requirement omissions and errors    | -   5.4.1(4)   |
| 2.5.5 | > been fed back to the appropriate process |                |
|       | > for resolution?                          |                |
+-------+--------------------------------------------+----------------+
| > **  | > **Review the Production Transition       |                |
| 2.6** | > Process**                                |                |
+-------+--------------------------------------------+----------------+
| >     | > Has manufacturing data been produced and | -   5.5.1(1)   |
| 2.6.1 | > established from the configured design   |                |
|       | > data for the implemented product?        |                |
+-------+--------------------------------------------+----------------+
| >     | > Have changes or improvements             | -   8.1(2)     |
| 2.6.2 | > incorporated during the production       |                |
|       | > transition process been evaluated        |                |
|       | > against product and safety requirements? |                |
+-------+--------------------------------------------+----------------+
| >     | > Has the manufacturing data been checked  | -   8.1(2)     |
| 2.6.3 | > for completeness and consistency with    |                |
|       | > the configured design data?              |                |
+-------+--------------------------------------------+----------------+
| >     | > Has the manufacturing requirements       | -   5.5.1(2)   |
| 2.6.4 | > related to safety been identified and    |                |
|       | > documented and manufacturing controls    |                |
|       | > established?                             |                |
+-------+--------------------------------------------+----------------+
| >     | > Has the data required to develop         | -   5.5.1(2)   |
| 2.6.5 | > acceptance test criteria been            |                |
|       | > determined?                              |                |
+-------+--------------------------------------------+----------------+
| >     | > Have the derived requirements (generated | -   5.5.1(3)   |
| 2.6.6 | > by the production transition process)    |                |
|       | > been fed back to the implementation      |                |
|       | > process or other appropriate processes?  |                |
+-------+--------------------------------------------+----------------+
| >     | > Have requirement omissions and errors    | -   5.5.1(4)   |
| 2.6.7 | > been fed back to the appropriate process |                |
|       | > for resolution? Is there a person or     |                |
|       | > organization whose responsibilities      |                |
|       | > ensure that any safety implications from |                |
|       | > these omissions and errors have been     |                |
|       | > properly addressed?                      |                |
+-------+--------------------------------------------+----------------+

## 3.3 Activities for Stage of Involvement #3 -- VALIDATION AND VERIFICATION REVIEW {#activities-for-stage-of-involvement-3-validation-and-verification-review .unnumbered}

+------------------+---------------------------------------------------+
| ###              | -   Assess effective implementation of the        |
| Purpose {#purpos |     applicant's validation/ verification plans    |
| e-3 .unnumbered} |     and procedures.                               |
|                  |                                                   |
|                  | -   Check the completion of all associated CM and |
|                  |     PA tasks.                                     |
|                  |                                                   |
|                  | -   Make determination on acceptable deviations   |
|                  |     from plans and standards found during the     |
|                  |     review or with the applicant's requested      |
|                  |     deviations.                                   |
|                  |                                                   |
|                  | -   Ensure that the selected hardware             |
|                  |     requirements have been validated and          |
|                  |     verified, as applicable.                      |
|                  |                                                   |
|                  | -   Ensure that the hardware life cycle data      |
|                  |     meets DO-254 objectives.                      |
|                  |                                                   |
|                  | -   Ensure that the verification activity         |
|                  |     satisfied the verification coverage           |
|                  |     requirements found in DO-254 Appendix B.      |
+------------------+---------------------------------------------------+
| ### When R       | When the following activities are in place (or    |
| eview Occurs {#w | when deemed necessary):                           |
| hen-review-occur |                                                   |
| s-2 .unnumbered} | -   Test procedures and results (if available)    |
|                  |     are documented and reviewed.                  |
|                  |                                                   |
|                  | -   Detailed Design Data (e.g., HDL, RTL,         |
|                  |     schematic capture, C) satisfies hardware      |
|                  |     requirements.                                 |
|                  |                                                   |
|                  | -   A coverage analysis indicates that the        |
|                  |     requirements are met for levels A and B, per  |
|                  |     Appendix B of DO-254.                         |
|                  |                                                   |
|                  |     **Note:** Testing is where many applicants    |
|                  |     have problems. It is best to perform this     |
|                  |     review early enough that major retest will    |
|                  |     not be required if issues are found, but late |
|                  |     enough to see some trends in the test         |
|                  |     program.                                      |
+------------------+---------------------------------------------------+
| ### Data Reviewe | Reports from SOI #1 and SOI #2, open items from   |
| d Prior to Revie | SOI #1 and\                                       |
| w {#data-reviewe | SOI #2, and all plans (PHAC, HVP, HDP, HCMP, HPAP |
| d-prior-to-revie | (as a refresher after SOI #1 & SOI #2 or to       |
| w-2 .unnumbered} | review changes to plans since SOI #1 & SOI #2)).  |
+------------------+---------------------------------------------------+
| ###              | Hardware Requirements; Hardware Design            |
| Data Reviewed at | Description; Detailed Design Data; Hardware       |
|  Review {#data-r | Verification Cases and Procedures; Hardware       |
| eviewed-at-revie | Verification Results; Problem Reports; Hardware   |
| w-2 .unnumbered} | Configuration Management Records; Hardware        |
|                  | Process Assurance Records; Trace Matrix/Tool; and |
|                  | Designees' findings/observations from pre-review  |
|                  | activities.                                       |
+------------------+---------------------------------------------------+
| ###              | 1-3 days                                          |
| Number of Days R |                                                   |
| equired {#number |                                                   |
| -of-days-require |                                                   |
| d-2 .unnumbered} |                                                   |
+------------------+---------------------------------------------------+
| ### Evaluati     | During SOI #3, a trace is performed on a sampling |
| on Activities an | of system requirements allocated to hardware to   |
| d Questions {#ev | see if they are adequately tested. Likewise, test |
| aluation-activit | cases are traced up to the system requirements to |
| ies-and-question | verify traceability. Table 7 provides typical     |
| s-2 .unnumbered} | activities and questions for SOI #3.              |
+------------------+---------------------------------------------------+
| ### Instructio   | -   There are fourteen major evaluation           |
| ns {#instruction |     activities for Stage of Involvement #3:       |
| s-2 .unnumbered} |     Validation and Verification Review.           |
|                  |                                                   |
|                  | -   Review the questions for each activity in     |
|                  |     relationship to its corresponding DO-254      |
|                  |     objective and hardware level.                 |
+------------------+---------------------------------------------------+

[]{#__RefHeading___Toc191963523 .anchor}Table 7. SOI #3 Evaluation
Activities

+-------+--------------------------------------------+-----------------+
| *     | **SOI #3 Evaluation Activity/Question**    | **Related       |
| *Item |                                            | DO-254          |
| \#**  |                                            | objective(s)**  |
+=======+============================================+=================+
| **    | **Review status from SOI #1 and #2**       | > []{.mark}     |
| 3.1** |                                            |                 |
+-------+--------------------------------------------+-----------------+
| 3.1.1 | Have all issues and Findings from SOI #1   | -               |
|       | and SOI #2 been satisfactorily addressed?  |    4.1(1,2,3,4) |
|       | If not, then has justification or          |                 |
|       | rationale been given?                      | -               |
|       |                                            |    5.1.1(1,2,3) |
|       |                                            |                 |
|       |                                            | -               |
|       |                                            |    5.2.1(1,2,3) |
|       |                                            |                 |
|       |                                            | -               |
|       |                                            |    5.3.1(1,2,3) |
|       |                                            |                 |
|       |                                            | -               |
|       |                                            |    5.4.1(1,2,3) |
|       |                                            |                 |
|       |                                            | -               |
|       |                                            |  5.5.1(1,2,3,4) |
+-------+--------------------------------------------+-----------------+
| **    | **Review documented activities and         |                 |
| 3.2** | artifacts against plans.**                 |                 |
+-------+--------------------------------------------+-----------------+
| 3.2.1 | Is there evidence that the HVP             | -   8.1(1,2)    |
|       | (Validation/Verification) and other plans  |                 |
|       | related to verification, integration, and  |                 |
|       | testing are being followed (e.g., progress |                 |
|       | against timeframes, staffing etc.)?        |                 |
+-------+--------------------------------------------+-----------------+
| **    | **Review validation of derived             |                 |
| 3.3** | requirements. Consider the following       |                 |
|       | questions:**                               |                 |
+-------+--------------------------------------------+-----------------+
| 3.3.1 | Are the derived requirements against which | -   6.1.1(1)    |
|       | the hardware item is to be verified        |                 |
|       | correct and complete?                      |                 |
+-------+--------------------------------------------+-----------------+
| 3.3.2 | Have the derived requirements been         | -   6.1.1(2)    |
|       | evaluated for impact on safety and have    |                 |
|       | the evaluations been documented?           |                 |
+-------+--------------------------------------------+-----------------+
| 3.3.3 | Have omissions and errors associated with  | -   6.1.1(3)    |
|       | derived requirements been fed back to the  |                 |
|       | appropriate process for resolution and     |                 |
|       | have they been documented accurately in    |                 |
|       | problem reports? Is there a person or      |                 |
|       | organization whose responsibilities ensure |                 |
|       | that any safety implications from these    |                 |
|       | omissions and errors have been properly    |                 |
|       | addressed?                                 |                 |
+-------+--------------------------------------------+-----------------+
| **    | **Sample the applicant's test cases and    |                 |
| 3.4** | consider:**                                |                 |
+-------+--------------------------------------------+-----------------+
| 3.4.1 | Are test cases traceable to the            | -   6.2.1(2)    |
|       | requirements?                              |                 |
+-------+--------------------------------------------+-----------------+
| 3.4.2 | Are the requirements traceable to the      | -   6.2.1(2)    |
|       | detailed design (e.g., HDL, hardware       |                 |
|       | schematics)?                               |                 |
+-------+--------------------------------------------+-----------------+
| 3.4.3 | Have normal ranges been tested?            | -   6.2.1(1)    |
+-------+--------------------------------------------+-----------------+
| 3.4.4 | Is robustness of the design adequately     | -   6.2.1(1)    |
|       | assessed by the test cases?                |                 |
|       |                                            |                 |
|       | **Note:** Robustness testing does not      |                 |
|       | appear as an objective for DO-254, but its |                 |
|       | application has shown to be effective for  |                 |
|       | other domains (e.g., software).            |                 |
+-------+--------------------------------------------+-----------------+
| **    | **Review test cases and procedures,        |                 |
| 3.5** | considering the following questions:**     |                 |
+-------+--------------------------------------------+-----------------+
| 3.5.1 | Have test cases and procedures been        | -               |
|       | reviewed for correctness?                  |    6.2.1(1,2,3) |
+-------+--------------------------------------------+-----------------+
| 3.5.2 | Do the test cases and procedures adhere to | -   6.2.1(1)    |
|       | the relevant plans and standards? For      |                 |
|       | example, have detailed design standards,   |                 |
|       | especially those relevant to limitations   |                 |
|       | of limitations related to advanced         |                 |
|       | verification techniques (DO-254 Appendix   |                 |
|       | B), been followed?                         |                 |
+-------+--------------------------------------------+-----------------+
| 3.5.3 | Are the test cases and procedures          | -   6.2.1(1,3)  |
|       | appropriately commented?                   |                 |
+-------+--------------------------------------------+-----------------+
| 3.5.4 | Have the test cases and procedures been    | -   7.1(1,2,3)  |
|       | subjected to appropriate change and        |                 |
|       | configuration control?                     |                 |
+-------+--------------------------------------------+-----------------+
| 3.5.5 | Is the purpose for each test case clearly  | -               |
|       | explained?                                 |    6.2.1(1,2,3) |
+-------+--------------------------------------------+-----------------+
| 3.5.6 | Is the separation between test cases       | -               |
|       | clear? For example, is each test start and |    6.2.1(1,2,3) |
|       | stop identified? This assists tracing the  |                 |
|       | source of unexpected drops in coverage.    |                 |
+-------+--------------------------------------------+-----------------+
| 3.5.7 | Do the test cases and procedures specify   | -   6.2.1(1,3)  |
|       | required input data, sequence and test     |                 |
|       | conditions (e.g., ambient temperature and  |                 |
|       | applied voltage), and expected output      |                 |
|       | data?                                      |                 |
+-------+--------------------------------------------+-----------------+
| 3.5.8 | Were the inputs for each test case derived | -   6.2.1(1,3)  |
|       | from the requirements (as opposed to being |                 |
|       | derived from the HDL)?                     |                 |
+-------+--------------------------------------------+-----------------+
| 3.5.9 | Are the test cases and procedures          | -               |
|       | sufficient to cover all the relevant       |    6.2.1(1,2,3) |
|       | requirements (including environmental      |                 |
|       | qualification test requirements)? That is, |                 |
|       | do the traceability matrices provide clear |                 |
|       | association between test cases and         |                 |
|       | requirements?                              |                 |
|       |                                            |                 |
|       | **Note:** This is also applicable for      |                 |
|       | Previously Developed Hardware. Refer to    |                 |
|       | DO-254, section 6.3.2.                     |                 |
+-------+--------------------------------------------+-----------------+
| 3     | Does each test case have procedures for    | -   6.2.1(1,3)  |
| .5.10 | test set-up (include the test              |                 |
|       | environment), test execution, and          |                 |
|       | pass-fail criteria?                        |                 |
+-------+--------------------------------------------+-----------------+
| 3     | If test cases are run on a simulator or    | -   6.2.1(1,3)  |
| .5.11 | emulator (for DO-254 compliance), has the  |                 |
|       | simulator or emulator eliminated any of    |                 |
|       | the test steps? If so, has the simulator   |                 |
|       | or emulator been assessed for tool         |                 |
|       | qualification per section 11.4 of DO-254?  |                 |
+-------+--------------------------------------------+-----------------+
| 3     | Are there sufficient tests to provide      | -               |
| .5.12 | adequate verification coverage of the      |    6.2.1(1,2,3) |
|       | hardware?                                  |                 |
+-------+--------------------------------------------+-----------------+
| **    | **Review checklists for test cases,        |                 |
| 3.6** | procedures, and results, considering the   |                 |
|       | following questions:**                     |                 |
+-------+--------------------------------------------+-----------------+
| 3.6.1 | Are the checklists sufficient to determine | -   6.2.1(1,3)  |
|       | that the requirements-based test cases,    |                 |
|       | procedures, and results meet verification  |                 |
|       | objectives?                                |                 |
+-------+--------------------------------------------+-----------------+
| 3.6.2 | Do the checklists specify:                 | -               |
|       |                                            |    6.2.1(1,3,4) |
|       | -   who performed the review?              |                 |
|       |                                            |                 |
|       | -   what was reviewed (with revision       |                 |
|       |     data)?                                 |                 |
|       |                                            |                 |
|       | -   when it was reviewed?                  |                 |
|       |                                            |                 |
|       | -   what was found?                        |                 |
|       |                                            |                 |
|       | -   references to corrective actions,      |                 |
|       |     where necessary?                       |                 |
+-------+--------------------------------------------+-----------------+
| 3.6.3 | Will the test case, procedures, and test   | -   6.2.1(1)    |
|       | results checklists reveal whether the      |                 |
|       | results of the test cases that are counted |                 |
|       | for credit are observable? That is, does   |                 |
|       | the test procedure require that the test   |                 |
|       | results are collected with standard        |                 |
|       | instrumentation and not inferred by        |                 |
|       | observing the high-level system            |                 |
|       | performance? Is this an item on the        |                 |
|       | verification checklists?                   |                 |
|       |                                            |                 |
|       | **Note:** This ensures that the test       |                 |
|       | cases/procedures for a named signal that   |                 |
|       | can be recorded and repeated.              |                 |
+-------+--------------------------------------------+-----------------+
| 3.6.4 | Will the procedure checklists reveal test  | -   6.2.1(1,3)  |
|       | cases that violate project standards?      |                 |
+-------+--------------------------------------------+-----------------+
| 3.6.5 | Will the procedures checklists reveal test | -   6.2.1(1,3)  |
|       | cases that are not expected to achieve     |                 |
|       | coverage of every functional element as    |                 |
|       | described in DO-254 Appendix B section     |                 |
|       | 3.3.1?                                     |                 |
+-------+--------------------------------------------+-----------------+
| 3.6.6 | Do the test case, procedures, and results  | -   6.2.1(1,3)  |
|       | checklists require evaluation of specified |                 |
|       | tolerances?                                |                 |
+-------+--------------------------------------------+-----------------+
| 3.6.7 | Have the test case, procedures, and        | -   6.2.1(1)    |
|       | results checklists been reviewed?          |                 |
|       |                                            | -   8.1(2)      |
+-------+--------------------------------------------+-----------------+
| **    | **Review and assess the test results.      |                 |
| 3.7** | Consider the following questions:**        |                 |
+-------+--------------------------------------------+-----------------+
| 3.7.1 | Are the test result files clearly linked   | -   6.2.1(2)    |
|       | to the test procedures and detailed design |                 |
|       | (i.e., does configuration control and      | -   7.1(1,2,3)  |
|       | traceability exist)?                       |                 |
+-------+--------------------------------------------+-----------------+
| 3.7.2 | Is each test result clearly linked to a    | -   6.2.1(2)    |
|       | test case?                                 |                 |
+-------+--------------------------------------------+-----------------+
| 3.7.3 | Are failed test cases obvious from the     | -   6.2.1(3)    |
|       | test results?                              |                 |
+-------+--------------------------------------------+-----------------+
| 3.7.4 | Do the test results indicate whether each  | -   6.2.1(3)    |
|       | procedure passed or failed and the final   |                 |
|       | pass/fail results?                         |                 |
+-------+--------------------------------------------+-----------------+
| 3.7.5 | Do the test results adhere to the relevant | -   6.2.1(1,3)  |
|       | plans, standards, and procedures?          |                 |
|       |                                            | -   8.1(2)      |
+-------+--------------------------------------------+-----------------+
| 3.7.6 | Witness at least one requirements-based    | -               |
|       | test and consider the following questions: |    6.2.1(1,2,3) |
|       |                                            |                 |
|       | Are the tests repeatable?                  | -   8.1(2)      |
|       |                                            |                 |
|       | Are the tests complete?                    |                 |
|       |                                            |                 |
|       | Do the results agree with what was         |                 |
|       | included in the test results?              |                 |
|       |                                            |                 |
|       | Does the test verify the requirement?      |                 |
+-------+--------------------------------------------+-----------------+
| 3.7.7 | Have all discrepancies between expected    | -               |
|       | results and actual results been            |    6.2.1(1,3,4) |
|       | documented, explained or fed back to the   |                 |
|       | appropriate process for resolution?        |                 |
+-------+--------------------------------------------+-----------------+
| 3.7.8 | Does traceability exist between test       | -   6.2.1(2)    |
|       | results, test cases and requirements       |                 |
+-------+--------------------------------------------+-----------------+
| 3.7.9 | Have the hardware requirements been        | -               |
|       | tested/verified?                           |    6.2.1(1,2,3) |
+-------+--------------------------------------------+-----------------+
| 3     | Does the reviewed data support the process | -   8.1(2)      |
| .7.10 | defined in the Hardware                    |                 |
|       | Validation/Verification Plan?              |                 |
+-------+--------------------------------------------+-----------------+
| 3     | Have the test results been subjected to    | -   7.1 (1,2,3) |
| .7.11 | appropriate configuration control?         |                 |
+-------+--------------------------------------------+-----------------+
| **    | **Review and assess failure explanations   |                 |
| 3.8** | and rework. Consider the following         |                 |
|       | questions:**                               |                 |
+-------+--------------------------------------------+-----------------+
| 3.8.1 | Is there an acceptable rationale for       | -   6.2.1(1,3)  |
|       | deviations from expected results,          |                 |
|       | standards, or plans?                       | -   8.1(2)      |
+-------+--------------------------------------------+-----------------+
| 3.8.2 | Are explanations for the failed test cases | -               |
|       | documented, understandable, and linked to  |    6.2.1(1,3,4) |
|       | relevant problem reports?                  |                 |
+-------+--------------------------------------------+-----------------+
| 3.8.3 | Are explanations for detailed design or    | -               |
|       | test rework suitable to address the        |    6.2.1(1,3,4) |
|       | failure?                                   |                 |
+-------+--------------------------------------------+-----------------+
| 3.8.4 | Have test cases been re-executed in        | -               |
|       | compliance with plans for regression       |    6.2.1(1,3,4) |
|       | testing?                                   |                 |
+-------+--------------------------------------------+-----------------+
| **    | **Review and assess verification coverage  |                 |
| 3.9** | achievement, considering the following     |                 |
|       | questions:**                               |                 |
+-------+--------------------------------------------+-----------------+
| 3.9.1 | Is 100% HDL coverage achieved through      | -   6.2.1(1)    |
|       | requirements-based testing? If 100%        |                 |
|       | coverage is not achieved through           |                 |
|       | requirements-based testing, is there an    |                 |
|       | explanation detailing which parts of the   |                 |
|       | code were not executed and why? Are        |                 |
|       | explanations for drops in coverage         |                 |
|       | sufficiently detailed and acceptable?      |                 |
+-------+--------------------------------------------+-----------------+
| **3   | **Review the integration process data to   |                 |
| .10** | determine compliance to DO-254.**          |                 |
+-------+--------------------------------------------+-----------------+
| 3     | How is each objective for the board level  | -   6.2.1(1)    |
| .10.1 | integration (including HW/SW integration)  |                 |
|       | and verification process met?              |                 |
+-------+--------------------------------------------+-----------------+
| 3     | Does the integration test process comply   | -   6.2.1(1)    |
| .10.2 | with the plans?                            |                 |
+-------+--------------------------------------------+-----------------+
| 3     | Are there any hardware verification        | -   6.2.1(1)    |
| .10.3 | objectives met by software (DO-178B)       |                 |
|       | verification activities? If so, are they   |                 |
|       | identified and documented?                 |                 |
+-------+--------------------------------------------+-----------------+
| **3   | **Review the Problem Reports and changes   |                 |
| .11** | to hardware life cycle data for impact on  |                 |
|       | hardware design.**                         |                 |
+-------+--------------------------------------------+-----------------+
| 3     | Is the applicant documenting problems as   | -   6.2.1(4)    |
| .11.1 | described in their plans (e.g., problem    |                 |
|       | reports)?                                  | -   8.1(2)      |
+-------+--------------------------------------------+-----------------+
| 3     | Is there a problem reporting process in    | -   6.2.1(4)    |
| .11.2 | place? Is there a change control process?  |                 |
|       | Is the applicant following the process?    | -   7.1(1,2,3)  |
+-------+--------------------------------------------+-----------------+
| 3     | Does the problem report adequately         | -   6.2.1(4)    |
| .11.3 | describe the deficiency or anomalous       |                 |
|       | behavior and the proposed change(s)?       |                 |
+-------+--------------------------------------------+-----------------+
| 3     | Are all effected hardware module(s)        | -   7.1(1,2,3)  |
| .11.4 | identified?                                |                 |
+-------+--------------------------------------------+-----------------+
| 3     | Was the configuration updated to reflect   | -   7.1(1,2,3)  |
| .11.5 | the new version(s)?                        |                 |
+-------+--------------------------------------------+-----------------+
| 3     | Does the description in the problem report | -   6.2.1(4)    |
| .11.6 | adequately describe the change made?       |                 |
+-------+--------------------------------------------+-----------------+
| 3     | Was the correct form for problem reports   | -   8.1(2)      |
| .11.7 | used?                                      |                 |
+-------+--------------------------------------------+-----------------+
| 3     | How was change authorization confirmed?    | -   8.1(2)      |
| .11.8 |                                            |                 |
+-------+--------------------------------------------+-----------------+
| 3     | Was the change documented in the prologue  | -   8.1(2)      |
| .11.9 | header?                                    |                 |
+-------+--------------------------------------------+-----------------+
| 3.    | If the change affected the hardware design | -   6.2.1(4)    |
| 11.10 | was the design data updated or a change    |                 |
|       | applied to the baseline?                   | -   7.1(1,2,3)  |
|       |                                            |                 |
|       |                                            | -   8.1(2)      |
+-------+--------------------------------------------+-----------------+
| 3.    | If the change effected the requirements,   | -   6.2.1(4)    |
| 11.11 | were the requirements updated or a change  |                 |
|       | applied to the baseline?                   | -   7.1(1,2,3)  |
|       |                                            |                 |
|       |                                            | -   8.1(2)      |
+-------+--------------------------------------------+-----------------+
| 3.    | Were retest, regression analysis, and      | -   6.2.1(4)    |
| 11.12 | safety affects addressed in the change     |                 |
|       | process?                                   | -   7.1(3)      |
+-------+--------------------------------------------+-----------------+
| **3   | **Review the Archival, Retrieval, and      |                 |
| .12** | Release Procedures.**                      |                 |
+-------+--------------------------------------------+-----------------+
| 3     | Was the product protected from             | -   7.1(3)      |
| .12.1 | unauthorized changes?                      |                 |
+-------+--------------------------------------------+-----------------+
| 3     | Does the storage medium minimize risk of   | -   7.1(2)      |
| .12.2 | deterioration and regeneration of errors?  |                 |
+-------+--------------------------------------------+-----------------+
| 3     | Are copies stored in physically separate   | -   7.1(2)      |
| .12.3 | archives for disaster recovery?            |                 |
+-------+--------------------------------------------+-----------------+
| 3     | Are there provisions to make and verify    | -   7.1(2)      |
| .12.4 | error free copies, including executable    |                 |
|       | document name, version, and date;          |                 |
|       | paragraph numbers; requirements            |                 |
|       | identification; and results?               |                 |
+-------+--------------------------------------------+-----------------+
| **3   | **If tool qualification is required for    |                 |
| .13** | verification tools, review tool            |                 |
|       | qualification data, considering the        |                 |
|       | following questions:**                     |                 |
+-------+--------------------------------------------+-----------------+
| 3     | Do the plans state which tools are being   | -   6.2.1(1)    |
| .13.1 | qualified and the rationale for            |                 |
|       | qualification?                             |                 |
|       |                                            |                 |
|       | **Note:** This might be in the Plan for    |                 |
|       | Hardware Aspects of Certification or a     |                 |
|       | separate tool qualification plan for       |                 |
|       | verification tools.                        |                 |
+-------+--------------------------------------------+-----------------+
| 3     | Are the specific verification tool         | -   6.2.1(1)    |
| .13.2 | requirements documented?                   |                 |
+-------+--------------------------------------------+-----------------+
| 3     | If a qualified tool is used for            | -   6.2.1(1)    |
| .13.3 | verification coverage, does the tool       |                 |
|       | qualification data address whether the     |                 |
|       | tool needs to instrument the HDL (if       |                 |
|       | applicable) to perform the analysis? If    |                 |
|       | the tool does need to instrument the HDL,  |                 |
|       | has the effect of the instrumentation on   |                 |
|       | the code been assessed?                    |                 |
+-------+--------------------------------------------+-----------------+
| 3     | Is the tool qualification analysis         | -   6.2.1(1,4)  |
| .13.4 | sufficient to discover errors in the       |                 |
|       | verification tool and limitations of the   |                 |
|       | tool's functions?                          |                 |
+-------+--------------------------------------------+-----------------+
| 3     | Does the tool qualification data address   | -   6.2.1(4)    |
| .13.5 | how tool deficiencies that are found while |                 |
|       | the verification tools are being used in a |                 |
|       | certification project should be handled?   |                 |
+-------+--------------------------------------------+-----------------+
| 3     | Does the tool qualification data detail    | -   7.1(3)      |
| .13.6 | how changes to the verification tool will  |                 |
|       | be evaluated and controlled?               |                 |
+-------+--------------------------------------------+-----------------+
| 3     | Are procedures for using each verification | -   6.2.1(1)    |
| .13.7 | tool documented?                           |                 |
+-------+--------------------------------------------+-----------------+
| **3   | **Review Level A & B Verification**        |                 |
| .14** |                                            |                 |
+-------+--------------------------------------------+-----------------+
| 3     | Have the independence requirements for     | -   6.2.1(1)    |
| .14.1 | verification been satisfied (see Appendix  |                 |
|       | B of DO-254)?                              |                 |
+-------+--------------------------------------------+-----------------+
| 3     | Is the functional failure path analysis    | -   6.2.1(1)    |
| .14.2 | (FFPA) complete (see Appendix B of         |                 |
|       | DO-254)?                                   |                 |
+-------+--------------------------------------------+-----------------+
| 3     | Are the functional failure paths           | -   6.2.1(1)    |
| .14.3 | identified (see Appendix B of DO-254)?     |                 |
+-------+--------------------------------------------+-----------------+
| 3     | Is the additional assurance method         | -   6.2.1(1)    |
| .14.4 | appropriate and complete (see Appendix B   |                 |
|       | of DO-254)?                                |                 |
+-------+--------------------------------------------+-----------------+

## 3.4 Activities for Stage of Involvement #4 -- FINAL REVIEW

+------------------+---------------------------------------------------+
| ### Purpose      | -   Determine if final compliance to all of the   |
|                  |     DO-254 objectives has been achieved and all   |
|                  |     open items addressed/dispositioned.           |
|                  |                                                   |
|                  | -   Assess the Hardware Configuration Management  |
|                  |     Records (including those for the hardware     |
|                  |     life cycle environment), Hardware             |
|                  |     Accomplishment Summary, and any other         |
|                  |     documents not previously reviewed.            |
+------------------+---------------------------------------------------+
| ###              | When the hardware life cycle is completed, and    |
|  When to Perform | the following items have been completed by the    |
|                  | applicant (or when deemed necessary):             |
|                  |                                                   |
|                  | Hardware conformity review has been performed.    |
|                  |                                                   |
|                  | Hardware Configuration Management Records have    |
|                  | been reviewed and are correct.                    |
|                  |                                                   |
|                  | Formal signature process has been completed.      |
+------------------+---------------------------------------------------+
| ### Da           | Reports from SOI #1, SOI #2, and/or SOI #3; open  |
| ta to Review Pri | items from\                                       |
| or to the Review | SOI #1, SOI #2, and/or SOI #3; all plans;         |
|                  | Hardware Accomplishment Summary; and Hardware     |
|                  | Configuration Management Records.                 |
+------------------+---------------------------------------------------+
| ### Data to Revi | Hardware Configuration Management Records;        |
| ew at the Review | Problem Reports; Hardware Accomplishment Summary; |
|                  | Designees' findings/observations from pre-review  |
|                  | activities; and any data that had issues in       |
|                  | previous reviews.                                 |
+------------------+---------------------------------------------------+
| ##               | 1-3 days                                          |
| # Number of Days |                                                   |
|                  | **Note 1:** If SOI #1, SOI #2, and SOI #3 have    |
|                  | been performed, SOI #4 may only be an assessment  |
|                  | of whether or not outstanding issues have been    |
|                  | resolved (in this case the review might take only |
|                  | 1 day).                                           |
|                  |                                                   |
|                  | **Note 2:** If SOI #1, SOI #2, and SOI #3 were    |
|                  | not performed, this review could take much        |
|                  | longer.                                           |
+------------------+---------------------------------------------------+
| ### Evaluati     | During SOI #4 the Hardware Accomplishment Summary |
| on Activities an | and Hardware Configuration Management Records are |
| d Questions {#ev | evaluated. Additionally, open items from previous |
| aluation-activit | reviews are evaluated to ensure that all of the   |
| ies-and-question | DO-254 objectives and project issues are          |
| s-3 .unnumbered} | addressed. Table 8 provides typical activities    |
|                  | and questions for SOI #4.                         |
+------------------+---------------------------------------------------+
| ### Instructions | There are ten evaluation activities/questions for |
|                  | Stage of Involvement #4 - Final Review.           |
|                  |                                                   |
|                  | Review the questions for each activity in         |
|                  | relationship to its corresponding DO-254          |
|                  | objective and level.                              |
+------------------+---------------------------------------------------+

[]{#__RefHeading___Toc191963524 .anchor}Table 8. SOI #4 Evaluation
Activities

+------+------------------------------------------------+-------------+
| **   | **SOI #4 Evaluation Activity/Question**        | **Related   |
| Item |                                                | DO-254      |
| \#** |                                                | obj         |
|      |                                                | ective(s)** |
+======+================================================+=============+
| 4.1  | Were activities performed from SOI #1, SOI #2, | -   All     |
|      | or SOI #3 that were not previously completed   |             |
|      | or that were not found satisfactory and        |             |
|      | required changes completed?                    |             |
+------+------------------------------------------------+-------------+
| 4.2  | Has the Hardware Accomplishment Summary been   | -           |
|      | reviewed (e.g., includes the required          |  8.1(1,2,3) |
|      | information and addresses hardware             |             |
|      | identification, change history, hardware       |             |
|      | status (unresolved problems and limitations)   |             |
|      | and compliance statement)? See section 10.9 of |             |
|      | DO-254.                                        |             |
+------+------------------------------------------------+-------------+
| 4.3  | Do the Hardware Configuration Management       | -           |
|      | Records adequately identify all elements of    |  7.1(1,2,3) |
|      | the hardware life cycle environment necessary  |             |
|      | for hardware regeneration, reverification, or  |             |
|      | hardware modification?                         |             |
+------+------------------------------------------------+-------------+
| 4.4  | Do the Hardware Configuration Management       | -           |
|      | Records adequately identify the hardware item  |  7.1(1,2,3) |
|      | and all subassemblies and subcomponents?       |             |
+------+------------------------------------------------+-------------+
| 4.5  | Are all required hardware life cycle data      | -           |
|      | under appropriate configuration control?       |  7.1(1,2,3) |
+------+------------------------------------------------+-------------+
| 4.6  | In assessing problem reports, determine if the | -           |
|      | following have been properly analyzed and      |  8.1(1,2,3) |
|      | addressed:                                     |             |
|      |                                                |             |
|      | Are there any open problem reports that affect |             |
|      | safety? Is there a person or organization      |             |
|      | whose responsibilities ensure that any safety  |             |
|      | implications of leaving these problem reports  |             |
|      | open have been properly addressed?             |             |
|      |                                                |             |
|      | Are there any open problem reports that affect |             |
|      | operations?                                    |             |
|      |                                                |             |
|      | Are the open problem reports categorized       |             |
|      | correctly (e.g., "impacts safety" vs. "product |             |
|      | improvement")?                                 |             |
|      |                                                |             |
|      | Have problem reports been adequately analyzed? |             |
+------+------------------------------------------------+-------------+
| 4.7  | Complete the Summary of                        | -           |
|      | Compliances/Findings/Observations table for    |  8.1(1,2,3) |
|      | all objectives for the appropriate hardware    |             |
|      | level.                                         |             |
+------+------------------------------------------------+-------------+
| 4.8  | Does the system still satisfy the safety       | -           |
|      | assessment objectives? Ensure that the planned |  8.1(1,2,3) |
|      | safety objectives were actually addressed in   |             |
|      | the project implementation. Is there a person  |             |
|      | or organization whose responsibilities ensure  |             |
|      | that the system design addresses all the       |             |
|      | safety assessment objectives?                  |             |
+------+------------------------------------------------+-------------+
| 4.9  | Ensure that all applicable DO-254 objectives   | -           |
|      | have been satisfied.                           |  8.1(1,2,3) |
+------+------------------------------------------------+-------------+
| 4.10 | Was the hardware conformity review performed   | -           |
|      | on the "as-built" system? Do the Hardware      |  7.1(1,2,3) |
|      | Configuration Management Records capture the   |             |
|      | "as-built" information? (See section           | -           |
|      | 10.3.2.2.1 of DO-254.)                         |  8.1(1,2,3) |
+------+------------------------------------------------+-------------+

# Part 4 - Summarizing Compliances, Findings, and Observations for each DO-254 Objective

This section provides a way to tie the applicant's activities and
compliance with the objectives of DO-254 and to document any findings
and observations. For each objective, the review team evaluates what
evidence exists to verify compliance. The "Summary of Compliances/
Findings/Observations" form is included on the following pages. This
form flags any issues found during a hardware review that may be
considered certification issues. If the objective is not met, the reason
for non-compliance should be stated in the form. This form provides a
summary and tracking mechanism for discussions with the applicant.

While carrying out the activities/questions in Part 3 of the Job Aid,
findings and observations are typically made. Findings should be mapped
against the objectives of DO-254 using the Summary of
Compliances/Findings/Observations form in this section. Observations may
also be recorded in these tables, if desired; however, it should be
clearly stated which are observations and which are findings.
Additionally, the compliances to DO-254 objectives that were evaluated
should be documented.

The Summary of Compliances/Findings/Observations form has four columns.
The first column summarizes the DO-254 objectives. The second column
provides reference to a DO-254 section. The third column provides a
place to record the Compliances/Findings/Observations found during a
review. The last column provides a tie back to the Job Aid tables in
Part 3 of this Job Aid.

Completion of these tables should be performed during and/or after the
hardware review and should be included as part of the review report. All
applicable DO-254 objectives should be assessed for compliance. Any
actions and issues should also be noted during the review, but will
likely be summarized in a separate table, since they may not tie to
specific DO-254 objectives.

**Note:** This section provides one way to summarize review results.
Appendix A provides an alternate approach that may be effective as well.
In both cases, it is important to evaluate all applicable DO-254
objectives and to document where compliances have been found and where
findings and/or observations exist.

[]{#__RefHeading___Toc191963525 .anchor}Table 9. Documenting Review
Compliances/Findings/Observations (C/F/O)

+-----------------+---+------+--------------------------------+---------+
| **Objective     |   | **DO | **Summary of**                 | **Job** |
| Summary**       |   | -254 |                                |         |
|                 |   | sec  | **Compliances/                 | **Aid** |
|                 |   | tion | Findings/Observations**        |         |
|                 |   | ref  |                                | *       |
|                 |   | eren |                                | *Ref.** |
|                 |   | ce** |                                |         |
+=================+===+======+================================+=========+
| > **Planning**  |   |      |                                | []      |
|                 |   |      |                                | {.mark} |
+-----------------+---+------+--------------------------------+---------+
| > The hardware  | 4 |      |                                | 1.1,    |
| > design life   | . |      |                                | 1.2,    |
| > cycle         | 1 |      |                                | 1.3,    |
| > processes are | ( |      |                                | 1.4,    |
| > defined.      | 1 |      |                                | 1.5,    |
|                 | ) |      |                                | 1.6,    |
|                 |   |      |                                | 1.7,    |
|                 |   |      |                                | 1.8,    |
|                 |   |      |                                | 2.1,    |
|                 |   |      |                                | 3.1     |
+-----------------+---+------+--------------------------------+---------+
| > The hardware  | 4 |      |                                | 1.1,    |
| > development   | . |      |                                | 1.2,    |
| > and           | 1 |      |                                | 1.3,    |
| > verification  | ( |      |                                | 1.4,    |
| > environments  | 2 |      |                                | 1.5,    |
| > are selected  | ) |      |                                | 1.6,    |
| > or defined.   |   |      |                                | 1.7,    |
|                 |   |      |                                | 1.8,    |
|                 |   |      |                                | 2.1,    |
|                 |   |      |                                | 2.2,    |
|                 |   |      |                                | 3.1     |
+-----------------+---+------+--------------------------------+---------+
| The means of    | 4 |      |                                | 1.1,    |
| compliance of   | . |      |                                | 1.2,    |
| the hardware    | 1 |      |                                | 1.3,    |
| design          | ( |      |                                | 1.4,    |
| assurance       | 3 |      |                                | 1.5,    |
| objectives,     | ) |      |                                | 1.6,    |
| including       |   |      |                                | 1.7,    |
| strategies      |   |      |                                | 1.8,    |
| identified      |   |      |                                | 2.1,    |
| using guidance  |   |      |                                | 3.1     |
| in Section      |   |      |                                |         |
| 2.3.4, are      |   |      |                                |         |
| proposed to the |   |      |                                |         |
| Certification   |   |      |                                |         |
| Authority.      |   |      |                                |         |
+-----------------+---+------+--------------------------------+---------+
| Standards are   | 4 |      |                                | 1.1,    |
| selected and    | . |      |                                | 1.2,    |
| defined.        | 1 |      |                                | 1.3,    |
|                 | ( |      |                                | 1.4,    |
|                 | 4 |      |                                | 1.5,    |
|                 | ) |      |                                | 1.8,    |
|                 |   |      |                                | 2.1,    |
|                 |   |      |                                | 3.1     |
+-----------------+---+------+--------------------------------+---------+
| >               |   |      |                                |         |
|  **Requirements |   |      |                                |         |
| > Capture**     |   |      |                                |         |
+-----------------+---+------+--------------------------------+---------+
| > Requirements  | 5 |      |                                | 1.4,    |
| > are           | . |      |                                | 2.2,    |
| > identified,   | 1 |      |                                | 3.1     |
| > defined and   | . |      |                                |         |
| > documented.   | 1 |      |                                |         |
|                 | ( |      |                                |         |
|                 | 1 |      |                                |         |
|                 | ) |      |                                |         |
+-----------------+---+------+--------------------------------+---------+
| > Derived       | 5 |      |                                | 1.4,    |
| > requirements  | . |      |                                | 2.2,    |
| > produced are  | 1 |      |                                | 3.1     |
| > fed back to   | . |      |                                |         |
| > the           | 1 |      |                                |         |
| > appropriate   | ( |      |                                |         |
| > process.      | 2 |      |                                |         |
|                 | ) |      |                                |         |
+-----------------+---+------+--------------------------------+---------+
| > Requirement   | 5 |      |                                | 1.4,    |
| > omissions and | . |      |                                | 2.2,    |
| > errors are    | 1 |      |                                | 3.1     |
| > provided to   | . |      |                                |         |
| > the           | 1 |      |                                |         |
| > appropriate   | ( |      |                                |         |
| > process for   | 3 |      |                                |         |
| > resolution.   | ) |      |                                |         |
+-----------------+---+------+--------------------------------+---------+
| > **Conceptual  |   |      |                                |         |
| > Design**      |   |      |                                |         |
+-----------------+---+------+--------------------------------+---------+
| > The hardware  | 5 |      |                                | 1.4,    |
| > item          | . |      |                                | 2.2,    |
| > conceptual    | 2 |      |                                | 2.3,    |
| > design is     | . |      |                                | 3.1     |
| > developed     | 1 |      |                                |         |
| > consistent    | ( |      |                                |         |
| > with its      | 1 |      |                                |         |
| > requirements. | ) |      |                                |         |
+-----------------+---+------+--------------------------------+---------+
| > Derived       | 5 |      |                                | 1.4,    |
| > requirements  | . |      |                                | 2.3,    |
| > produced are  | 2 |      |                                | 3.1     |
| > fed back to   | . |      |                                |         |
| > the           | 1 |      |                                |         |
| > requirements  | ( |      |                                |         |
| > capture or    | 2 |      |                                |         |
| > other         | ) |      |                                |         |
| > appropriate   |   |      |                                |         |
| > processes.    |   |      |                                |         |
+-----------------+---+------+--------------------------------+---------+
| > Requirement   | 5 |      |                                | 1.4,    |
| > omissions and | . |      |                                | 2.3,    |
| > errors are    | 2 |      |                                | 3.1     |
| > provided to   | . |      |                                |         |
| > the           | 1 |      |                                |         |
| > appropriate   | ( |      |                                |         |
| > process for   | 3 |      |                                |         |
| > resolution.   | ) |      |                                |         |
+-----------------+---+------+--------------------------------+---------+
| > **Detailed    |   |      |                                |         |
| > Design**      |   |      |                                |         |
+-----------------+---+------+--------------------------------+---------+
| > Detailed      | > |      |                                | 1.4,    |
| > design is     |   |      |                                | 2.2,    |
| > developed     | 5 |      |                                | 2.4,    |
| > from the      | . |      |                                | 3.1     |
| > hardware item | 3 |      |                                |         |
| > requirements  | . |      |                                |         |
| > and           | 1 |      |                                |         |
| > conceptual    | ( |      |                                |         |
| > design data.  | 1 |      |                                |         |
|                 | ) |      |                                |         |
+-----------------+---+------+--------------------------------+---------+
| > Derived       | > |      |                                | 1.4,    |
| > requirements  |   |      |                                | 2.4,    |
| > are fed back  | 5 |      |                                | 3.1     |
| > to the        | . |      |                                |         |
| > conceptual    | 3 |      |                                |         |
| > design        | . |      |                                |         |
| > process or    | 1 |      |                                |         |
| > other         | ( |      |                                |         |
| > appropriate   | 2 |      |                                |         |
| > processes.    | ) |      |                                |         |
+-----------------+---+------+--------------------------------+---------+
| > Requirement   | > |      |                                | 1.4,    |
| > omissions and |   |      |                                | 2.4,    |
| > errors are    | 5 |      |                                | 3.1     |
| > provided to   | . |      |                                |         |
| > the           | 3 |      |                                |         |
| > appropriate   | . |      |                                |         |
| > process for   | 1 |      |                                |         |
| > resolution    | ( |      |                                |         |
|                 | 3 |      |                                |         |
|                 | ) |      |                                |         |
+-----------------+---+------+--------------------------------+---------+
| > **I           |   |      |                                |         |
| mplementation** |   |      |                                |         |
+-----------------+---+------+--------------------------------+---------+
| > A hardware    | 5 |      |                                | 1.4,    |
| > item is       | . |      |                                | 2.5,    |
| > produced      | 4 |      |                                | 3.1     |
| > which         | . |      |                                |         |
| > implements    | 1 |      |                                |         |
| > the hardware  | ( |      |                                |         |
| > detailed      | 1 |      |                                |         |
| > design using  | ) |      |                                |         |
| > the           |   |      |                                |         |
| >               |   |      |                                |         |
|  representative |   |      |                                |         |
| > manufacturing |   |      |                                |         |
| > processes.    |   |      |                                |         |
+-----------------+---+------+--------------------------------+---------+
| > The hardware  | 5 |      |                                | 1.4,    |
| > item          | . |      |                                | 2.5,    |
| >               | 4 |      |                                | 3.1     |
| implementation, | . |      |                                |         |
| > assembly and  | 1 |      |                                |         |
| > installation  | ( |      |                                |         |
| > data is       | 2 |      |                                |         |
| > complete.     | ) |      |                                |         |
+-----------------+---+------+--------------------------------+---------+
| Derived         | 5 |      |                                | 1.4,    |
| requirements    | . |      |                                | 2.5,    |
| are fed back to | 4 |      |                                | 3.1     |
| the conceptual  | . |      |                                |         |
| design process  | 1 |      |                                |         |
| or other        | ( |      |                                |         |
| appropriate     | 3 |      |                                |         |
| processes.      | ) |      |                                |         |
+-----------------+---+------+--------------------------------+---------+
| Requirements    | 5 |      |                                | 1.4,    |
| omissions and   | . |      |                                | 2.5     |
| errors are      | 4 |      |                                |         |
| provided to the | . |      |                                |         |
| appropriate     | 1 |      |                                |         |
| processes for   | ( |      |                                |         |
| resolution.     | 4 |      |                                |         |
|                 | ) |      |                                |         |
+-----------------+---+------+--------------------------------+---------+
| > **Production  |   |      |                                |         |
| > Transition**  |   |      |                                |         |
+-----------------+---+------+--------------------------------+---------+
| > A baseline is | 5 |      |                                | 1.4,    |
| > established   | . |      |                                | 2.6,    |
| > that includes | 5 |      |                                | 3.1     |
| > all design    | . |      |                                |         |
| > and           | 1 |      |                                |         |
| > manufacturing | ( |      |                                |         |
| > data needed   | 1 |      |                                |         |
| > to support    | ) |      |                                |         |
| > the           |   |      |                                |         |
| > consistent    |   |      |                                |         |
| > replication   |   |      |                                |         |
| > of the        |   |      |                                |         |
| > hardware      |   |      |                                |         |
| > item.         |   |      |                                |         |
+-----------------+---+------+--------------------------------+---------+
| > Manufacturing | 5 |      |                                | 1.4,    |
| > requirements  | . |      |                                | 2.6,    |
| > related to    | 5 |      |                                | 3.1     |
| > safety are    | . |      |                                |         |
| > identified    | 1 |      |                                |         |
| > and           | ( |      |                                |         |
| > documented    | 2 |      |                                |         |
| > and           | ) |      |                                |         |
| > manufacturing |   |      |                                |         |
| > controls are  |   |      |                                |         |
| > established.  |   |      |                                |         |
+-----------------+---+------+--------------------------------+---------+
| > Derived       | 5 |      |                                | 1.4,    |
| > requirements  | . |      |                                | 2.6,    |
| > are fed back  | 5 |      |                                | 3.1     |
| > to the        | . |      |                                |         |
| >               | 1 |      |                                |         |
|  implementation | ( |      |                                |         |
| > process or    | 3 |      |                                |         |
| > other         | ) |      |                                |         |
| > appropriate   |   |      |                                |         |
| > processes.    |   |      |                                |         |
+-----------------+---+------+--------------------------------+---------+
| -   Errors and  | 5 |      |                                | 2.6,    |
|     omissions   | . |      |                                | 3.1     |
|     are         | 5 |      |                                |         |
|     provided to | . |      |                                |         |
|     the         | 1 |      |                                |         |
|     appropriate | ( |      |                                |         |
|     processes   | 4 |      |                                |         |
|     for         | ) |      |                                |         |
|     resolution. |   |      |                                |         |
+-----------------+---+------+--------------------------------+---------+
| >               |   |      |                                |         |
|  **Validation** |   |      |                                |         |
+-----------------+---+------+--------------------------------+---------+
| > Derived       | 6 |      |                                | 1.7,    |
| > hardware      | . |      |                                | 2.2,    |
| > requirements  | 1 |      |                                | 3.3     |
| > against which | . |      |                                |         |
| > the hardware  | 1 |      |                                |         |
| > item is to be | ( |      |                                |         |
| > verified are  | 1 |      |                                |         |
| > correct and   | ) |      |                                |         |
| > complete.     |   |      |                                |         |
+-----------------+---+------+--------------------------------+---------+
| > Derived       | 6 |      |                                | 1.7,    |
| > requirements  | . |      |                                | 3.3     |
| > are evaluated | 1 |      |                                |         |
| > for impact on | . |      |                                |         |
| > safety.       | 1 |      |                                |         |
|                 | ( |      |                                |         |
|                 | 2 |      |                                |         |
|                 | ) |      |                                |         |
+-----------------+---+------+--------------------------------+---------+
| -   Omissions   | 6 |      |                                | 1.7,    |
|     and errors  | . |      |                                | 3.3     |
|     are fed     | 1 |      |                                |         |
|     back to the | . |      |                                |         |
|     appropriate | 1 |      |                                |         |
|     processes   | ( |      |                                |         |
|     for         | 3 |      |                                |         |
|     resolution. | ) |      |                                |         |
+-----------------+---+------+--------------------------------+---------+
| > *             |   |      |                                |         |
| *Verification** |   |      |                                |         |
+-----------------+---+------+--------------------------------+---------+
| > Evidence is   | 6 |      |                                | 1.7,    |
| > provided that | . |      |                                | 2.2,    |
| > the hardware  | 2 |      |                                | 3.4,    |
| >               | . |      |                                | 3.5,    |
|  implementation | 1 |      |                                | 3.6,    |
| > meets the     | ( |      |                                | 3.7,    |
| > requirements. | 1 |      |                                | 3.9,    |
|                 | ) |      |                                | 3.10,   |
|                 |   |      |                                | 3.13,   |
|                 |   |      |                                | 3.14    |
+-----------------+---+------+--------------------------------+---------+
| > Traceability  | 6 |      |                                | 1.7,    |
| > is            | . |      |                                | 2.2,    |
| > established   | 2 |      |                                | 2.3,    |
| > between       | . |      |                                | 2.4,    |
| > hardware      | 1 |      |                                | 2.5,    |
| > requirements, | ( |      |                                | 3.4,    |
| > the           | 2 |      |                                | 3.5,    |
| >               | ) |      |                                | 3.7,    |
| implementation, |   |      |                                | 3.8     |
| > and the       |   |      |                                |         |
| > verification  |   |      |                                |         |
| > procedures    |   |      |                                |         |
| > and results.  |   |      |                                |         |
+-----------------+---+------+--------------------------------+---------+
| > Acceptance    | 6 |      |                                | 1.7,    |
| > test criteria | . |      |                                | 2.2,    |
| > are           | 2 |      |                                | 3.5,    |
| > identified,   | . |      |                                | 3.6,    |
| > can be        | 1 |      |                                | 3.7,    |
| > implemented   | ( |      |                                | 3.8     |
| > and are       | 3 |      |                                |         |
| > consistent    | ) |      |                                |         |
| > with the      |   |      |                                |         |
| > hardware      |   |      |                                |         |
| > design        |   |      |                                |         |
| > assurance     |   |      |                                |         |
| > levels of the |   |      |                                |         |
| > hardware      |   |      |                                |         |
| > functions.    |   |      |                                |         |
+-----------------+---+------+--------------------------------+---------+
| -   Omissions   | 6 |      |                                | 3.6,    |
|     and errors  | . |      |                                | 3.7,    |
|     are fed     | 2 |      |                                | 3.8,    |
|     back to the | . |      |                                | 3.11,   |
|     appropriate | 1 |      |                                | 3.13    |
|     processes   | ( |      |                                |         |
|     for         | 4 |      |                                |         |
|     resolution. | ) |      |                                |         |
+-----------------+---+------+--------------------------------+---------+
| >               |   |      |                                |         |
| **Configuration |   |      |                                |         |
| > Management**  |   |      |                                |         |
+-----------------+---+------+--------------------------------+---------+
| > Configuration | > |      |                                | 1.1,    |
| > items are     |   |      |                                | 1.3,    |
| > uniquely      | 7 |      |                                | 1.5,    |
| > identified    | . |      |                                | 2.2,    |
| > and           | 1 |      |                                | 2.3,    |
| > documented.   | ( |      |                                | 3.5,    |
|                 | 1 |      |                                | 3.7,    |
|                 | ) |      |                                | 3.11,   |
|                 |   |      |                                | 4.0     |
+-----------------+---+------+--------------------------------+---------+
| > Consistent    | > |      |                                | 1.1,    |
| > and accurate  |   |      |                                | 1.3,    |
| > replication   | 7 |      |                                | 1.5,    |
| > of            | . |      |                                | 2.2,    |
| > configuration | 1 |      |                                | 2.3,    |
| > items is      | ( |      |                                | 3.5,    |
| > ensured.      | 2 |      |                                | 3.7,    |
|                 | ) |      |                                | 3.11,   |
|                 |   |      |                                | 3.12,   |
|                 |   |      |                                | 4.0     |
+-----------------+---+------+--------------------------------+---------+
| > A controlled  | > |      |                                | 1.1,    |
| > method of     |   |      |                                | 1.3,    |
| > identifying   | 7 |      |                                | 1.5,    |
| > and tracking  | . |      |                                | 1.6,    |
| > modification  | 1 |      |                                | 2.2,    |
| > to            | ( |      |                                | 2.3,    |
| > configuration | 3 |      |                                | 3.5,    |
| > items is      | ) |      |                                | 3.7,    |
| > provided.     |   |      |                                | 3.11,   |
|                 |   |      |                                | 3.1     |
|                 |   |      |                                | 2,3.13, |
|                 |   |      |                                | 4.0     |
+-----------------+---+------+--------------------------------+---------+
| > **Process     |   |      |                                |         |
| > Assurance**   |   |      |                                |         |
+-----------------+---+------+--------------------------------+---------+
| > Life cycle    | > |      |                                | 1.6,    |
| > processes     |   |      |                                | 2.2,    |
| > comply with   | 8 |      |                                | 3.2,    |
| > the approved  | . |      |                                | 4.0     |
| > plans.        | 1 |      |                                |         |
|                 | ( |      |                                |         |
|                 | 1 |      |                                |         |
|                 | ) |      |                                |         |
+-----------------+---+------+--------------------------------+---------+
| > Hardware      | > |      |                                | 1.6,    |
| > design life   |   |      |                                | 2.2,    |
| > cycle data    | 8 |      |                                | 3.2,    |
| > produced      | . |      |                                | 3.6,    |
| > complies with | 1 |      |                                | 3.7,    |
| > the approved  | ( |      |                                | 3.8,    |
| > plans.        | 2 |      |                                | 3.11,   |
|                 | ) |      |                                | 4.0     |
+-----------------+---+------+--------------------------------+---------+
| The hardware    | > |      |                                | 1.6,    |
| item used for   |   |      |                                | 4.0     |
| conformance     | 8 |      |                                |         |
| assessment is   | . |      |                                |         |
| built to comply | 1 |      |                                |         |
| with the        | ( |      |                                |         |
| associated life | 3 |      |                                |         |
| cycle data.     | ) |      |                                |         |
+-----------------+---+------+--------------------------------+---------+

**Note:** The material contained in Table 9.regarding DO-254 objectives
is copyrighted by RTCA, Inc. and used with permission. DO-254, along
with all RTCA, Inc. documents, may be purchased directly from RTCA, Inc.
To order a copy of DO-254 or any other RTCA, Inc. documents, please
contact:

RTCA, Inc.

1828 L Street, N.W.

Suite 805

Washington D.C. 20036

Ph. 202-833-9339

Fax 202-833-9434

www.rtca.org

# Appendix A -- Alternate Approach for Recording Compliances/Findings/Observation

[]{#__RefHeading___Toc191963526 .anchor}Table A1. Alternate Method for
Documenting Review Compliances/Findings/Observations

  -----------------------------------------------------------------------------------------
  **Item   **Doc**   **DO-254   **C/F/O**   **Description**   **Applicant      **Status**
  \#**               Obj.**                                   Response**       
  -------- --------- ---------- ----------- ----------------- ---------------- ------------
  Note 1   Note 2    Note 3     Note 4      Note 5            Note 6           Note 7

                                                                               

                                                                               

                                                                               
  -----------------------------------------------------------------------------------------

Note 1: Number the item for future reference.

Note 2: Include document or data that the finding or observation is made
against.

Note 3: Include the applicable DO-254 objective(s)

Note 4: Classify the item as a finding (F), observation (O), or
compliance (C). Issues (I), actions (A), and notes (N) might also be
included in this format.

Note 5: Describe the review finding or observation -- be specific

Note 6: Allow space for the applicant to respond to each item of the
review report. This will typically include their strategy for dealing
with the finding or observation.

Note 7: Document status of items, as the project matures. The goal is
for all findings to be closed or properly dispositioned.

# Appendix B -- DO-254 Objectives Summary

[]{#__RefHeading___Toc191963527 .anchor}Table B1. Hardware Planning
Process

+---+--------------------+------+-----------------+---+---+---+---+---+
|   | **Objective**      |      | **Hardware**    |   | * |   |   |   |
|   |                    |      |                 |   | * |   |   |   |
|   |                    |      | **Life Cycle    |   | C |   |   |   |
|   |                    |      | Data**          |   | o |   |   |   |
|   |                    |      |                 |   | n |   |   |   |
|   |                    |      |                 |   | t |   |   |   |
|   |                    |      |                 |   | r |   |   |   |
|   |                    |      |                 |   | o |   |   |   |
|   |                    |      |                 |   | l |   |   |   |
|   |                    |      |                 |   | C |   |   |   |
|   |                    |      |                 |   | a |   |   |   |
|   |                    |      |                 |   | t |   |   |   |
|   |                    |      |                 |   | e |   |   |   |
|   |                    |      |                 |   | g |   |   |   |
|   |                    |      |                 |   | o |   |   |   |
|   |                    |      |                 |   | r |   |   |   |
|   |                    |      |                 |   | y |   |   |   |
|   |                    |      |                 |   | B |   |   |   |
|   |                    |      |                 |   | y |   |   |   |
|   |                    |      |                 |   | * |   |   |   |
|   |                    |      |                 |   | * |   |   |   |
|   |                    |      |                 |   |   |   |   |   |
|   |                    |      |                 |   | * |   |   |   |
|   |                    |      |                 |   | * |   |   |   |
|   |                    |      |                 |   | H |   |   |   |
|   |                    |      |                 |   | W |   |   |   |
|   |                    |      |                 |   | A |   |   |   |
|   |                    |      |                 |   | s |   |   |   |
|   |                    |      |                 |   | s |   |   |   |
|   |                    |      |                 |   | u |   |   |   |
|   |                    |      |                 |   | r |   |   |   |
|   |                    |      |                 |   | a |   |   |   |
|   |                    |      |                 |   | n |   |   |   |
|   |                    |      |                 |   | c |   |   |   |
|   |                    |      |                 |   | e |   |   |   |
|   |                    |      |                 |   | L |   |   |   |
|   |                    |      |                 |   | e |   |   |   |
|   |                    |      |                 |   | v |   |   |   |
|   |                    |      |                 |   | e |   |   |   |
|   |                    |      |                 |   | l |   |   |   |
|   |                    |      |                 |   | * |   |   |   |
|   |                    |      |                 |   | * |   |   |   |
+---+--------------------+------+-----------------+---+---+---+---+---+
|   | **Description**    | **Re | **Description** | * | * | * | * | * |
|   |                    | f.** |                 | * | * | * | * | * |
|   |                    |      |                 | R | A | B | C | D |
|   |                    |      |                 | e | * | * | * | * |
|   |                    |      |                 | f | * | * | * | * |
|   |                    |      |                 | . |   |   |   |   |
|   |                    |      |                 | * |   |   |   |   |
|   |                    |      |                 | * |   |   |   |   |
+---+--------------------+------+-----------------+---+---+---+---+---+
| * | > The hardware     | 4.   | > Plan for      | 1 | H | H | H | H |
| * | > design life      | 1(1) | > Hardware      | 0 | C | C | C | C |
| 1 | > cycle processes  |      | > Aspects of    | . | 1 | 1 | 1 | 1 |
| * | > are defined.     |      | > Certification | 1 |   |   |   |   |
| * |                    |      | >               | . | H | H | H | N |
|   |                    |      | > Hardware      | 1 | C | C | C | A |
|   |                    |      | > Design Plan   |   | 2 | 2 | 2 |   |
|   |                    |      | >               | 1 |   |   |   | N |
|   |                    |      | > Hardware      | 0 | H | H | H | A |
|   |                    |      | > Validation    | . | C | C | C |   |
|   |                    |      | > Plan (Note 3  | 1 | 2 | 2 | 2 | H |
|   |                    |      | > & 4)          | . |   |   |   | C |
|   |                    |      | >               | 2 | H | H | H | 2 |
|   |                    |      | > Hardware      |   | C | C | C |   |
|   |                    |      | > Verification  | 1 | 2 | 2 | 2 | H |
|   |                    |      | > Plan          | 0 |   |   |   | C |
|   |                    |      | >               | . | H | H | H | 2 |
|   |                    |      | > Hardware      | 1 | C | C | C |   |
|   |                    |      | > Configuration | . | 1 | 1 | 2 | N |
|   |                    |      | > Plan          | 3 |   |   |   | A |
|   |                    |      | >               |   | H | H | N |   |
|   |                    |      | > Hardware      | 1 | C | C | A |   |
|   |                    |      | > Process       | 0 | 2 | 2 |   |   |
|   |                    |      | > Assurance     | . |   |   |   |   |
|   |                    |      | > Plan (except  | 1 |   |   |   |   |
|   |                    |      | > objective.    | . |   |   |   |   |
|   |                    |      | > 4.1.(3))      | 4 |   |   |   |   |
|   |                    |      |                 |   |   |   |   |   |
|   |                    |      |                 | 1 |   |   |   |   |
|   |                    |      |                 | 0 |   |   |   |   |
|   |                    |      |                 | . |   |   |   |   |
|   |                    |      |                 | 1 |   |   |   |   |
|   |                    |      |                 | . |   |   |   |   |
|   |                    |      |                 | 5 |   |   |   |   |
|   |                    |      |                 |   |   |   |   |   |
|   |                    |      |                 | 1 |   |   |   |   |
|   |                    |      |                 | 0 |   |   |   |   |
|   |                    |      |                 | . |   |   |   |   |
|   |                    |      |                 | 1 |   |   |   |   |
|   |                    |      |                 | . |   |   |   |   |
|   |                    |      |                 | 6 |   |   |   |   |
+---+--------------------+------+-----------------+---+---+---+---+---+
| * | > The hardware     | 4.   |                 |   |   |   |   |   |
| * | > development and  | 1(3) |                 |   |   |   |   |   |
| 2 | > verification     |      |                 |   |   |   |   |   |
| * | > environments are |      |                 |   |   |   |   |   |
| * | > selected or      |      |                 |   |   |   |   |   |
|   | > defined.         |      |                 |   |   |   |   |   |
+---+--------------------+------+-----------------+---+---+---+---+---+
| * | > The means of     | 4.   |                 |   |   |   |   |   |
| * | > compliance of    | 1(4) |                 |   |   |   |   |   |
| 3 | > the hardware     |      |                 |   |   |   |   |   |
| * | > design assurance |      |                 |   |   |   |   |   |
| * | > objectives,      |      |                 |   |   |   |   |   |
|   | > including        |      |                 |   |   |   |   |   |
|   | > strategies       |      |                 |   |   |   |   |   |
|   | > identified using |      |                 |   |   |   |   |   |
|   | > guidance in      |      |                 |   |   |   |   |   |
|   | > RTCA/DO-254      |      |                 |   |   |   |   |   |
|   | > Section 2.3.4,   |      |                 |   |   |   |   |   |
|   | > are proposed to  |      |                 |   |   |   |   |   |
|   | > the              |      |                 |   |   |   |   |   |
|   | > certification    |      |                 |   |   |   |   |   |
|   | > authority.       |      |                 |   |   |   |   |   |
+---+--------------------+------+-----------------+---+---+---+---+---+
| * | > Standards are    | 4.   | > Requirements  | 1 | H | H | N | N |
| * | > selected and     | 1(2) | > Standards     | 0 | C | C | A | A |
| 4 | > defined.         |      | > (Note 3)      | . | 2 | 2 |   |   |
| * |                    |      | >               | 2 |   |   | H | N |
| * |                    |      | > Hardware      | . | H | H | C | A |
|   |                    |      | > Design        | 1 | C | C | 2 |   |
|   |                    |      | > Standards     |   | 2 | 2 |   | N |
|   |                    |      | > (Note 3)      | 1 |   |   | N | A |
|   |                    |      | >               | 0 | H | H | A |   |
|   |                    |      | > Validation    | . | C | C |   | N |
|   |                    |      | > and           | 2 | 2 | 2 | N | A |
|   |                    |      | > Verification  | . |   |   | A |   |
|   |                    |      | > Standards     | 2 | H | H |   |   |
|   |                    |      | > (Note 3)      |   | C | C |   |   |
|   |                    |      | >               | 1 | 2 | 2 |   |   |
|   |                    |      | > Hardware      | 0 |   |   |   |   |
|   |                    |      | > Archive       | . |   |   |   |   |
|   |                    |      | > Standards     | 2 |   |   |   |   |
|   |                    |      | > (Note 3)      | . |   |   |   |   |
|   |                    |      |                 | 3 |   |   |   |   |
|   |                    |      |                 |   |   |   |   |   |
|   |                    |      |                 | 1 |   |   |   |   |
|   |                    |      |                 | 0 |   |   |   |   |
|   |                    |      |                 | . |   |   |   |   |
|   |                    |      |                 | 2 |   |   |   |   |
|   |                    |      |                 | . |   |   |   |   |
|   |                    |      |                 | 4 |   |   |   |   |
+---+--------------------+------+-----------------+---+---+---+---+---+

**Relevant notes from RTCA/DO-254 Appendix A, Table A-1:**

> Note 3. If this data is used for certification, then its availability
> is shown in the table. This data is not always used for certification
> and may not be required.
>
> Note 4. This can be accomplished informally through the certification
> liaison process for Levels C and D. Documentation can be in the form
> of meeting minutes and or presentation material.

[]{#__RefHeading___Toc191963528 .anchor}Table B2. Hardware Design
Process

<table style="width:100%;">
<colgroup>
<col style="width: 6%" />
<col style="width: 29%" />
<col style="width: 10%" />
<col style="width: 21%" />
<col style="width: 11%" />
<col style="width: 5%" />
<col style="width: 5%" />
<col style="width: 0%" />
<col style="width: 0%" />
<col style="width: 4%" />
<col style="width: 0%" />
<col style="width: 0%" />
<col style="width: 4%" />
<col style="width: 0%" />
</colgroup>
<tbody>
<tr class="odd">
<td></td>
<td colspan="2"><strong>Objective</strong></td>
<td colspan="2"><p><strong>Hardware</strong></p>
<p><strong>Life Cycle Data</strong></p></td>
<td colspan="8"><p><strong>Control Category By</strong></p>
<p><strong>HW Assurance Level</strong></p></td>
<td></td>
</tr>
<tr class="even">
<td></td>
<td><strong>Description</strong></td>
<td><strong>Ref.</strong></td>
<td><strong>Description</strong></td>
<td><strong>Ref.</strong></td>
<td><strong>A</strong></td>
<td><strong>B</strong></td>
<td colspan="3"><strong>C</strong></td>
<td colspan="3"><strong>D</strong></td>
<td></td>
</tr>
<tr class="odd">
<td></td>
<td><blockquote>
<p><strong>Requirements Capture</strong></p>
</blockquote></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td colspan="3"></td>
<td colspan="3"></td>
<td></td>
</tr>
<tr class="even">
<td><strong>1</strong></td>
<td><blockquote>
<p>Requirements are identified, defined and documented.</p>
</blockquote></td>
<td>5.1.1(1)</td>
<td rowspan="2"><blockquote>
<p>Hardware Requirements</p>
</blockquote></td>
<td rowspan="2">10.3.1</td>
<td rowspan="2">HC1</td>
<td rowspan="2">HC1</td>
<td colspan="3" rowspan="2">HC1</td>
<td colspan="3" rowspan="2">HC1</td>
<td></td>
</tr>
<tr class="odd">
<td><strong>2</strong></td>
<td><blockquote>
<p>Derived requirements produced are fed back to the appropriate
process.</p>
</blockquote></td>
<td>5.1.1(2)</td>
<td></td>
</tr>
<tr class="even">
<td><strong>3</strong></td>
<td><blockquote>
<p>Requirement omissions and errors are provided to the appropriate
process for resolution.</p>
</blockquote></td>
<td>5.1.1(3)</td>
<td><blockquote>
<p>Problem Reports</p>
</blockquote></td>
<td>10.6</td>
<td>HC2</td>
<td>HC2</td>
<td colspan="3">HC2</td>
<td colspan="3">HC2</td>
<td></td>
</tr>
<tr class="odd">
<td></td>
<td><blockquote>
<p><strong>Conceptual Design</strong></p>
</blockquote></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td colspan="3"></td>
<td colspan="3"></td>
<td></td>
</tr>
<tr class="even">
<td><strong>4</strong></td>
<td><blockquote>
<p>The hardware item conceptual design is developed consistent with its
requirements.</p>
</blockquote></td>
<td>5.2.1(1)</td>
<td><blockquote>
<p>Conceptual Design Data (Note 3)</p>
</blockquote></td>
<td><blockquote>
<p>10.3.2.1</p>
</blockquote></td>
<td>HC2</td>
<td>HC2</td>
<td colspan="3">NA</td>
<td colspan="3">NA</td>
<td></td>
</tr>
<tr class="odd">
<td><strong>5</strong></td>
<td><blockquote>
<p>Derived requirements produced are fed back to the requirements
capture or other appropriate processes.</p>
</blockquote></td>
<td>5.2.1(2)</td>
<td><blockquote>
<p>Hardware Requirements</p>
</blockquote></td>
<td>10.3.1</td>
<td>HC1</td>
<td>HC1</td>
<td colspan="3">HC1</td>
<td colspan="3">HC1</td>
<td></td>
</tr>
<tr class="even">
<td><strong>7</strong></td>
<td><blockquote>
<p>Requirement omissions and errors are provided to the appropriate
process for resolution.</p>
</blockquote></td>
<td>5.2.1(3)</td>
<td><blockquote>
<p>Problem Reports</p>
</blockquote></td>
<td>10.6</td>
<td>HC2</td>
<td>HC2</td>
<td colspan="3">HC2</td>
<td colspan="3">HC2</td>
<td></td>
</tr>
<tr class="odd">
<td></td>
<td><blockquote>
<p><strong>Detailed Design</strong></p>
</blockquote></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td colspan="3"></td>
<td colspan="3"></td>
<td></td>
</tr>
<tr class="even">
<td><strong>8</strong></td>
<td><blockquote>
<p>Detailed design is developed from the hardware item requirements and
conceptual design data.</p>
</blockquote></td>
<td>5.3.1(1)</td>
<td><blockquote>
<p>Detailed Design Data</p>
<p>Top-Level Drawing</p>
</blockquote>
<p>Assembly Drawing</p>
<blockquote>
<p>HW/SW Interface Data</p>
</blockquote></td>
<td><p>10.3.2.2</p>
<p>10.3.2.2.1</p>
<p>10.3.2.2.2</p>
<p>10.3.2.2.4</p></td>
<td><p>Note5</p>
<p>HC1</p>
<p>HC1</p>
<p>HC1</p></td>
<td><p>Note5</p>
<p>HC1</p>
<p>HC1</p>
<p>HC1</p></td>
<td colspan="3"><p>Note5</p>
<p>HC1</p>
<p>HC1</p>
<p>HC1</p></td>
<td colspan="3"><p>Note5</p>
<p>HC1</p>
<p>HC1</p>
<p>HC1</p></td>
<td></td>
</tr>
<tr class="odd">
<td><strong>9</strong></td>
<td><blockquote>
<p>Derived requirements are fed back to the conceptual design process or
other appropriate processes.</p>
</blockquote></td>
<td>5.3.1(2)</td>
<td><blockquote>
<p>Hardware Requirements</p>
</blockquote></td>
<td>10.3.1</td>
<td>HC1</td>
<td>HC1</td>
<td colspan="3">HC1</td>
<td colspan="3">HC1</td>
<td></td>
</tr>
<tr class="even">
<td><strong>10</strong></td>
<td><blockquote>
<p>Requirement omissions and errors are provided to the appropriate
process for resolution.</p>
</blockquote></td>
<td>5.3.1(3)</td>
<td><blockquote>
<p>Problem Reports</p>
</blockquote></td>
<td>10.6</td>
<td>HC2</td>
<td>HC2</td>
<td colspan="3">HC2</td>
<td colspan="3">HC2</td>
<td></td>
</tr>
<tr class="odd">
<td></td>
<td><blockquote>
<p><strong>Implementation</strong></p>
</blockquote></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td colspan="3"></td>
<td colspan="3"></td>
<td></td>
</tr>
<tr class="even">
<td><strong>11</strong></td>
<td><blockquote>
<p>A hardware item is produced which implements the hardware detailed
design using the representative manufacturing processes.</p>
</blockquote></td>
<td>5.4.1(1)</td>
<td rowspan="2"><blockquote>
<p>Detailed Design Data</p>
<p>Top-Level Drawing</p>
<p>Assembly Drawing</p>
<p>Installation Control Drawings</p>
</blockquote></td>
<td rowspan="2"><p>10.3.2.2</p>
<p>10.3.2.2.1</p>
<p>10.3.2.2.2</p>
<p>10.3.2.2.3</p></td>
<td rowspan="2"><p>Note5</p>
<p>HC1</p>
<p>HC1</p>
<p>HC1</p></td>
<td rowspan="2"><p>Note5</p>
<p>HC1</p>
<p>HC1</p>
<p>HC1</p></td>
<td colspan="3" rowspan="2"><p>Note5</p>
<p>HC1</p>
<p>HC1</p>
<p>HC1</p></td>
<td colspan="3" rowspan="2"><p>Note5</p>
<p>HC1</p>
<p>HC1</p>
<p>HC1</p></td>
<td></td>
</tr>
<tr class="odd">
<td><strong>12</strong></td>
<td><blockquote>
<p>The hardware item implementation, assembly and installation data is
complete.</p>
</blockquote></td>
<td>5.4.1(2)</td>
<td></td>
</tr>
<tr class="even">
<td><strong>13</strong></td>
<td><blockquote>
<p>Derived requirements are fed back to the conceptual design process or
other appropriate processes.</p>
</blockquote></td>
<td>5.4.1(3)</td>
<td><blockquote>
<p>Hardware Requirements</p>
</blockquote></td>
<td>10.3.1</td>
<td>HC1</td>
<td>HC1</td>
<td colspan="3">HC1</td>
<td colspan="3">HC1</td>
<td></td>
</tr>
<tr class="odd">
<td><strong>14</strong></td>
<td><blockquote>
<p>Requirement omissions and errors are provided to the appropriate
processes for resolution.</p>
</blockquote></td>
<td>5.4.1(4)</td>
<td><blockquote>
<p>Problem Reports</p>
</blockquote></td>
<td>10.6</td>
<td>HC2</td>
<td>HC2</td>
<td colspan="3">HC2</td>
<td colspan="3">HC2</td>
<td></td>
</tr>
<tr class="even">
<td></td>
<td><blockquote>
<p><strong>Production Transition</strong></p>
</blockquote></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td colspan="3"></td>
<td colspan="3"></td>
<td></td>
</tr>
<tr class="odd">
<td><strong>15</strong></td>
<td><blockquote>
<p>A baseline is established that includes all design and manufacturing
data needed to support the consistent replication of the hardware
item.</p>
</blockquote></td>
<td>5.5.1(1)</td>
<td><blockquote>
<p>Hardware Requirements</p>
<p>Top-Level Drawing</p>
<p>Assembly Drawing</p>
<p>Installation Control Drawings</p>
<p>Hardware Configuration Management Records</p>
</blockquote></td>
<td><blockquote>
<p>10.3.1</p>
</blockquote>
<p>10.3.2.2.1</p>
<p>10.3.2.2.2</p>
<p>10.3.2.2.3</p>
<p>10.7</p></td>
<td><p>HC1</p>
<p>HC1</p>
<p>HC1</p>
<p>HC1</p>
<p>HC2</p></td>
<td colspan="2"><p>HC1</p>
<p>HC1</p>
<p>HC1</p>
<p>HC1</p>
<p>HC2</p></td>
<td colspan="3"><p>HC1</p>
<p>HC1</p>
<p>HC1</p>
<p>HC1</p>
<p>HC2</p></td>
<td colspan="3"><p>HC1</p>
<p>HC1</p>
<p>HC1</p>
<p>HC1</p>
<p>HC2</p></td>
</tr>
<tr class="even">
<td><strong>16</strong></td>
<td><blockquote>
<p>Manufacturing requirements related to safety are identified and
documented and manufacturing controls are established.</p>
</blockquote></td>
<td>5.5.1(2)</td>
<td><blockquote>
<p>Hardware Requirements</p>
</blockquote></td>
<td>10.3.1</td>
<td>HC1</td>
<td colspan="3">HC1</td>
<td colspan="3">HC1</td>
<td colspan="2">HC1</td>
</tr>
<tr class="odd">
<td><strong>17</strong></td>
<td><blockquote>
<p>Derived requirements are fed back to the implementation process or
other appropriate processes.</p>
</blockquote></td>
<td>5.5.1(3)</td>
<td><blockquote>
<p>Hardware Acceptance Test Criteria</p>
</blockquote></td>
<td>10.5</td>
<td>HC2</td>
<td colspan="3">HC2</td>
<td colspan="3">HC2</td>
<td colspan="2">HC2</td>
</tr>
<tr class="even">
<td><strong>18</strong></td>
<td><blockquote>
<p>Errors and omissions are provided to the appropriate processes for
resolution.</p>
</blockquote></td>
<td>5.5.1(4)</td>
<td><blockquote>
<p>Problem Reports</p>
</blockquote></td>
<td>10.6</td>
<td>HC2</td>
<td colspan="3">HC2</td>
<td colspan="3">HC2</td>
<td colspan="2">HC2</td>
</tr>
</tbody>
</table>

**Relevant notes from RTCA/DO-254 Appendix A, Table A-1:**

> Note 3. If this data is used for certification, then its availability
> is shown in the table. This data is not always used for certification
> and may not be required.
>
> Note 5. If the applicant references this data item in submitted data
> items, it should be available.

[]{#__RefHeading___Toc191963529 .anchor}Table B3. Validation and
Verification Processes

+---+--------------------+------+---------------+-------+---+---+---+---+
|   | **Objective**      |      | **Hardware**  |       | * |   |   |   |
|   |                    |      |               |       | * |   |   |   |
|   |                    |      | **Life Cycle  |       | C |   |   |   |
|   |                    |      | Data**        |       | o |   |   |   |
|   |                    |      |               |       | n |   |   |   |
|   |                    |      |               |       | t |   |   |   |
|   |                    |      |               |       | r |   |   |   |
|   |                    |      |               |       | o |   |   |   |
|   |                    |      |               |       | l |   |   |   |
|   |                    |      |               |       | C |   |   |   |
|   |                    |      |               |       | a |   |   |   |
|   |                    |      |               |       | t |   |   |   |
|   |                    |      |               |       | e |   |   |   |
|   |                    |      |               |       | g |   |   |   |
|   |                    |      |               |       | o |   |   |   |
|   |                    |      |               |       | r |   |   |   |
|   |                    |      |               |       | y |   |   |   |
|   |                    |      |               |       | B |   |   |   |
|   |                    |      |               |       | y |   |   |   |
|   |                    |      |               |       | * |   |   |   |
|   |                    |      |               |       | * |   |   |   |
|   |                    |      |               |       |   |   |   |   |
|   |                    |      |               |       | * |   |   |   |
|   |                    |      |               |       | * |   |   |   |
|   |                    |      |               |       | H |   |   |   |
|   |                    |      |               |       | W |   |   |   |
|   |                    |      |               |       | A |   |   |   |
|   |                    |      |               |       | s |   |   |   |
|   |                    |      |               |       | s |   |   |   |
|   |                    |      |               |       | u |   |   |   |
|   |                    |      |               |       | r |   |   |   |
|   |                    |      |               |       | a |   |   |   |
|   |                    |      |               |       | n |   |   |   |
|   |                    |      |               |       | c |   |   |   |
|   |                    |      |               |       | e |   |   |   |
|   |                    |      |               |       | L |   |   |   |
|   |                    |      |               |       | e |   |   |   |
|   |                    |      |               |       | v |   |   |   |
|   |                    |      |               |       | e |   |   |   |
|   |                    |      |               |       | l |   |   |   |
|   |                    |      |               |       | * |   |   |   |
|   |                    |      |               |       | * |   |   |   |
+---+--------------------+------+---------------+-------+---+---+---+---+
|   | **Description**    | **Re | **            | **R   | * | * | * | * |
|   |                    | f.** | Description** | ef.** | * | * | * | * |
|   |                    |      |               |       | A | B | C | D |
|   |                    |      |               |       | * | * | * | * |
|   |                    |      |               |       | * | * | * | * |
+---+--------------------+------+---------------+-------+---+---+---+---+
|   | > **Validation**   |      |               |       |   |   |   |   |
+---+--------------------+------+---------------+-------+---+---+---+---+
| * | > Derived hardware | 6.1. | > Hardware    | 1     | H | H | H | H |
| * | > requirements     | 1(1) | > Validation  | 0.1.3 | C | C | C | C |
| 1 | > against which    |      | > Plan        |       | 2 | 2 | 2 | 2 |
| * | > the hardware     |      | >             | 1     |   |   |   |   |
| * | > item is to be    |      | > Hardware    | 0.4.1 | H | H | H | H |
|   | > verified are     |      | >             |       | C | C | C | C |
|   | > correct and      |      |  Traceability | 1     | 2 | 2 | 2 | 2 |
|   | > complete.        |      | > Data        | 0.4.2 |   |   | N | N |
|   |                    |      | >             |       | H | H | o | o |
|   |                    |      | > Hardware    | 1     | C | C | t | t |
|   |                    |      | > Review and  | 0.4.3 | 1 | 1 | e | e |
|   |                    |      | > Analysis    |       |   |   | 6 | 6 |
|   |                    |      | > Procedures  | 1     | H | H |   |   |
|   |                    |      | > (Note 3)    | 0.4.4 | C | C | N | N |
|   |                    |      | >             |       | 2 | 2 | A | A |
|   |                    |      | > Hardware    | 1     |   |   |   |   |
|   |                    |      | > Review and  | 0.4.5 | H | H | H | H |
|   |                    |      | > Analysis    |       | C | C | C | C |
|   |                    |      | > Results     |       | 1 | 1 | 2 | 2 |
|   |                    |      | > (Note 3)    |       |   |   |   |   |
|   |                    |      | >             |       | H | H | H | H |
|   |                    |      | > Hardware    |       | C | C | C | C |
|   |                    |      | > Test        |       | 1 | 1 | 2 | 2 |
|   |                    |      | > Procedures  |       |   |   |   | N |
|   |                    |      | > (Note 3)    |       |   |   | H | o |
|   |                    |      | >             |       |   |   | C | t |
|   |                    |      | > Hardware    |       |   |   | 2 | e |
|   |                    |      | > Test        |       |   |   |   | 7 |
|   |                    |      | > Results     |       |   |   |   |   |
|   |                    |      | > (Note 3)    |       |   |   |   | H |
|   |                    |      |               |       |   |   |   | C |
|   |                    |      |               |       |   |   |   | 2 |
|   |                    |      |               |       |   |   |   | N |
|   |                    |      |               |       |   |   |   | o |
|   |                    |      |               |       |   |   |   | t |
|   |                    |      |               |       |   |   |   | e |
|   |                    |      |               |       |   |   |   | 7 |
+---+--------------------+------+---------------+-------+---+---+---+---+
| * | > Derived          | 6.1. |               |       |   |   |   |   |
| * | > requirements are | 1(2) |               |       |   |   |   |   |
| 2 | > evaluated for    |      |               |       |   |   |   |   |
| * | > impact on        |      |               |       |   |   |   |   |
| * | > safety.          |      |               |       |   |   |   |   |
+---+--------------------+------+---------------+-------+---+---+---+---+
| * | > Omissions and    | 6.1. | > Problem     | 10.6  | H | H | H | H |
| * | > errors are fed   | 1(3) | > Reports     |       | C | C | C | C |
| 3 | > back to the      |      |               |       | 2 | 2 | 2 | 2 |
| * | > appropriate      |      |               |       |   |   |   |   |
| * | > processes for    |      |               |       |   |   |   |   |
|   | > resolution.      |      |               |       |   |   |   |   |
+---+--------------------+------+---------------+-------+---+---+---+---+
|   | > **Verification** |      |               |       |   |   |   |   |
+---+--------------------+------+---------------+-------+---+---+---+---+
| * | > Evidence is      | 6.2. | > Hardware    | 1     | H | H | H | H |
| * | > provided that    | 1(1) | >             | 0.1.4 | C | C | C | C |
| 4 | > the hardware     |      |  Verification |       | 2 | 2 | 2 | 2 |
| * | > implementation   |      | > Plan        | 1     |   |   |   |   |
| * | > meets the        |      | >             | 0.4.1 | H | H | H | H |
|   | > requirements.    |      | > Hardware    |       | C | C | C | C |
|   |                    |      | >             | 1     | 2 | 2 | 2 | 2 |
|   |                    |      |  Traceability | 0.4.2 |   |   | N | N |
|   |                    |      | > Data        |       | H | H | o | o |
|   |                    |      | >             | 1     | C | C | t | t |
|   |                    |      | > Hardware    | 0.4.3 | 1 | 1 | e | e |
|   |                    |      | > Review and  |       |   |   | 6 | 6 |
|   |                    |      | > Analysis    | 1     | H | H |   |   |
|   |                    |      | > Procedures  | 0.4.4 | C | C | N | N |
|   |                    |      | > (Note 3)    |       | 2 | 2 | A | A |
|   |                    |      | >             | 1     |   |   |   |   |
|   |                    |      | > Hardware    | 0.4.5 | H | H | H | H |
|   |                    |      | > Review and  |       | C | C | C | C |
|   |                    |      | > Analysis    |       | 1 | 1 | 2 | 2 |
|   |                    |      | > Results     |       |   |   |   |   |
|   |                    |      | > (Note 3)    |       | H | H | H | H |
|   |                    |      | >             |       | C | C | C | C |
|   |                    |      | > Hardware    |       | 1 | 1 | 2 | 2 |
|   |                    |      | > Test        |       |   |   |   | N |
|   |                    |      | > Procedures  |       |   |   | H | o |
|   |                    |      | > (Note 3)    |       |   |   | C | t |
|   |                    |      | >             |       |   |   | 2 | e |
|   |                    |      | > Hardware    |       |   |   |   | 7 |
|   |                    |      | > Test        |       |   |   |   |   |
|   |                    |      | > Results     |       |   |   |   | H |
|   |                    |      | > (Note 3)    |       |   |   |   | C |
|   |                    |      |               |       |   |   |   | 2 |
|   |                    |      |               |       |   |   |   | N |
|   |                    |      |               |       |   |   |   | o |
|   |                    |      |               |       |   |   |   | t |
|   |                    |      |               |       |   |   |   | e |
|   |                    |      |               |       |   |   |   | 7 |
+---+--------------------+------+---------------+-------+---+---+---+---+
| * | > Traceability is  | 6.2. |               |       |   |   |   |   |
| * | > established      | 1(2) |               |       |   |   |   |   |
| 5 | > between hardware |      |               |       |   |   |   |   |
| * | > requirements,    |      |               |       |   |   |   |   |
| * | > the              |      |               |       |   |   |   |   |
|   | > implementation,  |      |               |       |   |   |   |   |
|   | > and the          |      |               |       |   |   |   |   |
|   | > verification     |      |               |       |   |   |   |   |
|   | > procedures and   |      |               |       |   |   |   |   |
|   | > results.         |      |               |       |   |   |   |   |
+---+--------------------+------+---------------+-------+---+---+---+---+
| * | > Acceptance test  | 6.2. | > Hardware    | 10.5  | H | H | H | H |
| * | > criteria are     | 1(3) | > Acceptance  |       | C | C | C | C |
| 6 | > identified, can  |      | > Test        |       | 2 | 2 | 2 | 2 |
| * | > be implemented   |      | > Criteria    |       |   |   |   |   |
| * | > and are          |      |               |       |   |   |   |   |
|   | > consistent with  |      |               |       |   |   |   |   |
|   | > the hardware     |      |               |       |   |   |   |   |
|   | > design assurance |      |               |       |   |   |   |   |
|   | > levels of the    |      |               |       |   |   |   |   |
|   | > hardware         |      |               |       |   |   |   |   |
|   | > functions.       |      |               |       |   |   |   |   |
+---+--------------------+------+---------------+-------+---+---+---+---+
| * | > Omissions and    | 6.1. | > Problem     | 10.6  | H | H | H | H |
| * | > errors are fed   | 1(3) | > Reports     |       | C | C | C | C |
| 7 | > back to the      |      | >             | 10.7  | 2 | 2 | 2 | 2 |
| * | > appropriate      | 6.2. | > Hardware    |       |   |   |   |   |
| * | > processes for    | 1(4) | >             |       | H | H | H | H |
|   | > resolution.      |      | Configuration |       | C | C | C | C |
|   |                    |      | > Management  |       | 2 | 2 | 2 | 2 |
|   |                    |      | > Records     |       |   |   |   |   |
+---+--------------------+------+---------------+-------+---+---+---+---+

**Relevant notes from RTCA/DO-254 Appendix A, Table A-1:**

> Note 3. If this data is used for certification, then its availability
> is shown in the table. This data is not always used for certification
> and may not be required.
>
> Note 6. Only the traceability data from requirements to test is
> needed.
>
> Note 7. Test coverage of derived or lower hierarchical requirements is
> not needed.

[]{#__RefHeading___Toc191963530 .anchor}Table B4. Configuration
Management and Process Assurance Processes

+---+--------------------+------+----------------+-----+---+---+---+---+
|   | **Objective**      |      | **Hardware**   |     | * |   |   |   |
|   |                    |      |                |     | * |   |   |   |
|   |                    |      | **Life Cycle   |     | C |   |   |   |
|   |                    |      | Data**         |     | o |   |   |   |
|   |                    |      |                |     | n |   |   |   |
|   |                    |      |                |     | t |   |   |   |
|   |                    |      |                |     | r |   |   |   |
|   |                    |      |                |     | o |   |   |   |
|   |                    |      |                |     | l |   |   |   |
|   |                    |      |                |     | C |   |   |   |
|   |                    |      |                |     | a |   |   |   |
|   |                    |      |                |     | t |   |   |   |
|   |                    |      |                |     | e |   |   |   |
|   |                    |      |                |     | g |   |   |   |
|   |                    |      |                |     | o |   |   |   |
|   |                    |      |                |     | r |   |   |   |
|   |                    |      |                |     | y |   |   |   |
|   |                    |      |                |     | B |   |   |   |
|   |                    |      |                |     | y |   |   |   |
|   |                    |      |                |     | * |   |   |   |
|   |                    |      |                |     | * |   |   |   |
|   |                    |      |                |     |   |   |   |   |
|   |                    |      |                |     | * |   |   |   |
|   |                    |      |                |     | * |   |   |   |
|   |                    |      |                |     | H |   |   |   |
|   |                    |      |                |     | W |   |   |   |
|   |                    |      |                |     | A |   |   |   |
|   |                    |      |                |     | s |   |   |   |
|   |                    |      |                |     | s |   |   |   |
|   |                    |      |                |     | u |   |   |   |
|   |                    |      |                |     | r |   |   |   |
|   |                    |      |                |     | a |   |   |   |
|   |                    |      |                |     | n |   |   |   |
|   |                    |      |                |     | c |   |   |   |
|   |                    |      |                |     | e |   |   |   |
|   |                    |      |                |     | L |   |   |   |
|   |                    |      |                |     | e |   |   |   |
|   |                    |      |                |     | v |   |   |   |
|   |                    |      |                |     | e |   |   |   |
|   |                    |      |                |     | l |   |   |   |
|   |                    |      |                |     | * |   |   |   |
|   |                    |      |                |     | * |   |   |   |
+---+--------------------+------+----------------+-----+---+---+---+---+
|   | **Description**    | **Re | *              | **  | * | * | * | * |
|   |                    | f.** | *Description** | Ref | * | * | * | * |
|   |                    |      |                | .** | A | B | C | D |
|   |                    |      |                |     | * | * | * | * |
|   |                    |      |                |     | * | * | * | * |
+---+--------------------+------+----------------+-----+---+---+---+---+
|   | > **Configuration  |      |                |     |   |   |   |   |
|   | > Management**     |      |                |     |   |   |   |   |
+---+--------------------+------+----------------+-----+---+---+---+---+
| > | > Configuration    | 7.   | > Hardware     | 1   | H | H | H | H |
|   | > items are        | 1(1) | >              | 0.7 | C | C | C | C |
| * | > uniquely         |      |  Configuration |     | 2 | 2 | 2 | 2 |
| * | > identified and   |      | > Management   | 10. |   |   |   |   |
| 1 | > documented.      |      | > Records      | 2.4 | H | H | N | N |
| * |                    |      | >              |     | C | C | A | A |
| * |                    |      | > Hardware     |     | 2 | 2 |   |   |
|   |                    |      | > Archive      |     |   |   |   |   |
|   |                    |      | > Standards    |     |   |   |   |   |
|   |                    |      | > (Note 3)     |     |   |   |   |   |
+---+--------------------+------+----------------+-----+---+---+---+---+
| > | > Consistent and   | 7.   | > Hardware     | 1   | H | H | H | H |
|   | > accurate         | 1(2) | >              | 0.7 | C | C | C | C |
| * | > replication of   |      |  Configuration |     | 2 | 2 | 2 | 2 |
| * | > configuration    |      | > Management   | 1   |   |   |   |   |
| 2 | > items is         |      | > Records      | 0.8 | H | H | H | N |
| * | > ensured.         |      | >              |     | C | C | C | A |
| * |                    |      | > Hardware     | 10. | 2 | 2 | 2 |   |
|   |                    |      | > Process      | 2.4 |   |   |   | N |
|   |                    |      | > Assurance    |     | H | H | N | A |
|   |                    |      | > Records      |     | C | C | A |   |
|   |                    |      | >              |     | 2 | 2 |   |   |
|   |                    |      | > Hardware     |     |   |   |   |   |
|   |                    |      | > Archive      |     |   |   |   |   |
|   |                    |      | > Standards    |     |   |   |   |   |
|   |                    |      | > (Note 3)     |     |   |   |   |   |
+---+--------------------+------+----------------+-----+---+---+---+---+
| > | > A controlled     | 7.   | > Hardware     | >   | H | H | H | H |
|   | > method of        | 1(3) | >              | 10. | C | C | C | C |
| * | > identifying and  |      |  Configuration | 1.5 | 1 | 1 | 2 | 2 |
| * | > tracking         |      | > Plan         |     |   |   |   |   |
| 3 | > modification to  |      | >              | 1   | H | H | H | H |
| * | > configuration    |      | > Hardware     | 0.7 | C | C | C | C |
| * | > items is         |      | >              |     | 2 | 2 | 2 | 2 |
|   | > provided.        |      |  Configuration | 1   |   |   |   |   |
|   |                    |      | > Management   | 0.6 | H | H | H | H |
|   |                    |      | > Records      |     | C | C | C | C |
|   |                    |      | >              |     | 2 | 2 | 2 | 2 |
|   |                    |      | > Problem      |     |   |   |   |   |
|   |                    |      | > Reports      |     |   |   |   |   |
+---+--------------------+------+----------------+-----+---+---+---+---+
|   | > **Process        |      |                |     |   |   |   |   |
|   | > Assurance**      |      |                |     |   |   |   |   |
+---+--------------------+------+----------------+-----+---+---+---+---+
| > | > Life cycle       | 8.   | > Hardware     | 10. | H | H | N | N |
|   | > processes comply | 1(1) | > Process      | 1.6 | C | C | A | A |
| * | > with the         |      | > Assurance    |     | 2 | 2 |   |   |
| * | > approved plans.  |      | > Plan         | 1   |   |   | H | N |
| 4 |                    |      | >              | 0.8 | H | H | C | A |
| * |                    |      | > Hardware     |     | C | C | 2 |   |
| * |                    |      | > Process      | 1   | 2 | 2 |   | H |
|   |                    |      | > Assurance    | 0.9 |   |   | H | C |
|   |                    |      | > Records      |     | H | H | C | 1 |
|   |                    |      | >              |     | C | C | 1 |   |
|   |                    |      | > Hardware     |     | 1 | 1 |   |   |
|   |                    |      | >              |     |   |   |   |   |
|   |                    |      | Accomplishment |     |   |   |   |   |
|   |                    |      | > Summary      |     |   |   |   |   |
+---+--------------------+------+----------------+-----+---+---+---+---+
| > | > Hardware design  | 8.   |                |     |   |   |   |   |
|   | > life cycle data  | 1(2) |                |     |   |   |   |   |
| * | > produced         |      |                |     |   |   |   |   |
| * | > complies with    |      |                |     |   |   |   |   |
| 5 | > the approved     |      |                |     |   |   |   |   |
| * | > plans.           |      |                |     |   |   |   |   |
| * |                    |      |                |     |   |   |   |   |
+---+--------------------+------+----------------+-----+---+---+---+---+
| > | > The hardware     | 8.   |                |     |   |   |   |   |
|   | > item used for    | 1(3) |                |     |   |   |   |   |
| * | > conformance      |      |                |     |   |   |   |   |
| * | > assessment is    |      |                |     |   |   |   |   |
| 6 | > built to comply  |      |                |     |   |   |   |   |
| * | > with the         |      |                |     |   |   |   |   |
| * | > associated life  |      |                |     |   |   |   |   |
|   | > cycle data.      |      |                |     |   |   |   |   |
+---+--------------------+------+----------------+-----+---+---+---+---+

**Relevant notes from RTCA/DO-254 Appendix A, Table A-1:**

> Note 3. If this data is used for certification, then its availability
> is shown in the table. This data is not always used for certification
> and may not be required.

**Note:** The material contained in Tables B1 through B4 in this Job Aid
regarding DO-254 objectives and notes is copyrighted by RTCA, Inc. and
used with permission. DO-254, along with all RTCA, Inc. documents, may
be purchased directly from RTCA, Inc. To order a copy of DO-254 or any
other RTCA, Inc. documents, please contact:

RTCA, Inc.

1828 L Street, N.W.

Suite 805

Washington D.C. 20036

Ph. 202-833-9339

Fax 202-833-9434

[www.rtca.org]{.underline}

# Appendix C -- Frequently Asked Questions

**Q1:** Part 1, Overview of the Airborne electronic Hardware Review,
states that the Job Aid "should not be used as a checklist." What does
this mean? If it isn't a checklist, how should the Job Aid be used?

**A1:** This Job Aid identifies questions that may need to be addressed
in order to evaluate compliance. However, the questions do not represent
specific audit tasks to accomplish. They are not a list of things to do.
The review team must decide what activities to perform and which
questions are applicable to those activities. You can think of these
questions as the requirements for a review, and the review team has to
generate the "review procedures" that will verify that requirements are
met. For example, one common review technique is to perform a
requirements trace. There is no question that asks about "performing a
requirements trace" but there are a number of questions that can be
addressed while doing a trace. As another example, item 1.1.3 in Table 5
states, "Do the plans and standards address the content as specified in
DO-254 section 10." This is no small task. It requires a review of each
of the plans against the section 10 content list. But there is more to a
plan than just section 10 content. The review team could create a
checklist for each plan and include in it all section 10 content as well
as review items that will address the other compliance aspects of the
documents, such that when the document reviews are done, there is
evidence of compliance for each applicable question.\
\
Do not expect to answer each and every question in Tables 5, 6, 7 and 8
of this Job Aid during a review. Plan ahead. Use only those questions
that are appropriate for the review you are performing. Create
additional questions, if there are new and novel concerns that are not
adequately being covered by this Job Aid. This Job Aid is meant to be
used as a tool, but as a flexible tool that requires judgment about how
it is applied.

**Q2:** The questions contained in the Tables 5, 6, 7 and 8 seem very
much targeted at a review of Complex Airborne Electronic Hardware. Can
this Job Aid be used to assist in the review of Simple Airborne
Electronic Hardware?

**A2:** Yes. That is inherent in the title of this Job Aid, which is
"Conducting Airborne Electronic Hardware Reviews". Airborne hardware
includes both complex and simple hardware. However, there are several
issues that the user must be aware of in order to use this Job Aid
effectively when performing an audit on a Simple Airborne Electronic
Hardware.

FAA AC 20-20-152, "RTCA, INC., DOCUMENT RTCA/DO-254, DESIGN ASSURANCE
GUIDANCE FOR AIRBORNE ELECTRONIC HARDWARE", does not invoke RTCA/DO-254
as an acceptable means of compliance for Simple Airborne Electronic
Hardware. The AC specifically states that it is invoking DO-254 for
"**complex** custom micro-coded components", such as application
specific integrated circuits (ASIC), programmable logic devices (PLD),
field programmable gate arrays (FPGA), and similar electronic components
used in the design of aircraft systems and equipment. Therefore, while
AC 20-152 does not exclude the use of DO-254 for Simple Airborne
Electronic Hardware, it does not specifically document it as an
acceptable means of compliance for that type of hardware.

The main difference between Complex Airborne Electronic Hardware and
Simple Airborne Electronic Hardware is that Simple hardware is not
developed using a rigorous design assurance process. Rather, exhaustive
testing of the end item product is the method used to ensure that a
Simple hardware device contains no errors or unacceptable behavior, and
that systems in which the device is installed will meet the applicable
regulatory requirements. Therefore, many of the objectives (and the
related questions about how to assess compliance to those objectives)
are not relevant to Simple Airborne Electronic Hardware.

However, there are certainly processes contained in DO-254 that *are*
relevant to both Simple and Complex Airborne Electronic Hardware
devices. Specifically, all or parts of the following sections of DO-254
are relevant to Simple Airborne Electronic Hardware.

> 2.0 SYSTEM ASPECTS OF HARDWARE DESIGN ASSURANCE
>
> 7.0 CONFIGURATION MANAGEMENT PROCESS
>
> 8.0 PROCESS ASSURANCE
>
> 9.0 CERTIFICATION LIASON PROCESS
>
> 10.0 HARDWARE DESIGN LIFE CYCLE DATA

This Job Aid does not attempt to specify which DO-254 objectives and
their related questions in Tables 5, 6, 7 and 8 are relevant to Simple
devices. Judgment should be used in the application of these questions
and related DO-254 objectives when attempting to determine compliance or
non-compliance for Simple Airborne Electronic Hardware.

Please refer to Order 8110.CEH\* for more information regarding Simple
Airborne Electronic Hardware.

> \* Order 8110.CEH will cover aspects of both Complex and Simple Custom
> Micro-Coded Devices, also referred to as CEH (Complex Electronic
> Hardware devices) and SEH (Simple Electronic Hardware devices). This
> Order has not been published at the time of initial publication of
> this Job Aid, and therefore cannot be referred to by a specific Order
> number or title.

**Q3:** Is compliance to DO-254 related only to the objectives compiled
in Appendix B of this Job Aid?

> **A3:** No. This Job Aid provides a means of determining compliance to
> DO-254 by referencing the objectives of DO-254. Each reference to an
> objective is merely a convenient way to identify the guidance that the
> objective summarizes. This is not to suggest that the objectives are
> more important than the guidance. Compliance to DO-254 means
> compliance to the guidance itself and not solely to the objectives.

**Q4:** If the FAA is in charge of the review, does the Hardware Review
Team consist only of FAA personnel?

**A4:** Not necessarily. Each review, and the team that performs the
review, will be unique. The FAA should take advantage of any expertise
that is available. For example, consultant DERs that are working with
the avionics supplier or applicant may be a member of the Review Team.
They should be very knowledgeable about the program, documentation and
possible problem areas and can therefore make suggestions to the team
about where to concentrate their efforts.

Additionally, non-U.S. Certification Authority personnel such as from
EASA or Transport Canada or other authorities may be present, in the
case of a joint review. The Team Leader should understand the
motivations and needs from each prospective team member, and assign
tasks accordingly. For example, a non-U.S. Certification Authority
representative is present and is concerned about a configuration
management issue, perhaps based on previous experience with this
hardware supplier. The Review Team Leader should understand this concern
and assign the representative to look into this area. The Team Leader is
responsible for completing the review activities that is needed by the
FAA, but also should be mindful of any non-U.S. Certification Authority
needs as well and attempt to accommodate them (e.g., evaluating
compliance to a non-U.S. Certification Authority Issue Paper), when the
non-U.S. representative is a team member. Otherwise, the various
Certification Authority personnel may end up working at cross-purposes
to each other. Another possibility is that a non-U.S. Certification
Authority representative is the Review Team Lead, and FAA personnel are
team members. This model has worked well in previous reviews and
normally satisfies FAA requirements of the review, if planned
accordingly.