AMC 20-189 / AC 20-189 and AC 00-71: Managing Open Problem Reports

What AMC 20-189 and AC 20-189 are

AMC 20-189, The Management of Open Problem Reports (OPRs), is EASA's acceptable means of compliance for handling problem reports that are still open when a product or ETSO article is approved. EASA published it in 2020. The FAA issued its harmonized counterpart, AC 20-189, Management of Open Problem Reports (OPRs), on September 16, 2022, with best-practice material in the companion AC 00-71.

Before this guidance, problem reporting rules were scattered across DO-178C, DO-254 and ARP4754A and did not line up. A software supplier, a hardware supplier and the aircraft applicant could each use different states, categories and reporting formats, and critical issues could lose visibility on the way up the supply chain. AMC/AC 20-189 gives the system, software and airborne electronic hardware (AEH) domains one common vocabulary and one reporting standard.

It applies to airborne systems and equipment, including their software and AEH, that could cause or contribute to Catastrophic, Hazardous or Major failure conditions, in both type certification and TSO / ETSO authorization. Like all advisory material it is an acceptable means of compliance, not the only one, but alternatives have to be proposed and accepted on the project.

Key definitions

• Problem report (PR): a means to identify and record the resolution of anomalous behavior, process non-compliance with development assurance plans and standards, and deficiencies in life cycle data.
• Open problem report (OPR): a problem report that has not reached the state 'Closed' at the time of approval.
• Approval: approval of a product or change to a product, or authorization of a TSO / ETSO article or change to one.

The four PR states

Every problem report moves through the same four states, and the guidance is precise about the last two. Many programs blur them, and that is where final-review findings come from.

1. 01Recorded: the problem has been documented through the problem reporting process.
2. 02Classified: the PR has been categorized under the project's classification scheme.
3. 03Resolved: the problem has been corrected or fully mitigated and the resolution verified, but not yet formally reviewed and confirmed.
4. 04Closed: a resolved PR that has gone through a formal review confirming the resolution is effective.

The four OPR classifications

The applicant has to establish a classification scheme that includes at least these four classes, describe it in the planning documents, and give every OPR exactly one class. When more than one could apply, the highest-priority class wins. Sub-classes are allowed but rank below the four.

1. 01Significant (highest priority): assessed at the product, system or equipment level, an actual or potential effect on function that may lead to a Catastrophic, Hazardous or Major failure condition, or may affect compliance with the operating rules.
2. 02Functional: an actual or potential effect on a function at the product, system or equipment level.
3. 03Process: a process non-compliance or deficiency that cannot result in a safety or functional effect.
4. 04Life Cycle Data: a deficiency in a life cycle data item that is not linked to a process non-compliance or deficiency.

Classification rules that catch suppliers out

• Mitigations count only if you control them. A classification may take credit for mitigations under the classifying stakeholder's control. A mitigation owned by someone else, such as the integrator or the aircraft applicant, can be credited only if that stakeholder has validated it and it remains acceptable within the TC, STC or TSO approval.
• When in doubt, a supplier classifies up. Any stakeholder other than the TC or STC applicant should classify an OPR as Significant if it could be Functional in one installation and Significant in another. An equipment or TSO supplier usually cannot see every installation, so it cannot assume the benign one.
• Classifications can legitimately differ between stakeholders. The same OPR may be Significant at the equipment level and Functional at the aircraft level once installation mitigations are known. That is expected, as long as each level documents the mitigations it relied on.

AC 00-71: mapping the old DO-248C problem report types

AC 00-71, Best Practices for Management of Open Problem Reports, was issued alongside AC 20-189 on September 16, 2022. Much of it explains how the four new classes relate to the problem report types many programs still use from DO-248C / ED-94C Discussion Paper #9, and where the new scheme deliberately removes ambiguity.

The most important change is that each OPR gets one classification, taken in priority order. AC 00-71's example: a missing or incorrect requirement can be classified as Life Cycle Data only after it is confirmed it cannot be Significant, Functional or Process.

