AC 20-148

AC 20-148

REUSABLE

SOFTWARE

COMPONENTS

December 7, 2004

CONTENTS Paragraph Title Page

1. Purpose1

2. Motivation for this Guidance1

3. Document Overview1

4. General Guidelines for Getting FAA to Accept an RSC2

5. Guidelines for the RSC Developer4

6. Data the RSC Developer Must Supply to the RSC Integrator or Applicant7

7. Guidelines for the Integrator and Applicant Using the RSC9

8. Expectations from Certification Authorities on the First Use of an RSC11

9. The RSC Acceptance Letter12

10. Expectations from Certification Authorities on the Subsequent Use of an

Accepted RSC13

11. Common Software Reuse Issues14

12. Changes to Reusable Software Components18

13. Concurrent Use of an RSC21

14. Related Documents22

Appendix 1. Definitions of Terms (3 pages) Appendix 2. Acronyms (1 page) Appendix 3. Sample Format for RSC Developer’s Table (1 page) Page i (and ii)

1. PURPOSE.

a. This advisory circular (AC) provides one acceptable means of compliance, but not the only means, for reusable software component (RSC) developers, integrators, and applicants to gain:

• The Federal Aviation Administration’s (FAA) “acceptance” of a software component that may be only a part of an airborne system’s software applications and intended functions.

• Credit for the reuse of a software component in follow-on systems and certification projects, including “full credit” or “partial credit” for compliance to the objectives of RTCA/DO-178B, Software Considerations in Airborne Systems and Equipment Certification.

b. Like all advisory material, this AC is not mandatory and does not constitute a regulation.

Because the means of compliance in this AC is not mandatory, the term “must” applies only to the applicants, integrators, and RSC developers who choose to follow the method in this AC.

2. MOTIVATION FOR THIS GUIDANCE.

a. Because of economic incentives and advances in software component technology, software developers want to develop an RSC that can be integrated into many systems’ target computers and environments with other system software applications, as determined by the integrator or applicant. In these cases, an RSC developer may partially satisfy the applicable RTCA/DO-178B objectives, while the integrator or applicant completes and shows the compliance for the integrated software package, systems aspects, and aircraft certification.

Examples of potential RSCs include software libraries, operating systems, and communication protocols.

b. The guidance in this AC ensures that systems using RSCs meet all applicable RTCA/DO-178B objectives.

NOTE: The reuse concept in this AC may apply to verification and development tools. Applicants and tool developers must discuss with the FAA the details of each reusable tool qualification project.

Because tools differ from airborne software, there are other concerns to address when trying to reuse tool qualification data. The FAA plans to address tool reuse in future guidance.

3. DOCUMENT OVERVIEW.

a. Paragraphs 1 through 3 explain the purpose of this AC, discuss the motivation for the guidance, and provide a document overview.

b. Paragraph 4 provides general guidelines for receiving FAA acceptance of an RSC.

c. Paragraphs 5 through 7 guide the RSC developers, integrators, and applicants on developing or using an RSC.

d. Paragraphs 8 through 10 provide typical activities the RSC developers, integrators, and applicants can expect from the FAA for the first acceptance of an RSC and its subsequent use.

e. Paragraph 11 discusses common issues to address when developing and using RSCs.

These issues may affect multiple RTCA/DO-178B objectives. Paragraph 11 is not an exhaustive list of issues that may arise, since each project will have its own specific issues.

f. Paragraph 12 addresses changes to an RSC.

g. Paragraph 13 considers concurrent uses of an RSC.

h. Paragraph 14 lists FAA and industry documents that guide how to show an RSC complies with regulations for software components.

i. Appendix 1 defines the terms used in this AC. Please review this appendix before reading the AC.

j. Appendix 2 lists the acronyms used in this AC.

k. Appendix 3 provides a sample format for an RSC developer to document RTCA/DO- 178B credit.

4. GENERAL GUIDELINES FOR RECEIVING FAA ACCEPTANCE OF AN RSC.

a. The FAA may grant acceptance for an RSC after: (i) all stakeholders comply with this AC and (ii) the FAA (or authorized designee) does not identify any installation, safety, operational, functional, or performance concerns. The term “stakeholders” means the applicant, integrator, RSC developer, and certification authority. To show acceptance for an RSC, the FAA will issue an RSC acceptance letter. The FAA will not write the letter until it grants a certification or authorization for a product or equipment using the RSC. If the RSC is unchanged and meets the limitations in the RSC acceptance letter, it may be reused without additional FAA review of the RSC data. This can only happen when no safety, installation, operational, functional, or performance concerns are identified in the subsequent uses.

