# AC 20-170: Integrated Modular Avionics Development, Verification, Integration, and Approval Using RTCA/DO-297 and Technical Standard Order-C153

- Type: Advisory circular (guidance, not mandatory unless a rule or AD requires it)
- Status: Current
- Approved: November 21, 2013
- Last reviewed: January 30, 2020
- Family: AC 20-170
- Cancels: [AC 20-145](https://openairdocs.org/ac/20-145)
- 14 CFR parts: 21
- Pages: 66
- PDF: https://openairdocs.org/files/sha256/e2/d8/e2d8df928c79c4567ea800fa22e92457e8d6ec21703e7db9ab303e7920bdc0c9
- FAA DRS: https://drs.faa.gov/browse/excelExternalWindow/FED2F4EB786B1639862577D10048AC1E.0001
- DRS record last changed: November 22, 2025
- Page: https://openairdocs.org/ac/20-170

## Versions

- [AC 20-170](https://openairdocs.org/ac/20-170) (Current), approved Nov 21, 2013, 66 pages

## Text

Each page's text from the PDF; open the PDF at a page with #page=N.

### Page 1

0 Advisory U.S. Department of Transportation Federal Aviation Administration Circular Subject: Integrated Modular Avionics Date: 11/21/2013 AC No: 20-170 Development, Verification, Integration, and Initiated by: AlR-120 Change: 1Approval Using RTCA/OO-297 and Technical Standard Order-Cl53 Purpose. This advisory circular (AC) sets forth an acceptable means ofcompliance for aircraft and engines that utilize Integrated Modular Avionics (IMA) systems. This AC calls out and supplements the guidance material ofRTCAID0-297, Integrated Modular Avionics (IMA) Development Guidance and Certificatitm Considerations, dated November 8, 2005. This AC incorporates pertinent guidance material and information from AC 20-145, Guidance.far Integrated Modular Ai·ionics (IMA) that Implement TSO-CJ53 Authorized Hardware Elements.

AC 20-145 is now cancelled.

Principal Changes. This change incorporates minor changes and updates, and a new appendix to AC 20-170. These changes are necessary in order to address incorrect references in RTCNDO-297 when using SAE ARP 4754, Rev. A, which is recognized by AC 20-174.

Information regarding whom you may contact with questions regarding the information in this AC, and where you may obtain a copy, are also included.

PAGE CONTROL Cl lART Remove Pa es Dated Insert P cs Dated Table of Contents. page 10/28/IO Table ofContents. page iv. ­ iv (12/28/I 0) Pages 3 through 4 10/28/10 Pages 3 through 4 Page 26 10/28/10 Page 26 Pages D-1 through D-3 10/20/10 Appendix D. pages 0-1 through D-3 Appendix H. page Il-1 ~ ~~ ~ f',;,J.. David W. I lempe Manager, Aircraft Engineering Division Aircraft Certification Division

### Page 2

AdvisoryU.S. Department of Transportation Federal viation Admini tration Circular Subject: Integrated M dular A ionics Date: I 0/28/ J o: 20-170 Development, Verificali n. Integration an Approval Using RTCA/OO -297 and Tecluucal Initiated by: AIR-120 Standard Order-Cl 53 Thi advi ory circular cts forth an acceptable mean f compliance for aircraft and engine s that utiliz [ntegrated Modular Avjonics (I.MA) ·ystems. This AC calls out and supplements the guidance materia] of RT A/DO-297 , Integrated Modular Avionics (IMA) Development Guidan e and Certification Consideration , dated November 2005. This A incorporates pertinent guidance material and infom1ati n from AC 20- l 45~ 01,idance for /11tegrated Modular Avio nics (JMA) that Implement TSO-CI 53 Authoriz.ed Hard ware Elements. AC 20-145 i now cancelled .

h~ David W. Hempe Manager, Aircraft Engine ring Di isi n Aircraft Certifica tion Divi. i n

### Page 3

10/28/10 AC20- 170 Table of Contents

Chapter 1 RTCA-0O-297 as an Acceptable Means of Compliance … 1

1-1. Purpose of this AC … 1

1-2. Whom this AC A ff~cts … l

1-3. Cancellation … 2

1-4. Using this AC and RTCA/ D O-297 … 2

1-5. App lying RTCAIDO-297 as an Acceptable Means of Comp liance … 2

1-6. What This AC Cove rs … 4

Chapter 2 Acceptance And Incremental Acceptance … 5

2-1. Compari son ofRTCAIDO 297 Acceptance and FAA Approval … 5

2-2. Major Benefits of Incremental Accepta nce … 6

2-3. IMA Module, Appli cation, S ystem, and Installation Acce ptan ce … 6

2-4. Documentation And Data Packaging … 7

Chapter 3 Obtaining an IMA Component Acceptance Letter … 8

3- 1. General Guidance Regar din g LM A Component Accep tance Letters … 8

3-2. Parts of the IMA Component Acceptance Letter … 9

3-3. Essen tial Elements of the IMA Compo nent Acceptance Cover Letter................... .......... I 0

3-4. Esse ntial Elements of the IMA Compone nt Accep tance Letter Data Sheet … 12

3-5. Acceptanc e Letter … 13

3-6. lMA Compon ent Accept anc e Letters For Revised IMA Component s … 13

3-7 . Cance lling an IMA Component Acceptance Letter … 14

Chapter 4 Reuse Of IMA Components … 15

4-1 . Reuse of an Accepted lMA Component. ...................... ...... ............................. ................. l 5

4-2. What Can Be Reused … 15

4-3. Reuse of Other Types of Comp liance Data ................................................. , … 16

4-4. Reuse of Previous ly Acce pted Software-O nl y or Hardware Componen t Contain ing

Airborne Software … 17

4-5. Reuse of CEH or Hardware Component Containin g CEH … 17

4-6. Reuse OfSEH or Hardware Compo nent Containing SEH … J8

II

### Page 4

4-7. Reuse of EQT Data … 18

4-8. Data the Componen t Developer Owes to Lhe IMA Developer /System Integrator or

Applicant … 19

4-9. Reuse of a Previous ly Accepted IMA Component That Wa.,., Revised … 19

4-10. Reuse of an fMA Component with a Previous TSO Authorization … 20

Chapter 5 Configuration Management of an IMA System … 21

5-1. IMA Configuration Management … 21

5-2. Automated, Robust Configuration Management ............... .......... ................. .................. .. 2 1

5-3. Non-Automated, Robust Configuration Management … 22

5-4. Software Loading Procedures … 22

5-5. Assurance Level of lMA Components Used in Configuration Management … 22

Chapter 6 IMA Recovery Features … 23

6-L Restarting Safety Critica l IMA Functions … 23

6-2. Restart Mechanism Implementation … 23

Chapter 7 Topics Not Covered by RTCA/DO-297 … 24

7-1. Electrical Power For IMA Systems … 24

7-2. Field Loadable Software … 24

7-3. Electronic Identification Guidance … 26

7-4. Aircraft System Lightning and HCRF Protection … 27

Chapter 8 Use Of TSO Authorized Components In IMA Systems … 29

8-1. IMA Syste.ms and TS Os … 29

8-2. TSO-C 153 Authorization for IMA Hardware Components … 29

8-3. FunctionaJ TSO Authorization … 30

8-4. EQT of IMA Components with TSO Authoriza tion … 30

8-5. lMA Compone nt TSO Part Marking … 31

8-6. Integration ofTSO Authorized Components in [MA Systems … 32

8-7. Aircraft Installation Approval of IM A Systems includin g TSO Autl1orized Components .

. … 32

8-8. Roles and Responsibilities When TSO Authorized Components Are Used in IMA

Systems … 32

Ill

### Page 5

Appendix A Environmental Qualification Guidance forTSO-C153 … A-1

Appendix B Sample IMA Component Acceptance Cover Letter … B-1

Appendix C Sample Acceptance Letter … C-1

Appendix D Related Documents And How To Get Them .•....•••...•...••...••.••• D-1

Appendix E Glossary … E-1

Appendix F Acronyms .............•..••..•••..••.......•..•....•..•......•.................•... F-1

Appendix G Partial List of Functional TSOs … G-1

Appendix H SAE ARP 4754 to ARP 4754A Cross-Reference Matrix ..• … H-1

iv

### Page 6

Chapter 1 RTCA-OQ ..297 as an Acceptable Means of Compliance.

1-l. Purpose of this AC.

a. This advisory circular (AC) shows you 110w to obtain Federal Aviation Administration (FAA) airworthiness approva l for the devel opment. verification , and integration of an integrated modular avionics (IMA) system for installation into an aircraft or engine. We cite RTCA, Inc.

document RTCA/DO-297 , Integrated Modular Avionics (IMA) Development Guidance and Certification Considerations , dated November 8, 2005 and supplement it with this text. This AC also provides guidance on how to show compliance with Technical Standard Order (TSO)-C15 3, integrated Modular Avionics Hardware Ele ments.

b. This AC is not mandatory and does not constitute a regulation. In it, we describe an acceptable means , though it is not the only means, to obtain FAA approval of rMA systems.

c. This AC uses the terminology "should'' when discussing compliance to the AC itself , as the AC represents one, but not the only, method of complying wiU1 the regulations. This AC uses the term ''must " when discussing compliance to the re_brtilations, as com pliance to a regulation is not optional ln these cases, the AC text supplies a reference to the specific rule(s) being discussed.

1-2. Whom this AC Affects.

a. We wrote this AC for:

(I) Applicants for type certificates (fC), amended TC (ATC), suppleme ntal TC (STC) , or amended STC (ASTC) of aircraft and aircraft engines implementing IMA systems and equipment ,

(2) Developer s of IMA systems, applications, and compo nents,

(3) Applican ts for TSO-C153 , Integrated Modular Avionics Hardwar e Elements , and for functiona l TSOs as they apply to IMA systems,

(4) Integrators of lMA systems,

(5) Installer s of the lMA syste m into the aircraft, and

(6) Those involved in the approval and continued airworthines s of IMA systems.

b. When the term ..applicant'' is used in this AC, we are refening to the applicant for an aircraft or engine TC. STC , A TC. or ASTC . When this AC is referrin g to an applicant for a TSO authorizat ion (TSOA), the phrase "applicant for TSO authorization " or other similar phrase is

### Page 7

used. When this AC is referring to an applicant for an IMA Component Acceptance Letter, the phrase "applicant for fMA Component Acccptanc ,e Letter • or othe r similar phrase is used .

1-3. Cancellation. This AC cancels AC 20-145, Guidance/or Integrated Modular Avionics (IMAJ that Jmpleme11t TSO-C153 Authori=ed Hardware Elements. and incorpornte s all pertin ent information from it that is not covered by RTCA/DO-297.

1-4. Using this AC and RTCA/0O-297.

a. The means in this AC are a complete method to sJ10w compliance and obtain approval of IMA components and systems for installatiou into an aircraft or engine. We intend that this AC be applied at the aircraft or engine level by the applicant for o TC, STC, A TC, or ASTC. That is, this AC is not intended as gujdance solely for an IMA developer, IMA system integrator , or lMA application/component supplier .

b. If you are an appl icant for an authorizution for TSO-C 153, Integrated Modular Avionics Hardware Elements, you may use the guidance in this AC as one acceptable means of compliance to requirements defined in TSO-C153. See paragraph 8-7 and appendix A ofthi s AC for more information.

c. We find that the objectives, processes, and activittes in RTCA/DO-297, plus the additional guidance material contained in this AC, constitute an acceptable means of compliance for the developm ent, integration, verification, and installation approval of1MA syste ms. If the applicant wants to propose an alternativ e means. including those from other industry documents refer enced by RTCA /DO-2 971 document those altemative means and secure FAA approval during yoUI project's planning stage. Prepare to use Issue Papers to document agreements reached.

d. According to the definition of an lMA in Appendix E. Glossary , an [MA is a "shared set of flexible, reusable , and interoperable hardware and software resources that, when integrated, fonn a platform that provide s services.'' You should keep in mind that an IMA system is defined by the system architecture, not by the functionality the syst em provides . lMA systems may not always imp lement functions historically regarded as "avio nics", such as flight deck displays, navigation, communication, etc. IMA syste ms may also be used to implement other aircraft functionality, such as fly-by-wire flight controls, inertial reference/air data systems, or electrical power control systems. The re may be more than one IMA sys tem on an aircraft. An IMA system could feasibly be mounted within an engine assembly.

1-5. App lying RTCA/DO -297 as an Acceptable Means of Compliance.

a. RTCNDO-297 des(..Tibes objectives. proce sses, and activities to incrementally accumulate design ass urance and accepta nce of IMA syste ms and components. RTCA/DO-297 refers to indu stry standar ds such as SAE Intemational' s Aerospace Recommended Practice (ARP) 4754, Certification Consideralio11sfor Highly Integrated or Complex Aircraft, Syste,ns, and SAE ARP 4761, Guidelines and Methods ofConducti11g the Safety Assessment Process 0 11 Civil Airborne Systems and Equipment. When RTCA/0O-297 invokes the processes and methods in specific 2

### Page 8

sections of those industry standards as part of the IMA development. integration, verification, or approval process, you should consider those sections of the referenced industry standard (or other acceptable alternative means) to be part of the overall acceptable means of compliance as outlined in RTCA/DO-297.

Note: SAE International updated their ARP 4754 to ARP 4754A, ··Guidelines.for Development ofCivil Aircraft and Systems"' in December 2010. AC 20-174. Development of Civil Aircrc!ff and Systems, dated September 30,2011, recognizes ARP 4754A as an acceptable means of compliance for development of aircraft systems. This revision A reflects a significant change to that document, including section and paragraph numbering from that used in the original release. As a result, several references to ARP 4754 by RTCA/DO-297 are incorrect when using SAE ARP 4754A. Please see appendix Hof this AC in order to cross reference ARP 4754 with ARP 4754A sections and paragraphs referenced by the original release ofRTCA/DO-297.

b. You may use this AC as an acceptable means of compliance for a IMA systems that include TSO authorized articles. Although RTCA/DO-297 docs not address TSOs, you should apply the intent of its objectives in Annex A to IMA systems that include TSO authorization(s) in order to obtain IMA system approval. See chapter 8 of this AC for more information.

c. If you choose to follow this AC to show compliance, apply the AC to your !MA development and approval process regardless of the complexity of the IMA system or business model under which it is developed and approved. RTCA/DO-297 is written primarily from the perspective of a complex IMA system developed and integrated by multiple organizations and companies (see RTCA/DO-297, subsection 2.4). Although the development, integration, verification. and approval of an IMA system developed by a single company are likely lo be less complex than for multiple companies. RTCA/DO-297 applies equally. This AC should be used as an acceptable means of compliance for IMA systems that:

(I) Arc developed by a single company as well as those developed by multiple companies.

lfa single company develops a complete IMA system, many of the separate roles defined in RTCA/DO-297 - such as !MA developer, application developer, and !MA integrator -- will be taken by this single company.

(2) Are simple IMA systems as well as complex IMA systems. These terms are purposely left undefined. because it is difficult to make a clear distinction between them. The purpose of this item is to illustrate that this AC should be applied to IMA systems of all levels of complexity.

(3) Are closed architecture as well as open architecture. (See Appendix E. Glossary.)

### Page 9

(4) Use TSO authorized components (that is, TSO-Cl53) and functional TSOs (such as TSO-C 113, Electronic Flight Displays and TSO-C9, Automatic Pilots) as well as IMA systems that do not use TSO authorized components.

Note: Because of the variations described inc. above, not all aspects of RTCND0-297 or the additional guidance contained in this AC may apply to every IMA development program.

We strongly recommend that any question regarding the application of this AC be discussed with us at the beginning of the certification program and the a!,>reements reached during those discussions be documented. The FAA may require an Issue Paper on these questions.

d. Appendix A of this AC, Environmental Qualification Guidance for TSO-Cl 53, Integrated Modular Avionics Hardware Elements. shows applicants for TSO-C 153 authorization how to conduct environmental qualification testing (EQT) that ensures compliance to the minimum performance standard (MPS) ofTSO-Cl53. We do not require compliance to appendix A if you are not using TSO-C 153 authori,:cd hardware components.

1-6. What This AC Covers. This AC describes an acceptable means by which to apply RTCND0-297, along with the additional guidance material included in this AC, to an aircraft or engine certification program which uses an IMA system. We cover the following subjects in detail:

-Acceptance and Incremental Acceptance (in chapter 2).

- Getting An IMA Component Acceptance Letter (in chapter 3 ).

- Reuse Of IMA Components (in chapter 4 ).

- Configuration Management of an !MA System (in chapter 5).

- IMA Recovery Features (in chapter 6).

- Additional Topics Not Covered by RTCA/D0-297 (in chapter 7).

- Use of TSO Authorized Components in !MA Systems (in chapter 8).

### Page 10

10/28/ lO AC 20-170 Chapter 2 Acceptance And Incremental Acceptance.

2-1. Comparison of RTCA/DO 297 Acceptance and FAA Approval.

a. RTCA /DO-297 , paragraph 2.1.2, gjves the following definitions:

(I) Acceptance -Acknowledgement by the FAA thal the moduJe1 application, or system comp lies with its defined requirem ents. Ac;ceptance is recognition by the FAA (typically in the form of a letter or stamped data sheet) signifying that the submission of data, justification, or claim of equivalence satisfies applicable guidance or requirements.

The goal of acceptance is to achieve credit for future use in a certification project.

(2) Incremental Acceptance - A process for obtaining credit toward approval and certification by accepting or finding that an IMA module. applicalion, and/or off-aircraft lMA syste m complies with specific requirement s. This incremental acceptance is divided into tasks. Credit granted for individual tasks contributes to the overall certification goal.

Increm ental acceptance provides tbe ability to integrate and accept new applications and/or module s, in an IMA system, and maintain existing applications and/or modules , without the need for re-acceptance.

b. We view acceptance, as defined above, as part of the processes documented by Title 14 of the Code of Federal Regulations ( l 4 CFR.) and published FAA policy used to approve airborne systems during an aircraft or engine certification program. To obtain approval for installation on a certified aircraft or engine, applicants must show that the aircraft or engine system/ fwiction meets with the applicable regulatory requfrements. See§§ 2 l. l 7, 21.20, and 2Ll 15. Some of the regulatory requirem ents are accompanied by an AC (such as this one) that describes one, but not the only, possible means of complying with those regulations.

c. The main differences between RTCA/DO-297 .. acceptance" and our current formal process of showing compliance in an aircraft certification program are 1) each stage of RTCA /OO-297 acceptance is accompanied by some fom1 of recogni tion, such as a "signed letter or stampe d data sheet" or <(accepted or approved comp liance data package,' ' and 2) a goal of acceptance, as defined by RTCA/DO-297 , is to "achieve credit for futur e use in a certification pro cess." Otherwise, the two concepts are very similar: data submission s and statements of compliance are used to show that an airborne system or component complies with all applicable requir ements and therefore can be approved for installation onto an aircraft or engine.

d. "Acceptance" is a term often used during the approval of aircraft or engine systems, but its meaning may not be consistent throughout the certification process. The meaning of this word can depend on the conte xt. For example, the RTCA/OO-297's "acceptance" is very similar, but not identical , lo AC 20-148, Reusable Software Components. That AC states:

"Acceptance is credit the FAA grants for fully or pruiially meeting RTCA/OO-178B objective s for an (Reusable Software Component) RSC. The FAA shows acceptance by issuing a RSC acceptance letter.'' Although the concept is similar between RTCA/DO-297 and AC 20-148, the specific definitions of "acceptance" are not identical. This examp le illu strates that the meaning 5

### Page 11

of ''acce ptance" may vary, given 1ts context. Make sure you understand the context and meaning of this term when you encounter it.

e. "Incremental acceptance", as defined in RTCA/ 00-297, takes the concept of acceptance further. lt divides acceptance into «certification tasks" accomplished during different points, or increments, in the certification program. Each task builds upon previous tasks. Incremental acceptance of IMA components is no1mally associated with the (MA Component Acceptance Letter process described by RTCA/00-297. See RTCA/ 00-297, Section 4 for more infom1ation.

f. An applicant may use acceptance of components within the IMA to accumulate certification credit towa rd instaJlation approval of an I.MA system on an aircraft or engine. The concept of acceptance does not alter or replace FAA certificatio n processes. [nstead, acceptance is a means to recognize that a specific lMA component complies with all docwnented requirements and objectives. and that an accepted component can be used without detailed examination of the compliance data for that component - that is, is the component acceptable for use in an approved airborne system? IMA Component Acceptance Letters described in Chapter 3 of this AC are not required to accumulate cettification credit toward installation approval.

2-2. Major Benefits of Incremental Acceptance.

a. The major bendit of using the incremental acceptance process, as defined in RTCA/D0­ 297, is that incrementa l acceptance provides the ability to integrate and accept new components in an IMA system and maintain existing components without the need for re-acceptance. This allows you to:

(I) Reuse accepted lMA components in multiple applications in the same certification program by submitting certification data packages that have an established pedigree. This reduces certification effort of the current aircraft or engine program without compromising system safety.

(2) Reuse accepted [MA components in future certification programs by submittin g certification data packages that have an established pedigree. This reduces follow-on certification effort without compromising system safety.

b. The incremental acceptance -process defined in RTCA/00-297 shows how to package and docwnent the data and artifacts of a specific IMA component, so the previously accepted data and artifacts may easily be used in multiple concurrent or future programs.

2-3. IMA Mod ule, App lication , System, and Installation Acceptance.

a. Acceptance at each stage of IMA development and verification, as described RTCA/00­ 297, subsection 4.2 (Task I - Module Acceptance), subsection 4.3 (Task 2 - Application Acceptance), subsection 4.4 (Task J - IMA System Acceptance), and subsection 4.5 (Task 4 ­ Aircraft integration oflMA System), is required for IMA system installation approval. We intend that a11 important aspects in RTCA/00-297 regarding IMA development, integration.

### Page 12

verification, and approval (Tasks 1 t11rougb 4) be fo11owed and you show that the IMA system complies with all object ives ofRTCA/00-297, Annex A, regardless of whether you request IMA Component Acceptance Letters. The IMA Component Acceptance Letter process covered in RTCA/D0-297, Section 4, and chapter 3 of this AC is optional. As an appl icant, IMA developer /system integrator. or IMA component supplier, you may decide whether or not to request an fMA Component Acceptance Letter.

Note: RTCA/D0-297 , subsection 4.6 (Task 5) deals with change s to acce pted modules and subsection 4. 7 (Task 6) <leals with reuse of modules or applications. These subsections are important and should be foJlowed. However , for the purposes ofthe initial accepta nce ofthe IMA system and approval for installation on an aircraft or engine, only subsections 4.2 through

4.5 (Tasks l though 4) are relevant. If previously accepted componen ts are being reused , subsection 4. 7 (Task 6) should a1so be consi<lered.

b. The documentation required to obtain acceptance when you are planning to reuse IMA components may be more than that required ifyou seeking approval for a component to be only used on a single TC/STC / ATC/ ASTC program. Although it is not mandatory, we strongly suggest that in your initial certification plans for the IMA system and/or compo nents, you state which compone nts for which you desire [MA Compone nt Acceptance Letters at the end of the certification program, aJong with the name of the company or companies that will be asking for those letters.

c. The FAA will not grant acceptance at the higher task levels- that is, Tasks 2, 3, and 4 ­ unti l aJJ acceptances at the subordinate leve ls on which those higher tasks depe nd have been completed. For example , to obtain acceptance for an IMA application, you should first obtain acceptance of all module s which comprise that applica tion. Likewise, all applications that make up an lMA system should be accepted before we accept the system.

d. If you are going to deviate from ccrti fication planning documents already accepted by the FAA, you should request a deviation to those plans. The request should include a justification for the deviation and the mitigating actions (if any) that you plan to take.

2-4. Documentation And Data Packaging . RTCA/D0-297 , Section 4 addresses the artifacts required for acceptance al the various task levels. Exa mples include the module acceptance plan , the module requirements specification, the module configuralion index, the fMA system certification plan, and the IMA system vaJidation and verification plan. This AC does not requir e that you use those spec ific document titles or methods of data packaging. They represent one particular acceptable means to comply with RTCND0-297. We accept alternative document titles and data packaging. However , if you use alternative documentation naming convention and data packagi ng, you should address all significant aspects in RTCA/D0-297 , Section 4 and Annex A to claim complianc e to this AC. See RTCA/D0-297 , subsection 4.1 for more infonnation.

### Page 13

Chapter 3 Obtaining an IMA Component Acceptance Letter.

3-1. Genera l Guidance Regarding IMA Component Acceptance Letters.

a. Obtaining an IMA Component Acceptance Letter is optiona l for app licants, IMA developers/system inte grators, and [MA component developers . The decision to apply or not app ly for an IMA Component Acceptance Letter has no bearing on the final approval of the IMA system and its instal lation onto an aircraft or engine. The main reason to obtain an IMA Component Acceptance Letter is to formall y document acceptance of the compliance data for future or concurrent reuse of that accept eel IMA component. If you do not request an IMA Component Acceptan ce Letter, we will not issue one.

b. We typicall y issue the fMA Compo nent Acceptance Letter after :

( I) The applicant has compl eted and submitted all applicable documentation and shown that the object ives ofRTCAID0-297, Annex A, Table A-1 and/or A-2 (depending on if the IMA component is a modul e or an application) , Table A-3, and Table A-4 have been achieved , and

(2) We find no installation, safety, operational , functiona l, or performance concerns.

c. lfthere are softwa re operating systems, generic hardware computing/power supply mod ules, or other IMA components not dependent on IMA system integration or aircraft installation, we may issue an IMA Compone nt Acceptance Letter before complet ion of those later stages of IMA development and integratio n. However, you should work with the FAA during the planning process if you desire an IMA Component Acceptance Letter ptior to the certification ofthe aircraft or engine. Otherw ise, this request for an IMA Compo nen t Acceptance Letter may not be prioritized according to your needs, as the FAA will nonnal ly issue IMA Component Acceptance Letters after the completion of the certification program.

d. Accord ing to RTCA /D0- 297, subsectio n 4.7, future reuse of compliance data for a previou sly accepted IMA component is limited to IMA modules and applications. Therefor e, we will only issue IMA Com ponent Acceptance Letters for IMA modules and applications. We will not iss ue [MA Compo nent Acceptance Letters for an IMA syste m or its installation onto an aircraft or engine.

c. RTCA/D0-297, subsection 4.1, states: "IMA acceptaJtce can only be proposed in the context of an actual certificatio n project.'' That means we issue IMA Component Acceptance Letters only for IMA components being developed and approved for a specific aircraft/engine certification program. We do not issue IMA Compo nent Acceptanc e Letters for TSO authorized articles that are not for an identifie d aircrafi/engine certification program .

f. A request for an IMA Compon ent Acceptance Letter is not limited to the developer of an IMA component. The appli cant, IMA developer /system integ rator, or lMA component develope r may apply for an £MA Compo nent Accept ance Letter . The intent to request an IMA 8

### Page 14

Component Acceptance Letter should be included in the appropriate certification -planning documentation.

g. Because lMA component acceptance is relevant only within the context of an aircraft/engine certification program, you may ask if a specific compliance data package belongs to the applicant, or to the company supplying the lMA component or system. The answer depend s upon the agreemenls reached between the various companies. Consequently, we strongly suggest that all pa1iies document their plan for IMA Component Acceptance Letters, including the intent for concurrent or future reuse, at the start of the aircraft or engine certification program . This way, all parties will understand and agree on how data for the current program may be used in the future-possibly for a different applicant than the current aircraft/engine program.

h. Use the following guidance to detennjne which FAA office you should apply to for an IMA Component Acceptance Letter:

(I) If there is a valid [MA Component Acceptance Letter for an IMA component and that component is being updated , then you sho uld apply for a new IMA Component Acceptance Letter to the Aircraft Certification Office (ACO) that issued the existing [MA Compone nt Acceptance Letter. Otherwise, use the guidance in items (2) through (5).

(2) If the IMA component in question will not also be getting a TSO authorization (either TSO-C 153 or functional TSO) , you should apply for an lMA Component Acceptance Letter to the ACO that is responsible for the certification of the aircraft or engine that will be using that rMA component.

(3) lfthe lMA compone nt is questi0n will also be getting a TSO authorization (either TSO-Cl 53 or functional TSO), you should apply for a new IMA Component Acceptance Letter to the ACO that is responsible for issuing the TSO authori zation for that IMA component.

(4) If the aircraft or engine in which the IMA component is to be installed is of non-U.S.

design and manufacture , you should apply for an IMA Component Acceptance Letter to the ACO that you would norma lly apply to for a TSO authorization . The manufacturer of that aircraft or engine should be in the process of obtaining , or has already obtained, an FAA certification. We will not issue an IMA Component Acceptance Letter for an lMA component that is used on an aircraft or engine that is not seeking an FAA certHication. In this case, the ACO to which the application for an IMA Component Acceptance Letter is made will coordinate with the FAA office that is acting as the Validating Authority for lhat aircraft or engine program .

(5) We will not issue an I.NIA Componen t Acceptance letter to a company that is not based within the United States. There JS not an ACO that has geographic respons ibility and oversight of that company .

3-2. Parts of the [MA Component Acceptance Letter.

a. An IMA Component Acceptance Letter is composed of three parts:

Q

### Page 15

(I) The IMA Component Acceptance Cover Letter , prepared and signed by the applicant for the IMA Component Acceptance Letter . See paragraph 3-3.

(2) The 1MA Component Acceptance Letter data sheet. prepared by the applicant for the IMA Component Acceptance Letter . See paragraph 3-4.

(3) The Acceptan ce Letter , prepared and signed by the FAA. See paragraph 3-5.

b. If you are an applican t for an IMA Component Acceptance Letter, assemble your request package (both the complet ed IMA Component Acceptance Cover Letter and the lMA Component Acceptance Letter data sheet) and submit it to the appropriate FAA office. If we approve your request, we will prepare and sign a Accepta nce Lette r for that [MA component.

We will send the applicant ·for the IMA Compo nent Acceptance Letter a copy of the IMA Component Acceptance Cover Letter and the signed Acceptance Letter. We will retain and archive the original of all three parts of the IMA Component Acceptance Letter.

c. At your re-quest, we will provide extra copies of the signed Acceptance Letter and !MA Component Acceptance Cove r Letter to you or to another company.

d. You should maintain your own files of the IMA Com ponent Acceptance Cover Letter and IMA Compone nt Acceptance Letter data sheet. We will not provide copies of the IMA Component Acceptance Letter data sheet.

e. We do not allow modification s to previo-usly accepted IMA components under an existing lMA Compon ent Acceptance Letter . [f you chang e a previously accep ted IMA component and still want an IMA Component Acceptance Letter, you wm have to apply for another one. See paragraph 4-9 of this AC for more information on changes to an accepted lMA component.

3-3. Essent ial Elements of the IMA Component Acceptance Cover Letter.

a. The IMA Compo nent Acceptance Cover Letter specifies what compliance data is being accepted by the FAA . The applicant for an IMA Component Acceptance Letter should include the followjng information in the IMA Compone nt Acceptance Cove r Letter:

(1) Date of appl ication for the IMA Component Acceptance Letter .

(2) The FAA office to which tbe request for an IMA Component Acceptance Letter is being made.

(3) Unique identifier for the JMA Comp<.1nent Acceptance Cover Letter. The specific fo1111at of this ident ifier is left to the discretio n of the applicant for the IMA Component Acceptance Letter. It could be a company correspondence number or a uniqu e identifier used solely for the purpose of application for IMA Component Acceptance Letters. However, once a particular identification is used. it should not be re-used .

### Page 16

(4) Name and contact infonnati on for the company requesting the IMA Componen t Acceptance Letter .

(5) Name and contact information of the origina l IMA developer /system integrator , the airborne system and aircraft/e ngine in which the compo nent will be installed . the target environment , such as the microprocessor , memory management unit, data busses, input/output devices ~ etc., and other infonnation about the initial acceptance of the IMA component. lnclude name and contact infomiation of the IMA component developer, if different than the applicant for the IMA Component Acceptance Lette r.

(6) Contact infonnatio n fot persons or organizations who will answer questions about compone nt accept ance and concurrent/future reuse.

(7) IMA compo nent name, unique component identifier, and all associate d document number s, titles, and revision levels. Examples are the system, softw are or hardware (as appropriate) con figuration index number and revision. a component's acceptance accomplishme nt summary number and revision, and any configuration information not included in the module configu ration index.

(8) All configu ration infom1ation (use references t o other documents as necessary) to fully define the component and its development environment.

(9) High level description of the component pw-pose und usage domain. See RTCA/DO­ 297, paragra phs 4.2. l0 and 4.3.2. and the Glossary ofthis AC for the discussion of and definition of usage doma in.

( I 0) Short description of the software partitions, software levels, and hardware design assurance levels within the component.

(l 1) Definitio n of the comp! iance <lata type(s) being accepted and documented by this IMA component acceptan ce letter - that is. airborne so'flware, complex electronic hardware (CEH), comprehensive testing for simple electronic hardware (SEH) component s, EQT. and any other data type that has been mutuall y agrce<l on.

(12) State whether each compliance data type shows full or partial comp liance to their respective standards - for example, RTCA/DO- 1788 for airborne software. A full descripti on of any pa11ial complianc e is not necessary, as we expect you lo include that infonnatio n 1n the IMA Component Acceptance Letter data sheet described in paragraph 3-4.

(13) Stateme nt of compliance that the signatorie s attest that the IMA component meets al] the applicable requirem ents defined in the lMA Component Acceptance Letter.

(14) Signa tures and dates. At least one managerial signature representing each of the technical discipline s cove red by the IMA Compone nt Acceptance Letter: RTCA/D O-17 8B compliance for airborn e software, RTCA/DO-254 compliance for CEH, com prehensive testing 11

### Page 17

10/28/ lO AC 20-170 and analysis of SEH, and RTCA/DO- I 60F compliance for EQT. One signature may cover more than one technical disciplines. Other signatures , such as engineering personnel, may be included if the applicant for the lMA Component Acceptance Letter desires. Each signature should include the date of the signature and the typed or printed name, as well as an identification of which technical discipline that signature covers.

b. See appendix B for a sample lMA Component Acceptance Cover Letter .

3-4. EssentiaJ Elements of the IMA Component Acceptance Letter Data Sheet.

a. The IMA Component Acceptance Cover Letter or the accompanying IMA Component Acceptance Letter data sheet should fully define the usage domain of the IMA component, or else it should reference a document where the usage domain of the TMA component is fully defined. If that infonnation is not in the fMA Component Acceptance Cover Letter, then you should include it as part of the accompanying LMA Compo nent Acceptance Letter data sheet.

b. Each IMA Component Acceptance Letter data sheet shou ld contain, at a minimum:

(1) Assumptions the JMA component developer made during the acceptance . These assumptions may be documented by referencing the compo nent developer's accomplishment summary or other appropriate certification docum ent. Include assumptions for each applicable RTCA/OO-297 objective in lhe approprial'e accompl ishment summary. The asswnptions should be detailed enough that the FAA, the lMA developer /systc..,ns integrator, and applicant can apply this information to any future or concur rent IMA programs that will reuse this component.

(2) Summary of technical or policy issues that arose during the initial acceptance and how the applicant and FAA reso lved them .

(3) Summary of additional activities that the lMA developer /system integrator and/or applicant need to perform to ensure that all objectives of RTCA-DO-297 Task s 3 and 4 can be met when using the accepted [MA component. Describe any remaining compliance activity required to show full compliance to the appropriate standard - for example, RTCA/DO-178B for airborne software, any remaining EQT requ ired by RTCA/DO-160F, Environmental Conditions and Test Procedures.for Airborne Equipment, not covered by the lMA Component Acceptance Letter.

(4) The softwa re level (s) and/or hardware design assurance level(s) of all software partitions and/or CEH/SEH devices .

(5) A description of the target computer. incl.uding the applicable hardware , operating system, board support package. diivers, etc., that will host software to perfonn aircraft-level functions.

(6) High-level description of the function and/o r purpose of the component and target environment. If the component conta ins multiple soltwa re partitions and/or multiple CEH/SEH devices , include a high level description of each. This allows us and the IMA component 12

### Page 18

integrator to clearly understand the relationship of each partition and/or hardware device and their associated software levels and/or hardware design assurance levels .

(7) Testing levels achieved for aU EQTs performed.

(8) Limitations , plu s any installati on, safety, operational. functiona l, or performance issues.

(9) Module or application acceptance dat~ including interface specifications, user's guide, and usage domain described in RTCA/DO- 297, paragraphs 4.2.4e, 4.2.10, 4.2.12e, 4.3.2, and4.4.2.

( I 0) Full explanation of kinds of technical data other than those specific technical discipline s addressed in paragrnph 4-2.b of this AC included in the lMA Component Acceptance Letter. The applfoant for the lMA Component Acceptance Letter should also include a detailed explanation of what remains to be done by the IMA developer /system integrator and/or aircraft or engine manufacturer , to obtain full comp liance for the compliance data associated with this technical discipline.

( 11 ) A copy of any pertinent document that demonstrates the compliance data contained in the JMA Component Acceptance Letter data sheet has been evaluat ed and found acceptable by the FAA orby an authorized representative of the FAA. Examp les include signed 8110-3 fonns and TSOA letters. By including evidence that data within the IMA Component Acceptance Letter data sheet has found Lo be acceptab le, you will significantly speed the process of evaluating the application for an IMA Component Acceptance Letter .

3-5. Acceptance Letter.

a. The FAA will prepare and sign an Acceptance Letter for the IMA component to signify that the IMA component has been accepted . Tile Acceptance Letter will reference the IMA Component Acceptance Cover Letter unique identifier , so that the Acceptance Letter will be associated with that spec i fie lMA Component Acceptance Cover Letter .

b. See Appendix C for a sample Acceptance Letter.

3-6. IMA Component Acceptance Letten For Revised IMA Components.

a. If a previous ly accepted [MA component has been changed or revised in any manner, the original IMA Component Acceptance Letter is no longe r valid. As stated in paragraph 3-5 above, an IMA Component Acceptance Letter is associated with a specific configuration of that component, defined by its accompanying documentation. Any change to a previously accepted IMA component requires at least some of tbe accom panying documentation - such as the component configuration index - to be updated . This requires a new IMA Component Acceptance Letter.

### Page 19

b. Lfthere's a change to a previou sly accepted IMA component and you want a new IMA Component Acceptance Letter for it, you should show that the component meets the guidance of RTCA /D0-297, subsection 4.6 for the updated IMA component. Paragraph 4.6.5 ofRTCA/D0­ 297 discusses the change data that should be submitted when requesting a new IMA Component Acceptance Letter for a change to a previously accepted !MA component.

3-7. Cancelling an lMA Component Acceptance Letter.

a. The FAA may cancel a previou sly issued IMA Compone1;1t Acceptance Letter. Reasons that we may cancel an IMA Com ponent Acceptance Letter include , but are not limited to, the followmg:

(1) The accepted IMA component is determined lo be the cause of or contributed to an in-service accident or safety related incident.

(2) The accepted IMA component is the subject of a § 21.3 report.

(3) The lMA component developer. IMA devel ope r/system integrat or, or applicant detenninc s that the IMA component does not meet the acceptance criteria defined in the original IMA Com ponent Acceptance Letter.

(4) It is discovered that the accepted component was developed from erroneo u s or incomplete requirements. and those erroneous or incomplet e requirements could, given the correct circumstances, lead to a reduction in safety in any aiTcraft or engine in which the compone nt i.s installed.

b. We wilJ notify the holder of an IMA Component Acceptance Letter when it is cancelled .

This action has the effect of not al1owing that version of the lMA component to be reused on a future or concurrent certificati on program until U1e reason for the cancellation has been addressed. A new IMA Component Accept ance Letter for the updated JMA component may be requested per para!:,'Taph 3-6.

Note: Cancelling an IMA Component Acceptance Letler has no bearing on the continued safe operation of an aircraft or engine that uses that IMA component. lf action is required, the FAA will issue an Airworthiness Directive lhat will require operators to update the compone nt or aircraft function in question.

c. We expec t the holder of an £MA Compo nent Acceptance Letter to contact the ACO that issued the IMA Component Acceptance Letter in a timely manner if any issues such as those listed in a. are discovered.

### Page 20

Chapter 4 Reuse Of IMA Components .

4-1. Reuse of an Accep ted IMA Component.

a. If a previously accepted IMA com ponent is unchanged, its intended reuse meets the limitations in the IMA Component Accepta nce Letter, and the FAA engineer for the certification program in which the lMA component is being reused does not have any concerns, you may reuse that component without need for additional FAA review of U1e originally accepted IMA component comp liance data.

b. If you are an IMA developer/system integrator or applicant proposing to reuse a previously accepted IMA compo nent, you sho uld ens ure and document that you identified no safety, installation, operat ional, functional, or performance concems with the subsequent use of that component.

c. Although the intent of IMA Component Acceptance Letters is to document our acceptance of the comp liance data for an IMA component , the existence of such a letter does not prevent us, on a new or concurrent TC/STC/ A TC/ASTC program , from requesting to examine the com plian ce dala associated wilh lhe ::iccepted IMA component if we have questions or conce rns. We will first try to address any open questions without resorting to re-examination of the previously accepted compliance data. However, ifwe have specific concerns that cannot be answered hy any other means, we may ask you to provide some of the previously accepted dnta. Only compl iance data spec ific to the identified issue or concem should need to be rc-exam in~d. If the initial IM A Component Acceptance Letter was done correctly and all necessary com pliance data was included in the IMA Component Acceptance Letter, we should not need lo resort to re-examination of previously accepted compliance data.

d. RTCND0-297, paragraph 4. 7. I. states that future reuse of any component should be plann ed during the initial development of that component and documented in tbe appropriate certification planning documen t. An IMA com ponent not mitially developed for future reuse and lacking a signed Acceptance Letter should be treated as a newly developed component.

4-2. What Can Be Reused.

a. RTCA/D0-297, subsectio n 4.7 states that reus e of a previously accepted compon ent should be limited to modu les (see Task 1 in RTCA/D0-297, subsectio n 4.2) and applications (Task 2, subsection 4.3). We do not allow reuse of previously accepted data at the IMA system level (Task 3, subsectio n 4.4) or IMA installation level (Task 4, subsection 4.5).

b. RTCA/00-297, subsect ion 4.7 Jimits reuse of the types ofdata for Tasks 1 and 2 to the following technical subjects:

(1) Airborne sotlware compliance to RTCA/D0-1788. See RTCND0-297 , paragraph

4.7.2 and paragraph 4-4 below.

### Page 21

(2) CEH component compliance lo RTCA/DO-254 . See RTCA/DO-297 , paragraph

4. 7.3 and paragraph 4-5 below.

(3) EQT compliance to RTCA/DO-1 60F. See RTC N DO-297, paragraph 4.7.4 and to paragraph 4-7 below .

c. In addition to those three techni cal data types, this AC identifies comprehensive testing of SEH as another data type for which acceptance data can readily be develop ed, packaged , and accepted for future reuse. Reuse of compliance data for SEH is not covered in RTCAIDO- 297.

( I) RTCAIDO- 254, subsection 1.6, provides the following definition:

Simple Hardwar e Item - Item with a comprehe nsive combinati on of detertn inistic tests and analyses appropriate to the design assurance level that ensures correct functional perfonnance under all foreseeable operating conditions, with no anomalous behavior.

(2) AC 20-152, RTCA, Inc., Document R.TCAID0 -254, Design Assura nce Guidance.for Airborne Electronic Hardware, says that applicants should apply RTCA/DO-254 to custom micro- coded components , which are a subset of "hardwa re items." This is AC 20-152's definition:

Custom micro-coded component - A component that includes application specific integrated circuits (ASIC) , programmable logic devices (PLO) , field programmable gate atTays (FPGA) and olhe r similar electronic components used in the design of aircraft systems and equipment.

(3) FAA Order 8110. 105, paragraph 5-1, explajns that SEH is a custom micro­ coded com ponent that satjsfies the definition a simple hardware item of RTCA/DO-254 .

The design of an SER device can be shown to be correct and complete by comprehe nsive testing and analysis without a detailed development assurance process. Ask your FAA ACO for more information regarding definit ions and explanatio ns of CEH, SEH, hardware items, and custom micro-coded devices . See RTC A/0O-254) subsect ion 1.6 for more information on si mple hardware items .

4-3. Reuse of Other Types of Compliance Data.

a. If you are an 1MA component developer intending to develop any data for future reuse beyond those listed in 4-2.b and 4-2.c, you should include U1is intent in the appropriate certification planning document. Work closely with us, the fMA developer /system integrat or, and applicant at the beginning of the component development program to ensure that future reuse ofthis data is feasible, and all parties agree on what is required to ensure the succe ss of any future reuse. We are not required. to accept a proposal for future reuse of data beyond those listed in 4-2.b and 4-2.c. but we wm consider your proposal.

### Page 22

10/28/ 10 AC 20-170

b. Any compliance data beyond those data types listed in paragraph s 4-2.b and 4-2.c. that you propose for inclusion in an TMA Component Acceptance Letter should fall within Tasks I and 21 per paragraph 4-2 above.

c. The IMA component requirement s for the additional compliance data types should be documented in an appropriate certification document and referenced in either the IMA Component Acceptance Cover Letter or the IMA Component Acceptance Letter data sheet.

4-4. Reuse of Previously Accepted Software-Only or Hardware Component Containing Airborne Software.

a. RTCA/DO-297 , paragraph 4.7.2 , addre sses reu se of a software module or application.

However , as stated in RTCNDO-297, paragraph 4.7.5, this guidance should also be followed for IMA hardware component s that contain airborne software .

b. lo additi on to the guidance for reuse of a previously accepted component containing airborne software provided by RTCA/DO -297, the guidance for the reuse of afrbome software contained in AC 20-148, Reusable Softwar e Components, should also be used in its entirety , with the exception of Chapter 9 which addres ses the Reusable Software Component (RSC) Accept ance Letter. AC 20-148 contains more detail than RTCNDO-297 about developing airborne software for reuse , and reusing that so ftwar e i11 another project. AC 20-148 specifies the roles a nd responsibilitie s of all partie s, the processes LO be used, how the data should be developed when future reuse is intended , and what data should be suppli ed by the software develop er to the integrator of the software or to the applicant.

c. RTCA /DO-297 , paragraph 4. 7.2 states lhal the prerequisites for reusing previousl y accepted so ftware is that the software should be hosted on the "same target hardware " and is 'used in the same way operationa lly" for the carJier accepted application and the intended reuse applicati on. Given the rapid change in technolog y employed in today 's IMA systems as well as the rapid rate ofhardwar e parts obsole scence. it' s likel y that the intended platfonn that is to host the reused software component wm not includ e the same target hardware that initially hosted the accepted software. The target hardware may include a microprocesso r from the same family as that of the pre vious target hardware . Howe ver, coming from the same family of microproces sors does not automatically quali fy as " the same target hard ware." lf an lMA developer/syst em integrator or applicant wants to reuse a previous ly accepted IMA component that contains software . but that software will be hosted on non-identi cal target hardwar e, the applicant shou ld ensure compliance with all RTCA/DO-178B and RTCA/0O-297 objectiv es and document how they intend on showin g that comp liance.

4-5. Reu se of CEH or Hardware Component Containing CEH.

a. AC 20-152 , paragraph 2.c states that RTCA /DO-254 applies to complex custom micro­ coded components wiU1 hardware design assurance levels A, B, and C. See paragraph 4-2.c (2) for defin ition of custom micro-coded components. Accordingly , we restrict grantin g IMA Component Acceptance Letters {per RTCA/ DO-297, paragraph 4.7.3) to RTCA/DO-254 17

### Page 23

complex custom micro- coded components - that is, to CEH and not commercial-off-the-shelf (COTS) hardware device s.

b. Your ACO will use FAA Order 8 1 l 0.105 for definitions and additional information on usingRTCNDO-254 as an accep table m eans of compliance .

c. Currently , there is no guidance for CEH that define ::; a detailed acceptable means of complian ce similar to that provided by AC 20- 148 for an RSC. However , because of the many similari6e s between the processes in RTC A/OO-17 88 for airborne software and those in RTCA/D O-254 for airborne electronic hardwar e, adapt the paragraphs of AC 20-148 listed below to CEH. Use these paragraphs of AC 20-148 when negotiating an agreement between yourself and us on reusing CEH compon ents:

( l) Paragraph 4 - Genera l Guidelit1es for Getting the FAA 10 Accept an RSC .

(2) Paragraph 5 - Guidelines for the RSC Developer.

(3) Paragraph 6 - Data the RSC Developer Must Supply to the RSC Lntegra tor or Applicant.

(4) Paragraph 7 - Guidelines for the lntegrator and Applicant Using the RSC.

(5) Paragraph 8 - Expectations from FAA on First Use of an RSC.

(6) Paragraph J0 - Expectation s from FAA on the Subsequent Use of an Accepte d R SC.

4-6. Reuse Of SEH or Hardwa re Component Containing SEH. As with CEH, there's no current guidance on reusing SEH compliu.nce data. Consul t the same paragraphs listed 1n paragraph 4-5 above when negotiating wilb us on adapting and using these paragraphs for SEH components. Your ACO wiIJ use FAA Order 8 1 J0.105 for infonnation on SEH and our expectati ons regarding comprehensive testing of SEH component s.

4-7. Reuse of EQT Data.

a. RTCA/ DO-160F , Section 1, stresses the importan ce of selecting the right environmental conditions and test pro cedure s for equipment under test. A phrase used throughout RTCA /DO­ 160F is, ''detennine comp liance with applicable equipment perfo nnance standards.'' If you are the teste r responsible for EQT, it is up to you l o detennine the s pedfic test configuration and requirements appropriate for the equipment und er test. There are many aspect s of environmental testing - vibration levels, temperature , altitud e, orie ntation of equipment , electrical connectors, electrical ground ing schemes, and electri cal wire lengths - specific to the aircraft in which the equipment will be installed . The qualificati on test plan for the equi pment under test should proper ly define all variable test parameters .

b. RTCA/DO-297 , paragraph 5.2.6 stresses the flexibility and reconfi1:,,urable nature of modem 1MA systems. That is, although the basic architeclure of an IMA system is set and will 18

### Page 24

J0/28/10 not change, each lMA system can be tailored specifica lly for the aircraft or engine in which it is installed. This is true for the functionality provided by the IMA system as well as for the environmental conditions to which it is subjected- for example, vibration levels for installation in a rotorcraft versus a fixed wing aircraft. This flexibility , while beneficial in many respects, introduces complications when you attempt to develop reusable EQT data per RTCA/DO-297 , paragraph 4.7.4.

c. A company asking us for an lMA Component Acceptance Letter for an IMA component being developed for future reuse should ensure that the data package of this component clearly identifies all variables and parameters used during EQT. The LMA developer /system integrator intent on reusing a previously accepted component which includes EQT data should ensure that all aspects of that testing are appropriate for the aircratl or engine in which it will be installed. If any testing variable or parameter used during the component's initial acceptance is not identica l to what is required for the intended reuse , then Lhe integrator of U1at previou sly accepted component sho uld document those differ ences and justify why they are acceptable for the new intended installation. If there is not adequate justification for any difference between the original acceptance and the intended reuse , then the fMA developer/syste m integrator or applicant sho uld re-test that aspect of the EQT, using the appropriate values and test configurations.

4-8. Data the Component Developer Owes to the IMA Developer /System Integrator or Applicant.

a. The developer of a previousl y accepted !MA component should supply the IMA developer /system jntegrato r and/or applicant who is reusing the component with many different types ofdata. This ensures that the lMA developer/system integrator and applicant can fully satisfy tho objectives ofRTCA/DO-297, subsection 4.7 and Annex A. The data required by the IMA developer/system integrator and applicant are likely to exceed that included in the IMA Component Acceptance Letter.

b. instead of providing data directly to another company, the developer of a previously accepted lMA component may choose to use a data/software escrow approach. See AC 20-148, paragraph 6.j(2) for guidance regarding data/software escrow .

c. AC 20- 148, paragraph 6 detail s the data for airborne software that a developer of a pre vious ly accepte<l software component shou ld make available to the IMA developer/syste m integrator, the apphcant, and to us, if we ask. As noted pre viously, there is oo similar guidance for accepted reuse of either RTCA/DO- 254 or RTCA/DO- I60F compliance data. Howev er, RTCA/DO- 297, parabrraphs 4.2.3, 4.2 .12, 4.3.1, and 4.3.2 document many of the elements required. A developer of a previou sly accepted IMA component should provide the data required to ensure comp liance with RTC A/DO-297, subsection 4.7 and with the objectives of Annex A, eithe r directly or by data escrow, to the IMA developer /system integrator and/or applicant.

4-9. Reuse of a Previously Accepted lMA Component That Was Revised. A previou sly accep ted IMA component that has been revised since its last acceptance should meet the 19

### Page 25

guidance in RTCA/DO-297, subsection 4-5 lo be reused in a new or concurrent application. lf you want a new IMA Component Acceptance Letter, see paragraph 3-6.

4-·10. Reuse of an IMA Component with n Previous TSO Autborjzation.

a. If the IMA compone nt that has a previous TSO authorization also has been previously issued an IMA Component Acceptance Letter. then the process for reuse of a previous ly accepted TMA component takes precedence. The applicant and IMA developer /system inte&rrator should use the guidance in section 4 without regard to remainder of this paragraph.

b. lfthe IMA compo nent that has a previous TSO authorization has not been issued an IMA Compone nt Acceptance Letter, then the following applies:

(1) You sho uld follow all limitation s descr ibed in the TSO authorization when integrating the component into the IMA sys tem . These limitations should be documented in the appropriate certification planning documenl(s) .

(2) The intended usage domain of th~ TSO authorized IMA component should be identical to the usage domain ident ified in the TSO authorization. If the intended usage domajn is not the same as identified in the TSO authorization, then you should <lo analysjs and/or testing to demonstrate those differences do not affect the use of the IMA component within the intended usage domain .

(3) You should identify all RTCA /DO - 178B and RTCA/DO-254 objectives that have only been partially met under the TSO authorization and descri be in the appropriate certification planning document(s) how full compliance to these objecti ves will be shown for the integrated rMA syste m. See AC 20-148, paragraph 5.d(t) for more infonnat ion.

(4) You sho uld identify all remaining EQT that are required for the aircraft or engine installation that is not cove red by the TSO authorization. These remaining EQT should be described in the appropriate certification planning document( s). Any EQT result s from the TSO authorization that you des ire to take credit for at the aircra ft or engine installation level shou ld be described in the appropriate certification planning document(s). See paragraph 4-7 for more information regarding reuse of EQT data.

(5) Any SEH dev ices that arc within the TSO authorized IMA component should be identified in the appropriate certification planning uocument(s). Compliance to RTCA /DO-254 for SEH devices are not covered by TSO authorizat ions, unless specifically stated in the TSO .

The guidance of paragraph 4-6 should be used.

### Page 26

L0/28/10 AC 20-170 Chapter 5 Configuration Management of an IMA System .

5·1. IMA Config uration Management.

a. The applicant is responsible for overall IMA system configuration management.

b. Configuration management of an [MA system instol led in an aircraft is critical because the system may contain many hardware components and functiona l software components, with each component having multiple approved version s or on-aircraft option selections. Some possibl e combinations of hardware and soflware versions will not be approved for flight.

c. Configuration management tec hniques to manage tJ1e IMA architecture are necessary to safely accommodate system attributes. such as (but not limited to) the followi ng:

(J) Hosting multiple software appl ications on a single processor or on multiple , non­ dedicated processo rs.

(2) Produc ing and distribu ting hardware components without loadi ng specific funct ional software.

(3) Allowing electronic part nwnbering for software components, without the need to physica lly mark hardware elements with the software part number(s).

(4) Allowing the clectronfo disp lay ofTSO ide ntificat ion.

(5) Allowi ng the field-loadi ng of hardware components with functional software components for efficient maintenance and incorporation of approved design c hanges .

(6) Allowjng the stocking of gene1ic, non-configured hardware components for maintenance purpose s. A non-co nfigu r~ hardware component is one that does not already contain the functional software componen ts needed for satisfying an airc raft, engine or system function. These hardware components will be loaded later with field-loadable software. Each generic hardware component may have multiple versions, as components normally undergo update s during their lifecycle . Unless a specific effort is made to purge operato r spares of earlier versions of a hardware component, you should assume that every version of a hardware component will exist in service and couJd be used on an aircraft or engine insta llation.

(7) Providing the ability to update and maintain IMA sys tem configuration files without corruption.

5-2. Automated, Rob ust Configuration Management.

a. We stro ngly recommend a robust, automated configuration management scheme for an IMA syste m installed on an aircraft. A key feature of an automated configuration management scheme is that the IMA syste m itself monit ors the configuration of either all or a subset of the 21

### Page 27

10/28/ t0 AC 20-170 IMA hardware and software components. When an invalid configuration of the monitored components is detected, it should be annunciated in a way that will not allow the aircraft to be dispatched until the invalid configuration is corrected.

b. A robust, automated configuration management scheme shou ld be ab le to detect , at a muumum:

(I) Incompatible versions of a software component hosted in a hardware component.

(2) Incompatible versions of multiple copies of a software com ponent hosted in multiple hardware components .

(3) Incompatibilities or uncertified configurations between various systems that are closely coup led, such as autopilot and flight managem em systems .

(4) Incompatible system configurations with the aircrafl model in which it is installed , and

(5) Incompatjb )e optio n select ions.

c. Any loss of function caused by configuration management system protections must be shown to be acceptab le through the applicant's aircraft or engine level safety assessment. See § xx.1309, xx denoting parts 23, 25, 27, or 29 as applicable .

5-3. Non-Automated, Robust Configuration Management. lf your configuratio n management scheme of the .IMA system installed on the airc raft or engine is not automated or depend s on maintenance personnel to config ure the system, either fully or partially , and to determine if the system configuration correct for that specific aircraft or engine. you should explain, in the appropriate certification document , why your configuration management scheme is robust. You should address possible issues with your proposed approach , such as likely maintenance errors that could result in a uon-opproved rMA configurati on. You shou ld explain the testing and analysis that you plan to do to ensure the process is indeed robust.

5-4. Software Loading Procedures. For lMA systems that allow on-aircraft loading of software , the applicant should provide field-loading procedures that ensure correct software loading, as well as a means to vetify that the software load operation was com pleted successfully and that the corre ct version of software is now installed.

5-5. Assurance Level of IMA Components Used in Configuration Management Any IMA system component used in determining the validity and/or safety of an IMA configuration, whether the configuration management syste m is fully automated or manual , should be developed to the assurance level commensurate with the hazard classificati on of allowing a non.­ approved configuration to be dispatched . This includes automatic configuration monitoring and displaying electronically stored part numbers and versions on a flight deck or maintenance displa y.

### Page 28

10/28/ 1() AC 20-170 Chapter 6 IMA Recovery Features .

6-1. Restarting Safety Critical IMA Functions. Due to unfo reseen circumstances. an fMA function, collection of lMA functio ns, or an entire Uv1A cabine t may unexpe ctedly shut down without the hosting ]MA hardwa re com pone11ts experiencing a pcnnanent failure. IMA systems must include the ability to restart any hosted function or functions whose cont inued ope1·ation is requir ed by the sys tem or aircraft level safety assessme nt. See § xx. 1309, x.x denoting parts 23, 25 . 27, or 29 as applicable.

6-2. Restart Mechanism Implementation .

a. An IMA function or system restrut feature includ ed in an IMA system, when feasible, should be initiated automatically when a safety critical loss of functi on is detected. The IMA design should avoid the need for crew-ini tiated recovery features.

b. lf an autom atic recovery feat ure is not feasible and a crew- initiated - that is, non­ automated - recovery feature is implem ented instead. you should put protection mechani sms and operations procedures in place to prevent accidental a1,.'tivalion of the recovery featw-e b y the flight crew

c. The system design should carefully consider how man y automatic attempts at restarting failed lMA functions or cabinets should be attempted . Allempting to restart indefinitely when the failed function or cabinet repeated ly shuts itself down may cause increased crew workl oad or distraction. Repeated failures after resta rt attempts may indicate that there is a fai led JMA resource that should not be restarte d. The system resta.it mechanism design should consider potential causes for restarts and determine the appropriate nwnber ofrestarts to attempt before dec]aring the system failed. Factors that influence this ar~hilecturc are the failure condition(s) assoc iated with loss of IMA functionality , the in1pact of multipl e restruts of a function or functions on interfacing sys tems , and the functionality rema ining from non- LMA systems.

d. The IMA design should not rely on cycling aircraft circuit breakers to restart any IMA syste m or function . If crew- initiated manual recovery feature s a re used, design a means other than cycling circuit breakers.

e. The appl1cant should evaluate the effects of automati cally and/or manua lly activating recove ry features in both normal and failed condition s for all phases of flight. The applicant should evaluate the effect s of loss of functions durin g manual or automa tic restart for all phases of flight.

### Page 29

I 0/28/10 AC 20-1 70 Chapter 7 Topics Not Covered by RTCA/00-297 .

7-1. Electrical Power For l MA Systems.

a. The applicant and lMA developer /system integrator should design the physical and electrical power architec ture of the lMA to suppoti the flight crew's ability to manage smoke or fire events without losing funct ions whose loss are catastroph ic.

b. If arc fault circuit breakers (AFCB) are utilized for IMA cabinet or rack circ uit protecti on, they should be specifically qualifi ed for use on aircraft. At the issue date of this AC, the use of AFCB technology in airborne systems is in its infancy. Therefore, unt il more experience is gained and updated regulatory and/or guidance material is issued for the certification ofAFCBs, the FAA may deve lop a metl1od of compliance Issue Paper for certification program s that use AFCB technology .

c. The 1MA cabinet or rack should not be powered wit h circuit protection features such as software controlled circ uit breakers that are controlled by microprocessors hosted in that IMA cabinet or rack. The intent of this guidance is to prevent the complete loss of control of the circuit protection feature( s) of any speci fie lMA cabinet or rack, or lMA components installed within that cabinet or rack, such that the electr ical power input cannot be remo ved to that cabinet or rack ifit fails.

d. The following app lies to part 25 transpor1 airplane s only.

( l) Electri cal wiring inte rconnection system (EWJS) components, as defined by § 25. 170 1, associated with lMA systems must comply with the applicable EWlS requirem ents of Part 25. See § 25. 170 I. Refer to Advi sory Circular 25.170 1-1. Certificatio11 ofElectrical Wiring interconnection Systems on Transport Catego,y Airplan es, for specific compliance guidance.

(2) We consider EW IS to be an airpl.ane system. Therefore, EWIS associated witb IMA systems required for type certification or by opera ting rules, including those specifically listed in § 25 . l 705(b) mus t be conside red as an integral part of thal IMA system and must be conside red in showi ng complian ce with the applicable requirements for that LMA system. See§ 25.l 705( b).

(3) Circuit protect ive devices for the IMA cabinet or rack must comply with the requ irements of§ 25.1357. See§ 25.1357. T hjs inc1udes § 25.1357(f) which requires IMA systems for which the abi lity to remove or reset power during nonnal operations i s necessary be designed so that circuit breakers are not the primary mean s to remove or reset syste m power unless speci fically designed for use as a switch.

7-2. Field Load able Software.

a. Many IMA systems use field loadab le softwa re (FLS) as part of the TC/STC/ATC /ASTC installation. FLS is softw are that can be loaded into the host hardwar e without removing the equipment from the aircraft instaJlution. FLS might also include software 24

### Page 30

10/28/10 AC20-l 70 loaded into a line replaceable unit (LRU) or hardw are component at a repair station or shop.

FLS can refer to either exec utable code or data, such as a database. When seeki ng approval to use FLS, you should cons ider the following:

(1) FLS should meet the objectives and guidan ce of RTCA/0 O- 178B or other acceptable means of compliance, as agreed to between the applicant and your responsible ACO.

(2) The FLS should be loaded on the target computer and hard ware configuration that the software was verified on during D0-17 8B on-target verifica tion testing.

(3) A means must exist to ensure that the FLS is loaded into the proper IMA configuration approved for that aircraft. See § 21.31. See Chapter 5 for more infonn ation on configurat ion management.

(4) lfredundant functions of the IMA sys tem are field loadable, the applicant should ensure that they have the same softw are configurat ion . unless intermixing of different softwa re confi&rurations is supported by the safety assessme nt and approved for the aircraft configuration and type design.

(5) The appli cant should have a process to assure that the softwar e loaded is the software approved and that it hasn't been com1ptcd - for example, verification with a cyclic redun dancy or other data transfer integrity check. Differen t data integrity algorithms give differen t assurances that the data transfer is correct. Ensure that the algorithm used is commensu rate with the integr ity requir ed for the softwar e level of the data being l.oaded.

(6) lf the applicant proposes more thai1 one medium for loading the FLS, such as a diskette , mass sto rage device or compact disc, loading from each m edium should comply witit the guidance in this sect ion.

(7) The applicant should demon strate that the airborne equipment software part numbers can be verified with onboard equipment, carry-on equipm ent, an automated configuration man agemen t scheme, or other appropriat e means.

(8) Loading protection mechanism s should be implemented to inhibit loading FLS during flight. The reliability of these mechanisms should be commensura te with the failure condition associated with the inadvertent loading of software durin g flight.

Note: Please refer to AC l20-76A, Guidelines.for the Certification, Airworthiness, and Operational Approl'Q/ ofElccLronic Flight Bag Computing Devices, fo r guidance that pertains to loadable IMA software compone nts that implement an Electronic Flight Bag fun ction.

b. FLS jnsta llati on documents should specify the following eleme nts:

(1) A ircraft and hardware app licabi lity and intenni xability allowances for redunda nt systems that load software.

### Page 31

(2) Verification procedures to ensure that the sotiware was correctly loaded into an approved, compatible target computer and memory device(s).

(3) Any post-load verification and/or test procedures required to show compliance to the guidelines specified in this AC.

(4) Actions to take -for example, prohibiting dispatch of aircrati- if there's an unsuccessful load.

(5) Reference to an approved loading procedure.

(6) Maintenance record entry procedures required to document and maintain configuration control.

(7) Reference to the appropriate Aircrati Flight Manual (AFM). Aircraft Flight Manual Supplement (AFMS) or operator's manual. if necessary.

7-3. Electronic Identification Guidance.

a. Identification of software components field-loaded into hardware elements should be implemented by electronic means. Electronic identification markings consist of identifying sotiware components by electronically embedding the identification within sotiwarc contained in the hardware. rather than on the equipment nameplate.

b. Electronic software part numbers and versions should be verifiable through an electronic query, such as an electronic display. Software part number configuration errors detected by an automated robust IMA configuration management function should be annunciated to the flight crew until appropriate maintenance action is performed.

e. Equipment authorized by TSO must be permanently and legibly marked with specific information. Sec§ 45.IS(b). The applicant can demonstrate compliance to§ 45.IS(b) when you provide the information required by an electronic identification query system stored in non­ volatile memory. This approach is commonly called an '"electronic TSO nameplate." The electronic identification system should be verifiable onboard the aircrati when the aircrati is on the ground at any geographic location. lt must provide the specific information for all applicable TSOs being marked is using the electronic TSO nameplate as the only means of labeling. See § 45.15(b).

d. Electronic identification may also provide softv;are and hardware component revision or modification status information and RTCA/DO-178B software level. The applicant can use this to demonstrate conformity to type design configuration.

e. Include information identifying the location of each hardware component in the electronic identification. This is necessary because the configuration depends on the specific location of each hardware component within the cabinet or rack. You can satisfy this 26

### Page 32

10/28/10 AC20-170 requirement when an automa ted configurati on management system scheme tracks and protects the IMA system configurat ion by ensuring hard ware components are prop erly located.

f. All hardware components that support functjons approved by a TSO should have a physical TSO nameplate. However , you may use electronic means instead of verify ing nameplates on each hardware com ponent, if aU required information is available electronically.

Electro nic identificatio n does not replace hardware and software conformity inspectio ns that determine the components are prod uced in conformity to type design.

g. Order 8150.1 (see the most current version) provides addit ional information on TSO part marki ng.

7-4. Aircraft System Lightning and HIRF Protection.

a. When you are showing compliance with aircraft lightning and HIRF protection regulation s, you must demonstrate that the functions performed by elec trical and electronic systems, whose failure cou ld prevent continued safe flight and landing, are not adversely affected when exposed to lightning and HIRF. See§§ 23. 1308, 25.1316, 25. 13 17, 27.1317, and

29. 131 7. The compliance demonstration for these systems should consider the performance of the integrated system, not only the equipme nt or modules that make up the system. To comply with this requirement to demonstrate no adverse effects on the functions performed by the system, lightning, and HlRF tests shou ld be perfom1ed with the IMA system in a test setup that represents the wiring, hardware, and software configurat ion that wi11 be installed on the aircraft.

These lightning and HIRF system test configuratio ns are typica11y more complex than those used for TSO compliance or equ ipm ent qualification. Guidance for compl iance is in AC 20-1 36A, Protection ofAircraft Electrical/Electronic Systems Agains t the lndirect Effects ofLightning, and AC 20-158, The CerNfication ofAircraft Electrical and Electronic Systems.for Operation in the High-Intensity Radiated Fields (HJRFJ Environment.

b. For systems that perfom1 functions whose failure wou ld significantly reduce the capabi lity of the aircraft or the abi lity of the flight crew to respo nd to an adverse operating condition, the compliance demonstrat ion may be based on lightnin g and HlRF tests performed on individual elements of equipme nt. RTCA/DO-l60F tests satisfy these rcqujrements.

c. Electromagnetic com patibility (EMC) between the IMA system and other aircraft systems shou ld be demonstrated when the IMA syste m is installed in the aircraft. RF emission tests, such as those in RTCA/ DO- I 60F, Section 2 l, should be performed on the IMA modules , equipment and systems to provide confidence that the [MA system does not produce unacceptable RF emjssions. However, the EMC demonstration to comp ly with regulations such as §§ 23.1431 ,

25.143 J, and 29. 1431 shou ld be perfom1ed with the IMA syste m and the othe r electrical and electronic systems installed on the aircraft.

7-5. lMA System Data Network. Many, if.not all, lM A sys tems will include a dedicated data network , such that the elements within an IMA system may comm unicate with each other without using the main aircraft or engine data network . This data network may be purely internal to an lMA cabinet or. for distributed IMA components, the data network may be 27

### Page 33

10/28/ l 0 required to span the length and breadth of the airframe in which the IMA is instal1ed. For data networks that are dedicated to or primarily for IMA sys tem data transmission and reception and are distributed in nature - that is, not purel y intemaJ to the rMA cabinets or modules - the applicant and IMA developer /system integrator should follow the guidance provided in AC 20­ 156, Aviation Darabus Assurance, or use another acceptable means.

### Page 34

Chapter 8 Use Of TSO Authorized Components In IMA Systems .

8-1. IMA Systems and TSOs .

a. IMA systems, depending on the specific aircraft or engin e application, may combine many functions that were historically in funchonaJly and physica lly separated systems. These IMA functions are made up of hardware and softwar e components, each of which may be authorized by TSO, either complete or incomplete. Additionally, hardware modules , cabinets, and racks that host the IMA hardware module s may also be authorized by TSO.

b. TSO authorizations are allowed under 14 CFR part 2 1, subpart 0. Your responsible ACO can explain how we evaluate and issue TSOAs and lette rs of TSO design approval (LODA) for aviation-re lated articles.

c. TSOs associated with lMA syste ms are:

(1) TSO-C153, which covers two types of hard ware used in lMA syste ms: generic hardw are modules and cabinets/racks that host hardware modu les.

(2) Functional TSOs. See paragraph 8-7 below and refer to Appendix G for examples of functional TSOs. You should keep in mind that this term is not normally used except in the context of IMA systems.

d. RTCNDO-297 does not specifically uddress TSO at1th01ized articles within an IMA system. This chapt er offe rs you a way to obta in approval for IMA systems that contain hardware and/or softw are components authori zed by TSO.

e. Due to the high integration, functi\mal TSO data packages for IMA systems are typica lly developed in parall el with the TC/STC/ATC/ASTC effort. In these cases , you sho uld not submit TSO data to the ACO for authorization until the TC/STC/ A TC/ ASTC testing for the IMA sys tem is com pleted and the final IMA syste m configuration is established. This will ensure thai- the IMA system meets all required TSO MPS. Alternati vely, comp liance data for TSO authorization and compliance data for the TC/STC/ A TC/ASTC maybe be submitted to the appropri ate FAA offices concurren tly, such that the TSO authorization may be issued concurrently with the aircraft/engine certifi cate. This alternative approach require s a high level of coordination between the responsible FAA offices to ensure that issue s that arise iD one area do not affect the other.

8-2. TSO-Cl53 Authorization for lMA Hardware Components.

a. To obtain TSO-Cl 53 auth01ization, the applican t for TSO authorization must demon strate that the individual hardwar e com ponent s meet the MPS and defined subs et of RTCNDO- l 60F environmental qualification requ irements in TSO-C 153, as described in Appendix A. See§ 2 I .616(c). TSO-Cl 53 does not prov ide either functional or insta11ation approval.

### Page 35

J0/28/ ) 0 AC 20- 170

b. The applicant for an LMA Component Acceptance Letter may use TSO-C 153 authorizalion as compliance data to obtain IMA component acceptance for IMA hard ware compone nts. See RTCA /DO-297, Table 4.

8~3. Functional TSO Author ization.

a. A functional TSO is a TSO with a defined aircraft functionality. For example, TSO­ C I 06 is for an air data computer. Other examples of functional TSOs are listed in Appendix G of this AC. TSO-C 153 is not considered a functional TSO because the hardw are element it addresses does not have system level functionality. A functional TSO authorization is issued for a specific IMA system configuration, including hardwar e and softwa re components, that performs the function defined in the functiona l TSO MPS. lt is not simply for the software component that is loaded into a TSO-C 153 authorize d h ardware clement.

b. If the IMA system provides all or part of the functionality required by the functional TSOs MPS and the company applying for functional TSO authorization also controls the design and quality of the complete lMA system, then that company may apply for functional TSO authorizations (eit her comple te or incomplete) for each aircraft function for which there is an applicable functional TSO . As noted above in 8-3(a), the TSO authori zation will apply to the JMA system and not a specific lMA component.

Note: Per§ 21.60 1 (b)(S}, the manufacturer of an article i s the ''person who controls the design and quality of the article produced . .. including the parts of them and any processes or services related to them that are procured from an outside source." For paragraph 8-3(b) to be app ljcable, the appli cant for a TSO authorization must control the design and quality of the parts, processes , and serv ices lhat are provided by any suppli er to that applicant for a TSO authorization. See§ 21.60l(b)(S).

c. If the company supplyi ng functional software that wilt be installed in an IMA system does not control the entire design and quality , per 8-3(b) above, ofthe article that provides the functionality defined in the functional TSO MPS, then that company may not apply for functional TSO authori zation.

d. It shou ld be noted that there will typically be multiple functional TSO authorizations that comprise the lMA syste m, and the lMA ~ystem will likely cont::iin functionality and features not addressed by any TSO. The overall functionality of the IMA system and the portions cove red by TSOA versus TC, STC, A TC, or ASTC should be carefu lly documented and coo rdinated with the FAA.

8-4. EQT of lMA Components with TSO Authorization.

a. There will be three different stages at which TSO authorized IMA components and the IMA system in which the se components are insta lled need to comply with EQT requirements:

### Page 36

10/28/ 10 AC 20-170 (I) TSO-Cl 53. This TSO contajns EQT MPS for IMA hardware modules that qualify for TSO-Cl53 authorization. Comply with these requirement s lo obtain TS0-C153 authorization for the generic IMA hardwar e.

(2) Functional TSO MPS. Each individual functional TSO (see Appendix G for examples) MPS normally include EQT requirements. Comply with these requirements to obtain the individual functional TSO authorization(s).

(3) Aircraft or engine installation EQT requirements. EQT procedur es and test configurations are based on the specific aircraft or engine installation of the complete IMA system. Compliance to the aircraft or engine level installation EQT requirements may be completed under the aircraft/engine certification program independent of the TSO authorizations.

Alternatively, certification credit at the aircraft or engine installation level may be taken from the TSO authorizations, if applicable at the insta llation level.

b. TSO-Cl53 was written specifically to address how partial EQT compliance at the aircraft or engine installation level can take credit from the EQT compliance from TSO-Cl53 authorization. EQT procedures that requir e tJ1e test to be mn on the specific IMA system configuration ash will be installed on the aircraft or engine should be accomplished during the aircraft or engine TC/ATC/STC/ ASTC program . TSO-C 153 and Appendi x A of this AC address how this can be done.

c. Compliance to the EQT MPS for the individual functional TSO MPS is still required, even with TSO-Cl53 authorization of the hardwa re components which host that function.

d. An applicant for an IMA Compone nt Acceptance Leiter may use the EQT comp liance data from a TSO authorization to use as compliance data for lhe IMA Component Acceptance Letter process addressed in Chapter 3 of this AC. The IMA Component Acceptance Cover Letter and the accompanying IMA Component Acceptance Letter data sheet should include which EQT are being accep ted, including a statement of ful I or partial comp] iance and a matrix or table of al I EQT procedure testing levels accomplished .

8-5. JMA Component TSO Part Marking.

a. Tf loadable software compone nts are used with generic hardware modu les authorized under TSO-Cl 53 to implement a functional TSO, an applicant for functional TSO authorization should identify the loadable software - both the electronic identification and the physical or electronic media containing the loadable functional software - with the functional TSO identification.

b. The generic hardware componen ts autho rized by TSO-C 153 must be permanently marked as being authorized under that TSO, in addition to any electro nic identification. See § 21.607(d).

c. See paragraph 7-3 for electronic identification guidance.

### Page 37

8-6. Integration of TSO Authorized Components in IMA Systems .

a. The applicant should demonstrate that all RTCA /OO-297 objectives required to obtain Acceptance of the IMA modules, applications. system, and installation into the aircraft or engine have been met. This is true regardless whether any of the modules or applications are also part of a TSO authorized article as described above in paragraph 8-3. The TSO authorization for the IMA function may be used, if relevant. in showing that you met RTCA/DO-297 objectives. The presence of a TSO authorization in no way removes or redu ces your responsibilities as an applicant, which is to ensure that the installed [M A syste m - including any TSO authorized components - meets the appropriate aircraft nnd engiue regulations and the guidance in this AC.

b. functional TSOs, such as TSO- C 113. Airbome Mulapmpose Electronic Displays, do not normally cover integration with other aircraft functi ons or hardware /so ftware components in the integrated rMA syste m. Each TSO MPS is normally written assuming thal it is a stand-a lone function and that no integration requirements exist beyond integration into the aircraft . For this reason ~ additional work is likely to be requ ired beyond the TSO authorizations when showing compliance at the 1ntegrated IMA system level. Please refer to RTCNDO-297 , subsection 4.4.

c. The installation instructions for TSO authorized lMA components should include all information necessary for the applicant and/or the IMA developer /syste m integrator to fully integrated the TSO authorized lMA compo nent into the fMA system.

8-7. Aircraft InstaUation Approval of IMA Systems Including TSO Authorized Components.

a. The applicant must demonstrate that the installed CMA sys tem configuration - including both hardware and software components - and perfonnancc meet s the appropriate aircraft and engine certification basis . See § 2 1.20. This demonsu·ation should include functiona l perfonnance , interoperability, aircraft-leve l and system-leve l safety assessments, environmenta l qualifi cation, sys tem integration test, flight-tes t, software and hardwar e assurance, etc., as required to show com pliance to the regulations.

b. The applicant may use TSO authorizations to support airworthiness assessment if you show tbat the TSO requirements app ly to the installation into the aircraft or engine. Any change to the bardware or software configuration of an IMA component must be controlled at both the TSO and the aircraft installation level. See §§ 21.3 1and 21.61 I.

8-8. Role s and Responsibilities When TSO Authorized Components Are Used in IMA Systems.

This section identifies the major roles and responsibi lities for the TSO-Cl 53 app licant, the functional TSO applicant, and the aircraft /engin e app licant when TSO authorized components are used . These lists are not all-inclu sive. We enco ura ge all affected partie s to coordinate with us throughout the entire IMA system development. See Appendix A for more guidance applicable to TSO-Cl 53 authorization.

### Page 38

a. TSO-Cl 53 Applicant Roles and Responsibilities:

( l) Apply for TSO-Cl 53. If you arc a manufacturer of a TSO article, due to the complexity of lMA projects , we recommend that you coordinate with us early in the program .

(2) Build an MPS for the hardwar e element according to TSO-C153. Ensure that you document all the appropriate items in TSO-Cl53, Appendix I and that we approved them.

(3) Develop and implement part identification and configuration management functionality into hardware elements. The configuration management and part identification approach should follow chapter 5 and paragraphs 7-3 and 8-5 of this AC.

(4) Coordinate with the applicant and/or IMA developer/system integrator who will be integrating and installing lhe 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-C' 153 and the MPS.

(6) Perfunn the tests necessary to demonstrate comp liance with the TSO-Cl 53 and the MPS. See paragraph 8-4 and appendix A of this AC. lfspecial purpose test softw are is used for EQT, validate and control the configuration of the hardware elements and software components to ensure the validity of the testing .

(7) Submit the data package (the inform ation in TSO-CI 53 paragraph 5, includin g the MPS) to your responsible ACO for review and issue of TSO authori zation.

(8) Apply for changes to TSO-C153 elements as design chang es occur, Notify TC, ATC, STC, and ASTC holders and functional TSO holders, if any, of the design change.

b. Functional TSO Applica nt Roles and Responsibilities.

( 1) Apply for functional TSO to your responsible ACO.

(2) Design the system accordi ng to the appropriate TSO MPS .

(3) Identify the usage domain in wluch the TSO author ized IMA compo nent was shown to meet the TSO MPS. lf the envfronment in which the compo nent verification was conducted is not exact ly the same as the usage domain of the comp leted IMA system, then you should perfonn analysis and/or testing to demon strate those differences do not affect the use of the IMA component witl1in the intended usage domain.

(4) Identify and address all integration and-approval issues with the LMA hardware component that will host the functional TSO softwa re. Coordinate these issues with the applicant and/or the IMA developer/system integrator (if different than the functionaJ TSO applicant).

### Page 39

l 0/28/10 AC 20-170

(5) Develop mapping between the TSO requirements and the IMA system implementation - for example, a mapping matrix. Mapping should identify TSO requirement s that are fully met, partiall y met, or not met at all. This include s any partial compliance to RTCA/DO-178B for software, RTCNDO- 254 for CEH, and RTCA/DO- l60F for EQT.

(6) Identify any limitations regarding the use of the lMA component in an IMA system.

(7) Refer to FAA Order 8150.1, Technical Srandard Order Program , as needed to understand the FAA policy regarding TSO authorized article s. You should contact your respon sible ACO if you have any question s you cannot answer.

(8) Identify functions in the IMA system not addressed by the TSO. Any functionality not specifically addressed by the functional TSO MPS may require deviation s. This additiona l functionalit y may be classifie d as a "non-TSO function", or it may be small enough in nature or closely related to the functional TSO, such that the applicant for a functional TSO classifies it as a "featu re." Both non-TSO functions and features should be documented and addressed.

(9) Perform tests to demonstrate compliance to the functional TSO or functional performance standard s. Some required EQT may not have been accomplished during TSO-CJ 53 authorization. You should demonstrate that all testing, including EQTs required for the functional TSO, has been accomplished. If spec ial purpose test software is used for environmental qualification, you shou ld verify and control the configuration of the software to ensure the validity of the testing. Credit may be applied for EQT conducted for the TSO-Cl 53 authorization, if appropriate. See paragraph 8-4 for more information .

( l 0) Submit the data package required by the functional TSO to the responsible ACO for review and issuance of the TSO authorization. Include installation data and configuration of the functional TSO as part of the data package. See paragraph 8-3 for more infonnation .

{I I) App ly for changes to functional TSOs, as design changes occur. Notify TC, STC, ATC, and ASTC holder s of the design change .

c. Applicant Roles and Responsibilities.

(I) Develop and submit a Project-Specifi c Certification Plan (PSCP) for the fMA system to the responsible ACO for approval.

(a) We recommend that you include a detailed confonnity plan covering all hardware and software components' conformi ty and installation conformity inspections (including the plan for addressing any "red label" units).

(b) The PSCP should clear ly identify what functions will and will not be approved through the TSOA process . This is necessary to identify what will be TSO authorized and what will be TC/STC/ATC/ASTC approved.

### Page 40

J0/28/1 0 AC 20-170

(c) The PSCP should address integration and approval of all components of the IMA system (including all hardware elements and software components).

(2) Define aircraft system and performance requirements.

(3) Perfom, aircraft-level safety assessme nt per RTCA/D0-297, subsection 5.1 and submit it to your ACO.

(4) lntegrate all hardware elements and software components in the IMA system. This task may be accomp lished by the 1MA developer /system integrator.

(5) Integrate the JM A system into the aircraft or engine.

(6) Ensure that no TSO assumptions are violated in the installation. For example. ensure that relocating the GPS card does not invalidate the environmental qualification credit for the GPS TSO. (See chapter 8 of this AC.)

(7) Deve lop field-loading procedures to ensure that proper software is loaded on the aircraft. (See paragraphs 5-4 and 7-2 of this AC.)

(8) Verify software and complex electronic hardware issues were properly addressed for the installation. (See RTCA/D0-297 , Sections 3. 4, and subsection 5.2.)

(9) Determine appropriate aircraft environmental conditions and ensure that EQTs were performed. (See RTCND0-297, subsectio n 5.2.6.)

(10) Develop all required test plans (see RTCA/D0-297. Section 4) and perform necessary tests.

(11) Develop a plan for addressing human factors issues (see RTCA/D0-297, subsection

3.10) ahd perform human factors and flight crew evaluations of the IMA system .

(12) Ensure that the IMA systen1 meets all airworthiness requirements.

{13) Submit the functional hazard analyses. safety assessments, hardware design assurance data, software data, test plans, test results, compliance reports , and all other appropriate certification data to the FAA for approval. The preliminary functional hazard analysis and preliminary system safety analysis sho uld be submitted before finalizing the software, CEH, and SEH levels and the IMA architecture.

(14) Maintain aircraft system configuration management. (See RTCA/D0-297.

subsec tion 3. 7 and paragraph 5-1 of this AC.)

### Page 41

L0/28/ 10 AC 20-170

(15) Evaluate and document changes lo IMA system and elements per§ 21.93. (See RTCA/D0- 297, subsection 4.6.)

( 16) Ensure that aircraft design featu res address safoty (See RTCA/D0 -297, subsection

3.3.)

### Page 42

------ I0/20/ LO Appendix A Appendix A Environmental Qualification Guidance for TSO-C153.

1. T 0-Cl 53 Appendix I Ii t environm ntal qualification test (EQT) to atisfy the TSO minimum performance tandard. Perfonn th• e EQT · ac ording to procedure and category levels in RTCA/DO-l 60F. Select the category levels tested appropriate ti r the aircraft installation and environment. The EQTs hould apply to functional TSO environmenta l qualification and may be applied to the aircraft TC, STC , ATC or ASTC envir nment qualification .

2. Tabl 1-1 below li t the RTCAID0-16 Fen ironmental tests that can be accomplished under TSO-Cl 53 authorization. and how they may affect funct ional TSO authorization.

Table 1-1. RT A/DO-160F Environmental Qualification Requirements.

RTCA/ DO-160 Section # 4 4 5 >---­ 6 7 7 l O 1 l 12 13 RTC /DO-l60F Section Title Temperature and Altitude ­ Temperature Temperature and Altitude ­ Altitude Temperature Variati n Humidity perational Shock and Crash afety - Operati nal Shock Operational Sh Safety - Crash plosion-pro fne Waterproofness Fluid Susceptibility and and Dust Fungus Resi tance Required for Required for TSO-Cl53 Functional TSO Nol tested Yes Ye Not tested Yes t tested Yes T 0- 153 quali ficati n data may be u ed by imilarity Yes Yes, TSO-C 1 5 qualificati n data may be u ed b similarity Yes y . Yes, TSO-C 153 qualification data may be u ed by similarity Yes Ye if appropriate Yes, TSO-Cl 53 qualification data may be u ed by similarity Yes, if appropriate Yes, TSO­ 153 qualification data may be u cd by similarity Ye if appropriate es TSO-Cl53 qualification data may be u ed by imilarity Yes, if appropri a le Yes, TSO- Cl 53 qualification data may be u ed by similarity Yes if appropriat Yes TSO-Cl53 qualification data may be u ed by similarity A-1

### Page 43

10/20/ l0 Appendix A RTCA / DO-160F RTCA/DO-160F Section Section itle # ]4 Salt Spray Required for TSO-C153 Ye . if appropriate Required for Functional TSO - Yes, TSO-Cl 53 qualification data may be used by similarity 15 Magnetic Effect Yes

- - Yes, TSO-Cl 53 qualification data may be used by similarity 16 Power Input Nolte ted Yes - 17 V ltage Spike Ye Yes TSO­ 153 qualification data may be u ed by similarity - 18 Audio Susceptibility - Power [nputs Ye Yes, TSO- data may b 153 qualification u ed by similarity 19 Induced Signal Su ceptibility Notte ted Yes - 20 Radio Frequenc y usceptibility N t tested Yes 21 Emissio ns of Radio Frequency Energy Not tested Yes ._ 22 Lightning Indu ed Transient Su ceptibility Not tested Yes 23 Lightning Direc Effects Not tested Yes 24 Icing Ys Yes, TSO-Cl 53 qualification data may be used by similarity 25 Electrostatic Di harge Ye Yes TSO-C153 qualification

- - ~ata may be u ed by similarity -1 Note: RT A/DO-160Fl S ctions 20 and 22 may require additional te ting at aircraft in talla:tion.

3. Certain EQTs cannot e appropriately I erformed on th hardware element s part of TS ­ Cl53 . These EQTs can only be appropriate! pe1fonned when the IMA sy t m and hardware element ar arranged in the configuration spec ified for lhe applicable aircraft, as defined for the aircraft TC. STC, ATC, or ASTC. Also, lhe e EQ can nly be appropriately performed with the functional software in talled and operating. Therefore certain RTCNDO-160F EQTs are exclude from TSO-Cl53. You should addre s these EQ s as part of the functional T 0 compliance or a part f the TC/STC /ATC /ASTC environmental qualification. These te ts arc de crib d below:

a. EQT for temperature (RTCNDO-l 60F, Section 4) and temperature variation (RTCA/DO­ 160F ection 5), Perfonn these with the cabinet or rack and modules in the hardware configuration intended for the functional T O authorization r the TC/STC/ATC /ASTC approval. For temperature and temperature arialion tests ti r the functional T O or A-2

### Page 44

10/20/ 10 Appendix A TC/STC/ ATC/ ASTC, the hardware module urra11gement should represent the expected worst­ case temperatur e conditions. Alternately, applicants for the functional TSO or for aircraft/engine certification may perform engine ering analysis, using validated models, of the thermal characteristics of the expecte d cabinet or rack and module configuratio n variatio ns to determin e temperature test param eters that exceed the worst-case expected temperature conditions. These temperature test paramet ers could be used instead of the standard RTCA/DO-160F , Sections 4 and 5, temperature conditions.

b. EQT for operationa l shock (RTCA /DO-160F , Section 7) and vibration (RTCA/DO-160F, Section 8). Perform these with all cabinet/rack module posi tions occupied in the hardwar e con.figuration specified for the functional TSO or TC/STC/ ATC/ ASTC installation. Alternately , you could perform an engineering analysis, using validated models , of the characteristic s of the expected cabinet or rack and module con.figuration s to determine vibration and operational shock test param eters that exceed the worst expected conditions . These test parameter s could be use-d instead of the standard RTCA/DO-l60F , Sections 7 and 8 conJiti ons.

c. EQT for induced transients {RTCA/DO-160F, Section 19), radio frequency {RF) susceptibilit y (RTCA/D O-160F , Section 20), RF emissions (RTCA/ DO-160F, Section 21 ), and lightni ng induced tran sients (RTCA /DO-160P, Section 22). These are most appropr iately perform ed with the functional hardware and software in the IMA system. This is becau se the response of the system may be highly dependen t on the functional softwa re and hardware .

Therefore , perform these EQTs as part of the functional TSO comp liance or as part of the TC/STC/ATC/ASTC environmental qualifi cation.

d. EQT for lightning and HlRF protection . Perfom1 these with the hardw are elements and softwa re components loaded in the configuration specified for the applicable aircraft, per the lightn ing regulations, ACs, and the HIRF policy. The interface wiring and connected equipment should represent the wiring and connected equipment installed in the aircraft.

4. You may use EQT performed for a single functional TSO authorization or aircraft TC/STC/ATC/ASTC to support other applications for functional TSOs or aircraft TC/STC/ ATC/ ASTCs with similar configurations . A TSO applicant may use similarity assessment and worst-case test conditions Lo minimize the EQT required for subsequent functional TSO applicatio ns or aircraft TC/STC/A TC/ ASTC. Your use of the environmental qualification data should be accom panied by a rational engineeri ng analysis of the difference s between hardware and softwa re configu ration used during the origina l environmental tests a11d the proposed new configuration. The engineeri ng analysis may consider worst-case environmental limit s developed above.

5. The functional TSO qualificatio n data sheet should state explicitly the RTCA/DO -l 60F test categorie s and tests performed in the functional TSO configuration and the test categories and tests perfom1ed in the TSO-C l 53 configuration . Includ e this information in the install ation instructions.

A-3

### Page 45

10/20/10 Appendix A

6. Hardware modules and software components providing a function that lacks an applicable functional TSO must meet the TC/STC/ATC/ ASTC environmental requirements. See § 2 1.3 1.

7. You must evaluate all hardware elements before installation lo ensure that the TC/STC/ A TC/ASTC environmenta l requireme nts have bee n sat isfied. See § 21.31.

A-4

### Page 46

10/20/ 10 ppendi B Appendix B Sample IMA Component Acceptance Cover Letter.

Use the fi II wing a a guide for an IMA C mponent Acceptan Cover Letter. The format given h re does not need to be followed pre isely. It is imp rtant however that all the information be present, in ome form in the letter.

Page l ofx AME COMP

OMPA NY CONTA CT INFORMATION D ate f appl ication Unique identifier ]MA omponent Acceptance Cover LeUer General lnformation lMA comp nent name:

Y ADDR E TMA componen t top level identification: (Must uniquely identify the componenz, including anv revision or modificatio n level. ) ame and c ntact information of company that develope the IMA component different than the applicant for the IMA mponent Ac· ptance Letter):

Contact in ormation: (List the name(s) o[engin eri11g and/or mana gerial 1aff'to 1,vlzich the FAA and other companies involved in the u c a11d po sible {1.1t11r reu e o[Lhis component may corr espond. Include the person ·s posilio11 or title within th company, telephone number and, ii po sibl e, a stable e-mail addre .)

FAA office to which the ap plicat ion for lM ompo nent acceptance is being made:

Aircraft r engine erti-ficati n program in which TMA comp nent will b u. ed or initial acceptance including targ t ertification date:

Name and identification of [MA system in whic h the IMA c mpo nent will be used for initial acceptance:--------- ----------------------­ B-1

### Page 47

10/20/1 0 Appendix B Name and address of IMA system developer/ integrator (if different than the lMA componen t developer making this application): _____________________ _ Information Regarding Initial Use of IMA component Describe the airborne system and environment in which the JMA component will be operating, also referred lo as tile "usage domain. " This i1lormation may l'ary widely based on the type of component. b!(ormation about hardwar e compon ents. such as their being install ed in a rotor cra/t or in an unpressuri zed location ofthe aircrafi structure, will be different than ifthe component is a software operating system. For hardware components. this description should be adequate to estimate the environmelllal qualification testing levels.for RTCA IDO-160F complianc e for the initial installation.

Tllis section informs the FAA, as well as any potemial.future re-users ofthe accepted component, how the IMA component is being usedjor ils initial acceptance and what might need to be re­ examined during any future reuse.

information may be at a high level, with more detailed i1?formation contained in the IMA Component Acceplance Leite r data sheet.

lnformation Regarding Partitions (if any) and Assurance Levels within the IMA Component Describe all the various soft ware partiJiu11s (ifany) within the !MA compon ent. Identify the so.ftt-vare assurance level fo r each so.ftHw·e partition s. Justify at a high level why that assurance level is appropriat e. With hard ware compon ents.for which you are seeki ng acceptancefor compliance to RTCAIDO-254 , ident!/y u.nd describe each component along with the design assurance level (DAL) ofeach component and a justifi cation ofwhy this DAL is appropriate. If there are multipl e DALs 0 11 u single CEHISEH device, then addr ess each ofthose DALs. Include il!fonnalion regarding the separation ofthe multipl e DALs on a single device .

This section informs the FAA. as well as any potential.future re-users ofthe accepted component, ofthe various assura nce levels (both hardwar e and soflll'are) wit/,;11 the £MA component and what might need to be re-examined during any f uture reuse.

information may be at a high level, with more de/ailed informalion contained in the IMA Component Acceptance Letter data sheel.

Statement of Full or Partial Complianc e to Industry Standards State for which indust, y standards RTCAIDO-1788.for airborn e software, RTCAIDO-254.for CEH, RTCA IDO- 160F for EQT) acceptan ce is being sought H•ith this IMA component. State whether you seek full or partial complian ce to these ~fandards. Your IMA Component Accepta nce Cover Letter does not need to explain. in detail. any partial compliance to Lhese sta ndards--inc/ud e that detailed informatio11 in t.he IMA cmnpon ent acceptance data sheet. The statement of/LIii or partial compliance in the IMA Component Acceprance Cover Lette r is on(v 8-2

### Page 48

10/20/10 Appendix B an indicator to the FAA and any future re-user ofthis componenL that additional activity is needed to show full comp liance at the time ofinstallation approval ofthe IMA system.

lfyou seek any compliance.for SEHfor the /MA component acceptance. this section should document that fact. Include the compliance data or refer e11ces to wher e the complianc e data may be found in the /MA compo nent acceptance data sheer.

ffyou seek compliance to any other tec/,nical discipline, besides t/zose listed abov e with i/zis IMA compone nt acceptance . document it here. Include a high-level discussion ofthe requirements for which you seek compliance, and where rlze de/ailed requir ements are docum ented. Include more detailed i1?formation about the complian ce dala in the IMA Component Acceptance Letter dala shee t.

Configuration Information of IMA component Include eno ugh if!formation to specf/y exactly the baseline configuration ofthe IMA component being accepted, including the development and verification environment. Include only a list of the documents names, numbers and revisio n levels. All other i,!(ormation concerning the configuration identification may be included in the IMA Component Acceptan ce Letter data sheet.

This section makes clear the configuratfon ofthe IMA compo nent being accepted , Ifany oftlze docume111s identified in this secti on are revised, then write a new !MA component acceptance letter .

Statement of compliance to the applicable requirement s Stare in the IMA Component Acceptance lette r that t/ze signatories al/est that the /MA component meets all the applicable requirements defined in th<! IMA Component Accep1ance Letter. A sample statemenr is shown beloll':

We, the undersigned, attest that we. lo the best of our abilit y, have found this IMA compone nt to be comp liant with the applicable requ irements as documented within this IMA Component Acceptance Letter.

Signatures - AppHca-nt for the IMA Component Acceptanc e Letter This seclivn should show the signatur es ofspecific compa ny individuals. per paragraph 4-3 of this AC. There should also be a print ed versio n ofthe signi ng individual's name and title. Each signatur e should include 1he date on which they signed the lMA Component Acceprance Cove r Letter, as well as an indication ofwhich technical disciplin e to which that signatur e appli es. The IMA component acceptance letter should be signed by the appropriate p ersons before submitting the original, along with the IMA Component Acceptance letter data sheet, to the FAA.

B-3

### Page 49

0 l 0/20/10 Appendix C Appendix C Sample Acceptance Letter .

Issuing FAA office Issuing FAA office address Issuing FAA office address U.S. Deportment of Transportation Federal Aviation Administration 1n Reply Refer To: (FAA correspondence number) (Date ofLetter) (Name and address ofrecipient) Subjec t: Integrated Modu lar Avio nics (lMA) Compo nent Acce ptance Letter (unique idenL{fier Ji·om company's application for an IMA Component Acceptance Cover Letter) The FAA has detennined that (company name) complies with AC 20-170 and RTCA/DO-297 , Integrated Modular Avionics (IMA) Development Guidance and Certffication Considerations.

with regards to (IMA component name), (}MA co111po11e11t top level identification , including revision level), for the purposes of IMA component acceptance.

The following tenns and conditions are appl icable to this IMA Component Acceptance Letter:

1. This acceptance is based on the usage domain , restric tions, partial compliance, assurance levels and other such informa tion as documen ted in the attached IMA Component Acceptance Cover Letter and its IMA Component Acceptance Letter data sheet.

2. This IMA Component Acceptance Letter is only applicab le to (]MA component name and top level identification . including revision /evC'/). This Acceptance Letter is not transferable to an updated version of (!MA component name). A new FAA IMA Component Acceptance Letter should be requested for the updated component, ifone is desired.

3. (Company name) should report to the (FAA office issuing this IMA Component Acceptance Letter) any failure, malfunction, defect of the component or finding of any non-compliance or deviation from the compliance statements made in the attached IMA component acceptance letter. The FAA may choose lo cancel this IMA Component Acceptance Letter if warranted, which will have the effect of requiring (company name) to update (IMA component name) to address the shortcoming before a new IMA Component Acceptance Lette r can be issued.

C-1

### Page 50

I 0/20/ 10 Appendix C

4. (Company name) should coordinate with and supply any required data to any future or concurrent user of the accepted LMA component, such lhat the user is able to show full compliance to AC 20-170 and RTCND0-297 for that future or concurrent use.

The holder of a vaJid FAA !MA Component Acceptnncc Letter may use it as proof of acceptance by the FAA, as defined in the LMA Component Acceptance Letter including the TMA component acceptance data sheet, for the purpose of future or concurrent use of the accepted IMA component. The actual compliance data used in obtaining the IMA Component Acceptance Letter does not need to be re-submitted to the FAA, unless the FAA has concerns that cannot be answered by any other means except by re-examining the original IMA component acceptance data.

(signature) (printed FAA signato,y ) cc: (as appropriate) Attachment: (Copy ofthe lMA Component Acceptance Cover Letter. Do not include the IMA Component Acceptance Let/er data sheet.)

C-2

### Page 51

11/21/2013 Appendix D Appendix D Related Documents And How To Get Them.

1. Copies of 14 CFR parts are available from the Superintendent of Documents, Government Printing Office, P.O. Box 979050, St. Louis MO 63197. Telephone (202) 512-1800. fax (202) 512-2250. You can also order copies online at www.acccs~.!lpo.gov. Select --Online Bookstore:· ·1bcn select ··Code of Federal Regulations."

2. The following ACs are available from the FAA website at http://www.faa.gov/rcgulations_policics/advisory _circulars/.

1) AC 20-88, Guidelines on the Marking ofAircrafi Powerplant Instruments (Displays).

2) AC 20-115, RTC"A. Inc. Document RTCAIDO-178B.

3) AC 20-136A, Protection ofAircrqft Electrical/Electronic Systems Against the Indirecl Effects c!fLightning.

4) AC 20-148. Reusable Software Components.

5) AC 20-152, RTCA. Inc. Document RTC"A/DO-254, Design Assurance Guidance for Airborne Electronic Hardware.

6) AC 20-156. Aviation Datahus Assurance.

7) AC 20-158, The Certification ofAircrqfi Electrical and Electronic Systemsfi1r Operation in the High-Intensity Radiated Fie/cl\· (If/RF) Environment.

8) AC 20-174, Development o_[Civil Aircrqfi and Systems.

9) AC 21-16, RTCA. Inc. Documenl RTCAIDO-160F.

10) AC 23.1309-1, System Sqfe1y Analysis and Assessment for Part 23 Airplanes.

11) AC 23.13 I 1-18, Installation ofElectronic Displays in Par/ 23 Airplanes.

12) AC 25-1 lA Electronic F!ighr Deck Displays.

13) AC 25.1309-l. System Design and Analysis.

15) AC 25.1701-1, Certification ofElectrical WirinK Interconnection Systems on Transport Category Airplanes.

15) AC 27-l. Cert/fication o/Norma/ Category Rolorcrafi.

16) AC 29-2. ( 'ert/fication of'Ii'tm.17,ort Category Rotorcraft.

D-1

### Page 52

11/21/2013 Appendix D

17) AC 33.28-1, Compliance Criterici For l 4 CFR § 33.28, Aircrqfi Engines. Electrical And Electronic Engine Control Systems.

18) AC 33.28-2, Guidance Material For N CFR § 33.28. Reciprocating Engines, Electrical and Electronic Engine Control Systems.

19) AC 33.75-l, Guidance Ma1erialfor 14 CFR 33. 75, Sqfely Analysis.

20) AC 120-64. Operational Use and Modification ofElectronic Checklists.

21) AC 120-76A, Guidelines.for the Certification, Airworthiness. and Operational Approval ofElectronic Flight Bag Compuling Devices.

3. The following FAA policy statements are available from the FAA website at http:1/www.faa.gov/rc£uhttions policies.

I) FAA Policy Memo ANM-01-03, Factors to Consider When Reviewing an Applicant's Proposed Human Factors Methods ofCompliance.for Flight Deck Cert/fication.

