c. Installation Approval.
(1) The TC/STC/ATC/ASTC applicant must demonstrate that the installed IMA system configuration (including hardware and software) meets the appropriate aircraft and engine certification basis. This demonstration must include functional performance, interoperability, aircraft-level and system-level safety assessments, environmental qualification, system integration test, flight test, software assurance, hardware assurance, and other certification activities (as required to show compliance to the regulations).
(2) TC/STC/ATC/ASTC applicants may use TSO data to support airworthiness assessment, if they show that the TSO requirements apply to the installation. Any change to an IMA system’s hardware or software configuration must be controlled at both the TSO authorization and the aircraft installation level. Section 20c of this AC provides additional guidance on changes.
NOTE: IMA systems often have generic software functions (for example, an operating system). These functions are approved as part of the functional TSO authorization or aircraft installation approval of the TC/STC/ATC/ASTC (that is, they are not approved as stand-alone components).
9. SAFETY ASSESSMENT PROCESS GUIDANCE.
a.
b.
Because of the high level of complexity and integration inherent in IMA systems, it is recommended that applicants conduct a structured formal analysis of these systems using the guidance contained in Society of Automotive Engineers (SAE) ARP4754 (Certification Considerations for Highly-Integrated or Complex Aircraft Systems) and ARP4761 (Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment), or an acceptable alternative. IMA systems, depending on the specific airframe application, can combine many functions that historically have been contained in functionally and physically separate systems. In the IMA system architecture, electrical power, computing hardware, memory, databus, physical location, etc. may all be shared by multiple functions; some of which have little commonality with each other.
All hosted functions may use common resources, such as common processing, common operating system, common protection and partitioning mechanisms, common core services, and common interconnect buses. System and functional hardware module communications may be tied together using a bi-directional digital communication network that uses a standard interface circuit for each hardware module. Time and space software partitioning may rely on a common operating system that allows functions of mixed hazard categories, design assurance levels, and software levels to co-exist and execute on the same processing platform. These features raise several concerns, such as:
(1) Possible interference to critical systems (for example, fly-by-wire flight controls or electronic engine control) by functions of lower integrity.
(2) Failure conditions (either single or multiple) that could affect multiple functions, thereby reducing safety and causing increased flight crew workloads when attempting to determine the nature of the problem and the correct flight crew response.
c. The TC/STC/ATC/ASTC applicant should conduct an aircraft-level safety assessment for the installation of IMA systems; the failure of which could result in catastrophic, hazardous/severe-major, or major failure conditions. This assessment must specifically address system integration issues and should be performed in addition to the system safety assessment (SSA) performed for individual functions. Central to the aircraft-level safety assessment is the identification of the cross-functional effects of single and/or multiple failure combinations.
Cascading or common-cause failures, and fault propagation effects, if they exist, should be identified, analyzed, and mitigated. Additional guidance is provided in SAE documents ARP4754 and ARP4761. The safety assessment should include the following:
(1) Functional Hazard Assessment (FHA). The intended functions of the IMA system should be identified and evaluated for their impact on aircraft and engine safety. An FHA should be conducted at the aircraft level to determine and classify the hazards associated with both the loss and malfunction of each function provided by the IMA system. The hazards associated with the simultaneous loss or malfunction of multiple functions provided by the IMA system must also be identified and classified. In addition, the loss and malfunction of functions provided by the IMA system should be considered in combination with the loss and malfunction of related functions provided by other aircraft and engine systems.
(2) Preliminary System Safety Assessment (PSSA).
(a) Based on the hazard classifications determined by the FHA, the proposed design and installation of the IMA system should be evaluated by a PSSA to establish the specific safety requirements of each component in the IMA system (for example, cabinet, rack, hardware modules, buses, connectors, displays, sensors, control devices, and functional software).
(b) The PSSA should establish the number, isolation features, and reliability of each component of the IMA system, including the power supplies, communication interfaces, displays, and controls that are required to protect the aircraft from the effects of random hardware failures. The system development assurance levels necessary to protect the aircraft and engine from design and development errors in the hardware and software of each hardware element should be determined. Unless extraordinary measures are provided (for example, physical and electrical isolation within a cabinet or rack) to protect an IMA cabinet or rack from commoncause failures (such as an electrical fire), all of the functions provided by a single IMA cabinet or rack should be assumed to fail as the result of a single failure. All functions that use any single hardware element (for example, printed wire board, connector, power supply, or wire bundle) should be assumed to fail as the result of a single failure. Loss of all functions in each IMA Page 10
cabinet or rack and/or hardware module should be addressed in the safety analysis, including common-cause issues.
(c) The PSSA should consider the fail-safe design techniques, as applicable for the aircraft type (for example, AC 25.1309-1 for Part 25 aircraft). The PSSA should ensure the effective use of design techniques in order to prevent single failures or other events from damaging or adversely affecting: (1) more than one IMA cabinet or rack, and/or (2) an IMA cabinet or rack and independent aircraft and engine systems performing operationally similar functions. To simplify the analysis, the IMA system should be installed to minimize the effects of its failures on other aircraft and engine systems. When considering such common-cause failures or other events, consequential or cascading effects should also be addressed. Some examples of such potential common-cause failures or other events include:
1. Rapid energy released from concentrated sources, such as uncontained failures of rotating parts (other than engines and propellers) or pressure vessels.
2. Pressure differentials.
3. Non-catastrophic structural failures.
4. Loss of environmental temperature control.
5. Disconnection of more than one sub-system or component by overtemperature protection devices.
6. Contamination by fluids.
7. Damage from localized fires.
8. Loss of power supply or return (for example, mechanical damage or deterioration of connections).
9. Excessive voltage.
10. Physical or environmental interactions among parts.
11. Errors (for example, design errors, operation errors, and maintenance errors).
12. Events external to the system or to the aircraft.
13. Uncontained engine and Auxiliary Power Unit rotorburst.
14. Uncontained propeller and propeller blade out.
15. Vibration due to engine or propeller blade out.
16. Tire burst.
17. Thrown tire tread.
18. Wheel rim release.
19. Runway debris.
20. Bird strike.
21. High Intensity Radiated Fields (HIRF).
22. Lightning.
23. Duct rupture.
24. Explosion (sabotage).
25. Release of stored energy (batteries, accumulators, and pressure bottles).
(d) See SAE ARP4761 for more information on recommended methods for conducting a Zonal Safety Analysis and a Particular Risks Assessment.
(e) The software level should be determined for all installed software. The software level may be determined using the procedures described in RTCA/DO-178B.
Additional guidance material for assigning software levels by aircraft category should be consulted (for example, AC 23.1309-1C for Part 23 airplanes). When the applicant uses system architectural features, as described in SAE ARP4754, to propose a lower software level than the level determined by the guidance contained in RTCA/DO-178B, the applicant should consult with certification authorities early in the program and obtain concurrence.
(f) If the IMA system contains electronic devices that cannot feasibly be evaluated by test and/or analysis, hardware design assurance levels should be identified using a functional failure path analysis, as described in Appendix B of RTCA/DO-254, Design Assurance Guidance for Airborne Electronic Hardware. The appropriate design assurance should be achieved for each complex electronic device using RTCA/DO-254 or other acceptable means of compliance.
(g) Failure probabilities of the protection scheme(s) must be commensurate with the failure condition classifications of the simultaneous malfunction of all IMA functions that it supports. The FAA recommends that design features that implement protection use both hardware and software means.
(3) System Safety Assessment (SSA). A systematic, comprehensive evaluation of the functions implemented by the IMA system, as installed in the aircraft, should be conducted to show that the relevant safety requirements identified in the PSSA have been met. This evaluation may include bench, ground, and flight tests to ensure assumptions made in the PSSA are correct. The SSA combines the results of a number of different analyses and tests to verify the safety of the overall system, as installed. The SSA should be conducted as described in SAE ARP4761. A typical SSA includes:
(a) A system description, including functions and interfaces.
(b) A list of failure conditions.
(c) The classification of each failure condition.
(d) Qualitative analysis of each failure condition.
(e) Quantitative analysis of each failure condition, as required.
(f) The results of common-cause analyses.
(g) Confirmation that any hazards associated with failure of the functions implemented in the IMA system, combined with the failure of other aircraft systems, have been addressed.
(h) Laboratory, simulator, and aircraft test (ground and flight) data, as appropriate, that substantiate flight crew recognition and response to failure conditions.
(i) An assurance that any failure modes of lower criticality functions that could adversely affect higher criticality functions are addressed.
(j) Confirmation that all software has been developed to the appropriate software level identified in the PSSA using the guidance of RTCA/DO-178B or other acceptable means of compliance.
(k) Confirmation that electronic devices whose functions cannot be feasibly evaluated by test and/or analysis have been developed to the hardware design assurance levels identified in the PSSA using the guidance of RTCA/DO-254 or other acceptable means of compliance.
10. CONFIGURATION MANAGEMENT GUIDANCE.
a. Configuration management and control in an IMA system is especially necessary because the system may contain many hardware elements and functional software components, with multiple approved configurations. Techniques to effectively manage and use the IMA architecture are necessary to safely provide system attributes, such as:
(1) Hosting multiple software applications on a single processor or on multiple, nondedicated processors.
(2) Producing and distributing hardware elements 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 elements with functional software components for efficient maintenance and incorporation of approved design changes.
(6) Allowing the stocking of generic, non-configured hardware elements for maintenance. A non-configured hardware element is one that does not already contain the functional software components needed for satisfying an aircraft, engine, or system function, and for installation. These hardware elements will later be loaded with field-loadable software.
(7) Providing the ability to update and maintain IMA system configuration files without corruption.
b. The TC/STC/ATC/ASTC applicant is responsible for the overall aircraft configuration management. A robust automated configuration management scheme for the IMA system may be required to support aircraft configuration management by monitoring incorrect assembly, configuration, or installation of hardware elements in the cabinet or rack. A key feature of the robust automated configuration management system is to monitor correct configuration of hardware elements that implement field-loadable software used throughout the IMA system.
c. IMA systems that do not include field-loadable software may not need a robust automated configuration management scheme when other means (such as, mechanical interlocks or keyed connectors) are implemented.
d. When field-loadable software is loaded into the IMA system, a robust automated configuration management scheme is required to enable the safe operation and maintenance of an IMA system with some or all of the features described in 10a above. This scheme, along with any necessary manual inspections, must guarantee that the configuration of the software components loaded is identical to what was approved under the TC, STC, ATC, or ASTC process. The scheme must also be able to identify improper configuration of the hardware elements and software components in the IMA system. Improper configuration of the hardware elements and software components in the IMA system must be annunciated to the flight crew until appropriate maintenance action has been taken. In addition, the automated configuration management scheme should provide a means to verify that the software components and hardware elements of the system are correctly configured for the aircraft on which they are Page 14
installed (for example, the automated configuration management system should ensure that the correct software is loaded into the correct hardware element(s) and is installed in the correct rack or cabinet location).
e. Any loss of functionality caused by the protection mechanisms of the configuration management system must be shown to be acceptable through the aircraft-level safety assessment and Master Minimum Equipment List (MMEL).
f. If individual hardware elements require direct interfaces to the aircraft, engine, or other equipment with mechanical connector(s), the applicant must show that each interface, by either mechanical means or automated electronic monitoring, will prevent or detect an incorrect connection at power up.
g. TC/STC/ATC/ASTC applicants must provide appropriate field-loading procedures that ensure that the proper software is always correctly loaded on the aircraft. This procedure should not rely on a single action to verify that the correct software version has been loaded. For example, (1) a procedure may be added to the Aircraft Flight Manual (AFM) or Aircraft Flight Manual Supplement (AFMS) requiring the pilot to verify the part number of the IMA system, or
(2) a procedure may be implemented to support critical maintenance items, per 14 CFR § 121.369, requiring duplicate inspection.
h. All changes to an IMA system, whether the change is major or minor (by either the TSO definition (14 CFR § 21.611) or the TC definition (14 CFR § 21.93)), should be evaluated and tracked by the TC/STC/ATC/ASTC holder. The results of the change evaluation should be included in the type design data package for the change. Additional guidance on the change process is included in section 20c of this AC. The following configuration management items should be considered when making changes:
(1) All software changes in the hardware elements, whether major or minor, should be tracked by the automated configuration management system.
(2) Hardware changes to hardware elements that do not affect weight, balance, structural strength, reliability, operational characteristics, or other characteristics affecting airworthiness of the aircraft (for example, change of resistor manufacturer) may be approved as a minor change to the TSO-C153 authorization. The change should at least result in a modification status update to the hardware element and should be tracked by the TC/STC/ATC/ASTC applicant.
(3) All major hardware changes to hardware elements should be tracked by the automated configuration management system. However, minor hardware changes to hardware elements need not be tracked by the automated configuration management system.
11. ELECTRONIC IDENTIFICATION GUIDANCE.
a. Identification of software components field-loaded into hardware elements must be implemented by electronic means, unless the automated configuration management system is unnecessary per 10c above. Electronic identification markings consist of identifying software components by electronically embedding the identification within software installed on the hardware element, rather than on the equipment nameplate.
b. Electronic software part numbers and versions must be verifiable through an electronic query, such as an electronic display. Software part number configuration errors must be annunciated to the flight crew until appropriate maintenance action has been taken.
c. 14 CFR § 21.607 requires TSO’d equipment to be permanently and legibly marked with specific information. Compliance to 14 CFR § 21.607 can be demonstrated when the information required to be included is provided by an electronic identification query system stored in non-volatile memory. This approach is commonly referred to as an “electronic TSO nameplate.” The electronic identification system must be verifiable on-board the aircraft, when the aircraft is on the ground at any geographic location, and must provide the specific information required by 14 CFR § 21.607 for all applicable functional TSOs being integrated.
d. Electronic identification may also provide software component and hardware element revision or modification status information and RTCA/DO-178B software level which can be used to demonstrate conformity to type design configuration.
e. Information identifying the location of each hardware element must be included in the electronic identification since configuration is dependent on the specific location of each hardware element within the cabinet or rack. This requirement can be satisfied when the automated configuration management scheme tracks and protects the IMA system configuration by ensuring hardware elements are properly located.
f. All hardware elements that support a functional TSO must have a physical TSO nameplate (either a TSO-C153 or a functional TSO nameplate). Even when electronic identification (that is, electronic nameplate) is used, a physical TSO nameplate (either functional TSO or TSO-C153) must be included on supporting hardware elements.
g. The verification of electronic identification information is an acceptable alternative to physical verification of hardware part number and revision/modification status. Electronic means may be used in lieu of verifying dataplates on each hardware element, if all required information is available electronically. Electronic identification does not replace hardware element and software conformity inspections that determine the elements and components are produced in conformity to type design.
h. Operators should establish a separate process that records the IMA system configuration (for example, identification and revision status of hardware elements and software components).
This information should be kept up-to-date and maintained off-board the aircraft.
TC/STC/ATC/ASTC applicants should define the process as part of their instructions for continued airworthiness (per 14 CFR § XX.1529, where XX may be 14 CFR parts 23, 25, 27, or
29). Operators should maintain the information as part of their maintenance program.
NOTE: Order 8150.1 (see the most current edition) provides additional information on TSO part marking.
12. SOF TWARE GUIDANCE.
a. S oftware Assurance. All software used in IMA systems should be developed to the guidance of RTCA/DO-178B, Software Considerations in Airborne Systems and Equipment Certification, dated December 1, 1992, or another acceptable means of compliance, as agreed to between the applicant and the cognizant FAA Aircraft Certification Office (ACO).
b. Soft ware Levels. The software levels for all software should be determined by the appropriate safety assessments (see section 9 of this AC) and any additional requirements, such as those specified by functional TSOs.
c. Field-Loadable Software (FLS).
(1) Many IMA systems utilize Field-Loadable Software (FLS) as part of the TC/STC/ASC/ASTC installation. FLS is software that can be loaded without removal of the equipment from the aircraft installation. FLS might also include software loaded into a line replaceable unit (LRU) or hardware element at a repair station or shop. FLS can refer to either executable code or data. When obtaining certification approval for utilization of the FLS capability, the applicant should consider the following guidance:
(a) The FLS should meet the objectives and guidance of RTCA/DO-178B or another acceptable means of compliance, as agreed to between the applicant and the cognizant ACO.
(b) The software should be loaded on the target computer and hardware configuration that the software was verified on for the approval.
(c) To ensure that the FLS is loaded in the proper configuration, there must be a robust automated configuration management scheme (as described in paragraphs 10b through 10e of this AC) to ensure that the installation configuration (that is, software part number(s), the hardware part number(s), the aircraft model, and the aircraft serial number combination, as applicable) is the configuration approved during the TC, ATC, STC, ASTC, or TSO authorization process.
(d) If redundant functions of the IMA system are field-loadable, the applicant should ensure that the redundant functions have the same software configuration, unless intermixing of different software configurations is supported by the safety assessment and has been approved for the aircraft configuration and type design.
(e) There should be a process to assure that the software loaded is the software approved and that it has not been corrupted (for example, verification with an appropriate data transfer integrity check, such as a cyclic redundancy check). Different data integrity algorithms give different assurances that the data transferred are correct. The applicant should assure that the algorithm used is commensurate with the integrity required for the software level of the data being loaded.
(f) If the applicant proposes more than one medium for loading of FLS (such as diskette, mass storage device, or compact disk), loading from all mediums should comply with the guidance in this section.
(g) The applicant should demonstrate the ability to verify the airborne equipment software part numbers with onboard equipment, carry-on equipment, an automated configuration management system, or other appropriate means.
(h) Loading protection mechanisms should be implemented to inhibit loading FLS during flight.
(i) If FLS is loaded onto a hardware element that previously had software loaded, the out-of-configuration software component(s) on the hardware element should be removed prior to loading the new FLS, in order to prevent the existence of unapproved or out-ofconfiguration code.
(j) All changes to FLS should be submitted to the cognizant ACO for review and approval.
(2) FLS installation documents should specify the following elements:
(a) The aircraft and hardware applicability and intermixability allowances for redundant systems that load software.
(b) Verification procedures to ensure that the software was correctly loaded into an approved and compatible target computer and memory device(s).
(c) Any post load verification and/or test procedures required to show compliance to the guidelines specified in this AC.
(d) Actions to be taken in the event of an unsuccessful load (for example, prohibit dispatch of aircraft).
(e) Reference to an approved loading procedure.
(f) Maintenance record entry procedures required to maintain configuration control.
(g) Reference to the AFM, AFMS, or Operator’s Manual, as appropriate.
d. Partitioning and Protection.
(1) IMA systems may combine many functions of different software levels on the same target computer or hardware element. Per RTCA/DO-178B, higher-level software must be partitioned and/or protected in such a way that lower-level software cannot affect the memory locations allocated to the higher-level software or otherwise interfere with the computation of its functions (that is, there must be both time and space protection). It should be noted that functions operating on the same hardware may need to be partitioned and/or protected to support fail-safe designs and safety requirements, even if they are the same software level. It is recommended that design features that implement protection and partitioning use both hardware and software means.
(2) IMA systems typically contain many functions, often using the same computer resources (for example, real-time operating systems, memory, and input/output devices). A function can affect the operation of other functions by affecting the timing, the space (that is, memory), or the performance behavior of the other functions. When partitioning is used as the means of protection for the computer resources in an IMA system, the applicant should demonstrate the partitioning in both the time and space domains.
(3) As a minimum, when evaluating timing properties, the following items should be considered to demonstrate that functions either have no effect or that their effect is acceptable based on the identified safety parameters:
(a) Interrupts and interrupt inhibits (software and hardware).
(b) Loops (for example, infinite loops or indirect non-terminating call loops).
(c) Real-time correspondence (for example, frame overrun, interference with realtime clock, counter/timer corruption, pipeline and caching, deterministic scheduling).
(d) Loss, corruption, or delay of input or output data (timing aspects).
(e) Control flow defects (timing aspects) (for example, incorrect branching into a partition or protected area, corruption of a jump table, corruption of the processor sequence control, corruption of return addresses, unrecoverable hardware state corruption (for example, mask and halt)).
(f) Memory, input, and/or output contention.
(g) Data flags.
(h) Software traps (for example, divide by zero, un-implemented instruction, specific software interrupt instructions, unrecognized instruction, and recursion termination).
(i) Hold-up commands (such as, performance hedges).
(4) As a minimum, when evaluating space properties, the following items should be considered to demonstrate those functions either have no effect or that their effect is acceptable based on the identified safety parameters:
(a) Loss, corruption, or delay of input or output data (memory aspects).
(b) Memory overflow.
(c) Corruption of internal data (for example, direct or indirect memory writes, table overrun, incorrect linking, calculations involving time, or corrupted cache memory).
(d) Memory mapping errors.
(e) Program overlays.
(f) Buffer sequence.
(g) External device interaction (for example, loss of data, delayed data, incorrect data, or protocol halts).
(h) Control flow defects (space aspects) (for example, incorrect branching into a partition or protected area, corruption of a jump table, corruption of the processor sequence control, corruption of return addresses, or unrecoverable hardware state corruption).
(i) Partition address violations.
e. S oftware Reuse. IMA systems frequently implement reusable software. If software is reused, the following items should be assured:
(1) The software life cycle data being considered for reuse has not changed since its previous approval.
(2) The required software level of the software application(s) is equal to, or less than, the software level of the previous approval.
(3) The range and data type of inputs to the configuration item are equivalent to its approved predecessor.
(4) The configuration item being reused is resident on the same target computer and used in the same way operationally as it was for the previous approval.