AC 20-145

GUIDANCE FOR INTEGRATED MODULAR AVIONICS 

(IMA) THAT IMPLEMENT TSO-C153 AUTHORIZED 

HARDWARE ELEMENTS

Date: 2/25/03 

2/25/03 AC 20-145

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. Installation 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. Field-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 
AC 20-145 2/25/03 

d. Maintenance Diagnostics. ........................................................................................22 

e. Failure Detection and Annunciation. .......................................................................22 

f. Functional Partitioning.............................................................................................22 

g. Functional 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 
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. PURPOSE. 

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 
AC 20-145 2/25/03 

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: 

 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 2 
2/25/03 AC 20-145

(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. SAE 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. DEFINITIONS.

a. Cognizant Aircraft Certification Office (ACO). The ACO granting the certificate or 

TSO authorization for the specific product, system, or appliance. 

Page 3 
AC 20-145 2/25/03 

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. Development 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. Functional 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. Functional 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. Hardware 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. IMA 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. Partitioning. 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. Protection. 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. Software Component. A functional software file that is loaded into the IMA system. 

Page 4 
2/25/03 AC 20-145

m. Stakeholders. 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 
AC 20-145 2/25/03 

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. SCOPE. 

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 6 
2/25/03 AC 20-145

6. BACKGROUND. 

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 
AC 20-145 2/25/03 

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 8 
2/25/03 AC 20-145

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 9 
AC 20-145 2/25/03 

(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 
2/25/03 AC 20-145

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 11 
AC 20-145 2/25/03 

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 12 
2/25/03 AC 20-145

(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 13 
AC 20-145 2/25/03 

(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 
2/25/03 AC 20-145

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 15 
AC 20-145 2/25/03 

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 16 
2/25/03 AC 20-145

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. SOFTWARE GUIDANCE. 

a. Software 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. Software 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 17 
AC 20-145 2/25/03 

(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 18 
2/25/03 AC 20-145

(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 19 
AC 20-145 2/25/03 

(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. Software 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 20 
2/25/03 AC 20-145

(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 
AC 20-145 2/25/03 

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. Maintenance 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. Functional 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. Functional 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. Intentional 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 22 
2/25/03 AC 20-145

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 i il i

Page 23 
AC 20-145 2/25/03 

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 
2/25/03 AC 20-145

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 
AC 20-145 2/25/03 

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) Electronic 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 
2/25/03 AC 20-145

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) Cursor-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 
AC 20-145 2/25/03 

“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 28 
2/25/03 AC 20-145

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 
AC 20-145 2/25/03 

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 
2/25/03 AC 20-145

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 31 
AC 20-145 2/25/03 

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) Power-up testing.

(b) Verification of correct software part number(s). 

(c) Hardware and software integration testing for the specific system and 

functions. 

Page 32 
2/25/03 AC 20-145

(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 33 
AC 20-145 2/25/03 

(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 
2/25/03 AC 20-145

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 35 
AC 20-145 2/25/03 

(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 36 
2/25/03 AC 20-145

(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 37 
AC 20-145 2/25/03 

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 38 
2/25/03 AC 20-145

(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 
AC 20-145 2/25/03 

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 
2/25/03 AC 20-145

component manufacturers should consider the FAA’s AC on software 

components (see http://av-info.faa.gov/software). 

20. AIRWORTHINESS CONSIDERATIONS. 

a. Initial 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. Follow-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 41 
AC 20-145 2/25/03 

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 42 
2/25/03 AC 20-145

(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 43 

2/25/03 AC 20-145

21. Maintenance and Continued Airworthiness Guidance. 

a. Maintenance 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. Maintenance 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 
2/25/03 AC 20-145 

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. 

Page 1