Document
Advisory
U.S. Department of Transportation
Circular
Federal Aviation Administration Subject : Best Practices for Management of Date: Sep 1 6 , 2022 AC No: 00-71 Open Problem Reports (OPRs) Initiated by: AIR-622 Change: 1. PURPOSE. This advisory circular (AC) provides “best practices” for the management of open problem reports, and is intended to complement AC 20-189, Management of Open Problem Reports (OPRs) . 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.
2. APPLICABILITY. This AC provides a means of assisting 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 airborne electronic hardware (AEH) components contained in those systems that could cause or contribute to Catastrophic, Hazardous, or Major failure conditions.
3. DEFINITIONS.
3.1 Terms defined in this AC (Sources cited are found in paragraph 5) • Approval – The term ‘approval’ in this document means the approval by the FAA of a product or of changes to a product, or authorization of a technical standard order (TSO) article or of changes to a TSO article.
• Article – Refer to Title 14 of the Code of Federal Regulations (14 CFR) part 21.
• 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).
• Equipment – An item or collection of items with a defined set of requirements.
09/1 6 /2022 AC 00-71 • Error – A mistake in requirements, design, or implementation with the potential of producing a failure.
• 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).
• Item – A hardware or software element having bounded and well-defined interfaces (source: ARP4754A/ED-79A).
• Open problem report (OPR) – A problem report that has not reached the state ‘closed’ at the time of approval.
• 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).
• Product – Refer to 14 CFR part 21.
• System – A combination of inter-related equipment, article(s), and/or items arranged to perform a specific function(s) within a product.
3.2 States of PRs/OPRs • Recorded – A problem that has been documented using the problem reporting process.
• Classified – A problem report that has been categorized in accordance with an established classification scheme.
• 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.
• Closed – A resolved problem report that underwent a formal review and confirmation of an effective resolution of the problem.
3.3 Classification of PRs/OPRs • 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.
• Functional – a PR that has an actual or a potential effect on a function at the product, system, or equipment level.
• Process – a PR that records a process non-compliance or deficiency that cannot result in a potential safety nor a potential functional effect.
09/1 6 /2022 AC 00-71 • 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.
4. BEST PRACTICES.
4.1 PR Management . Typically, PR processes include the following aspects: 4.1.1 PR Recording – a means to document problems resulting from the execution of life cycle processes.
4.1.2 PR Classification – a means to classify PRs prior to the time of approval of the product or of the TSO article, as early in the life cycle as practical. While early classification may be preliminary, it will help to focus attention on PRs with a potential safety or functional effect, as well as process PRs that may impact the development or development assurance processes.
4.1.3 PR Assessment – a means to assess the effect of having a PR remain open at the time of approval. Assessment of PRs classified as ‘Significant’, ‘Functional’ or ‘Process’ would typically be performed by a review board which includes representatives from the appropriate disciplines, e.g., flight test pilot, safety engineer(s). For example, if the PR affects a crew display or alerting system, the review board should include flight crew specialist(s). Assessment of PRs classified as ‘Life Cycle Data’ may be performed within the peer review process instead of a review board.
4.1.4 PR Resolution – a means to correct or mitigate PRs prior to the time of approval, as early in the life cycle as practical. The PR resolution process may depend on the classification of the PR; for example, shorter closure loops could be set for PRs classified as ‘Life Cycle Data’.
4.1.5 PR Closure – a means to close PRs, which includes the review and confirmation of the resolution of the problem, and is indicated through a documented authorization process (e.g., Change Control Board signoff).
4.2 OPR Classification. The following subparagraphs link the classifications presented in DO-248C/ED-94C, DP #9 to those defined in AC 20-189, subparagraph 6.1. This paragraph highlights the clarifications made to the former scheme (e.g., removing overlaps between classifications).
4.2.1 The most important clarification when compared with the former classification scheme is to give each OPR a single classification using a given order of priority as reflected in AC 20-189 subparagraph 6.1.2. This promotes visibility of the most relevant issues and helps to prevent inconsistencies in classification. For example, a missing or incorrect requirement issue can be classified as ‘Life Cycle Data’ only if it is confirmed that it cannot be classified as ‘Significant’, ‘Functional’, or ‘Process’, in that order of priority.
09/1 6 /2022 AC 00-71 4.2.2 Type ‘Significant’ – this typically maps to ‘type 0’. However, some applicants may have used ‘type 1A’ to characterize some PRs, for instance, those linked to Major failure conditions. AC 20-189 clarifies that those PRs potentially causing or contributing to Catastrophic, Hazardous, or Major failure conditions belong to the class ‘Significant’.
4.2.3 Type ‘Functional’ – this typically maps to ‘type 1A’ or ‘type 1B’, that is, a problem that results in a failure with a minor or no adverse impact on safety. A PR whose consequence is a failure that can potentially lead to a Minor failure condition could be mapped to ‘type 1A’ and a PR leading to a failure having No Safety Effect could be mapped to ‘type 1B’. Two separate sub-classifications could therefore be created in the applicant’s classification scheme to ease the mapping: problems having a functional effect leading to a Minor failure condition could be classified separately (e.g., ‘Functional 1’) from the ones having No Safety Effect (e.g. ‘Functional 2’). Moreover, an important clarification is that AC 20-189 does not explicitly consider the ‘operational’ nature of a PR in the classification scheme to avoid creating overlaps, as a PR with operational consequences could either be classified as ‘Significant’ or ‘Functional’. Creating an ‘Operational’ sub-classification within the classification ‘Significant’ or ‘Functional’ is nevertheless an option available to stakeholders to create a specific emphasis on operational issues within the proposed classification scheme.
4.2.4 Type ‘Process’ – this may map to type 3A, however, not in cases where the process non-compliance or deficiency could result in either not detecting a failure or creating a failure. An important clarification in AC 20-189 is the removal of the ambiguous notion of ‘significant deviation from the plans or standards’ used in the definition of ‘type 3A’. The ‘Process’ classification in AC 20-189 should be used for PRs that record a process non-compliance or deficiency, provided they cannot result in a potential safety or potential functional effect. An example of an OPR that should not be classified as a ‘Process’ PR is one related to a requirement that was not completely verified due to a process deficiency, because the potential safety or functional impact remains undetermined. Considering the highest priority classification would, in such a case, lead to a ‘Significant’ or ‘Functional’ classification, thus putting even more emphasis on the need to resolve the shortcoming in the verification activities.
4.2.5 Type ‘Life Cycle Data’ – this typically maps to ‘type 2’ or ‘type 3B’. Since ‘Life Cycle Data’ OPRs may range widely, sub-classifications may be proposed by stakeholders to distinguish the different types of OPRs. Examples of OPRs classified as ‘Life Cycle Data’ may range from issues in a component having no potential safety or functional impact to PRs on pure documentary issues.
Moreover, the removal of the notion of ‘non-significant deviation from the plans or standards’ from the definition of ‘type 3B’ helps to remove ambiguity and overlap between the ‘Process’ and ‘Life Cycle Data’ classifications.
09/1 6 /2022 AC 00-71 4.2.6 Other OPR classification – additional classifications of OPRs may be created to cover ‘type 4’ or any other classification not specified in AC 20-189, paragraph 6.1.1.
4.3 Additional Information Related to the ‘Significant’ Classification.
4.3.1 In the frame of an engine or propeller TC/STC or of a TSO article authorization, the definition of ‘Significant’ is based on the anticipation of a potential effect on the product, system, or equipment function that could lead to a Catastrophic, Hazardous, or Major failure condition. The goal is to identify and enhance the visibility of OPRs that may pose potential safety risks at the aircraft installation level (refer to AC 20-189 paragraph 6.1.4).
4.3.2 For example, in the case of an engine TC, a partial or complete loss of thrust or power is regarded as a Minor Engine Effect, whereas it may have a more severe effect at the aircraft level. Unless the engine manufacturer can confirm that the effect at the installation level is no more than Minor, the OPR would be classified as ‘Significant’. The associated assumptions or mitigations are usually recorded through instructions for installing and operating the engine, e.g., in an engine installation manual.
4.3.3 In the case of a TSO authorization, classification of the failure condition is either based on assumptions defined by the applicant, or mandated through the TSO standard, and is the basis of the safety analysis at the TSO article level. An OPR is classified as ‘Significant’ when the OPR may lead to a functional failure associated with a Catastrophic, Hazardous, or Major failure condition.
5. RELATED PUBLICATIONS 5.1 Title 14 CFR Applicable Sections. 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).
5.2 FAA ACs. ( Refer to current version) • AC 20-115, Airborne Software Development Assurance Using EUROCAE ED-12( ) and RTCA DO-178( ).
• AC 20-152, Development Assurance for Airborne Electronic Hardware (AEH) .
• AC 20-170, Integrated Modular Avionics Development, Verification, Integration and Approval using RTCA DO-297 and Technical Standard Order C-153 .
• AC 20-171, Alternatives to RTCA/DO-178B for Software in Airborne Systems and Equipment.
• AC 20-174, Development of Civil Aircraft and Systems.
09/1 6 /2022 AC 00-71 • AC 21-46, Technical Standard Order Program.
• AC 21-50, Installation of TSOA Articles and LODA Appliances.
• AC 23.2010-1, FAA Accepted Means of Compliance process for 14 CFR Part 23 .
• AC 23.1309-1, System Safety Analysis and Assessment for Part 23 Airplanes.
• AC 25 .1309-1, System Design and Analysis.
• AC 27-1309 , Equipment, Systems, and Installations, (included in AC 27-1, Certification of Normal Category Rotorcraft ) .
• AC 29-1309, Equipment, Systems, and Installations, (included in AC 29-2, Certification of Transport Category Rotorcraft ) .
• AC 33.28-1, Compliance Criteria for 14 CFR § 33.28, Aircraft Engines, Electrical and Electronic Engine Control Systems.
• AC 33.28-2, Guidance Material for 14 CFR 33.28, Reciprocating Engines, Electrical and Electronic Engine Control Systems .
• AC33.28-3, Guidance Material For 14 CFR § 33.28, Engine Control Systems.
• AC 35.23-1, Guidance Material for 14 CFR 35.23, Propeller Control Systems .
5.3 EASA Acceptable Means of Compliance (AMC) (Refer to the current version) • AMC 20-115, Airborne Software Development Assurance Using EUROCAE ED-12 and RTCA DO-178 .
• AMC 20-152, Development Assurance for Airborne Electronic Hardware (AEH) .
5.4 Industry Documents • SAE International Aerospace Recommended Practice (ARP) 4754A , Guidelines for Development of Civil Aircraft and Systems , dated December 21, 2010.
• RTCA DO-178 , Software Considerations in Airborne Systems and Equipment Certification, dated January 1982 (no longer in print).
• RTCA DO-178A, Software Considerations in Airborne Systems and Equipment Certification, dated March 1985 (no longer in print).
• RTCA DO-178B , Software Considerations in Airborne Systems and Equipment Certification, dated December 1, 1992.
09/1 6 /2022 AC 00-71 • RTCA DO-178C, Software Considerations in Airborne Systems and Equipment Certification, dated December 13, 2011.
• RTCA DO-248C , Supporting Information for DO-178C and DO-278A, dated December 13, 2011.
• RTCA DO-254, Design Assurance Guidance for Airborne Electronic Hardware , dated April 19, 2000.
• RTCA DO-297 , Integrated Modular Avionics (IMA) Development Guidance and Certification Considerations, dated November 8, 2005.
• RTCA DO-330 , Software Tool Qualification Considerations, dated December 13, 2011.
• RTCA DO-331, Model-Based Development and Verification Supplement to DO-178C and DO-278A, dated December 13, 2011.
• RTCA DO-332, Object-Oriented Technology and Related Techniques Supplement to DO-178C and DO-278A, dated December 13, 2011.
• RTCA DO-333, Formal Methods Supplement to DO-178C and DO-278A, dated December 13, 2011.
• EUROCAE ED-12, Software Considerations in Airborne Systems and Equipment Certification, dated May 1982 (no longer in print).
• EUROCAE ED-12A , Software Considerations in Airborne Systems and Equipment Certification, dated October 1985 (no longer in print).
• EUROCAE ED-12B , Software Considerations in Airborne Systems and Equipment Certification, dated December 1992.
• EUROCAE ED-12C , Software Considerations in Airborne Systems and Equipment Certification, dated January 2012.
• EUROCAE ED-80, Design Assurance Guidance for Airborne Electronic Hardware , dated April 2000.
• EUROCAE ED-94C, Supporting Information for ED-12C and ED-109A, dated January 2012.
• EUROCAE ED-215 , Software Tool Qualification Considerations, dated January 2012.
• EUROCAE ED-216 , Formal Methods Supplement to ED-12C and ED-109A, dated January 2012.
09/1 6 /2022 AC 00-71 • EUROCAE ED-217 , Object-Oriented Technology and Related Techniques Supplement to ED-12C and ED-109A, dated January 2012 • EUROCAE ED-218 , Model-Based Development and Verification Supplement to ED- 12C and ED-109A, dated January 2012.
6. WHERE TO FIND THIS AC.
6.1 You may find this AC at http://www.faa.gov/regulations_policies/advisory_circulars / .
6.2 If you have suggestions for improvement or changes, you may use the template at the end of this AC.
Digitally signed by VICTOR W WICKLUND Date: 2022.09.16 11:15:02 -07'00' Victor Wicklund Aviation Safety Acting Director, Policy and Innovation Division Aircraft Certification Service AC 00-71 09/16/2022 OMB Control Number: 2120-0746 Expiration Date: 11 /3 0 /202 4 Advisory Circular Feedback Form Paperwork Reduction Act Burden Statement: A federal agency may not conduct or sponsor, and a person is not required to respond to, nor shall a person be subject to a penalty for failure to comply with a collection of information subject to the requirements of the Paperwork Reduction Act unless that collection of information displays a currently valid OMB Control Number. The OMB Control Number for this information collection is 2120-0746. Public reporting for this collection of information is estimated to be approximately 20 minutes per response, including the time for reviewing instructions, searching existing data sources, gathering and maintaining the data needed, completing and reviewing the collection of information.
All responses to this collection of information are voluntary FAA Order 1320.46D Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this burden to: Information Collection Clearance Officer, Barbara Hall, 800 Independence Ave, Washington, D.C. 20590.
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: Date: Please mark all appropriate line items: □ An error (procedural or typographical) has been noted in paragraph on page .
□ Recommend paragraph on page be changed as follows: □ In a future change to this AC, please cover the following subject: (B riefly describe what you want added.)
□ Other comments: □ I would like to discuss the above. Please contact me.
Submitted b y: Date: FAA Form 1320-73 ( 09/22) SUPERSEDES PREVIOUS EDITIONS