![]() EASA/FAA Publication | |
Abbreviation | AMC 20-189 / AC 20-189 with AC 00-71 |
---|---|
Status | Active |
First published | 2020/2022 |
Domain | Airworthiness certification |
Website |
AMC 20-189 AC 20-189 AC 00-71 |
AC 20-189 and AMC 20-189, both entitled Management of Open Problem Reports (OPRs), are harmonized [1] advisory publications of the Federal Aviation Administration (FAA) and European Union Aviation Safety Agency (EASA), respectively.
These orders cover the importance of reporting and taking care of aircraft design problems known during certification or discovered any time after certification. They suggest that establishing effective problem reporting and correction methods early in development improves confidence in problem management during and after certification.
These AC/AMCs describe acceptable means for assisting both design approval applicants and holders of design approvals as they demonstrate compliance with airworthiness regulations for the management of open problem reports. Their intent is to provide consistent problem report guidance across the domains of systems ( ARP4754), software ( DO-178/ED-12), and hardware ( DO-254/ED-80). [2]
The two publications have nearly identical content; however, the EASA AMC has an appended section entitled "Guidance Material", regarding problem report lifecycle management, open problem report classification, and additional guidance related to one of the problem report classifications. The FAA did not include this appended material in AC 20-189 but has published it separately in AC 00-71, Best Practices for Management of Open Problem Reports (OPRs). For some background to the distinction between "Guidance Material" and "Best Practices", refer to the RTCA DO-178C clarification between guidance and guidelines.
Businesses developing equipment and system designs for aircraft should record evidence that assures the FAA and EASA that their designs are safe enough to fly in public airspace. Whenever a mistake or hazard is discovered or suspected in such designs, problem reports (PR) may be issued and managed until the problem is completely fixed and the problem report is "closed". Any time between starting a problem report and closing it, the problem report is usually said to be "open". Ideally, all problems are fixed and closed before the FAA or EASA certifies a design, but these authorities give specific considerations to problem reports that have not been closed at the time of certification, designating them as Open Problem Reports (OPR).
By communicating how the FAA and EASA want to see problem reports handled during and after certification, they hope to inform developers how to best prepare and manage their problem report systems for successful and effective certification.
Problem reporting is an important activity in the creation of safe equipment and systems for hazardous industries. As a discipline, problem reporting conducts a life cycle of activities; beginning by recording the problem, hazard in the design of a product or system,
Broadly, problem reports are open from the moment they are started to the moment they are closed. More narrowly, OPR can refer to problem reports that are identified as open at the time of a major milestone or certification review. The intention is for the OPR to remain open past completion of the review to allow work and certification effort to continue before the issues are closed. The FAA is particularly concerned that OPR at the time of certification are adequately managed so that they represent no unacceptable flight hazard.
In 1987, the International Organization for Standardization introduced problem reporting to quality system management for the development of new products, through the first edition of their standard ISO 9001, Model for quality assurance in design, development, production, installation, and servicing. From this origin, problem reporting entered aviation software safety considerations through DO-178B:
The present FAA/EASA guidelines for problem reporting are now found in these later advisories:
4.2 States of PRs/OPRs
4.3 Classification of PRs/OPRs
These documents have been developed in close coordination with FAA, in order to achieve harmonization in these domains.
Published July 2020, this document compliments current airborne software, hardware and systems guidance by covering the topic of "The Management of Open Problem Reports.
AMC 20-189 provides guidance on management and classification of Open Problem Reports (OPR) at time of product approval or ETSO authorization. This material is intended to be used when showing compliance for and across airborne electronic hardware, software and system development.
These documents have been developed in close coordination with FAA, in order to achieve harmonization in these domains. They result from four years of work in coordination with FAA, including a joint EASA/FAA public consultation phase, and with the support of the US and European industry associations ASD, GAMA, AIA according to EASA.
Published July 2020, this document compliments current airborne software, hardware and systems guidance by covering the topic of "The Management of Open Problem Reports.
In the document "DO-248C Supporting Information for DO-178C and DO-278A" there is a title "Assessment and Classification of Open Software Problems" [3]. Under this heading, there is also a warning that having a large number of open problem reports during the certification approval phase can pose a risk in terms of obtaining approval. The main reason for this is that the large number of open problem reports is an indication that the software is not mature enough and that the process assurance approach that should be applied while developing the software is not properly implemented[4]. An example chart that can be used to classify open problem reports is also given under the title.
AMC 20-189 "The Management of Open Problem Reports (OPRs)" published by EASA on 29 July 2020 proposes a different classification from the classification in DO-248C. AMC 20-189 provides a common problem reporting management system for software and complex-electronic hardware. It is emphasized in the document that one of the main objectives of AMC 20-189 is to provide compatibility in different open problem report management methods currently recommended by different guidance documents for software and complex-electronic hardware.
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.
In August 2017, five months after the 737 MAX was certified by the FAA and three months after it entered revenue service, Boeing issued a problem report to its supplier complaining that the 737 MAX's AOA Disagree alert was tied to an optional AOA Indicator display and therefore was not functioning on the vast majority of the 737 MAX fleet worldwide.
40 ▪ Rather than immediately informing the FAA and Boeing customers about this issue, and advising Boeing to fix the problem via a software update as soon as possible, a Boeing AR consented to Boeing's plan to postpone the software update until 2020, three years later, so it could be done in conjunction with the rollout of Boeing's planned 737 MAX-10 aircraft.
41 ▪ Although Boeing prepared a "Fleet Team Digest" to inform its customers about the inoperable AOA Disagree alert, the company never sent it, keeping its customers in the dark about the inoperable alert.
42 ▪ Boeing provided Lion Air a Flight Crew Operations Manual (FCOM) on August 16, 2018, one year after learning that the AOA Disagree alert was not functioning on most 737 MAX aircraft, highlighting the operation of the AOA Disagree alert. Boeing failed to indicate that it knew the AOA Disagree alert on the Lion Air 737 MAX aircraft was not operational.
Category:Avionics Category:Safety Category:Software requirements Category:Computer standards
![]() EASA/FAA Publication | |
Abbreviation | AMC 20-189 / AC 20-189 with AC 00-71 |
---|---|
Status | Active |
First published | 2020/2022 |
Domain | Airworthiness certification |
Website |
AMC 20-189 AC 20-189 AC 00-71 |
AC 20-189 and AMC 20-189, both entitled Management of Open Problem Reports (OPRs), are harmonized [1] advisory publications of the Federal Aviation Administration (FAA) and European Union Aviation Safety Agency (EASA), respectively.
These orders cover the importance of reporting and taking care of aircraft design problems known during certification or discovered any time after certification. They suggest that establishing effective problem reporting and correction methods early in development improves confidence in problem management during and after certification.
These AC/AMCs describe acceptable means for assisting both design approval applicants and holders of design approvals as they demonstrate compliance with airworthiness regulations for the management of open problem reports. Their intent is to provide consistent problem report guidance across the domains of systems ( ARP4754), software ( DO-178/ED-12), and hardware ( DO-254/ED-80). [2]
The two publications have nearly identical content; however, the EASA AMC has an appended section entitled "Guidance Material", regarding problem report lifecycle management, open problem report classification, and additional guidance related to one of the problem report classifications. The FAA did not include this appended material in AC 20-189 but has published it separately in AC 00-71, Best Practices for Management of Open Problem Reports (OPRs). For some background to the distinction between "Guidance Material" and "Best Practices", refer to the RTCA DO-178C clarification between guidance and guidelines.
Businesses developing equipment and system designs for aircraft should record evidence that assures the FAA and EASA that their designs are safe enough to fly in public airspace. Whenever a mistake or hazard is discovered or suspected in such designs, problem reports (PR) may be issued and managed until the problem is completely fixed and the problem report is "closed". Any time between starting a problem report and closing it, the problem report is usually said to be "open". Ideally, all problems are fixed and closed before the FAA or EASA certifies a design, but these authorities give specific considerations to problem reports that have not been closed at the time of certification, designating them as Open Problem Reports (OPR).
By communicating how the FAA and EASA want to see problem reports handled during and after certification, they hope to inform developers how to best prepare and manage their problem report systems for successful and effective certification.
Problem reporting is an important activity in the creation of safe equipment and systems for hazardous industries. As a discipline, problem reporting conducts a life cycle of activities; beginning by recording the problem, hazard in the design of a product or system,
Broadly, problem reports are open from the moment they are started to the moment they are closed. More narrowly, OPR can refer to problem reports that are identified as open at the time of a major milestone or certification review. The intention is for the OPR to remain open past completion of the review to allow work and certification effort to continue before the issues are closed. The FAA is particularly concerned that OPR at the time of certification are adequately managed so that they represent no unacceptable flight hazard.
In 1987, the International Organization for Standardization introduced problem reporting to quality system management for the development of new products, through the first edition of their standard ISO 9001, Model for quality assurance in design, development, production, installation, and servicing. From this origin, problem reporting entered aviation software safety considerations through DO-178B:
The present FAA/EASA guidelines for problem reporting are now found in these later advisories:
4.2 States of PRs/OPRs
4.3 Classification of PRs/OPRs
These documents have been developed in close coordination with FAA, in order to achieve harmonization in these domains.
Published July 2020, this document compliments current airborne software, hardware and systems guidance by covering the topic of "The Management of Open Problem Reports.
AMC 20-189 provides guidance on management and classification of Open Problem Reports (OPR) at time of product approval or ETSO authorization. This material is intended to be used when showing compliance for and across airborne electronic hardware, software and system development.
These documents have been developed in close coordination with FAA, in order to achieve harmonization in these domains. They result from four years of work in coordination with FAA, including a joint EASA/FAA public consultation phase, and with the support of the US and European industry associations ASD, GAMA, AIA according to EASA.
Published July 2020, this document compliments current airborne software, hardware and systems guidance by covering the topic of "The Management of Open Problem Reports.
In the document "DO-248C Supporting Information for DO-178C and DO-278A" there is a title "Assessment and Classification of Open Software Problems" [3]. Under this heading, there is also a warning that having a large number of open problem reports during the certification approval phase can pose a risk in terms of obtaining approval. The main reason for this is that the large number of open problem reports is an indication that the software is not mature enough and that the process assurance approach that should be applied while developing the software is not properly implemented[4]. An example chart that can be used to classify open problem reports is also given under the title.
AMC 20-189 "The Management of Open Problem Reports (OPRs)" published by EASA on 29 July 2020 proposes a different classification from the classification in DO-248C. AMC 20-189 provides a common problem reporting management system for software and complex-electronic hardware. It is emphasized in the document that one of the main objectives of AMC 20-189 is to provide compatibility in different open problem report management methods currently recommended by different guidance documents for software and complex-electronic hardware.
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.
In August 2017, five months after the 737 MAX was certified by the FAA and three months after it entered revenue service, Boeing issued a problem report to its supplier complaining that the 737 MAX's AOA Disagree alert was tied to an optional AOA Indicator display and therefore was not functioning on the vast majority of the 737 MAX fleet worldwide.
40 ▪ Rather than immediately informing the FAA and Boeing customers about this issue, and advising Boeing to fix the problem via a software update as soon as possible, a Boeing AR consented to Boeing's plan to postpone the software update until 2020, three years later, so it could be done in conjunction with the rollout of Boeing's planned 737 MAX-10 aircraft.
41 ▪ Although Boeing prepared a "Fleet Team Digest" to inform its customers about the inoperable AOA Disagree alert, the company never sent it, keeping its customers in the dark about the inoperable alert.
42 ▪ Boeing provided Lion Air a Flight Crew Operations Manual (FCOM) on August 16, 2018, one year after learning that the AOA Disagree alert was not functioning on most 737 MAX aircraft, highlighting the operation of the AOA Disagree alert. Boeing failed to indicate that it knew the AOA Disagree alert on the Lion Air 737 MAX aircraft was not operational.
Category:Avionics Category:Safety Category:Software requirements Category:Computer standards