Advisory U.S. Department of Transportation Circular Federal Aviation Administration Subject: Airborne Software Assurance Date: 07/19/2013 AC No: 20-115C Initiated by: AIR-120 Change:
1. Purpose of this Advisory Circular (AC).
a. This AC describes an acceptable means, but not the only means, for showing compliance with the applicable airworthiness regulations for the software aspects of airborne systems and equipment certification. This AC is not mandatory and is not a regulation. Other ACs may describe alternate means.
b. We, the Federal Aviation Administration (FAA), wrote this AC to recognize the following RTCA, Inc. documents (RTCA DO):
(1) RTCA DO-178C, Software Considerations in Airborne Systems and Equipment Certification, dated December 13, 2011.
(2) RTCA DO-330, Software Tool Qualification Considerations, dated December 13, 2011.
(3) RTCA DO-331, Model-Based Development and Verification Supplement to DO- 178C and DO-278A, dated December 13, 2011.
(4) RTCA DO-332, Object-Oriented Technology and Related Techniques Supplement to DO-178C and DO-278A, dated December 13, 2011.
(5) RTCA DO-333, Formal Methods Supplement to DO-178C and DO-278A, dated December 13, 2011.
Note: RTCA DO is hereafter referred to as DO.
c. References to use of DO-178C in this AC include use of supplements and DO-330 as applicable.
d. This AC also establishes guidance for transitioning to DO-178C when making modifications to software previously approved using DO-178, DO-178A, or DO-178B.
e. This AC also explains the use of DO-178C for Technical Standard Order (TSO) authorizations.
f. This AC does not obligate the FAA to approve any data or perform any activities as specified within the referenced RTCA documents.
g. If you use the means in this AC as a means of compliance, you must follow it entirely.
2. Applicability. We wrote this AC for applicants, design approval holders, and developers of airborne systems and equipment containing software for type certificated aircraft, engines, and propellers. The term “type certificate” (TC) applies to the original TC, supplemental TC, and amended original or supplemental TC. We recommend developers of TSO articles use this AC for software assurance (see paragraph 7).
3. Cancellation. This AC cancels AC 20-115B, RTCA, Inc., Document RTCA/DO-178B, dated January 11, 1993.
4. Background. DO-178C addresses several issues discovered through the use of DO-178B.
See DO-178C, Appendix A, paragraph 3, for a summary of differences between DO-178C and DO-178B.
5. Using Previously Acceptable Means of Compliance. Our experiences working with applicants using DO-178B for software assurance have revealed that there are areas that DO- 178B does not adequately address. DO-178B also contains ambiguities that could be misinterpreted by the applicant. This may result in the applicant failing to meet some of the DO- 178B objectives. Therefore, we used project-specific issue papers to clarify our expectations and document how the applicant complies. Applicants who have used DO-178B in the past, or other means of compliance that were accepted by the FAA, may still be able to use the same means of compliance for certification projects. If you want to use DO-178B for software assurance, the FAA may continue to use project-specific issue papers to achieve an acceptable means of compliance. We recommend, however, that you upgrade your processes to DO-178C. New applicants or developers who are establishing software life cycle processes should do so in accordance with DO-178C.
6. Using DO-178C for Type Certification. DO-178C is an acceptable means of compliance for the software aspects of type certification. When you use DO-178C:
a. You should satisfy all the objectives associated with the software level assigned to the software components and develop all of the associated life cycle data as specified in the outputs listed in the DO-178C Annex A tables and, where applicable, the DO-330, DO-331, DO-332, and DO-333 Annex A tables. You should plan and execute activities that will satisfy each objective. If the FAA chooses not to be involved in the certification liaison process, you can consider the certification liaison process objectives and activities to be satisfied after you have produced the life cycle data specified in DO-178C, Table A-10.
b. You should submit the life cycle data specified in DO-178C, section 9.3, and DO-330, section 9.0.a. (as applicable for tool qualification), to the appropriate project certification office.
Our involvement in your software assurance processes will be at our discretion. Regardless of our involvement, it is your responsibility to perform the planned activities and produce the life cycle data necessary to satisfy all applicable objectives.
c. DO-178C, section 9.4, 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. For the data specified in DO-178C, section 9.4, if it is not required in Table A-2 or Table A-10 for a given software level, then it is not part of the type design data.
d. You should make available to us any of the data described in DO-178C, section 11, applicable tool qualification data, data outputs from any applicable supplements, and any other data needed to substantiate satisfaction of all applicable objectives.
7. Using DO-178C for TSO Authorization.
a. Requirements for submitting software documentation for TSO authorization are stated in each applicable TSO.
b. Many FAA TSOs do not specify DO-178C for software assurance. For TSOs that specify a version prior to DO-178C, or do not specify any version of DO-178, we recommend that you use DO-178C. If you use DO-178C in lieu of a specified earlier version, you should request a deviation in accordance with the requirements of 14 CFR part 21, subpart O. The project ACO may approve this type of deviation without Aircraft Engineering Division (AIR-100) coordination.
8. Use of Supplements. DO-331, DO-332 and DO-333 are supplements that address certain software development techniques. Supplements add, delete, or modify objectives, activities, and life cycle data in DO-178C. You should apply the guidance within a particular supplement when you use the addressed technique. Your Plan for Software Aspects of Certification (PSAC) should identify which supplements apply and describe how you intend to use each applicable supplement. You cannot use supplements as stand-alone documents.
a. If you intend to use multiple software development techniques together, more than one DO-178C supplement may apply. When using multiple supplements, your PSAC should describe:
(1) How you will apply DO-178C and the supplements together.
(2) How you will address the applicable DO-178C objectives and those added or modified by the supplements, which objectives apply to which software components, and how your planned activities will satisfy all applicable objectives.
b. If you intend to use any techniques addressed by the supplements to satisfy the DO-330 objectives, then you should use the applicable supplements for those objectives (tool qualification levels (TQLs) 1, 2, 3, and 4 only). Your Tool Qualification Plan should describe:
(1) How you will apply DO-330 and the supplement guidance to the tool development or verification.
(2) How you will address the applicable DO-330 objectives and those added or modified by the supplements, which objectives apply to which components of each software tool, and how the planned activities will satisfy all applicable objectives.
c. If you are using models as defined in DO-331, section MB.1.0, as the basis for developing software, you should apply the guidance in DO-331.
(1) Section MB.6.8.1 identifies certain objectives and describes the activities for using model simulation to satisfy those objectives. When applying section MB.6.8.1:
(a) You should identify which of the objectives you propose to satisfy using model simulation.
(b) If you propose to use model simulation in combination with reviews and analysis to satisfy the objectives in MB.6.8.1, you should show that the errors detected include all errors that could be detected by reviews and analysis alone.
(2) Section MB.6.8.2 identifies certain objectives relating to verification of the Executable Object Code and describes the activities for using model simulation to satisfy those objectives. When applying section MB.6.8.2:
(a) You should identify which of the objectives you propose to satisfy using model simulation.
(b) If you propose to use model simulation in combination with testing to satisfy the objectives in MB.6.8.2, you should show that the errors detected include all errors that could be detected by testing on the target platform alone.
d. The same approach to obtaining credit described in paragraph 8.c. can also be applied to simulation or testing used in non-model-based development environments.
e. DO-332, Annex OO.D.1.2-OO.D.1.7, provides information regarding related techniques that may apply to any software development, even when object oriented technology is not used.
If you plan to use related techniques outside of OOT, you may benefit from design practices identified in the related techniques sections of DO-332.
9. Modifying and Re-using Software Approved using DO-178, DO-178A, or DO-178B.
a. We previously approved the software for many airborne systems using DO-178, DO-178A, or DO-178B as a means of compliance. In this AC, we refer to these systems as legacy systems, and the software as legacy system software. In this paragraph, we describe how to demonstrate compliance with the software aspects of certification for an application that includes modifications to legacy system software or use of unmodified legacy system software.
b. Figure 1 presents a flow chart for using legacy system software. Use the flow chart while following the procedures in this paragraph if you are modifying or re-using legacy system software. Although these procedures will apply to the majority of projects, there may be situations that do not follow this flow. You should coordinate these situations with the certification office.
Figure 1 - Legacy System Software Process Flow Chart Intent to use software previously shown to satisfy DO-178, DO-178A, Conduct or DO-178B Change Impact Analysis See 9 b(4) Evaluate software usage history, SDs, ADs, OPRs, etc Will Determine too See 9 b (1) there be new software Yes qualification tools or changes to tools? requirements See 9 b (5) See paragraph 10 Is the Correct product and No software usage history process deficiencies acceptable? See 9 b (1) See 9 b (1) Did you Yes baseline to DO-178C IAW upgrade the software Yes paragraph 9 b (2)(a)or(b)?
See 9 b (6) software developed Is the No Determine if the DO-178 or DO-178A software No using DO- 178B? level satisfies the See 9 b (2) assigned software level See 9 b (2) Do you want to declare the Yes software as having satisfied DO-178C2 See 9 b (6) Is the Is the DO-178B DO-178 or DO-178A Yes No software level software level acceptable? acceptable?
See 9 b (2)(b) See 9 b (2)(a) Will No No be introduced for the first MBD, OOT, or FM Yes time during the change?
Upgrade DO-178B software Upgrade DO-178 or DO-178A See 9 b (7)(a) baseline using DO-178B or software baseline using DO-178C, section 12 1 4 DO-178C, section 12 1 4 See 9 b (2)(b) See 9 b (2)(a) Have the software plans No and environment been maintained?
See 9 b (7)(b) the software to be Yes modified?
See 9 b (3) Are parameter data item files introduced for the Yes No first time during the change?
See 9 b (7)(c) Original approval with or without baseline upgrade acceptable as approval basis Acronyms No See 9 b (3) ADS - Airworthiness Directives MBD - Model-Based Development FM - Formal Methods IAW - In Accordance With OOT - Object Onented Technology OPRS - Open Problem Reports associated life cycle data using the same DO-178() version as the original approval Change software and See 9 b (8) associated life cycle data using DO-178C, Section 12 1, and applicable supplements See 9 b (6) and 9 b (9) Change software and SDS - Service Difficulties
(1) Assess the legacy system software to be modified, or re-used in a different product, for its usage history from previous installations. If the software has safety-related service difficulties, airworthiness directives, or open problem reports that may have a safety impact on the proposed installation, correct the known software and development process deficiencies prior to modifying or re-using it in a different product.
(2) The guidance of DO-178B applies to four levels of software assurance, whereas the guidance of DO-178 and DO-178A applies to three levels. DO-178C has retained the DO-178B software levels. Use Table 1 to determine if your legacy system software level satisfies the software level assigned by the system safety assessment for the proposed installation. A “” in the intersection of the row and column indicates that the legacy system software level is acceptable. For example, legacy system software with assurance to DO-178A software Essential/Level 2 can be considered to satisfy DO-178B or DO-178C software Levels C and D.
A blank indicates that the software level is not acceptable. Therefore, the DO-178A software developed to Essential/Level 2 would not be acceptable where DO-178B or DO-178C software Levels A or B are required.
Table 1 - Assurance Level Relationships DO-178B/C Software Level Assigned by the System Safety Assessment Legacy System Software Level per DO-178/DO-178A Legacy System Software Level per DO-178B Critical/ Level 1 Essential/ Level 2 Non- Essential/ Level 3
A B C D A B * C D * For legacy system software developed using DO-178 or DO-178A at Essential/Level 2 that was previously shown to be equivalent to DO- 178B Level B per Order 8110.49, paragraph 10-3.a.(1), equivalency remains valid for the new project.
(a) If your legacy system software was developed using DO-178 or DO-178A, and the software level is not acceptable, upgrade the software development baseline using DO-178C, section 12.1.4.
(b) If your legacy system software was developed using DO-178B, and the software level is not acceptable, upgrade the software development baseline using DO-178B or DO-178C, section 12.1.4.
(3) If the usage history of your legacy system software is acceptable, the software level has a “” entry in Table 1 (or the baseline has been upgraded appropriately), and modifications to the software are not required, then the original approval may serve as the basis for the software in the installation approval of the proposed system. If you upgraded the software 7
development baseline using DO-178C and you want to declare your software as having satisfied DO-178C, you should update your processes and procedures, including tool qualification processes, to DO-178C. However, you cannot declare your unmodified tools as having satisfied DO-178C. All subsequent modifications are to be made using your processes and procedures that satisfy DO-178C.
(4) If modifications to the software are required, conduct a software change impact analysis (CIA) to determine the potential impact of the modifications on continued operational safety of the aircraft on which the system and software components are to be installed. The CIA should 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 comply with the identified means of compliance.
(a) Identify the software changes to be incorporated and perform a CIA consisting of one or more analyses associated with the software change as identified in DO-178C, section
12.1. Analyses of the change should be made as applicable.
(b) Conduct the verification as indicated by the CIA.
(c) Summarize the results of the analysis in the Software Accomplishment Summary (SAS).
(5) If new software tools or modifications to tools are needed, refer to paragraph 10 of this AC to determine tool qualification requirements.
(6) If you upgraded the software baseline to DO-178C, or as an alternative to modifying your legacy system software using DO-178, DO-178A, or DO-178B, make all modifications to the software using DO-178C, section 12.1. If you want to declare your software as having satisfied DO-178C, you should accomplish all software modifications using DO-178C and update your processes and procedures, including tool qualification processes, to DO-178C. Your declaration applies to both modified and unmodified software and is valid even if you use unmodified tools that have not been qualified using DO-178C. However, you cannot declare your unmodified tools as having satisfied DO-178C. All subsequent modifications are to be made using your processes and procedures that satisfy DO-178C.
(7) You may make modifications to legacy system software using the version of DO- 178 (i.e. DO-178, DO-178A, or DO-178B) that was used for the original software approval, provided all of the following conditions are met:
(a) You do not introduce model based development, object oriented technology, or formal methods for the first time during the modification;
(b) You have maintained, and can still use, the software plans, processes, and life cycle environment, including process improvements and changes resulting from subparagraph
9.b.(2); and 8
(c) You do not introduce parameter data item files, as defined in DO-178C, for the first time during the modification.
(8) If all of the conditions in subparagraph 9.b.(7) are satisfied, you may accomplish all modifications to the software using the same DO-178( ) version as the original approval.
However, you may not declare your software as having satisfied DO-178C.
(9) If any of the conditions in subparagraph 9.b.(7) are not satisfied, accomplish all modifications to the software using DO-178C, section 12.1. If you want to declare your software as having satisfied DO-178C, you should accomplish all software modifications using DO-178C and update your processes and procedures, including tool qualification processes, to DO-178C.
Your declaration applies to both modified and unmodified software and is valid even if you use unmodified tools that have not been qualified using DO-178C. However, you cannot declare your unmodified tools as having satisfied DO-178C. All subsequent modifications are to be made using your processes and procedures that satisfy DO-178C.
10. Tool Qualification. DO-178C, section 12.2, and DO-330 provide an acceptable method for tool qualification. DO-330 contains its own complete set of objectives, activities, and life cycle data for tool qualification.
a. If your legacy system software was previously approved using DO-178 or DO-178A, and you intend to use a new or modified tool for modifications to the legacy system software, use the criteria of DO-178C, section 12.2, to determine if tool qualification is needed. If you need to qualify the tool, use the software level assigned by the system safety assessment for determining the required TQL, and use DO-330 for the applicable objectives, activities, guidance, and life cycle data. You may declare your qualified tool as having satisfied DO-330 and not the legacy system software as having satisfied DO-178C.
b. If your legacy system software was previously approved using DO-178B, and you do not intend to claim compliance to DO-178C, you can use your DO-178B tool qualification processes for qualifying new or modified tools in support of modifications to DO-178B legacy system software.
c. If your legacy system software was previously approved using DO-178B, you intend to claim compliance to DO-178C, and you have DO-178B legacy tools that need to be qualified, follow the guidance of this subparagraph.
(1) DO-178C establishes five levels of tool qualification based on the tool use and its potential impact in the software life cycle processes (see DO-178C, section 12.2.2 and Table 12-
1). However, DO-178C does not address the use of tools previously qualified to the DO-178B criteria. For a tool previously qualified as a DO-178B development tool or verification tool, use Table 2 (below) to determine the correlation between the DO-178B tool qualification type and DO-178C tool criteria and tool qualification levels (TQLs).
Table 2 - Correlation Between DO-178B Tool Qualification Type and DO-178C Tool Criteria/TQL
DO-178B Tool Qualification Type Software Level DO-178C Tool Criteria DO-178C/DO- 330 TQL Development A 1 TQL-1 Development B 1 TQL-2 Development C 1 TQL-3 Development D 1 TQL-4 Verification A, B 2 TQL-4 Verification C, D 2 TQL-5 Verification All 3 TQL-5
(2) Development Tools Previously Qualified Using DO-178B.
(a) If the DO-178B software level assigned to the tool correlates with or exceeds the required TQL established by DO-178C, you may continue to use your DO-178B tool qualification processes for a DO-178C project or use DO-330.
(i) If there are changes to the tool’s operational environment, refer to DO- 330, section 11.2.2, for guidance on performing an analysis to determine what activities need to be performed or re-performed.
(ii) If there are changes to the tool, refer to DO-330, section 11.2.3, for conducting a tool change impact analysis. Use the tool change impact analysis to determine the potential impact of the change on the generated code and the needed re-verification activities.
(b) If the DO-178B software level assigned to the tool does not satisfy the required TQL for a DO-178C project, you should re-qualify the tool using DO-330.
(c) You may declare your tool as having satisfied DO-330 if all changes to the tool and your tool qualification processes satisfy DO-330.
(3) Verification Tools Previously Qualified Using DO-178B.
(a) If the tool qualification level required for a DO-178C project is TQL5, and your verification tool was previously qualified using DO-178B:
(i) You may continue to use your DO-178B tool qualification process.
(ii) If there are changes to the tool or the tool’s operational environment, you should conduct a tool change impact analysis and re-verify the tool using your DO-178B tool qualification processes or re-qualify the tool using DO-330.
(b) If the tool qualification level required for a DO-178C project is TQL4, you should re-qualify your verification tool using DO-330.
(c) You may declare your tool as having satisfied DO-330 if all changes to the tool and your tool qualification processes satisfy DO-330.
11. Related Regulatory, Advisory, and Industry Material.
a. 14 CFR Applicable Sections. 14 CFR parts 21, 23, 25, 27, 29, 33, and 35.
b. FAA ACs.
(1) AC 20-170, Integrated Modular Avionics Development, Verification, Integration and Approval using RTCA DO-297 and Technical Standard Order C-153.
(2) AC 20-171, Alternatives to RTCA/DO-178B for Software in Airborne Systems and Equipment.
(3) AC 20-174, Development of Civil Aircraft and Systems.
(4) AC 21-50, Installation of TSOA Articles and LODA Appliances.
(5) AC 23.1309-1, System Safety Analysis and Assessment for Part 23 Airplanes.
(6) AC 25.1309-1, System Design and Analysis.
(7) AC 27-1309, Equipment, Systems, and Installations, (included in AC 27-1, Certification of Normal Category Rotorcraft).
(8) AC 29-1309, Equipment, Systems, and Installations, (included in AC 29-2, Certification of Transport Category Rotorcraft).
(9) AC 33.28-1, Compliance Criteria for 14 CFR § 33.28, Aircraft Engines, Electrical and Electronic Engine Control Systems.
(10) AC 33.28-2, Guidance Material for 14 CFR 33.28, Reciprocating Engines, Electrical and Electronic Engine Control Systems.
(11) AC 35.23-1, Guidance Material for 14 CFR 35.23, Propeller Control Systems.
c. Industry Documents.
(1) SAE International Aerospace Recommended Practice (ARP) 4754A, Guidelines for Development of Civil Aircraft and Systems, dated December 21, 2010.
(2) RTCA DO-178, Software Considerations in Airborne Systems and Equipment Certification, dated January 1982 (no longer in print).
(3) RTCA DO-178A, Software Considerations in Airborne Systems and Equipment Certification, dated March 1985 (no longer in print).
(4) RTCA DO-178B, Software Considerations in Airborne Systems and Equipment Certification, dated December 1, 1992.
(5) RTCA DO-178C, Software Considerations in Airborne Systems and Equipment Certification, dated December 13, 2011.
(6) RTCA DO-248C, Supporting Information for DO-178C and DO-278A, dated December 13, 2011.
(7) RTCA DO-297, Integrated Modular Avionics (IMA) Development Guidance and Certification Considerations, dated November 8, 2005.
(8) RTCA DO-330, Software Tool Qualification Considerations, dated December 13, 2011.
(9) RTCA DO-331, Model-Based Development and Verification Supplement to DO- 178C and DO-278A, dated December 13, 2011.
(10) RTCA DO-332, Object-Oriented Technology and Related Techniques Supplement to DO-178C and DO-278A, dated December 13, 2011.
(11) RTCA DO-333, Formal Methods Supplement to DO-178C and DO-278A, dated December 13, 2011.
12. Where to Get Referenced Documents.
a. Order SAE documents from SAE World Headquarters, 400 Commonwealth Drive, Warrendale, PA, 15096-0001, telephone (724) 776-4970, fax (724) 776-0790. You can also order copies through the SAE website at www.sae.org.
b. Order copies of RTCA documents from RTCA, Inc., 1150 18th Street, NW, Suite 910 Washington, DC 20036, telephone (202) 833-9339, fax (202) 833-9434. You can also order copies on the RTCA website at www.rtca.org.
c. Order copies of 14 CFR part 21, Subpart O, Technical Standard Order Authorizations, from the Superintendent of Documents, Government Printing Office, P.O. Box 37154, Pittsburgh, PA 15250-7954, telephone (202) 512-1800, fax (202) 512-2250. You can also order 12