(1) The IMA Component Acceptance Cover Letter, prepared and signed by the applicant for the IMA Component Acceptance Letter. See paragraph 3-3.
(2) The IMA Component Acceptance Letter data sheet, prepared by the applicant for the IMA Component Acceptance Letter. See paragraph 3-4.
(3) The Acceptance Letter, prepared and signed by the FAA. See paragraph 3-5.
b. If you are an applicant for an IMA Component Acceptance Letter, assemble your request package (both the completed IMA Component Acceptance Cover Letter and the IMA Component Acceptance Letter data sheet) and submit it to the appropriate FAA office. If we approve your request, we will prepare and sign a Acceptance Letter for that IMA component.
We will send the applicant for the IMA Component Acceptance Letter a copy of the IMA Component Acceptance Cover Letter and the signed Acceptance Letter. We will retain and archive the original of all three parts of the IMA Component Acceptance Letter.
c. At your request, we will provide extra copies of the signed Acceptance Letter and IMA Component Acceptance Cover Letter to you or to another company.
d. You should maintain your own files of the IMA Component Acceptance Cover Letter and IMA Component Acceptance Letter data sheet. We will not provide copies of the IMA Component Acceptance Letter data sheet.
e. We do not allow modifications to previously accepted IMA components under an existing IMA Component Acceptance Letter. If you change a previously accepted IMA component and still want an IMA Component Acceptance Letter, you will have to apply for another one. See paragraph 4-9 of this AC for more information on changes to an accepted IMA component.
3-3. Essential Elements of the IMA Component Acceptance Cover Letter.
a. The IMA Component Acceptance Cover Letter specifies what compliance data is being accepted by the FAA. The applicant for an IMA Component Acceptance Letter should include the following information in the IMA Component Acceptance Cover Letter:
(1) Date of application for the IMA Component Acceptance Letter.
(2) The FAA office to which the request for an IMA Component Acceptance Letter is being made.
(3) Unique identifier for the IMA Component Acceptance Cover Letter. The specific format of this identifier is left to the discretion of the applicant for the IMA Component Acceptance Letter. It could be a company correspondence number or a unique identifier used solely for the purpose of application for IMA Component Acceptance Letters. However, once a particular identification is used, it should not be re-used.
(4) Name and contact information for the company requesting the IMA Component Acceptance Letter.
(5) Name and contact information of the original IMA developer/system integrator, the airborne system and aircraft/engine in which the component will be installed, the target environment, such as the microprocessor, memory management unit, data busses, input/output devices, etc., and other information about the initial acceptance of the IMA component. Include name and contact information of the IMA component developer, if different than the applicant for the IMA Component Acceptance Letter.
(6) Contact information for persons or organizations who will answer questions about component acceptance and concurrent/future reuse.
(7) IMA component name, unique component identifier, and all associated document numbers, titles, and revision levels. Examples are the system, software or hardware (as appropriate) configuration index number and revision, a component's acceptance accomplishment summary number and revision, and any configuration information not included in the module configuration index.
(8) All configuration information (use references to other documents as necessary) to fully define the component and its development environment.
(9) High level description of the component purpose and usage domain. See RTCA/DO- 297, paragraphs 4.2.10 and 4.3.2, and the Glossary of this AC for the discussion of and definition of usage domain.
(10) Short description of the software partitions, software levels, and hardware design assurance levels within the component.
(11) Definition of the compliance data type(s) being accepted and documented by this IMA component acceptance letter - that is, airborne software, complex electronic hardware (CEH), comprehensive testing for simple electronic hardware (SEH) components, EQT, and any other data type that has been mutually agreed on.
(12) State whether each compliance data type shows full or partial compliance to their respective standards - for example, RTCA/DO-178B for airborne software. A full description of any partial compliance is not necessary, as we expect you to include that information in the IMA Component Acceptance Letter data sheet described in paragraph 3-4.
(13) Statement of compliance that the signatories attest that the IMA component meets all the applicable requirements defined in the IMA Component Acceptance Letter.
(14) Signatures and dates. At least one managerial signature representing each of the technical disciplines covered by the IMA Component Acceptance Letter: RTCA/DO-178B compliance for airborne software, R'TCA/DO-254 compliance for CEH, comprehensive testing 11
and analysis of SEH, and RTCA/DO-160F compliance for EQT. One signature may cover more than one technical disciplines. Other signatures, such as engineering personnel, may be included if the applicant for the IMA Component Acceptance Letter desires. Each signature should include the date of the signature and the typed or printed name, as well as an identification of which technical discipline that signature covers.
b. See appendix B for a sample IMA Component Acceptance Cover Letter.
3-4. Essential Elements of the IMA Component Acceptance Letter Data Sheet.
a. The IMA Component Acceptance Cover Letter or the accompanying IMA Component Acceptance Letter data sheet should fully define the usage domain of the IMA component, or else it should reference a document where the usage domain of the IMA component is fully defined. If that information is not in the IMA Component Acceptance Cover Letter, then you should include it as part of the accompanying IMA Component Acceptance Letter data sheet.
b. Each IMA Component Acceptance Letter data sheet should contain, at a minimum:
(1) Assumptions the IMA component developer made during the acceptance. These assumptions may be documented by referencing the component developer's accomplishment summary or other appropriate certification document. Include assumptions for each applicable RTCA/DO-297 objective in the appropriate accomplishment summary. The assumptions should be detailed enough that the FAA, the IMA developer/systems integrator, and applicant can apply this information to any future or concurrent IMA programs that will reuse this component.
(2) Summary of technical or policy issues that arose during the initial acceptance and how the applicant and FAA resolved them.
(3) Summary of additional activities that the IMA developer/system integrator and/or applicant need to perform to ensure that all objectives of RTCA-DO-297 Tasks 3 and 4 can be met when using the accepted IMA component. Describe any remaining compliance activity required to show full compliance to the appropriate standard - for example, RTCA/DO-178B for airborne software, any remaining EQT required by RTCA/DO-160F, Environmental Conditions and Test Procedures for Airborne Equipment, not covered by the IMA Component Acceptance Letter.
(4) The software level(s) and/or hardware design assurance level(s) of all software partitions and/or CEH/SEH devices.
(5) A description of the target computer, including the applicable hardware, operating system, board support package, drivers, etc., that will host software to perform aircraft-level functions.
(6) High-level description of the function and/or purpose of the component and target environment. If the component contains multiple software partitions and/or multiple CEH/SEH devices, include a high level description of each. This allows us and the IMA component 12
integrator to clearly understand the relationship of each partition and/or hardware device and their associated software levels and/or hardware design assurance levels.
(7) Testing levels achieved for all EQTs performed.
(8) Limitations, plus any installation, safety, operational, functional, or performance issues.
(9) Module or application acceptance data, including interface specifications, user's guide, and usage domain described in RTCA/DO-297, paragraphs 4.2.4e, 4.2.10, 4.2.12e, 4.3.2, and 4.4.2.
(10) Full explanation of kinds of technical data other than those specific technical disciplines addressed in paragraph 4-2.b of this AC included in the IMA Component Acceptance Letter. The applicant for the IMA Component Acceptance Letter should also include a detailed explanation of what remains to be done by the IMA developer/system integrator and/or aircraft or engine manufacturer, to obtain full compliance for the compliance data associated with this technical discipline.
(11) A copy of any pertinent document that demonstrates the compliance data contained in the IMA Component Acceptance Letter data sheet has been evaluated and found acceptable by the FAA or by an authorized representative of the FAA. Examples include signed 8110-3 forms and TSOA letters. By including evidence that data within the IMA Component Acceptance Letter data sheet has found to be acceptable, you will significantly speed the process of evaluating the application for an IMA Component Acceptance Letter.
3-5. Acceptance Letter.
a. The FAA will prepare and sign an Acceptance Letter for the IMA component to signify that the IMA component has been accepted. The Acceptance Letter will reference the IMA Component Acceptance Cover Letter unique identifier, so that the Acceptance Letter will be associated with that specific IMA Component Acceptance Cover Letter.
b. See Appendix C for a sample Acceptance Letter.
3-6. IMA Component Acceptance Letters For Revised IMA Components.
a. If a previously accepted IMA component has been changed or revised in any manner, the original IMA Component Acceptance Letter is no longer valid. As stated in paragraph 3-5 above, an IMA Component Acceptance Letter is associated with a specific configuration of that component, defined by its accompanying documentation. Any change to a previously accepted IMA component requires at least some of the accompanying documentation - such as the component configuration index - to be updated. This requires a new IMA Component Acceptance Letter.
b. If there's a change to a previously accepted IMA component and you want a new IMA Component Acceptance Letter for it, you should show that the component meets the guidance of RTCA/DO-297, subsection 4.6 for the updated IMA component. Paragraph 4.6.5 of RTCA/DO- 297 discusses the change data that should be submitted when requesting a new IMA Component Acceptance Letter for a change to a previously accepted IMA component.
3-7. Cancelling an IMA Component Acceptance Letter.
a. The FAA may cancel a previously issued IMA Component Acceptance Letter. Reasons that we may cancel anIMA Component Acceptance Letter include, but are not limited to, the following:
(1) The accepted IMA component is determined to be the cause of or contributed to an in-service accident or safety related incident.
(2) The accepted IMA component is the subject of a § 21.3 report.
(3) The IMA component developer, IMA developer/system integrator, or applicant determines that the IMA component does not meet the acceptance criteria defined in the original IMA Component Acceptance Letter.
(4) It is discovered that the accepted component was developed from erroneous or incomplete requirements, and those erroneous or incomplete requirements could, given the correct circumstances, lead to a reduction in safety in any aircraft or engine in which the component is installed.
b. We will notify the holder of an IMA Component Acceptance Letter when it is cancelled.
This action has the effect of not allowing that version of the IMA component to be reused on a future or concurrent certification program until the reason for the cancellation has been addressed. A new IMA Component Acceptance Letter for the updated IMA component may be requested per paragraph 3-6.
Note: Cancelling an IMA Component Acceptance Letter has no bearing on the continued safe operation of an aircraft or engine that uses that IMA component. If action is required, the FAA will issue an Airworthiness Directive that will require operators to update the component or aircraft function in question.
c. We expect the holder of an IMA Component Acceptance Letter to contact the ACO that issued the IMA Component Acceptance Letter in a timely manner if any issues such as those listed in a. are discovered.
Chapter 4 Reuse Of IMA Components.
4-1. Reuse of an Accepted IMA Component.
a. If a previously accepted IMA component is unchanged, its intended reuse meets the limitations in the IMA Component Acceptance Letter, and the FAA engineer for the certification program in which the IMA component is being reused does not have any concerns, you may reuse that component without need for additional FAA review of the originally accepted IMA component compliance data.
b. If you are an IMA developer/system integrator or applicant proposing to reuse a previously accepted IMA component, you should ensure and document that you identified no safety, installation, operational, functional, or performance concerns with the subsequent use of that component.
c. Although the intent of IMA Component Acceptance Letters is to document our acceptance of the compliance data for an IMA component, the existence of such a letter does not prevent us, on a new or concurrent TC/STC/ATC/ASTC program, from requesting to examine the compliance data associated with the accepted IMA component if we have questions or concerns. We will first try to address any open questions without resorting to re-examination of the previously accepted compliance data. However, if we have specific concerns that cannot be answered by any other means, we may ask you to provide some of the previously accepted data. Only compliance data specific to the identified issue or concern should need to be re-examined. If the initial IMA Component Acceptance Letter was done correctly and all necessary compliance data was included in the IMA Component Acceptance Letter, we should not need to resort to re-examination of previously accepted compliance data.
d. RTCA/DO-297, paragraph 4.7.1, states that future reuse of any component should be planned during the initial development of that component and documented in the appropriate certification planning document. An IMA component not initially developed for future reuse and lacking a signed Acceptance Letter should be treated as a newly developed component.
4-2. What Can Be Reused.
a. RTCA/DO-297, subsection 4.7 states that reuse of a previously accepted component should be limited to modules (see Task 1 in RTCA/DO-297, subsection 4.2) and applications (Task 2, subsection 4.3). We do not allow reuse of previously accepted data at the IMA system level (Task 3, subsection 4.4) or IMA installation level (Task 4, subsection 4.5).
b. RTCA/DO-297, subsection 4.7 limits reuse of the types of data for Tasks 1 and 2 to the following technical subjects:
(1) Airborne software compliance to RTCA/DO-178B. See RTCA/DO-297, paragraph
4.7.2 and paragraph 4-4 below.
(2) CEH component compliance to RTCA/DO-254. See RTCA/DO-297, paragraph
4.7.3 and paragraph 4-5 below.
(3) EQT compliance to RTCA/DO-160F. See RTCA/DO-297, paragraph 4.7.4 and to paragraph 4-7 below.
c. In addition to those three technical data types, this AC identifies comprehensive testing of SEH as another data type for which acceptance data can readily be developed, packaged, and accepted for future reuse. Reuse of compliance data for SEH is not covered in RTCA/DO-297.
(1) RTCA/DO-254, subsection 1.6, provides the following definition:
Simple Hardware Item - Item with a comprehensive combination of deterministic tests and analyses appropriate to the design assurance level that ensures correct functional performance under all foreseeable operating conditions, with no anomalous behavior.
(2) AC 20-152, RTCA, Inc., Document RTCA/DO-254, Design Assurance Guidance for Airborne Electronic Hardware, says that applicants should apply RTCA/DO-254 to custom micro-coded components, which are a subset of "hardware items." This is AC 20-152's definition:
Custom micro-coded component - A component that includes application specific integrated circuits (ASIC), programmable logic devices (PLD), field programmable gate arrays (FPGA) and other similar electronic components used in the design of aircraft systems and equipment.
(3) FAA Order 8110.105, paragraph 5-1, explains that SEH is a custom microcoded component that satisfies the definition a simple hardware item of RTCA/DO-254.
The design of an SEH device can be shown to be correct and complete by comprehensive testing and analysis without a detailed development assurance process. Ask your FAA ACO for more information regarding definitions and explanations of CEH, SEH, hardware items, and custom micro-coded devices. See RTCA/DO-254, subsection 1.6 for more information on simple hardware items.
4-3. Reuse of Other Types of Compliance Data.
a. If you are an IMA component developer intending to develop any data for future reuse beyond those listed in 4-2.b and 4-2.c, you should include this intent in the appropriate certification planning document. Work closely with us, the IMA developer/system integrator, and applicant at the beginning of the component development program to ensure that future reuse of this data is feasible, and all parties agree on what is required to ensure the success of any future reuse. We are not required to accept a proposal for future reuse of data beyond those listed in 4-2.b and 4-2.c, but we will consider your proposal.
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