U.S. Department of Transportation Federal Aviation Administration Advisory Circular Subject: Management of Open Problem Reports (OPRs) Date: Sep 1, 2022 Initiated by: AIR-622 AC No: 20-189 Change:
1. PURPOSE. This advisory circular (AC) describes an acceptable means for showing compliance with the applicable airworthiness regulations for the management of open problem reports (OPRs) in technical standard order (TSO) authorization and type certification for the system, software, and airborne electronic hardware (AEH) domains.
This document contains guidance that is not legally binding in its own right nor will be relied upon by the Department of Transportation or the Federal Aviation Administration as a separate basis for affirmative enforcement action or other administrative penalty.
Moreover, conformity with this guidance document (as distinct from existing statutes and regulations) is voluntary only, and nonconformity will not affect rights and obligations under statutes and regulations. This document is intended only to provide clarity to the public regarding existing requirements under the law or agency policies. However, if you use the means described in this AC, you should follow it in all applicable respects unless alternate means are proposed and accepted by the FAA.
2. APPLICABILITY. This AC may be used by applicants, design approval holders, and developers of airborne systems and equipment to be installed on type certificated aircraft, engines, and propellers. This AC applies to all airborne electronic systems and equipment, including to the software and AEH components contained in those systems that could cause or contribute to Catastrophic, Hazardous, or Major failure conditions.
3. BACKGROUND.
3.1 Each of the system, software, and AEH domains relies on problem report (PR) management to ensure the proper management of OPRs and to help ensure safe products at the time of approval. However, existing guidance on PR and OPR management is inconsistent and incomplete across domains. Therefore, this AC provides consistent guidance across these domains for PR management, OPR management, stakeholder responsibilities, reporting, and other aspects of OPR management. This AC complements but does not alleviate the project-applicable system, software, and AEH guidance.
3.2 The technical content of this AC is harmonized as appropriate with European Union Aviation Safety Agency (EASA) AMC 20-189.
3.3 See AC 00-71, Best Practices for Management of Open Problem Reports.
09/1/2022 AC 20-189 2
4. DEFINITIONS.
4.1 Terms defined in this AC (Sources cited are found in paragraph 8) x Approval – The term ‘approval’ in this document means approval by the FAA of a product or of changes to a product, or authorization of a TSO article or of changes to a TSO article.
x Article – Refer to Title 14 of the Code of Federal Regulations (14 CFR) part 21.
x Development assurance – All of those planned and systematic actions used to substantiate, with an adequate level of confidence, that errors in requirements, design, and implementation have been identified and corrected such that the system satisfies the applicable certification basis (source: ARP4754A/ED-79A).
x Equipment – An item or collection of items with a defined set of requirements.
x Error – A mistake in requirements, design, or implementation, with the potential of producing a failure.
x Failure – The inability of a system or system component to perform a function within specified limits (source: DO-178C/ED-12C and DO-254/ED-80).
x Item – A hardware or software element having bounded and well-defined interfaces (source: ARP4754A/ED-79A).
x Open problem report (OPR) – A problem report that has not reached the state ‘closed’ at the time of approval.
x 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 (adapted from DO-178C/ED-12C).
x Product – Refer to 14 CFR part 21.
x System – A combination of inter-related equipment, article(s), and/or items arranged to perform a specific function(s) within a product.
4.2 States of PRs/OPRs x Recorded – A problem that has been documented using the problem reporting process.
x Classified – A problem report that has been categorized in accordance with an established classification scheme.
09/1/2022 AC 20-189 3 x Resolved – A problem report that has been corrected or fully mitigated, for which resolution of the problem has been verified but not formally reviewed and confirmed.
x Closed – A resolved problem report that underwent a formal review and confirmation of an effective resolution of the problem.
4.3 Classification of PRs/OPRs x ‘Significant’ – assessed at the product, system, or equipment level, a PR that has an actual or potential effect on the product, system, or equipment function that may lead to a Catastrophic, Hazardous or Major failure condition, or may affect compliance with the operating rules.
x ‘Functional’ – a PR that has an actual or a potential effect on a function at the product, system, or equipment level.
x ‘Process’ – a PR that records a process non-compliance or deficiency that cannot result in a potential safety, nor a potential functional, effect.
x ‘Life Cycle Data’ – a PR that is linked to a deficiency in a life cycle data item but not linked to a process non-compliance or process deficiency.
5. PROBLEM REPORT MANAGEMENT. The PR management process is a key enabler for OPR management. The PR management process enables the consistent and timely management of problems encountered across the system, software and AEH domains. Consequently, this process reduces the risk of a loss of visibility of critical issues remaining at the time of approval.
5.1 A PR management process across the system, software, and AEH domains should be established and used during the development (both for initial certification and subsequent changes) of a product or a TSO article. The PR management process should address the review and resolution of PRs that impact the transition to other development assurance processes.
5.2 A problem recorded after approval should also be managed through the PR management process, and any related systemic process issues should be identified and corrected.
5.3 PRs that cannot be resolved by the current stakeholder should be reported in a manner that is understandable to the affected stakeholders.
5.4 For PRs that may have an impact on other products or articles that are developed within an organization, a means should be established for sharing PR information so that any necessary corrective actions can be taken.
6. OPR MANAGEMENT. An OPR management process, based on the PR management process, should be established across the system, software, and AEH domains, including the following process steps:
09/1/2022 AC 20-189 4
6.1 Classification of OPRs
6.1.1 The applicant should establish an OPR classification scheme including, at a minimum, the following classifications: ‘Significant’, ‘Functional’, ‘Process’, and ‘Life Cycle Data’. Other classifications or sub-classifications may be created as needed. The classification scheme should be described in the appropriate planning document(s).
6.1.2 Each OPR should be assigned a single classification per the classification scheme.
When multiple classifications apply, the OPR should be assigned the classification with the highest priority. The priority from highest to lowest (including defined sub-classifications) is:
x ‘Significant’;
x ‘Functional’;
x ‘Process’;
x ‘Life Cycle Data’;
x Any other OPR classification.
Note: the classification of an individual OPR may differ from one stakeholder to another, depending on the known mitigations at the time of classification.
6.1.3 The classification of an OPR should account for and document all mitigations known at the time of classification that are under the control of the classifying stakeholder. A mitigation that is controlled by another stakeholder may be considered in the classification only if validated with that stakeholder, and provided this mitigation remains acceptable in the frame of the type certificate (TC)/supplemental type certificate (STC) approval, or TSO article authorization, as applicable.
6.1.4 A stakeholder, other than the aircraft TC or STC applicant, should classify as ‘Significant’ any OPR for which the classification may vary between ‘Functional’ and ‘Significant’, depending on the installation.
6.2 Assessment of OPRs. Each OPR should be assessed to determine:
x Any resulting functional limitations or operational restrictions at the equipment level (for TSO articles) or at the product level (for other types of approvals);
x Relationships that may exist with other OPRs; and x For a ‘Significant’ or ‘Functional’ OPR, the underlying technical cause of the problem.
6.3 Disposition: OPRs classified as ‘Significant’ per the classification in paragraph 6.1, for which no sufficient mitigation or justification exists to substantiate the acceptability of
09/1/2022 AC 20-189 5 the safety effect, should be resolved prior to approval. The disposition of OPRs may involve coordination with the certification authority.
6.4 Reporting: An OPR summary report should be prepared and provided to the affected stakeholder(s), and to the certification authority upon request. The OPR summary report may be an aggregation of summaries (e.g., Software/Hardware Accomplishment Summaries or system-level OPR reports) prepared by all involved stakeholders. The summary report should provide access to the following information for each OPR:
6.4.1 Identification of the OPR (for example, the OPR ID);
6.4.2 Identification of the affected configuration item(s) (for example, the item part number, component name, artifact name) or of the affected process(es);
6.4.3 The title or a summary of the problem, formulated in a manner understandable by the affected stakeholder(s);
6.4.4 Description of the problem, formulated in a manner understandable by the affected stakeholder(s);
6.4.5 Conditions under which the problem occurs;
6.4.6 OPR classification and assessment results (per paragraphs 6.1 and 6.2), including:
6.4.6.1. For each OPR, regardless of its classification:
6.4.6.1.1. The classification of the OPR; and
6.4.6.1.2. Relationships that are known to exist with other OPRs.
6.4.6.2. For OPRs classified as ‘Significant’:
6.4.6.2.1. Description of any mitigations or justifications used to substantiate the acceptability of the OPR safety effect (per paragraph 6.3); and
6.4.6.2.2. Functional limitations and operational restrictions, if any.
6.4.6.3. For OPRs classified as ‘Functional’:
6.4.6.3.1. Description of any mitigations or justifications used to reduce the safety effect to Minor or No Safety Effect; and
6.4.6.3.2. Functional limitations and operational restrictions, if any.
6.4.6.4. For OPRs classified as ‘Process’, a description of the extent or nature of the process non-compliance or deficiency that might contribute to not satisfying the applicable development assurance objectives.
6.4.6.5. For each OPR not classified as ‘Significant’ or ‘Functional’, justification that the error cannot have a safety or functional effect.
09/1/2022 AC 20-189 6
6.5 TSOA Specifics: The TSO Authorization holder may exclude from the reporting process (per paragraph 6.4) any OPRs classified as ‘Process’ or ‘Life Cycle Data’ that are not necessary for the installation approval. However, all OPRs should be available upon request by the certification authority for assessment in the frame of the TSO approval.
7. STAKEHOLDER RESPONSIBILITIES. The levels of stakeholders include: item, equipment or TSO article, system, and product. The actual stakeholders for a specific project depend on the project organization.
7.1 PR Management (per paragraph 5): Should be performed by the stakeholder at each level. The applicant has responsibility for the overall PR process for all the involved stakeholders.
7.2 OPR Management (per paragraph 6): Should be performed, at a minimum, at the TSO article level, at the level of each individual system within a product, and at the product level.
8. RELATED PUBLICATIONS.
8.1 Title 14 CFR Applicable Sections. This AC provides guidance on development of an acceptable means of compliance to the following regulations, with respect to managing problem reporting: 14 CFR parts 21, 23, 25, 27, 29, 33, and 35 (principally, §§ 21 subpart O, 23.2500, 23.2505, 23.2510, 25/27/29.1301, 25/27/29.1309, 33.28, and 35.23).
8.2 FAA ACs (Refer to current version) x AC 20-115, Airborne Software Development Assurance Using EUROCAE ED-12( ) and RTCA DO-178( ).
x AC 20-152, Development Assurance for Airborne Electronic Hardware (AEH).
x AC 20-170, Integrated Modular Avionics Development, Verification, Integration and Approval using RTCA DO-297 and Technical Standard Order C-153.
x AC 20-171, Alternatives to RTCA/DO-178B for Software in Airborne Systems and Equipment.
x AC 20-174, Development of Civil Aircraft and Systems.
x AC 21-46, Technical Standard Order Program.
x AC 21-50, Installation of TSOA Articles and LODA Appliances.
x AC 23.2010-1, FAA Accepted Means of Compliance process for 14 CFR Part 23.
x AC 23.1309-1, System Safety Analysis and Assessment for Part 23 Airplanes.
x AC 25.1309-1, System Design and Analysis.
09/1/2022 AC 20-189 7 x AC 27-1309, Equipment, Systems, and Installations, (included in AC 27-1, Certification of Normal Category Rotorcraft).
x AC 29-1309, Equipment, Systems, and Installations, (included in AC 29-2, Certification of Transport Category Rotorcraft).
x AC 33.28-1, Compliance Criteria for 14 CFR § 33.28, Aircraft Engines, Electrical and Electronic Engine Control Systems.
x AC 33.28-2, Guidance Material for 14 CFR 33.28, Reciprocating Engines, Electrical and Electronic Engine Control Systems.
x AC33.28-3, Guidance Material For 14 CFR § 33.28, Engine Control Systems.
x AC 35.23-1, Guidance Material for 14 CFR 35.23, Propeller Control Systems.
8.3 EASA Acceptable Means of Compliance (AMC) (Refer to current version) x AMC 20-115, Airborne Software Development Assurance Using EUROCAE ED-12 and RTCA DO-178.
x AMC 20-152, Development Assurance for Airborne Electronic Hardware (AEH).
8.4 Industry Documents x SAE International Aerospace Recommended Practice (ARP) 4754A, Guidelines for Development of Civil Aircraft and Systems, dated December 21, 2010.
x RTCA DO-178, Software Considerations in Airborne Systems and Equipment Certification, dated January 1982 (no longer in print).
x RTCA DO-178A, Software Considerations in Airborne Systems and Equipment Certification, dated March 1985 (no longer in print).
x RTCA DO-178B, Software Considerations in Airborne Systems and Equipment Certification, dated December 1, 1992.
x RTCA DO-178C, Software Considerations in Airborne Systems and Equipment Certification, dated December 13, 2011.
x RTCA DO-248C, Supporting Information for DO-178C and DO-278A, dated December 13, 2011.
x RTCA DO-254, Design Assurance Guidance for Airborne Electronic Hardware, dated April 19, 2000.
x RTCA DO-297, Integrated Modular Avionics (IMA) Development Guidance and Certification Considerations, dated November 8, 2005.
09/1/2022 AC 20-189 8 x RTCA DO-330, Software Tool Qualification Considerations, dated December 13, 2011.
x RTCA DO-331, Model-Based Development and Verification Supplement to DO-178C and DO-278A, dated December 13, 2011.
x RTCA DO-332, Object-Oriented Technology and Related Techniques Supplement to DO-178C and DO-278A, dated December 13, 2011.
x RTCA DO-333, Formal Methods Supplement to DO-178C and DO-278A, dated December 13, 2011.
x EUROCAE ED-12, Software Considerations in Airborne Systems and Equipment Certification, dated May 1982 (no longer in print).
x EUROCAE ED-12A, Software Considerations in Airborne Systems and Equipment Certification, dated October 1985 (no longer in print).
x EUROCAE ED-12B, Software Considerations in Airborne Systems and Equipment Certification, dated December 1992.
x EUROCAE ED-12C, Software Considerations in Airborne Systems and Equipment Certification, dated January 2012.
x EUROCAE ED-80, Design Assurance Guidance for Airborne Electronic Hardware, dated April 2000.
x EUROCAE ED-94C, Supporting Information for ED-12C and ED-109A, dated January 2012.
x EUROCAE ED-215, Software Tool Qualification Considerations, dated January 2012.
x EUROCAE ED-216, Formal Methods Supplement to ED-12C and ED-109A, dated January 2012.
x EUROCAE ED-217, Object-Oriented Technology and Related Techniques Supplement to ED-12C and ED-109A, dated January 2012 x EUROCAE ED-218, Model-Based Development and Verification Supplement to ED- 12C and ED-109A, dated January 2012.
09/1/2022 AC 20-189 9
9. WHERE TO FIND THIS AC.
9.1 You may find this AC at http://www.faa.gov/regulations_policies/advisory_circulars/.
9.2 If you have suggestions for improvement or changes, you may use the template at the end of this AC.
Victor Wicklund Aviation Safety Acting Director, Policy and Innovation Division Aircraft Certification Service Digitally signed by
VICTOR W WICKLUND Date: 2022.09.16 11:12:24 -07'00'
If you find an error in this AC, have recommendations for improving it, or have suggestions for new items/subjects to be added, you may let us know by (1) emailing this form to ( ) or
(2) faxing it to the attention of the LOB/SO ( ).
Subject:D a t e :
Please mark all appropriate line items:
ڧ An error (procedural or typographical) has been noted in paragraph on page .
OMB Control Number: 2120-0746 Expiration Date: /3/202 Advisory Circular Feedback Form Paperwork Reduction Act Burden Statement: $IHGHUDODJHQF\PD\QRWFRQGXFWRUVSRQVRUDQGDSHUVRQLVQRW UHTXLUHGWRUHVSRQGWRQRUVKDOODSHUVRQEHVXEMHFWWRDSHQDOW\IRUIDLOXUHWRFRPSO\ZLWKDFROOHFWLRQRILQIRUPDWLRQ VXEMHFWWRWKHUHTXLUHPHQWVRIWKH3DSHUZRUN5HGXFWLRQ$FWXQOHVVWKDWFROOHFWLRQRILQIRUPDWLRQGLVSOD\VDFXUUHQWO\YDOLG 20%&RQWURO1XPEHU7KH20%&RQWURO1XPEHUIRUWKLVLQIRUPDWLRQFROOHFWLRQLV3XEOLFUHSRUWLQJIRUWKLV FROOHFWLRQRILQIRUPDWLRQLVHVWLPDWHGWREHDSSUR[LPDWHO\PLQXWHVSHUUHVSRQVHLQFOXGLQJWKHWLPHIRUUHYLHZLQJ LQVWUXFWLRQVVHDUFKLQJH[LVWLQJGDWDVRXUFHVJDWKHULQJDQGPDLQWDLQLQJWKHGDWDQHHGHGFRPSOHWLQJDQGUHYLHZLQJWKH FROOHFWLRQRILQIRUPDWLRQ $OOUHVSRQVHVWRWKLVFROOHFWLRQRILQIRUPDWLRQDUHYROXQWDU\)$$2UGHU'6HQGFRPPHQWVUHJDUGLQJWKLVEXUGHQ HVWLPDWHRUDQ\RWKHUDVSHFWRIWKLVFROOHFWLRQRILQIRUPDWLRQLQFOXGLQJVXJJHVWLRQVIRUUHGXFLQJWKLVEXUGHQWR ,QIRUPDWLRQ&ROOHFWLRQ&OHDUDQFH2IILFHU%DUEDUD+DOO,QGHSHQGHQFH$YH:DVKLQJWRQ'& ڧ Recommend paragraph on page be changed as follows:
ڧ In a future change to this AC, please cover the following subject:
(Briefly describe what you want added.)
ڧ Other comments:
ڧ Iwould like to discuss the above. Please contact me.
Submitted by: Date:
FAA Form 1320-73 ( 683(56('(635(9,286(',7,216