Equipment qualification
Laboratory procedures for temperature, altitude, vibration, fluids, power input, RF susceptibility and emissions, lightning, electrostatic discharge, icing, and other installed environments.
FAA AC 21-16G ↗AIRWORTHINESS · DEVELOPMENT ASSURANCE · COMPLIANCE
FAA Aircraft
Certification
A field guide to the approval path for aircraft, systems, software, airborne electronic hardware, tools, and equipment qualification. Start with the certification basis and safety assessment; use standards as coordinated means of compliance.
EDUCATIONAL REFERENCE · REFERENCE UPDATED OCTOBER 5, 2026A standard is not the certificate. The FAA approves a product or article against an agreed certification basis. Advisory circulars describe accepted approaches, but applicants must coordinate the specific means of compliance, plans, data, reviews, tests, and findings for their project.
01
CERTIFICATION ROADMAP
From concept to approved production
- 01
Standards
Familiarize the FAA with the product, intended use, novel features, organization, and certification request.
- 02
Definition
Establish the certification basis, applicable regulations, special conditions, exemptions, and equivalent-safety findings.
- 03
Detail
Agree on certification plans, means of compliance, schedules, delegation, conformity, and authority involvement.
- 04
Build
Develop the design and production-quality system under configuration, supplier, and conformity controls.
- 05
Test
Complete analyses, inspections, laboratory and ground testing, flight testing, and compliance findings.
- 06
Certification
Close issues and open problem reports, finalize approved data and manuals, and obtain the design approval.
- 07
Production
Show repeatable conformity to the approved design and sustain continued operational safety after entry into service.
Roadmap aligned with the FAA’s 2026 seven-phase aircraft certification overview. A TSO authorization, STC, PMA, or other approval follows a path tailored to its regulatory purpose.
02
CORE STANDARDS
The assurance stack
Airborne software assurance
Life-cycle objectives for planning, development, verification, configuration management, quality assurance, and certification liaison. Software level A through E follows the system safety classification.
FAA AC 20-115D ↗Airborne electronic hardware
Design assurance for complex custom devices and associated hardware evidence, including planning, requirements capture, detailed design, implementation, validation, verification, and process assurance.
FAA AC 20-152A ↗Software tool qualification
Qualification objectives for tools whose output is relied upon without the verification that would otherwise detect an error, or that could fail to detect an error. Scope qualification to the claimed use and tool qualification level.
RTCA software standards ↗Aircraft and system development
Coordinates requirements, architecture, allocation, validation, verification, integration, and development assurance. FAA AC 20-174 currently recognizes ARP4754A; coordinate use of the newer ARP4754B with the FAA for the specific project.
FAA AC 20-174 ↗Safety assessment
Methods supporting functional hazard assessment, preliminary and final system safety assessment, common-cause analysis, fault trees, FMEA, and quantitative or qualitative safety objectives.
FAA AC 25.1309-1B ↗03
HOW THE PIECES CONNECT
Safety drives assurance
AIRCRAFT FUNCTIONIntended behavior
→HAZARD ANALYSISFailure condition
→ASSURANCE LEVELDAL / IDAL
→ITEM PROCESSSoftware + hardware
→EVIDENCECompliance finding
Do not choose DO-178C or DO-254 levels by intuition. Classify aircraft and system failure conditions, allocate safety requirements, then flow the resulting assurance rigor to software and hardware items.
04
SUPPORTING GUIDANCE
Common extensions and adjacent domains
Model-based development
Supplement to DO-178C for executable models and model-based verification.
Object-oriented technology
Addresses object-oriented and related techniques used in airborne software.
Formal methods
Defines how formal methods may satisfy or modify selected DO-178C objectives.
Integrated modular avionics
Roles, artifacts, and assurance for shared IMA platforms, applications, and integration.
Aeronautical data
Data-quality processes for navigation and other installed aeronautical databases.
Airworthiness security
Security process and methods for intentional unauthorized electronic interaction and connected aircraft systems.
Open problem reports
FAA guidance for managing unresolved system, software, and hardware problem reports at approval.
Crew and maintenance use
Address workload, controls, displays, alerts, foreseeable misuse, maintainability, and operational limitations early.
05
PROGRAM ADVICE
Practices that prevent late surprises
- Engage early.Bring the FAA or authorized representatives into novel technology, assurance, tool, COTS, multicore, cybersecurity, and standards-revision decisions before the design hardens.
- Make the safety case lead.Keep the FHA, PSSA, SSA, architecture, requirements, and item assurance levels synchronized as the design changes.
- Baseline the plans.Agree on the certification plan and domain plans before credit-bearing development and verification accumulate.
- Write verifiable requirements.Separate intended function, derived requirements, assumptions, interfaces, robustness, and safety constraints; resolve ambiguity before test.
- Protect independence.Plan who verifies what, at the required level of independence, and preserve objective evidence of reviews and results.
- Control every artifact.Use reproducible baselines, change impact analysis, traceability, problem reporting, supplier oversight, and auditable configuration records.
- Qualify only where credit is claimed.Document the exact tool functions and outputs being trusted; do not qualify an entire toolchain without a certification need.
- Design DO-160 with the installation.Select categories from the aircraft environment and installation, define pass/fail criteria, control test configuration, and handle deviations before entering the laboratory.
- Rehearse the compliance story.Before authority reviews, prove that every applicable requirement has a planned means, responsible owner, traceable evidence, status, and closure path.
06
ONE-STOP REFERENCE
Acronyms & certification documents
Find a document, its purpose and a practical place to manage it. These are reference names and recommended workflows, not a prescribed company data list. The approved plans define the actual titles, contents, owners and release process.
21 document entries
| Acronym / full title | Family | Typical home / export | Purpose & naming notes |
|---|---|---|---|
| PSAC / PHACPlan for Software / Hardware Aspects of Certification | Planning | Word → controlled PDF | Defines the item, assurance level, life cycle, compliance approach, data, suppliers, tools, and authority coordination. PHAC describes how the applicant will develop and substantiate the hardware functions for the identified product. |
| SDP / HDPSoftware Development Plan / Hardware Design Plan | Planning | Word → controlled PDF | Organizes development activities, responsibilities, standards, design methods and transitions. “Hardware Development Plan” is also a local title; DO-254 uses Hardware Design Plan. |
| SVP / HVPSoftware / Hardware Verification Plan | Planning | Word → controlled PDF | Defines verification methods, independence, environments, coverage and completion criteria. HVP alone does not necessarily cover requirements validation. |
| HVVPHardware Validation and Verification Plan | Planning | Word → controlled PDF | Common combined plan: validation asks whether requirements are correct and complete; verification asks whether implementation meets them. Document the two activities distinctly. |
| SCMP / HCMPSoftware / Hardware Configuration Management Plan | Planning | Word → controlled PDF | Defines identification, baselines, change control, problem reporting, release and archival controls. |
| SQAP / HQAPSoftware / Hardware Quality Assurance Plan | Planning | Word → controlled PDF | HQAP ends in “Assurance Plan,” not just “Hardware Quality.” Explain its relationship to DO-254 hardware process assurance; use HPAP when that is the project’s plan title. |
| HPAPHardware Process Assurance Plan | Planning | Word → controlled PDF | Defines independent process oversight, audits, records, deviations and corrective-action closure. Can be coordinated with HQAP. |
| HRS / HDSHardware Requirements Standards / Hardware Design Standards | Planning | Word or controlled standards repository | Defines writing and design conventions; link compliance checks to reviews. Acronyms and packaging vary. |
| HRDHardware Requirements Data / Document | Development | DOORS / DOORS Next → reviewed export | Typical requirements module: unique IDs, allocation, derived requirements, interfaces, rationale, validation status and trace links. “Document” is a common local title. |
| HDDHardware Design Data / Document | Development | DOORS / DOORS Next + design repository | Describe architecture and design decisions in modules where useful. Schematics, HDL, models and implementation files remain controlled in their engineering repositories. |
| HCDProject-specific title: confirm locally | Development | DOORS / DOORS Next if defined by project | May mean Hardware Conceptual Design or Hardware Configuration Data. Use the project glossary to resolve the title. Define it in the PHAC/data-item list before using it. |
| HVTCHardware Verification Test Cases | Verification | DOORS / DOORS Next or ETM | Common local title. Captures test purpose, requirements, inputs, expected outputs, tolerances and pass/fail criteria. Link each case to the requirements it verifies. |
| HVTPHardware Verification Test Procedures (or Test Plan) | Verification | Procedures: DOORS / DOORS Next or ETM; plan: Word/PDF | Ambiguous local acronym. In a DOORS-based verification set, the title may refer to procedures; confirm the template. Procedures give executable steps; a plan sets the strategy. |
| HVTRHardware Verification Test Results / Report | Verification | ETM or results repository → linked DOORS evidence | Common local title. Preserve actual versus expected results, test configuration, execution records, anomalies and review approval. A DOORS export may summarize results; retain the underlying logs. |
| HTDHardware Traceability Data | Verification | DOORS / DOORS Next → controlled report | Common title for bidirectional links across requirements, design and verification evidence, plus unresolved gaps and justified exceptions. |
| HCI / SCIHardware / Software Configuration Index | Completion | Configuration repository → controlled Word/PDF | Identifies the released item and associated life-cycle data revisions. HCI identifies the hardware baseline; SCI identifies the software baseline. |
| HECI / SECIHardware / Software Environment Configuration Index | Completion | Tool/build repository → controlled Word/PDF | Identifies the environment needed to reproduce development and verification. For HECI include relevant workstations/OS, design and verification tools, versions/settings and qualification references; reference it from HCI. |
| HAS / SASHardware / Software Accomplishment Summary | Completion | Word → controlled PDF | Summarizes completed activities, compliance, deviations, approved configuration and outstanding issues for the approval package. |
| HPARHardware Process Assurance Records | Completion | Quality repository → controlled reports | Common expansion; some companies title an individual document “Report.” Keep audit results, nonconformances, corrective actions and closure evidence. Confirm the exact local title. |
| PR / OPRProblem Report / Open Problem Report | Completion | Issue tracker → baseline-linked report | Records defects, impact, disposition and closure. Evaluate open reports against safety, intended function and certification impact; see AC 20-189. |
| TQP / TASTool Qualification Plan / Tool Accomplishment Summary | Tools | Word/PDF + controlled tool evidence | DO-330 software-tool qualification data when applicable. Do not assume DO-330 replaces the DO-254 tool assessment approach; agree the hardware tool approach with the authority. |
No matching documents. Try another term or select all families.
Technical acronym glossary
- AEHAirborne Electronic Hardware
- Hardware installed in airborne systems or equipment.
- HPA / HPSHardware Process Assurance / unconfirmed local abbreviation
- HPA is the usual shorthand. HPS was supplied as “Hardware Process Assurance,” but is not a universal standard acronym; confirm the company glossary.
- FPGAField-Programmable Gate Array
- A programmable logic device; control HDL, constraints, implementation reports and the released programming image.
- ASIC / PLDApplication-Specific Integrated Circuit / Programmable Logic Device
- Custom hardware technologies addressed by the agreed assurance approach.
- HDL / RTLHardware Description Language / Register-Transfer Level
- Design source and abstraction commonly used for FPGA/ASIC implementation.
- COTS / IPCommercial Off-the-Shelf / Intellectual Property
- Purchased devices and reusable design blocks; their use still requires applicable assurance and integration evidence.
- CM / QAConfiguration Management / Quality Assurance
- Control the configuration and independently evaluate compliance with processes.
- V&VValidation and Verification
- Validate the requirements; verify the implementation against them.
- SOIStage of Involvement
- A commonly used name for staged certification authority reviews.
- DAL / IDALDevelopment Assurance Level / Item Development Assurance Level
- Assurance rigor allocated through system development and safety assessment; use the definitions of the applicable standard.
- FHA / PSSA / SSAFunctional Hazard Assessment / Preliminary System Safety Assessment / System Safety Assessment
- Safety analysis across function classification, architecture and completed implementation.
- FMEA / FTA / CCAFailure Modes and Effects Analysis / Fault Tree Analysis / Common Cause Analysis
- Complementary safety assessment methods.
- MC/DCModified Condition/Decision Coverage
- Software structural coverage criterion associated with DO-178C Level A; do not treat it as a universal hardware coverage requirement.
- TQLTool Qualification Level
- DO-330 classification determined by the tool criteria and applicable software level.
- DER / ODADesignated Engineering Representative / Organization Designation Authorization
- FAA delegation mechanisms with defined scopes of authority.
- TC / STC / TSOType Certificate / Supplemental Type Certificate / Technical Standard Order
- Different approval contexts. A TSO authorization is an article approval and does not by itself approve installation.
- DOORS / DNGDynamic Object-Oriented Requirements System / DOORS Next Generation
- IBM requirements tools. DNG is the familiar abbreviation for DOORS Next Generation. Confirm whether “NGD” in a local document means this product or another internal tool.
- ELM / ETMEngineering Lifecycle Management / Engineering Test Management
- IBM suite and its test-management application; link test artifacts and results to requirements in DOORS Next.
07
DOORS / DOORS NEXT
Where the evidence lives
Documents do not automatically “come from DOORS.” The project chooses its source of truth. HRD and traceability are natural requirements-tool artifacts. HDD and HCD can be modules with links to engineering files. HVTC and HVTP procedures can be modules or linked test artifacts; HVTR usually combines controlled execution evidence with a reviewed report.
Plans & summaries
Use controlled Word/PDF for PHAC, PSAC, development/verification/CM/assurance plans, indexes and accomplishment summaries. Link them to module baselines and data-item revisions.
Requirements & design
Use DOORS or DOORS Next for structured IDs, attributes, reviews and trace links. Keep HDL, schematics, constraints and build outputs in their controlled design repositories.
Cases & results
With IBM ELM, test cases, scripts and execution records can live in ETM and link to DOORS Next requirements. Classic DOORS workflows may use modules and integrations. Preserve original evidence.
Freeze & reproduce
Baseline modules and linked configurations. Export reviewed data with IDs and versions, reconcile trace gaps, and verify that the delivered report matches the approved source baseline.
Source: IBM: linking requirements, design and test artifacts ↗. The workflow recommendations above are practical organization choices; neither the FAA nor DO-254 mandates Word or an IBM product.
EXAMPLE · ONE FPGA REQUIREMENT
Requirement → design → procedure → result
HRD-042 → HDD clock/reset design and controlled HDL revision → HVTC-019 / HVTP-019 → HVTR execution evidence → anomaly disposition → HCI release baseline. HECI identifies the tools and environment; HAS summarizes completion. Real IDs and link types follow your project’s process.
A green trace link is not proof of compliance: verify the linked artifact, review status, revision and actual result.Hardware environment and release-index guidance: FAA AC 00-72, §3.1.1 ↗. Hardware verification strategy: FAA AC 20-152A ↗.
08
STAGES OF INVOLVEMENT
Prepare for the review, not just the presentation
SOI reviews are certification authority or authorized representative reviews of the project’s processes and evidence. Often called “audits,” they combine discussion, data sampling, demonstrations and follow-up actions. The familiar four-stage framework below is a preparation aid; coordinate scope, timing, delegation and readiness criteria with the responsible authority.
Planning
Can this approach satisfy the applicable objectives?
Bring controlled evidence
Baseline PSAC/PHAC and supporting plans, standards, level rationale, responsibility/independence matrix, tool strategy, supplier approach and proposed review schedule.
Be ready to demonstrate
Walk reviewers through the intended life cycle. Resolve plan gaps and record agreed actions before the project depends on an unaccepted approach.
Development
Are the plans being followed and is the design traceable?
Bring controlled evidence
Representative reviewed requirements, architecture/design, implementation data, derived requirements, traceability, CM records and process-assurance evidence.
Be ready to demonstrate
Demonstrate requirements-to-design links and change control. For FPGA hardware, include HDL, interfaces, constraints, clock/reset design and implementation evidence as applicable.
Verification
Does the evidence show the implemented item meets its requirements?
Bring controlled evidence
Reviewed cases/procedures/results, coverage and analyses, reproducible test configuration, independence evidence, anomaly reports and tool-credit rationale.
Be ready to demonstrate
Follow a requirement through the case, execution and result. Explain uncovered requirements, failures, retests and open issues using the controlled baseline.
Final / accomplishment
Is the certification data package complete and internally consistent?
Bring controlled evidence
HAS/SAS, HCI/SCI and environment indexes, final trace/coverage status, assurance records, deviations, open-report assessments and review-action closure.
Be ready to demonstrate
Show the final release identity and evidence completeness. Close findings or document authority-agreed dispositions; a completed review is not itself a certificate.
Before, during and after an SOI review
- Before: agree the agenda and data list, submit requested revisions in advance, identify owners and independent reviewers, rehearse live trace navigation, and prepare a findings/action log.
- During: use the agreed baseline, show the actual toolchain and evidence, explain deviations and unresolved anomalies, and record each action with owner and due date.
- After: make controlled corrections, assess impact on related artifacts, repeat affected verification, provide closure evidence, and obtain the agreed disposition of review findings.
Authoritative review guidance: FAA Order 8110.49A, Chapter 2 ↗ and FAA Order 8110.105B, Chapter 2 ↗. Use the licensed DO-178C / DO-254 standards for the applicable objectives and life-cycle data contents.
09
OFFICIAL STARTING POINTS
Guidance and source documents
FAAHow Aircraft Certification WorksThe current seven-phase overview of FAA and applicant responsibilities.↗FAADesign ApprovalsTC, STC, PMA, TSO, field approval, guidance, and applicant resources.↗AIRSoftware & Airborne Electronic HardwareFAA orders, policy, training, advisory circulars, and technical resources.↗AEHFAA Order 8110.105BCurrent FAA approval guidance for airborne electronic hardware.↗DATAFAA AC 20-153BAcceptance of aeronautical data processes and associated databases.↗CPGApplicant & Design Approval Holder ResourcesProduct Certification Guide, PSCP material, templates, conformity, and policy.↗RTCASoftware & Hardware StandardsOfficial RTCA overview and document-store links for DO-178C supplements and DO-254.↗SAEARP4754 Revision HistoryOfficial SAE record for ARP4754A and the newer ARP4754B revision.↗