Compare and highlight differences

Compare / EASA/ Incorporated Amendments/ Compare & Highlight Differences

AMC 20-115D Airborne Software Development Assurance Using EUROCAE ED-12 and RTCA DO-178

Available versions for ERULES-1963177438-9015

ED Decision 2017/020/R found in: AMC-20 Amdt 23 - Airworthiness of Products, Parts and Appliances (Jan 2022)

From

Show details Hide details

AMC 20-115D Airborne Software
Development Assurance Using EUROCAE ED-12 and RTCA DO-178

ED Decision 2017/020/R

1.         PURPOSE

a.         This
AMC describes an acceptable means, but not the only means, for showing
compliance with the applicable airworthiness regulations with regard to
the software aspects of airborne systems and equipment in the domain of
product certification or European technical standard orders (ETSOs)
authorisation. Compliance with this AMC is not mandatory and therefore an
applicant may elect to use an alternative means of compliance (AltMoC).
However, the AltMoC must meet the relevant requirements, ensure an equivalent
level of software safety as this AMC, and be approved by the European Aviation
Safety Agency (EASA) on a product or ETSO article basis.

b.         This AMC
recognises the following European Organisation for Civil Aviation Equipment
(EUROCAE) and Radio Technical Commission for Aeronautics (RTCA) documents:

1.         EUROCAE
ED-12C, Software Considerations in Airborne Systems and Equipment
Certification, 1 January 2012, and RTCA DO-178C, Software
Considerations in Airborne Systems and Equipment Certification,
13 December 2011;

2.         EUROCAE
ED-215, Software Tool Qualification Considerations, 1 January 2012, and RTCA
DO-330, Software Tool Qualification Considerations, 13 December 2011;

3.         EUROCAE
ED-216, Formal Methods Supplement to ED-12C and ED-109A,
1 January 2012, and RTCA DO-333, Formal Methods Supplement to
DO-178C and DO-278A, 13 December 2011;

4.         EUROCAE
ED-217, Object-Oriented Technology and Related Techniques Supplement to ED-12C
and ED-109A, 1 January 2012, and RTCA DO-332, Object-Oriented
Technology and Related Techniques Supplement to DO-178C and DO-278A,
13 December 2011; and

5.         EUROCAE
ED-218, Model-Based Development and Verification Supplement to ED-12C and ED‑109A,
1 January 2012, and RTCA DO-331, Model-Based Development and
Verification Supplement to DO-178C and DO-278A, 13 December 2011.

Note: EUROCAE ED is hereinafter referred to as ‘ED’; RTCA DO is
hereinafter referred to as ‘DO’. Where the notation ‘ED-XXX/DO-XXX’ appears in
this document, the referenced documents are recognised as being equivalent.

c.         This
AMC identifies the following as supporting documents:

—
             ED-94C,
Supporting Information for ED-12C and ED-109A, 1 January 2012; and

—
DO-248C, Supporting Information for DO-178C and
DO-278A, 13 December 2011.

ED-94C/DO-248C contains a collection of frequently asked questions
(FAQs) and discussion papers (DPs) compiled and approved by the authors of
ED-12C and DO-178C to provide clarification of the guidance contained in
ED-12C/DO-178C.

d.         References
to the use of ED-12C/DO-178C in this AMC include the use of ED-215/DO-330 and
supplements ED-216/DO-333, ED-217/DO-332 and ED-218/DO-331, as applicable.

e.         This AMC
establishes guidance for using existing ED-12B/DO-178B processes for new
software development.

f.          This
AMC also establishes guidance for transitioning to ED-12C/DO-178C when making
modifications to software previously approved using ED-12/DO-178,
ED-12A/DO-178A, or ED-12B/DO-178B.

2.         APPLICABILITY

This AMC applies to applicants, design approval holders (DAHs), and
developers of airborne systems and equipment containing software to be
installed on type-certified aircraft, engines, and propellers, or to be used
in ETSO articles.

3.         REPLACEMENT

This AMC replaces and cancels AMC 20-115C, Software Considerations in
Airborne Systems and Equipment Certification, 12 September 2013.

4.         BACKGROUND

a.         ED-12C/DO-178C,
Appendix A, Section 3, provides a summary of the differences between ED‑12C/DO‑178C
and ED-12B/DO-178B. The EUROCAE and RTCA Inc. documents listed in
subparagraph 1.b. of this AMC provide guidance for establishing software
life cycle planning, development, verification, configuration management,
quality assurance and certification liaison processes to be used in the
development of software for airborne systems. The guidance provided in these
documents is in the form of:

1.         objectives
for software life cycle processes;

2.         activities
that provide a means for satisfying the objectives; and

3.         descriptions
of the evidence indicating that the objectives have been satisfied.

b.         The
technical content of this AMC is, as far as practicable,
harmonised with Federal Aviation Administration (FAA) AC 20-115D, which is
also based on ED-12C/DO-178C.

5.         USING
ED-12B/DO-178B PROCESSES AND PROCEDURES FOR NEW SOFTWARE DEVELOPMENT

a.         Applicants
who have established software development assurance processes using
ED-12B/DO-178B may continue to use those processes (including tool
qualification processes) for new software development and certification
projects, provided that the following criteria are met:

1.         The
software development assurance processes are shown to have no known process
deficiencies, such as those discovered during internal or external audits or
reviews, or identified in open problem reports (OPRs), resulting in
non-satisfaction of one or more ED-12B/DO-178B objectives. Evidence of
resolution and closure of all process-related OPRs and of all process‑related
audit or review findings may be requested.

2.         The
processes were previously used to develop software that was used in a
certified product at a software level at least as high as the software level
of the software to be developed.

3.         If
model-based development (MBD), object-oriented technology (OOT), or formal
methods (FMs) are to be used, existing processes incorporating these methods
should have been evaluated and found to be acceptable by EASA on a previous
certified project. These processes should have been developed in accordance
with EASA guidance specific to the technique, such as that contained in an
associated certification review item (CRI) or a published certification memorandum
(CM).

4.         If
configuration data is used, as defined in ED-12C/DO-178C under ‘Parameter data
item’, existing processes for such data should have been evaluated and found
to be acceptable by EASA on a previous certified project. In the absence of
processes for using configuration data, the applicant should establish new
processes for using PDIs in accordance with ED-12C/DO-178C.

5.         There
are no significant changes to the software processes described in the plans or
to the software development environment. This should be supported through
analysis of the changes to the previously accepted software development
processes and environment.

6.         The
applicant does not intend to declare the proposed software as having satisfied
ED‑12C/DO‑178C.

b.         If
the criteria of subparagraph 5.a. are not met, the applicant should upgrade
their processes and develop the new software using ED-12C/DO-178C; tool
qualification processes should be addressed in accordance with Section 12.2 of
ED-12C/DO-178C and paragraph 10(c) of this AMC.

c.         Applicants
or developers should establish new software life cycle processes in accordance
with ED-12C/DO-178C.

6.         USING
EUROCAE ED-12C AND RTCA DO-178C

ED-12C/DO-178C is an acceptable means of compliance (AMC) with regard
to the software aspects of product certification or ETSOs authorisation. When
using ED-12C/DO-178C, the following should apply:

a.         The
applicant should satisfy all of the objectives associated with the software
level assigned to the software, and develop all of the associated life cycle
data to demonstrate compliance with the applicable objectives, as listed in
the Annex A tables of ED-12C/DO-178C and, where applicable, of ED-215/DO-330,
ED-216/DO-333, ED-217/DO-332, and ED-218/DO-331. The applicant should plan and
execute activities that satisfy each objective.

b.         The
applicant should submit to EASA the life cycle data specified in Section 9.3
of ED-12C/DO-178C, and Section 9.0 a. of ED-215/DO-330, as applicable to tool
qualification. It is the applicant’s responsibility to perform the planned
activities and produce the life cycle data necessary to satisfy all the
applicable objectives.

c.         Section
9.4 of ED-12C/DO-178C specifies the software life cycle data related to the
type design of the certified product. However, not all of the specified data
applies to all software levels; specifically the design description and the
source code are not part of the type design data for Level D software.

d.         The
applicant should make available to EASA, upon request, any of the data
described in Section 11 of ED-12C/DO-178C, applicable tool qualification
data, data outputs from any applicable supplements, and any other data needed
to substantiate the satisfaction of all the applicable objectives.

e.         EASA
may publish an AMC to specific certification specifications (CSs), stating the
required relationship between the criticality of the software-based systems
and the software levels, as defined in ED-12C/DO-178C. Such AMC takes
precedence over the application of Section 2.3 of ED-12C/DO-178C.

7.         RESERVED

8.         GUIDANCE
APPLICABLE TO ED-12B/DO-178B OR ED-12C/DO-178C

a.         The use
of supplements with ED-12C/DO-178C

The applicant should apply the guidance of supplements to ED-216/DO-333,
ED-217/DO-332 and ED-218/DO-331 when incorporating the addressed software
development techniques. If the applicant intends to use multiple software
development techniques together, more than one supplement applies. The
applicant should not use supplements as stand-alone documents.

1.         When
using one or more supplements, the applicant’s plan for software aspects of
certification (PSAC) should describe:

a.         how
the applicant applies ED-12C/DO-178C and the supplement(s) together; and

b.         how
the applicant addresses the applicable ED-12C/DO-178C objectives and those
added or modified by the supplement(s): which objectives from which documents
apply to which software components, and how the applicant’s planned activities
satisfy all the applicable objectives.

2.         If
the applicant intends to use any techniques addressed by the supplements to
develop a qualified tool (for tool qualification levels (TQLs) 1, 2, 3, and 4
only), then the tool qualification plan (TQP) should describe:

a.         based
on supplement analysis, which tool qualification objectives are affected by
the use of the technique(s); and

b.         how
the planned activities satisfy the added or modified objectives.

3.         The
intent of this subparagraph is to provide clarification of Section MB.6.8.1 of
ED-218/DO-331. If the applicant uses models as defined in Section MB.1.0 of
ED-218/DO-331 as the basis for developing software, the applicant should apply
the guidance of ED-218/DO-331. When applying Section MB.6.8.1 of
ED-218/DO-331, the applicant should do the following:

a.         identify
which review and analysis objectives are planned to be satisfied by simulation
alone or in combination with reviews and analyses; all other objectives should
be satisfied by reviews and analyses, as described in Section MB.6.3 of
ED-218/DO-331; and

b.         for
each identified objective, justify in detail how the simulation activity,
alone or in combination with reviews and analyses, fully satisfies the
specific review and analysis objective.

b.         Guidance
on field-loadable software (FLS)

This Section supplements ED-12C/DO-178C and ED-12B/DO-178B. The
applicant should use this guidance in addition to ED-12C/DO-178C and
ED-12B/DO-178B when using FLS in their project.

1.         As the
developer, the applicant should provide the necessary information to support
the system‑level guidance identified in items a, b, c and d of ED-12C/DO-178C,
Section 2.5.5, and items a, b, c and d of ED-12B/DO-178B, Section 2.5.

2.         The
FLS should be protected against corruption or partial loading at an integrity
level appropriate for the FLS software level.

3.         The
FLS part number, when loaded in the airborne equipment, should be verifiable
by appropriate means.

4.         Protection
mechanisms should be implemented to prevent inadvertent enabling of the field-loading
function during cruising or any other safety-critical phase.

c.         Guidance
on user-modifiable software (UMS)

This Section supplements ED-12C/DO-178C and ED-12B/DO-178B. The
applicant should use this guidance in addition to ED-12C/DO-178C and
ED-12B/DO-178B when using UMS in their project.

1.         As
the developer, the applicant should provide the necessary information to
support the system‑level guidance identified in items a, b, c and f of
ED-12C/DO-178C, Section 2.5.2, and items a and b of ED‑12B/DO-178B, Section
2.4.

2.         The
modifiable part of the software should be developed at a software level at
least as high as the software level assigned to that software.

9.         MODIFYING
AND REUSING SOFTWARE APPROVED USING ED-12/DO-178, ED-12A/DO-178A, OR
ED-12B/DO-178B

a.         EASA
previously approved the software for many airborne systems using ED-12/DO-178,

ED-12A/DO-178A, or ED-12B/DO-178B as a means of compliance. In this AMC,
reference to legacy software includes the previously approved software or
component(s) that makes up the software used in legacy systems. In this
subparagraph, it is described how to demonstrate compliance with the software
aspects of certification for an application that includes modifications to
legacy software or the use of unmodified legacy software.

b.         Figure
1 presents a flow chart for using legacy software. The applicant should use
the flow chart while following the procedures in this subparagraph if the
applicant modifies or reuses legacy software. Although these procedures apply
to the majority of projects, the applicant should coordinate with EASA any
cases that do not follow this flow.

Figure
1 — Legacy software process flow chart

