How AMC/AC 20-189 Stops “Un-Accomplishment Summaries” in DO-178C or DO-254 programs

How Can the New AMC/AC 20-189 Help Manage Problem Reports in DO-178C and DO-254 Projects?

Your DO-178C or DO-254 Accomplishment Summary becomes a “un” accomplishment summary when too many open Problem Reports (PRs) remain unresolved at the end of a certification or TSO project. Both DO-178C (airborne software) or DO-254 (airborne electronic hardware) standards allow for a listing of open PRs in the accomplishment summary document.  However, many applicants have abused this and create long lists of unresolved and uncategorized PRs in the Software/Hardware Accomplishment Summary documents. This makes it difficult for applicants to show compliance and regulators to find compliance. The result, as one would guess, is equipment and aircraft level functional issues and airworthiness directives. 

The New AMC/AC 20-189 provides guidance on a means of compliance when applicants have unresolved (i.e., open) PRs at the end of a TC, STC or TSO project.  The reason for this is to provide a consistent expectation related to the communication, review and assessment of open PRs (OPRs) by all possible stakeholders who are integrating the software or AEH into their aircraft programs.  

AMC 20-189 was released on July 29, 2020 by EASA (and soon the FAA will release the harmonized AC 20-189). This document provides guidance on management and classification of OPRs for airborne electronic hardware, software and system development, at the time of product approval or ETSO authorization.


The compliance of system, software and electronic hardware domains relies on managing PRs to ensure the product is safe at the time of approval. The problem is the existing guidance was inconsistent and unclear, especially across and between each of these domains. This new AMC provides consistent guidance on managing OPRs that works alongside existing guidance for each domain, and is harmonized between EASA and the FAA.

What AMC 20-189 Covers

This AMC provides consistent terminology to use to define Problem Report “states,” type classifications for PRs, and guidance on how to manage them to enable the consistent and timely management of PRs across domains to ensure visibility of critical issues remaining at the time of approval.

What Will this Mean for YOUR Project?

First and foremost, if you are starting or working on any airborne systems, software or hardware programs, you will need to review your configuration management procedures to see what gaps exist between those procedures and this AC/AMC.   You will then need to update your Configuration Management Plan document to ensure it aligns with this new guidance. (Don’t forget to have your certification liaison sign off on any significant changes).

The key things to keep in mind are:

  1. PR management plans and processes should span systems, software and hardware domains and be used throughout development and for continued airworthiness aspects.
  2. PRs that occur after a certification or authorization approval should be reported in a manner that is understandable to all affected stakeholders.  For example, an equipment level PR after certification authority approval (via TC, STC or TSO) may affect aircraft level functions and create a hazard if not reported and addressed. 
  3. Companies with distributed geographical organizations, especially across countries, should ensure that the tools and procedures for problem reporting are accessible (including viewing and resolution) by all affected stakeholders.
  4. Companies should strive to actively work to close problem reports throughout the development process to reduce the number of OPRs presented at the time of certification (or authorization in the case of a TSO/ETSO piece of equipment). 
  5. The PR process and configuration management plan should describe classification systems and ensure the OPR content aligns with AC/AMC20-189. This will ensure that all affected parties understand the types and seriousness of the OPRs.
  6. The PR process should review documentation of the assessment of each OPR to ensure it clearly captures functional limitations and/or operation restrictions at the equipment level or product level.
  7. Stakeholders at each level should manage OPRs (TSO, System and final product — aircraft, engine propeller).