2) FAA Policy Memo ANM-99-2, Guidance for Reviewing Certification Pluns To Address Human Factors/or CenificCttion a/Transport Airplane Flight Decks.

3) FAA Policy Memo PS-ACE I00-2001-004, Guidance/or Rei-iewing Cert/ficmion Plans to Address lluman Factors/or Certification ofPart 23 Airplanes.

4. Order RTCA documents from RTCA. Inc .. 1150 18th Street NW, Suite 910, Washington, D.C. 20036. You can also order copies online at www.rtca.org. We referenced the following RTCA documents:

I) RTCND0-!60F. Em·ironmenlal Conditions and Test Procedures for Airborne Equipment.

2) RTCA/D0-1788, Software Considerations in Airborne Systems and Equipment Certification.

3) RTCA/D0-254. Design Assurance Guidance for Airborne Electronic HardwCtre.

4) RTCA/D0-257 A, Afinimum Performance Standardsfiir the Depiction ofNavigational J1!f'ormation on Electronic Maps.

5) RTCA/D0-297. Integrated Modular Avionics (/MA) Development Guidance and Cert/fication Considerations.

D-2

### Page 53

11/21/2013 Appendix D

5. Order SAE documents from SAE International. 400 Commonwealth Drive. Warrendale, PA 15096-0001. You can also order copies on-line at WW\\.sae.org. We referenced the following SAE documents:

1) ARP4754 Rev A. Guidelines.for Development ofCivil Aircraft and Systems.

2) ARP476 I, Guidelines and Methodffor Conducting the Sq(ely Assessment Process on Civil Airborne Systems and Equipmenf.

D-3

### Page 54

I 0/20/ 10 Appendix E Acceptance Aircraft function Airworthiness Applicant Application Application-speci fie hardware Approval A ssumptions Assurance Authority Baseline Appendix E Glossary FAA acknowledgement that the module, application, or system meets defined requiremen ts.

Capability of the aircraft prov ided by the hardware and software of the syste ms on the aircraft .

Condition of an item (aircraft, aircraft system, or part) in which that item operates in a safe manner to accomplish its intended function .

Person or organization seeking approval from the FAA.

Software and/or application-specific hardware with a defined set of interfaces that, when integrated with a platfonn(s), perfonns a function .

Hardware dedicated lo one application.

Act or instance of giv ing fom1al or official acknowledgement of compl iance with regu latio ns.

Statements, principles, and/or premises offered without proof .

Planned and systemat ic act ions necessary to provide adequate confidence and evide nce that a product or process satisfies given requirements.

Organization or person responsible withfo the state (com1try) concerned wiU1 applicable requireme nts. Aircraft, engine, or propeller type certificatio n or equipment approval is nonnally handled by the certification authority. Matters concerning continuing airworthines s might be handled by (whaf s referred to as) the airworthiness authority.

Approved, recorded config uration of one or more configuration items, that serves as the basis for further development. Baseline is changed only through change controt procedures.

E-1

### Page 55

10/20/ 10 Cabinet Certification Certification credit Closed architecture Complexity Complex electronic hardware Complex hardware item Compliance Component Computer Configuration control Configuration identification Appendix E Physical package containing one or more IMA components or modules.

Provides partial protection from environmental effects (shielding).

May enable installation and removal of those component(s) or module(s) from the aircraft without physically altering other aircraft systems or equipment.

Legal recognition by the FAA that a product, service, organization, or person complies with the requirements. Certification comprises the activity of technica lly checking the product, service, organization, or person and the formal recognition of compliance with the applicable requirements by issuing a certificate, license, approval, or other documents as required by national laws and procedures. In particular, product certification involves: (a) assessing the product design to ensure that it compl ies with standa rds applying to that type of product to demonstrate an acceptable level of safety, (b) assessing an individual product to ensure that il conforms with the certified type design , and (c) issuing a certificate required by national laws to declare that compliance or conformity was found with standards according to items

(a) or (b) above .

Acceptance by the FAA that a process , product, or demonstration satisfies a certification requirement.

System whose technical specifications are not made public. Such systems restrict third parties from building product s that interface with or add enhancements to them.

Attribute of systems or items that makes their design and/or operation difficult to comprehend.

A subset of a complex hardware item; a custom micro-coded component that is not considered to be simple. (See "simple electronic hardware.") Any hardware item nol considered to be simple. (See "simple hardware item.") Successful perfom1ance of all mandatory activities; agreement between the expected or specified result, and the actual result.

Self-contained hardware or software part, database , or combination thereof that is configuration controlled.

Device or group of devices that perfonns a data processing function.

See "change control.'' Process of designating the configuration items in a system and recording their characteristics.

E-2

### Page 56

10/20/ 10 Configuration index Configuration item Conftgurati on management Criticality Custom micro-coded component Domain Feature (of an article authorized by TSO) Federated system Function Functional software Functional TSO Appendix E Approved documentation that defines a configuration item.

I) One or more hardware or software components treated as a unit for configuration management purposes.