b. This AC requires that an RSC being considered for acceptance has its own set of software life cycle data. This AC applies to the “acceptance” of an RSC to support the approval of airborne systems and equipment. Since an RSC is integrated with other systems’ software, the RSC must comply with the applicable regulations, guidance, and RTCA/DO-178B objectives.

c. The FAA will grant acceptance for an RSC as part of the approval for type certificates (TC), supplemental type certificates (STC), amended supplemental type certificates (ASTC), amended type certificates (ATC), and technical standard order (TSO) authorizations. For TSO authorized articles that are highly integrated into the aircraft or that have aircraft dependencies, the FAA typically will not grant the RSC acceptance letter until it grants installation approval to the TSO authorized article and the RSC. This is necessary because of the aircraft system’s Page 2

complexity and aircraft-specific dependencies on installed systems and equipment. The FAA grants installation approval for a TSO authorized article as part of a TC, ATC, STC, or ASTC.

d. The first acceptance of an RSC must be performed during a project (such as a TC, ATC, STC, ASTC, or TSO authorization project). Stakeholders may need to provide extra resources.

Later acceptance of the RSC for a different system or project will likely require less effort and resources, if stakeholders follow the guidance in this AC.

e. This reuse guidance applies only when all stakeholders agree that the software component is reusable. The RSC Plan for Software Aspects of Certification (PSAC) and the first applicant’s system-level PSAC must document that stakeholders agree on the proposed means of showing the RSC compliance with this AC. Both plans also help define the communication channels and roles among stakeholders. Agreeing on the reuse is important because the first applicant will likely use more resources to qualify the component as reusable. If there is no agreement, then stakeholders should follow the traditional approach to software development and approval for all software in the system (see paragraph 5 of this AC).

f. Each RSC developer’s project will have different limitations, needs, and issues. For example, one developer may package the software life cycle data so the data fully satisfy a particular objective of RTCA/DO-178B. Another RSC developer may only partially satisfy that same objective. This may be due to some project-specific issues, or more coordination with the integrator to add to the RSC developer’s efforts. Paragraphs 5 through 7 of this AC guide the RSC developer, integrator, and applicant. The guidelines are flexible enough to satisfy the multiple needs of the RSC developer, integrator, and applicant. However, the guidelines are also detailed enough to ensure that the RSC developer, integrator, and applicant address relevant certification, compliance, and safety issues.

g. Applicants must submit compliance data, coordinate and communicate with the FAA, and serve as the certification liaison for the project. However, the certification authority and the RSC developer (with the applicant’s involvement) may need to communicate about the reuse aspects of the project.

h. Acceptance of an RSC for one project does not guarantee acceptance on a later project.

Applicants must consider installation, safety, operational, functional, and performance issues for each project. If concerns arise in any of these areas, the FAA may need to reassess RSC life cycle data. Also, applicants must address compliance to all applicable RTCA/DO-178B objectives, guidance, and regulations relevant to their project.

i. Although the FAA coordinated this AC with international certification authorities, international programs or approvals may require activities not addressed in this AC. Applicants should closely coordinate international projects with all applicable certification authorities.

j. The integrator and applicant should be aware that:

(1) An RSC is unlikely to satisfy all objectives of RTCA/DO-178B.

(2) The integrator or applicant may need to validate the RSC developer claims.

(3) The integrator or applicant may need to provide additional resources to show compliance to RTCA/DO-178B objectives for systems containing RSCs.

(4) The communication paths and division of responsibilities can be complex, when using an RSC.

(5) Other regulations, guidance, and agreements – beyond RTCA/DO-178B – may apply to their system and its aircraft installation approval. These may depend on the date of application for the certification; the system they are proposing; the introduction of novel design, technology, or methods; or other factors. The applicant must show that all components of their system, including RSCs, comply with all applicable regulations.

k. The FAA recommends that the RSC developer, integrator, and applicant use RTCA/DO-178B as the means of compliance for the software aspects of the initial approval or future certification approvals of systems containing RSCs. As described in paragraph 14b of this AC, if an alternate means is proposed, this AC may not apply.

5. GUIDELINES FOR THE RSC DEVELOPER. Traditionally, RSC developers provided one of two ways to show that their RSC complied with RTCA/DO-178B:

• By resubmitting the RSC software life cycle data and repeating the work for each system’s application; or

