Chapter 5 Configuration Management of an IMA System.
5-1. IMA Configuration Management.
a. The applicant is responsible for overall IMA system configuration management.
b. Configuration management of an IMA system installed in an aircraft is critical because the system may contain many hardware components and functional software components, with each component having multiple approved versions or on-aircraft option selections. Some possible combinations of hardware and software versions will not be approved for flight.
c. Configuration management techniques to manage the IMA architecture are necessary to safely accommodate system attributes, such as (but not limited to) the following:
(1) Hosting multiple software applications on a single processor or on multiple, nondedicated processors.
(2) Producing and distributing hardware components without loading specific functional software.
(3) Allowing electronic part numbering for software components, without the need to physically mark hardware elements with the software part number(s).
(4) Allowing the electronic display of TSO identification.
(5) Allowing the field-loading of hardware components with functional software components for efficient maintenance and incorporation of approved design changes.
(6) Allowing the stocking of generic, non-configured hardware components for maintenance purposes. A non-configured hardware component is one that does not already contain the functional software components needed for satisfying an aircraft, engine or system function. These hardware components will be loaded later with field-loadable software. Each generic hardware component may have multiple versions, as components normally undergo updates during their lifecycle. Unless a specific effort is made to purge operator spares of earlier versions of a hardware component, you should assume that every version of a hardware component will exist in service and could be used on an aircraft or engine installation.
(7) Providing the ability to update and maintain IMA system configuration files without corruption.
5-2. Automated, Robust Configuration Management.
a. We strongly recommend a robust, automated configuration management scheme for an IMA system installed on an aircraft. A key feature of an automated configuration management scheme is that the IMA system itself monitors the configuration of either all or a subset of the 21
IMA hardware and software components. When an invalid configuration of the monitored components is detected, it should be annunciated in a way that will not allow the aircraft to be dispatched until the invalid configuration is corrected.
b. A robust, automated configuration management scheme should be able to detect, at a minimum:
(1) Incompatible versions of a software component hosted in a hardware component.
(2) Incompatible versions of multiple copies of a software component hosted in multiple hardware components.
(3) Incompatibilities or uncertified configurations between various systems that are closely coupled, such as autopilot and flight management systems.
(4) Incompatible system configurations with the aircraft model in which it is installed, and
(5) Incompatible option selections.
c. Any loss of function caused by configuration management system protections must be shown to be acceptable through the applicant's aircraft or engine level safety assessment. See § xx. 1309, xx denoting parts 23, 25, 27, or 29 as applicable.
5-3. Non-Automated, Robust Configuration Management. If your configuration management scheme of the IMA system installed on the aircraft or engine is not automated or depends on maintenance personnel to configure the system, either fully or partially, and to determine if the system configuration correct for that specific aircraft or engine, you should explain, in the appropriate certification document, why your configuration management scheme is robust. You should address possible issues with your proposed approach, such as likely maintenance errors that could result in a non-approved IMA contiguration. You should explain the testing and analysis that you plan to do to ensure the process is indeed robust.
5-4. Software Loading Procedures. For IMA systems that allow on-aircraft loading of software, the applicant should provide field-loading procedures that ensure correct software loading, as well as a means to verify that the software load operation was completed successfully and that the correct version of software is now installed.
5-5. Assurance Level of IMA Components Used in Configuration Management. Any IMA system component used in determining the validity and/or safety of an IMA configuration, whether the configuration management system is fully automated or manual, should be developed to the assurance level commensurate with the hazard classification of allowing a nonapproved configuration to be dispatched. This includes automatic configuration monitoring and displaying electronically stored part numbers and versions on a flight deck or maintenance display.
Chapter 6 IMA Recovery Features.
6-1. Restarting Safety Critical IMA Functions. Due to unforeseen circumstances, an IMA function, collection of IMA functions, or an entire IMA cabinet may unexpectedly shut down without the hosting IMA hardware components experiencing a permanent failure. IMA systems must include the ability to restart any hosted function or functions whose continued operation is required by the system or aircraft level safety assessment. See § xx. 1309, xx denoting parts 23, 25, 27, or 29 as applicable.
6-2. Restart Mechanism Implementation.
a. An IMA function or system restart feature included in an IMA system, when feasible, should be initiated automatically when a safety critical loss of function is detected. The IMA design should avoid the need for crew-initiated recovery features.
b. If an automatic recovery feature is not feasible and a crew-initiated - that is, nonautomated - recovery feature is implemented instead, you should put protection mechanisms and operations procedures in place to prevent accidental activation of the recovery feature by the thight crew.
c. The system design should carefully consider how many automatic attempts at restarting failed IMA functions or cabinets should be attempted. Attempting to restart indefinitely when the failed function or cabinet repeatedly shuts itself down may cause increased crew workload or distraction. Repeated failures after restart attempts may indicate that there is a failed IMA resource that should not be restarted. The system restart mechanism design should consider potential causes for restarts and determine the appropriate number of restarts to attempt before declaring the system failed. Factors that influence this architecture are the failure condition(s) associated with loss of IMA functionality, the impact of multiple restarts of a function or functions on interfacing systems, and the functionality remaining from non-IMA systems.
d. The IMA design should not rely on cycling aircraft circuit breakers to restart any IMA system or function. If crew-initiated manual recovery features are used, design a means other than cycling circuit breakers.
e. The applicant should evaluate the effects of automatically and/or manually activating recovery features in both normal and failed conditions for all phases of flight. The applicant should evaluate the effects of loss of functions during manual or automatic restart for all phases of flight.
Chapter 7 Topics Not Covered by RTCA/DO-297.
7-1. Electrical Power For IMA Systems.
a. The applicant and IMA developer/system integrator should design the physical and electrical power architecture of the IMA to support the flight crew's ability to manage smoke or fire events without losing functions whose loss are catastrophic.
b. If are fault circuit breakers (AFCB) are utilized for IMA cabinet or rack circuit protection, they should be specifically qualified for use on aircraft. At the issue date of this AC, the use of AFCB technology in airborne systems is in its infancy. Therefore, until more experience is gained and updated regulatory and/or guidance material is issued for the certification of AFCBs, the FAA may develop a method of compliance Issue Paper for certification programs that use AFCB technology.
c. The IMA cabinet or rack should not be powered with circuit protection features such as software controlled circuit breakers that are controlled by microprocessors hosted in that IMA cabinet or rack. The intent of this guidance is to prevent the complete loss of control of the circuit protection feature(s) of any specific IMA cabinet or rack, or IMA components installed within that cabinet or rack, such that the electrical power input cannot be removed to that cabinet or rack if it fails.
d. The following applies to part 25 transport airplanes only.
(1) Electrical wiring interconnection system (EWIS) components, as defined by § 25.1701, associated with IMA systems must comply with the applicable EWIS requirements of Part 25. See § 25.1701. Refer to Advisory Circular 25.1701-1, Certification of Electrical Wiring Interconnection Systems on Transport Category Airplanes, for specific compliance guidance.
(2) We consider EWIS to be an airplane system. Therefore, EWIS associated with IMA systems required for type certification or by operating rules, including those specifically listed in § 25.1705(b) must be considered as an integral part of that IMA system and must be considered in showing compliance with the applicable requirements for that IMA system. See § 25.1705(b).
(3) Circuit protective devices for the IMA cabinet or rack must comply with the requirements of § 25.1357. See § 25.1357. This includes § 25.1357(t) which requires IMA systems for which the ability to remove or reset power during normal operations is necessary be designed so that circuit breakers are not the primary means to remove or reset system power unless specifically designed for use as a switch.
7-2. Field Loadable Software.
a. Many IMA systems use field loadable software (FLS) as part of the TC/STC/ATC/ASTC installation. FLS is software that can be loaded into the host hardware without removing the equipment from the aircraft installation. FLS might also include software 24
loaded into a line replaceable unit (LRU) or hardware component at a repair station or shop.
FLS can refer to either executable code or data, such as a database. When seeking approval to use FLS, you should consider the following:
(1) FLS should meet the objectives and guidance of RTCA/DO-178B or other acceptable means of compliance, as agreed to between the applicant and your responsible ACO.
(2) The FLS should be loaded on the target computer and hardware configuration that the software was verified on during DO-178B on-target verification testing.
(3) A means must exist to ensure that the FLS is loaded into the proper IMA configuration approved for that aircraft. See § 21.31. See Chapter 5 for more information on configuration management.
(4) If redundant functions of the IMA system are field loadable, the applicant should ensure that they have the same software configuration, unless intermixing of different software configurations is supported by the safety assessment and approved for the aircraft configuration and type design.
(5) The applicant should have a process to assure that the software loaded is the software approved and that it hasn't been corrupted - for example, verification with a cyclic redundancy or other data transfer integrity check. Different data integrity algorithms give different assurances that the data transfer is correct. Ensure that the algorithm used is commensurate with the integrity required for the software level of the data being loaded.
(6) If the applicant proposes more than one medium for loading the FLS, such as a diskette, mass storage device or compact disc, loading from each medium should comply with the guidance in this section.
(7) The applicant should demonstrate that the airborne equipment software part numbers can be verified with onboard equipment, carry-on equipment, an automated configuration management scheme, or other appropriate means.
(8) Loading protection mechanisms should be implemented to inhibit loading FLS during flight. The reliability of these mechanisms should be commensurate with the failure condition associated with the inadvertent loading of software during flight.
Note: Please refer to AC 120-76A, Guidelines for the Certification, Airworthiness, and Operational Approval of Electronic Flight Bag Computing Devices, for guidance that pertains to loadable IMA software components that implement an Electronic Flight Bag function.
b. FLS installation documents should specify the following elements:
(1) Aircraft and hardware applicability and intermixability allowances for redundant systems that load software.
(2) Verification procedures to ensure that the software was correctly loaded into an approved, compatible target computer and memory device(s).
(3) Any post-load verification and/or test procedures required to show compliance to the guidelines specified in this AC.
(4) Actions to take - for example, prohibiting dispatch of aircraft - if there's an unsuccessful load.
(5) Reference to an approved loading procedure.
(6) Maintenance record entry procedures required to document and maintain configuration control.
(7) Reference to the appropriate Aircraft Flight Manual (AFM). Aircraft Flight Manual Supplement (AFMS) or operator's manual. il necessary.
7-3. Electronic Identification Guidance.
a. Identification of software components field-loaded into hardware elements should be implemented by electronic means. Electronic identification markings consist of identifying software components by electronically embedding the identification within softwarc contained in the hardware. rather than on the equipment nameplate.
b. Electronic software part numbers and versions should be verifiable through an electronic query, such as an electronic display. Software part number configuration errors detected by an automated robust IMA configuration management function should be annunciated to the flight crew until appropriate maintenance action is performed.
c. Equipment authorized by TSO must be permanently and legibly marked with specific information. Scc § 45.15(b). The applicant can demonstrate compliance to § 45.15(b) when you provide the information required by an electronic identification query system stored in nonvolatile memory. This approach is commonly called an "electronic TSO nameplate." The electronic identification system should be verifiable onboard the aircraft when the aircraft is on the ground at any geographic location. It must provide the specific information for all applicable TSOs being marked is using the clectronic TSO nameplate as the only means of labeling. See $ 45.15(b).
d. Electronic identification may also provide software and hardware component revision or modification status information and RTCA/DO-178B software levcl. The applicant can use this to demonstrate conformity to type design configuration.
e. Include information identifying the location of each hardware component in the electronic identification. This is necessary because the configuration depends on the specific location of cach hardware component within the cabinet or rack. You can satisfy this 26
requirement when an automated configuration management system scheme tracks and protects the IMA system configuration by ensuring hardware components are properly located.
f. All hardware components that support functions approved by a TSO should have a physical TSO nameplate. However, you may use electronic means instead of verifying nameplates on each hardware component, if all required information is available electronically.
Electronic identification does not replace hardware and software conformity inspections that determine the components are produced in conformity to type design.
g. Order 8150.1 (see the most current version) provides additional information on TSO part marking.
7-4. Aircraft System Lightning and HIRF Protection.
a. When you are showing compliance with aircraft lightning and HIRF protection regulations, you must demonstrate that the functions performed by electrical and electronic systems, whose failure could prevent continued safe flight and landing, are not adversely affected when exposed to lightning and HIRF. See §§ 23.1308, 25.1316, 25.1317, 27.1317, and
29.1317. The compliance demonstration for these systems should consider the performance of the integrated system, not only the equipment or modules that make up the system. To comply with this requirement to demonstrate no adverse etfects on the functions performed by the system, lightning, and HIRF tests should be performed with the IMA system in a test setup that represents the wiring, hardware, and software configuration that will be installed on the aircraft.
These lightning and HIRF system test configurations are typically more complex than those used for TSO compliance or equipment qualification. Guidance for compliance is in AC 20-136A, Protection of Aircraft Electrical/Electronic Systems Against the Indirect Effects of Lightning.
and AC 20-158, The Certification of Aircraft Electrical and Electronic Systems for Operation in
b. For systems that perform functions whose failure would significantly reduce the capability of the aircraft or the ability of the flight crew to respond to an adverse operating condition, the compliance demonstration may be based on lightning and HIRF tests performed on individual elements of equipment. RTCA/DO-160F tests satisfy these requirements.
c. Electromagnetic compatibility (EMC) between the IMA system and other aircraft systems should be demonstrated when the IMA system is installed in the aircraft. RF emission tests, such as those in RTCA/DO-160F, Section 21, should be performed on the IMA modules, equipment and systems to provide confidence that the IMA system does not produce unacceptable RF emissions. However, the EMC demonstration to comply with regulations such as §§ 23.1431,
23.1431, and 29.1431 should be pertormed with the IMA system and the other electrical and electronic systems installed on the aircraft
7-5. IMA System Data Network. Many, if not all, IMA systems will include a dedicated data network, such that the elements within an IMA system may communicate with each other without using the main aircraft or engine data network. This data network may be purely internal to an IMA cabinet or, for distributed IMA components, the data network may be 27
required to span the length and breadth of the airframe in which the IMA is installed. For data networks that are dedicated to or primarily for IMA system data transmission and reception and are distributed in nature - that is, not purely internal to the IMA cabinets or modules - the applicant and IMA developer/system integrator should follow the guidance provided in AC 20- 156, Aviation Databus Assurance, or use another acceptable means.
Chapter 8 Use Of TSO Authorized Components In IMA Systems.
8-1. IMA Systems and TSOs.
a. IMA systems, depending on the specific aircraft or engine application, may combine many functions that were historically in functionally and physically separated systems. These IMA functions are made up of hardware and software components, each of which may be authorized by TSO, either complete or incomplete. Additionally, hardware modules, cabinets, and racks that host the IMA hardware modules may also be authorized by TSO.
b. TSO authorizations are allowed under 14 CFR part 21, subpart O. Your responsible ACO can explain how we evaluate and issue TSOAs and letters of TSO design approval (LODA) for aviation-related articles.
c. TSOs associated with IMA systems are:
(1) TSO-C153, which covers two types of hardware used in IMA systems: generic hardware modules and cabinets/racks that host hardware modules.
(2) Functional TSOs. See paragraph 8-7 below and refer to Appendix G for examples of functional TSOs. You should keep in mind that this term is not normally used except in the context of IMA systems.
d. RTCA/DO-297 does not specifically address TSO authorized articles within an IMA system. This chapter offers you a way to obtain approval for IMA systems that contain hardware and/or software components authorized by TSO.
e. Due to the high integration, functional TSO data packages for IMA systems are typically developed in parallel with the TC/ST/AT/ASTC effort. In these cases, you should not submit TSO data to the ACO for authorization until the TC/STC/ATC/ASTC testing for the IMA system is completed and the final IMA system configuration is established. This will ensure that the IMA system meets all required TSO MPS. Alternatively, compliance data for TSO authorization and compliance data for the TC/STC/ATC/ASTC maybe be submitted to the appropriate FAA offices concurrently, such that the TSO authorization may be issued concurrently with the aircraft/engine certificate. This alternative approach requires a high level of coordination between the responsible FAA offices to ensure that issues that arise in one area do not affect the
8-2. TSO-C153 Authorization for IMA Hardware Components.
a. To obtain TSO-C153 authorization, the applicant for TSO authorization must demonstrate that the individual hardware components meet the MPS and defined subset of RTCA/DO-160F environmental qualification requirements in TSO-C153, as described in Appendix A. See § 21.616(c). TSO-C153 does not provide either functional or installation approval.
b. The applicant for an IMA Component Acceptance Letter may use TSO-C153 authorization as compliance data to obtain IMA component acceptance for IMA hardware components. See RTCA/DO-297, Table 4.
8-3. Functional TSO Authorization.
a. A functional TSO is a TSO with a defined aircraft functionality. For example, TSO- C106 is for an air data computer. Other examples of functional TSOs are listed in Appendix G of this AC. TSO-C153 is not considered a functional TSO because the hardware element it addresses does not have system level functionality. A functional TSO authorization is issued for a specific IMA system configuration, including hardware and software components, that performs the function defined in the functional TSO MPS. It is not simply for the software component that is loaded into a TSO-C153 authorized hardware element.
b. If the IMA system provides all or part of the functionality required by the functional TSOs MPS and the company applying for functional TSO authorization also controls the design and quality of the complete IMA system, then that company may apply for functional TSO authorizations (either complete or incomplete) for each aircraft function for which there is an applicable functional TSO. As noted above in 8-3(a), the TSO authorization will apply to the IMA system and not a specific IMA component.
Note: Per § 21.601(b)(5), the manufacturer of an article is the "person who controls the processes, and services that are provided by any supplier to that applicant for a TSO authorization. See § 21.601 (b)(5).
c. If the company supplying functional software that will be installed in an IMA system does not control the entire design and quality, per 8-3(b) above, of the article that provides the functionality defined in the functional TSO MPS, then that company may not apply for functional TSO authorization.
d. It should be noted that there will typically be multiple functional TSO authorizations that comprise the IMA system, and the IMA system will likely contain functionality and features not addressed by any TSO. The overall functionality of the IMA system and the portions covered by TSOA versus TC, STC, ATC, or ASTC should be carefully documented and coordinated with the FAA.
8-4. EQT of IMA Components with TSO Authorization.
a. There will be three different stages at which TSO authorized IMA components and the IMA system in which these components are installed need to comply with EQT requirements:
(1) TSO-C153. This TSO contains EQT MPS for IMA hardware modules that qualify for TSO-C153 authorization. Comply with these requirements to obtain TSO-C153 authorization for the generic IMA hardware.
(2) Functional TSO MPS. Each individual functional TSO (see Appendix G for examples) MPS normally include EQT requirements. Comply with these requirements to obtain the individual functional TSO authorization(s).
(3) Aircraft or engine installation EQT requirements. EQT procedures and test configurations are based on the specific aircraft or engine installation of the complete IMA system. Compliance to the aircraft or engine level installation EQT requirements may be completed under the aircraft/engine certification program independent of the TSO authorizations.
Alternatively, certification credit at the aircraft or engine installation level may be taken from the TSO authorizations, if applicable at the installation level.
b. TSO-C153 was written specifically to address how partial EQT compliance at the aircraft or engine installation level can take credit from the EQT compliance from TSO-C153 authorization. EQT procedures that require the test to be run on the specific IMA system configuration as it will be installed on the aircraft or engine should be accomplished during the aircraft or engine TC/ATC/STC/ASTC program. TSO-C153 and Appendix A of this AC address how this can be done.
c. Compliance to the EQT MPS for the individual functional TSO MPS is still required, even with TSO-C153 authorization of the hardware components which host that function.
d. An applicant for an IMA Component Acceptance Letter may use the EQT compliance data from a TSO authorization to use as compliance data for the IMA Component Acceptance Letter process addressed in Chapter 3 of this AC. The IMA Component Acceptance Cover Letter and the accompanying IMA Component Acceptance Letter data sheet should include which EQT are being accepted, including a statement of full or partial compliance and a matrix or table of all EQT procedure testing levels accomplished.
8-5. IMA Component TSO Part Marking.
a. If loadable software components are used with generic hardware modules authorized under TSO-C153 to implement a functional TSO, an applicant for functional TSO authorization should identify the loadable software - both the electronic identification and the physical or electronic media containing the loadable functional software - with the functional TSO identification.
b. The generic hardware components authorized by TSO-C153 must be permanently marked as being authorized under that TSO, in addition to any electronic identification. See § 21.607(d).
c. See paragraph 7-3 for electronic identification guidance.
8-6. Integration of TSO Authorized Components in IMA Systems.
a. The applicant should demonstrate that all RTCA/DO-297 objectives required to obtain Acceptance of the IMA modules, applications, system, and installation into the aircraft or engine have been met. This is true regardless whether any of the modules or applications are also part of a TSO authorized article as described above in paragraph 8-3. The TSO authorization for the IMA function may be used, if relevant, in showing that you met RTCA/DO-297 objectives. The presence of a TSO authorization in no way removes or reduces your responsibilities as an applicant, which is to ensure that the installed IMA system - including any TSO authorized components - meets the appropriate aircraft and engine regulations and the guidance in this AC.
b. Functional TSOs, such as TSO-C113, Airborne Multipurpose Electronic Displays, do not normally cover integration with other aircraft functions or hardware/software components in the integrated IMA system. Each TSO MPS is normally written assuming that it is a stand-alone function and that no integration requirements exist beyond integration into the aircraft. For this reason, additional work is likely to be required beyond the TSO authorizations when showing compliance at the integrated IMA system level. Please refer to RTCA/DO-297, subsection 4.4.
c. The installation instructions for TSO authorized IMA components should include all information necessary for the applicant and/or the IMA developer/system integrator to fully integrated the TSO authorized IMA component into the IMA system.
8-7. Aircraft Installation Approval of IMA Systems Including TSO Authorized Components.
a. The applicant must demonstrate that the installed IMA system configuration - including both hardware and software components - and performance meets the appropriate aircraft and engine certification basis. See § 21.20. This demonstration should include functional performance, interoperability, aircraft-level and system-level safety assessments, environmental qualification, system integration test, flight-test, software and hardware assurance, etc., as required to show compliance to the regulations.
b. The applicant may use TSO authorizations to support airworthiness assessment if you show that the TSO requirements apply to the installation into the aircraft or engine. Any change to the hardware or software configuration of an IMA component must be controlled at both the TSO and the aircraft installation level. See §§ 21.31 and 21.611.
8-8. Roles and Responsibilities When TSO Authorized Components Are Used in IMA Systems.
This section identifies the major roles and responsibilities for the TSO-C153 applicant, the functional TSO applicant, and the aircraft/engine applicant when TSO authorized components are used. These lists are not all-inclusive. We encourage all affected parties to coordinate with us throughout the entire IMA system development. See Appendix A for more guidance applicable to TSO-C153 authorization.