credit in the RSC SAS. The applicant must ensure compliance to all applicable RTCA/DO-178B objectives for the integrated RSC.
m. Evaluate and address the common reuse issues in paragraph 11 of this AC for each particular application. Additionally, address any project-specific reuse issues.
n. Validate and verify the throughput, timing, memory usage, resource usage, and other resource items of the RSC and other installed software components for the specific target environment.
o. Inform the certification authority and designees (if applicable) of the project status and approved plan deviations. This communication supports timely reviews by the certification authority or designees (if applicable) and approval of changed plans.
p. Submit all SCIs, SASs, and other required software life cycle data to the certification authority (that is, submit both system-level and RSC data). The system-level SAS must include the information in Section 11.20 of RTCA/DO-178B for the system’s software. Also, the system-level SAS must include a description of how the integrator or applicant for the entire integrated system completely satisfied RTCA/DO-178B objectives that the RSC developer did not fully meet. The system-level SCI and SAS must identify:
• The RSC is in the applicant’s project;
• The configuration (including part and version numbers) of the RSC;
• The configuration (including part and version numbers) of other software components; and
• The software life cycle data configuration to support the RSC and other software components in the system.
q. Report in-service problems with the RSC to the RSC developer and the certification authority who granted the acceptance letter.
r. For subsequent use of the RSC, investigate the in-service experience related to the RSC to ensure there have been no safety-related problems connected with the RSC. For this purpose (see paragraph 6j(4)), evaluate relevant information, such as problem reports available to the RSC developer. The RSC developer and the certification authorities must know about all safetyrelated in-service experiences involving the RSC.
s. Establish a legal agreement with the RSC developer about continued airworthiness support, data ownership, and so on, to meet the regulations.
8. EXPECTATIONS FROM CERTIFICATION AUTHORITIES ON THE FIRST USE OF AN RSC. The RSC developer, integrator, and applicant should work closely with the certification authority throughout the RSC development and integration. To gain acceptance of an RSC in its first system installation, the certification authority will typically:
a. Coordinate and work closely with the applicant, integrator, and RSC developer to ensure they comply with this AC and other applicable regulations or guidance.
b. Involve directorate personnel, headquarters personnel, technical specialists, and chief scientific and technical advisors (CSTA), as needed, to address policy and technical issues in the project.
c. Review the RSC developer’s, applicant’s, and integrator’s plans to ensure the applicable RTCA/DO-178B objectives, regulations, and guidance will be satisfied.
d. Perform on-site or desk reviews of the software life cycle data and the ability of the RSC developer, applicant, and integrator, as needed, to ensure compliance to the applicable RTCA/DO-178B objectives, guidance, and regulations.
e. Ensure the applicant and RSC developer establish a process to address any continued airworthiness and in-service problems (see paragraphs 6j(4), 7q, 7r, 7s, and 10h of this AC).
f. Approve data from the applicant, integrator, and RSC developer (as in a typical software program) for the system software, when the stakeholders satisfactorily complete their development and compliance activities. The approval will include approval of the data and software escrow processes, where applicable.
9. THE RSC ACCEPTANCE LETTER. If this AC is followed, upon successful certification of the product or authorization of the equipment using the RSC, the FAA will write an acceptance letter for the RSC and will submit it to the RSC developer. The certification authority will provide a copy to the applicant or integrator. This letter documents the initial acceptance of the RSC and its suitability for applicants or integrators to use in other certification projects. The acceptance letter typically includes:
a. The RSC document numbers and revision levels approved, and a general description of the RSC functionality and target environment. Examples of RSC document numbers and revision levels include the SCI number and revision; the SAS number and revision; and any configuration information not included in the SCI.
b. The RSC developer’s name and contact information.
c. The name and contact information of the original RSC applicant or integrator, the airborne system and environment, and other relevant information about the initial acceptance of the RSC.
d. Assumptions the RSC developer made during the acceptance – typically done by including a reference to the RSC developer’s SAS (or other appropriate data). The referenced document must include assumptions for each applicable RTCA/DO-178B objective. The assumptions must be detailed enough that other certification authorities, RSC integrators, and applicants could apply the information to later projects.
e. Summary of technical or policy issues that arose during the initial acceptance and how those issues were addressed.
f. Summary of extra activities that the integrator and applicant performed to ensure the RSC meets requirements for the initial approval, including system bench and aircraft testing.
g. Contact information for the certification office that will address questions about the RSC acceptance and subsequent reuse.
h. Software level of the RSC, any RSC limitations, and known installation, safety, operational, functional, or performance issues of the RSC.
i. RSC data sheet, as described in paragraph 6i of this AC. The certification authority may attach a copy of the RSC data sheet to the acceptance letter.
j. Emphasis that acceptance of the RSC in one project is not approval in any other project.
Subsequent users of the RSC must evaluate installation, safety, operational, functional, and performance aspects of the RSC in their application. Also, subsequent users of the RSC must evaluate complete compliance to all applicable RTCA/DO-178B objectives, regulations, and guidance for the RSC and other components in their system.
NOTE: Certification authorities may encourage RSC developers to document some or all of the information in paragraphs 9a through 9j in their data sheet or RSC SAS. If RSC developers use this approach, then the certification authority can simply refer to the data sheet or RSC SAS (number, title, and revision number) in the acceptance letter.
In either case, the RSC developer must supply the data sheet and RSC SAS to subsequent RSC users (applicants or integrators) per paragraph 6 of this AC.
10. EXPECTATIONS FROM THE CERTIFICATION AUTHORITIES ON THE SUBSEQUENT USE OF AN ACCEPTED RSC. When a previously accepted RSC is submitted for subsequent reuse in another product or project or by another integrator or applicant, the certification authority or the designee (if delegated) will:
a. Review the RSC acceptance letter that documents the initial acceptance. Get this letter from the RSC developer or the certification authority office that originally issued the acceptance.
b. Contact the certification office that performed the first acceptance (as documented in the acceptance letter) to discuss project details and to address any questions or concerns.
c. Coordinate and work closely with applicants or integrators to ensure they follow this AC’s guidelines, address the common reuse issues in paragraph 11 of this AC, and address any other certification issues.
d. Ensure that installation, safety, operational, functional, and performance aspects of the RSC in the specific system have been analyzed and addressed.
e. Involve FAA Directorate personnel, headquarters personnel, technical specialists, or CSTAs, as needed, to address policy and technical issues in the project.
f. Review the integrator’s or applicant’s plans to ensure:
(1) The objectives of RTCA/DO-178B will be satisfied;
(2) Other applicable regulations, guidance, and agreements will be satisfied; and
(3) The assumptions and requirements documented for the RSC and for other software components used in the target system will be satisfied.
g. Perform on-site and desk reviews of the integrator’s or applicant’s data and organization’s ability, as needed. This ensures compliance to the applicable RTCA/DO-178B objectives, regulations, guidance, and approved plans. It also ensures compliance with the assumptions and requirements documented for the RSC and other software components.
h. Evaluate the in-service experience related to the RSC, as described in paragraphs 7q through 7s. Address safety-related in-service experience and continued airworthiness concerns before accepting the new use of the RSC.
i. Accept the applicant’s or integrator’s data for the overall system software after they satisfactorily complete the integration and compliance activities.
j. Inform the original certification authority of later software acceptance, and report any issues that arose during the acceptance.
11. COMMON SOFTWARE REUSE ISSUES. Several issues may affect the reuse of software components. Below are some common issues; this is not an exhaustive list:
a. Requirements definition.
(1) RTCA/DO-178B discusses several types of requirements, including system requirements, safety-related requirements, high-level requirements, low-level requirements, and derived requirements. The RTCA/DO-178B discussion and objectives about requirements were developed with a traditional federated system in mind. In the traditional case, a single manufacturer typically develops and integrates the software. When RSCs and multiple stakeholders become involved in the software assurance process, determining the types and levels of requirements may become more difficult. Therefore, satisfying the RTCA/DO-178B objectives related to requirements requires special attention.
(2) Each RSC developer must establish a plan to satisfy the RTCA/DO-178B objectives related to system, high-level, low-level, and derived requirements. RSC developers will most likely not be able to satisfy RTCA/DO-178B objectives related to traceability and to compliance and consistency with system requirements. They also will most likely not be able to validate RSC derived requirements for the system’s safety assessment process to ensure design decisions do not affect the system safety. This will likely result in more effort for the integrator or applicant.
(3) The RSC developer must clearly document in the RSC PSAC the means of addressing requirements. The integrator or applicant must adhere to those means. In the systemlevel PSAC, the integrator or applicant must clearly document the means of addressing requirements and the system safety assessment. The applicant should also coordinate both PSACs with the appropriate certification authorities as early in the program as possible.
b. Reverification.
(1) When an RSC is reused, the question of how much reverification to perform often arises. Reverification activities depend on the situation (such as same or different processor, same or different compiler, same or different compiler options, and so on). RSC developers should document their overall verification (and reverification) plans in the RSC PSAC. The RSC SVP should provide more details. The RSC PSAC and SVP should have enough detail for the certification authority to determine the approach will address the RTCA/DO-178B verification objectives. The integrator or applicant will also need to address verification objectives in the system-level plans. Some examples of verification objectives the RSC developer cannot typically satisfy and the integrator or applicant must address are:
• Integration;
• Software integration testing;
• Hardware-software integration testing;
• Requirements-based test coverage;
• Timing analysis;
• Memory analysis;
• Stack analysis;
• Data coupling analysis;
• Control coupling analysis;
• Robustness testing;
• Partitioning and other protection mechanisms for integrity validation;
and
• Any installation-specific testing, such as system bench testing, aircraft ground and flight testing, and flight test pilot’s and human factors specialist’s evaluations of flight deck effects.
(2) Some common reverification questions to consider are (not an exhaustive list):
• How much reverification is required if a different compiler type or optimization is used?
• How much reverification is required if a different target environment (microprocessor, memory management unit, timers, memory, input/output devices, databuses, and so on) is used?
• How are data coupling and control coupling analyses performed in the new system for the entire application?
• What reverification or other verification is required to integrate the RSC with other software components into the overall system?
• How much structural coverage analysis should be repeated if the target system changes?
• How much reverification is needed for run-time and compiler libraries?
• If a new target environment is used, what kinds of resource issues exist?
For example, are there non-deterministic, dynamic memory allocation algorithms with the RSC that could create resource issues (such as Page 15
memory and execution time) in the new target environment? If resource issues do exist, how will reverification be carried out?
• If a new target environment is used and structural coverage changes (that is, there are different unreached code sections), how will the unreached code be addressed? How will it be assured deactivated code cannot be inadvertently activated in the new system?
c. Interface. The RSC developer must provide interface data. These data must clearly define what the integrator or applicant must do to ensure the RSC will perform according to its requirements. Typical items included in interface data are (not an exhaustive list):
• Configuration parameters;
• Restrictions on tools;
• Additional verification activities;
• Memory and timing requirements;
• External resources required by the RSC for proper functioning and performance;
• Definition of the communication mechanisms between the RSC (and other software programs) and the communication protocols with hardware components;
• Accessible variables and their characteristics;
• Variables and data required from the system and their characteristics (for example, inputs to RSC);
• Bus and input/output ports and devices; and
• Access mechanisms.
d. Partitioning and Protection. Although partitioning and protection will most likely be a function at the system level, the RSC itself may require some partitioning and protection. For example, some maintenance code may be at a different software level than the operational flight program for the RSC. Sometimes the RSC might have specific protocols that help protect and partition it. The integrator, applicant, and certification authorities should document and evaluate these protocols.
e. Data Coupling and Control Coupling Analyses. The integrator or applicant must:
(1) Address data coupling and control coupling to ensure they have fully identified and verified all potential side effects of data modifications.
(2) Analyze each side effect to ensure it does not adversely affect functionality or performance.
(3) Evaluate how much the RSC and other integrated software and hardware components depend on data and control interchanges. For example, all modifications of RSC data should only occur at defined interfaces where the RSC can fully control the data behavior.
f. Using Qualified Tools. If qualified tools are used to develop or verify the RSC, the RSC developer must consider reuse of those tools during RSC development and acceptance.
Section 12.2 of RTCA/DO-178B and chapter 9 of Order 8110.49 provide more information on the tool qualification process and the supporting documentation.
(1) When qualified tools are used to develop or verify an RSC, the Tool Qualification Plan and the Tool Accomplishment Summary (or PSAC and SAS for verification tools) must document portions of the tool qualification the applicant must complete. For example, test procedures and cases might have some target dependencies, and the integrator or applicant must perform more verification activities.
NOTE: Some developers have found that packaging the qualification data for each tool helps with reuse. For example, each verification tool used with an RSC might have its own Tool Qualification Plan, Tool Operational Requirements, and Tool Accomplishment Summary.
(2) The RSC developer must provide the following tool qualification data to the applicant for all tools used in getting acceptance of the RSC:
(a) Tool plans;
(b) Tool Operational Requirements; and
(c) The Tool Accomplishment Summary. For some verification tools, the RSC SAS may include the Tool Accomplishment Summary.
(3) All tool data not listed in paragraph 11f(2) of this AC must be available for review by the applicant and certification authority (and authorized designees), as needed, to support continued airworthiness.
g. Deactivated Code. Because RSCs often have functions in the initial application that they will not use in the subsequent applications, deactivated code is a common reuse issue. If implemented, the RSC developer must consider deactivated code during the development of the RSC (for example, the RSC user’s guide may define how the user deactivates functions). The applicant or integrator must also consider the approach for implementing deactivated code in their overall system to ensure they comply with RTCA/DO-178B’s guidance on deactivated code. In the life cycle data, the RSC developer – and the applicant or integrator – must clearly identify any information about deactivated code and the associated deactivation mechanisms.
h. Traceability. Several RTCA/DO-178B objectives address the traceability of system requirements, high-level requirements, low-level requirements, derived requirements, code, and test cases and procedures. When multiple stakeholders and multiple components are involved, this traceability becomes more difficult. The integrator or applicant must address and maintain traceability between the RSC, the system software, and the system.
i. Robustness. Since the RSC is developed for various applications, it must be able to anticipate out-of-range data or unexpected input (that is, it must be robust). Stakeholders must document how they plan to address the robustness of the RSC. Developers, integrators, and applicants must verify the robustness through robustness tests, while developing and integrating the RSC.
12. CHANGES TO REUSABLE SOFTWARE COMPONENTS.
a. RSCs will likely change. When an RSC is changed, the original reuse status will no longer apply to the changed component (that is, the acceptance letter cannot be used for the modified RSC). If the stakeholders want to change a previously accepted RSC, they must modify the software component using the guidelines of this AC (see paragraphs 12b through 12f) and RTCA/DO-178B, Section 12.1. They also must reaccept the software component as part of a project.
b. When an RSC is changed, the appropriate stakeholders must perform a change impact analysis to identify the changed and affected aspects of the software. The change impact analysis should follow a defined process. This process should determine the potential impact of the change on continued operational safety of the aircraft and the impact of the change to the previously accepted RSC. The change impact analysis should address the following items, as applicable; this list is not all-inclusive and depends on the product being modified:
(1) Traceability analysis identifies areas the software change could affect. This includes the analysis of affected requirements, design, architecture, code, testing, and analyses, as described below:
(a) Requirements and design analysis identifies the software requirements, software architecture, and safety-related software requirements the change affects. Also, the analysis identifies any other features or functions being implemented in the system, ensures added functions are appropriately verified, and ensures the added functions do not adversely affect existing functions.
(b) Code analysis identifies the software components and interfaces the change affects.
(c) Test procedures and cases analysis identifies specific test procedures and cases that will need to be reexecuted to verify the changes and any potential impacts of the changes. This analysis also identifies and develops new or modified test procedures and cases (for added functionality or previously deficient testing), and ensures the changes do not cause any adverse effects. Regression tests may verify the absence of adverse effects. Perform these tests at a hierarchical level appropriate for the software levels of the changed software.
Examples of regression tests are aircraft flight tests, aircraft ground tests, laboratory system integration tests, simulator tests, bench tests, hardware and software integration tests, and module tests.
(2) Memory margin analysis ensures memory allocation requirements and acceptable margins are maintained.
(3) Timing margin analysis ensures the timing requirements, central processing unit task scheduling requirements, system resource contention characteristics, interface timing requirements, and acceptable timing margins are maintained.
(4) Data flow analysis identifies changes to data flow and coupling between components and ensures there are no adverse impacts.
(5) Control flow analysis identifies changes to the control flow and coupling of components and ensures there are no adverse impacts.
(6) Input/output analysis ensures the changes have not adversely affected the input and output (including bus loading, memory access, and hardware input/output device interfaces) requirements of the product.
(7) Development environment and process analyses identify any changes, which may adversely affect the software application or product (for example, compiler options or versions and optimization change; linker, assembler, and loader instructions or options change;
or software tool change).
(8) Operational characteristics analysis ensures changes (such as changes to gains, filters, limits, data validation, performance, interrupt and exception handling, and fault mitigation) do not result in adverse effects.
(9) Certification maintenance requirements (CMR) analysis determines if new or changed CMRs are necessitated by the software change.
(10) Partitioning or protection analysis ensures the changes do not affect any protective mechanisms incorporated in the design.
c. The change impact analysis should determine if the change to the RSC could adversely affect safe operation of the system or product. The following are examples of areas that could have an adverse impact on installation, safety, operations, functionality, or performance:
(1) Safety-related information is changed. For example:
(a) Previous hazards, identified by the system safety assessment, are changed.
(b) Failure condition categories, identified by the system safety assessment, are changed.
(c) Software levels are changed, particularly if the new software level is higher than the previous level.
(d) Safety-related requirements, identified by the system safety assessment, are changed.
(e) Safety margins are reduced.
(2) Changes to operational or procedural characteristics of the aircraft that could adversely affect flight safety. For example:
(a) Aircraft operational or airworthiness characteristics are changed.
(b) Flight crew procedures are changed.
(c) Pilot workload is increased.
(d) Situational awareness, cautions, warnings, and alerts are changed.
(e) Displayed information for making flight decisions is changed.
(f) Assembly and installation requirements are changed.
(g) Equipment interchangeability or interoperability with other equipment is changed.
(h) CMRs are changed or added.
(3) New functions or features are added to the existing system functions that could adversely affect flight safety or operations.
(4) Processors, interfaces, and other hardware components or the environment are changed in a way they could adversely affect safety, operations, functionality, or performance (see RTCA/DO-178B, Section 12.1.3).
(5) Software life cycle data (requirements, code, and architecture) are significantly changed in a way that could adversely affect safety, operations, functionality, or performance. For example:
(a) Changes to software requirements, design, architecture, and code components (especially those affecting safety-related functions, partitioning, redundancy, or safety monitors).
(b) Changes to code (source, object, and executable object) components that perform a safety-related function or changes to a component providing input to another component that performs a safety-related function. For this AC, a safety-related function is one that could potentially cause or allow a major, hazardous, or catastrophic failure condition to go undetected.
(c) Changes to characteristics of the development environment affecting the executable object code.
(d) Changes to memory allocation requirements so memory margins are adversely affected (for example, less than 5 percent margin remaining).
(e) Changes to timing requirements so timing margins are adversely affected (for example, margins are unpredictable or less than 10 percent margin remains).
(f) Changes to input/output requirements (such as bus loading) so input or output performance is adversely affected (for example, less than 5 percent margin remains).
(g) Data and control coupling characteristics are adversely affected (for example, to the extent more than 50 percent of the coverage analysis must be redone).
(h) Changes to interface characteristics.
d. Also, the following items should be identified in the change impact analysis:
(1) Updates ensure the software changes are incorporated in the appropriate software life cycle data, including requirements, design, architecture, source and object code, and traceability.
(2) Verification activities verify changes and ensure changes do not adversely affect the system. The change impact analysis should cover how to verify changes that could adversely affect safe operation of the system or aircraft, so the changed and unchanged software will continue to satisfy their requirements for safe operation. These verification activities may include reviews, analyses, regression testing, requirements-based testing, robustness testing, flight testing, reevaluation of existing analyses, reexecution of existing tests, and new test procedures and cases (for added functionality or previously deficient testing).
e. When the applicant or integrator changes the RSC without the RSC developer’s assistance, that integrator or applicant becomes responsible for satisfying the applicable RTCA/DO-178B objectives for the RSC and all other software components of the system.
f. The RSC developer, users of the RSC, and the appropriate certification authority must coordinate changes to an RSC that result from an airworthiness directive (AD). Coordination will help determine how the AD applies to other projects. An AD issued on any system containing an RSC may invalidate that RSC as reusable.
13. CONCURRENT USE OF AN RSC.
a. Sometimes an RSC may be developed for use by concurrent projects. The development of the RSC and the multiple applications using the RSC may progress at the same time. In this situation, the RSC developer must create a “Reuse Plan” (or equivalent document) which typically includes:
(1) Known applications and projects that will use the RSC (including the first applicant). Because developers may not know all future users when they write the Reuse Plan, the plan should document plans, procedures, and policies for working with future users and certification authorities.
(2) The schedule for the multiple applications and projects.
(3) Statement of the intent to follow this AC.
(4) A proposed reuse approach, based on this AC’s guidance and the specific project needs. The Reuse Plan should thoroughly address this AC. The reuse approach should also propose a way to use FAA and designee resources efficiently. For example, shared reviews and review reports may help to optimize resources of FAA and applicants.
(5) A list of all data items (with specific configuration identification) being developed for each user.
(6) A summary of which data items will be the same for all integrators or applicants and which data items are user-specific.
(7) An explanation of data items that differ among users. These may not be suitable for reuse.
(8) An approach for managing configuration of the RSC with multiple users. To gain reuse credit, all users must be using the same RSC configuration.
(9) A list of affected applicants and certification offices. (NOTE: Sometimes the list of applicants may be proprietary data that can only be shared with the certification authority.
Therefore, the list of affected applicants may be in a separate document to share with certification authorities only.)
(10) A description of how to enable users to use the product correctly (for example, a user’s guide or interface document).
(11) A description of how to keep the users up-to-date during the development and deployment of the product. For example, describe how to inform the integrators or applicants of problems with the RSC, potential safety issues, changes to RSC requirements and the user’s guide, and other relevant reporting processes.
(12) A description of how to address potential changes to the RSC.
b. The RSC developer must coordinate the Reuse Plan with all appropriate certification authorities, applicants, and integrators. All stakeholders must agree on the approach for concurrently using the RSC. Typically, the focal point for the Reuse Plan is the FAA office that will likely have first approval of a project using the RSC.
14. RELATED DOCUMENTS.
a. Code of Federal Regulations (CFR). Title 14 CFR parts 21, 23, 25, 27, 29, 33, and 35 are relevant to this AC. Copies of the CFR parts are available from the FAA website at http://www.airweb.faa.gov/rgl.
b. FAA Advisory Circulars (AC). AC 20-115B, RTCA, Inc., Document RTCA/DO-178B, dated January 11, 1993, offers a way to get FAA approval of software. This RSC AC guides applicants on using RTCA/DO-178B as their means of showing compliance to the regulations for software components. This AC supplements RTCA/DO-178B and AC 20-115B, for accepting compliance based on some RTCA/DO-178B objectives for individual components of a system’s software application and functions. If an applicant proposes a means of compliance other than RTCA/DO-178B, the FAA will decide if this AC applies and if other policy or guidance is warranted. You can get copies of this AC, AC 20-115B, and other ACs from the FAA website at http://www.airweb.faa.gov/rgl.
c. FAA Policy Documents. FAA Order 8110.4, Type Certification (as amended), and Order 8110.49, Software Approval Guidelines, are relevant to this AC. You can get copies of orders from the FAA website at http://www.airweb.faa.gov/rgl.