b. Any compliance data beyond those data types listed in paragraphs 4-2.b and 4-2.c. that you propose for inclusion in an IMA Component Acceptance Letter should fall within Tasks 1 and 2, per paragraph 4-2 above.
c. The IMA component requirements for the additional compliance data types should be documented in an appropriate certification document and referenced in either the IMA Component Acceptance Cover Letter or the IMA Component Acceptance Letter data sheet.
4-4. Reuse of Previously Accepted Software-Only or Hardware Component Containing Airborne Software.
a. RTCA/DO-297, paragraph 4.7.2, addresses reuse of a software module or application.
However, as stated in RTCA/DO-297, paragraph 4.7.5, this guidance should also be followed for IMA hardware components that contain airborne software.
b. In addition to the guidance for reuse of a previously accepted component containing airborne software provided by RTCA/DO-297, the guidance for the reuse of airborne software contained in AC 20-148, Reusable Software Components, should also be used in its entirety, with the exception of Chapter 9 which addresses the Reusable Software Component (RSC) Acceptance Letter. AC 20-148 contains more detail than RTCA/DO-297 about developing airborne software for reuse, and reusing that software in another project. AC 20-148 specifies the roles and responsibilities of all parties, the processes to be used, how the data should be developed when future reuse is intended, and what data should be supplied by the software developer to the integrator of the software or to the applicant.
c. RTCA/DO-297, paragraph 4.7.2 states that the prerequisites for reusing previously accepted software is that the software should be hosted on the "same target hardware" and is "used in the same way operationally" for the earlier accepted application and the intended reuse application. Given the rapid change in technology employed in today's IMA systems as well as the rapid rate of hardware parts obsolescence, it's likely that the intended platform that is to host the reused software component will not include the same target hardware that initially hosted the accepted software. The target hardware may include a microprocessor from the same family as that of the previous target hardware. However, coming from the same family of microprocessors does not automatically qualify as "the same target hardware." If an IMA developer/system integrator or applicant wants to reuse a previously accepted IMA component that contains sottware, but that software will be hosted on non-identical target hardware, the applicant should ensure compliance with all RTCA/DO-178B and RTCA/DO-297 objectives and document how they intend on showing that compliance.
4-5. Reuse of CEH or Hardware Component Containing CEH.
a. AC 20-152, paragraph 2.c states that RTCA/DO-254 applies to complex custom microcoded components with hardware design assurance levels A, B, and C. See paragraph 4-2.c (2) for definition of custom micro-coded components. Accordingly, we restrict granting IMA Component Acceptance Letters (per RTCA/DO-297, paragraph 4.7.3) to RTCA/DO-254 17
complex custom micro-coded components - that is, to CEH and not commercial-off-the-shelf (COTS) hardware devices.
b. Your ACO will use FAA Order 8110.105 for definitions and additional information on using RTCA/DO-254 as an acceptable means of compliance.
c. Currently, there is no guidance for CEH that defines a detailed acceptable means of compliance similar to that provided by AC 20-148 for an RSC. However, because of the many similarities between the processes in RTCA/DO-178B for airborne software and those in RTCA/DO-254 for airborne electronic hardware, adapt the paragraphs of AC 20-148 listed below to CEH. Use these paragraphs of AC 20-148 when negotiating an agreement between yourself and us on reusing CEH components:
(1) Paragraph 4 - General Guidelines for Getting the FAA to Accept an RSC.
(2) Paragraph 5 - Guidelines for the RSC Developer.
(3) Paragraph 6 - Data the RSC Developer Must Supply to the RSC Integrator or Applicant.
(4) Paragraph 7 - Guidelines for the Integrator and Applicant Using the RSC.
(5) Paragraph 8 - Expectations from FAA on First Use of an RSC.
(6) Paragraph 10 - Expectations from FAA on the Subsequent Use of an Accepted RSC.
4-6. Reuse Of SEH or Hardware Component Containing SEH. As with CEH, there's no current guidance on reusing SEH compliance data. Consult the same paragraphs listed in paragraph 4-5 above when negotiating with us on adapting and using these paragraphs for SEH components. Your ACO will use FAA Order 8110.105 for information on SEH and our expectations regarding comprehensive testing of SEH components.
4-7. Reuse of EQT Data.
a. RTCA/DO-160F, Section 1, stresses the importance of selecting the right environmental conditions and test procedures for equipment under test. A phrase used throughout RTCA/DO- 160F is, "determine compliance with applicable equipment performance standards." If you are the tester responsible for EQT, it is up to you to determine the specific test configuration and requirements appropriate for the equipment under test. There are many aspects of environmental testing - vibration levels, temperature, altitude, orientation of equipment, electrical connectors, electrical grounding schemes, and electrical wire lengths - specific to the aircraft in which the equipment will be installed. The qualification test plan for the equipment under test should properly define all variable test parameters.
b. RTCA/DO-297, paragraph 5.2.6 stresses the flexibility and reconfigurable nature of modern IMA systems. That is, although the basic architecture of an IMA system is set and will 18
not change, each IMA system can be tailored specifically for the aircraft or engine in which it is installed. This is true for the functionality provided by the IMA system as well as for the environmental conditions to which it is subjected - for example, vibration levels for installation in a rotorcraft versus a fixed wing aircraft. This flexibility, while beneficial in many respects, introduces complications when you attempt to develop reusable EQT data per RTCA/DO-297, paragraph 4.7.4.
c. A company asking us for an IMA Component Acceptance Letter for an IMA component being developed for future reuse should ensure that the data package of this component clearly identifies all variables and parameters used during EQT. The IMA developer/system integrator intent on reusing a previously accepted component which includes EQT data should ensure that all aspects of that testing are appropriate for the aircraft or engine in which it will be installed. If any testing variable or parameter used during the component's initial acceptance is not identical to what is required for the intended reuse, then the integrator of that previously accepted component should document those differences and justify why they are acceptable for the new intended installation. If there is not adequate justification for any difference between the original acceptance and the intended reuse, then the IMA developer/system integrator or applicant should re-test that aspect of the EQT, using the appropriate values and test configurations.
4-8. Data the Component Developer Owes to the IMA Developer/System Integrator or Applicant.
a. The developer of a previously accepted IMA component should supply the IMA developer/system integrator and/or applicant who is reusing the component with many different types of data. This ensures that the IMA developer/system integrator and applicant can fully satisfy the objectives of RTCA/DO-297, subsection 4.7 and Annex A. The data required by the IMA developer/system integrator and applicant are likely to exceed that included in the IMA Component Acceptance Letter.
b. Instead of providing data directly to another company, the developer of a previously accepted IMA component may choose to use a data/software escrow approach. See AC 20-148, paragraph 6.j(2) for guidance regarding data/software escrow.
e. AC 20-148, paragraph 6 details the data for airborne software that a developer of a previously accepted software component should make available to the IMA developer/system integrator, the applicant, and to us, if we ask. As noted previously, there is no similar guidance for accepted reuse of either RTCA/DO-254 or RTCA/DO-160F compliance data. However, RTCA/DO-297, paragraphs 4.2.3, 4.2.12, 4.3.1, and 4.3.2 document many of the elements required. A developer of a previously accepted IMA component should provide the data required to ensure compliance with RTCA/DO-297, subsection 4.7 and with the objectives of Annex A, either directly or by data escrow, to the IMA developer/system integrator and/or applicant.
4-9. Reuse of a Previously Accepted IMA Component That Was Revised. A previously accepted IMA component that has been revised since its last acceptance should meet the 19
guidance in RTCA/DO-297, subsection 4-5 to be reused in a new or concurrent application. If you want a new IMA Component Acceptance Letter, see paragraph 3-6.
4-10. Reuse of an IMA Component with a Previous TSO Authorization.
a. If the IMA component that has a previous TSO authorization also has been previously issued an IMA Component Acceptance Letter, then the process for reuse of a previously accepted IMA component takes precedence. The applicant and IMA developer/system integrator should use the guidance in section 4 without regard to remainder of this paragraph.
b. If the IMA component that has a previous TSO authorization has not been issued an IMA Component Acceptance Letter, then the following applies:
(1) You should follow all limitations described in the TSO authorization when integrating the component into the IMA system. These limitations should be documented in the appropriate certification planning documents).
(2) The intended usage domain of the TSO authorized IMA component should be identical to the usage domain identified in the TSO authorization. If the intended usage domain is not the same as identified in the TSO authorization, then you should do analysis and/or testing to demonstrate those differences do not affect the use of the IMA component within the intended usage domain.
(3) You should identify all RTCA/DO-178B and RTCA/DO-254 objectives that have only been partially met under the TSO authorization and describe in the appropriate certification planning documents) how full compliance to these objectives will be shown for the integrated IMA system. See AC 20-148, paragraph 5.d(1) for more information.
(4) You should identify all remaining EQT that are required for the aircraft or engine installation that is not covered by the TSO authorization. These remaining EQT should be described in the appropriate certification planning documents). Any EQT results from the TSO authorization that you desire to take credit for at the aircraft or engine installation level should be described in the appropriate certification planning documents). See paragraph 4-7 for more information regarding reuse of EQT data.
(5) Any SEH devices that are within the TSO authorized IMA component should be identified in the appropriate certification planning documents). Compliance to RTCA/DO-254 for SEH devices are not covered by TSO authorizations, unless specifically stated in the TSO.
The guidance of paragraph 4-6 should be used.
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.