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
 Date: 2/25/03 AC No: 20-145
Subject: GUIDANCE FOR
INTEGRATED MODULAR
AVIONICS (IMA) THAT Initiated By: AIR-100 Change:
IMPLEMENT TSO-C153
AUTHORIZED HARDWARE
ELEMENTS

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 sub-
systems 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. 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.

b. 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 common-
cause 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 over-

temperature 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, non-

dedicated 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-of-
configuration 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 real-
time 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 non-
resettable 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/
RTCA/DO-160D TSO-C153 Functional TSO or Aircraft
DO-160D
Section Title Requirement Installation Requirement
Section #
4 Temperature and Altitude – Not tested Yes
Temperature
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 – Not tested Yes
Operational Shock
7 Operational Shock and Crash Safety – Yes Yes, TSO-C153 qualification
Crash Safety 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/
RTCA/DO-160D TSO-C153 Functional TSO or Aircraft
DO-160D
Section Title Requirement Installation Requirement
Section #
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 Not tested Yes
Susceptibility
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 solid-
state 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 cursor-
based 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-in-
expected 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 cursor-
based 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 cursor-
based 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 common-
cause 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 third-
party 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