• By providing traceability through the TC, ATC, STC, ASTC, or TSO approval back to the desired data, and justifying the validity of their processes and data from the original approval basis to the new approval basis for each system.

Before issuance of this AC, there were no procedures for RSC developers to transfer their accepted data directly from one project to the next and across company boundaries. This AC addresses the reuse of software components and software life cycle data across company or division boundaries. The RSC developer must do the following:

a. Produce a PSAC for the RSC as early as possible in the project. The RSC PSAC must:

(1) Include the information in Section 11.1 of RTCA/DO-178B;

(2) Detail the RSC developer’s plans for satisfying each applicable RTCA/DO-178B objective;

(3) Identify which objectives the RSC developer will not satisfy, and which objectives they will partially satisfy;

(4) Clearly state the RSC developer’s agreement to develop the RSC for reuse in future projects;

(5) State the intent to comply with this AC;

(6) Define the failure conditions, safety features, protection mechanisms, architecture, limitations, software levels, interface specifications, and intended use of the RSC; and

(7) Describe the proposed certification liaison process (including communication and coordination focal points) to all involved stakeholders.

b. Consider and address, as applicable, the common reuse issues in paragraph 11 of this AC.

c. For each RTCA/DO-178B objective applicable to the software level, document in the RSC PSAC the information in paragraphs 5d(1) through 5d(4). Include enough detail to obtain certification authority concurrence and to enable the integrator or applicant to use the RSC. The RSC developer may include this information in a table, with columns for the following (see a sample format in appendix 3):

• RTCA/DO-178B objective reference;

• RTCA/DO-178B objective description;

• Amount of credit being sought (full, partial, or no credit);

• Assumptions;

• Means of compliance; and

• Remaining activities the integrator or applicant must complete.

d. List preliminary information in the RSC PSAC, since resource-specific, target computerspecific, and system-specific issues may be uncertain early in the project. Update this information in RSC PSAC revisions and the RSC Software Accomplishment Summary (SAS), when the RSC is completed. Some reuse details may not be finalized until the end of the project.

RSC developers must thoroughly document the following information for each applicable RTCA/DO-178B objective for review by certification authorities (and authorized designees) and for use by integrators or applicants:

(1) Credit Being Sought for the Objective. The RSC PSAC or referenced document must specify if the RSC developer is seeking full, partial, or no credit for the objective. Full credit means being able to satisfy an objective completely using the RSC data package, and to show that all associated assumptions are valid. If integrators need to do more, then they cannot claim full credit. This is true even when the RSC developer fully specifies what integrators must do. Also, if integrators or applicants do not satisfy the assumptions, they cannot get credit.

(2) RSC Developer’s Assumptions on How the Integrators or Applicants Will Use the RSC. The RSC developer must provide enough justification to ensure that the original acceptance is valid if the assumptions are satisfied. For example, the RSC developer may assume the source code, compiler type, and compiler options will remain the same. However, if integrators or applicants do not meet these assumptions, they cannot get credit for the applicable RTCA/DO-178B objective.

(3) Means of Compliance for the Objective. The RSC PSAC and SAS must document what software life cycle data support compliance for each applicable objective. As Page 5

evidence of compliance, the RSC PSAC and SAS must provide document titles, version numbers, and/or a description of the data.

(4) Activities Remaining for the Integrator or Applicant. The RSC PSAC and SAS must document what an applicant or integrator must do to satisfy any partial or unsatisfied objectives fully.

e. Document the following safety-related items in the RSC PSAC and SAS:

(1) The software levels for the RSC.

(2) An analysis of all interfaces and settable parameters. The analysis should describe the functional and performance effects of these parameters and interfaces on the user. The analysis should document required actions by the user to ensure proper operation.

(3) Architectural and design features supporting any portion of the safety analysis, partitioning, or other protection strategies.

(4) Any safety, operational, functional, or performance assumptions that support the use of the RSC (see paragraph 5f).

(5) Any new or novel concepts, methods, and technologies for developing the RSC.

f. Produce an analysis of the RSC’s behavior that could adversely affect the users’ implementation (for example, vulnerabilities, partitioning requirements, hardware failure effects, requirements for redundancy, data latency, and design constraints for correct RSC operation).

The analysis may support the integrator’s or applicant’s safety analysis.

g. Get agreement (as early as possible) from all stakeholders for the first application. Do this by coordinating the following with the certification authority, designees (if delegated), and the applicant or integrator:

(1) The RSC PSAC;