• Type 0 maps to Significant. Some programs used type 1A for problems linked to Major failure conditions; under AC 20-189 anything that may cause or contribute to a Catastrophic, Hazardous or Major failure condition is Significant.
• Types 1A and 1B map to Functional. AC 00-71 suggests two sub-classes to keep the distinction: one for a functional effect that can lead to a Minor failure condition (e.g. 'Functional 1') and one for No Safety Effect (e.g. 'Functional 2').
• Type 3A may map to Process, but not when the process non-compliance could create a failure or fail to detect one. The old 'significant deviation from plans or standards' wording is gone.
• Types 2 and 3B map to Life Cycle Data, which can range from components with no safety or functional impact to purely documentary issues. Sub-classes are encouraged to separate them.
• Type 4 and anything else not covered can be an additional classification, ranked below the four required classes.

Two classification traps AC 00-71 calls out

• An incompletely verified requirement is not a Process OPR. If a requirement was not fully verified because of a process deficiency, its safety or functional impact is unknown, so the priority rule pushes it to Significant or Functional. That is deliberate: it puts the emphasis on finishing the verification rather than documenting the gap.
• There is no separate 'Operational' class. A problem with operational consequences is Significant or Functional depending on its effect. Programs that want visibility of operational issues can add an 'Operational' sub-class under Significant or Functional.

What 'Significant' means for engines, propellers and TSO articles

For an engine or propeller TC or STC, or a TSO article, the supplier is judging effects it cannot fully see at the aircraft level, so AC 00-71 defines Significant by anticipating the installed effect. Its example: on an engine TC, a partial or complete loss of thrust is a Minor Engine Effect, but may be far more severe at the aircraft level. Unless the engine manufacturer can confirm the installed effect is no more than Minor, the OPR is Significant. The assumptions and mitigations are typically recorded in the installation and operating instructions, such as the engine installation manual.

For a TSO authorization, the failure condition classification comes either from the applicant's own assumptions or from the TSO standard, and that drives the article-level safety analysis. An OPR is Significant when it may lead to a functional failure associated with a Catastrophic, Hazardous or Major failure condition.

Assessment and disposition

Each OPR has to be assessed for any functional limitations or operational restrictions it creates (at the equipment level for TSO articles, at the product level otherwise), for its relationships with other OPRs, and, for Significant and Functional OPRs, for the underlying technical cause.

The hard line is this: a Significant OPR without sufficient mitigation or justification to show its safety effect is acceptable should be resolved before approval. Disposition may involve coordination with the certification authority, which in practice means agreeing the mitigation argument with your FAA or EASA specialist, or your DER within delegated authority, well before the final review.

AC 00-71 best practices for the PR process

AC 00-71 describes what a mature problem report process typically includes. None of it is mandatory, but it is what a certification authority or DER will expect to see when they look at how your OPRs were produced.

• Recording: a defined way to document problems found while executing any life cycle process.
• Early classification: classify PRs as early in the life cycle as practical, not just before approval. A preliminary classification is fine; the point is to focus attention early on PRs with a potential safety or functional effect, and on process PRs that could undermine development assurance.
• Assessment by a review board: Significant, Functional and Process PRs are typically assessed by a board with representatives from the relevant disciplines, such as a flight test pilot and safety engineers. If a PR affects a crew display or alerting system, the board should include flight crew specialists. Life Cycle Data PRs can be assessed through peer review instead.
• Resolution scaled to classification: correct or mitigate PRs as early as practical, with resolution loops matched to the class. Life Cycle Data PRs, for example, can have shorter closure loops.
• Documented closure: closure includes review and confirmation that the fix works, recorded through a documented authorization such as Change Control Board sign-off. That sign-off is what moves a PR from Resolved to Closed.

What goes in the OPR summary report

An OPR summary report goes to the affected stakeholders and to the certification authority on request. It can be an aggregation of the Software and Hardware Accomplishment Summaries and system-level OPR reports. For each OPR it should give access to:

• The OPR identifier and the affected configuration items (part number, component or artifact name) or affected processes.
• A title and description written so the affected stakeholder can understand them, not in developer shorthand.
• The conditions under which the problem occurs.
• The classification and any known relationships with other OPRs.
• For Significant OPRs: the mitigations or justifications that make the safety effect acceptable, and any functional limitations or operational restrictions.
• For Functional OPRs: the mitigations or justifications that reduce the safety effect to Minor or No Safety Effect, and any limitations or restrictions.
• For Process OPRs: the extent and nature of the non-compliance that might affect meeting the development assurance objectives.
• For every OPR not classed Significant or Functional: the justification that it cannot have a safety or functional effect.

TSO and ETSO specifics

A TSO / ETSO authorization holder may leave Process and Life Cycle Data OPRs that are not needed for installation approval out of the summary it hands to installers. All OPRs should still be available to the certification authority on request. Significant and Functional OPRs stay in the report, because the installer is the one who has to show the installation is acceptable.

Who is responsible for what

The guidance recognizes four stakeholder levels: item, equipment or TSO article, system, and product. Problem report management should happen at every level, and the applicant is responsible for the overall PR process across all of its suppliers. OPR management (classification, assessment, disposition and reporting) should happen at a minimum at the TSO article level, for each individual system within the product, and at the product level.

Problems found after approval go through the same PR process, and any systemic process issue behind them should be identified and corrected. Where a PR could affect other products or articles in the same organization, there should be a way to share it so corrective action reaches them too.

Where programs lose time

• Treating Resolved as Closed. A fix that is verified but not formally reviewed is still open. Large numbers of Resolved PRs at SOI #4 or the final hardware review turn into OPRs that all need classifying and justifying.
• OPR titles only the developer understands. An installer or the certification authority has to be able to read the summary and judge the effect without access to your tracker.
• Crediting the integrator's mitigation without asking. Unvalidated mitigations from another stakeholder cannot lower a classification.
• Classification schemes that do not map to the four classes. Legacy DO-248C types are fine as sub-classes, as AC 00-71 shows, but the four classes and their priority order have to be visible.
• Parking unfinished verification as a Process OPR. If the impact is unknown, AC 00-71 is clear it belongs in Significant or Functional.
• No review board for the PRs that matter. Significant and Functional PRs assessed only by the developer, without safety, flight test or crew input, rarely survive the certification review unchanged.
• No assessment of related OPRs. Several individually Functional OPRs can combine into a Significant effect.
• Classifying late. OPR classification and justification written in the last month of a program rarely survive the review intact.

Putting it into your plans

1. 01Describe the PR states, the classification scheme (including any sub-classes, and how legacy DO-248C types map to it) and the priority order in the PSAC, PHAC or system certification plan, and in the configuration management plans.
2. 02Define the review board: who assesses Significant, Functional and Process PRs, which disciplines must attend for which systems, and what Change Control Board sign-off closes a PR.
3. 03Make classification, mitigation, related OPRs and technical cause mandatory fields in your problem reporting tool, so the summary report is generated, not written.
4. 04Agree with suppliers how their OPRs and classifications flow up, and which of your mitigations they may credit.
5. 05Review open PRs at each Stage of Involvement, not only at the end, and drive Resolved PRs to Closed continuously.
6. 06Prepare the OPR summary as part of the Software and Hardware Accomplishment Summaries and the system-level certification summary.

Working with a DER on open problem reports

OPR findings sit at the boundary between software, hardware and system safety, which is why they surface late and are hard to close. Aries Aero Systems' principal holds FAA DER authority for software (DO-178C) and airborne electronic hardware (DO-254) through Level A, and our team includes system safety and ODA experience, so OPR classifications and mitigation arguments can be reviewed across all three domains at once.

We can review your problem reporting and OPR process before SOI #1, audit an OPR list before the final review, or help a supplier and an integrator agree classifications and mitigations before they become findings.