2) Software life cycle data treated as a unit for configuration management purposes.

Discipline applying technical and administrative direction and surveillance to (a) identify and record the functional and physical characteristics of a configuration item, (b) control changes to those characteristics, and ( c) record and report change control processing and implementation status.

Indication of th~ hazard level of a funcLion, hardware, software, (and so forth), addressing abnormal behavior of this item alone, or with external events.

Component that includes application specific integrated circuits (ASIC), programmable logic devices (PLO), field programmable gate arrays (FPGA) and other similar electronic components used in the design of aircraft systems and equipment.

Grouping items into areas that share a common interest or characteristics.

An aircraft or engine function that is not identified in a functional TSO minimum performance specification. However, Lhal Cealure is related to the functionality provided by a function provided by an article authorized by a functional TSO. The feature is also smaller than a complete function (see "non-TSO function), such that the feature can be included in tbc article authorized by the functional TSO, even though the functional TSO MPS does not specifically mention that functionality. Features are not approved by the functional TSO authorization. They should be approved during the aircraft or engine certification program.

Aircraft equipment architecture consisting ofprimarily line replaceable units that perform a specific function, connected by dedicated interfaces or aircraft system data buses.

Named capability that performs a specific task.

Software applications that will be approved as part of a functional TSO authorization or as part of a type certification effort. Sometimes called operational software, application software, or flight software.

TSO with a defined function. Examples of functional TSOs are in appendix G oftrus AC. TSO-Cl53 is not a functional TSO, because hardware elements typically do not provide system-level functionality.

E-3

### Page 57

I 0/20/10 Functional TSO applicant Guidelines Hardware Hardware element Hardware/so fiware integration Integrated modular avionics Component Acceptance Letter Integrated modular avionics IMA developer/system integrator Cncremental acceptance Appendix E Applicant seeking functional TSO authorization.

Recommended procedures for complying with regulations.

Hem with a physical being. Generally refers to line replaceable units or modules, circuit cards, power supplies and other line items.

Element authoiized to TSO-C 153. A hardware element (as defined in TSO-C l 53) is (1) a hardware module, or (2) cabinets or racks that host hardware modules. A hardware element with TSO-C 153 authorization is not a functional TSO authorization.

Note: This definition 111ay differ from tenns in RTCND0-254 and other documents.

Embedding the soHware into the target computer.

A letter, signed by the FAA, which is composed of three parts; the IMA Component Acceptance Cover Letter, the IMA Component Acceptance Letter data sheet and the signed ACceptance Letter. The holder of a valid lMA Component Acceptance Letter may submit this letter as proof of compliance to the applicable requirements, as defined by the lMA Component Acceptance Cover Letter and IMA Component Acceptance Letter data sheet, to the FAA on a future or concun-ent certification program for that IMA component.

Shared set of flexible, reusable, and interoperable hardware and software resources that, when integrated, form a platform that provides services. These services are designed and verified to a defined set of safety and perfonnance requirements, to host applications perfonning aircraft functions.

Company or organization responsible for TMA system integration. An lMA system integrator may or may not aJso develop most of the IMA hardware or software components.

Process for obt::iining credit toward approval and certification by accepting or finding that an IMA module, application, and/or off­ aircraft IMA system complies with specific requirements. Credit granted for individual tasks contributes to the overall certification goal.

### Page 58

10/20/ 10 Integration Maintainability Means of compliance Module Non-configured hardware component Non-TSO function Appendix E Gathering a number of separate components to fonn a single implementat1on.

Attribute of dependability in the ease of performing maintenance. ln a quantified way, it is the measure of the interruption of service if a failure appears, the ease of identifying the failure, and performing the correct repair. A useful estimator associated with this measure is the MTTR, or mean time to repair .

Method(s) used by the applicant to satisfy the requirements in the certification basis for an aircraft , engine or propeller .

Component or collectio n of components that may be accepted by themselves or in the context of an lMA system. A module may also comprise other modules. A module may be software, hardware , or a combination of hardware and software, that provides resources to the IMA system's hosted applications.

A generic TMA hardware component that has not been configured (such as being loaded with operational software or enabling specific hardware pin programming) which is required before the component can perfonn an intended function or functions when installed on an aircraft or engine.

A non-TSO function:

(a) ls anything that adds a perfo1mance capability to the article that is not covered or evaluated by any TSO MPS.

(b) Does not support or must not affect the performance of the articJe addressed by the TSO MPS.

Note: .. Characteristics" or ''features" added. to enhance performance, usability or integrity of the TSO article, are inherent in the design of the TSO article, and have a direct bearing on the basic TSO operation are evaluated under the TSO approval and are not non-TSO function.

Compliance with the software and hardware considerations in RTCNDO-178 and RTCNDO-254 , when required by the TSO, provide the basis for approval of these characteristics or features of the article with respect to the RTCA/DO-178 and RTCA/DO-254 requirements . Examples might include: the capability to flip-flop the "active" and "stand by" frequenci es of a communication or navigation radio, facility infonnation (such as, airport frequencies, runway s, airport services avai lable, etc.), built in test (BIT) capability on start-up, and health monitoring to name just a few. These examples are all associated with supporting the MPS of the TSO .

Type of computer or software architecture that allows adding, upgrading and swap ping components with minimal effect on the remaining system.

Open architecture E-5

### Page 59

10/20/10 Appendix E Operating syste m 1) Same as executive sotlware.