(2) Any other RSC plans (for example, Software Development Plan (SDP), Software Verification Plan (SVP), Software Quality Assurance Plan (SQAP), and Software Configuration Management Plan (SCMP)); and

(3) Software development standards (that is, requirements, design, and coding standards).

h. Develop the RSC per the approved plans. As previously stated, the RSC developer must produce the RTCA/DO-178B software life cycle data and documentation in paragraph 6 of this AC (such as plans, standards, development data, verification data, quality assurance records, and configuration management records).

i. Inform the certification authority, designees (if delegated), integrator, and applicant of development progress and any deviations from plans, to allow for timely reviews and adjustments as necessary.

j. Submit the RSC Software Configuration Index (SCI) and the RSC SAS to the certification authority through the project applicant, when completed. The RSC SAS must include or refer to the software life cycle data in RTCA/DO-178B, Section 11. Additionally, the RSC SAS must show how the RSC complies with this AC.

6. DATA THE RSC DEVELOPER MUST SUPPLY TO THE RSC INTEGRATOR OR APPLICANT. The RSC developer must supply the appropriate software life cycle data to the integrator or applicant. These data will support acceptance of the RSC in the context of the software aspects of certification of the airborne systems using the RSC. RSC developers must supply the data in paragraphs 6a through 6i to the RSC integrator or applicant, and to the certification authority on request, unless they use a data/software escrow approach per paragraph 6j(2) of this AC:

a. The type design data in Section 9.4 of RTCA/DO-178B for the RSC (that is, software requirements data, design description, source code, executable object code, SCI, and SAS).

b. The RSC PSAC, which identifies the credit sought for each RTCA/DO-178B objective.

c. Interface description data (for example, interface control document and porting guide).

The interface description data include any hardware and software resource requirements (such as timing and memory) and applicable analyses, verification procedures, and verification cases.

d. Installation or integration procedures and limitations, to ensure the RSC will be properly used, integrated, and installed. They must be detailed enough to identify unique aspects of the installation or integration. The limitations and procedures must include, as a minimum:

(1) Equipment specifications for proper operation and performance of the RSC, including verification activities the integrator or applicant must perform to ensure the equipment meets specifications;

(2) A list of any RSC subcomponents, as defined by RTCA/DO-178B, Section 11.16;

and

(3) Instructions for periodic maintenance and/or calibration needed for continued airworthiness after installing the software on the target environment.

e. Data to support the integrator’s or applicant’s completion of partially satisfied or unsatisfied objectives. As an example, if seeking partial credit for objective 1 of RTCA/DO-178B, Table A-1, the RSC developer clearly defines to the integrator or applicant what that partial credit entails. Also, the RSC developer defines what the integrator or applicant needs to do to gain full credit for the installation. The data supporting any “full” or “partial” credit must also be available to the integrator or applicant.

f. Software verification results, verification cases, and verification procedures, especially for verification activities that the integrator or applicant must repeat for the integrated software installed on the target computer environment. Examples of verification activities the integrator or applicant carries out include:

• Data coupling analysis;

• Control coupling analysis;

• Timing analysis;

• Memory analysis;

• Software integration testing;

• Hardware-software integration testing; and

• Robustness testing of RSC functions, including safety and protection features.

g. The verification data should include a list of test cases and procedures affected by any settable parameters. The integrator or applicant should consider the total requirements for system and subsystem testing. Within this context the integrator or applicant should address:

(1) Applicable credit for reusable tests of the RSC.

(2) Retests where new settings or parameters may affect the requirements, code, function, performance, or protection features.

(3) Analyses of data coupling and control coupling of the RSC, including guidance for the integrator or applicant. This guidance helps with the data coupling analysis and control coupling analysis of the RSC integrated with other airborne software components of the system.

(4) Development of new test cases and procedures to complete all tests and test coverage objectives, including guidance for the integrator or applicant. The guidance will help show normal range and robustness testing and test coverage objectives for the entire integrated airborne software.

h. Open problem reports on the RSC and analysis of any potential functional, operational, performance, and safety effects. The RSC developer should document this information in the RSC SAS, and – if the developer knows this information at the beginning of the project – include it in the RSC PSAC.

i. The RSC developer must develop a data sheet for the RSC and submit it to the FAA.

The integrator or applicant may attach the data sheet to the FAA acceptance letter. This data sheet must concisely summarize:

• RSC functions;

• Limitations;

• Analysis of potential interface safety concerns;

• Assumptions;

• Configuration;

• Supporting data;