![Aviation.Bot AI suggestion, not from EASA source: The image displays a flowchart titled "Legacy software process flow chart" that outlines the steps and decision points for assessing, modifying, or reusing software previously approved under ED-12, ED-12A, or ED-12B standards for new aviation projects.

Detailed Description: The image presents a vertical flowchart with a white background, composed of various interconnected shapes and text, along with a legend box. The title "Figure 1 — Legacy software process flow chart" is centered above the flowchart.

The flowchart begins at the top with a rounded rectangular start node containing the text: "Intent to use software previously shown to satisfy ED-12, ED-12A, or ED-12B."

From this start node, a solid black arrow points downwards to a rectangular process node labeled: "Evaluate software usage history, SDs, ADs, OPRs, etc. See 9(b)(1)."

Following this, a solid black arrow leads to a diamond-shaped decision node asking: "Is the software usage history acceptable? See 9(b)(1)."
*   If the answer is "No," a solid black arrow points right to a rectangular process node: "Correct process deficiencies and document plan for resolving related software deficiencies. See 9(b)(1)." From this node, a solid black arrow points upwards and then right, merging into a later part of the flow at the "Conduct a CIA" node.
*   If the answer is "Yes," a solid black arrow points downwards to another diamond-shaped decision node: "Is the software developed using ED-12B? See 9(b)(2)."

From the "Is the software developed using ED-12B?" decision node:
*   If the answer is "Yes," a solid black arrow points downwards to a diamond-shaped decision node: "Is the ED-12B software level acceptable? See 9(b)(2)."
    *   If the answer is "Yes," a solid black arrow points downwards to a diamond-shaped decision node: "Is the legacy system software to be modified? See 9(b)(3)."
    *   If the answer is "No," a solid black arrow points downwards to a rectangular process node: "Upgrade software baseline including all processes & procedures using ED-12B or use ED-12C and ED-215. See 9(b)(2)(c)." From this node, a solid black arrow points downwards, merging into the "Is the legacy system software to be modified?" decision node.
*   If the answer is "No," a solid black arrow points right to a diamond-shaped decision node: "Is the ED-12 or ED-12A software level acceptable? See 9(b)(2)."
    *   If the answer is "Yes," a solid black arrow points downwards and then left, merging into the "Is the legacy system software to be modified?" decision node.
    *   If the answer is "No," a solid black arrow points downwards to a rectangular process node: "Upgrade software baseline including all processes & procedures using ED-12C and ED-215. See 9(b)(2)(a) or (b)." From this node, a solid black arrow points downwards and then left, merging into the "Is the legacy system software to be modified?" decision node.

From the "Is the legacy system software to be modified?" decision node:
*   If the answer is "No," a solid black arrow points downwards to a rounded rectangular end node: "Original approval basis or baseline upgrade to ED-12C acceptable as approval basis. See 9(b)(3)(a) or (b)."
*   If the answer is "Yes," a solid black arrow points right to a rectangular process node: "Conduct a CIA. See 9(b)(4)." This node also serves as the merge point for the path originating from "Correct process deficiencies."

From the "Conduct a CIA" node, a solid black arrow points downwards to a diamond-shaped decision node: "Will there be new software tools or changes to tools? See 9(b)(5)."
*   If the answer is "Yes," a solid black arrow points right to a rectangular process node: "Determine tool qualification requirements. See Section 10." From this node, a solid black arrow points downwards, merging into the "Did you upgrade the software baseline to ED-12C IAW paragraph 9(b)(2)(a), (b), or (c)?" decision node.
*   If the answer is "No," a solid black arrow points downwards to the "Did you upgrade the software baseline to ED-12C IAW paragraph 9(b)(2)(a), (b), or (c)?" decision node.

From the "Did you upgrade the software baseline to ED-12C IAW paragraph 9(b)(2)(a), (b), or (c)?" decision node:
*   If the answer is "Yes," a solid black arrow points downwards and then right, merging into the "Have the software plans and environment been properly maintained?" decision node.
*   If the answer is "No," a solid black arrow points downwards to a diamond-shaped decision node: "If MBD, OOT, or FMS will be used, do processes support the technique IAW applicable guidance? See 9(b)(7)(a)."
    *   If the answer is "Yes," a solid black arrow points downwards to the "Have the software plans and environment been properly maintained?" decision node.
    *   If the answer is "No," a solid black arrow points right to a rounded rectangular end node: "Change software and associated life cycle data using ED-12C, Section 12.1, and applicable supplements. See 9(b)(6) & (9)."

From the "Have the software plans and environment been properly maintained?" decision node:
*   If the answer is "Yes," a solid black arrow points downwards to a diamond-shaped decision node: "Do you want to declare equivalence to ED-12C? See 9(b)(7)(c)."
    *   If the answer is "Yes," a solid black arrow points right to a rectangular process node: "Upgrade software baseline including all processes & procedures using ED-12C and ED-215. See 9(b)(9)." From this node, a solid black arrow points downwards and then left, merging into the "Change software and associated life cycle data using ED-12C, Section 12.1, and applicable supplements." end node.
    *   If the answer is "No," a solid black arrow points downwards to a rounded rectangular end node: "Change software and associated life cycle data using the same ED-12 version as the original approval. For configuration data/PDI, use an approved process or establish new process using ED-12C. See 9(b)(8)(a) & (b)."
*   If the answer is "No," a solid black arrow points right to the "Change software and associated life cycle data using ED-12C, Section 12.1, and applicable supplements." end node.

The flowchart concludes with three distinct rounded rectangular end nodes, representing different outcomes or final actions:
1.  "Original approval basis or baseline upgrade to ED-12C acceptable as approval basis. See 9(b)(3)(a) or (b)."
2.  "Change software and associated life cycle data using the same ED-12 version as the original approval. For configuration data/PDI, use an approved process or establish new process using ED-12C. See 9(b)(8)(a) & (b)."
3.  "Change software and associated life cycle data using ED-12C, Section 12.1, and applicable supplements. See 9(b)(6) & (9)."

In the bottom left corner of the image, there is a rectangular box titled "Acronyms" which lists definitions for abbreviations used in the flowchart:
*   "ADs — airworthiness directives"
*   "CIA — change impact analysis"
*   "FMS — formal methods"
*   "IAW — in accordance with"
*   "MBD — model-based development"
*   "OOT — object-oriented technology"
*   "OPRs — open problem reports"
*   "PDI — parameter data item"
*   "SDs — service difficulties"

Contextual Linkage: The flowchart visually represents a decision-making process for handling legacy software in aviation projects. Each step and decision point in the flowchart explicitly refers to a specific paragraph within section 9(b) of the accompanying text (e.g., "See 9(b)(1)", "See 9(b)(2)", etc.), indicating that the visual flow is a direct graphical representation of the procedural guidance provided in the text. The process starts with evaluating the software's history and development standard (ED-12, ED-12A, or ED-12B), proceeds through checks for software level acceptability, potential modifications, tool usage, baseline upgrades, and maintenance of plans and environment, ultimately leading to different outcomes regarding approval basis or required changes to software and life cycle data. The acronyms box provides definitions for technical terms used throughout the flowchart, ensuring clarity for aviation professionals.](file_tNNDI2wQkpg/image050.jpg)

1.         The
applicant should assess the legacy software to be modified or reused for its
usage history from previous installations. If the software has safety-related
service difficulties, airworthiness directives, or OPRs with a potential
safety impact on the proposed installation, the applicant should establish plans
to resolve all related software deficiencies. Prior to modifying or reusing
the legacy software, the applicant should correct any related development
process deficiencies, such as those discovered during internal or external
audits or reviews, or identified in OPRs resulting in non-satisfaction of one
or more ED-12B/DO-178B objectives. Evidence of resolution and closure of all
process-related OPRs and of all process-related audit or review findings may
be requested.

2.         The
system safety process assigns the minimum development assurance level based on
the severity classifications of failure conditions for a given function. The
ED-12B/DO-178B software levels are consistent with the ED-12C/DO-178C software
levels. However, ED-12/DO-178 and ED‑12A/DO-178A were published prior to the
establishment of the software levels addressed in ED‑12B/DO-178B and ED‑12C/DO‑178C.
The applicant should use Table 1 to determine whether their legacy software
level satisfies the software level assigned by the system safety process for
the proposed installation. A ‘ü’ in the
intersection of the row and column indicates that the legacy software level is
acceptable. For example, legacy software with development assurance for ED‑12A/DO‑178A
software Level 2 can be considered to satisfy software Levels B, C, and D. A
blank indicates that the software level is not acceptable. Therefore, the
ED-12A/DO-178A software developed for software Level 2 would not be acceptable
where software Level A is required.

Table 1 —
Software level relationships

<table border="1" cellpadding="0" cellspacing="0" width="603">
<thead>
<tr>
<td rowspan="2" valign="top" width="65">
Assigned software level
</td>
<td colspan="4" valign="top" width="164">
Legacy software level
 per ED-12B
</td>
<td colspan="3" valign="top" width="158">
Legacy software level
 per ED-12A
</td>
<td colspan="3" valign="top" width="217">
Legacy software Level 
 per ED-12
</td>
</tr>
<tr>
<td valign="top" width="41">
A
</td>
<td valign="top" width="41">
B
</td>
<td valign="top" width="41">
C
</td>
<td valign="top" width="41">
D
</td>
<td valign="top" width="53">
1
</td>
<td valign="top" width="53">
2
</td>
<td valign="top" width="53">
3
</td>
<td valign="top" width="61">
Critical
</td>
<td valign="top" width="64">
Essential
</td>
<td valign="top" width="91">
Non-Essential
</td>
</tr>
</thead>
<tr>
<td valign="top" width="65">
A
</td>
<td width="41">
ü
</td>
<td width="41">
</td>
<td width="41">
</td>
<td width="41">
</td>
<td width="53">
ü
</td>
<td width="53">
</td>
<td width="53">
</td>
<td width="61">
ü
</td>
<td width="64">
</td>
<td valign="top" width="91">
</td>
</tr>
<tr>
<td valign="top" width="65">
B
</td>
<td width="41">
ü
</td>
<td width="41">
ü
</td>
<td width="41">
</td>
<td width="41">
</td>
<td width="53">
ü
</td>
<td width="53">
ü
</td>
<td width="53">
</td>
<td width="61">
ü
</td>
<td width="64">
</td>
<td valign="top" width="91">
</td>
</tr>
<tr>
<td valign="top" width="65">
C
</td>
<td width="41">
ü
</td>
<td width="41">
ü
</td>
<td width="41">
ü
</td>
<td width="41">
</td>
<td width="53">
ü
</td>
<td width="53">
ü
</td>
<td width="53">
</td>
<td width="61">
ü
</td>
<td width="64">
ü
</td>
<td valign="top" width="91">
</td>
</tr>
<tr>
<td valign="top" width="65">
D
</td>
<td width="41">
ü
</td>
<td width="41">
ü
</td>
<td width="41">
ü
</td>
<td width="41">
ü
</td>
<td width="53">
ü
</td>
<td width="53">
ü
</td>
<td width="53">
</td>
<td width="61">
ü
</td>
<td width="64">
ü
</td>
<td valign="top" width="91">
</td>
</tr>
</table>

a.         If
the legacy software was developed at software level ‘Essential’ using
ED-12/DO-178 and was previously accepted by the certification authority as
acceptable for software Level B, it remains acceptable for the new project. If
the ED-12/DO-178 legacy software was not previously assessed, or the software
level is not acceptable, then the applicant should upgrade the software
development baseline, including all processes and procedures (as well as tool
qualification processes), using Section 12.1.4 of ED-12C/DO-178C, and ED‑215/DO-330.

b.         If
the legacy software was developed using ED-12A/DO-178A, and the software level
is not acceptable, the applicant should upgrade the software development
baseline, including all processes and procedures (as well as tool
qualification processes), using Section 12.1.4 of ED-12C/DO-178C, and
ED-215/DO-330.

c.         If
the legacy software was developed using ED-12B/DO-178B, and the software level
is not acceptable, the applicant should upgrade the software development
baseline, including all processes and procedures (as well as tool
qualification processes), using Section 12.1.4 of ED-12B/DO‑178B or ED-12C/DO-178C, and ED-215/DO-330.

3.         If
the criteria of 9(b)(1) and 9(b)(2) are satisfied and modifications to the
software are not required, then:

a.         the
original approval may serve as the basis for the software in the installation
approval of the proposed system; and

b.         if
the applicant upgraded the software development baseline using ED-12C/DO-178C
and updated all processes and procedures, as well as tool qualification
processes, to ED‑12C/DO-178C and ED‑215/DO-330, then the applicant may declare
their software as equivalent to satisfying ED-12C/DO-178C; however, the
applicant cannot declare their unmodified tools as equivalent to satisfying
ED-12C/DO-178C and ED-215/DO-330. The applicant should make all subsequent
modifications to all their software and tools using their processes and
procedures that satisfy ED-12C/DO-178C and ED-215/DO-330.

4.         If
modifications to the software are required, the applicant should conduct a
software change impact analysis (CIA) to determine the extent of the
modifications, the impact of those modifications, and what verification is
required to ensure that the modified software performs its intended function
and continues to satisfy the identified means of compliance. The applicant
should:

a.         identify
the software changes to be incorporated and conduct a CIA consisting of one or
more analyses associated with the software change, as identified in
ED-12C/DO-178C, Section 12.1;

b.         conduct
the verification, as indicated by the CIA; and

c.         summarise
the results of the CIA in the plan for software aspects of certification
(PSAC) or in the software accomplishment summary (SAS).

5.         If
new software tools or modifications to tools are needed, please refer to
paragraph 10 of this AMC to determine the tool qualification requirements.

6.         If
the applicant upgraded the software baseline to ED-12C/DO-178C in accordance
with subparagraph 9(b)(2), they should make all modifications to the software
using ED-12C/DO-178C, Section 12.1. If the applicant wants to declare their
software as equivalent to satisfying ED‑12C/DO-178C, the applicant’s
equivalence declaration applies to both modified and unmodified software and
is valid even if the applicant uses unmodified tools that have not been
qualified using ED-12C/DO-178C. However, the applicant cannot declare their unmodified
tools as equivalent to satisfying ED-12C/DO-178C and ED-215/DO-330. All
subsequent modifications to all their software and tools are to be made using
processes and procedures satisfying ED‑12C/DO‑178C and ED-215/DO-330.

7.         If
the applicant wants to use their existing processes to make modifications to
their legacy software using the version of ED-12/DO-178 (i.e. ED-12/DO-178,
ED-12A/DO-178A, or ED‑12B/DO-178B) used for the original software approval,
the applicant may do so, provided that all of the following conditions are
met:

a.         If
MBD, OOT, or FMs are to be used, existing processes incorporating these
methods should have been evaluated and found to be acceptable by EASA on a
previous certified project. These processes should have been developed in
accordance with EASA guidance specific to the technique, such as that
contained in an associated CRI or a published CM.

b.         The
applicant has maintained, and can still use, the software plans, processes,
and life cycle environment, including improvements to processes or to the life
cycle environment as captured in revised plans.

c.         The
applicant does not intend to declare the proposed software as satisfying ED‑12C/DO‑178C.

8.         If
the conditions of subparagraph 9(b)(7) are satisfied:

a.         the
applicant may accomplish all modifications to the software using the same ED‑12/DO‑178
version as for the original approval. However, the applicant may not declare
their software as equivalent to satisfying ED-12C/DO-178C; and

b.         if
configuration data is used, as defined under ‘Parameter data item’ in ED‑12C/DO‑178C,
the applicant may use existing processes for such data if the processes were
evaluated and found to be acceptable by EASA on a previous certified project;
in the absence of processes for using configuration data, the applicant should
establish new processes for using parameter data items (PDIs) in accordance
with ED-12C/DO-178C.

9.         If
any of the conditions of subparagraph 9(b)(7) is not satisfied, the applicant
should update all their processes and procedures, as well as tool
qualification processes, using ED-12C/DO-178C and ED‑215/DO‑330, and make all
modifications to the software using ED-12C/DO-178C, Section 12.1. If the
applicant wants to declare their software as equivalent to satisfying ED‑12C/DO‑178C,
their declaration applies to both the modified and unmodified software and is
valid even if the applicant uses unmodified tools that have not been qualified
using ED‑12C/DO‑178C and ED-215/DO-330. However, the applicant cannot declare
their unmodified tools as equivalent to satisfying ED-12C/DO-178C and
ED-215/DO-330. The applicant should make all subsequent modifications to all
their software and tools using their processes and procedures that satisfy
ED-12C/DO-178C and ED-215/DO-330.

10.       TOOL
QUALIFICATION

Sections 12.2 of ED-12C/DO-178C and ED-215/DO-330 provide an acceptable
method for tool qualification. ED-215/DO-330 contains its own complete set of
objectives, activities, and life cycle data for tool qualification.

a.         If
the applicant’s legacy software was previously approved using ED-12/DO-178 or
ED-12A/DO-178A, and the applicant intends to use a new or modified tool for
modifications to the legacy software, they should use the criteria of
ED-12C/DO-178C, Section 12.2 to determine whether tool qualification is
needed. If the applicant needs to qualify the tool, they should use the
software level assigned by the system safety assessment for determining the
required TQL, and should use ED-215/DO-330 for the applicable objectives,
activities, and life cycle data. The applicant may declare their qualified
tool as satisfying ED-215/DO-330, but not the legacy software as equivalent to
satisfying ED‑12C/DO-178C.

b.         If
the applicant’s legacy software was previously approved using ED-12B/DO-178B,
and they do not intend to declare equivalence to satisfying ED-12C/DO-178C,
the applicant can either:

1.         use
their ED-12B/DO-178B tool qualification processes for qualifying new or
modified tools in support of modifications to ED-12B/DO-178B legacy software,
or

2.         update
their tool qualification processes and qualify the tool using ED 215/DO-330,
referring to Table 2 of this document for determining the required TQL; the
applicant may then declare their qualified tool as satisfying ED-215/DO-330.

c.         If
the applicant’s legacy software was previously approved using ED-12B/DO-178B,
the applicant intends to declare equivalence to satisfying ED-12C/DO-178C, and
has ED-12B/DO-178B legacy tools that need to be qualified, the applicant
should follow the guidance of this subparagraph.

1.         ED-12C/DO-178C
establishes five levels of tool qualification based on the tool use and its
potential impact on the software life cycle processes (see Section 12.2.2 and
Table 12-1 of ED‑12C/DO‑178C). However, ED-12C/DO-178C does not address the
use of tools previously qualified according to the ED-12B/DO-178B criteria.
For a tool previously qualified as an ED‑12B/DO-178B development tool or
verification tool, the applicant should use Table 2 below to determine the
correlation between the ED-12B/DO-178B tool qualification type and the ED‑12C/DO-178C
tool criteria and TQLs.

Table 2 —
Correlation between ED-12B/DO-178B tool qualification type and ED-12C/DO-178C
tool criteria and TQLs

<table border="1" cellpadding="0" cellspacing="0" width="580">
<tr>
<td valign="top" width="177">
ED-12B/DO-178B 
 Tool Qualification Type
</td>
<td valign="top" width="77">
Software Level
</td>
<td valign="top" width="119">
ED-12C/DO-178C 
 Tool Criteria
</td>
<td valign="top" width="206">
ED-12C/ED-215 
 TQL
</td>
</tr>
<tr>
<td valign="top" width="177">
Development
</td>
<td valign="top" width="77">
A
</td>
<td valign="top" width="119">
1
</td>
<td valign="top" width="206">
TQL-1
</td>
</tr>
<tr>
<td valign="top" width="177">
Development
</td>
<td valign="top" width="77">
B
</td>
<td valign="top" width="119">
1
</td>
<td valign="top" width="206">
TQL-2
</td>
</tr>
<tr>
<td valign="top" width="177">
Development
</td>
<td valign="top" width="77">
C
</td>
<td valign="top" width="119">
1
</td>
<td valign="top" width="206">
TQL-3
</td>
</tr>
<tr>
<td valign="top" width="177">
Development
</td>
<td valign="top" width="77">
D
</td>
<td valign="top" width="119">
1
</td>
<td valign="top" width="206">
TQL-4
</td>
</tr>
<tr>
<td valign="top" width="177">
Verification
</td>
<td valign="top" width="77">
A, B
</td>
<td valign="top" width="119">
2
</td>
<td valign="top" width="206">
TQL-4
</td>
</tr>
<tr>
<td valign="top" width="177">
Verification
</td>
<td valign="top" width="77">
C, D
</td>
<td valign="top" width="119">
2
</td>
<td valign="top" width="206">
TQL-5
</td>
</tr>
<tr>
<td valign="top" width="177">
Verification
</td>
<td valign="top" width="77">
All
</td>
<td valign="top" width="119">
3
</td>
<td valign="top" width="206">
TQL-5
</td>
</tr>
</table>

2.         Development
tools previously qualified using ED-12B/DO-178B

a.         If
the ED-12B/DO-178B software level assigned to the tool correlates with or
exceeds the required TQL established by ED-12C/DO-178C, the applicant may
continue to use their ED‑12B/DO‑178B tool qualification processes. If there
are changes to the tool’s operational environment or to the tool itself, then
the applicant should conduct a tool CIA in accordance with Section 11.2.2 or
11.2.3 of ED-215/DO-330, respectively, and perform changes using their
ED-12B/DO-178B tool qualification processes.

b.         If
the ED-12B/DO-178B software level assigned to the tool does not satisfy the
required TQL, the applicant should update their tool qualification processes
and requalify the tool using ED-215/DO-330.

c.         The
applicant may declare their tool as equivalent to satisfying ED-215/DO-330 if
all the changes to the tool and to their tool qualification processes satisfy
ED-215/DO-330.

3.         Verification
tools previously qualified using ED-12B/DO-178B

a.         If
TQL-5 is required, and the applicant’s verification tool was previously
qualified using
ED-12B/DO-178B:

i.          the
applicant may continue to use their ED-12B/DO-178B tool qualification process;
and

ii.         If
there are changes to the tool or the tool’s operational environment, the
applicant should conduct a tool CIA and reverify the
tool using their ED-12B/DO-178B tool qualification processes or requalify the
tool using ED-215/DO-330.

b.         If
TQL-4 is required, the applicant should requalify their verification tool
using
ED-215/DO-330.

c.         The
applicant may declare their tool as equivalent to satisfying ED-215/DO-330 if
all changes to the tool (if applicable) and to their tool qualification
processes satisfy
ED-215/DO-330.

11.       RELATED
REGULATORY, ADVISORY, AND INDUSTRY MATERIAL

a.         Related EASA CSs

1.         Decision
No. 2003/14/RM of the Executive Director of the Agency of 14 November 2003 on
certification specifications, including airworthiness codes and acceptable
means of compliance for normal, utility, aerobatic and commuter category
aeroplanes (‘CS-23’).

2.         Decision
No. 2003/2/RM of the Executive Director of the Agency of 17 October 2003 on
certification specifications, including airworthiness codes and acceptable
means of compliance, for large aeroplanes (‘CS-25’).

3.         Decision
No. 2003/15/RM of the Executive Director of the Agency of 14 November 2003 on
certification specifications for small rotorcraft (‘CS-27’).

4.         Decision
No. 2003/16/RM of the Executive Director of the Agency of 14 November 2003 on
certification specifications for large rotorcraft (‘CS-29’).

5.         Decision
No. 2003/9/RM of the Executive Director of the Agency of 24 October 2003 on
certification specifications, including airworthiness codes and acceptable
means of compliance, for engines (‘CS-E’).

6.         Decision
No. 2003/7/RM of the Executive Director of the Agency of 24 October 2003 on
certification specifications, including airworthiness codes and acceptable
means of compliance, for propellers (‘CS-P’).

7.         Decision
No. 2003/10/RM of the Executive Director of the Agency of 24 October 2003 on
certification specifications, including airworthiness codes and acceptable
means of compliance, for European Technical Standard Orders (‘CS-ETSO’).

8.         Decision
No. 2003/5/RM of the Executive Director of the Agency of 17 October 2003 on
certification specifications, including airworthiness codes and acceptable
means of compliance, for auxiliary power units (‘CS-APU’).

9.         Decision
No. 2003/12/RM of the Executive Director of the Agency of 5 November 2003 on
general acceptable means of compliance for airworthiness of products, parts
and appliances (‘AMC-20’).

b.         FAA advisory circulars (ACs)

1.         AC
23.1309-1E, System Safety Analysis and Assessment for Part 23 Airplanes, 17
November 2011.

2.         AC
27.1309A, Equipment, Systems, and Installations (included in AC 27-1B,
Certification of Normal Category Rotorcraft), 4 February 2016.

3.         AC
29.1309A, Equipment, Systems, and Installations (included in AC 29-2C,
Certification of Transport Category Rotorcraft), 4 February 2016.

c.         Industry documents

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

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

3.         EUROCAE
ED-12B, Software Considerations in Airborne Systems and Equipment
Certification, 1 December 1992.

4.         EUROCAE
ED-12C, Software Considerations in Airborne Systems and Equipment
Certification, 1 January 2012.

5.         EUROCAE
ED-94C, Supporting Information for ED-12C and ED-109A,
1 January 2012.

6.         EUROCAE
ED-215, Software Tool Qualification Considerations, 1 January 2012.

7.         EUROCAE
ED-216, Formal Methods Supplement to ED-12C and ED-109A,
1 January 2012.

8.         EUROCAE
ED-217, Object-Oriented Technology and Related Techniques Supplement to ED-12C
and ED-109A, 1 January 2012.

9.         EUROCAE
ED-218, Model-Based Development and Verification Supplement to ED-12C and ED-109A,
1 January 2012.

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

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

12.      RTCA
DO-178B, Software Considerations in Airborne Systems and Equipment
Certification, 1 December 1992.

13.      RTCA
DO-178C, Software Considerations in Airborne Systems and Equipment
Certification, 13 December 2011.

14.      RTCA
DO-248C, Supporting Information for DO-178C and DO-278A,
13 December 2011.

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

16.      RTCA DO-330,
Software Tool Qualification Considerations, 13 December 2011.

17.      RTCA
DO-331, Model-Based Development and Verification Supplement to DO-178C and
DO-278A, 13 December 2011.

18.      RTCA
DO-332, Object-Oriented Technology and Related Techniques Supplement to
DO-178C and DO-278A, 13 December 2011.

19.      RTCA
DO-333, Formal Methods Supplement to DO-178C and DO-278A,
13 December 2011.

12.       AVAILABILITY
OF DOCUMENTS

—
EASA CSs and AMC are available at: [www.easa.europa.eu](http://www.easa.europa.eu).

—
FAA ACs are available at: [www.faa.gov](http://www.faa.gov).

—
EUROCAE are available on payment at:

European Organisation for Civil Aviation Equipment

102 rue Etienne Dolet, 92240 Malakoff, France

Telephone: +33 1 40 92 79 30; Fax +33 1 46 55 62 65

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

—
RTCA documents are available on payment at:

RTCA, Inc.

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

Email: info@rtca.org,
website: [www.rtca.org](http://www.rtca.org).

[Amdt 20/14]

AMC 20-115D Airborne Software
Development Assurance Using EUROCAE ED-12 and RTCA DO-178

ED Decision 2017/020/R

1.         PURPOSE

a.         This AMC describes an acceptable
means, but not the only means, for showing compliance with the applicable airworthiness regulations with regard to the software
aspects of airborne systems and equipment in the domain of product
certification or European technical standard orders (ETSOs) authorisation.
Compliance with this AMC is not mandatory and therefore an applicant may elect
to use an alternative means of compliance (AltMoC). However, the AltMoC must
meet the relevant requirements, ensure an equivalent level of software safety
as this AMC, and be approved by the European Aviation Safety Agency (EASA) on
a product or ETSO article basis.

b.         This
AMC recognises the following European Organisation for Civil Aviation
Equipment (EUROCAE) and Radio Technical Commission for Aeronautics (RTCA) documents:

1.         EUROCAE ED-12C, Software
Considerations in Airborne Systems and Equipment Certification,
1 January 2012, and RTCA DO-178C, Software Considerations in
Airborne Systems and Equipment Certification, 13 December 2011;

2.         EUROCAE ED-215, Software Tool
Qualification Considerations, 1 January 2012, and RTCA DO-330, Software Tool
Qualification Considerations, 13 December 2011;

3.         EUROCAE ED-216, Formal Methods
Supplement to ED-12C and ED-109A, 1 January 2012, and RTCA DO-333,
Formal Methods Supplement to DO-178C and DO-278A, 13 December 2011;

4.         EUROCAE ED-217, Object-Oriented
Technology and Related Techniques Supplement to ED-12C and ED-109A,
1 January 2012, and RTCA DO-332, Object-Oriented Technology and
Related Techniques Supplement to DO-178C and DO-278A,
13 December 2011; and

5.         EUROCAE ED-218, Model-Based
Development and Verification Supplement to ED-12C and ED‑109A,
1 January 2012, and RTCA DO-331, Model-Based Development and
Verification Supplement to DO-178C and DO-278A, 13 December 2011.

Note:
EUROCAE ED is hereinafter referred to as ‘ED’; RTCA DO is hereinafter referred
to as ‘DO’. Where the notation ‘ED-XXX/DO-XXX’ appears in this document, the
referenced documents are recognised as being equivalent.

c.         This AMC identifies the following as
supporting documents:

—
    ED-94C, Supporting Information
for ED-12C and ED-109A, 1 January 2012; and

—
DO-248C, Supporting Information for DO-178C and DO-278A,
13 December 2011.

ED-94C/DO-248C
contains a collection of frequently asked questions (FAQs) and discussion
papers (DPs) compiled and approved by the authors of ED-12C and DO-178C to
provide clarification of the guidance contained in ED-12C/DO-178C.

d.         References to
the use of ED-12C/DO-178C in this AMC include the use of ED-215/DO-330 and
supplements ED-216/DO-333, ED-217/DO-332 and ED-218/DO-331, as applicable.

e.         This AMC establishes guidance for
using existing ED-12B/DO-178B processes for new software development.

f.          This AMC also establishes guidance
for transitioning to ED-12C/DO-178C when making modifications to software
previously approved using ED-12/DO-178, ED-12A/DO-178A, or ED-12B/DO-178B.

2.         APPLICABILITY

This AMC
applies to applicants, design approval holders (DAHs), and developers of
airborne systems and equipment containing software to be installed on
type-certified aircraft, engines, and propellers, or to be used in ETSO
articles.

3.         REPLACEMENT

This AMC
replaces and cancels AMC 20-115C, Software Considerations in Airborne Systems
and Equipment Certification, 12 September 2013.

4.         BACKGROUND

a.         ED-12C/DO-178C, Appendix A, Section 3,
provides a summary of the differences between ED‑12C/DO‑178C and
ED-12B/DO-178B. The EUROCAE and RTCA Inc. documents listed in
subparagraph 1.b. of this AMC provide guidance for establishing software
life cycle planning, development, verification, configuration management,
quality assurance and certification liaison processes to be used in the development
of software for airborne systems. The guidance provided in these documents is
in the form of:

1.         objectives for software life
cycle processes;

2.         activities that provide a means
for satisfying the objectives; and

3.         descriptions of the evidence
indicating that the objectives have been satisfied.

b.         The technical content of this AMC is, as far as
practicable, harmonised with Federal Aviation Administration (FAA) AC 20-115D,
which is also based on ED-12C/DO-178C.

5.         USING ED-12B/DO-178B PROCESSES AND
PROCEDURES FOR NEW SOFTWARE DEVELOPMENT

a.         Applicants who have established
software development assurance processes using ED-12B/DO-178B may continue to
use those processes (including tool qualification processes) for new software
development and certification projects, provided that the following criteria
are met:

1.         The software development
assurance processes are shown to have no known process deficiencies, such as
those discovered during internal or external audits or reviews, or identified
in open problem reports (OPRs), resulting in non-satisfaction of one or more
ED-12B/DO-178B objectives. Evidence of resolution and closure of all
process-related OPRs and of all process‑related audit or review findings may
be requested.

2.         The processes were previously
used to develop software that was used in a certified product at a software
level at least as high as the software level of the software to be developed.

3.         If model-based development
(MBD), object-oriented technology (OOT), or formal methods (FMs) are to be
used, existing processes incorporating these methods should have been
evaluated and found to be acceptable by EASA on a previous certified project.
These processes should have been developed in accordance with EASA guidance
specific to the technique, such as that contained in an associated certification review item (CRI)
or a published certification memorandum (CM).

4.         If configuration data is used,
as defined in ED-12C/DO-178C under ‘Parameter data item’, existing processes
for such data should have been evaluated and found to be acceptable by EASA on
a previous certified project. In the absence of processes for using
configuration data, the applicant should establish new processes for using
PDIs in accordance with ED-12C/DO-178C.

5.         There are no significant changes
to the software processes described in the plans or to the software
development environment. This should be supported through analysis of the
changes to the previously accepted software development processes and
environment.

6.         The applicant does not intend to
declare the proposed software as having satisfied ED‑12C/DO‑178C.

b.         If the criteria of subparagraph 5.a.
are not met, the applicant should upgrade their processes and develop the new
software using ED-12C/DO-178C; tool qualification processes should be
addressed in accordance with Section 12.2 of ED-12C/DO-178C and paragraph
10(c) of this AMC.

c.         Applicants or developers should
establish new software life cycle processes in accordance with ED-12C/DO-178C.

6.         USING EUROCAE ED-12C AND RTCA DO-178C

ED-12C/DO-178C
is an acceptable means of compliance (AMC) with regard to the software aspects
of product certification or ETSOs authorisation. When using ED-12C/DO-178C,
the following should apply:

a.         The applicant should satisfy all of
the objectives associated with the software level assigned to the software,
and develop all of the associated life cycle data to demonstrate compliance
with the applicable objectives, as listed in the Annex A tables of
ED-12C/DO-178C and, where applicable, of ED-215/DO-330, ED-216/DO-333,
ED-217/DO-332, and ED-218/DO-331. The applicant should plan and execute
activities that satisfy each objective.

b.         The applicant should submit to EASA
the life cycle data specified in Section 9.3 of ED-12C/DO-178C, and Section
9.0 a. of ED-215/DO-330, as applicable to tool qualification. It is the
applicant’s responsibility to perform the planned activities and produce the
life cycle data necessary to satisfy all the applicable objectives.

c.         Section 9.4 of ED-12C/DO-178C
specifies the software life cycle data related to the type design of the
certified product. However, not all of the specified data applies to all
software levels; specifically the design description and the source code are not
part of the type design data for Level D software.

d.         The applicant should make available to
EASA, upon request, any of the data described in Section 11 of
ED-12C/DO-178C, applicable tool qualification data, data outputs from any
applicable supplements, and any other data needed to substantiate the satisfaction
of all the applicable objectives.

e.         EASA may publish an AMC to specific
certification specifications (CSs), stating the required relationship between
the criticality of the software-based systems and the software levels, as
defined in ED-12C/DO-178C. Such AMC takes precedence over the application of
Section 2.3 of ED-12C/DO-178C.

7.         RESERVED

8.         GUIDANCE APPLICABLE TO ED-12B/DO-178B
OR ED-12C/DO-178C

a.         The use of supplements with
ED-12C/DO-178C

The
applicant should apply the guidance of supplements to ED-216/DO-333,
ED-217/DO-332 and ED-218/DO-331 when incorporating the addressed software
development techniques. If the applicant intends to use multiple software
development techniques together, more than one supplement applies. The
applicant should not use supplements as stand-alone documents.

1.         When using one or more supplements,
the applicant’s plan for software aspects of certification (PSAC) should
describe:

a.         how the applicant applies
ED-12C/DO-178C and the supplement(s) together; and

b.         how the applicant addresses the
applicable ED-12C/DO-178C objectives and those added or modified by the
supplement(s): which objectives from which documents apply to which software
components, and how the applicant’s planned activities satisfy all the applicable
objectives.

2.         If the applicant intends to use any
techniques addressed by the supplements to develop a qualified tool (for tool
qualification levels (TQLs) 1, 2, 3, and 4 only), then the tool qualification
plan (TQP) should describe:

a.         based on supplement analysis, which
tool qualification objectives are affected by the use of the technique(s); and

b.         how the planned activities satisfy the
added or modified objectives.

3.         The intent of this subparagraph is to
provide clarification of Section MB.6.8.1 of ED-218/DO-331. If the applicant
uses models as defined in Section MB.1.0 of ED-218/DO-331 as the basis for
developing software, the applicant should apply the guidance of ED-218/DO-331.
When applying Section MB.6.8.1 of ED-218/DO-331, the applicant should do the
following:

a.         identify which review and analysis
objectives are planned to be satisfied by simulation alone or in combination
with reviews and analyses; all other objectives should be satisfied by reviews
and analyses, as described in Section MB.6.3 of ED-218/DO-331; and

b.         for each identified objective, justify
in detail how the simulation activity, alone or in combination with reviews
and analyses, fully satisfies the specific review and analysis objective.

b.         Guidance on field-loadable
software (FLS)

This
Section supplements ED-12C/DO-178C and ED-12B/DO-178B. The applicant should
use this guidance in addition to ED-12C/DO-178C and ED-12B/DO-178B when using
FLS in their project.

1.         As the developer, the applicant
should provide the necessary information to support the system‑level guidance
identified in items a, b, c and d of ED-12C/DO-178C, Section 2.5.5, and items
a, b, c and d of ED-12B/DO-178B, Section 2.5.

2.         The FLS should be protected against
corruption or partial loading at an integrity level appropriate for the FLS
software level.

3.         The FLS part number, when loaded in
the airborne equipment, should be verifiable by appropriate means.

4.         Protection mechanisms should be
implemented to prevent inadvertent enabling of the field-loading function
during cruising or any other safety-critical phase.

c.         Guidance on user-modifiable
software (UMS)

This
Section supplements ED-12C/DO-178C and ED-12B/DO-178B. The applicant should
use this guidance in addition to ED-12C/DO-178C and ED-12B/DO-178B when using
UMS in their project.

1.         As the developer, the applicant should
provide the necessary information to support the system‑level guidance
identified in items a, b, c and f of ED-12C/DO-178C, Section 2.5.2, and items
a and b of ED‑12B/DO-178B, Section 2.4.

2.         The modifiable part of the software
should be developed at a software level at least as high as the software level
assigned to that software.

9.         MODIFYING AND REUSING SOFTWARE
APPROVED USING ED-12/DO-178, ED-12A/DO-178A, OR ED-12B/DO-178B

a.         EASA previously approved the software
for many airborne systems using ED-12/DO-178,
ED-12A/DO-178A, or ED-12B/DO-178B as a means of compliance. In this AMC, reference to legacy software
includes the previously approved software or component(s) that makes up the
software used in legacy systems. In this subparagraph, it is described how to
demonstrate compliance with the software aspects of certification for an
application that includes modifications to legacy software or the use of
unmodified legacy software.

b.         Figure 1 presents a flow chart for
using legacy software. The applicant should use the flow chart while following
the procedures in this subparagraph if the applicant modifies or reuses legacy
software. Although these procedures apply to the majority of projects, the
applicant should coordinate with EASA any cases that do not follow this flow.

Figure 1 — Legacy software process flow chart

![Aviation.Bot AI suggestion, not from EASA source: This flowchart illustrates the process for assessing and managing legacy software, including modifications and reuse, in compliance with EASA's AMC 20-115D guidance, specifically referencing sections related to ED-12, ED-12A, ED-12B, and ED-12C standards.

Detailed Description:
The image displays a flowchart with a black background and blue lines connecting various shapes. The shapes include ovals (start/end points), rectangles (process steps), and diamonds (decision points). Text labels are present within each shape and on some connecting arrows.

The flowchart begins at the top-left with an oval labeled "Intent to use software previously shown to satisfy ED-12, ED-12A, or ED-12B."
An arrow points downwards from this oval to a rectangular process step labeled "Evaluate software usage history, SDs, ADs, OPRs, etc. See 9(b)(1)."

From this rectangle, an arrow points downwards to a diamond-shaped decision point labeled "Is the software usage history acceptable? See 9(b)(1)."
*   If the answer is "No," an arrow points right to a rectangular process step labeled "Correct process deficiencies and document plan for resolving related software deficiencies. See 9(b)(1)." An arrow then points downwards from this rectangle, turns left, and connects to the diamond-shaped decision point labeled "Is the software developed using ED-12B? See 9(b)(2)."
*   If the answer is "Yes," an arrow points downwards directly to the diamond-shaped decision point labeled "Is the software developed using ED-12B? See 9(b)(2)."

From the "Is the software developed using ED-12B? See 9(b)(2)" decision point:
*   If the answer is "No," an arrow points right to a diamond-shaped decision point labeled "Is the ED-12 or ED-12A software level acceptable? See 9(b)(2)."
    *   If the answer is "No," an arrow points downwards to a rectangular process step labeled "Upgrade software baseline including all processes & procedures using ED-12C and ED-215. See 9(b)(2)(a) or (b)."
    *   If the answer is "Yes," an arrow points right, then downwards, then left, connecting to the diamond-shaped decision point labeled "Is the legacy system software to be modified? See 9(b)(3)."
*   If the answer is "Yes," an arrow points downwards to a diamond-shaped decision point labeled "Is the ED-12B software level acceptable? See 9(b)(2)."
    *   If the answer is "No," an arrow points downwards to a rectangular process step labeled "Upgrade software baseline including all processes & procedures using ED-12B or use ED-12C and ED-215. See 9(b)(2)(c)."
    *   If the answer is "Yes," an arrow points right, then downwards, then left, connecting to the diamond-shaped decision point labeled "Is the legacy system software to be modified? See 9(b)(3)."

From the "Upgrade software baseline including all processes & procedures using ED-12C and ED-215. See 9(b)(2)(a) or (b)." rectangle, an arrow points downwards, then left, connecting to the "Is the legacy system software to be modified? See 9(b)(3)." decision point.
From the "Upgrade software baseline including all processes & procedures using ED-12B or use ED-12C and ED-215. See 9(b)(2)(c)." rectangle, an arrow points downwards, then left, connecting to the "Is the legacy system software to be modified? See 9(b)(3)." decision point.

From the "Is the legacy system software to be modified? See 9(b)(3)." decision point:
*   If the answer is "No," an arrow points downwards to an oval-shaped end point labeled "Original approval basis or baseline upgrade to ED-12C acceptable as approval basis. See 9(b)(3)(a) or (b)."
*   If the answer is "Yes," an arrow points right, then upwards, then right again, connecting to a rectangular process step labeled "Conduct a CIA. See 9(b)(4)."

From the "Conduct a CIA. See 9(b)(4)." rectangle, an arrow points downwards to a diamond-shaped decision point labeled "Will there be new software tools or changes to tools? See 9(b)(5)."
*   If the answer is "Yes," an arrow points right to a rectangular process step labeled "Determine tool qualification requirements. See Section 10." An arrow then points downwards from this rectangle, turns left, and connects to the diamond-shaped decision point labeled "Did you upgrade the software baseline to ED-12C IAW paragraph 9(b)(2)(a), (b), or (c)? See 9(b)(6)."
*   If the answer is "No," an arrow points downwards directly to the diamond-shaped decision point labeled "Did you upgrade the software baseline to ED-12C IAW paragraph 9(b)(2)(a), (b), or (c)? See 9(b)(6)."

From the "Did you upgrade the software baseline to ED-12C IAW paragraph 9(b)(2)(a), (b), or (c)? See 9(b)(6)." decision point:
*   If the answer is "No," an arrow points right, then downwards, then left, connecting to a rectangular process step labeled "Upgrade software baseline including all processes & procedures using ED-12C and ED-215. See 9(b)(9)."
*   If the answer is "Yes," an arrow points downwards to a diamond-shaped decision point labeled "If MBD, OOT, or FM will be used, do processes support the technique IAW applicable guidance? See 9(b)(7)(a)."
    *   If the answer is "No," an arrow points right, then downwards, then left, connecting to the "Upgrade software baseline including all processes & procedures using ED-12C and ED-215. See 9(b)(9)." rectangle.
    *   If the answer is "Yes," an arrow points downwards to a diamond-shaped decision point labeled "Have the software plans and environment been properly maintained? See 9(b)(7)(b)."
        *   If the answer is "No," an arrow points right, then downwards, then left, connecting to the "Upgrade software baseline including all processes & procedures using ED-12C and ED-215. See 9(b)(9)." rectangle.
        *   If the answer is "Yes," an arrow points downwards to a diamond-shaped decision point labeled "Do you want to declare equivalence to ED-12C? See 9(b)(7)(c)."
            *   If the answer is "No," an arrow points downwards to a rectangular process step labeled "Change software and associated life cycle data using the same ED-12 version as the original approval. For configuration data/PDI, use an approved process or establish new process using ED-12C. See 9(b)(8)(a) & (b)."
            *   If the answer is "Yes," an arrow points right, then downwards, then left, connecting to a rectangular process step labeled "Change software and associated life cycle data using ED-12C, Section 12.1, and applicable supplements. See 9(b)(6) & (9)."

From the "Upgrade software baseline including all processes & procedures using ED-12C and ED-215. See 9(b)(9)." rectangle, an arrow points downwards, then left, connecting to the "Change software and associated life cycle data using ED-12C, Section 12.1, and applicable supplements. See 9(b)(6) & (9)." rectangle.
From the "Change software and associated life cycle data using the same ED-12 version as the original approval. For configuration data/PDI, use an approved process or establish new process using ED-12C. See 9(b)(8)(a) & (b)." rectangle, an arrow points downwards, then left, connecting to the "Change software and associated life cycle data using ED-12C, Section 12.1, and applicable supplements. See 9(b)(6) & (9)." rectangle.

Finally, from the "Change software and associated life cycle data using ED-12C, Section 12.1, and applicable supplements. See 9(b)(6) & (9)." rectangle, an arrow points upwards and left, looping back to the "Is the legacy system software to be modified? See 9(b)(3)." decision point.

Contextual Linkage:
The flowchart outlines a decision-making process for handling legacy software. It starts by evaluating the software's history and compliance with previous ED-12 versions. Depending on the software's development standard (ED-12B, ED-12, or ED-12A) and its acceptable software level, a decision is made whether to upgrade the software baseline. If the legacy software is to be modified, a separate branch of the flowchart is followed, involving a Compliance Impact Assessment (CIA), assessment of new tools or tool changes, verification of software baseline upgrades to ED-12C, and checks for specific development techniques (MBD, OOT, FM) and maintenance of software plans. The process then leads to a decision on declaring equivalence to ED-12C, which dictates how software and life cycle data changes are managed, potentially looping back to re-evaluate the modified system. Each step references a specific paragraph within section 9(b) or Section 10, indicating a direct correlation with regulatory guidance.](file_wSyEACTCE2d/image040.png)

1.         The applicant should assess the legacy
software to be modified or reused for its usage history from previous
installations. If the software has safety-related service difficulties,
airworthiness directives, or OPRs with a potential safety impact on the
proposed installation, the applicant should establish plans to resolve all related
software deficiencies. Prior to modifying or reusing the legacy software, the
applicant should correct any related development process deficiencies, such as
those discovered during internal or external audits or reviews, or identified
in OPRs resulting in non-satisfaction of one or more ED-12B/DO-178B
objectives. Evidence of resolution and closure of all process-related OPRs and
of all process-related audit or review findings may be requested.

2.         The system safety process assigns the
minimum development assurance level based on the severity classifications of
failure conditions for a given function. The ED-12B/DO-178B software levels
are consistent with the ED-12C/DO-178C software levels. However, ED-12/DO-178
and ED‑12A/DO-178A were published prior to the establishment of the software
levels addressed in ED‑12B/DO-178B and ED‑12C/DO‑178C. The applicant should
use Table 1 to determine whether their legacy software level satisfies the
software level assigned by the system safety process for the proposed
installation. A ‘ü’ in the intersection of the row
and column indicates that the legacy software level is acceptable. For
example, legacy software with development assurance for ED‑12A/DO‑178A
software Level 2 can be considered to satisfy software Levels B, C, and D. A
blank indicates that the software level is not acceptable. Therefore, the
ED-12A/DO-178A software developed for software Level 2 would not be acceptable
where software Level A is required.

Table
1 — Software level relationships

<table border="1" cellpadding="0" cellspacing="0" width="603">
<thead>
<tr>
<td rowspan="2" valign="top" width="65">
Assigned software level
</td>
<td colspan="4" valign="top" width="164">
Legacy software level per ED-12B
</td>
<td colspan="3" valign="top" width="158">
Legacy software level per ED-12A
</td>
<td colspan="3" valign="top" width="217">
Legacy software Level 
 per ED-12
</td>
</tr>
<tr>
<td valign="top" width="41">
A
</td>
<td valign="top" width="41">
B
</td>
<td valign="top" width="41">
C
</td>
<td valign="top" width="41">
D
</td>
<td valign="top" width="53">
1
</td>
<td valign="top" width="53">
2
</td>
<td valign="top" width="53">
3
</td>
<td valign="top" width="61">
Critical
</td>
<td valign="top" width="64">
Essential
</td>
<td valign="top" width="91">
Non-Essential
</td>
</tr>
</thead>
<tr>
<td valign="top" width="65">
A
</td>
<td width="41">
ü
</td>
<td width="41">
</td>
<td width="41">
</td>
<td width="41">
</td>
<td width="53">
ü
</td>
<td width="53">
</td>
<td width="53">
</td>
<td width="61">
ü
</td>
<td width="64">
</td>
<td valign="top" width="91">
</td>
</tr>
<tr>
<td valign="top" width="65">
B
</td>
<td width="41">
ü
</td>
<td width="41">
ü
</td>
<td width="41">
</td>
<td width="41">
</td>
<td width="53">
ü
</td>
<td width="53">
ü
</td>
<td width="53">
</td>
<td width="61">
ü
</td>
<td width="64">
</td>
<td valign="top" width="91">
</td>
</tr>
<tr>
<td valign="top" width="65">
C
</td>
<td width="41">
ü
</td>
<td width="41">
ü
</td>
<td width="41">
ü
</td>
<td width="41">
</td>
<td width="53">
ü
</td>
<td width="53">
ü
</td>
<td width="53">
</td>
<td width="61">
ü
</td>
<td width="64">
ü
</td>
<td valign="top" width="91">
</td>
</tr>
<tr>
<td valign="top" width="65">
D
</td>
<td width="41">
ü
</td>
<td width="41">
ü
</td>
<td width="41">
ü
</td>
<td width="41">
ü
</td>
<td width="53">
ü
</td>
<td width="53">
ü
</td>
<td width="53">
</td>
<td width="61">
ü
</td>
<td width="64">
ü
</td>
<td valign="top" width="91">
</td>
</tr>
</table>

a.         If the legacy software was developed
at software level ‘Essential’ using ED-12/DO-178 and was previously accepted
by the certification authority as acceptable for software Level B, it remains
acceptable for the new project. If the ED-12/DO-178 legacy software was not previously
assessed, or the software level is not acceptable, then the applicant should
upgrade the software development baseline, including all processes and
procedures (as well as tool qualification processes), using Section 12.1.4 of
ED-12C/DO-178C, and ED‑215/DO-330.

b.         If the legacy software was developed
using ED-12A/DO-178A, and the software level is not acceptable, the applicant
should upgrade the software development baseline, including all processes and
procedures (as well as tool qualification processes), using Section 12.1.4 of
ED-12C/DO-178C, and ED-215/DO-330.

c.         If the legacy software was developed
using ED-12B/DO-178B, and the software level is not acceptable, the applicant
should upgrade the software development baseline, including all processes and
procedures (as well as tool qualification processes), using Section 12.1.4 of
ED-12B/DO‑178B or ED-12C/DO-178C, and ED-215/DO-330.

3.         If the criteria of 9(b)(1) and 9(b)(2)
are satisfied and modifications to the software are not required, then:

a.         the original approval may serve as the
basis for the software in the installation approval of the proposed system;
and

b.         if the applicant upgraded the software
development baseline using ED-12C/DO-178C and updated all processes and
procedures, as well as tool qualification processes, to ED‑12C/DO-178C and ED‑215/DO-330,
then the applicant may declare their software as equivalent to satisfying
ED-12C/DO-178C; however, the applicant cannot declare their unmodified tools
as equivalent to satisfying ED-12C/DO-178C and ED-215/DO-330. The applicant
should make all subsequent modifications to all their software and tools using
their processes and procedures that satisfy ED-12C/DO-178C and ED-215/DO-330.

4.         If modifications to the software are
required, the applicant should conduct a software change impact analysis (CIA)
to determine the extent of the modifications, the impact of those
modifications, and what verification is required to ensure that the modified
software performs its intended function and continues to satisfy the
identified means of compliance. The applicant should:

a.         identify the software changes to be
incorporated and conduct a CIA consisting of one or more analyses associated
with the software change, as identified in ED-12C/DO-178C, Section 12.1;

b.         conduct the verification, as indicated
by the CIA; and

c.         summarise the results of the CIA in
the plan for software aspects of certification (PSAC) or in the software
accomplishment summary (SAS).

5.         If new software tools or modifications
to tools are needed, please refer to paragraph 10 of this AMC to determine the
tool qualification requirements.

6.         If the applicant upgraded the software
baseline to ED-12C/DO-178C in accordance with subparagraph 9(b)(2), they
should make all modifications to the software using ED-12C/DO-178C, Section
12.1. If the applicant wants to declare their software as equivalent to
satisfying ED‑12C/DO-178C, the applicant’s equivalence declaration applies to
both modified and unmodified software and is valid even if the applicant uses
unmodified tools that have not been qualified using ED-12C/DO-178C. However,
the applicant cannot declare their unmodified tools as equivalent to
satisfying ED-12C/DO-178C and ED-215/DO-330. All subsequent modifications to
all their software and tools are to be made using processes and procedures
satisfying ED‑12C/DO‑178C and ED-215/DO-330.

7.         If the applicant wants to use their
existing processes to make modifications to their legacy software using the
version of ED-12/DO-178 (i.e. ED-12/DO-178, ED-12A/DO-178A, or ED‑12B/DO-178B)
used for the original software approval, the applicant may do so, provided
that all of the following conditions are met:

a.         If MBD, OOT, or FMs are to be used,
existing processes incorporating these methods should have been evaluated and
found to be acceptable by EASA on a previous certified project. These
processes should have been developed in accordance with EASA guidance specific
to the technique, such as that contained in an associated CRI or a published
CM.

b.         The applicant has maintained, and can
still use, the software plans, processes, and life cycle environment,
including improvements to processes or to the life cycle environment as
captured in revised plans.

c.         The applicant does not intend to
declare the proposed software as satisfying ED‑12C/DO‑178C.

8.         If the conditions of subparagraph
9(b)(7) are satisfied:

a.         the applicant may accomplish all
modifications to the software using the same ED‑12/DO‑178 version as for the
original approval. However, the applicant may not declare their software as
equivalent to satisfying ED-12C/DO-178C; and

b.         if configuration data is used, as
defined under ‘Parameter data item’ in ED‑12C/DO‑178C, the applicant may use
existing processes for such data if the processes were evaluated and found to
be acceptable by EASA on a previous certified project; in the absence of
processes for using configuration data, the applicant should establish new processes
for using parameter data items (PDIs) in accordance with ED-12C/DO-178C.

9.         If any of the conditions of
subparagraph 9(b)(7) is not satisfied, the applicant should update all their
processes and procedures, as well as tool qualification processes, using
ED-12C/DO-178C and ED‑215/DO‑330, and make all modifications to the software
using ED-12C/DO-178C, Section 12.1. If the applicant wants to declare
their software as equivalent to satisfying ED‑12C/DO‑178C, their declaration
applies to both the modified and unmodified software and is valid even if the
applicant uses unmodified tools that have not been qualified using ED‑12C/DO‑178C
and ED-215/DO-330. However, the applicant cannot declare their unmodified
tools as equivalent to satisfying ED-12C/DO-178C and ED-215/DO-330. The applicant
should make all subsequent modifications to all their software and tools using
their processes and procedures that satisfy ED-12C/DO-178C and ED-215/DO-330.

10.       TOOL QUALIFICATION

Sections
12.2 of ED-12C/DO-178C and ED-215/DO-330 provide an acceptable method for tool
qualification. ED-215/DO-330 contains its own complete set of objectives,
activities, and life cycle data for tool qualification.

a.         If the applicant’s legacy software was
previously approved using ED-12/DO-178 or ED-12A/DO-178A, and the applicant
intends to use a new or modified tool for modifications to the legacy
software, they should use the criteria of ED-12C/DO-178C, Section 12.2 to
determine whether tool qualification is needed. If the applicant needs to
qualify the tool, they should use the software level assigned by the system
safety assessment for determining the required TQL, and should use
ED-215/DO-330 for the applicable objectives, activities, and life cycle data.
The applicant may declare their qualified tool as satisfying ED-215/DO-330,
but not the legacy software as equivalent to satisfying ED‑12C/DO-178C.

b.         If the applicant’s legacy software was
previously approved using ED-12B/DO-178B, and they do not intend to declare
equivalence to satisfying ED-12C/DO-178C, the applicant can either:

1.         use their ED-12B/DO-178B tool
qualification processes for qualifying new or modified tools in support of
modifications to ED-12B/DO-178B legacy software, or

2.         update their tool qualification
processes and qualify the tool using ED 215/DO-330, referring to Table 2 of
this document for determining the required TQL; the applicant may then declare
their qualified tool as satisfying ED-215/DO-330.

c.         If the applicant’s legacy software was
previously approved using ED-12B/DO-178B, the applicant intends to declare
equivalence to satisfying ED-12C/DO-178C, and has ED-12B/DO-178B legacy tools
that need to be qualified, the applicant should follow the guidance of this
subparagraph.

1.         ED-12C/DO-178C establishes five levels
of tool qualification based on the tool use and its potential impact on the
software life cycle processes (see Section 12.2.2 and Table 12-1 of ED‑12C/DO‑178C).
However, ED-12C/DO-178C does not address the use of tools previously qualified
according to the ED-12B/DO-178B criteria. For a tool previously qualified as
an ED‑12B/DO-178B development tool or verification tool, the applicant should
use Table 2 below to determine the correlation between the ED-12B/DO-178B tool
qualification type and the ED‑12C/DO-178C tool criteria and TQLs.

Table
2 — Correlation between ED-12B/DO-178B tool qualification type
and ED-12C/DO-178C tool criteria and TQLs

<table border="1" cellpadding="0" cellspacing="0" width="580">
<tr>
<td valign="top" width="177">
ED-12B/DO-178B
 
 Tool Qualification Type
</td>
<td valign="top" width="77">
Software
 Level
</td>
<td valign="top" width="119">
ED-12C/DO-178C 
 Tool Criteria
</td>
<td valign="top" width="206">
ED-12C/ED-215 
 TQL
</td>
</tr>
<tr>
<td valign="top" width="177">
Development
</td>
<td valign="top" width="77">
A
</td>
<td valign="top" width="119">
1
</td>
<td valign="top" width="206">
TQL-1
</td>
</tr>
<tr>
<td valign="top" width="177">
Development
</td>
<td valign="top" width="77">
B
</td>
<td valign="top" width="119">
1
</td>
<td valign="top" width="206">
TQL-2
</td>
</tr>
<tr>
<td valign="top" width="177">
Development
</td>
<td valign="top" width="77">
C
</td>
<td valign="top" width="119">
1
</td>
<td valign="top" width="206">
TQL-3
</td>
</tr>
<tr>
<td valign="top" width="177">
Development
</td>
<td valign="top" width="77">
D
</td>
<td valign="top" width="119">
1
</td>
<td valign="top" width="206">
TQL-4
</td>
</tr>
<tr>
<td valign="top" width="177">
Verification
</td>
<td valign="top" width="77">
A, B
</td>
<td valign="top" width="119">
2
</td>
<td valign="top" width="206">
TQL-4
</td>
</tr>
<tr>
<td valign="top" width="177">
Verification
</td>
<td valign="top" width="77">
C, D
</td>
<td valign="top" width="119">
2
</td>
<td valign="top" width="206">
TQL-5
</td>
</tr>
<tr>
<td valign="top" width="177">
Verification
</td>
<td valign="top" width="77">
All
</td>
<td valign="top" width="119">
3
</td>
<td valign="top" width="206">
TQL-5
</td>
</tr>
</table>

2.         Development tools previously qualified
using ED-12B/DO-178B

a.         If the ED-12B/DO-178B software level
assigned to the tool correlates with or exceeds the required TQL established
by ED-12C/DO-178C, the applicant may continue to use their ED‑12B/DO‑178B tool
qualification processes. If there are changes to the tool’s operational
environment or to the tool itself, then the applicant should conduct a tool
CIA in accordance with Section 11.2.2 or 11.2.3 of ED-215/DO-330,
respectively, and perform changes using their ED-12B/DO-178B tool
qualification processes.

b.         If the ED-12B/DO-178B software level
assigned to the tool does not satisfy the required TQL, the applicant should
update their tool qualification processes and requalify the tool using
ED-215/DO-330.

c.         The applicant may declare their tool
as equivalent to satisfying ED-215/DO-330 if all the changes to the tool and
to their tool qualification processes satisfy ED-215/DO-330.

3.         Verification tools previously
qualified using ED-12B/DO-178B

a.         If TQL-5 is required, and the
applicant’s verification tool was previously qualified using
ED-12B/DO-178B:

i.          the applicant may continue to use
their ED-12B/DO-178B tool qualification process; and

ii.         If there are changes to the tool or
the tool’s operational environment, the applicant should conduct a tool CIA
and reverify the tool using their ED-12B/DO-178B tool
qualification processes or requalify the tool using ED-215/DO-330.

b.         If TQL-4 is required, the applicant
should requalify their verification tool using
ED-215/DO-330.

c.         The applicant may declare their tool
as equivalent to satisfying ED-215/DO-330 if all changes to the tool (if
applicable) and to their tool qualification processes satisfy
ED-215/DO-330.

11.       RELATED REGULATORY, ADVISORY, AND
INDUSTRY MATERIAL

a.         Related EASA CSs

1.         Decision No. 2003/14/RM of the
Executive Director of the Agency of 14 November 2003 on certification
specifications, including airworthiness codes and acceptable means of
compliance for normal, utility, aerobatic and commuter category aeroplanes
(‘CS-23’).

2.         Decision No. 2003/2/RM of the
Executive Director of the Agency of 17 October 2003 on certification specifications,
including airworthiness codes and acceptable means of compliance, for large
aeroplanes (‘CS-25’).

3.         Decision No. 2003/15/RM of the
Executive Director of the Agency of 14 November 2003 on certification
specifications for small rotorcraft (‘CS-27’).

4.         Decision No. 2003/16/RM of the
Executive Director of the Agency of 14 November 2003 on certification
specifications for large rotorcraft (‘CS-29’).

5.         Decision No. 2003/9/RM of the
Executive Director of the Agency of 24 October 2003 on certification
specifications, including airworthiness codes and acceptable means of
compliance, for engines (‘CS-E’).

6.         Decision No. 2003/7/RM of the
Executive Director of the Agency of 24 October 2003 on certification
specifications, including airworthiness codes and acceptable means of
compliance, for propellers (‘CS-P’).

7.         Decision No. 2003/10/RM of the
Executive Director of the Agency of 24 October 2003 on certification
specifications, including airworthiness codes and acceptable means of
compliance, for European Technical Standard Orders (‘CS-ETSO’).

8.         Decision No. 2003/5/RM of the
Executive Director of the Agency of 17 October 2003 on certification
specifications, including airworthiness codes and acceptable means of
compliance, for auxiliary power units (‘CS-APU’).

9.         Decision No. 2003/12/RM of the
Executive Director of the Agency of 5 November 2003 on general acceptable
means of compliance for airworthiness of products, parts and appliances
(‘AMC-20’).

b.         FAA advisory circulars (ACs)

1.         AC 23.1309-1E, System Safety Analysis
and Assessment for Part 23 Airplanes, 17 November 2011.

2.         AC 27.1309A, Equipment, Systems, and
Installations (included in AC 27-1B, Certification of Normal Category
Rotorcraft), 4 February 2016.

3.         AC 29.1309A, Equipment, Systems, and
Installations (included in AC 29-2C, Certification of Transport Category
Rotorcraft), 4 February 2016.

c.         Industry documents

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

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

3.         EUROCAE ED-12B, Software
Considerations in Airborne Systems and Equipment Certification,
1 December 1992.

4.         EUROCAE ED-12C, Software
Considerations in Airborne Systems and Equipment Certification,
1 January 2012.

5.         EUROCAE ED-94C, Supporting
Information for ED-12C and ED-109A, 1 January 2012.

6.         EUROCAE ED-215, Software Tool
Qualification Considerations, 1 January 2012.

7.         EUROCAE ED-216, Formal Methods
Supplement to ED-12C and ED-109A, 1 January 2012.

8.         EUROCAE ED-217, Object-Oriented
Technology and Related Techniques Supplement to ED-12C and ED-109A,
1 January 2012.

9.         EUROCAE ED-218, Model-Based
Development and Verification Supplement to ED-12C and ED-109A,
1 January 2012.

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

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

12.      RTCA DO-178B, Software
Considerations in Airborne Systems and Equipment Certification,
1 December 1992.

13.      RTCA DO-178C, Software
Considerations in Airborne Systems and Equipment Certification,
13 December 2011.

14.      RTCA DO-248C, Supporting
Information for DO-178C and DO-278A, 13 December 2011.

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

16.      RTCA DO-330, Software Tool Qualification
Considerations, 13 December 2011.

17.      RTCA DO-331, Model-Based
Development and Verification Supplement to DO-178C and DO-278A,
13 December 2011.

18.      RTCA DO-332, Object-Oriented
Technology and Related Techniques Supplement to DO-178C and DO-278A,
13 December 2011.

19.      RTCA DO-333, Formal Methods
Supplement to DO-178C and DO-278A, 13 December 2011.

12.       AVAILABILITY OF DOCUMENTS

—
EASA CSs and AMC are available at: [www.easa.europa.eu](http://www.easa.europa.eu).

—
FAA ACs are available at: [www.faa.gov](http://www.faa.gov).

—
EUROCAE are available on payment at:

European
Organisation for Civil Aviation Equipment

102 rue
Etienne Dolet, 92240 Malakoff, France

Telephone:
+33 1 40 92 79 30; Fax +33 1 46 55 62 65

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

—
RTCA documents are available on payment at:

RTCA,
Inc.

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

Email: info@rtca.org, website: [www.rtca.org](http://www.rtca.org).

[Amdt 20/14]

AMC 20-115D Airborne Software Development Assurance Using EUROCAE ED-12 and RTCA DO-178

ED Decision 2017/020/R

1. PURPOSE

a. This AMC describes an acceptable means, but not the only means, for showing compliance with the applicable airworthiness regulations with regard to the software aspects of airborne systems and equipment in the domain of product certification or European technical standard orders (ETSOs) authorisation. Compliance with this AMC is not mandatory and therefore an applicant may elect to use an alternative means of compliance (AltMoC). However, the AltMoC must meet the relevant requirements, ensure an equivalent level of software safety as this AMC, and be approved by the European Aviation Safety Agency (EASA) on a product or ETSO article basis.

b. This AMC recognises the following European Organisation for Civil Aviation Equipment (EUROCAE) and Radio Technical Commission for Aeronautics (RTCA) documents:

1. EUROCAE ED-12C, Software Considerations in Airborne Systems and Equipment Certification, 1 January 2012, and RTCA DO-178C, Software Considerations in Airborne Systems and Equipment Certification, 13 December 2011;

2. EUROCAE ED-215, Software Tool Qualification Considerations, 1 January 2012, and RTCA DO-330, Software Tool Qualification Considerations, 13 December 2011;

3. EUROCAE ED-216, Formal Methods Supplement to ED-12C and ED-109A, 1 January 2012, and RTCA DO-333, Formal Methods Supplement to DO-178C and DO-278A, 13 December 2011;

4. EUROCAE ED-217, Object-Oriented Technology and Related Techniques Supplement to ED-12C and ED-109A, 1 January 2012, and RTCA DO-332, Object-Oriented Technology and Related Techniques Supplement to DO-178C and DO-278A, 13 December 2011; and

5. EUROCAE ED-218, Model-Based Development and Verification Supplement to ED-12C and ED‑109A, 1 January 2012, and RTCA DO-331, Model-Based Development and Verification Supplement to DO-178C and DO-278A, 13 December 2011.

Note: EUROCAE ED is hereinafter referred to as ‘ED’; RTCA DO is hereinafter referred to as ‘DO’. Where the notation ‘ED-XXX/DO-XXX’ appears in this document, the referenced documents are recognised as being equivalent.

c. This AMC identifies the following as supporting documents:

— ED-94C, Supporting Information for ED-12C and ED-109A, 1 January 2012; and

— DO-248C, Supporting Information for DO-178C and DO-278A, 13 December 2011.

ED-94C/DO-248C contains a collection of frequently asked questions (FAQs) and discussion papers (DPs) compiled and approved by the authors of ED-12C and DO-178C to provide clarification of the guidance contained in ED-12C/DO-178C.

d. References to the use of ED-12C/DO-178C in this AMC include the use of ED-215/DO-330 and supplements ED-216/DO-333, ED-217/DO-332 and ED-218/DO-331, as applicable.

e. This AMC establishes guidance for using existing ED-12B/DO-178B processes for new software development.

f. This AMC also establishes guidance for transitioning to ED-12C/DO-178C when making modifications to software previously approved using ED-12/DO-178, ED-12A/DO-178A, or ED-12B/DO-178B.

2. APPLICABILITY

This AMC applies to applicants, design approval holders (DAHs), and developers of airborne systems and equipment containing software to be installed on type-certified aircraft, engines, and propellers, or to be used in ETSO articles.

3. REPLACEMENT

This AMC replaces and cancels AMC 20-115C, Software Considerations in Airborne Systems and Equipment Certification, 12 September 2013.

4. BACKGROUND

a. ED-12C/DO-178C, Appendix A, Section 3, provides a summary of the differences between ED‑12C/DO‑178C and ED-12B/DO-178B. The EUROCAE and RTCA Inc. documents listed in subparagraph 1.b. of this AMC provide guidance for establishing software life cycle planning, development, verification, configuration management, quality assurance and certification liaison processes to be used in the development of software for airborne systems. The guidance provided in these documents is in the form of:

1. objectives for software life cycle processes;

2. activities that provide a means for satisfying the objectives; and

3. descriptions of the evidence indicating that the objectives have been satisfied.

b. The technical content of this AMC is, as far as practicable, harmonised with Federal Aviation Administration (FAA) AC 20-115D, which is also based on ED-12C/DO-178C.

5. USING ED-12B/DO-178B PROCESSES AND PROCEDURES FOR NEW SOFTWARE DEVELOPMENT

a. Applicants who have established software development assurance processes using ED-12B/DO-178B may continue to use those processes (including tool qualification processes) for new software development and certification projects, provided that the following criteria are met:

1. The software development assurance processes are shown to have no known process deficiencies, such as those discovered during internal or external audits or reviews, or identified in open problem reports (OPRs), resulting in non-satisfaction of one or more ED-12B/DO-178B objectives. Evidence of resolution and closure of all process-related OPRs and of all process‑related audit or review findings may be requested.

2. The processes were previously used to develop software that was used in a certified product at a software level at least as high as the software level of the software to be developed.

3. If model-based development (MBD), object-oriented technology (OOT), or formal methods (FMs) are to be used, existing processes incorporating these methods should have been evaluated and found to be acceptable by EASA on a previous certified project. These processes should have been developed in accordance with EASA guidance specific to the technique, such as that contained in an associated certification review item (CRI) or a published certification memorandum (CM).

4. If configuration data is used, as defined in ED-12C/DO-178C under ‘Parameter data item’, existing processes for such data should have been evaluated and found to be acceptable by EASA on a previous certified project. In the absence of processes for using configuration data, the applicant should establish new processes for using PDIs in accordance with ED-12C/DO-178C.

5. There are no significant changes to the software processes described in the plans or to the software development environment. This should be supported through analysis of the changes to the previously accepted software development processes and environment.

6. The applicant does not intend to declare the proposed software as having satisfied ED‑12C/DO‑178C.

b. If the criteria of subparagraph 5.a. are not met, the applicant should upgrade their processes and develop the new software using ED-12C/DO-178C; tool qualification processes should be addressed in accordance with Section 12.2 of ED-12C/DO-178C and paragraph 10(c) of this AMC.

c. Applicants or developers should establish new software life cycle processes in accordance with ED-12C/DO-178C.

6. USING EUROCAE ED-12C AND RTCA DO-178C

ED-12C/DO-178C is an acceptable means of compliance (AMC) with regard to the software aspects of product certification or ETSOs authorisation. When using ED-12C/DO-178C, the following should apply:

a. The applicant should satisfy all of the objectives associated with the software level assigned to the software, and develop all of the associated life cycle data to demonstrate compliance with the applicable objectives, as listed in the Annex A tables of ED-12C/DO-178C and, where applicable, of ED-215/DO-330, ED-216/DO-333, ED-217/DO-332, and ED-218/DO-331. The applicant should plan and execute activities that satisfy each objective.

b. The applicant should submit to EASA the life cycle data specified in Section 9.3 of ED-12C/DO-178C, and Section 9.0 a. of ED-215/DO-330, as applicable to tool qualification. It is the applicant’s responsibility to perform the planned activities and produce the life cycle data necessary to satisfy all the applicable objectives.

c. Section 9.4 of ED-12C/DO-178C specifies the software life cycle data related to the type design of the certified product. However, not all of the specified data applies to all software levels; specifically the design description and the source code are not part of the type design data for Level D software.

d. The applicant should make available to EASA, upon request, any of the data described in Section 11 of ED-12C/DO-178C, applicable tool qualification data, data outputs from any applicable supplements, and any other data needed to substantiate the satisfaction of all the applicable objectives.

e. EASA may publish an AMC to specific certification specifications (CSs), stating the required relationship between the criticality of the software-based systems and the software levels, as defined in ED-12C/DO-178C. Such AMC takes precedence over the application of Section 2.3 of ED-12C/DO-178C.

7. RESERVED

8. GUIDANCE APPLICABLE TO ED-12B/DO-178B OR ED-12C/DO-178C

a. The use of supplements with ED-12C/DO-178C

The applicant should apply the guidance of supplements to ED-216/DO-333, ED-217/DO-332 and ED-218/DO-331 when incorporating the addressed software development techniques. If the applicant intends to use multiple software development techniques together, more than one supplement applies. The applicant should not use supplements as stand-alone documents.

1. When using one or more supplements, the applicant’s plan for software aspects of certification (PSAC) should describe:

a. how the applicant applies ED-12C/DO-178C and the supplement(s) together; and

b. how the applicant addresses the applicable ED-12C/DO-178C objectives and those added or modified by the supplement(s): which objectives from which documents apply to which software components, and how the applicant’s planned activities satisfy all the applicable objectives.

2. If the applicant intends to use any techniques addressed by the supplements to develop a qualified tool (for tool qualification levels (TQLs) 1, 2, 3, and 4 only), then the tool qualification plan (TQP) should describe:

a. based on supplement analysis, which tool qualification objectives are affected by the use of the technique(s); and

b. how the planned activities satisfy the added or modified objectives.

3. The intent of this subparagraph is to provide clarification of Section MB.6.8.1 of ED-218/DO-331. If the applicant uses models as defined in Section MB.1.0 of ED-218/DO-331 as the basis for developing software, the applicant should apply the guidance of ED-218/DO-331. When applying Section MB.6.8.1 of ED-218/DO-331, the applicant should do the following:

a. identify which review and analysis objectives are planned to be satisfied by simulation alone or in combination with reviews and analyses; all other objectives should be satisfied by reviews and analyses, as described in Section MB.6.3 of ED-218/DO-331; and

b. for each identified objective, justify in detail how the simulation activity, alone or in combination with reviews and analyses, fully satisfies the specific review and analysis objective.

b. Guidance on field-loadable software (FLS)

This Section supplements ED-12C/DO-178C and ED-12B/DO-178B. The applicant should use this guidance in addition to ED-12C/DO-178C and ED-12B/DO-178B when using FLS in their project.

1. As the developer, the applicant should provide the necessary information to support the system‑level guidance identified in items a, b, c and d of ED-12C/DO-178C, Section 2.5.5, and items a, b, c and d of ED-12B/DO-178B, Section 2.5.

2. The FLS should be protected against corruption or partial loading at an integrity level appropriate for the FLS software level.

3. The FLS part number, when loaded in the airborne equipment, should be verifiable by appropriate means.

4. Protection mechanisms should be implemented to prevent inadvertent enabling of the field-loading function during cruising or any other safety-critical phase.

c. Guidance on user-modifiable software (UMS)

This Section supplements ED-12C/DO-178C and ED-12B/DO-178B. The applicant should use this guidance in addition to ED-12C/DO-178C and ED-12B/DO-178B when using UMS in their project.

1. As the developer, the applicant should provide the necessary information to support the system‑level guidance identified in items a, b, c and f of ED-12C/DO-178C, Section 2.5.2, and items a and b of ED‑12B/DO-178B, Section 2.4.

2. The modifiable part of the software should be developed at a software level at least as high as the software level assigned to that software.

9. MODIFYING AND REUSING SOFTWARE APPROVED USING ED-12/DO-178, ED-12A/DO-178A, OR ED-12B/DO-178B

a. EASA previously approved the software for many airborne systems using ED-12/DO-178,
 ED-12A/DO-178A, or ED-12B/DO-178B as a means of compliance. In this AMC, reference to legacy software includes the previously approved software or component(s) that makes up the software used in legacy systems. In this subparagraph, it is described how to demonstrate compliance with the software aspects of certification for an application that includes modifications to legacy software or the use of unmodified legacy software.

b. Figure 1 presents a flow chart for using legacy software. The applicant should use the flow chart while following the procedures in this subparagraph if the applicant modifies or reuses legacy software. Although these procedures apply to the majority of projects, the applicant should coordinate with EASA any cases that do not follow this flow.

Figure 1 — Legacy software process flow chart

![EASA EAR image](/static/files/file_ftLzkYEblJP/image041.png)

1. The applicant should assess the legacy software to be modified or reused for its usage history from previous installations. If the software has safety-related service difficulties, airworthiness directives, or OPRs with a potential safety impact on the proposed installation, the applicant should establish plans to resolve all related software deficiencies. Prior to modifying or reusing the legacy software, the applicant should correct any related development process deficiencies, such as those discovered during internal or external audits or reviews, or identified in OPRs resulting in non-satisfaction of one or more ED-12B/DO-178B objectives. Evidence of resolution and closure of all process-related OPRs and of all process-related audit or review findings may be requested.

2. The system safety process assigns the minimum development assurance level based on the severity classifications of failure conditions for a given function. The ED-12B/DO-178B software levels are consistent with the ED-12C/DO-178C software levels. However, ED-12/DO-178 and ED‑12A/DO-178A were published prior to the establishment of the software levels addressed in ED‑12B/DO-178B and ED‑12C/DO‑178C. The applicant should use Table 1 to determine whether their legacy software level satisfies the software level assigned by the system safety process for the proposed installation. A ‘’ in the intersection of the row and column indicates that the legacy software level is acceptable. For example, legacy software with development assurance for ED‑12A/DO‑178A software Level 2 can be considered to satisfy software Levels B, C, and D. A blank indicates that the software level is not acceptable. Therefore, the ED-12A/DO-178A software developed for software Level 2 would not be acceptable where software Level A is required.

Table 1 — Software level relationships

<table border="1" cellpadding="0" cellspacing="0" width="603"><thead><tr><td rowspan="2" valign="top" width="65">Assigned software level</td><td colspan="4" valign="top" width="164">Legacy software level per ED-12B</td><td colspan="3" valign="top" width="158">Legacy software level per ED-12A</td><td colspan="3" valign="top" width="217">Legacy software Level per ED-12</td></tr><tr><td valign="top" width="41">A</td><td valign="top" width="41">B</td><td valign="top" width="41">C</td><td valign="top" width="41">D</td><td valign="top" width="53">1</td><td valign="top" width="53">2</td><td valign="top" width="53">3</td><td valign="top" width="61">Critical</td><td valign="top" width="64">Essential</td><td valign="top" width="91">Non-Essential</td></tr></thead><tr><td valign="top" width="65">A</td><td width="41"></td><td width="41"></td><td width="41"></td><td width="41"></td><td width="53"></td><td width="53"></td><td width="53"></td><td width="61"></td><td width="64"></td><td valign="top" width="91"></td></tr><tr><td valign="top" width="65">B</td><td width="41"></td><td width="41"></td><td width="41"></td><td width="41"></td><td width="53"></td><td width="53"></td><td width="53"></td><td width="61"></td><td width="64"></td><td valign="top" width="91"></td></tr><tr><td valign="top" width="65">C</td><td width="41"></td><td width="41"></td><td width="41"></td><td width="41"></td><td width="53"></td><td width="53"></td><td width="53"></td><td width="61"></td><td width="64"></td><td valign="top" width="91"></td></tr><tr><td valign="top" width="65">D</td><td width="41"></td><td width="41"></td><td width="41"></td><td width="41"></td><td width="53"></td><td width="53"></td><td width="53"></td><td width="61"></td><td width="64"></td><td valign="top" width="91"></td></tr></table>

a. If the legacy software was developed at software level ‘Essential’ using ED-12/DO-178 and was previously accepted by the certification authority as acceptable for software Level B, it remains acceptable for the new project. If the ED-12/DO-178 legacy software was not previously assessed, or the software level is not acceptable, then the applicant should upgrade the software development baseline, including all processes and procedures (as well as tool qualification processes), using Section 12.1.4 of ED-12C/DO-178C, and ED‑215/DO-330.

b. If the legacy software was developed using ED-12A/DO-178A, and the software level is not acceptable, the applicant should upgrade the software development baseline, including all processes and procedures (as well as tool qualification processes), using Section 12.1.4 of ED-12C/DO-178C, and ED-215/DO-330.

c. If the legacy software was developed using ED-12B/DO-178B, and the software level is not acceptable, the applicant should upgrade the software development baseline, including all processes and procedures (as well as tool qualification processes), using Section 12.1.4 of ED-12B/DO‑178B or ED-12C/DO-178C, and ED-215/DO-330.

3. If the criteria of 9(b)(1) and 9(b)(2) are satisfied and modifications to the software are not required, then:

a. the original approval may serve as the basis for the software in the installation approval of the proposed system; and

b. if the applicant upgraded the software development baseline using ED-12C/DO-178C and updated all processes and procedures, as well as tool qualification processes, to ED‑12C/DO-178C and ED‑215/DO-330, then the applicant may declare their software as equivalent to satisfying ED-12C/DO-178C; however, the applicant cannot declare their unmodified tools as equivalent to satisfying ED-12C/DO-178C and ED-215/DO-330. The applicant should make all subsequent modifications to all their software and tools using their processes and procedures that satisfy ED-12C/DO-178C and ED-215/DO-330.

4. If modifications to the software are required, the applicant should conduct a software change impact analysis (CIA) to determine the extent of the modifications, the impact of those modifications, and what verification is required to ensure that the modified software performs its intended function and continues to satisfy the identified means of compliance. The applicant should:

a. identify the software changes to be incorporated and conduct a CIA consisting of one or more analyses associated with the software change, as identified in ED-12C/DO-178C, Section 12.1;

b. conduct the verification, as indicated by the CIA; and

c. summarise the results of the CIA in the plan for software aspects of certification (PSAC) or in the software accomplishment summary (SAS).

5. If new software tools or modifications to tools are needed, please refer to paragraph 10 of this AMC to determine the tool qualification requirements.

6. If the applicant upgraded the software baseline to ED-12C/DO-178C in accordance with subparagraph 9(b)(2), they should make all modifications to the software using ED-12C/DO-178C, Section 12.1. If the applicant wants to declare their software as equivalent to satisfying ED‑12C/DO-178C, the applicant’s equivalence declaration applies to both modified and unmodified software and is valid even if the applicant uses unmodified tools that have not been qualified using ED-12C/DO-178C. However, the applicant cannot declare their unmodified tools as equivalent to satisfying ED-12C/DO-178C and ED-215/DO-330. All subsequent modifications to all their software and tools are to be made using processes and procedures satisfying ED‑12C/DO‑178C and ED-215/DO-330.

7. If the applicant wants to use their existing processes to make modifications to their legacy software using the version of ED-12/DO-178 (i.e. ED-12/DO-178, ED-12A/DO-178A, or ED‑12B/DO-178B) used for the original software approval, the applicant may do so, provided that all of the following conditions are met:

a. If MBD, OOT, or FMs are to be used, existing processes incorporating these methods should have been evaluated and found to be acceptable by EASA on a previous certified project. These processes should have been developed in accordance with EASA guidance specific to the technique, such as that contained in an associated CRI or a published CM.

b. The applicant has maintained, and can still use, the software plans, processes, and life cycle environment, including improvements to processes or to the life cycle environment as captured in revised plans.

c. The applicant does not intend to declare the proposed software as satisfying ED‑12C/DO‑178C.

8. If the conditions of subparagraph 9(b)(7) are satisfied:

a. the applicant may accomplish all modifications to the software using the same ED‑12/DO‑178 version as for the original approval. However, the applicant may not declare their software as equivalent to satisfying ED-12C/DO-178C; and

b. if configuration data is used, as defined under ‘Parameter data item’ in ED‑12C/DO‑178C, the applicant may use existing processes for such data if the processes were evaluated and found to be acceptable by EASA on a previous certified project; in the absence of processes for using configuration data, the applicant should establish new processes for using parameter data items (PDIs) in accordance with ED-12C/DO-178C.

9. If any of the conditions of subparagraph 9(b)(7) is not satisfied, the applicant should update all their processes and procedures, as well as tool qualification processes, using ED-12C/DO-178C and ED‑215/DO‑330, and make all modifications to the software using ED-12C/DO-178C, Section 12.1. If the applicant wants to declare their software as equivalent to satisfying ED‑12C/DO‑178C, their declaration applies to both the modified and unmodified software and is valid even if the applicant uses unmodified tools that have not been qualified using ED‑12C/DO‑178C and ED-215/DO-330. However, the applicant cannot declare their unmodified tools as equivalent to satisfying ED-12C/DO-178C and ED-215/DO-330. The applicant should make all subsequent modifications to all their software and tools using their processes and procedures that satisfy ED-12C/DO-178C and ED-215/DO-330.

10. TOOL QUALIFICATION

Sections 12.2 of ED-12C/DO-178C and ED-215/DO-330 provide an acceptable method for tool qualification. ED-215/DO-330 contains its own complete set of objectives, activities, and life cycle data for tool qualification.

a. If the applicant’s legacy software was previously approved using ED-12/DO-178 or ED-12A/DO-178A, and the applicant intends to use a new or modified tool for modifications to the legacy software, they should use the criteria of ED-12C/DO-178C, Section 12.2 to determine whether tool qualification is needed. If the applicant needs to qualify the tool, they should use the software level assigned by the system safety assessment for determining the required TQL, and should use ED-215/DO-330 for the applicable objectives, activities, and life cycle data. The applicant may declare their qualified tool as satisfying ED-215/DO-330, but not the legacy software as equivalent to satisfying ED‑12C/DO-178C.

b. If the applicant’s legacy software was previously approved using ED-12B/DO-178B, and they do not intend to declare equivalence to satisfying ED-12C/DO-178C, the applicant can either:

1. use their ED-12B/DO-178B tool qualification processes for qualifying new or modified tools in support of modifications to ED-12B/DO-178B legacy software, or

2. update their tool qualification processes and qualify the tool using ED 215/DO-330, referring to Table 2 of this document for determining the required TQL; the applicant may then declare their qualified tool as satisfying ED-215/DO-330.

c. If the applicant’s legacy software was previously approved using ED-12B/DO-178B, the applicant intends to declare equivalence to satisfying ED-12C/DO-178C, and has ED-12B/DO-178B legacy tools that need to be qualified, the applicant should follow the guidance of this subparagraph.

1. ED-12C/DO-178C establishes five levels of tool qualification based on the tool use and its potential impact on the software life cycle processes (see Section 12.2.2 and Table 12-1 of ED‑12C/DO‑178C). However, ED-12C/DO-178C does not address the use of tools previously qualified according to the ED-12B/DO-178B criteria. For a tool previously qualified as an ED‑12B/DO-178B development tool or verification tool, the applicant should use Table 2 below to determine the correlation between the ED-12B/DO-178B tool qualification type and the ED‑12C/DO-178C tool criteria and TQLs.

Table 2 — Correlation between ED-12B/DO-178B tool qualification type
 and ED-12C/DO-178C tool criteria and TQLs

<table border="1" cellpadding="0" cellspacing="0" width="580"><tr><td valign="top" width="177">ED-12B/DO-178B Tool Qualification Type</td><td valign="top" width="77">Software Level</td><td valign="top" width="119">ED-12C/DO-178C Tool Criteria</td><td valign="top" width="206">ED-12C/ED-215 TQL</td></tr><tr><td valign="top" width="177">Development</td><td valign="top" width="77">A</td><td valign="top" width="119">1</td><td valign="top" width="206">TQL-1</td></tr><tr><td valign="top" width="177">Development</td><td valign="top" width="77">B</td><td valign="top" width="119">1</td><td valign="top" width="206">TQL-2</td></tr><tr><td valign="top" width="177">Development</td><td valign="top" width="77">C</td><td valign="top" width="119">1</td><td valign="top" width="206">TQL-3</td></tr><tr><td valign="top" width="177">Development</td><td valign="top" width="77">D</td><td valign="top" width="119">1</td><td valign="top" width="206">TQL-4</td></tr><tr><td valign="top" width="177">Verification</td><td valign="top" width="77">A, B</td><td valign="top" width="119">2</td><td valign="top" width="206">TQL-4</td></tr><tr><td valign="top" width="177">Verification</td><td valign="top" width="77">C, D</td><td valign="top" width="119">2</td><td valign="top" width="206">TQL-5</td></tr><tr><td valign="top" width="177">Verification</td><td valign="top" width="77">All</td><td valign="top" width="119">3</td><td valign="top" width="206">TQL-5</td></tr></table>

2. Development tools previously qualified using ED-12B/DO-178B

a. If the ED-12B/DO-178B software level assigned to the tool correlates with or exceeds the required TQL established by ED-12C/DO-178C, the applicant may continue to use their ED‑12B/DO‑178B tool qualification processes. If there are changes to the tool’s operational environment or to the tool itself, then the applicant should conduct a tool CIA in accordance with Section 11.2.2 or 11.2.3 of ED-215/DO-330, respectively, and perform changes using their ED-12B/DO-178B tool qualification processes.

b. If the ED-12B/DO-178B software level assigned to the tool does not satisfy the required TQL, the applicant should update their tool qualification processes and requalify the tool using ED-215/DO-330.

c. The applicant may declare their tool as equivalent to satisfying ED-215/DO-330 if all the changes to the tool and to their tool qualification processes satisfy ED-215/DO-330.

3. Verification tools previously qualified using ED-12B/DO-178B

a. If TQL-5 is required, and the applicant’s verification tool was previously qualified using
 ED-12B/DO-178B:

i. the applicant may continue to use their ED-12B/DO-178B tool qualification process; and

ii. If there are changes to the tool or the tool’s operational environment, the applicant should conduct a tool CIA and reverify the tool using their ED-12B/DO-178B tool qualification processes or requalify the tool using ED-215/DO-330.

b. If TQL-4 is required, the applicant should requalify their verification tool using
 ED-215/DO-330.

c. The applicant may declare their tool as equivalent to satisfying ED-215/DO-330 if all changes to the tool (if applicable) and to their tool qualification processes satisfy
 ED-215/DO-330.

11. RELATED REGULATORY, ADVISORY, AND INDUSTRY MATERIAL

a. Related EASA CSs

1. Decision No. 2003/14/RM of the Executive Director of the Agency of 14 November 2003 on certification specifications, including airworthiness codes and acceptable means of compliance for normal, utility, aerobatic and commuter category aeroplanes (‘CS-23’).

2. Decision No. 2003/2/RM of the Executive Director of the Agency of 17 October 2003 on certification specifications, including airworthiness codes and acceptable means of compliance, for large aeroplanes (‘CS-25’).

3. Decision No. 2003/15/RM of the Executive Director of the Agency of 14 November 2003 on certification specifications for small rotorcraft (‘CS-27’).

4. Decision No. 2003/16/RM of the Executive Director of the Agency of 14 November 2003 on certification specifications for large rotorcraft (‘CS-29’).

5. Decision No. 2003/9/RM of the Executive Director of the Agency of 24 October 2003 on certification specifications, including airworthiness codes and acceptable means of compliance, for engines (‘CS-E’).

6. Decision No. 2003/7/RM of the Executive Director of the Agency of 24 October 2003 on certification specifications, including airworthiness codes and acceptable means of compliance, for propellers (‘CS-P’).

7. Decision No. 2003/10/RM of the Executive Director of the Agency of 24 October 2003 on certification specifications, including airworthiness codes and acceptable means of compliance, for European Technical Standard Orders (‘CS-ETSO’).

8. Decision No. 2003/5/RM of the Executive Director of the Agency of 17 October 2003 on certification specifications, including airworthiness codes and acceptable means of compliance, for auxiliary power units (‘CS-APU’).

9. Decision No. 2003/12/RM of the Executive Director of the Agency of 5 November 2003 on general acceptable means of compliance for airworthiness of products, parts and appliances (‘AMC-20’).

b. FAA advisory circulars (ACs)

1. AC 23.1309-1E, System Safety Analysis and Assessment for Part 23 Airplanes, 17 November 2011.

2. AC 27.1309A, Equipment, Systems, and Installations (included in AC 27-1B, Certification of Normal Category Rotorcraft), 4 February 2016.

3. AC 29.1309A, Equipment, Systems, and Installations (included in AC 29-2C, Certification of Transport Category Rotorcraft), 4 February 2016.

c. Industry documents

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

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

3. EUROCAE ED-12B, Software Considerations in Airborne Systems and Equipment Certification, 1 December 1992.

4. EUROCAE ED-12C, Software Considerations in Airborne Systems and Equipment Certification, 1 January 2012.

5. EUROCAE ED-94C, Supporting Information for ED-12C and ED-109A, 1 January 2012.

6. EUROCAE ED-215, Software Tool Qualification Considerations, 1 January 2012.

7. EUROCAE ED-216, Formal Methods Supplement to ED-12C and ED-109A, 1 January 2012.

8. EUROCAE ED-217, Object-Oriented Technology and Related Techniques Supplement to ED-12C and ED-109A, 1 January 2012.

9. EUROCAE ED-218, Model-Based Development and Verification Supplement to ED-12C and ED-109A, 1 January 2012.

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

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

12. RTCA DO-178B, Software Considerations in Airborne Systems and Equipment Certification, 1 December 1992.

13. RTCA DO-178C, Software Considerations in Airborne Systems and Equipment Certification, 13 December 2011.

14. RTCA DO-248C, Supporting Information for DO-178C and DO-278A, 13 December 2011.

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

16. RTCA DO-330, Software Tool Qualification Considerations, 13 December 2011.

17. RTCA DO-331, Model-Based Development and Verification Supplement to DO-178C and DO-278A, 13 December 2011.

18. RTCA DO-332, Object-Oriented Technology and Related Techniques Supplement to DO-178C and DO-278A, 13 December 2011.

19. RTCA DO-333, Formal Methods Supplement to DO-178C and DO-278A, 13 December 2011.

12. AVAILABILITY OF DOCUMENTS

— EASA CSs and AMC are available at: [www.easa.europa.eu](http://www.easa.europa.eu).

— FAA ACs are available at: [www.faa.gov](http://www.faa.gov).

— EUROCAE are available on payment at:

European Organisation for Civil Aviation Equipment

102 rue Etienne Dolet, 92240 Malakoff, France

Telephone: +33 1 40 92 79 30; Fax +33 1 46 55 62 65

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

— RTCA documents are available on payment at:

RTCA, Inc.

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

Email: info@rtca.org, website: [www.rtca.org](http://www.rtca.org).

[Amdt 20/14]

Compare / EASA/ Incorporated Amendments/ Compare & Highlight Differences

AMC 20-115D Airborne Software Development Assurance Using EUROCAE ED-12 and RTCA DO-178

View