2) Software kern el that services only the underlying hardw are platfonn.

3) Software that directs the operatio ns of a computer . resource allocation and data management, controlling and scheduling the exec ution of computer host ed applications, and mana ging memory , storag e, inpu t/o utput, and commun ication resources .

Operational capability Function or group of functions that provides an aircraft capab ility visible to the flight crew or other personnel.

Partition Allocation of resources whose properties are guaranteed and prote cted by the platfo rm from adverse inter action or influences from outside the partition.

Pa1iitioning Arch itectural technique to provide sepa ratio n and independence of functions or app lications. To ens ure that only intended coupling occurs.

Robu st configuration management Capab le of pe1forming its intended function without failure under a wide range of condition s.

Platform Mod ule or group ofmodules, includin g core software , that man ages reso urces supp ort at least one application.

Resource Any processo r. memory. software, data. or object or component used by a proce ssor, JMA platform, core software, or app lication. A resource may be shared by multiple applications or ded icated to a specific applicati on. A resource may be physical (a hardware device) or logica l (a piece of infonnati on).

Re-use Subsequent use of unaffected, previously approved system hard ware or software assurance data.

Robust Partitioning Partitioning that provides demonstrable means of containment protection and enforce ment of the partition boundaries.

Safety Attribute of dependability in non-occurren ce of, or recovery from , failures and other conditi ons that could cause unacceptable , operational events of an airc raft, engine or component.

