Compare and highlight differences

Compare / EASA/ Incorporated Amendments/ Compare & Highlight Differences

AMC 20-189 The Management of Open Problem Reports (OPRs)

Available versions for ERULES-1963177438-17862

ED Decision 2020/010/R found in: AMC-20 Amdt 21 - Airworthiness of Products, Parts and Appliances (Apr 2021)

Select original version

Select changed version

Removed: 0 Added: 0

AMC 20-189 The Management of Open Problem Reports (OPRs)

ED Decision 2020/010/R

1.         PURPOSE

This AMC describes an acceptable means, but
not the only means, for showing compliance with the applicable airworthiness
regulations for the management of open problem reports (OPRs) in ETSO
authorisations and type certification, for the system, software and airborne
electronic hardware (AEH) domains. Compliance with this AMC is not mandatory,
and an applicant may elect to use an alternative means of compliance. However,
the alternative means of compliance must meet the relevant requirements,
ensure an equivalent level of safety, and be approved by EASA on a product or
ETSO article basis.

2.         APPLICABILITY

This AMC may be used by applicants, design
approval holders, and developers of airborne systems and equipment to be
installed on type-certified aircraft, engines, and propellers. This AMC
applies to all airborne electronic systems and equipment, including to the
software and AEH components contained in those systems, which 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 open problem reports (OPRs) and to help ensure
safe products at the time of approval. However, the existing guidance on PR
and OPR management is inconsistent and incomplete across domains. Therefore,
this AMC provides consistent guidance across these domains for PR management,
OPR management, stakeholder responsibilities, reporting, and other aspects of
OPR management. This AMC complements but does not alleviate the
project-applicable system, software and AEH guidance.

3.2.     The
technical content of this AMC has been jointly developed with the Federal
Aviation Administration (FAA), in order to harmonise as far as practicable.

4.         DEFINITIONS

4.1.     Terms defined in this AMC

Approval: the term ‘approval’ in this document addresses the approval by
EASA of a product or of changes to a product, or authorisation of an ETSO
article or of changes to an ETSO article.

Article: refer to Article 1(2)(f) of Regulation (EU) No 748/2012 (‘EASA
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.

Error: a mistake in the 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 that has 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
behaviour, process non-compliance with development assurance plans and
standards, and deficiencies in life-cycle data (adapted from DO-178C/ED-12C).

Product: refer to Article 3(3) of Regulation (EU) 2018/1139 (the ‘EASA
Basic Regulation’).

System: a combination of interrelated equipment, article(s), and/or items
arranged to perform a specific function (or functions) within a product.

4.2.     States of PRs/OPRs

**Recorded:** a problem that has been documented using the problem-reporting
process.

**Classified:** a problem report that has been categorised in accordance with an
established classification scheme.

**Resolved:** a problem report that has been corrected or fully mitigated, for
which the 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 the effective resolution of the problem.

4.3.     Classifications 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.

‘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 the management of OPRs. 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 an ETSO 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 organisation, 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:

6.1       The 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 subclassifications 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 the defined subclassifications) is:

1.         ‘Significant’;

2.         ‘Functional’;

3.         ‘Process’;

4.         ‘Life-cycle
data’;

5.         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 the 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
European technical standard order (ETSO) article authorisation, 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       The assessment of OPRs

Each OPR should be assessed to determine:

1.         any
resulting functional limitations or operational restrictions at the equipment
level (for ETSOs) or at the product level (for other types of approvals);

2.         relationships
that may exist with other OPRs; and

3.         for
a ‘Significant’ or ‘Functional’ OPR, the underlying technical cause of the
problem.

6.3       Disposition: OPRs classified as ‘Significant’ per the classification in Section
6.1, for which no sufficient mitigation or justification exists to
substantiate the acceptability of 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 the
involved stakeholders. The summary report should provide access to the
following information for each OPR:

6.4.1   The
identification of the OPR (for example, the OPR ID);

6.4.2   The
identification of the affected configuration item(s) (for example, the item
part number, component name, artefact name) or of the affected process(es);

6.4.3   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   The
conditions under which the problem occurs;

6.4.6   The OPR
classification and assessment results (per Sections 6.1 and 6.2), including:

1.         for
each OPR, regardless of its classification:

a.         the
classification of the OPR, and

b.        the
relationships that are known to exist with other OPRs;

2.         for
OPRs classified as ‘Significant’:

a.         a
description of any mitigations or justifications used to substantiate the
acceptability of the OPR safety effect (per Section 6.3), and

b.        the
functional limitations and operational restrictions, if any;

3.         for
OPRs classified as ‘Functional’:

a.         a
description of any mitigations or justifications used to reduce the safety
effect to Minor or No Safety Effect, and

