# AC 20-145: Guidance for Integrated Modular Avionics (IMA) that Implement TSO-C153 Authorized Hardware Elements - Type: Advisory circular (guidance, not mandatory unless a rule or AD requires it) - Status: Historical - Approved: February 25, 2003 - Last reviewed: August 24, 2004 - Family: AC 20-145 - Cancelled by: [AC 20-170](https://openairdocs.org/ac/20-170) - 14 CFR parts: 23, 25, 27, 29, 33, 35 - Pages: 50 - PDF: https://openairdocs.org/files/sha256/c2/2a/c22a6c412e5b7d06054eb10e9c3680108461d560be6a20d0644668e138ecd1f4 - FAA DRS: https://drs.faa.gov/browse/excelExternalWindow/D569727B55EDE92786256CE80076E82B.0001 - DRS record last changed: November 21, 2025 - Page: https://openairdocs.org/ac/20-145 ## Versions - [AC 20-145](https://openairdocs.org/ac/20-145) (Historical), approved Feb 25, 2003, 50 pages ## Text Each page's text from the PDF; open the PDF at a page with #page=N. ### Page 1 AC 20-145 **GUIDANCE FOR INTEGRATED MODULAR AVIONICS (IMA) THAT IMPLEMENT TSO-C153 AUTHORIZED** **HARDWARE ELEMENTS** Date: 2/25/03 ### Page 3 **TABLE OF CONTENTS** 1. PURPOSE … 1 2. RELATED DOCUMENTS … 1 a. Code of Federal Regulations … 1 b. FAA Technical Standard Orders (TSO) … 1 c. FAA Policy Documents … 2 d. FAA Advisory Circulars (AC) … 2 e. RTCA, Inc. Documents … 3 f. SAE Documents … 3 3. DEFINITIONS … 3 4. ACRONYMS … 5 5. SCOPE … 6 6. BACKGROUND … 7 7. DOCUMENT OVERVIEW … 7 8. IMA SYSTEM APPROVALS AND AUTHORIZATIONS … 7 a. TSO-C153 Authorization … 8 b. Functional TSO Authorization … 8 c. I nstallation Approval … 9 9. SAFETY ASSESSMENT PROCESS GUIDANCE … 9 10. CONFIGURATION MANAGEMENT GUIDANCE … 13 11. ELECTRONIC IDENTIFICATION GUIDANCE … 16 12. SOFTWARE GUIDANCE … 17 a. Software Assurance … 17 b. Software Levels … 17 c. F ield-Loadable Software (FLS) … 17 d. Partitioning and Protection … 19 e. Software Reuse … 20 13. ELECTRONIC HARDWARE GUIDANCE … 21 14. IMA DESIGN GUIDANCE … 21 a. Electrical Power for IMA Systems … 21 b. Recovery Features … 21 c. Built-In Test (BIT) … 22 Page i ### Page 4 d. Maintenance Diagnostics … 22 e. F ailure Detection and Annunciation … 22 f. F unctional Partitioning … 22 g. F unctional Isolation … 22 h. Intentional Transmitters … 22 i. Visual and Aural Alerting … 22 15. ENVIRONMENTAL QUALIFICATION GUIDANCE … 23 Figure 15-1. RTCA/DO-160D Environmental Qualification Requirements … 25 16. HUMAN FACTORS AND FLIGHT CREW INTERFACE GUIDANCE … 25 a. Human Factors Background … 25 b. Potential Human Factors and Flight Crew Interface Issues with IMA Systems … 26 c. Testing Considerations for Human Factors and Flight Crew Interface Issues … 30 d. Methods of Compliance with Controls Regulations … 30 17. TESTING PRACTICES … 32 a. IMA Hardware Element Testing … 32 b. Individual System Testing … 32 c. IMA System Integration Testing … 33 d. Aircraft Ground Testing … 34 e. Aircraft Flight Testing … 34 f. Configuration Control During Flight Testing … 35 18. ROLES AND RESPONSIBILITIES OF IMA SYSTEM APPLICANTS … 36 a. TSO-C153 Applicant Roles and Responsibilities … 36 b. Functional TSO Applicant Roles and Responsibilities … 37 c. TC, STC, ATC, ASTC Applicant Roles and Responsibilities … 38 19. ADDITIONAL GUIDANCE FOR THIRD-PARTY MANUFACTURERS … 39 20. AIRWORTHINESS CONSIDERATIONS … 41 a. Initial Installation … 41 b. Follow-on Installations … 41 c. Change Impact Analysis … 42 d. Change Classification … 43 21. MAINTENANCE AND CONTINUED AIRWORTHINESS GUIDANCE … 43 a. Maintenance Instructions … 43 b. Maintenance Diagnostics … 43 c. Master Minimum Equipment List (MMEL) … 43 APPENDIX 1. PARTIAL LIST OF FUNCTIONAL TSOs Page ii ### Page 5 Subject: GUIDANCE FOR **INTEGRATED MODULAR** **AVIONICS (IMA) THAT IMPLEMENT TSO-C153** **AUTHORIZED HARDWARE** ELEMENTS Date: 2/25/03 Initiated By: AIR-100 AC No: 20-145 Change: **1. P URPOSE.** a. This advisory circular (AC) establishes an acceptable means, but not the only means, to obtain Federal Aviation Administration’s (FAA) airworthiness approval for the installation of an Integrated Modular Avionics (IMA) System that uses hardware elements authorized under Technical Standard Order (TSO)-C153, Integrated Modular Avionics Hardware Elements. The FAA’s TSO process is a means for obtaining FAA design and production approval for an appliance, system, or product; however, the TSO authorization does not provide installation approval. This AC provides guidance for applicants involved in the integration, installation, certification, and continued airworthiness of IMA systems into an aircraft or engine, when the IMA system utilizes hardware elements that comply with TSO-C153. The guidance applies to the entire IMA system, not just the hardware elements. The guidance is specific to installations of these systems on aircraft or engines approved under Title 14 of the Code of Federal Regulations (14 CFR) parts 23, 25, 27, 29, 33, and 35. b. The means of compliance presented in this AC is not mandatory; therefore, the term “must” used in this AC only applies to an applicant who follows this particular means of compliance and TSO-C153. 2. RELATED DOCUMENTS. The latest amendments of the following publications are the primary reference tools when using this AC: a. Code of Federal Regulations. Title 14 CFR parts 21, 23, 25, 27, 29, 33, 35, 91, 121, and 135. b. FAA Technical Standard Order (TSO). Copies of TSOs may be obtained from the Department of Transportation, FAA, Aircraft Certification Service, Aircraft Engineering Page 1 ### Page 6 Division, AIR-100, 800 Independence Avenue, SW, Washington, D.C. 20591, or from the FAA website at http://av-info.faa.gov/tso. The following TSO is relevant to this AC: /g183 TSO-C153, Integrated Modular Avionics Hardware Elements. c. FAA Policy Documents. The following policy documents are relevant to this AC: (1) Order 8150.1, Technical Standard Order Program. (2) Order 8110.4, Type Certification. (3) Policy Statement PS-ANM100-2003-01-03, Factors to Consider When Reviewing an Applicant’s Proposed Human Factors Methods of Compliance for Flight Deck Certification. (4) Policy Statement PS-ANM111-1999-99-2, Guidance for Reviewing Certification Plans to Address Human Factors for Certification of Transport Airplane Flight Decks. (5) Policy Statement PS-ACE100-2001-004, Guidance for Reviewing Certification Plans to Address Human Factors for Certification of Part 23 Small Airplanes. NOTE: Copies of FAA orders, advisory circulars, and policy statements are also available from the FAA website at http://www.airweb.faa.gov/rgl. d. FAA Advisory Circulars (AC). Copies of ACs may be obtained from the Department of Transportation, Subsequent Distribution Office, SVC-121.23, Ardmore East Business Center, 3341 Q 75th Ave, Landover, MD 20785. The following ACs are relevant to this AC: (1) AC 20-88, Guidelines on the Marking of Aircraft Powerplant Instruments (Displays); (2) AC 20-115, Radio Technical Commission for Aeronautics, Inc. (RTCA) Document RTCA/DO-178B; (3) AC 21-16, RTCA Document DO-160D; (4) AC 21-40, Application Guide for Obtaining a Supplemental Type Certificate; (5) AC 23.1309-1, Equipment, Systems, and Installations in Part 23 Airplanes; (6) AC 23.1311-1, Installation of Electronic Displays in Part 23 Airplanes; (7) AC 25-11, Transport Category Airplane Electronic Display Systems; (8) AC 25.1309-1, System Design and Analysis; ### Page 7 (9) AC 27-1, Certification of Normal Category Rotorcraft; (10) AC 29-2, Certification of Transport Category Rotorcraft; (11) AC 33.28-1, Compliance Criteria for 14 CFR § 33.28, Aircraft Engines, Electrical and Electronic Engine Control Systems; and (12) AC 120-64, Operational Use and Modification of Electronic Checklists. NOTE: Other ACs may be applicable, depending on the functions being implemented in the IMA system. e. RTCA, Inc. Documents. Copies of RTCA documents may be purchased from RTCA, Inc., 1828 L Street, NW, Suite 805, Washington, D.C. 20036. Alternatively, copies may be purchased on-line at http://www.rtca.org. RTCA documents referenced in this AC are: (1) RTCA/DO-160D, Change 2, Environmental Conditions and Test Procedures for Airborne Equipment; (2) RTCA/DO-178B , Software Considerations in Airborne Systems and Equipment Certification; (3) RTCA/DO-254, Design Assurance Guidance for Airborne Electronic Hardware; and (4) RTCA/DO-257, Minimum Operational Performance Standards for the Depiction of Navigation Information on Electronic Maps. f. SA E Documents. Copies of Society of Automotive Engineers (SAE) documents may be purchased from SAE, 400 Commonwealth Drive, Warrendale, PA 15096-0001. Or, copies may be purchased on-line at http://www.sae.org/. The following SAE documents are referenced in this AC: (1) Aerospace Recommended Practice (ARP) 4754, Certification Considerations for Highly-Integrated or Complex Aircraft Systems; and (2) ARP4761, Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment. **3. DE FINITIONS.** a. Cognizant Aircraft Certification Office (ACO). The ACO granting the certificate or TSO authorization for the specific product, system, or appliance. ### Page 8 b. Design Assurance. All planned and systematic actions and data that substantiate that hardware or software correctly performs its intended function(s) and that design errors have been identified and corrected such that the hardware or software satisfies the applicable certification basis. c. Devel opment Assurance. All planned and systematic actions used to substantiate that development errors have been identified and corrected such that the system satisfies the applicable certification basis. d. F unctional Software. Software applications that will be approved as part of a functional TSO authorization or as part of a type certification effort. This software is sometimes referred to as operational software, application software, or flight software. e. F unctional TSO. A TSO with a defined functionality. Examples of functional TSOs are listed in appendix 1 of this AC. TSO-C153 is not considered a functional TSO, because hardware elements typically do not have system-level functionality. f. Functional TSO Applicant. The applicant seeking functional TSO authorization. g. H ardware Element. A hardware element (as defined in TSO-C153) is: (1) a hardware module, or (2) cabinets or racks that host hardware modules. TSO-C153 authorization of a hardware element is not considered a functional TSO authorization. NOTE: This definition may differ from terminology in other documents (for example, RTCA/DO-254). h. IM A System. For this AC, an IMA system encompasses all components (such as, hardware elements, software, displays, control devices, sensors, receivers, and transmitters) needed to make the aircraft or engine system functional and operational. i. P artitioning. The process of separating, usually with the express purpose of isolating one or more attributes of a function, to prevent specific interactions and cross-coupling interference. The terms “partitioning” and “protection” are often used interchangeably; however, partitioning is typically considered a means of protection. j. P rotection. A concept that ensures the separation of avionics functions so that a fault in one function cannot affect another. Protection is typically considered a superset of partitioning; however, the two terms are often used interchangeably. k. Red Label Unit. For this AC, a red label unit is one that contains hardware and/or software that does not yet have FAA approval. l. S oftware Component. A functional software file that is loaded into the IMA system. ### Page 9 m. S takeholders. All the entities involved in the development, integration, and certification of the IMA system. Stakeholders mentioned in this AC are the hardware element manufacturer, the functional TSO applicant, the IMA system integrator, the type certification applicant, the certification authority, and any other manufacturer involved in the IMA system development or integration. n. System Configuration File. A data file loaded into the IMA system. It typically defines the IMA system, rack, or cabinet configuration; provides means of checking that the system is correctly configured and that the correct software has been successfully loaded; provides parameters for checking that system and hardware module resource management protection features are functioning properly; and performs other related functions. o. Third-Party Manufacturer. For this AC, a third-party manufacturer is a developer of a hardware module to be installed into a rack or cabinet that has TSO-C153 authorization, and who is not the rack or cabinet manufacturer nor the IMA system integrator. The hardware module may or may not have an associated TSO authorization. p. TSO-C153 Applicant. The applicant seeking TSO-C153 authorization. q. Type Certificate (TC), Supplemental TC (STC), Amended TC (ATC), or Amended STC (ASTC) Applicant. The applicant seeking type certification approval using the TC, STC, ATC, or ASTC process. For purpose of this document, the TC, STC, ATC, or ASTC applicant is denoted as TC/STC/ATC/ASTC applicant. 4. ACRONYMS . The following acronyms are used in this AC: 14 CFR Title 14 of the Code of Federal Regulations AC Advisory Circular ACO Aircraft Certification Office AFM Aircraft Flight Manual AFMS Aircraft Flight Manual Supplement ARP Aerospace Recommended Practice ASTC Amended Supplemental Type Certificate ATC Amended Type Certificate BIT Built-In Test CCD Cursor Control Device CFR Code of Federal Regulations DOA Delegation Option Authorization DAS Designated Alteration Station EQT Environmental Qualification Test FAA Federal Aviation Administration FHA Functional Hazard Assessment FLS Field-Loadable Software GPS Global Positioning System HIRF High Intensity Radiated Fields Page 5 ### Page 10 IMA Integrated Modular Avionics MCDU Multifunction Control and Display Unit MLS Microwave Landing System MMEL Master Minimum Equipment List MPS Minimum Performance Standard ODAR Organizational Designated Airworthiness Representative PSCP Project-Specific Certification Plan PSSA Preliminary System Safety Assessment RF Radio Frequency SAE Society of Automotive Engineers SSA System Safety Assessment STC Supplemental Type Certificate TC Type Certificate TCAS Traffic Alert and Collision Avoidance System TSO Technical Standard Order **5. SCOP E.** a. IMA systems using TSO-C153 require consideration by all stakeholders involved (for example, the hardware element manufacturer, the functional TSO applicant, the IMA system integrator, the type certification applicant, and the FAA). This AC provides guidance for applicants involved in the integration, installation, certification, and continued airworthiness of IMA systems that use TSO-C153 authorized hardware elements in aircraft or engines. The guidance of this AC is focused on applicants who implement or interface with TSO-C153 authorized hardware elements. It should be noted that TSO-C153 authorization does not provide functional approval nor installation approval. This AC applies to the installation, integration, certification, and continued airworthiness of the entire IMA system, including the hardware elements. This AC provides guidance for an IMA system installed on an aircraft to provide aircraft or engine system functions. It addresses the integration of hardware elements, software, displays, sensors, control devices, and any other components needed to ensure the aircraft or engine systems operate properly and safely. b. The TC/STC/ATC/ASTC applicant is ultimately responsible for showing compliance to the applicable 14 CFR parts for their aircraft or engine. The IMA system may include subsystems that may or may not have TSO authorization. The applicability of TSO authorization to various portions of the IMA system should be handled like any other TSO application and authorized accordingly by the FAA. The IMA system must be approved as part of a TC/STC/ATC/ASTC project. c. While this AC is focused on IMA systems that use TSO-C153 authorized hardware elements, much of the guidance may also be useful for IMA systems that do not use these hardware elements. ### Page 11 **6. B ACKGROUND.** a. IMA systems, depending on the specific aircraft or engine application, can combine many functions that have historically been contained in functionally and physically separated systems. The integration of many functions and the implementation of hardware elements present several obstacles for compliance to the regulations. This AC provides a means of compliance to the regulations for applicants involved in the integration, installation, certification, and continued airworthiness of IMA systems for an aircraft or engine. b. TSO-C153 identifies two types of hardware that are considered hardware elements: (1) hardware modules and (2) cabinets/racks that host hardware modules. The hardware elements that do not have TSO-C153 authorization can also be integrated into IMA systems, if they meet the environmental, interoperability, and regulatory requirements of the installation (that is, they are approved as part of the TC/STC/ATC/ASTC). c. Hardware elements authorized under TSO-C153 may contain software to enable electronic part marking and/or future loading of functional software. The hardware elements manufactured to comply with TSO-C153 may be used in support of functional TSOs (for example, a Global Positioning System, TSO-C129) or systems approved under 14 CFR parts 23, 25, 27, 29, 33, or 35 (for example, a braking system approved as part of a type certificate (TC)). d. Field-loadable software (FLS) may be loaded into TSO-C153 authorized hardware elements to support functional TSO or aircraft-level functionality. The FLS must be approved via the functional TSO and/or the TC/STC/ATC/ASTC. Loading the TSO-C153 authorized hardware elements with approved software is not considered an alteration to the hardware element – instead, it is considered part of the installation process. 7. DOCUMENT OVERVIEW. The following sections are included in this AC: a. Sections 8 through 17 provide guidance on specific technical areas to be addressed by integrators and installers of IMA systems. b. Section 18 provides guidance on the roles and responsibilities of the multiple stakeholders in the certification, integration, and installation process. c. Section 19 provides guidance to third-party manufacturers. d. Section 20 provides guidance regarding the airworthiness considerations of IMA systems. e. Section 21 provides guidance regarding the maintenance and continued airworthiness of IMA systems. 8. IMA SYSTEM APPROVALS AND AUTHORIZATIONS. Integration, installation, and certification of an IMA system on an aircraft may use hardware and software that has undergone Page 7 ### Page 12 several levels of design and approval. Three types of authorization or approval will typically be applicable: a. TSO-C153 Authorization. In order to receive TSO-C153 authorization, the applicant must demonstrate that the hardware element being authorized meets the minimum hardware performance standards and the defined subset of RTCA/DO-160D environmental qualification requirements in TSO-C153. TSO-C153 authorization does not provide functional approval nor installation approval. b. Functional TSO Authorization. (1) A functional TSO authorization is for a TSO with a defined functionality (for example, air data computer, TSO-106). Other examples of functional TSOs are listed in appendix 1 of this AC. TSO-C153 is not considered a functional TSO, because these hardware elements do not have system-level functionality. The TSO-C153 and functional TSO applicants may be different entities. The functional TSO applicant must demonstrate that the IMA system, when loaded with the functional software, meets all applicable requirements of the functional TSO. Additionally, all environmental qualification testing must be carried out for the functional TSO. The environmental qualification may include selected environmental qualification tests performed as part of the TSO-C153. (2) The configuration of all software components and hardware modules installed in TSO-C153 authorized cabinets or racks must be identified in the type design defined for the particular aircraft or engine model. Additionally, the software and hardware must conform to that type design. (3) Functional TSO authorization supported by hardware modules authorized under TSO-C153 is granted for the specific system configuration, not for individual hardware modules. That is, a functional TSO may be comprised of multiple hardware elements with the appropriate loaded functional software. (4) A functional TSO authorization (for example, a Global Positioning System (GPS) hardware module that includes the functional software) may be obtained on a hardware element to be installed in a TSO-C153 authorized rack or cabinet. In this case, a hardware element without TSO-C153 authorization must be identified with the functional TSO markings. (5) TSO authorization is not an authorization to install either the TSO-C153 hardware element or a functional TSO authorized system in an aircraft. (6) Some functional TSO applications may be aircraft-specific (that is, they only apply to one aircraft type). These aircraft-specific TSO applications must meet the minimum performance standards (MPS) of the applicable TSO(s). (7) Order 8150.1 (see the most current edition) provides additional information on TSO procedures. ### Page 13 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: ### Page 14 (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 ### Page 15 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. ### Page 16 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. ### Page 17 (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: ### Page 18 (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 ### Page 19 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. ### Page 20 **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. ### Page 21 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. ### Page 22 (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. ### Page 23 (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. ### Page 24 (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. ### Page 25 (5) Equivalent software/hardware integration testing and system testing were conducted on the target computer and system as in the previous approval. (6) Software life cycle data have been shown to have no adverse effect on (1) the original systems safety margins and (2) the original operational capability, unless accompanied by a justifiable increase in safety. If software life cycle data intended for reuse adversely affect safety or exceed a pre-approved range of data, parameters, or equipment performance characteristics, then it will not be approved for reuse. The software life cycle data would require design approval under the applicable paragraph of 14 CFR. (7) All open problem reports and in-service problems associated with the software to be reused should be analyzed to ensure that there are no safety or operational issues. 13. ELECTRONIC HARDWARE GUIDANCE. If the IMA system contains electronic devices whose functions cannot feasibly be evaluated by test and/or analysis, the electronic devices should comply with RTCA/DO-254, or other acceptable means of compliance, as agreed to by the cognizant ACO. **14. IMA DESIGN GUIDANCE.** a. Electrical Power for IMA Systems. (1) IMA cabinet or rack installations should show compliance with XX.1357 (where XX may be 14 CFR parts 23, 25, 27, or 29) or provide supporting data to justify an equivalent level of safety finding. For part 25 aircraft, circuits that do not directly comply with 25.1357(e) may be acceptable if the failure effects are minor. (2) Design of the physical architecture should support the ability to manage smoke or fire without losing functions whose loss is catastrophic. (3) The IMA cabinet or rack should not be powered with circuit protection features that are under control of that IMA cabinet or rack. (4) If redundant IMA hardware elements are used to provide functions, individual nonresettable fuses or circuit breakers may be provided for each IMA hardware element. The applicant should provide supporting data in the aircraft-level SSA to verify that operation of the circuit device does not cause a loss of a function. The applicant must provide an analysis to demonstrate appropriate availability in compliance with XX.1309 (where XX may be 23, 25, 27, or 29) to justify an equivalent level of safety finding. b. Recovery Features. IMA systems should be designed to provide capabilities to initiate recovery of functions whose loss is catastrophic. IMA systems should be designed to avoid the need for crew-initiated recovery features. If crew-initiated recovery features are implemented, protective mechanisms and operational procedures should be in place to prevent accidental Page 21 ### Page 26 activation of the recovery feature. Effects of recovery feature activation in normal and failed conditions must be evaluated for all phases of flight. c. Built-In Test (BIT). BIT features are recommended to limit exposure time to latent failures. If pilot-initiated BIT features are provided, there should be provisions (for example, interlocks) to prevent interference with control functions (for example, flight controls, autopilots, and engine controls). Activation of BIT features intended only for ground operations should be inhibited during flight. d. Mai ntenance Diagnostics. It is recommended that the IMA system provide means to detect and record failures of hardware elements and to isolate these failures to the IMA hardware module that has failed in order to facilitate maintenance of the IMA system. Procedures for isolating the problems to the module-level are recommended. Activation of maintenance diagnostic software intended for ground operations should be inhibited during flight. e. Failure Detection and Annunciation. Failures that affect functions provided by the IMA system should be detected and annunciated to the flight crew with alerting and indication means for warning, caution, or advisory information appropriate for the failure effects. f. F unctional Partitioning. It is recommended that IMA systems that integrate multiple functions within a single processor implement partitioning among functions to reduce complexity and provide fault containment. This is recommended even if all of the software is developed to the same software level. g. F unctional Isolation. To enable continued use of the working IMA functions in the event of a failed function, it is recommended that IMA systems that integrate multiple functions incorporate a means that allows the failed function(s) to become disabled while other working functions remain operational. h. Int entional Transmitters. Intentional transmitters should not be installed in TSO-C153 authorized racks or cabinets. i. Visual and Aural Alerting. Because of the integrated nature of IMA systems, the visual and aural alerting systems must be carefully designed and evaluated. For example: (1) The presentation of visual and aural alerts should be prioritized (including addressing simultaneous alerts). (2) A means should be provided to disable nuisance and distracting aural and visual alerts. There should be an annunciation to the flight crew that the alerts have been disabled, until they are rearmed. (3) The visual and aural alerts should be included as part of the human factors and flight crew interface evaluations. ### Page 27 **15. ENVIRONMENTAL QUALIFICATION GUIDANCE.** a. Appendix 1 of TSO-C153 lists environmental qualification tests (EQT) that should be performed to satisfy the TSO. The TSO EQTs are performed according to procedures and category levels defined in RTCA/DO-160D (Change 2). The category levels tested should be selected, as appropriate, for the aircraft installation and environment. The EQTs performed as part of TSO-C153 should be applicable to the functional TSO environmental qualification and may be applied to the aircraft TC, STC, ATC, or ASTC environment qualification. Figure 15-1 lists the RTCA/DO-160D environmental tests that can be accomplished under TSO-C153 authorization and how they may affect functional TSO authorization or aircraft installation approval. Figure 15-1. RTCA/DO-160D Environmental Qualification Requirements RTCA/ DO-160D Section # RTCA/DO-160D Section Title TSO-C153 Requirement Functional TSO or Aircraft Installation Requirement 4 Temperature and Altitude – Temperature Not tested Yes 4 Temperature and Altitude – Altitude Yes Yes, TSO-C153 qualification data may be used by similarity 5 Temperature Variation Not tested Yes 6 Humidity Yes Yes, TSO-C153 qualification data may be used by similarity 7 Operational Shock and Crash Safety – Operational Shock Not tested Yes 7 Operational Shock and Crash Safety – Crash Safety Yes Yes, TSO-C153 qualification data may be used by similarity 8 Vibration Not tested Yes 9 Explosion-proofness Yes, if appropriate Yes, TSO-C153 qualification data may be used by similarity 10 Waterproofness Yes, if appropriate Yes, TSO-C153 qualification data may be used by similarity 11 Fluid Susceptibility Yes, if appropriate Yes, TSO-C153 qualification data may be used by similarity 12 Sand and Dust Yes, if appropriate Yes, TSO-C153 qualification data may be used by similarity 13 Fungus Resistance Yes, if appropriate Yes, TSO-C153 qualification data may be used by similarity 14 Salt Spray Yes, if appropriate Yes, TSO-C153 qualification data may be used by similarity 15 Magnetic Effect Yes Yes, TSO-C153 qualification data may be used by similarity 16 Power Input Not tested Yes 17 Voltage Spike Yes Yes, TSO-C153 qualification data may be used by similarity 18 Audio Susceptibility – Power Inputs Yes Yes, TSO-C153 qualification d b d b ii li Page 23 ### Page 28 RTCA/ DO-160D Section # RTCA/DO-160D Section Title TSO-C153 Requirement Functional TSO or Aircraft Installation Requirement data may be used by similarity 19 Induced Signal Susceptibility Not tested Yes 20 Radio Frequency Susceptibility Not tested Yes 21 Emissions of Radio Frequency Energy Not tested Yes 22 Lightning-Induced Transient Susceptibility Not tested Yes 23 Lightning Direct Effects Not tested Yes 24 Icing Yes Yes, TSO-C153 qualification data may be used by similarity 25 Electrostatic Discharge Yes Yes, TSO-C153 qualification data may be used by similarity NOTE: RTCA/DO-160D, Sections 20 and 22 may require more testing at aircraft installation (see section 17c(4) and (5) of this AC). b. Certain EQTs cannot be appropriately performed on the hardware elements as part of the TSO-C153. Those EQTs can only be appropriately performed when the IMA system and hardware elements are arranged in the configuration specified for the applicable aircraft, as defined for the aircraft TC, STC, ATC, or ASTC. Also, those EQTs can only be appropriately performed with the functional software components installed and operating. Therefore, certain RTCA/DO-160D EQTs are excluded from the TSO-C153. These EQTs must then be addressed as part of the functional TSO compliance, or as part of the TC/STC/ATC/ASTC environmental qualification. These tests are described below: (1) The EQT for temperature (RTCA/DO-160D, Section 4) and temperature variation (RTCA/DO-160D, Section 5) should be performed with the cabinet or rack and modules in the hardware configuration intended for the functional TSO authorization or the TC/STC/ATC/ASTC approval. For temperature and temperature variation tests performed for the functional TSO or TC/STC/ATC/ASTC, the hardware module arrangement should represent the expected worst-case temperature conditions. As an alternate approach, the functional TSO or TC/STC/ATC/ASTC applicant may perform engineering analysis of the thermal characteristics of the expected cabinet or rack and module configuration variations to determine temperature test parameters that exceed the worst-case expected temperature conditions. These temperature test parameters could be used instead of the standard RTCA/DO-160D, Sections 4 and 5 temperature conditions. (2) The EQT for operational shock (RTCA/DO-160D, Section 7) and vibration (RTCA/DO-160D, Section 8) should be performed with all cabinet or rack module positions (slots) occupied in the hardware configuration specified for the functional TSO or TC/STC/ATC/ASTC installation. An alternate approach would be to perform an engineering analysis of the characteristics of the expected cabinet or rack and module configurations to determine vibration and operational shock test parameters that exceed the worst expected Page 24 ### Page 29 conditions. These test parameters could be used instead of the standard RTCA/DO-160D, Sections 7 and 8 conditions. (3) The EQT for induced transients (RTCA/DO-160D, Section 19), Radio Frequency (RF) susceptibility (RTCA/DO-160D, Section 20), RF emissions (RTCA/DO-160D, Section 21), and lightning-induced transients (RTCA/DO-160D, Section 22) are most appropriately performed with the hardware elements and software components loaded and active in the IMA system. This is because the response of the system may be highly dependent on the hardware element position and software component configuration. Therefore, these EQTs should be performed as part of the functional TSO compliance or as part of the TC/STC/ATC/ASTC environmental qualification. (4) IMA systems should have lightning and HIRF protection EQTs performed with the hardware elements and software components loaded in the configuration specified for the applicable aircraft, per the lightning regulations and ACs and the HIRF policy. The interface wiring and connected equipment must be representative of the wiring and connected equipment intended to be installed in the aircraft. c. The EQT performed for a single functional TSO authorization or aircraft TC/STC/ATC/ASTC may be used to support other applications for functional TSOs or aircraft TC/STC/ATC/ASTCs with similar configurations. The TSO applicant may use similarity assessment and worst-case test conditions to minimize the EQTs required for subsequent functional TSO applications or aircraft TC/STC/ATC/ASTC. Use of the environmental qualification data should be accompanied by a rational and accurate engineering analysis of the differences between hardware element and software component load configurations used during the original environmental tests and the proposed new configuration. The engineering analysis may consider the worst-case environmental limits developed above. d. The functional TSO qualification data sheet should state explicitly the RTCA/DO-160D test categories and tests that are performed in the functional TSO configuration and the test categories and tests that are performed in the TSO-C153 configuration. This information should also be included in the installation instructions. e. Hardware elements and software components providing a function that does not have an applicable functional TSO must meet the TC/STC/ATC/ASTC environmental requirements. f. All hardware elements must be evaluated prior to installation to ensure that the TC/STC/ATC/ASTC environmental qualification requirements have been satisfied. **16. HUMAN FACTORS AND FLIGHT CREW INTERFACE GUIDANCE.** a. Human Factors Background. (1) This section provides guidance to identify and, in some cases, resolve human factors and flight crew interface issues of IMA systems. It addresses issues with the design of Page 25 ### Page 30 TSO-C153 hardware elements and the installation and integration of such elements into the aircraft. The installation and integration of an end-state, fully integrated IMA system is also addressed in this section. (2) Because IMA systems contain many unique issues, applicants should develop a plan early in the program to address human factors and flight crew interface issues. The plan should document how issues will be identified, tracked, and resolved throughout the life cycle of the program. Typically, this information is documented through either a Human Factors Certification Plan or through a general certification plan in which the human factors components are identified. (3) FAA Policy Statement PS-ANM100-2003-01-03, Factors to Consider When Reviewing an Applicant’s Proposed Human Factors Methods of Compliance for Flight Deck Certification, provides guidance on factors to consider when reviewing an applicant’s proposed method of compliance identified in a Human Factors Certification Plan or general certification plan. FAA Policy Statement PS-ANM111-1999-99-2, Guidance for Reviewing Certification Plans to Address Human Factors for Certification of Transport Airplane Flight Decks, provides guidance for reviewing the human factors components of the certification plan for Transport Category Airplanes, as well as what should be included in these plans. While these policy statements are tailored for part 25, much of the guidance is general and may prove useful for any aircraft type. Potential human factors and flight crew interface issues for all aircraft types are discussed below, as well as guidance related to finding compliance with the related regulations. b. Potential Human Factors and Flight Crew Interface Issues with IMA Systems. (1) Displays and associated flight deck controls typically pose the greatest challenges for human factors and flight crew interfaces in IMA systems. This section addresses the most common issues, but does not comprehensively address all potential human factors and flight crew interface issues with an IMA system. IMA systems have many novel aspects; therefore, new issues arise with each project. (2) Guidance in this section is intended to supplement the previously published material (as listed in section 2 of this AC) and provide awareness of the issues that applicants should consider. Thus, where relevant regulatory or advisory materials exist, they are referenced, and where none exists the issue is noted along with a recommended resolution path, where one has been established. (3) E lectronic Checklists. (a) In the past, electronic checklists were passive; that is, they only monitored system status and then allowed check-off (either manually or automatically) of the item when it was accomplished by the flight crew. In order to address the workload and task timeline issues with integration of utility system controls (including fuel, electrical, pneumatic, air conditioning, and pressurization), the applicant may use electronic checklists. These allow the flight crew to click on the checklist item (to call up the system synoptic display), move the cursor to the Page 26 ### Page 31 synoptic display, and position the cursor on required control function on that display. One good aspect of this approach is a reduction in errors associated with selecting the wrong control. However, a significant potential human factors and flight crew interface issue is system awareness, because overloaded or complacent pilots may adopt a “click, click, click, … checklist complete” habit and lose awareness of the consequences of the individual items. This is even more significant because of the small amount of display area that may have been reserved for the checklist (which may result in little room for expanded explanations of procedure steps). (b) The FAA’s Flight Standard Service normally handles the post-TC approval of user-modifiable checklists without the need of a design change. However, it is recommended that checklists that interact with aircraft systems not be user-modifiable, because they may require design changes to other aircraft systems and additional human factors evaluations. (c) Automatic control of aircraft functions through the electronic checklist is not recommended. (4) Accessibility of Functions. (a) As more and more functions are being controlled using multi-purpose controls (such as, Cursor Control Device (CCD) or Multifunction Control and Display Unit (MCDU)), the flight crew must step through more menus to access functions that had previously been immediately accessible using dedicated controls. For example, applicants may propose to use the CCD to control all radios (with the MCDU as a backup). This may take several steps to do something that previously took only one control action (such as, turning a single knob). While some shortcuts have been developed for on-side radios, there can still be more steps than required for conventional radio control panels. (b) Quick access to various functions can be an important issue, considering that many other functions may be performed using the CCDs and other multifunction controls. (c) Increased sharing of the MCDU may also cause problems. For example, an applicant design may propose to use the MCDU as the control and display device for the solidstate circuit breakers. This would require time-sharing with all of the other functions (for example, Flight Management System, datalink, display of maintenance data, backup tuning of communication/navigation radios, and so forth) that currently are hosted on the MCDUs. (d) It is important to evaluate this decrease in accessibility across all flight deck functions, in addition to evaluating it on a case-by-case basis. The cumulative effects on workload, task timelines, interference across functions, and flight crew coordination may be significant. (5) Cu rsor-Based Controls. (a) Controls used in IMA systems pose a number of potential human factors and flight crew interface issues. Specifically, a variety of cursor-based controls may be used with Page 27 ### Page 32 “point-and-click” graphical user interfaces for certain flight crew functions. Examples of cursorbased control technologies include touch-pads, joysticks, force-sensitive two-axis buttons (similar to those embedded in some laptop computer keyboards), and trackballs. A number of cursor-based control issues to be addressed are included below: 1. Numerous Functions. A number of functions are likely to be controlled by these cursor-based control devices, presenting the possibility of flight crew interface “choke points.” Rather than simply reaching for different discrete controls as needed, the flight crew may have to repeatedly work their way through menus in order to use the cursor-based control to perform various control functions. 2. Performance-in-Motion Environments. A related issue that needs to be evaluated when determining the acceptability of a cursor-based control is performance-inexpected motion environments. This may be especially problematic using cursor-based controls to navigate through multiple nested menus, during time-critical activities, in turbulence, or when tasks are interrupted (for example, by Air Traffic Control). 3. Control Labeling. Title 14 CFR § 25.1555(a) states the following: “Each cockpit control, other than primary flight controls and controls whose function is obvious, must be plainly marked as to its function and method of operation” (parts 23, 27, and 29 contain similar requirements). IMA system designs may use multifunction control devices that perform different functions under various conditions. Examples include cursor-based controls, multifunction rotary knobs (associated with the cursor-based controls), multifunction keyboards, and MCDUs. These controls perform a variety of functions, depending on the context. In the case of cursor-based control devices, part of the control function, including the labeling, actually exists on the display (the cursor and the selectable items). a. The flight crew must be able to quickly identify which function is currently active for cursor-based control functions. This means that the current location of the cursor should be easily identifiable, without searching the displays. b. In some designs, certain of these controls are labeled (on the display) with icons (symbols) in lieu of text. While a limited number of control functions may have icons associated with them that one could reasonably assume the pilot could recognize, most functions may have no universally accepted icons. Therefore, the association between the icons and the controlled function will require flight crew training and memorization. The use of such icons in lieu of text should be kept to a minimum. 4. Cursor-Based Control Failures. Several types of cursor-based control failures need to be considered. One is the failure of a single cursor-based control, which may disrupt the normal flow of flight crew tasks. The tasks on the flight deck are normally allocated based on which pilot is flying the aircraft. As tasks are performed, some will be accomplished by the Pilot-Flying, while others will be accomplished by the Pilot-Not-Flying. With the failure of one cursor-based control, there may be significant disruption in flight crew activities for the following two reasons: ### Page 33 a. In some designs, the pilot with a failed cursor-based control will be unable to use the other pilot’s cursor-based control. In this case, flight crew procedures can be disrupted. For example, tasks that are normally allocated to the Pilot-Flying or Pilot-Not-Flying may need to be done by the flight crew with the remaining functional cursor-based control, regardless of who is flying. b. Even if the remaining cursor-based control is usable by both pilots, it may be required by both pilots simultaneously. With some implementations, loss of both cursorbased controls can render significant numbers of important functions unavailable. 5. Replacement of Discrete Control Panels: a. In some configurations, the IMA system and associated cursor-based controls (in conjunction with synoptic (schematic) system displays and electronic checklists) can be used to control a wide variety of functions. Those include fuel, electrical, pneumatic, air conditioning, pressurization, communication and navigation radios, and display systems. In such cases, many discrete or dedicated control panels may be eliminated. Pilots will “point and click” to bring up menus, select icons that represent system components (for example, valves, pumps, generators, and radios), and change system states. Significant human factors issues include workload, time to complete functions, system status awareness, and crew coordination. For example, with a conventionally designed flight deck, the flight crew could turn off a hydraulic pump by simply reaching up to the overhead panel and pushing a button. To do the same thing using an integrated CCD or IMA system that replaces the overhead panel, the flight crew may have to perform many more individual actions. b. This sequence of individual actions is likely to take significantly longer than it would on a conventional design. This may also cause more difficulty in manipulating different systems in a sequence, particularly if the system requires the flight crew to navigate through various menus. Furthermore, these selections would be accomplished by very small finger motions on the cursor-based control, which are more likely to go unnoticed by the other flight crewmember, especially if cursor-based control activity is very routine and the selections occur on a multifunction display that is displaced to one side of the flight deck. Thus, the other flight crewmember might not know that the status of the system has changed. Additionally, the flight crew may spend significantly more time “heads-down” while manipulating the cursorbased control and navigating the menu selections than they would if using a single dedicated control. c. For IMA systems, applicants should present criteria and rationale to justify which functions will retain discrete or dedicated controls, and which ones will not. d. Another consideration is the splitting of controls for a system. For a given system, a few of its controls may be in the overhead panel while the rest will be operated by the CCD. In conventional designs, there will typically be a control panel or area of the overhead panel devoted to each major system. In that way, for example, all controls for the Page 29 ### Page 34 electrical system will be grouped together. However, when some controls are moved from the discrete or dedicated control panels, some of the system’s controls may now be accessed by the CCD and main displays, while other controls for that same system may remain in the overhead panel. For example, most electrical system controls (such as bus switching) would be controlled by the CCD, while the generator drive disconnect switches are likely to stay in the overhead panel due, in part, to the irreversible nature of the control. Thus, the flight crew would have to go to different locations for various electrical system controls. This scattering of system controls may result in flight crew confusion in critical, high workload/stress failure scenarios. Compliance with 14 CFR § XX.777a should be shown (where XX may be 23, 25, 27, or 29). c. Testing Considerations for Human Factors and Flight Crew Interface Issues. Cursor-based control evaluations should include scenarios involving manual flight, emergencies, multiple failures, turbulence, vibration from sustained engine imbalance (blade-out), and so forth. Scenarios should involve testing of all cursor-based control functionality, including when the flight crew might use the cursor-based control to select displays, position the cursor, select from menus, and navigate through menu trees to access control functions (see also section 17 of this AC for testing considerations). Testing the acceptability of the IMA cursor-based control system should focus on each of the issues discussed in the section above, as well as on determining compliance with the regulations, as partially discussed in the following section. d. Methods of Compliance with Controls Regulations. (1) Policy Statement PS-ANM111-1999-99-2 contains an appendix with a list of regulations typically associated with human factors and flight crew interface issues. It is important to check that the IMA system as a whole, as well as to check that the individual components, comply with these and other applicable regulations. It is recommended that an IMA system applicant develop a Human Factors Certification Plan that will provide the certification office a structured approach to show how compliance will be determined with each of the applicable regulations (that is, test, analysis, and simulation). The certification plan should be organized to show the relationship between the specific human factors requirements and the method of compliance. Methods of compliance must be evaluated for the following regulations: 14 CFR §§ XX.771(a), XX.771(e), XX.777(a), XX.1523, XX.1555(a), XX.1301(a), XX.1309(b), XX.1309(d) (where XX may be 23, 25, 27, or 29). A subset of these are discussed below with emphasis on part 25, but must also be evaluated for parts 23, 27, and 29 (as appropriate): (a) To comply with 14 CFR §§ 25.777(a) and 25.1523, the applicant must show that the flight crew can conveniently access required controls in all expected flight scenarios, without unacceptable disruption of aircraft control, crew task performance, and Crew Resource Management. Since not all possible scenarios can be evaluated, the applicant should develop a set of worst-case scenarios for evaluation, along with proposed methods for evaluation (such as, analysis, test, and demonstration). Comparison to conventional controls is considered an important aspect of this evaluation, in order to determine if the use of cursor-based controls results in an increase in flight crew workload or task timelines. The evaluation plan should show how each of the factors identified in 14 CFR part 25, Appendix D will be evaluated. Operation of the cursor-based control with both the dominant and non-dominant hand should be included in Page 30 ### Page 35 the evaluations. Additionally, experience has shown that control-display response lag (time delay between movement of the control and response of the cursor) and control gain characteristics can be critical in the acceptability of a cursor-based control. Therefore, usability testing should accurately replicate the response lag and control gain characteristics that will be present in the actual aircraft. (b) To show compliance with 14 CFR § 25.771(e), the applicant should show by test and/or demonstration in representative motion environment(s) that the cursor-based control is acceptable for controlling all functions that the flight crew will access using the cursor-based control during these conditions. In addition to turbulence, vibration due to the loss of a fan blade and the subsequent damage to other rotating parts of the fan and engine must be considered in the definition of the motion environment. (c) To show compliance with 14 CFR §§ 25.1309(b) and (d), the applicant must conduct an aircraft-level safety assessment to determine the hazards and failure conditions associated with the failure of one and of both cursor-based controls. Particular attention should be paid to the independence of the two cursor-based controls (that is, vulnerability to commoncause failures), and to the combined effects of the loss of control of multiple cursor-based systems and functions. The applicant should demonstrate that the failure of either cursor-based control does not unacceptably disrupt operation of the aircraft (that is, the allocation of flight crew tasks) in normal and emergency conditions. The failure condition classifications described in SAE ARP4761 can be used to assess the severity of the effect on the aircraft and on flight crew operations of the loss or malfunction of a single cursor-based control or the loss or malfunction of both cursor-based controls, either by themselves or in combination with other failures. In conducting the safety assessment, the failure conditions that could result in the failure or anomalous behavior of a cursor-based control should include fluid contamination, unless it can be shown that spills of fluids expected to be present in the flight deck (for example, coffee and syrup) will not result in cursor-based control failure or anomalous behavior, or in degraded flight crew usability of the cursor-based control. The safety assessment should also include common mode failures such as physical damage, HIRF, lightning, fire, and electrical faults. (d) To show compliance with 14 CFR § 25.1555(a), the following should be demonstrated: 1. That pilots are able to quickly and reliably identify what item on the display is “active” as a result of cursor positioning, as well as what that function will perform, if the item is selected using the selector buttons and/or changed using the multifunction knob. 2. That pilots will correctly identify and select the control functions, at a speed and error-rate that is equivalent to or better than that of controls that are labeled with text formats. The data required to substantiate that the speed and error rate is equivalent need not be objective data; the applicant may collect subjective data from test subjects to show that the design meets this standard. ### Page 36 NOTE: A smoke-filled cockpit should be considered when evaluating compliance to 14 CFR § 25.1555(a). 17. TESTING PRACTICES. This section describes hardware element testing, individual system testing, IMA system integration testing, aircraft ground testing, aircraft flight testing, and maintaining configuration control of test plans/procedures/results. The applicant(s) should develop test plans for each of the appropriate testing categories. The test plans should be coordinated with and approved by the cognizant ACO. In addition to normal certification testing, the following testing should be addressed for IMA systems, as a minimum. a. IMA Hardware Element Testing. (1) Testing of the hardware elements should be accomplished by TSO testing for TSO-C153 and functional TSOs. (2) Additional tests required for the installation of the hardware elements that were not performed for TSO compliance (for example, additional environmental qualification or hardware device testing) should be conducted. (3) Hardware elements that have functionality not addressed by a functional TSO should be tested to the aircraft system performance and environmental specifications. b. Individual System Testing. (1) Individual functions (for example, Flight Management System, braking system) within the overall IMA system should be tested with associated power, controls, sensors, and displays. (2) System-level testing should focus on performance and functional testing. It is beneficial for the system integrator to provide several early opportunities for human factors and flight crew interface evaluations. Early evaluation allows timely identification of human factors and flight crew interface issues so that changes can be made with acceptable technical, schedule, and economic impacts. It also allows for FAA evaluation of the design to instill confidence in the applicant’s design decisions and to potentially reduce certification risks. System-level testing is typically the earliest opportunity for this type of evaluation. (3) System-level testing may include: (a) Powe r-up testing. (b) Verification of correct software part number(s). (c) Hardware and software integration testing for the specific system and functions. ### Page 37 (d) Functions and features testing (for example, “functions” include things like GPS navigation, while “features” are parts of the system, such as a zoom-in button). (e) BIT versus external test equipment (for example, an Instrument Landing System test set or a Traffic Alert and Collision Avoidance System test set) to assure correct interfacing. (4) Environmental qualification tests requiring functional software should typically be performed as part of the system-level environmental qualification testing. (5) Robustness testing to verify that the system responds correctly to abnormal conditions, such as corrupted or invalid data inputs, and to ensure that assumptions made during the safety assessment and system design are valid. c. IMA System Integration Testing. (1) This testing addresses the integration of all hardware elements, functional software, displays, controls, sensors, power sources, and other IMA system components representing the configuration intended for aircraft certification. (2) Typically, the same issues are addressed as in the individual system testing, plus the addition of functional compatibility and interoperability among systems. (3) Worst-case system testing or analysis should be performed to verify the performance of the functionality of the overall system (for example, data communication, throughput, design margins, cooling, and power consumption). (4) HIRF testing should be performed as part of the system integration tests for systems whose failures may contribute to catastrophic or hazardous failure conditions for the aircraft or engine. (5) Lightning testing should be performed as part of the system integration tests for systems whose failures may contribute to major, hazardous, or catastrophic failure conditions for the aircraft or engine. (6) System integration testing provides another opportunity for human factors and flight crew interface evaluations. This enables timely identification of human factors and flight crew interface issues so that changes can be made with acceptable technical, schedule, and economic impacts. It allows for FAA evaluation of the design to instill confidence in the applicant’s design decisions and to potentially reduce certification risks. (7) Integration testing should include evaluation of built-in-test functionality, fault isolation, detection and annunciation, and maintenance diagnostics. Integration testing should also be used to validate assumptions made in the aircraft level and IMA safety assessment, where possible. ### Page 38 (8) System testing should verify independence assumptions between or among functions supported by the IMA system, as documented in the SSA. Verification includes assurance that functions are not affected during malfunction and/or loss of other independent systems and hardware elements, including short-circuited power. Analysis to identify worst-case conditions may be used to minimize the testing effort. It is recommended that this testing be performed in the laboratory but may be performed as part of the aircraft ground test. d. Aircraft Ground Testing. (1) The applicant should submit a ground test plan. Hardware elements must be installed and software components loaded in the conformed configuration that represents the intended type design. Ground tests should evaluate the high temperature extremes and may evaluate the low temperature operating conditions. (2) If system integration testing is not performed in a laboratory, then it must be performed on the aircraft. (3) Typically, Electro-Magnetic Compatibility testing is performed during the aircraft ground tests. (4) Some human factors and flight crew evaluations may be performed on the ground (for example, night lighting, equipment location, and hazardous system malfunctions). (5) Ground testing should also include IMA system testing with simulated malfunctions or losses, where possible. This testing should verify that functions are not affected during malfunction and/or loss of other independent systems and hardware elements, including loss of power (for example, that none of the non-GPS IMA systems are affected by a GPS hardware module failure). These tests should be a subset of the integration testing addressed in paragraph 17c(8) above. (6) Compliance of colors of advisories, cautions, and warnings with the regulations (such as 14 CFR § XX.1322) and applicable guidance of advisory materials (for example, AC 25-11). Portions of alerting system evaluation may be performed during flight-testing. (7) Equipment cooling testing. e. Aircraft Flight Testing. Hardware elements must be installed and software components loaded in the conformed configuration that represents the intended type design. Situational awareness, human factors, and flight crew workload must be considered with respect to the certification requirements of the type design for both normal and abnormal operational requirements. Certain tests may not be able to be conducted during flight due to safety reasons and may be accomplished during ground testing or simulator testing, as agreed with the cognizant ACO. The fidelity of simulator testing must be commensurate with the complexity of the task and the degree of system integration at the aircraft level. The following areas of each Page 34 ### Page 39 installation should be evaluated by flight testing for compliance with the applicable airworthiness regulations (for example, 14 CFR parts 23, 25, 27, or 29) and impact on crew workload: (1) Evaluation of functions, features, and abnormal modes of the IMA system. (2) Evaluation of flight crew situational awareness of selected/deselected systems/modes during normal and degraded system scenarios. (3) Evaluation of the crew alerting system(s). (4) Evaluation of pilot visibility of each required instrument from each pilot station, to include normal and reversionary modes. (5) Human factors aspects of control system (for example, cursor-based control or other control devices, location and accessibility of controls). (6) Any tests unique to the new equipment or new/novel functions. This should include simulated IMA system failures and the capability of the backup systems to take over without interruption. (7) Electrical bus switching. This testing should include monitoring the response of the different IMA systems with bus interruptions and transients. NOTE: Flight test personnel should also evaluate the AFM or AFMS procedures and limitations to ensure that they are accurate and support the safety assessment. f. Configuration Control During Flight Testing. Because of the dynamic and complex nature of IMA system configuration, “red label” units are often used during the certification flight-testing. The hardware elements and software configurations may change several times during the flight test program. Therefore, the applicant should define an IMA system configuration control process to use during the certification flight test program. This process should include “flight test conformity,” as well as a means of ensuring that the final product conforms to what was tested, and that the test results for configurations tested that were different than the final IMA system configuration are valid. Examples of items to be addressed in the process are: (1) Inclusion of the aircraft-level safety assessment and a summary of each function’s criticality and worst-case failure conditions. (2) A process to identify and control the configuration of each hardware element and software component of the IMA system during the certification flight test program. ### Page 40 (3) A process for analyzing the interoperability effects of all changes during the flight test program. For example, a process to determine how changes to some software components may affect other software components or functions in the IMA system. (4) A change impact analysis process for analyzing the effect of changes during the test program on the aircraft-level safety assessment and other systems, and the validity of previously conducted tests. (5) A process for analyzing the effect of every change on the overall functionality of the final IMA system and the validity of previous test results. 18. ROLES AND RESPONSIBILITIES OF IMA SYSTEM APPLICANTS. There are a number of different levels of roles and responsibilities that should be addressed in order for the overall IMA system certification to occur. This section identifies the major roles and responsibilities for the TSO-C153 applicant, the functional TSO applicant, and the TC/STC/ATC/ASTC applicant. Please note that these lists are not all-inclusive. All applicants are strongly encouraged to coordinate with the certification authorities throughout the entire IMA system development. a. TSO-C153 Applicant Roles and Responsibilities: (1) Apply for TSO-C153. NOTE: Due to the complexity of IMA projects, it is recommended that the TSO manufacturer coordinate with the FAA early in the program. (2) Build MPS in accordance with TSO-C153. Ensure that all the appropriate items in TSO-C153 Appendix 1 have been documented and approved by the FAA. (3) Develop and implement part identification and configuration management functionality into hardware elements. The configuration management and part identification approach should follow the guidance of sections 10 and 11 of this AC. (4) Coordinate with TC/STC/ATC/ASTC applicants who will be integrating and installing the hardware elements on the aircraft to ensure that the relevant issues are identified and addressed as early as possible. (5) Design and build hardware elements per TSO-C153 and the MPS. (6) Perform the tests necessary to demonstrate compliance with TSO-C153 and the MPS. If special purpose test software is used for environmental qualification testing, the manufacturer must verify, validate, and control the configuration of the hardware elements and software components to ensure the validity of the testing ### Page 41 (7) Submit the data package (that is, information in Section 5 of TSO-C153, including the MPS) to the cognizant FAA ACO for review and issuance of TSO authorization. (8) Apply for changes to TSO-C153 elements, as design changes occur. Notify TC, STC, ATC, ASTC holder and/or functional TSO holder of the design change. NOTE: During the manufacturing airworthiness determination of the hardware elements identified with TSO-C153 authorization, functional software must not be installed on the hardware element in order to comply with 14 CFR § 21.603. b. Functional TSO Applicant Roles and Responsibilities. (1) Apply for functional TSO. (2) Design the system in accordance with the appropriate TSO standards. (3) Identify and address all integration and installation issues with the TSO-C153 and TC/STC/ATC/ASTC applicants. (4) Develop a mapping between the TSO requirements and the system implementation (for example, a mapping matrix). The mapping should identify TSO requirements that are fully met, partially met, or not met at all. (5) Reference Order 8150.1 (see the most current edition), as needed. (6) Identify functions in the IMA system that are not addressed by the TSO. These functions may require deviations and must be addressed by the TC/STC/ATC/ASTC applicant. (7) Perform tests to demonstrate compliance to the functional TSO or functional performance standards. Some EQTs may not have been accomplished for TSO-C153 authorization. The functional TSO applicant must demonstrate that all testing, including EQTs, required for the functional TSO has been accomplished. If special purpose test software is used for environmental qualification testing, the applicant must verify, validate, and control the configuration of the software to ensure the validity of the testing. Credit may be applied for EQTs that were conducted for the TSO-C153 authorization, if appropriate. (8) Submit the data package required by the functional TSO to the cognizant FAA ACO for review and issuance of TSO authorization. The installation data are included as part of the data package and should include the configuration of the functional TSO submitted for authorization. (9) Apply for changes to functional TSOs, as design changes occur. Notify TC, STC, ATC, and ASTC holder of the design change. ### Page 42 NOTE: Due to the high integration, functional TSO data packages for IMA systems are typically developed in parallel with the TC/STC/ATC/ASTC effort. In these cases, TSO data should not be submitted to the ACO for authorization until the TC/STC/ATC/ASTC testing is completed. c. TC, STC, ATC, ASTC Applicant Roles and Responsibilities. (1) Develop and submit a Project-Specific Certification Plan (PSCP) for the IMA system to the cognizant ACO for approval. (a) It is recommended the PSCP include a detailed conformity plan that addresses all hardware elements and software components’ conformity and installation conformity inspections (including the plan for addressing any “red label” units). (b) The PSCP should clearly identify what functions will and will not be approved through the TSO authorization process. This is necessary in order to clarify the approval process (that is, to identify what will be TSO authorized and what will be TC/ATC/STC/ASTC approved). (c) The PSCP should address integration and installation of all components of the IMA system (including all hardware elements and software components). (2) Define aircraft system and performance requirements. (3) Perform aircraft-level safety assessment per section 9 of this AC and submit to ACO. (4) Integrate the IMA system into the aircraft or engine. NOTE: The TC/STC/ATC/ASTC applicant is responsible for system integration in the aircraft or engine, IMA system-level testing, ground testing, and flight-testing. (5) Ensure that all TSO assumptions are not violated in the installation (for example, relocation of a GPS hardware module does not invalidate environmental qualification credit for the GPS TSO). (6) Integrate all hardware elements and software components. (7) Develop field-loading procedures to ensure that proper software is loaded on the aircraft (see section 10g of this AC). (8) Verify that software and complex electronic hardware issues were properly addressed for the installation per sections 12 and 13 of this AC. ### Page 43 (9) Determine appropriate aircraft environmental conditions and ensure that EQTs were performed (see section 15 of this AC). (10) Develop test plans and perform necessary tests, including those addressed in section 17 of this AC. (11) Develop a plan for addressing human factors issues and perform human factors and flight crew evaluations of the IMA system, as described in section 16 of this AC. (12) Ensure that the IMA system meets all airworthiness requirements (see section 20 of this AC). (13) Submit all appropriate certification data (for example, safety assessments, hardware design assurance data, software data, test plans, test results, compliance reports) to ACO for approval. (14) Maintain aircraft system configuration management per sections 10 and 11 of this AC. (15) Evaluate and document changes to IMA system and elements per 14 CFR § 21.93. (16) Ensure that aircraft design features address safety and comply with the regulations (see section 14 of this AC). (17) Evaluate third-party hardware modules and/or any software installed in the IMA system and demonstrate compliance to regulations (see section 19 of this AC). NOTE: If a manufacturer desires production authority, the quality assurance, inspection, and test procedures data must be submitted for issuance of production approval. 19. ADDITIONAL GUIDANCE FOR THIRD-PARTY MANUFACTURERS. For purposes of this section, a third-party manufacturer is a developer of a hardware module to be installed into a TSO-C153 authorized rack or cabinet. However, this hardware module developer is not the developer of the rack or cabinet and is not the primary IMA system integrator. A thirdparty manufacturer may have many approaches to integrating their hardware module into an IMA system. This section provides additional guidance to be considered by third-party manufacturers and applicants of IMA systems using third-party hardware modules. a. Third-party hardware modules may or may not obtain TSO-C153 authorization. In order to not violate the TSO-C153 authorization granted for the rack or cabinet, the third-party manufacturer’s hardware module must be shown to meet the environmental, interoperability, configuration management, and regulatory requirements of the installation. The third-party hardware module must also participate in the robust automated configuration management Page 39 ### Page 44 system by providing configuration identification information to the system. This requires close cooperation between all stakeholders involved. b. Some third-party manufacturers may seek functional TSO authorization on their hardware module as part of a TSO authorized system (for example, GPS or Terrain Awareness Warning System TSO authorization). Hardware modules seeking functional TSO authorization should be designed and tested to operate in an environment that is valid for the actual environmental. During the functional TSO authorization, the configuration of all components needed for system operation should be specified. The expected installation approach and limitations should be documented when the TSO package is submitted to the FAA. During the actual installation of such hardware modules into IMA systems, TC/STC/ATC/ASTC applicants should ensure that the assumptions of the TSO authorization are not violated (for example, ensure that the actual environment is not harsher than the environment authorized by the TSO authorization). c. Some third-party hardware module manufacturers will not apply for any TSO authorization (neither TSO-C153 authorization nor a functional TSO authorization). This might happen because a functional TSO authorization doesn’t exist (for example, braking system or power distribution system) or because a TSO authorization isn’t desirable. Such hardware modules will be approved as part of the TC/STC/ATC/ASTC. The environmental, interoperability, configuration, and regulatory requirements must be demonstrated as part of the TC/STC/ATC/ASTC process. Regardless of the approach taken by the third-party manufacturer, third-party hardware modules should be evaluated at the installation level to verify that all requirements are met. Third-party manufacturers are suppliers to the TC/STC/ATC/ASTC applicant and must be controlled during production by the applicant’s quality assurance organization. d. Some third-party hardware modules may be designed to install field-loadable software (FLS). The FLS should meet the criteria of sections 10, 11, and 12 of this AC and the requirements of any functional TSOs involved. Additionally, the FLS should be carefully controlled. Loading software into third-party hardware modules may or may not be through the same port as other hardware modules in the IMA system. The loading approach must be carefully controlled to address configuration management, security, and verification of correct loads. There must be a robust loading process to ensure that incorrect software cannot be loaded and that other software cannot be inadvertently changed, when the third-party hardware module is loaded. e. All hardware modules installed into a TSO-C153 authorized rack or cabinet should have a data sheet, similar to the one shown in Appendix 2 of TSO-C153. A manufacturer can submit data in a different format, but it must contain all of the information listed in Appendix 2 of the TSO-C153. If a particular portion of the data sheet does not apply, mark it “Not Applicable.” NOTE: Third-party software has not been addressed in this AC. It may be utilized in some IMA systems. Third-party software Page 40 ### Page 45 component manufacturers should consider the FAA’s AC on software components (see http://av-info.faa.gov/software). **20. AIRWORTHINESS CONSIDERATIONS.** a. Init ial Installation. For initial approval of a particular equipment installation, the scope of the applicant’s program should be directed toward airworthiness approval through the TC or STC process. This AC is also appropriate for applicants who exercise their Delegation Option Authorization (DOA), Organizational Designated Airworthiness Representative (ODAR), or Designated Alteration Station (DAS) authorization for STC approval. As part of the ATC or ASTC program, the applicant should determine if the changes to the type certificated aircraft constitute a significant change, but not one so extensive as to require a new TC in accordance with 14 CFR § 21.19. If the design change is considered significant, the certification program should be coordinated with the responsible FAA Directorate and cognizant ACO, as described in FAA Order 8110.4 (see the most current edition). b. F ollow-on Installations. For equipment that has already obtained initial installation approval by the TC or STC process, approval may be obtained using either the STC, ATC, ASTC, or FAA Form 337, Major Repair and Alteration, process subject to the restrictions of paragraph (1) below. (1) For installations on aircraft operated under 14 CFR part 91 and with the applicant providing acceptable IMA system installation or alteration instructions, approval for return to service can be accomplished using FAA Form 337. Because of the complexity of IMA systems, the FAA Form 337 should be limited to return to service. Installation variations acceptable for approval by FAA Form 337 must not impact system or aircraft operation (for example, slight location changes, minor fastener changes, and so forth, could use the FAA Form 337 process). Therefore, it is recommended that the FAA Form 337 process be limited to minor aircraft installation variations from a TC/STC/ATC/ASTC that approves an IMA system for that particular aircraft model. Any operational variation in installation should only be accomplished by STC or amended TC. NOTE: Part 121 operators and Part 145 repair stations may not require FAA Form 337 for return to service, because their return to service method is specified in their FAA-approved manuals. (2) When using the STC or ATC process, all required data pertaining to the installation should be submitted to the ACO. These data should include the manufacturer’s operating and installation or alteration instructions, safety analysis for the installation or alteration, installation or alteration details, structural substantiation, system wiring diagrams, ground test plans, flight test plans, and test results, as a minimum. (3) Because of the complexity of IMA system installations and alterations, it is highly recommended that initial DAS and DOA/ODAR IMA projects have significant ACO participation. ### Page 46 c. Change Impact Analysis. When a change is made to the IMA system, a change impact analysis should be performed. The change impact analysis should determine whether the change could adversely affect safe operation of the system or product. The following are examples of areas that could have an adverse impact on safety or operation: (1) Safety-related information is changed. For example: (a) Previous hazards, as identified by the SSA, are changed. (b) Failure condition categories, as identified by the SSA, are changed. (c) Software levels or electronic hardware device design assurance levels are changed. (d) Safety-related requirements, as identified by the SSA, are changed. (e) Safety margins are reduced. (f) Validity of the environmental qualification testing is affected. (2) Operational or procedural characteristics of the aircraft are changed in a manner that could adversely affect flight safety as a result of the software change. For example: (a) Aircraft operational or airworthiness characteristics are changed. (b) Flight crew procedures are changed. (c) Pilot workload is increased. (d) Situational awareness, warnings, and alerts are changed. (e) Displayed information to make flight decisions is changed. (f) Assembly and installation requirements are changed. (g) Changes that affect equipment interchangeability and/or interoperability with other equipment. (h) Certification Maintenance Requirements are changed or added. (3) New functions or features are added to the existing system functions that could adversely impact flight safety. ### Page 47 (4) Processors, interfaces, and other hardware components or the environment are changed in such a way that safety could be adversely affected. See RTCA/DO-178B, Section 12.1.3, and RTCA/DO-254, Sections 11.1 and 11.2. (5) Life cycle data (for example, requirements, code, and architecture) are significantly changed in such a way that it could adversely affect safety. d. Change Classification. The change impact analysis should be used to justify minor or major classification of the change. The major and minor change classification procedures should also evaluate the interoperability of the changed components. The TC/STC/ATC/ASTC holder must control all changes, regardless of the classification. ### Page 49 21. Maintenance and Continued Airworthiness Guidance. a. Mai ntenance Instructions. TC/STC/ATC/ASTC applicant should specify instructions for handling, storing, shipping, and installing hardware elements in the IMA system. During the approval process of IMA systems, the applicant must address the requirements of 14 CFR 21.50(b) for Instructions for Continued Airworthiness. b. Mai ntenance Diagnostics. See paragraph 14d of this AC. c. Master Minimum Equipment List (MMEL). The applicant should develop a proposed MMEL with appropriate justification during the TC/STC/ATC/ASTC effort. Procedures for safely dispatching the aircraft using the MMEL should be developed. Any MMEL allowance should be determined with consideration given to the criticality of the IMA functionality. MMEL allowances should be substantiated based on the aircraft-level functional hazard assessment. The proposed MMEL, justification, and procedures should be submitted to the Flight Operations Evaluation Board Chairman in the Aircraft Evaluation Group for FAA evaluation and approval. If modifications are made to the IMA system, the following guidance should be considered regarding the MMEL: (1) The MMEL may need to be revised to address the IMA system hardware or software changes. Once the MMEL addresses the IMA equipment changes, it may be submitted to the FAA for approval. (2) The FAA approving office (for example, Flight Standards District Office) should coordinate with ACO engineering when evaluating the revised MMEL. Susan J.M. Cabler Assistant Manager, Aircraft Engineering Division, Aircraft Certification Service Page 43 ### Page 50 Appendix 1 APPENDIX 1. Partial List of Functional TSOs. The following is a partial list of the FAA TSOs that might be considered as functional TSOs in IMA systems. Note that applicants may apply for a TSO that does not adequately address all of the functionality in the system. Alternatively, applicants may apply for multiple TSOs, since no single TSO applies to all functions. If the applicant applies for multiple TSOs for a single system, that combination of TSOs may result in the system being considered complex or integrated, even though the individual TSOs were not. TSO NUMBER SUBJECT TITLE TSO-C2d 6/14/89 Airspeed Instruments (using electronic sensing) TSO-C4c 4/1/89 Bank and Pitch Instruments TSO-C9c 9/15/60 Automatic Pilots TSO-C10b 9/1/59 Altimeter, Pressure Actuated, Sensitive Type TSO-C52b 5/30/95 Flight Director Equipment TSO-C92c 3/19/96 Airborne Ground Proximity Warning Equipment TSO-C93 11/26/76 Airborne Interim Standard Microwave Landing System (MLS) Converter Equipment TSO-C101 2/19/87 Over Speed Warning Instruments TSO-C104 6/22/82 MLS Airborne Receiving Equipment TSO-C105 6/13/84 Optional Display Equipment for Weather and Ground Mapping Radar Indicators TSO-C106 1/15/88 Air Data Computer TSO-C110a 10/26/88 Airborne Passive Thunderstorm Detection Equipment TSO-C115b 9/30/94 Airborne Area Navigation Equipment Using Multi-Sensor Inputs TSO-C117a 8/1/96 Airborne Windshear Warning and Escape Guidance Systems for Transport Airplanes TSO-C118 8/5/88 Traffic Alert and Collision Avoidance System (TCAS) Airborne Equipment, TCAS I TSO-C119a 4/9/90 Traffic Alert and Collision Avoidance System (TCAS) Airborne Equipment, TCAS II TSO-C123 8/2/96 Cockpit Voice Recorder Systems TSO-C129a 2/20/96 Airborne Supplemental Navigation Equipment Using Global Positioning System (GPS) TSO-C146 10/6/99 Stand-Alone Airborne Navigation Equipment Using The Global Positioning System (GPS) Augmented By The Wide Area Augmentation System (WAAS) TSO-C147 4/6/98 Traffic Advisory System (TAS) Airborne Equipment TSO-C151b 12/17/02 Terrain Awareness and Warning System TSO-C153 5/6/02 Integrated Modular Avionics Hardware Elements NOTE: The revisions of TSOs may change. This list is only for reference purposes. Applicants should ensure that they are using the appropriate TSO revision. --- OpenAirDocs.org is an independent research project of [Contrail Labs](https://contraillabs.com/). It is not affiliated with the FAA or the NTSB. Source documents are U.S. government works in the public domain.