E-6

### Page 60

10/20/ lO Simple electronic hardware Simple Hardware ltem Software Software change Software integration Software life cycle Software product Specification Standard Structure System Appendix E A subset of simple hardware item; a custom micro-coded component with a comprehensive combination of deterministic tests and analyses appropriate to tbe desi&ll1 assurance level. Ensures correct functional performance under all foreseeable operating conditions, with no anomalous behavior .

ltem with a comprehensive combination of deterministic tests and analyses approp1iate to the design assurance level. Ensures correct functional perfonnance under all foreseeable operating conditions , with no anomalous behavior .

Computer programs and1 possibly, assoc iated documentation and data of a computer system.

Modification in source code, object code, executable object code, or its related documentation from its previous baseline.

Combining code components.

l) An ordered collection of processes determin ed by an organization to produce a software product.

2) Period chime that begins with decision to produce or modify a softw are product and ends when product is retired from service.

Set of computer programs and associated documentation and data designated for delivery to a user. ln this AC, it means software intended for use in an IMA system and its associated software life cycle data .

Collection of requi rements which, when taken together, constitute the criteria that define the functions and attributes of a system, a component thereof, or an interface.

Rule or basis of comparison that provides both guidance in and assessmen t of the perfom1ance of a given activity or the content of a specified data item.