b.        the
functional limitations and operational restrictions, if any;

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; and

5.         for
each OPR not classified as ‘Significant’ or ‘Functional’, the justification
that the error cannot have a safety or functional effect.

6.5       ETSO specifics: The ETSO authorisation holder may exclude from the reporting
process (per Section 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 ETSO approval.

7.         STAKEHOLDER RESPONSIBILITIES

The levels of stakeholders include: item,
equipment or ETSO article, system and product. The actual stakeholders for a
specific project depend on the project organisation.

7.1       The
levels of stakeholders include: item, equipment or ETSO article, system and
product. The actual stakeholders for a specific project depend on the project
organisation.

7.2       OPR
management (per Section 6) should be performed, at a minimum, at the ETSO
article level, at the level of each individual system within a product, and at
the product level.

8.         RELATED REGULATORY, ADVISORY AND
INDUSTRY MATERIAL

(a)       Related EASA Certification
Specifications (CSs)

(1)       CS-23, Certification
Specifications and Acceptable Means of Compliance for Normal Category
Aeroplanes

(2)       CS-25, Certification
Specifications and Acceptable Means of Compliance for Large Aeroplanes

(3)       CS-27, Certification
Specifications and Acceptable Means of Compliance for Small Rotorcraft

(4)       CS-29, Certification
Specifications and Acceptable Means of Compliance for Large Rotorcraft

(5)       CS-E, Certification
Specifications and Acceptable Means of Compliance for Engines, and [AMC 20-3A](#_DxCrossRefBm421436786), Certification of Engines Equipped with
Electronic Engine Control Systems

(6)       CS-P, Certification
Specifications for Propellers, and [AMC 20-1](#_DxCrossRefBm421436781), Certification of
Aircraft Propulsion Systems Equipped with Electronic Control Systems

(7)       CS-ETSO, Certification
Specifications for European Technical Standard Orders

(8)       CS-APU, Certification
Specifications for Auxiliary Power Units, and [AMC
20-2A](#_DxCrossRefBm421436782),
Certification of Essential APU Equipped with Electronic Controls

(b)       EASA Acceptable Means of Compliance
(AMC)

(1)       [AMC 20-115( )](#_DxCrossRefBm421436784), Airborne
Software Development Assurance Using EUROCAE ED-12 and RTCA DO-178

(2)       [AMC 20-152( )](#_DxCrossRefBm421436783), Development
Assurance for Airborne Electronic Hardware

Refer to latest version.

(1)       AC
20-115( ), Airborne Software Development Assurance Using
EUROCAE ED-12( ) and RTCA DO-178( )

(2)       AC
20-152( ), Development Assurance for Airborne Electronic
Hardware

(3)       AC
27-1309( ), Equipment, Systems, and Installations
(included in AC 27-1, Certification of Normal Category
Rotorcraft)

(4)       AC
29-1309( ), Equipment, Systems, and Installations (included in AC 29-2,
Certification of Transport Category Rotorcraft)

(d)       Industry Documents

(1)       EUROCAE
ED-12, Software Considerations in Airborne Systems and
Equipment Certification, dated May 1982 (no longer in print)

(2)       EUROCAE
ED-12A, Software Considerations in Airborne Systems and
Equipment Certification, dated October 1985 (no longer in print)

(3)       EUROCAE
ED-12B, Software Considerations in Airborne Systems and
Equipment Certification, dated December 1992

(4)       EUROCAE
ED-12C, Software Considerations in Airborne Systems and
Equipment Certification, dated January 2012

(5)       EUROCAE
ED-79A, Guidelines for Development of Civil Aircraft and
Systems, dated December 2010

(6)       EUROCAE
ED-80, Design Assurance Guidance for Airborne Electronic
Hardware, dated April 2000

(7)       EUROCAE
ED-94C, Supporting Information for ED-12C and ED-109A,
dated January 2012

(8)       EUROCAE
ED-215, Software Tool Qualification Considerations,
dated January 2012

(9)       EUROCAE
ED-216, Formal Methods Supplement to ED-12C and ED-109A,
dated January 2012

(10)     EUROCAE
ED-217, Object-Oriented Technology and Related Techniques
Supplement to ED-12C and ED-109A, dated January 2012

(11)     EUROCAE
ED-218, Model-Based Development and Verification Supplement
to ED-12C and ED-109A, dated January 2012

(12)     RTCA
DO-178, Software Considerations in Airborne Systems and
Equipment Certification, dated January 1982 (no longer in print)

(13)     RTCA
DO-178A, Software Considerations in Airborne Systems and
Equipment Certification, dated March 1985 (no longer in print)

(14)     RTCA
DO-178B, Software Considerations in Airborne Systems and
Equipment Certification, dated 1 December 1992

(15)     RTCA
DO-178C, Software Considerations in Airborne Systems and
Equipment Certification, dated 13 December 2011

(16)     RTCA
DO-248C, Supporting Information for DO-178C and DO-278A,
dated 13 December 2011

(17)     RTCA
DO-254, Design Assurance Guidance for Airborne Electronic
Hardware, dated April 19, 2000

(18)     RTCA
DO-297, Integrated Modular Avionics (IMA) Development
Guidance and Certification Considerations, dated 8 November 2005

(19)     RTCA
DO-330, Software Tool Qualification Considerations,
dated 13 December 2011

(20)     RTCA
DO-331, Model-Based Development and Verification Supplement
to DO-178C and DO-278A, dated 13 December 2011

(21)     RTCA
DO-332, Object-Oriented Technology and Related Techniques
Supplement to DO178C and DO-278A, dated 13 December 2011

(22)     RTCA
DO-333, Formal Methods Supplement to DO-178C and DO-278A,
dated 13 December 2011

(23)     SAE
International Aerospace Recommended Practice (ARP) 4754A, Guidelines
for Development of Civil Aircraft and Systems

9.         AVAILABILITY OF DOCUMENTS

(1)       EASA
Certification Specifications (CSs) and Acceptable Means of Compliance (AMC)
may be downloaded from the EASA website: [www.easa.europa.eu](http://www.easa.europa.eu)

(2)       FAA
Advisory Circulars (ACs) may be downloaded from the FAA website: [www.faa.gov](http://www.faa.gov)

(3)       EUROCAE
documents may be purchased from:

European Organisation for Civil Aviation
Equipment

9-23 rue Paul Lafargue

"Le Triangle" building

93200 Saint-Denis, France

Telephone: +33 1 49 46 19 65

(Email: eurocae@eurocae.net, website: [www.eurocae.net](http://www.eurocae.net))

(4)       RTCA
documents may be purchased from:

RTCA, Inc.1150 18th Street NW, Suite 910,
Washington DC 20036, USA

(Email: info@rtca.org, website:
www.rtca.org)

10.       GUIDANCE MATERIAL

GM 20-189 The Management
of Open Problem Reports

AMC 20-189 The Management of Open Problem Reports (OPRs)

ED
Decision 2020/010/R

1.         PURPOSE

This AMC describes an acceptable means, but not the only
means, for showing compliance with the applicable airworthiness regulations
for the management of open problem reports (OPRs) in ETSO authorisations and
type certification, for the system, software and airborne electronic hardware
(AEH) domains. Compliance with this AMC is not mandatory, and an applicant may
elect to use an alternative means of compliance. However, the alternative
means of compliance must meet the relevant requirements, ensure an equivalent
level of safety, and be approved by EASA on a product or ETSO article basis.

2.         APPLICABILITY

This AMC may be used by applicants, design approval holders,
and developers of airborne systems and equipment to be installed on
type-certified aircraft, engines, and propellers. This AMC applies to all
airborne electronic systems and equipment, including to the software and AEH
components contained in those systems, which 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 open problem reports (OPRs) and
to help ensure safe products at the time of approval. However, the existing
guidance on PR and OPR management is inconsistent and incomplete across
domains. Therefore, this AMC provides consistent guidance across these domains
for PR management, OPR management, stakeholder responsibilities, reporting,
and other aspects of OPR management. This AMC complements but does not
alleviate the project-applicable system, software and AEH guidance.

3.2.     The
technical content of this AMC has been jointly developed with the Federal
Aviation Administration (FAA), in order to harmonise as far as practicable.

4.         DEFINITIONS

4.1.     Terms
defined in this AMC

Approval: the term ‘approval’ in this
document addresses the approval by EASA of a product or of changes to a
product, or authorisation of an ETSO article or of changes to an ETSO article.

Article: refer to Article 1(2)(f) of
Regulation (EU) No 748/2012 (‘EASA 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.

Error: a mistake in the 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
that has 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 behaviour, process
non-compliance with development assurance plans and standards, and
deficiencies in life-cycle data (adapted from DO-178C/ED-12C).

Product: refer to Article 3(3) of
Regulation (EU) 2018/1139 (the ‘EASA Basic Regulation’).

System: a combination of interrelated
equipment, article(s), and/or items arranged to perform a specific function
(or functions) within a product.

4.2.     States
of PRs/OPRs

**Recorded:** a
problem that has been documented using the problem-reporting process.

**Classified:** a
problem report that has been categorised in accordance with an established
classification scheme.

**Resolved:** a
problem report that has been corrected or fully mitigated, for which the
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 the
effective resolution of the problem.

4.3.     Classifications
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.

‘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 the management
of OPRs. 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 an ETSO 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 organisation, 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:

6.1       The
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 subclassifications 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 the
defined subclassifications) is:

1.         ‘Significant’;

2.         ‘Functional’;

3.         ‘Process’;

4.         ‘Life-cycle
data’;

5.         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.2       The
assessment of OPRs

Each OPR should be assessed to determine:

1.         any
resulting functional limitations or operational restrictions at the equipment
level (for ETSOs) or at the product level (for other types of approvals);

2.         relationships
that may exist with other OPRs; and

3.         for a
‘Significant’ or ‘Functional’ OPR, the underlying technical cause of the
problem.

6.3       Disposition:
OPRs classified as ‘Significant’ per the classification in Section 6.1, for
which no sufficient mitigation or justification exists to substantiate the
acceptability of 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 the
involved stakeholders. The summary report should provide access to the
following information for each OPR:

6.4.1   The
identification of the OPR (for example, the OPR ID);

6.4.2   The
identification of the affected configuration item(s) (for example, the item
part number, component name, artefact name) or of the affected process(es);

6.4.3   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   The
conditions under which the problem occurs;

6.4.6   The
OPR classification and assessment results (per Sections 6.1 and 6.2),
including:

1.         for each
OPR, regardless of its classification:

a.         the
classification of the OPR, and

b.        the
relationships that are known to exist with other OPRs;

2.         for OPRs
classified as ‘Significant’:

a.         a
description of any mitigations or justifications used to substantiate the
acceptability of the OPR safety effect (per Section 6.3), and

b.        the
functional limitations and operational restrictions, if any;

3.         for OPRs
classified as ‘Functional’:

a.         a
description of any mitigations or justifications used to reduce the safety
effect to Minor or No Safety Effect, and

b.        the
functional limitations and operational restrictions, if any;

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; and

5.         for each
OPR not classified as ‘Significant’ or ‘Functional’, the justification that
the error cannot have a safety or functional effect.

6.5       ETSO
specifics: The ETSO authorisation holder may exclude from the reporting
process (per Section 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 ETSO approval.

7.         STAKEHOLDER
RESPONSIBILITIES

The levels of stakeholders include: item, equipment or ETSO
article, system and product. The actual stakeholders for a specific project
depend on the project organisation.

7.1       The
levels of stakeholders include: item, equipment or ETSO article, system and
product. The actual stakeholders for a specific project depend on the project
organisation.

7.2       OPR
management (per Section 6) should be performed, at a minimum, at the ETSO
article level, at the level of each individual system within a product, and at
the product level.

8.         RELATED
REGULATORY, ADVISORY AND INDUSTRY MATERIAL

(a)       Related
EASA Certification Specifications (CSs)

(1)       CS-23, Certification
Specifications and Acceptable Means of Compliance for Normal Category
Aeroplanes

(2)       CS-25, Certification
Specifications and Acceptable Means of Compliance for Large Aeroplanes

(3)       CS-27, Certification
Specifications and Acceptable Means of Compliance for Small Rotorcraft

(4)       CS-29, Certification
Specifications and Acceptable Means of Compliance for Large Rotorcraft

(5)       CS-E, Certification
Specifications and Acceptable Means of Compliance for Engines, and [AMC 20-3A](#_DxCrossRefBm1926189219), Certification of Engines Equipped with
Electronic Engine Control Systems

(6)       CS-P, Certification
Specifications for Propellers, and [AMC 20-1](#_DxCrossRefBm1926189217), Certification of
Aircraft Propulsion Systems Equipped with Electronic Control Systems

(7)       CS-ETSO, Certification
Specifications for European Technical Standard Orders

(8)       CS-APU, Certification
Specifications for Auxiliary Power Units, and [AMC 20-2A](#_DxCrossRefBm1926189218), Certification of Essential APU Equipped
with Electronic Controls

(b)       EASA
Acceptable Means of Compliance (AMC)

(1)       [AMC 20-115( )](#_DxCrossRefBm1926189222), Airborne
Software Development Assurance Using EUROCAE ED-12 and RTCA DO-178

(2)       [AMC 20-152( )](#_DxCrossRefBm1926189221), Development
Assurance for Airborne Electronic Hardware

Refer to latest version.

(1)       AC 20-115(
), Airborne Software Development Assurance Using EUROCAE
ED-12( ) and RTCA DO-178( )

(2)       AC 20-152(
), Development Assurance for Airborne Electronic Hardware

(3)       AC 27-1309(
), Equipment, Systems, and Installations (included
in AC 27-1, Certification of Normal Category Rotorcraft)

(4)       AC 29-1309(
), Equipment, Systems, and Installations (included in AC 29-2, Certification
of Transport Category Rotorcraft)

(d)       Industry
Documents