Integrated Modular Avionics Development. Verification, Integration and Approval using RTCA/DO-297 and Technical Standard Order C153

Advisory

U.S. Department of Transportation Federal Aviation

Circular

Administration Subject: Integrated Modular Avionics AC No: 20-170 Date: 11/21/2013 Development, Verification, Integration, and Change: 1 Initiated by: AlR-120 Approval Using RTCA/OO-297 and Technical Standard Order-Cl53 Purpose. This advisory circular (AC) sets forth an acceptable means of compliance 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 Dated Insert P cs Table of Contents. page 10/28/IO Table of Contents. 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. Ilempe Manager, Aircraft Engineering Division Aircraft Certification Division

Advisory

U.S. Department of Transportation Federal viation

Circular

Admini tration Subject: Integrated M dular A ionics Date: I 0 /2 8/ J o: 20-170 Development, Verificali n. Integration an Initiated by: AIR -120 Approval Using RTCA/OO-297 and Tecluucal Standard Order-Cl 53 Thi advi ory circular cts forth an acceptable mean f compliance for aircraft and engines 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 /11t eg rated Modular Avio nics ( JMA ) that Im plement TSO-CI 53 Author iz.ed Hardware Elements. AC 20-145 i now cancelled.

h~ David W. Hempe Manager, Aircraft Engine ring Di isi n Aircraft Certification Divi . i n 10/28/10 AC20- 1 70 Table of Contents 1-2. Wh om thi s AC A ff~cts .. ................ .. ............................. .. .. ................................................... l 3-3. Essen tial Elements of the IMA Compon ent Acceptance Cover Lett er ............................. I 0 4 -1 . Reu se of an A cce pt ed lMA Co mp onen t. .......................................................................... l 5 4-4. Reuse of P revious ly Acce pt ed Software-Onl y or Hard ware Com ponent Containi ng Airbor ne So ftware ..................................................................... .. ............................................ .. 17 4-6. R euse O fS EH or H ar d ware Component Containing SE H ... ............................................ J 8 II 10/28/10 AC 20-170 4-8. Data the Component Developer Owes to Lhe IMA Developer/System Integrator or 4-10. Reuse of an fMA Component with a Previous TSO Au tho ri zation ......... ...... ............ .. .. . 20 5-2. Automated, Robust Configurati on Management ............................................................ .. 2 1 7-4. Aircraft System Lightning and HCRF Protection ... .............................................. ... ........ .. 27 8-2. TSO-C 1 53 Authorization for IM A Hard ware Components ........... .. ............................... .. 29 8-7. Aircraft Installation Approval of IM A Systems including TSO Autl1orized Components .

8-8. Roles and Responsibilities When TSO Authorized Components Are Used in IMA Ill 11/21/2013 AC 20-170, Chg. 1 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 10 /28/10 AC 20-170 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 approval for the development. verification, and integration of an integrated modular avionics (IMA) system for in stallation 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 me nt s.

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. Thi s AC uses the terminology "s hould'' wh en discussing comp lian ce to the AC itself , as the AC represents one, but not the only , method of complying wiU1 the r eg ulations. This AC uses the term ''must " when discussing compliance to the r e_b rtilations, as compliance to a regulation is not optional ln th ese ca ses, the AC text supplies a reference to the specific rule(s) being di sc ussed.

1-2. Whom this AC Affects.

a. We wrote this AC for: (I) Applicants for type certificates (fC), amended TC (ATC), supplemental TC (STC), or amended STC (ASTC) of aircraft and aircraft engines implem ent ing IMA systems and equipment, (2) Developers of IM A syste ms , applications, and components, (3) Applicants for TSO-C153, Integrated Modular Avionics Hardware Elements, and for functional TSOs as th ey apply to IMA systems, (4) Integrators of lMA systems, (5) Installers of the lMA system into the aircraft, a nd (6) Those involved in the approval a nd continu ed airworthiness of IMA systems.

b. When the term .. applicant'' is used in this AC , we are refe ning to the app li cant for an aircraft or engine TC. STC, ATC. or ASTC. When this AC is referring to an applicant for a TSO authorizati on (TSOA), the phrase "applicant for TSO authorization" or other similar phrase is 10/28/10 AC 20-170 used. When this AC is referring to an applicant for an IMA Component Acceptance Letter, the phrase "app licant for fMA Component Acccptanc,e Letter • or other s imil ar phrase is used .

1-3. Cancellation. This AC cancels AC 20-145, Guidance/or Integrated Modular Avionics (IMAJ that Jmpleme11t TSO-C 153 Authori=ed Hardware Elements. and incorporntes all pertinent 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 Ele ments, 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 of thi 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 development, integration, verification, and installation approval of 1MA systems. If the applicant wants to propose an alternative means. including tho se from other industry documents refer enced by RTCA /DO-2 97 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 se t of flexible, reusable, and interoperable hardware and software resources that, when integrated, fonn a platform that provides se rvice s.'' You should keep in mind that an I MA system is defined by the system architecture, not by the functionality the system provides. lMA systems may not always imp l ement functions historically regarded as "avio nics", such as flight deck displays, navigation, communication, etc. IMA systems 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 l ying RTCA/DO-297 as an Acceptable Means of Compliance.

a. RTCNDO-297 des(..Tibes objectives. processes, and activities to incrementally accumulate design assurance and acceptance of IMA systems 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 of Conducti11g the Safety Assessment Process 0 11 Civil Airborne Systems and Equipment. When RTCA/0O-297 invokes the processes and methods in specific 11/21/2013 AC 20-170, Chg. 1 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 of Civil 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.)

11/21/2013 AC 20-170, Chg. 1 (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).

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 moduJe application, or system comp lies with its defined requirements. 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 ce rtification 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 system complies with specific requirements. This incremental acceptance is divided into tasks. Credit granted for individual tasks contributes to the overall certification goal.

Incremental acceptance provides tbe ability to integrate and accept new applications and/or modules, 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.) a nd published FAA policy used to approve airborne systems during an aircraft or engine ce rtification 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, 2 1.20, and 2Ll 15. Some of the regulatory requirements are accompanied by an AC (such as this one) that describes one, but not the o nl y, possible means of complying wi th tho se 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 re cognition, such as a "s igned letter or stamped data sheet" or <(acce pted or approved compliance data package,'' and 2) a goal of acceptance, as defined by RTCA/DO-297, is to "achieve credit for future use in a ce rtification pro cess." Otherwise, the two concepts are very similar: data submissions and statements of compliance are used to show that an airborne system or component complies with all applicable requir eme nt s and therefore can be approved for in stallation onto an ai rcraft 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 context. 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 fu ll y or pruiially meeting RTCA/OO-178B objectives 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 spec ifi c definitions of "acceptance" are not identical. Th is example illustrates that the meaning 10/28/10 AC 20 - 170 of ''acceptance" may vary, given 1t s context. Make sure you understand the context and meaning of this term when you enco un ter it.

e. "Incremental acceptance", as defined in RTCA/ 00- 297, takes the concept of acceptance further. lt divides acceptance into «certification tasks" accomp li shed during different points, or increments, in the certification program. Each task builds upon previous tasks. Incremental acceptance of IMA components is no1mall y 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 m ay u se 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 certification processes. [n stead, 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 incremental 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 certificati on effort of the current aircraft or engine program without compromising system safety.