Spec ified arrangement or interrelation ofparts to form a whole.

Collection of hardware and software components organized to accomplish a specific function or set of functions .

E-7

### Page 61

10/20/ 10 Appendix E System architecmre System safety assessment Task I Task2 Task 3 Task4 Technical standard order authorization Unintended function Usage domain Validat ion Verification Lnterfaces and structure of the hai·dware and software selected to implement the system requirement s.

1) Systemati c, comp rehensive evaluation of the proposed system to show that relevant safety -related requirements wiU be satisfied.

2) A systematic. comprehens ive evaluation of the implemented system to show that the relevant safety-rel ated requirem ents are satisfied.

The activity associated wilh showing compliance to RTCA/D0-297 , subsectio n 4.2 , for IMA modules.

The activity associated with showi ng compliance to RTCA/D0-297, subsec tion 4.3 , for IMA applications .

The activity assoc iated with showing complian ce to RTCA/D0- 297, subsection 4.4, for an IMA system.

The activity associa ted with showing complian ce to RTCA/D0-297 , subsectio n 4.5, for an IMA installation into an aircraft or engine .

Legat recogniti on by the FAA that a sys tem , equipment, or part satisfies the TSO requirements an<l minimum p erformance specifica tion , and FAA authorization to manufacture that item.

Function visible at tJ,e aircraft level and is neither inlended nor a predicted (foreseeable) fault condition in the prelimin ary syste m safety assessment .