• Open problem reports;

• Software characteristics; and

• Other relevant information that supports the integrator’s or applicant’s use of the RSC.

j. RSC developers must also address the following data-related items (although the items may not result in submittals):

(1) Any RTCA/DO-178B software life cycle data not listed above – but used for software development and approval – must be available to the applicant, integrator, and certification authority (for example, Software Quality Assurance and Software Configuration Management records).

(2) Regardless of any legal and proprietary issues and agreements about the delivery of software life cycle data between the applicant and the RSC developer, the data must be available for certification authority (and authorized designee) review and inspection. The RSC developer may set up a process (such as a data or software escrow) for making some data (such as design description or source code) available to the applicant, without supplying that data to the applicant. All stakeholders must agree on the process of escrowing a subset of the data in paragraphs 6a through 6h, and document the process in the RSC PSAC and system-level PSAC.

All data must be accessible to the certification authority (and authorized designees) to determine compliance or any safety or operational problems with the target system (see 14 CFR § 21.277).

The data may also need to be available to the applicant, if the target system or RSC requires modification (see 14 CFR § 21.301 through § 21.305, and FAA Order 8110.4).

(3) The RSC developer must identify and maintain data to support changes to the RSC.

For example, if the developer goes out of business, these data will support continued airworthiness and operational safety. Title 14 CFR part 21, Certification Procedures for Products and Parts (as supplemented by FAA Order 8110.4, Type Certification (Chapters 2 and

3)), discusses how to issue and preserve type design data for maintaining the continued airworthiness of aircraft products.

(4) The RSC developer must retain and maintain a list of all integrators and applicants buying or using their components to support continued airworthiness across multiple products.

The RSC developer, integrator, and applicant must set up a process to share in-service problem reports that support operators required to comply with 14 CFR § 21.3, and that support paragraphs 7q through 7s of this AC. The RSC developer and users must develop an agreement to support continued airworthiness of the systems using the RSC.

7. GUIDELINES FOR THE INTEGRATOR AND APPLICANT USING THE RSC.

Sometimes the integrator and applicant are the same company or organization, and sometimes they are separate entities. Below are the guidelines for the integrator and applicant. The applicant ensures these items are completed, even if an integrator performs some tasks. The applicant or integrator must perform the following for each RSC integrated into their system application:

a. Integrate the RSC developer’s plans, data, limitations, compliance statement, mapping to RTCA/DO-178B objectives, software approval approach, and other relevant information (such as RSC acceptance letter and data sheet) into their own software life cycle data.

b. Specify the software life cycle data that RSC developers must provide to support their project and continued airworthiness. See a list of these data in paragraph 6 of this AC.

c. Produce a system-level PSAC (or equivalent certification plan) for the target system, including the information in RTCA/DO-178B, Section 11.1. The system-level PSAC must include the integrator’s or applicant’s plans to address compliance with all RTCA/DO-178B objectives, regulations, and guidance for the RSC and other software components of the target system. Also, the system-level PSAC must clearly state the agreement that the RSC was developed with the intent to be reusable in other projects and that the applicant or integrator intends to comply with this AC.

d. Produce other system-level software plans (such as SDP, SCMP, SVP, and SQAP) for their target system. Each plan must address the RSC integration and other software components used. For example, the system-level SVP must cover the overall software verification program, plus any verification required to integrate the RSC and other components, and the credit proposed for the RSC developer’s verification.

e. Evaluate the safety, operational, performance, and functional impacts of the issues in the RSC developer’s PSAC, SAS, and safety analysis data; and determine the applicability and severity of these impacts on the specific application and system.

f. Determine any other impacts for the specific application.

g. Propose risk mitigation, system architectural design features, protection mechanisms, and other assurance methods to address those risks.

h. Address all safety, operational, functional, and performance issues during the development of the system.

i. Coordinate all plans and standards (as needed) with the certification authority and designees (if delegated) to get agreement on the project.

j. Follow the approved plans and standards. Coordinate any deviations from the plans or standards with the certification authority (and authorized designees) before implementation.

k. Analyze open problem reports on the RSC (including development problem reports and in-service problem reports), other software components, hardware, and the system. Ensure there are no safety, operational, functional, or performance effects from the RSC or other components in the specific application and system.

l. Validate that the assumptions the RSC developer made in the RSC SAS for RTCA/DO-178B objective credit are met. Show how the credit applies to the integrated system that uses the RSC, and complete the RTCA/DO-178B objectives identified as “partial” or “no” Page 10