(2) Reuse accepted [MA components in future certification programs by submitting certification data packages th at ha ve 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 compone nt , so the previously acce pt ed data and artifacts may eas il y be used in multiple concurrent or future programs.

2-3. I MA Mod ule, App lication, System, and In stallation Acceptance.

a. Acceptance at each st age 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 s ub section 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.

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

Note: RTCA/D0-297 , subsecti on 4.6 (Task 5) deals with changes to acce pt ed 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 of the initial acceptan ce of the 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 components are being reused, subsection 4. 7 (Task 6) should a1so be consi <l ered.

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

c. The FAA will not grant acceptance at the higher task level s- that is, Tasks 2, 3, and 4 unti l aJJ acceptances at the subordinate levels on which those higher tasks depe nd have been completed. For example, to obtain acceptance fo r an IMA application, you should first obtain acceptance of a ll modules wh ich comprise that applica ti on. Likewise, all applications that make up an lMA sys tem 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. Examples 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 require that you use tho se 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 compliance to this AC. See RTCA/D0-297 , subsection 4.1 for more infonnation.

10/28/10 AC 20-170 Chapter 3 Obtaining an IMA Component Acceptance Letter.

3-1. General Guidance Regarding IMA Component Acceptance Letters.

a. Obtaining an IMA Component Acceptance Letter is optional for app li cants, IMA de ve lopers/system integrators, and [M A component developers. The d ec ision to apply or not apply for an IMA Component Acceptance Letter has no bearing on the final appro val of the IMA system and its instal lation onto an aircraft or eng in e. The main reason to obtain an IMA Component Acceptance Letter is to formally docu ment acceptance of the compliance data for future or co ncurrent reu se of that accept eel IMA component. If you do not request an IMA Component Acc eptance Letter, we will not issue one.

b. We typically issue the fMA Component Acceptance Letter after: ( I ) The applicant has completed and submitted all applicable documentation and s hown that the objectives ofRTCAID0-297, Annex A, Table A-1 and/or A-2 (depending on if the IMA component is a m odule or an application), Tab le A-3, and Table A-4 have be en achieved, and (2) We find no installation, safety, operational, functional, or performance concerns.

c. l fthere are software operating systems, generic hardware computing/power supply modules, or other IMA components not depe nd e nt on IMA system integration or aircraft installation, we ma y issue an IMA Comp one nt Acceptance Letter before co mplet ion of those la t er stages of IMA development and integration. However, you should work with the FAA during the planning process if you desire an IMA Component Acceptance Letter ptior to the certification of the aircraft or engin e. Otherwise, this request for an IMA Component Acceptance Letter may n ot be prioritized according to your needs, as the FAA will nonnally issue IMA Co mponent Acceptance Letters after the completion of the certification program.

d. Accord ing to RTCA/ D0- 297, subsection 4. 7, future reuse of co mpliance data for a previously accepted IMA compo nent is li mited to IMA modules and applications. Therefore, we will only issue IMA Compone nt Acceptance Letters for IMA modules and applications. We will not iss ue [MA Component Acceptance Letters for an IMA system or its in stallation onto an aircraft or engine.

c. RTCA/D0-297, subsec ti on 4.1 , sta tes: " IMA acceptaJt ce can only be proposed in the context of an actual certification project.'' That means we issue IMA Component Acceptance Letters on ly for IMA components being de ve l ope d and approved for a specific aircraft/engine certification program. We do n ot i ssue IMA Component Acceptance Letters for TSO authorized articles that are not for an identified aircrafi/engine certification program.

f. A request for an IMA Co mponent Acceptance Letter is not limited to the developer of an IMA co mponent. The applicant, IMA developer/system integ rator, or lMA component developer m ay apply for an £MA Component Acceptance Letter. The intent to request an IMA 10 /28/10 AC 20-170 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 depends 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 should apply for a new IMA Component Acceptance Lett er to the Aircraft Ce rtification Office (ACO) that issued the ex isting [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) , yo u 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 component 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 is suing the TSO authori za tion 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 normally 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 i ss ue an IMA Component Acceptance Letter for an lMA component that is u se d 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 Component Acceptance letter to a company that is n ot based within the United States. There JS not an ACO that has geographic responsibility and oversight of that company.

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

a. An IMA Component Acceptance Letter is compos ed of three parts: Q 10/28/10 AC 20-J 70 (I) The IMA Co mponent Acceptance Cover Letter, prepared and signed by the applicant for t he IMA Co mp onent 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 Acceptance Letter, prepared and signed by the FAA. See paragraph 3-5.

b. If you are an appli can t for an IMA Component Acceptance Letter, assemble your request package (both the co mpleted I MA Co mponent Acceptance Cover Letter and the lMA Component Acceptance Letter data s he et) and submit it to the appropriate FAA office. If we approve your request, we wi ll prepare and sign a Accepta nc e Lette r for that [MA component.

We will se nd the app li cant ·for the IM A Component 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 I MA Component Acceptance Lett er .

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

d. You should maintain your ow n 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 modifications to previo-usly accepted IMA components under an existing lMA Co mponent Acceptance Letter. [f you c hang e a previously accepted IMA component and still wa nt 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. Essential Elements of the IMA Component Acceptance Cover Letter.

a. The IMA Compo ne nt Acceptance Cover Letter specifies what compliance data is being accepted by the FAA . The applicant for an I MA Component Acceptance Letter should include the followjng information in the IMA Compone nt Acceptance Cove r Letter: (1) Date of application for the IMA Co mponent Acceptance Letter.

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

(3) Unique identifier for the JMA Comp<.1 n en t Acceptance Cover Letter. The specific fo1111at of this ident ifier is left to the di sc retion of the app lica nt for the IMA Co mponent Acceptance Letter. It could be a company co rrespondence number or a unique identifier used solely for the purpose of application for IMA Component Acceptance Letters. Ho wever, once a particular identification is used. it should not be re-used.

10/28/10 AC 20-170 (4) Name and cont ac t infonnation fo r the company requesting the IMA Component Acceptance Letter.

(5) Name and contact information of the original IMA developer/system integrator, the airborne system and aircraft/engine in which the component will be installed. the target environment, such as the microprocessor, memory management unit, data bus ses, input/output devices~etc., and ot her 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 Letter.

(6) Contact infonnation fot persons or org anizations who will answer questions about component acceptance and concurrent/future reus e.

(7) IMA component name, unique component identifier, and all associated document numbers, titles, and revisi on levels. Examples are the system, software or hardware (as appropriate) configuration ind ex number and revision. a component's acceptance accomplishment summary number and revision, and any configurati on information not included in the module configuration index.

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

(9) High l eve l de scription of the component pw-p ose und usage domain. See RTC A/ DO 297, paragraphs 4.2. l0 and 4.3.2. and the Glossary of thi s AC for the di sc ussion 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) Definition of the co mp! iance <l ata type(s) being accepted and documented by this IMA component a cc eptance letter - that is. airborne so'flware, complex el ec tro ni c hardware (CEH), com prehensive te sting for simple el ec tronic hardware ( SE H) component s, EQT. and any other data type that ha s been mutuall y agrce <l on.

(12) State whether each compliance data type sh ow s f ull or parti al complian ce to their respective standards - for example, RTCA/DO- 1 78 8 for airborne software. A full description of any pa11ial compliance is not necessary, as we expect you lo in clude that infonnation 1n the IMA Component Acceptance Letter data she et de sc ribed in paragraph 3-4.

(13) Stateme nt of compliance that the signatories attest th at the IMA component meets al] th e applicable requirements defined in the lMA Component Acceptance Letter.

(14) Signa tures and dates. At least one managerial signature repre se nting each of th e technical disciplines cover ed by the IMA Component Acceptance Letter: RT CA/DO-178B compliance for airborne so ftware, RTCA/DO-254 compliance for C EH , com pr ehensive testing 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 Com ponent Acceptance Letter desires. Each signature shou ld 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 sa mple lMA Com ponent 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 TM A component is fully defined. If that infonnation is not in the fM A Component Acceptance Cover Letter, then you should include it as part of the accompanying LMA Component Acceptance Letter data sheet.

b. Each IMA Component Acceptance Letter data sheet should contain, at a minimum: ( 1) Assumptions the JMA component developer made during the acceptance. These assumptions may be documented by referencing the component developer's accomplishment summary or other appropriate certification document. In clude assumptions for each applicable RTCA/OO-297 objective in lhe approprial'e accompl i sh ment summary. The asswnptions should be detailed enough that the FAA, the l MA developer/sys tc..,ns integrator, and applicant can apply this information to any future or concurrent 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 resolved them .

(3) Summary of additional activities that the lMA developer/sys tem integrator and/or applicant need to perform to ensure that a ll objectives of RTCA-DO-297 Task s 3 and 4 can be met wh en us ing the accepted [MA component. De sc ribe any remaining compliance activity required to s how full compliance to the appropriate standard - for example, RTCA/DO-178B for airborne software, any remaining EQT requ i red by RTCA/DO-160F, Environmental Conditions and Test Proc edures.for Ai rborne 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 de sc ription of the target computer. incl.uding the applicable hardware, operating system, board support package. diivers, etc., that w ill host software to perfonn aircraft-level functions.

(6) High-level description of the fu nction and/or purpo se of the component and target environment. If the component contains multiple soltwa re partitions and/or multiple CEH / SEH devices, include a high level description of each. This allows us and the IMA component 10/28/ 10 AC 20-170 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 installation, safety, operational. functional, 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 techni ca l data ot her than those specific technical disciplines addressed in paragrnph 4-2.b of this AC included in the lMA Component Acceptance Letter. The applfoant for the lM A 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 compliance for the compliance data associated with this technical discipline.

( 11 ) A copy of any pertinent document that demonstrates the com pli ance data contained in the J MA Component Acceptance Letter data sheet has been eva luat ed and found acceptable by the FAA orby an authorized representative of the FAA . Examples include signed 8110-3 fonns and TSOA letters. By including evidence that data wit hin the IMA Component Acceptance Letter data sheet ha s found Lo be acceptable, you will significantly s pe ed 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 co mponent 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 wi ll 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 previously accepted [MA component has been changed or revised in any manner, the original IMA Component Acceptance Letter is no longer 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 l east some of tbe accompanying documentation - such as the component configuration index - to be updated. This requires a new IMA Co mponent Acceptance Letter.

10/28/10 AC 20-170 b. Lfthere's a change to a previously accepted IMA component and you want a new IMA Component Acceptance Letter for it, you sh ou ld sh ow 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 n ew 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 previously issued IMA Co mpone1;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 th e subject of a § 2 1 .3 repor t.

(3) The lMA co mp o nent de veloper. IMA devel ope r/system integrator, or applicant detenninc s that the IMA co mp onent does not meet the acceptance criteria defined in th e original IMA Com ponent Acceptance Letter.

( 4) It is discovered that the accepted co mp onent was d ev eloped from erroneou s or incomplete requirements. and th ose erroneous or incomplete requirements could, given the correct circumstances, lead to a reduction in safety in any aiTcraft or engine in which the co mp one nt i.s installed.

b. We wilJ notify the holder of an IM A Component Acceptan ce Letter when it is cancelled.

This action ha s the effect of not al1owing that version of the lMA component to be reused on a future or concurrent ce rtification program until U1e rea so n for th e cancellation has been addressed. A new IMA Co mp onent Acceptance Letter for the updated JMA co mponent ma y be requested p er para!:,'Taph 3-6.

Note: Cancelling an IMA Component Accept an ce Letler ha s no bearing on the continued safe operation of an aircraft or eng in e that u ses 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 que s ti on.

c. We expect the holder of an £MA Component Acceptance Letter to contact the ACO that issued the IM A Component Acceptance Letter in a timely manner if any issues such as those listed in a. are discovered.

10/28/10 AC 20-170 Chapter 4 Reuse Of IMA Components.

4-1. Reuse of an Accept ed IMA Component.

a. If a previously accepted IMA component is unchanged, its intended reuse meets the limitations in the IMA Component Acceptan ce 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 component, you should ens u re and document that you identified no safety, installation, operational, 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 li ance data for an IMA component, the existence of such a letter does not preve nt us, on a new or concurrent TC/STC/A TC/ ASTC program, from requesting to examine the com pliance dal a associated wilh lhe ::iccepted IMA co mponent if we have questions or concerns. We will fir st try to address any open questions without resorting to re-examination of the previously accepted compliance data. However, ifw e have specific concerns that cannot be answered hy any other means, we may ask you to provide some of the previously accepted dnt a. Only compl ian ce data spec ific to the identified issue or concem should need to be rc-examin~d. If the initial IM A Component Acceptance Letter was done co rre ctly and all necessary complian ce data was included in the IMA Component Acceptance Letter, we should not need lo resort to re-examination of previously accepted compliance data.

d. RT CND0-297, paragraph 4. 7. I. states that fu tu re reu se 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 n ew ly developed co mp onent.

4-2. What Can Be Reused.

a. RTCA/D0-297, subsection 4.7 states that reuse of a previously accepted co mpon ent should be limited to modules (see Task 1 in RTCA/ D0 -297, subsection 4.2) and applications (Task 2, subsection 4.3). We do not allow reuse of pr eviously accepted data at the IMA system level (Task 3, subsection 4.4) or IMA installation l eve l (Task 4, subsection 4.5).

b. RTCA/00-297, subsection 4.7 Jimits reuse of the types of data 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 be low.

10/28/10 AC 20-170 (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 RTCN DO-297, paragraph 4.7.4 and to paragraph 4-7 below.

c. In addition to those three techni c al data types, this AC identifies comprehensive testing of SEH as another data type for w hi ch acceptance data can readily be developed, packaged, and accepted for future reu se. Reuse of compliance data for SE H is not covered in RTCAIDO-297.

( I) RTCAIDO-254, subsection 1 .6, provides the following definition: Simple Hardware Item - Item with a comprehensive combinati on of detertnini st ic tests and analyses appropriate to the design assurance level that ensures correct functional perfonnance under all fo reseea ble operating conditions, with no anomalous behavior.

(2) AC 20-152, RTCA, Inc., Document R.TCAID0-254, Design Assuran ce Guidance.for Airborne Electronic Hardware, says that applicants should apply RTCA/DO-254 to custom micro-coded components, which are a subset of "hardware items." This is AC 20-152's definition: Custom mi cro-coded component - A compone nt that includes application specific integrated circuits (ASIC), programmable logic devices (PLO), field programmable ga te atTays (FPGA) and olher 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 sa tj sfies the definition a simple hardware item of RT CA/ DO-254.

The design of an SER device can be shown to be correct and complete by comprehensive testing and analysis without a deta il ed development assurance process. Ask your FAA ACO for mor e information regarding definitions and explanations of CEH, SEH, hardware items, and custom mi cro-coded devices. See RTC A/0O-254) sub sect ion 1.6 for more information on simple 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 th ose li sted in 4-2.b and 4-2.c, you should in clude U1i s intent in the appropriate certification planning document. Work closely with us, the fM A developer/system integrat or , and applicant at the beginning of the component development program to ensure that future reuse of thi s data is feasible, and all parties agree on w hat is required to ensure the success 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 yo ur proposa l.

10/28/ 10 AC 20-170 b. Any compliance data beyond tho se data types li sted in paragraphs 4-2.b and 4-2.c. that you propose for inclusion in an TMA Component Acceptance Letter should fa ll within Tasks I and 2 p er paragraph 4-2 above.

c. The IMA component requirements 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, addresses reu se of a software module or application.

However , as stated in RTCNDO-297, paragraph 4.7.5, this guidance should al so be followed for IMA hardware components that contain airborne software.

b. lo a dditi on to the guidance for reu se of a previously accepted component containing airborne software provided by RTCA/DO-297, th e guidance for the reu se of afrbome software contained in AC 20-148, Reusable Software Components, should also be u se d in i ts entirety, with the exception of Chapter 9 which addresses the Reusable Software Component (RSC) Accept ance Letter. AC 20-148 contains more detail than RT CN DO-297 about developing airborne software for reuse, and reusing that so ftware i11 another project. AC 20-148 specifies the roles and responsibilities of all parties, the pro cesses LO be used, how the data should be de ve l oped when future reuse is intended, and what data should be suppli ed by the software developer to the integrator o f the software or to the applicant.

c. RTCA/ DO-297 , paragraph 4. 7.2 stat es lhal the prerequisites for r eusing previously accepted so ftware is that the software should be hosted on the " sa me target hardware " and is 'used in the s ame wa y operati ona lly" for the carJier accepted application and the intended reuse application. Given the rapid change in technology employed in today 's IMA systems as we ll as the rapid rate of hardwar e parts obsole scence. it' s likel y that the intended platfonn that is to host the reused so ftware component wm not include the same target hardware that initially hosted the accepted so ftware. The ta rget hardware may include a mi croprocessor from the s ame family as that of the pre vious target hardware. Howe ve r, co ming from the sa me family of microprocessors doe s not automatically qualify as "the same target hard wa re." lf an l MA de veloper/ syst em integrator or applicant wants to reuse a previously accepted IMA component that contains software. but that software w ill be ho sted on non-identi ca l target hardware, th e applicant should ensure co mp liance with all RTCA/DO-178B and RTCA/0O-297 objectiv es and document h ow they int end on showing 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 co mponents wiU1 hardware design assurance levels A, B, and C. See paragraph 4-2.c (2) for definiti on of custom micro -c o ded components. Accordingly, we restrict g ranting IMA Component Acceptance Letters { per RTCA/ DO -297, paragraph 4.7.3) to RTCA/DO-254 10/28/10 AC 20-170 complex cu stom micro-coded components - that is, to CE H and not commercial-off-the-shelf (COTS) hardware device s.

b. Your ACO will u se FAA Order 8 1 l 0.105 for definitions and additional information on usingRTCNDO-254 as an acceptable means of compliance.

c. Cu rrently, there is no guidance for CE H that define ::; a detai l ed acceptable means of complian ce similar to that provided by AC 20- 148 for an RSC. However, because of the man y s imilari6e s between the processes in RTC A/ OO-1788 for airborne software and those in RT CA/D O-254 for airborne electronic hardwar e, adapt the paragraphs of AC 20 -148 listed below to CE H. Use these paragraphs of AC 20-148 when negotiating an agreement between yo ur se lf and us on reusing CE H co mponent s: ( l) Paragraph 4 - General Gu idelit1es for Getting t he FAA 10 Accept an RSC .

(2) Paragraph 5 - Guidelines for the RSC De ve lo per.

(3) Paragraph 6 - Data the RSC De ve lo per Must Supply to the RSC Lnt egrator or Applicant.

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

(5) Paragraph 8 - Expectations from FAA on First U se of an R SC.

(6) Par ag raph J 0 - Expectations from FAA on the Subsequent Use of an Ac cepted R SC.

4-6. Reuse Of SEH or Hardware Component Containing SEH. As with CE H, there's no current guidance on reusing SE H compliu.n ce data . Consult the sa me par agraphs listed 1n paragraph 4-5 above when negotiating wilb us on adapting and us ing the se paragraphs for SE H components. Your ACO w iIJ use FAA Order 8 1J0.105 for infonnation on SEH and our ex pe ctations r eg arding co mp rehensive testing of SEH components.

4-7. Reuse of EQT Data.

a. R TCA/ DO-160F , Section 1, stresses the importan ce of se lecting the right environmental conditions and test pro cedures for equipment under test. A phrase used throughout RTCA/ DO 160F is, ''detennine compl ia nce wi th applicable equi pment perfon nance standards.'' If you are the t este r r es ponsible fo r EQ T, it is up to you lo detennine the s pedfic te st co nfiguration and requirements a ppr op riate fo r the equipment und er te st. Th ere are many aspects of environmental testing - vi br ation levels, temperature, altitude, orientation of equipment, electrical connectors, electrical ground ing sc hemes, an d electrical wire lengths - speci fi c to the aircraft in which the equipment will be installed. The qualificati on t es t plan for the equip ment 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 J 0/28/10 not change, each lMA system can be tailored specifica ll y 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 varia ble s and parameters used during EQ T. 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 identical to what is required for the intended reuse, then Lhe integrator of U1at previously accepted component should document tho se differences 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/system integrat or or applicant sho uld re-test that aspect of the EQT, u si ng 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 previously accepted !MA component should supply the IMA developer/system jntegrator and/or applicant who is reusing the component with many different types of data. This ensures that the lMA developer/system integrator and applicant can fully sati sfy 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 previousl y accepted lMA component may choose to use a data/ so ftware escrow approach. See AC 20-148, paragraph 6.j(2) for guidance regarding data/software escrow.

c. AC 20-148, paragraph 6 details the data for airborne so ftware that a developer of a pre viously acce pte<l software component should make availabl e to the IMA developer/system integrator, the apphcant, and to us, if we ask. As noted previously, there is oo similar guidance for accepted reuse of either RTCA/DO-254 or RTCA/DO- I 60F compliance data. However, RTCA/DO-297, parabrraphs 4.2.3, 4.2. 12 , 4.3.1, and 4.3.2 document man y of the elements required. A developer of a previou sly accepted IMA component should provide the data required to ensure compliance with RTC A/DO-297, subsection 4.7 and with the objectives of Annex A, either 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 previously accepted IMA com ponent that has been revised since its last acceptance should meet the 1 9 10 /28/10 AC 20-L 70 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 ha s a previous TSO authorization also has been previously i ss ued an IMA Component Acceptance Letter. then the process for reuse of a previously accepted TMA component takes precedence. The ap plica nt and IMA developer/system inte&rrator s hould 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 IM A Compone nt Acceptance Letter, then the fo llowing applies: (1) You sho uld fo ll ow all limitations d escr ibed in the TSO authorization when integrating the component into the IMA system . The se 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 u sage domain identified 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 n ot affect the u se of the IMA component wit hin the intended usage domain .

(3) You should identify all RTCA /DO - 1 78B and RTCA/DO-254 objectives that have on ly been partially met under the TSO authorization and de scri be in the appropriate certification planning document(s) how full compliance to these objectives will be shown for the integrated rMA syste m. See AC 20-148, paragraph 5.d(t) for more i nfonnat i on .

(4) You sho uld identify all remaining EQT that are required for the aircraft or engine insta llation that is not cove red by the TSO authorization. These remaining EQT should be described in the appropriate ce rtification planning d oc ument( s). Any EQT r es ult s from the TSO authorization that you des ire to take credit for at the aircraft or engine installation l eve l shou ld be described in the a pp ropriate 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 SE H devices are not covered by TSO authorizations, unless specifically stated in the TSO .

The guidance of paragraph 4-6 should be used.

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

5 ·1. IMA Configuration Management.

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

b. Configuration management of an [MA system instolled in an aircraft is cr itical because the system may contain many hardware components and functiona l software components, with each component having multiple approved versions or on-aircraft option selections. Some possible combinations of hardware and so fl ware versions will not be approved for flight.

c. Configuration management techniques to man age tJ1 e I MA arch itecture are necessary to safely accommodate system attributes. suc h as (b ut not limited to) the fo llowing: (J) Hosting multiple software appl ications on a s ing le processor or on multiple, non dedicated processors.

(2) Produc i ng and distributing hardware components withou t loading specific functio nal software.

(3) Allowing electronic part nwnbering for software components, without the need to phy sica ll y mark hardware elements with the software part n umber(s).

(4) Allowing the clectronfo displ ay of TSO ide ntification.

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

(6) Allowjng the stocking of gene1 ic, non-configured hardware components for maintenance purpose s. A non-configur~ hardware component is one th at does not already contain the functional software components needed for sati sfy ing an aircraft, engine or system function. These hardware components will be loaded later with field-loadable software. Each generic hardware component may have mu ltiple versions, as components normally undergo updates during their lifecycle. Unless a specific effort is made to purge operator spares of earlier versions of a hardware component, you sh ou ld assume that every ve rsion of a hardware component w ill exist in service and co uJd be used on an aircraft or engine insta ll ation.

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

5-2. Automated, Robust Configuration Management.

a. We stro ng ly recommend a robust, automated configuration management scheme for an IMA system installed on an aircraft. A key feature of an automated configuration management scheme is that the IMA system itself monit ors the configuration of either all or a subset of the 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 p onent hosted in multiple hardware components.

(3) Incompatibilities or uncertified configurations between various systems that are clo sely coupled, such as autopilot and fli ght managemem systems.

(4) Incompatible system co nfigurations with the aircrafl model in which it is installed, and (5) Incompatjb)e option selections.

c. Any loss of function caused by configuration management system protections must be shown to be acceptable 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 configuration management scheme of the .IMA system installed on the aircraft or engine is not automated or depends on maintenance personnel to config ur e the system, eith er fully or partially, and to determine if the system configuration correct fo r 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 cou ld result in a uon-opproved rMA co nfiguration. 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 lM A 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 pl eted successfully and that the correct version of software is now installed.

5-5. Assurance Level of IMA Components Used in Configuration Management An y 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 l eve l commensurate with the hazard cla ss ificati on of allowing a non.

approved configuration to be di spatched. This includes automatic configuration monitoring and displaying electronically stored part numbers and ve rsions on a flight deck or maintenance display.

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

6-1. Restarting Safety Critical IMA Functions. Due to unfor eseen circumstances. an fMA function, co llect ion of lM A functions, or an entire Uv1A cabinet may unexpecte dly shut down without th e ho st ing ]M A hardware com p one 11t s experiencing a p cnnanent fai lure. IMA systems mu st include the ability to restart an y hosted function or fun ct io ns whose continued ope1·at ion is required by the sys tem or aircraft le vel safety assessmen t. S ee § xx. 1309, x.x denoting parts 23, 25. 27, or 29 as applicable.

6-2. Restart Mechanism Implementation.

a. An IMA function or sys tem restrut feature included in an IMA system, when feasible, should be initiated automatically when a safety critical lo ss of function is det ec ted. The IMA design should avoid the need for crew-initiated recovery fea tures.

b. lf an automatic recovery feature is not feasible and a crew-initiated - that is, non automated - recovery feature is implemented instead. you shou ld put protection mechanisms and operations procedures in place to pre ve nt accidental a1,.'tivalion of the recovery fea tw- e b y th e flight crew c. The system design should carefully co nsid er how man y automatic attempts at restarting failed lMA functions or cabinets should be attempted. A ll empting to restart indefinitely when the fa il ed fu nction or cabinet repeatedly shuts it se lf down may ca use increased cr ew workload or distraction. Repeated failures after r esta rt attempts ma y indicate that there is a fai l ed J MA resource that should not be restarted. The system resta.it m ec hanism design should consider potential causes for restarts and determine the appropriate nwnber of restarts to attempt before dec]aring the sys tem failed. Factors that influence this ar~hil ec turc are the failure condition(s) associated with lo ss of IMA functionality, the in1pa ct of multiple restruts of a function or fun ct i ons on interfacing systems, and the fun c ti onality remain ing from n on- LMA systems.

d. The IMA design should not rely on cycli ng aircraft circuit breakers to restart any IMA system or function. If crew-initiated manual recovery features are used, design a means other than cycling circuit breakers.

e. The appl1cant should eva luate the effects of automatically and/or manually activating re cove ry features in both normal and fai led conditions for all phases of flight. The applicant should evaluate the effects of l oss of functions d urin g manual or automatic restart for all phases of flight.

I0/ 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 architecture of the lMA to suppoti the fli ght crew's ab il ity to manage smoke or fire events without losing functions whose lo ss are catastrophic.

b. If arc fault circuit breakers (AFCB) are utilized for IMA cabinet or rack circ uit protecti on, they should be specifically qualified for u se on aircraft. At the issue date of this AC, the use of AFCB technology in airborne systems is in its infancy. Therefore, until more experience is gained and updat ed reg u la t ory and/or guidance material is issued for the certification of AFCBs, the FAA may develop a me tl 1od of compliance Issue Paper for certification programs that u se AFCB technology.

c. The 1MA cabinet or rack should not be powered wit h circuit prot ec tion features such as so ftware controlled circ uit breakers that are co ntroll ed by microprocessors hosted in that I MA cabinet or rack. T he intent of this guidance is to prevent the co mplete loss of control of the circuit pr otection feature(s) of any speci fie lM A cabinet or rack, or l MA components installed within that cabinet or rack, such that the electri ca l power input cannot be removed to that cabinet o r rack ifit fails.

d. The following app lies to part 25 transpo r1 airplanes only.

( l) E lectrical wiring interconnection syst em (EWJS) components, as defined by § 25. 1 70 1, associated with lMA systems must comply with th e applicable EWlS requirements of Part 25 . See § 25.170 I. Refer to Advisory Circular 25. 1 70 1- 1. Certificatio 11 of Electri cal Wiring in terconnection Systems on Transport Catego,y Airplanes, fo r specific co mpliance guidance.

(2) We consider EW IS to be an airpl.ane system. Therefore, EW IS associated witb IMA systems required for type certification or by opera ting rules, including th ose specifically listed in § 25. l 705(b) must be considered as an integral part of thal IMA system and mu st be considered in showi ng co mpliance with the ap plicable requirements for th at LMA system. See§ 25.l 705(b).

(3) C ircuit protective devices for the IMA cabinet or rack must comply with the requirements of§ 25.1357. See§ 25.1357. T hj s in c1 udes § 25.1357(f) which requires IMA sys tem s for which the abi li ty to remove or reset power d ur ing nonnal operations is neces sary be designed so th at circuit br eakers are not the primary means to remove or reset syste m power unless speci fi cally de signed fo r use as a sw itch.

7-2. Fie ld Lo ad able Software.

a . Many IMA systems use field loadable softwa re (FLS) as part of the TC / STC / ATC / ASTC installation. FLS is software that can be loaded into the host hardwar e without rem oving the equipment from th e aircraft in staJlutio n. FLS might al so include software 10 / 28 / 10 AC20-l 70 loaded into a line replaceable unit (LRU) or hardware component at a repair station or shop.

FLS can r efer to either exec uta ble co de or data, such as a database. When seeki ng approval to u se FLS, you should cons id er the following: ( 1) FLS should meet t he objectives and guidan ce of RT CA/0 O-178B or other acceptable means of compliance, as agreed to between the applicant and your responsible ACO.

(2) The FLS sho uld be loaded on the target computer and hard wa re configuration that the software was verified on during D0-178B on-target verification testing.

(3) A means must ex ist to ensure that the FLS is loaded into the proper IMA configuration approved for that aircraft. See § 21.3 1. See Chapter 5 for more in fonn ation on configuration management.

(4) lfredundant functions of the IMA system are field loadable, the applicant should ensure that they have the sa me softw are configuration. unle ss intermixing of different software confi&rurations is s up ported by the safety assessment and approved for the aircraft configuration and type de sign.

(5) The appli ca nt should have a process to assure that the software lo aded is the software approved and that it hasn't been com 1ptcd - for example, verification wit h a cyc li c re dun dancy or other data transfer integrity check. Diff erent data integrity algorithms give different assurances that the data transfer is co rrect. Ensure that the algorithm used is commensurate with the integrity required for the software level of the data being l. oa ded.

(6) lf the applicant proposes mor e thai1 one medium for l oa ding the FLS, such as a diskette, ma ss sto rage device or com p act disc, loading from each medium sh ould comply witit the guidance in this sect ion.

(7) The applicant sh ou ld demonstrate th at the airborne equipm ent software part numbers can be verified wi th onb oa rd equipment, carry -o n equipment, an automated co nfiguration man agement sc he me , or ot her appropriate means.

(8) Loading protection mechanisms should be implemented to inhibit loading FLS during flight. The reliability of these m ec ha ni sms should be co mmens ura te with the failure condition associated with the inadvertent loading of software during flight.

Note: Please refer to AC l 20-76A, Guidelines.for the Cer tification, Airworthiness, and Operational Approl'Q/ of ElccLron ic Flight Bag Computing Devices, fo r guidance that pertains to loadable IMA software compone nt s that implement an Electronic Fl i ght B ag fun ction.

b. FLS jnstallation documents should s pecify the foll ow ing element s: (1) A ircraft and hardware applicability and intenni xa bility allowances for redundant systems that l oad software.

11/21/2013 AC 20-170, Chg. 1 (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 10/28/10 AC20-170 req uir ement when an automated con fi guration management system scheme tracks and protects the IMA system configuration by ensuring hard ware co mp onents are prop erly located.

f. All hardware components that support functjons approved by a TSO should have a phy sical TSO nameplate. However, you may use el ec tr onic m eans instead of verify ing nameplates on each hardware com ponent, if aU required info rm ation is available electronically.

Electron ic identification does not re pla ce hardware a nd software co nformity inspections that determine the components are pr od uc ed in conformity to type design.

g. Order 8150.1 (see the most current ve rsion) provides additi ona l information on TSO part marking.

7-4. Aircraft System Lightning and HIRF Protection.

a. When you are showing compliance with aircraft lightning and HIRF protection regulations, you must demonstrate that the functi ons performed by electrical and electronic systems, whose failure could prevent continued safe flight and landing, are not adversely affected when exposed to lightning and HIRF. See§§ 23. 1308, 25.1316, 25. 13 1 7, 27.1317, and 29. 131 7. The compliance demonstration for these systems should consider the performance of the integrated system, not only the eq ui pme 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 configurati on that wi11 be installed on the aircraft.

These lightning and HIRF system test configurations are typica11y more complex than those u sed for TSO compliance or equipment qualification. Guidance fo r compl iance is in AC 20 -1 36A, Protection of Aircraft Electrical/Electronic Systems Against the lndirect Effects of Lightning, and AC 20-158, The CerNfication of Aircraft Electrical and Electronic Systems.for Operation in the High-Intensity Radiated Fields (HJRFJ Environment.

b. For systems that perfom1 functions wh ose fa ilure would sign ificantly reduce the capabi lity of the a ir craft or the abi lity of the fli ght cr ew to respo nd to an adverse operating condition, the compliance demonstrati on may be based on li ghtning and HlRF tests performed on individual elements of equipment. RTCA/DO-l60F tests sa t isfy these rcqujrements.

c. Electromagnetic com patibility (EMC) between the I MA system and other aircraft systems should be demonstrated wh en the IMA system is installed in the aircraft. RF emission tests, such as those in RTCA/DO- I 60F, Sect io n 2 l , should be performed on the IM A modules, equipment and systems to provide confidence that the [MA system does not produce unacceptable RF emjssions. However, the EMC demonstration to comply with regulations such as §§ 23.1431 , 25.143 J, and 29. 14 31 should be perfom1ed with th e IMA system and the other 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 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 syst em data transmission and reception and are distributed in nature - that is, not purel y intemaJ to the r MA ca binets or modules - the applicant and IMA de v eloper /sys tem integrator should follow the guidance provided in AC 20 156, Aviation Darabus Assurance, or u se another acceptable means.

10/28/10 AC 20-170 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 engine application, may combine many functions that were historically in funchonaJly and physica ll y separated systems. These IMA functions are made up of hardware and so ftware components, each of which may be authorized by TSO, either complete or incomplete. Additionally, hardware modules, cabinets, and racks that ho st th e IMA hardware modules may also be a uth orized by TSO.

b. TSO authorizations are allowed und er 14 CFR part 2 1, subpart 0. Your responsible ACO can explain how we evaluate and issue TSOAs and letters of TSO de sign approval (LODA) for aviation-related art i cle s.

c. TSOs associated with lMA systems are: (1) TSO-C153, which covers two types of hard ware used in lMA syste ms: generic hardw are modules and cabinets/racks that ho st hardware modules.

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

d. RTCNDO-297 does n ot specifically uddress TSO at 1 th01ized articles within an IMA system. This c hapt er offe rs yo u a way to obtain approval for I MA systems that contain hardware and/or softw are components authorized by TSO.

e. Due to the high integration, fun cti\mal TSO data packages fo r IMA systems are typica ll y developed in parallel with the TC / STC / ATC / ASTC effort. In the se cases, you sho uld not submit TSO data to the A CO for authorization until the TC / STC / A TC/ ASTC te sting for th e IMA sys tem is completed and the final IMA system configuration is established. Thi s will ensure thai- the IMA system meets all required TSO MPS. Alternati ve ly, comp lian ce data for TS O authorization and compliance data for the TC / STC /A TC / ASTC maybe be submitted to the ap propri ate FAA offices concurrently, such that the TSO authorization may be issued concurrently with the aircraft/engine certificate. Thi s alternative approach requires a high level of coordination between the re s pon sible FAA offices to ensure that issues that arise iD one ar ea do not affect th e other.

8-2. TSO-Cl53 Authorization for lMA Ha rd ware Co mp onents.

a. To o bt ain TSO-Cl 53 auth01i za tion, the applicant for TSO authorization must demon strate that the individual hardware com ponent s m eet the MPS and defined s ubs et of R TCNDO- l 60F environmental qualification requirements in TSO-C 153, as described in Appendix A. See§ 2 I .616(c). TSO-Cl 53 does not p rov i de eith er functional or insta11ation approval.

J 0/28/ ) 0 AC 20- 1 70 b. The applicant for an LMA Component Acceptance Letter ma y use TSO-C 153 authorizalion as compliance data to obtain IMA component acceptance for IMA hard ware components. See RTCA / DO -297, Table 4.

8~3. Functional TSO Authorization.

a. A functional TSO is a TSO with a defined aircraft functionality. For example, TSO C I06 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 hardware element it addresses does not ha ve system le ve l functionality. A functional TSO authorization is issued for a specific IMA syst em configuration, including hardwar e and software components, th at performs the function defined in the functional TSO MPS. lt is not s imply for the software component that is loaded into a TSO-C 1 53 authorized hardware 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 co mplete lMA system, th en that company ma y ap ply for fun ctional 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 authorization will ap pl y to the J MA system and not a s pe cific lMA component.

Note: Per§ 21.60 1(b)(S}, the manufacturer of an article is the '' per son 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 appl jcable, the appli ca nt for a TSO authorization must control the design and quality of the parts, processes, and serv ices lh at are provided by any supplier to that applicant for a TSO authorization. See§ 21.60l(b)(S).

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

d. It shou ld be noted that there will typically be multiple functional TSO authorizations that comprise the lMA system, and the lMA ~ystem will likely cont::iin functionality a nd features not addressed by any TSO. The overall functionality of the IMA system and the portions covered by TSOA versus TC, STC, ATC, or ASTC sho uld be carefu ll y documented and coordinated 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 ll ed need to comply with EQT requirements: 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 requirements lo obtain TS0-C153 authorization for the generic IMA hardware.

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

(3) Aircraft or engine installation EQT requirements. EQT procedures 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 und er the aircraft/engine certification program independent of the TSO authorizations.

Alternatively, certification credit at the aircraft or engine installati on level may be taken from the TSO authorizations, if app li cable at the insta ll ation level.

b. TSO-Cl53 was written specifica ll y to address how partial EQT compliance at the aircraft or engine installation level can take cred it from the EQT compliance from TSO-Cl53 authorization. EQT procedures that require tJ1 e test to be mn on the specific IMA system configuration ash will be in stall ed on the aircraft or engine should be accomplished during the aircraft or engine TC/ ATC/STC/ASTC program. TSO-C 1 53 and Appendix 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 hardware components which host that function.

d. An applicant for an IMA Component Acceptance Leiter may use the EQT compliance 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 accepted, 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. J MA Component TSO Part Marking.

a. Tf loadable software compone nt s are used with generic hardware modules 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 so ftware - with the functional TSO identification.

b. The generic hardware components autho ri zed by TSO-C 153 must be permanently marked as being authorized under that TSO, in addition to any electron ic identification. See § 21.607(d).

c. See paragraph 7-3 for electronic identification gu id ance.

10/28/10 AC 20-170 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 pre sence of a TSO authorization in no way removes or reduces your responsibilities as an applicant, which is to ensure that the installed [M A system - including any TSO authorized components - meets the appropriate aircraft nnd engiue regulations and the guidance in this AC.

b. functional TSOs, suc h as TSO- C 113. Airbome Mulapmpose Electronic Displays, do not normally cover integration with ot her aircraft functi ons or hardware /software components in the integrated rMA system. Each TSO MPS is normally written assuming thal it is a stand-al one function and that no integration requirements exist beyond integration into the aircraft. For this reason~additional work is likely to be r equ i red beyond the TSO authorizations when sh owing 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 /system integrator to fully integrated the TSO authorized lMA component 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. Th is demonsu·ation s hould include functional perfonnance , interoperability, aircraft-level and system-level safety assessments, environmental qualification, system integration test, flight-test, software and hardwar e assurance, etc., as required to show compl iance to the regulations.

b. The applicant may use TSO authorizations to support airworthiness assessment if you show tbat the TSO requirements apply 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 1 and 21.6 1 I.

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

This section identifies the major roles and responsibili ties for the TSO-Cl 53 app li cant, the functional TSO applicant, and the aircraft /e ngine appli cant when TSO authorized components are used . These lists are not all-inclusive. We enco ura ge all affected parties to coordinate with us throughout the entire IMA system development. See Appendix A for more guidance applicable to TSO-Cl 53 authorization.

AC 20-170 10/28/10 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 hardware 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 hard ware 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. lf special purpose test software is used for EQT , validate and control the configuration of the hardware elements and software components to ensure the validity of the testing.

(7) Subm it the data package (the inform at ion in TSO-CI 53 paragraph 5, including the MPS) to your responsible ACO for revi ew and issue of TSO authorization.

(8) Apply for changes to TSO-C153 elements as de sign c hang 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 according to the appropriate TSO MPS.

(3) Identify the usage domain in w lu ch th e TSO authorized IMA compo nent was shown to meet the TSO MPS. lf the envfronment in which the component verification was conducted is not exact ly the same as the usage domain of the completed IM A system, then you should perfonn analysis and/or testing to demonstrate those differences do not affect the use of the IMA component witl1in the intended usage domain.

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

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 requirements that are fully met, partially met, or not met at all. This includes any partial compliance to RTCA/DO-178B for software, RTCNDO- 254 for CEH, and RTC A/ DO- l 60F for EQT.

(6) I dentify 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 articles. You should contact your responsible ACO if you have any questions 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 deviations. This additional functionality may be classified 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 standards. 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 t es t software is used for environmental qualification, you should 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 mor e information.

( l 0) Submit the data package required by the functional TSO to the responsible ACO fo r 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 holders of the design change.

c. Applicant Roles and Responsibilities.

(I) Develop and s ubmit a Project-Specific Certification Plan (PSCP) for the fMA system to the responsible ACO for approval.

(a) We recommend that you include a detailed co nfonnity 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 clearly 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.

J 0/ 28/1 0 AC 20-170 (c) The PSCP should address integration and approval of a ll components of the IMA system (including all hardware elements and software components).

(2) Define aircraft system and performance requirements.

(3) Perfom, aircraft-level safety assessment per RTC A/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 accomplished 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) Devel op 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 el ec tronic 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, subsection 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 fun ctional 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 fo r approval. The preliminary functional hazard analysis and preliminary system safety analysis should be submitt ed before finalizing the software, CEH, and SEH levels and the IMA architect ur e.

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

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

L0 /28/ 10 AC 20-170 ( 15) Evaluate and document changes lo IMA system and elements pe r§ 21.93. (See RT CA / D0- 297, subsection 4.6.)

( 16) Ens ur e that aircraft design features address safoty (See RTC A/D0 -297, subsection 3.3.)

I 0/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 environmental 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 functional TSO authorization.

Table 1-1 . RT A/DO-160F Environmental Qualification R eq uirements.

RTCA/ DO -160 RTC / DO-l60F Required for Required for Section Section Title TSO-C l53 Functional TSO # 4 Temperature and Altitude Nol tested Yes Temperature 4 Temperature and Altitude Ye Yes T 0- 153 quali ficati n Altitude data may be u ed by imilarity 5 Temperature Variati n Not tested Yes ------ >-- - 6 Humidity Yes Yes, TSO-C 15 qualificati n data may be u ed b similarity t tested 7 perational Shock and Crash Yes afety - Operati nal Shock y .

7 Operational Sh Yes, TSO-C 153 qualification Safety - Crash data may be u ed by similarity Yes plosion-pro fne Ye if appropriate Yes, TSO-Cl 53 qualification data may be u ed by similarity l O Waterproofness Yes, if appropriate Yes, TSO 153 qua li fication data may be u cd by similarity 1 l Fluid Susceptibility Ye if appropriate es TSO-Cl53 qualification data may be u ed by imilarity 12 and and Dust Yes, if appropri a le Yes, TSO- Cl 53 qualification data may be u ed by similarity 13 Fungus Resi tance Yes if appropriat Yes TSO-Cl53 qualification data may be u ed by similarity A-1 10/ 20 / l0 Appendix A RTCA / DO-160F RTCA/DO-160F Required for Required for Section Section itle TSO-C153 Functional TSO #

-

]4 Salt Spray Ye . if appropriate 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 Ye Yes, TSO- 153 qualification [nputs data may b u ed by similarity 19 Induced Signal Su ceptibility Notte ted Yes - 20 Radio Frequency usceptibility N t tested Yes 21 Emissions of Radio Frequency Not tested Yes Energy 22 Lightning Indu ed Transient Not tested Yes Su ceptibility ._ 23 Lightning Direc Effects Not tested Yes Icing 24 Ys Yes, TSO-Cl 53 qualification data may be used by similarity 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 specified for lh e 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 10 /20/ 10 Appendix A TC /STC/ ATC / ASTC, the hardware module urra11g ement should represent the expected worst case temperature conditions. Alternately, applicants for the fun ctional TSO or for aircraft/engine certification may perform engineering analysis, using va lidated models, of the the rmal characteristics of the expected cabinet or rack and module configuration variations to determine temperature test parameters that exceed the worst-case expected temperature conditions. These temperature test parameters could be used instead of the sta nda rd RTC A/ DO-160F, Sections 4 and 5, temperature conditions.

b. EQT for operational shock (RTCA/DO-160F, Section 7) and vibration (RTCA/DO-160F, Section 8). Perform these with all cabinet/rack module posi ti ons occupied in the har dwar e con.figuration s pe cified for the functional TSO or TC /STC/ ATC/ ASTC installation. Alternately, you could perform an engineering analysis, using validated models, of the cha racteristics of the expected ca binet or rack and module co n. figurations to determine vi bration and operational shock test parameters that exceed the worst expect ed conditions. These test parameters could be u se-d instead of the standard RT CA /DO-l60F , Sections 7 and 8 conJitions.

c. EQT for induced transients {RTCA/DO-160F, Section 19), radio frequency {RF) susceptibility ( RT CA/DO-160F, Section 20), RF e mis sions (RTCA/DO-160F, Section 21 ), and lightning induced transients (RTCA/DO-160P, Section 22). These are mo st appropriately performed with the functional hardware and so ftware in the I MA system. This is becau se the response of the system may be highl y dependent on the functional software and hardware.

Therefore, p erform these E QT s as part of the fun c ti onal TSO comp li ance or as part of the TC /STC/ATC/ASTC environmental qualifica ti on.

d. EQT fo r lightning and HlRF protection. Perfom1 these with the hardware elements and software com po n en ts loaded in the configuration specified for the applicable aircraft, per the lightning regulations, ACs, and the HIRF policy. The interf ace wiring and connected equipment should repre se nt the wiring and connected equipment installed in the aircraft.

4. You may u se EQT performed for a single fun ct ional T SO authorization or aircraft T C/STC/A TC /ASTC to support other app li cations for functi onal TSO s or aircra ft TC /STC/ATC/ ASTCs with similar configurations. A TSO applicant m ay u se similarity assessment and worst-case test conditions Lo minimize the EQT required fo r subsequent functional TSO applications or aircraft TC /STC/A TC / ASTC. Your use of the environmental qualification data should be accompanied by a rational engineering analysis of the differences between hardware and software configura ti on used during the o ri ginal environmental tests a11d the propo sed new configuration. The engineering analysis may consider worst-case environmental limits devel ope d above.

5. The functional T SO qu alification data sheet should state exp li citly the RTCA/DO-l 60F test categories and tests performed in the functional TSO confi guration and the test categories and tests perfom1ed in the T SO-C l 53 configuration. Include this in fo rmation in the installation instructions.

A-3 10/20/10 Appendix A 6. Hardware m od ules and software components providing a fun ction that lacks an applicable fun ct ional TSO mu st meet the TC/ST C/ ATC/ ASTC environmental requirements. See § 2 1 .3 1.

7. You must evaluate all hardware elements before installation lo ens ur e that the TC / STC / A TC / ASTC environmental requireme nt s have bee n satisfied. See § 21.31.

A-4 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 fo ll owed pre isel y. It is imp rtant however that all the information be presen t, in ome fo rm in th e letter.

Page l ofx AME COMP Y ADDR E OMPANY C ONTA CT INFORMATION D ate f application Unique identifier ]MA omponent Acceptance Cover LeUer General lnformation lMA comp nent name: T MA component t op l eve l identification: (Must uniquely identi fy the componenz, including anv revision or modification leve l. ) ame and c ntact information of company that develope the I MA component different than the applicant for the IMA mponent Ac· ptance Letter): Contact in ormation: (List the name(s) o[engin eri 11 g and/or managerial 1 aff 'to 1 , vlzich the FAA and other companies involved in the u c a11d po sible {1.1t11r reu e o[Lhis component may correspond. 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 pli cation for lM omponent accep ta nce 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 id en tification of [MA system in which the I MA c mponent will be used for initial acceptance :- -- --- -- - -- -------------------- B-1 10/20 /1 0 Appendix B Name and address of IMA system developer/integrator (if different than the lMA component 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 re fe rr ed lo as tile "u sage domain. " This i1lormation may l'ary widely bas ed on the type of co mp one nt. b!( ormation about hardware components. such as the ir being install ed in a rotorcra/t or in an unpressurized location of the air crafi str ucture, will be diff erent than if the component is a software operating s ys tem. For hardware components. this description should be adequate to estimate the environmelllal qualification testing levels.for RTCAIDO-160F compliance for the initial installation.

Tllis section informs the FAA, as well as any potemial.future re-users of the ac ce pted component, how the IMA co mponent is being usedjor ils initial acceptance and what might n eed to be re examin ed during any future reus e.

inf ormation may be at a high level, with more detailed i1?formation contained in the IMA Component Acceplance Leiter data sheet.

lnformation Re garding Partitions (if any) and Assurance Levels within the IMA Co mponent Describe all the various software partiJiu11s (if any) within the !MA compone nt . 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 hardw ar e components.for which you ar e seeki ng acceptancefor compliance to RTCAIDO-254, ident!/y u.nd describe each component along with the design assurance l eve l (DAL) of each co mp onent and a justification of why this DAL is appropriate. If there are multiple DALs 0 11 u single CEHISEH devic e, then address eac h of tho se DALs. Include il!fonnalion r eg arding the sep aration of the multiple DALs on a single device.

This section informs the FAA. as well as any potential.future re-users of the accepted component, of the various assuran ce levels (both hardware and soflll'are) wit/,;11 the £MA component and what might n eed to be re-examined during any f uture reus e.

information may be at a high level, with more de/ail ed informalion contained in the IMA Co mp onent Acceptance Letter data sheel.

Statement of Full or Partial Compliance to Industry Standards State for which indust,y standards RT CAIDO-1788.for airborne software, RT CAI DO -254.for CE H, RTCAIDO- 160F for EQT) ac ce ptan 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 nc e Cover Letter does not need to ex plain. in detail. an y partial compliance to Lh ese standards--inc/ude that detailed informatio11 in t.h e IM A cmnponent acceptance data sheet. The stat ement of /LIii or par tial complian ce in the IMA Component Acceprance Cover Letter is on(v 8- 2 10/20/10 Appendix B an indicator to the FAA and any future re-user of this componenL that additional activity is needed to show full complian ce at the time of installation approval of the IMA system.

lfyou seek any compliance.for SEHfor the /MA component ac ce ptance. this sec tion should document that fact. In cl ud e the compliance data or refere 11 ces to wher e th e compliance data ma y be found in the /MA compo nent acceptance data sheer.

ff you seek compliance to any ot her tec/,nical discipline, bes id es t/zose listed above with i/zis IMA component acceptance. do cument it here. Include a high-level discussion of the requirements for which yo u seek compliance, and where rlz e de/ailed requirements are docum e nt e d. Include mor e detailed i1?formation about the co mpliance dala in the IMA Component Acceptance Le tter dala shee t.

Configuration Information of IMA component Include eno ugh if!formation to specf/y ex ac tl y the baseline co nfiguration of the IMA component being accepted, including the development and verification environment. In cl ud e only a list of the documents names, numbers and revision l eve ls. All other i,!(ormation con ce rning the configuration identification may be incl ud ed in the IMA Component Acceptan ce Letter data sheet.

This section mak es clear the configuratfon of the IMA compone nt being accepted , If any oftlze do cume 111 s identified in this section are revised, then write a n ew !MA component acceptance letter.

Statement of compliance to the applicable requirements Stare in the IMA Component Acceptance lette r that t/z e sig nato ri es al/est that the /MA component m eets all the applicable requirements defined in th<! IMA Component Ac cep 1an ce L etter. A sa mpl e statemenr is shown beloll': We , the undersigned, attest that we. lo the best of our ability, have found this IMA compone nt to be compliant with the applicable requirements as documented within this IMA Component Acceptance Letter.

Signatures - AppHca-nt for the IMA Component Acceptance Letter This seclivn should s how the s ignatures of specific company individuals. p er paragraph 4-3 of this AC. There should also be a print ed version of the signing individual's nam e and title. Each sig nature sh ould include 1h e dat e on whi ch th ey signed th e lMA Component Acceprance Cover Letter, as well as an indication of which t ec hnical discipline to which that signature appli es. The IMA component acceptance le tt er should be signed by the appropriate p ersons before submitting the o rig ina l, along with the IMA Component Acceptance lett er data she et, to the FAA.

B- 3 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 Transport ation Federal Aviation Admin ist ration 1n Reply Refer To: (FAA correspondence number) (Date of Letter) (Name and address of recipient) Subject: Integrated Modu lar Avionics (lMA) Component Accep ta nce 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, Int eg rated Modular Avionics (IMA) Development Guidance and Certffication Considerations.

with regards to (IMA component name), (}MA co111po11e11t top level id entification, 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 ba se d on the usage domain, restrictions, partial compliance, assurance levels and other such informat ion as documented in the attached IMA Component Acceptance Cover Letter and its IMA Component Acceptance Letter data sheet.

2. This IMA Component Acceptance Le tt er is only applicable to (]MA component name and top level identification. including revision / evC'/). This Acceptance Letter is not transferable to an updated version of (!MA component nam e). A new FAA IMA Component Acceptance Letter sh ou ld be requested fo r the updated component, if one is desired.

3. (Company name) should report to the (FAA office issuing this IMA Component Acceptance Letter) any fai lure, 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 Letter can be issued.

C-1 I 0/20/ 10 Appendix C 4. (Company name) should coordinate wit h and supply any required data to any future or concurrent user of the accepted LMA component, s uch lhat th e user is able to show full compliance to AC 20- 170 and RT CN D0- 297 for that future or concurrent use.

The holder of a v aJid FAA !MA Component Acceptnncc Letter may use it as proof of acceptance by the FAA, as defined in the L MA Component Acceptance Letter including the TMA component acceptance data sheet, for the purpose of fu ture or concurrent u se of the accepted IMA component. The actual compliance data used in obtaining the IMA Co mp one nt Acceptance Letter does not need to be re-submitted to the FAA, un less the FAA has concerns that cannot be answered by an y other means except by re-examining the original I MA component acceptan ce data.

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

C-2 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 of Aircrafi Powerplant Instruments (Displays).

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

3) AC 20-136A, Protection of Aircrqft Electrical/Electronic Systems Against the Indirecl Effects c!f Lightning.

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 of Electronic 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 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 of Electronic Checklists.

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

3. The following FAA policy statements are available from the FAA website at http: /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 of Compliance.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 I 00-2001-004, Guidance/or Rei-iewing Cert/ficmion Plans to Address lluman Factors/or Certification of Part 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) RTC A/D0-257 A, Afinimum Performance Standardsfiir the Depiction of Navigational J1!f'ormation on Electronic Maps.

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

D-2 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 of Civil Aircraft and Systems.

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

D-3 I 0/ 20 / 10 Appendix E Appendix E Glossary Acceptance FAA acknowledgement that the module, application, or system meets defined requirements.

Aircraft function Capability of the aircraft provided by the hardware and software of the systems on the aircraft.

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

Applicant Person or organization seeking approval from the FAA.

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

Application-speci fie Hardware dedicated lo one application.

hardware Approval Act or instance of giving fom1a l or official acknowledgement of compl iance with regulations.

A ss umptions Statements, principles, and/or premises offered without proof .

Assurance Planned and systematic act i ons necessary to provide adequate confidence and eviden ce th at a product or process satisfies given requirements.

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

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

E-1 10/ 20 / 10 Appendix E Cabinet Physical package containing one or more IMA components or modules.

Provides partial protection from environmental effects (shielding).

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

Certification Legal recognition by the FAA that a product, service, organization, or person complies with the requirements. Certification comprises the activity of technica ll y 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 standards 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.

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

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

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

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

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

Devi ce or group of devices that perfonns a data processing function.

Computer Configuration control See "c hange control.'' Configuration Process of designating the configuration items in a system and identification recording their characteristics.

E-2 10 / 20 / 10 Appendix E Configuration index Approved documentation that defines a configuration item.

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

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

Con ft gurati on Discipline applying technical and administrative direction and management surveillance to (a) id entify and record the functional and physical characteristics of a configuration item, (b) co nt rol changes to those characteristics, and (c) record and report change control processing and implementation status.

Criticality Indication of th~ hazard level of a funcL ion, hardwar e, software, (and so forth), addressing a bn ormal behavior of this item alone, or with external events.

Custom micro-coded Component that in cludes app li cation specific integrated circuits component (ASIC), programmable logic devices (PLO), field programmable gate arrays (FPGA) and oth er similar electronic components used in the design of aircraft systems and equipment.

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

Feature (of an article An aircraft or engi ne function that is not identified in a functional TSO authorized by 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 specifica ll y mention that functionality. Features are not approved by the functional TSO authorization. They shou ld be approved during the aircraft or engine certification program.

Aircraft equipment architecture consisti ng of primarily line replaceable Federated system units that perform a specific function, connected by dedicated interfaces or aircraft system data buses.

Function Named capability th at performs a specific task.

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

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

E -3 I 0/20/10 Appendix E Functional TSO Applicant seeking functional TSO authorization.

applicant Guidelines Recommended procedures for complying with regulations.

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

Hardware element Eleme nt 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.

Hardware/so fiware Embedding the soHware into the target computer.

integration Integrated modular A letter, signed by the FAA, which is composed of three parts; the I MA avionics Component Component Acceptance Cover Letter, the IMA Component Acceptance Acceptance Letter Letter data she et and the signed ACceptance Letter. The holder of a va lid lMA Component Acceptance Letter may submit this letter as proof of compliance to the applicable requirements, as defined by th e lMA Component Acceptance Cover Letter and I MA Component Acceptance Letter data sheet, to the FAA on a future or concun-ent certification program for that IMA component.

Integrated modular Shared set of flexible, reusable, and interoperable hardware and avionics software resources that, when integrated, form a platform that pro vides services. These services are designed and verified to a defined set of safety and perfonnance requirement s, to host applications perfonning aircraft functions.

IMA developer/system Company or organiza ti on responsible for TMA system integration. An integrator l MA system integrator may or ma y not aJso develop most of the IMA hardware or software components.

Cncremental Process for obt::ii ning credit toward approval and certification by acceptance accepting or finding that an IMA module, application, and/or off aircraft IMA system comp li es with specific requirements. Credit granted for individual tasks contributes to the overall certification goal.

10/20/ 10 Appendix E Integration Gathering a number of separate components to fonn a sing le implementat1on.

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

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

Module Co mp onent or collection 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.

Non-configured A generic TMA hardware component that has not been configured (such hardware component 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.

Non-TSO function 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 n ot 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" frequencies of a communication or navigation radio, facility infonnation (such as, airport frequencies, runways, 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, Open architecture upgrading and swapping components with minimal effect on the remaining system.

E-5 10/ 20 / 10 Appendix E Operating system 1) Same as executive sotlware.

2) Software kernel that services only the underlying hardware platfonn.

3) Software that directs the operations of a com puter . resource al location and data management, controlling and sc heduling the exec ution of computer hosted applications, and mana ging memory, storage, inpu t/output, and communication resources.

Operational capability Function or group of functions that provides an aircra ft capability visible to the flight crew or oth er per so nn e l.

Partition Allocation of resources who se properties are guaranteed and protected by the platform from adverse interaction or influences from ou tside the partition.

Pa1iitioning Architectural technique to provide sepa ration and independence of functions or app li cat ions. To ens ure that only intended coupling occurs.

Robust configuration Capable of pe1forming its intended function without failure under a management wide range of co ndition s.

Pl atform M od ule or group of modules, including core software, th at man ages reso ur ces s upp ort at least one application.

Resource Any pr ocessor. memory. software, data. or object or component used by a processor, J MA platform, core soft ware, or application. A resource may be shared by multiple applicat ions or ded i ca ted to a specific application. A resour ce may be ph ysical (a hardware device) or logical (a piece of info nnati on).

Re-use Sub se quent u se o f unaffected, pr ev iously approved system hardware or software assurance data.

Robust Partitioning Partitioning that provides demonstrable means of cont ainment protection a nd enforcement of the partition boundaries.

Attribute of dependability in non-occurren ce of, or recovery from, Safety failures and o ther co nditions that could cause unacceptable, operational eve nts of an airc raft, en gine or co mp onent.

E -6 10 /20/ lO Appendix E Simple electronic A subset of simple hardware item; a custom micro-coded component hardware with a comprehensive combination of deterministic tests and analyses appropriate to tbe desi &ll1 assurance leve l. Ensures correct functional performance under a ll foreseeable operating conditions, with no anomalous behavior.

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

Software Computer programs and possibly, associated documentation and data of a computer system.

Software change Modification in source code, object code, executable o bj ect code, or its related documentation from its previous baseline.

Software integration Combining code components.

Software life cycle l) An ordered collection of processes determined by an organization to produce a software product.

2) Period chime th at begins with decision to produce or modify a software product and ends when product is retired from service.

Software product Set of comput er 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 it s associated software life cyc le data.

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

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

Specified arrangement or interrelation of parts to form a whole.

Structure System Collection of hardware and software components organized to accomplish a specific function or se t of functions.

E-7 10 /20 / 10 Appendix E System architecmre Lnter faces and str ucture of the hai·dware and software selected to implement the system requirements.

System safety 1) Systematic, comprehensive evaluation of the proposed system to assessment show that relevant safety-related requirements wiU be satisfied.

2) A systematic. comprehensive evaluation of the impl emented syst em to show th at the relevant safety-rel ated requirements are sat isfied.

Ta sk I The activity associated wilh showing compliance to RTCA/D0-297 , subsection 4.2, for IMA modules.

Ta sk2 The activity associated with showi ng compliance to RTCA/D0-297, subsection 4.3 , fo r IMA applications.

Task 3 The activity associated with showing co mpliance to RTCA/D0- 297, subsection 4.4, for an IMA system.

Task4 The activity associated wit h showing com plian ce to RTCA/D0-297 , s ub section 4.5, for an IMA installation into an aircraft or engine.

Technical standard Legat recognition by the FAA that a sys tem, equipment, or part order authorization satisfies the TSO requirements an<l minimum performance specification, and FAA authorization to manufacture that item.

Unintended function Function visible at tJ,e aircraft l eve l and is neither inlended nor a predicted (foreseeable) fault condition in the preliminary system safety assessment .

Usage domain Declared set of characteristics for w hi ch it can be shown that: I) Module complies with its functional , pe rformance, and sa fety requirements as defined in the module requirements specification.

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

3) Module perf orma nce is full y characterized, including fault and error handling, failure modes, and behavior during adverse environmental effects.