Declared set of characteristics for which it can be shown that:

I) Module complies with its functional , performan ce, and safety requirement s as defined in the module requirement s specification .

2) Module meets all the assertions a nd guarant ees regarding its defined allocatable resources and capabilities .

3) Module performa nce is fully characterized , includin g fault and error handling , failur e modes, and behavior during adverse environme ntal effec ts.

Determin ing that requirements are both correct and complete. System deve lopment may use requirem ents and derived requirements in system validation .

1) Evaluation of a requirement s implem entati on to detenn ine that they were met.

2) Evaluation of process results to ensure corre ctness and consistency of inputs and standards provide d.

E-8

### Page 62

10/20/10 Appendix F AC ACO AFCB AFM AFMS ARP ASJC ASTC ATC CCD CEH CFR CRM EQT EMC EWIS FAA FLS FMS FPGA GPS HlRF Appendix F Acronyms Advisory circular Aircraft cert ification office Arc fault circuit breaker Aircraft flight manual Aircraft flight manual supplement Aerospace recommended pract ice Application specific integrated circuit Amended suppleme ntal type certificate Amended type certificate Cursor contro l devjce Complex electronic hardware Code of FederaJ Regu lations Crew resource management Environmental qualification test(s} Electroma&,netic Compa tibilit y Electrical wiring interconnection system Federal Aviation Adrnirustration Field-loadable software Flight management system Field programmable gate array Global posilio ning system High intensity radiated field

### Page 63

10/20/10 IMA LODA LRU MCDU MMEL MPS ODA PLD PSCP RF RSC RTCA SAE SEH STC TC TCAS TSO TSOA Appendix F Integrated modular avionics Letter(s) of Technical Standard Order (TSO) Design Appro val Line replaceable unit Multi-function control and display unit Master minimum equipment list Minimum petfonnance standard Organization Designation Authorization Programmable logi c device Project specific certification plan Radio Frequency Reusable software component Formerly, the Radio Technical Commission for Aeronautics SAE lntemational. Fonnerly , The Society of Automotive Engineers Simp le electronic hardware Supplemental type certificate Type certificate Traffic alert and collision avoidance system Technical standard order Technica l standard order authorization F-2

### Page 64

10/20/I0 Appendix G Appendix G Partial List of Functional TSOs Below is a partial list of the FAA TS Os that might be considered functional TS Os in IMA systems. Applicants may apply for a TSO that does not adequately cover all the functionality in the system. Or, they may apply for multip le TSOs) since no single TSO covers all functions. If applicants apply for multiple TSOs for a single system, that combination ofTSOs may result in the system being considered complex or integrated, even though the individual TSOs were not.

TSO NUM BER D ATE TSO-C2d 6/14/89 TSO-C4c 4/ 14/89 TSO-C9c 9/15/60 TSO-Cl Ob 9/1/59 TSO- C52b 5/30/95 TSO-C92c 3/19/96 TSO-C93 11/26/76 TSO-CI OI 2/19/87 TSO- Cl 04 6/22/82 TSO-C I05 6/13/84 TSO-C106 1/15/88 TSO-Cl I Oa 10/26/88 TSO-C 1 15b 9/30/94 TSO-Cl 17a 8/1/96 TSO-C 118 8/5/88 TSO-Cl 19a 4/9/90 TITLE Airspeed Jnstrume11ts (Using Electronic Sensing) Bank and Pitch Instruments Automatic Pilots Altimeter, Pressure Actuated, Sensitive Type Flight Director Equipment Airborne Ground Proximity Warning Equipment Airborne Interim Standard Microwave Landing System Converter Equipment Over Speed Warning Instruments Microwave landing System (MLS) Airborne Receiving Equipment Optional Display Equipment.for Weather and Ground Mapping Radar Indicators Air Data Computer Airborne Passive Thunderstorm Detection Equipment Airborne Area Navigation Equipment Using Multi-Sensor inputs Airbome Windshear Warning and Escape Guidance Systems/or Transport Airplanes Traffic Aler/ and Collision Avoidance System (TCAS) Alrbotne Equipment, TCAS I Traffic Aler/ and Collision Al'oidance System (TCAS) Airborn e G- 1

### Page 65

10/20/ 10 Appendix G Equipmenl , TCAS JI TSO-Cl 23b 6/1/06 Cockpit Voice Recorder Systems TSO-Cl 29a 2/20/96 Airborne Supp/cmellfal Navigation Equipmenr Using Global Posilioning System (OPS) TSO-C I46c 5/9/08 Stand-Alone Airbome Navigation Equipment Using The Global Positioning Sys/em Augmemed By The Satellite Based Augmentation Sysrem TSO-C147 4/6/98 Traffic Ad11iso,y System (TAS) Airborne Equipment TSO-C 15 I b 12/17/02 Terrain Awareness and Waming System Note: TSO revisions may change. This list is for reference only.

Ensure that you use the appropriate TSO.

G-1

### Page 66

11/21/2013 Appendix H Appendix H. SAE ARP 4754 to ARP 4754A Cross-Reference Matrix Below is a cross-reference matrix between the sections and paragraphs of SAE ARP 4 754 that are referenced by RTCA/DO-297 and the updated SAE ARP 4754A. Please refer to this matrix in order to determine the correct ARP 4754A paragraph.

RTCA/D0-297 Page#/ Para.# 3 I 1.5 [7] 20 / 3.1 56 I 4.5.7.d 63 15.1 65 I 5.1.5.I 65 / 5.1.5.2.e 66 / 5:J .5.3.1 6615.1.5.4 7215.3 7315.4 7515.5 77 15.6 77 15.6 - Note ARP 4754 Reference Corresponding ARP (Technical Subject of Discussion) 4754A Reference /Para.# of Technical Subject of Discussion ARP 4754 ARP4754A ARP4754 ARP4754A ARP 4754 ARP4754A ARP 4754 (Safety Assessment) ARP 4754A 15.1 Section 6.1 (functional Hazard Assessment) ARP 4754A / 5.1.1 Section 6.2 (Preliminary System Safety Assessment) ARP 4754A / 5.1.2 Section 6.3 (System Safety Assessment) ARP 4754A / 5.1.3 ARP 4754 (Common Cause Analysis) ARP 4754A / 5.1.4 ARP 4754 (Validation Process) ARP 4754A I 5.4 ARP 4754 (Verification Process) ARP 4754A / 5.5 ARP 4 754 (Configuration Management Process) ARP 4754A / 5.6 ARP 4754 (Quality Assurance Process) ARP 4754A I 5.7 ARP 4754 ARP4754A Note: Some references within RTCA/DO-297 refer to the entire SAE ARP 4 754 document. hut the discussion in that RTCJ\/DO-297 paragraph is limited to a specific technical subject. This table provides information on the technical subject being discussed for that RTCAJDO-297 reference and provides the exact paragraph number of ARP 4754A.

We believe that this information is or greater use to the reader than repeating the reference to the entire SAE ARP 4754A document. See rows 4, 8. 9, 10, IL and 12.

H-1

---
OpenAirDocs.org is an independent research project of [Contrail Labs](https://contraillabs.com/). It is not affiliated with the FAA or the NTSB. Source documents are U.S. government works in the public domain.