Validati on Determin ing that requirements are both co rr ec t and complete. System deve l opme nt may use requirements and derived requirements in sys tem validation.

Verification 1) Evaluation of a requirements implementati on to d etenn ine that they were met.

2) Evaluation of process results to ensure corre ct ne ss and consistency of inputs and standards provided.

E-8 10/20/10 Appendix F Appendix F Acronyms AC Advisory circular ACO Aircraft certification office AFCB Arc fault circuit breaker AFM Aircraft flight manual AFMS Aircraft flight ma nual supplement ARP Aerospace recommended practice ASJC Application specific integrated circuit ASTC Amended suppleme ntal type certificate ATC Amended type certificate CC D Cursor control devjce CEH Complex electronic hardware CFR Code of FederaJ Regulations CRM Crew resource management EQT Environmental qualification test(s} EMC Electroma&,netic Compa tibility EWIS Electrical wiring interconnection system FAA Federal Aviation Adrnirustration FLS Field-loadable software FMS Flight management system FPGA Field programmable gate array GPS Global posilio ning system HlRF High intensity radiated field 10/20/10 Appendix F IMA Integrated modular avionics LODA Letter(s) of Technical Standard Order (T SO) Design Approval Line replaceable unit LRU Multi-function control and display unit MCDU MMEL Master minimum equipment list Minimum petfonnance standard MPS ODA Organization Designation Authorization PLD Programmable logi c device PSCP Project specific certification plan Radio Frequency RF RSC Reusable software component RTCA Formerly, the Radio Technical Commission for Aeronautics SAE lntemational. Fonnerly, The Society of Automotive Engineers SAE SEH Simple electronic hardware STC Supplemental type certificate TC Type certificate TCAS Traffic alert and collision avoidance system Technical standard order TSO TSOA Technical standard order authorization F-2 10 / 20/I0 Appendix G Appendix G Partial List of Functional TSOs Below is a partial li st 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 multiple 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 DATE TITLE TSO-C2d 6/14/89 Airspeed Jnstrume11ts (Using Electronic Sensing) TSO-C4c 4/ 14 /89 Bank and Pitch Instruments TSO-C9c Automatic Pilots 9/ 15 /60 TSO-Cl Ob 9/1/59 Altimeter, Pressure Actuated, Sensitive Type TSO- C52b 5/30/95 Flight Director Equipment TSO-C92c 3/19/96 Airborne Ground Proximity Warning Equipment TSO-C93 11/26/76 Airborne Interim Standard Microwave Landing System Converter Equipment TSO-CI O I 2/19/87 Over Speed Warning Instruments TSO- Cl 04 6/22/82 Microwave landing System (MLS) Airborne Receiving Equipment Optional Display Equipment.for Weather and Ground Mapping TSO-C I 05 6/ 13 /84 Radar Indicators TSO-C106 1/15/ 88 Air Data Comput er TSO-Cl I Oa 10/26/88 Airborne Passive Thunderstorm Detection Equipment TSO-C 1 15b 9/30/94 Airborne Area Navigation Equipment Using Multi-Sensor inputs TSO-Cl 1 7a 8/1/96 Airbome Windshear Warning and Escape Guidance Systems/or Transport Airplanes TSO-C 118 8/5/88 Traffic Aler/ and Collision Avoidance System (TCAS) Alrbotne Equipment, TCAS I Traffic Aler/ and Collision Al'oidance System (TCAS) Airborne TSO-Cl 19a 4/9/90 G- 1 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 I 46c 5/9/08 Stand-Alone Ai rbome 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 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 ARP 4754 Reference Corresponding ARP Page#/ Para.# (Technical Subject of Discussion) 4754A Reference /Para.# of Technical Subject of Discussion 3 I 1.5 [7] ARP4754A ARP 4754 20 / 3.1 ARP4754 ARP4754A 56 I 4.5.7.d ARP4754A ARP 4754 63 15.1 ARP 4754A 15.1 ARP 4754 (Safety Assessment) ARP 4754A / 5.1.1 65 I 5.1.5.I Section 6.1 (functional Hazard Assessment) 65 / 5.1.5.2.e Section 6.2 (Preliminary System Safety Assessment) ARP 4754A / 5.1.2 66 / 5:J .5.3.1 Section 6.3 (System Safety Assessment) ARP 4754A / 5.1.3 6615.1.5.4 ARP 4754 (Common Cause Analysis) ARP 4754A / 5.1.4 ARP 4754A I 5.4 7215.3 ARP 4754 (Validation Process) 7315.4 ARP 4754 (Verification Process) ARP 4754A / 5.5 7515.5 ARP 4 754 (Configuration Management Process) ARP 4754A / 5.6 77 15.6 ARP 4754 (Quality Assurance Process) ARP 4754A I 5.7 77 15.6 - Note ARP4754A ARP 4754 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