AC 20-153A

Historical

Advisory circular · Acceptance of Aeronautical Data Processes and Associated Databases

A newer version is currentThis is a historical version. AC 20-153B is the version in force, approved April 19, 2016.
Approved
September 20, 2010
Last reviewed
September 21, 2010
Cancels
AC20-153
Cancelled by
AC20-153B
Family
AC 20-153 · 3 versions
Revision
A
14 CFR parts
Unknown Part

Guidance, not mandatory unless a rule or AD requires it. DRS record last changed November 22, 2025.

Advisory Circular

Subject: Acceptance of Aeronautical Data Processes and Associated Databases Date: 09/20/10 Initiated by: AIR-130 AC No: 20-153A

1. Purpose of this Advisory Circular (AC).

a. This AC will help you to:

(1) Obtain a Letter of Acceptance (LOA) from the Federal Aviation Administration (FAA) that acknowledges compliance with this AC regarding aeronautical data processing.

(2) Evaluate whether data processes comply with the requirements of RTCA, Inc.

document DO-200A, Standards for Processing Aeronautical Data.

(3) Define the data quality requirements (DQRs) for aeronautical data when obtaining airworthiness approval of new equipment or installations where the function of the equipment is dependent on an updateable database.

(4) Understand how an organization adheres to the data preparation and data transmission criteria applicable to the functions performed by that aeronautical data chain link or participant.

b. This AC is not mandatory and does not constitute a regulation. In it, we describe a means, though it is not the only means, to obtain a LOA that acknowledges compliance with this AC.

However, if you use the means described herein, you must follow it in all respects.

2. To Whom this AC Applies. We wrote this AC for aeronautical data service providers, original equipment manufacturers, avionics manufacturers, and operators.

3. Summary of Major Changes and Scope.

a. AC 20-153 only applied to navigation databases. This AC applies to other types of aeronautical data, such as terrain, obstacle, and airport map databases.

b. This AC provides a means for manufacturers of existing systems with RTCA/DO-200 compliance to obtain a LOA.

c. The standards used in this AC do not apply to Contracting States, or entities acting on behalf of Contracting States, publishing data as addressed in International Civil Aviation Organization (ICAO) Annex 15.

d. This AC does not apply to software programming pins (for option selectable software), configuration files, aircraft personality modules, registries, or other lookup tables used by airborne systems and equipment to adapt equipment to the aircraft.

e. This AC does not address airborne system databases that are used by an airborne system and approved as part of the type design of the aircraft or engine. Examples of airborne system databases include engine power settings (takeoff, climb, Maximum Continuous Thrust (MCT), Cruise) and airfield performance data (takeoff distance, V speeds).

f. Appendix 1 provides sample LOA applications. Appendix 2 provides sample FAA LOAs.

Appendix 3 provides an objectives matrix.

4. Cancellation. AC 20-153, issued on July 08, 2005, is cancelled. However, LOAs issued under AC 20-153 remain effective until they are superseded, surrendered, withdrawn by the holder, or terminated by the FAA.

5. Approvals Based on RTCA/DO-200A Compliance.

a. RTCA/DO-200A is the standard used to develop, support implementation, and assess change of data processing quality assurance and data quality management. Implementing a process complying with the requirements of RTCA/DO-200A provides a level of assurance that the data quality is maintained throughout all phases of the data handling process within an organization. Data quality is defined by several characteristics including accuracy, resolution, integrity (referred to as assurance level), timeliness, completeness, traceability and format. This includes the interface to a data supplier, receipt of the data, processing of the data, database distribution, and the interface to a customer. RTCA/DO-200A does not ensure the quality of Contracting State-originated data that is being addressed through other means such as an ICAO standard.

Note: The ultimate responsibility of ensuring that the data meets the quality for its intended application rests with the end-user of that data. This responsibility can be met by obtaining data from a supplier accredited against this standard by an appropriate organization. This does not alter the supplier’s responsibility for any functions performed on the data.

b. The intent of RTCA/DO-200A is to address the specific issues of the aeronautical data process by requiring organizations to have in place an acceptable quality management system (QMS) based on the requirements associated with the aeronautical data process.

RTCA/DO-200A, section 1.5.4 defines the basic concepts associated with the aeronautical data process, including the concepts used by suppliers, users, and the requirements for an aeronautical data chain. RTCA/DO-200A, section 1, Figures 1-1 and 1-2, depict two examples of data flow

3 in an aeronautical data chain for navigation and terrain applications. RTCA/DO-200A, section 2, contains the requirements for the aeronautical data process. RTCA/DO-200A, appendix B provides guidance on defining the DQRs; appendix C demonstrates compliance with the requirements contained in section 2. RTCA/DO-200A, section 3 details the specific objectives, procedures, and reports associated with auditing an aeronautical data process to demonstrate compliance with section 2.

c. The process of collecting this data begins at the governmental body level, where ICAO Contracting States around the world are responsible for compiling and transmitting the aeronautical data through its aeronautical information publication (AIP) in accordance with ICAO Annex 15 requirements. In the past, terrain data has not typically been considered AIP, and is not subject to the 28-day Aeronautical Information Regulation and Control (AIRAC) cycle. The latest edition of ICAO Annex 15, however, indicates AIP will include electronic terrain and obstacle data in accordance with the following coverage areas. Area 1 (entire territory of a state) and Area 4 (category II/III) data began to be available in November 2008.

Area 2 (terminal area) and Area 3 (aerodrome/heliport) data will begin to be available through AIP by November 2010 with additional data sets becoming available by November 2015.

Note: ICAO Contracting States are required to include the elements found in ICAO Annex 15, appendix 4, part 1 in its AIP. Contracting State AIP may include the elements recommended in ICAO Annex 15, appendix 4, part 2. Department of Defense (DOD) data may not be appropriate for aeronautical use, so we do not consider this data as AIP, but it may be considered as an official government source, if it is the only data source available.

d. The data service provider is an organization that collects the aeronautical data from the Contracting States or other sources and inputs the data into an electronic file as specified by the avionics manufacturer. For navigation data, this file has typically been processed into a standard format, defined by the Aeronautical Radio, Incorporated (ARINC) specification 424. For terrain, obstacle and airport map data this file has typically been defined by RTCA/DO-291A or by the ARINC specification 816. Other data interchange specifications and formats are allowed, as long as they meet the format requirements specified by the data customer (application provider, end-user, etc.).

e. The avionics manufacturer receives the aeronautical data file from the data service provider and loads that data into its ground-based processing software. This software is designed to run automated checks on the data, to customize the geographic area coverage and data content, and then compress or “pack” the data by changing the format into that specified for the target avionics. Once these steps have been accomplished, a navigation data file, or set of files, is created for each customer. The data is then sent to the customer, either electronically or on loadable media. If the data is sent electronically, the customer will have the means to transfer the data to loadable media or directly into the avionics system. The last activity of this process is the loading of the aeronautical data into the aircraft’s avionics system.

f. Navigation systems are designed to use navigation databases that are updated in accordance with the ICAO 28-day AIRAC cycle. Once loaded, the database information typically will not be changed until the beginning of the next AIRAC effective date. If a major change occurs or an error is detected within the 28-day cycle, the updated information may not be available to the automated system until the next cycle.

Note: As of Amendment 36, dated 01 April 2010, ICAO Annex 15 recommends obstacle and airport map data is distributed in the Contracting State’s AIP under the regulated AIRAC system.

6. Who needs to apply for a LOA?

a. This guidance is provided for all organizations within the aeronautical data chain except for an ICAO Contracting State (see paragraph 18 of this AC). This includes operators, data service providers, original equipment manufacturers, and avionics manufacturers that process aeronautical data. Organizations that comply with this AC may apply for a LOA for its aeronautical data process. The LOA identifies organizations within the aeronautical data chain that demonstrate acceptable data processes for applications that include navigation, terrain, obstacle, and airport map databases.

Note: For any Assurance Level 1 (critical) or 2 (essential) data that are not included in the Contracting State’s AIP, the origination of data must be validated by the data service provider (reference paragraph

14).

b. The LOA formally documents that a supplier’s databases are being produced pursuant to RTCA/DO-200A, or for some established systems, RTCA/DO-200 (see paragraph 19 of this AC). For those applications requiring database integrity (e.g., U.S. Area Navigation (RNAV) and Required Navigation Performance (RNP) Routes and terminal procedures, airport moving map displays, Terrain Awareness and Warning System (TAWS)), the LOA may be used as evidence of compliance with RTCA/DO-200A in support of application for operational approval or in support of a maintenance task per the instructions for continued airworthiness.

RTCA/DO-200A defines standards for processing and distributing data for aeronautical applications, such as navigation and flight planning.

7. Definitions.

a. Aeronautical database – An aeronautical database is any data that is stored electronically in a system that supports airborne aeronautical applications. An aeronautical database may be updated at regular intervals.

Note: In this AC, aeronautical databases will refer to aeronautical data only as defined below.

b. Aeronautical data – Data used for aeronautical applications such as navigation, flight planning, flight simulators, terrain awareness and other purposes, which comprises navigation data and terrain and obstacle data. However, this AC does not address databases for engine

5 power settings (takeoff, climb, MCT, cruise) or airfield performance data (takeoff distance, V speeds) and does not consider these types of data as aeronautical data as used in this AC.

c. Airport Map Database – Any navigation data stored electronically in a system supporting airport map applications. Airport map data is information intended to be used to assist the pilot to identify the aircraft's position with respect to items on the airport surface.

d. Data supplier – Organizations, not including the Contracting States, or entities acting on behalf of the Contracting State, that collect, process, or originate aeronautical data. Data service providers, avionics manufacturers and end operators may all act as data suppliers in the aeronautical data chain.

e. Navigation Database – Any navigation data stored electronically in a system supporting navigation applications. Navigation data is information intended to be used to assist the pilot to identify the aircraft's position with respect to flight plans, ground reference points and navaid fixes (such as VHF omni−directional radio ranges (VORs), nondirectional radio beacons (NDBs), etc.) as well as items some points on the airport surface.

f. Obstacle Database – Any data stored electronically in a system supporting obstacle applications. Obstacle data includes any natural or manmade fixed object which has vertical significance in relation to adjacent and surrounding features and which is considered as a potential hazard to the safe passage of aircraft.

g. Terrain Database – Any data stored electronically in a system supporting terrain applications. Terrain data includes the natural surface of the earth excluding man-made obstacles.

8. What is the Aeronautical Data Chain?

a. RTCA/DO-200A, section 1.5.4 describes the aeronautical data chain as a conceptual representation of the path aeronautical data takes from its creation to its end use. The aeronautical data chain is a series of interrelated links where each link provides a function that facilitates the origination, transmission and use of aeronautical data for a specific purpose.

Because an organization may perform one or all of the functions that comprise the aeronautical data chain, that organization may be responsible for data preparation and data transmission for more than one chain link. The organizations within the aeronautical data chain and the applicable paragraphs of this AC are the:

(1) Operator (RTCA/DO-200A: End-User) (paragraphs 11 and 12);

(2) Original equipment manufacturer (RTCA/DO-200A: Application Provider) (paragraphs 19 – 23);

(3) Avionics manufacturer (RTCA/DO-200A: Application Provider) (paragraphs 13, and 19 – 23);

(4) Data Service Provider (RTCA/DO-200A: Data Service Provider) (paragraph 13);

and

(5) Contracting State Aeronautical Information Service or Terrain Data Agency (paragraph 18).

b. With the exception of those organizations that operate data selection and packing tools covered under its data supplier’s Type 2 LOA, all other organizations that process data should comply with paragraph 13 of this AC and obtain a LOA.

c. Database production procedures of non-U.S. data suppliers should comply with RTCA/DO-200A (or EUROCAE ED-76) to the satisfaction of the data supplier/user as verified by the supplier’s civil aviation authority (CAA). The supplier’s approval may be considered acceptable and equivalent to the LOAs defined in this AC. The relevant foreign authority and its approval method (e.g., European Aviation Safety Agency (EASA) LOA or Production Organisation Approval) must be identified to customers of the data. The suitability of the supplier may then be evaluated as part of the operational approval (see appendix 2).

d. This AC is structured to accommodate the FAA acceptance of a link (organization) as compliant with RTCA/DO-200 or DO-200A. To separate the links in a chain and grant a LOA to an organization requires mutual agreement of the data requirements between a data supplier and a customer (represented by a pair of interlocking chain links). Data requirements provide the basis for the processes performed on the data. Figure 1 of this AC shows a conceptual layout of a typical aeronautical data chain.

Figure 1. Typical Aeronautical Data Chain

9. Types of FAA Data Supplier LOAs, Application Process, and LOA Maintenance.

a. Types of Data Suppliers. There are two types of data supplier acceptance letters.

Type 1 acceptance letters are based on generic data requirements agreed upon between the data supplier and the customer and are for data suppliers that are data service providers. Type 2 acceptance letters are based on requirements that ensure compatibility with particular systems or equipment and are for data suppliers that are avionics manufacturers/application integrators.

AIP/NOTAM (State) Data Service Provider OEM, Applicant for Aircraft Type Design Approval

(e.g., TC or STC) Avionics Manufacturer (Application Integrator) Data quality requirements Data quality requirements Data quality requirements Data Data Data Operator (End-User, Airline) Data quality requirements

7 Type 2 acceptance letters are intended to facilitate the operational approval process or approved maintenance program, and eliminate the operator’s need to re-evaluate compatibility if the data supplier has already assured compatibility. While RTCA/DO-200A applies to both types of acceptance letters, the Type 2 data suppliers have additional requirements to ensure the delivered database is compatible with the DQRs necessary to support the intended function approved for the target application.

(1) Type 1 LOA. A Type 1 LOA provides recognition of a data supplier’s compliance with RTCA/DO-200A with no identified compatibility with an aircraft system. A Type 1 LOA ensures the processes for producing the aeronautical data comply with this AC and the documented DQRs. This acceptance letter may be issued to data suppliers, operators, avionics manufacturers, or others. Guidance material regarding the application of RTCA/DO-200A to these organizations is provided in paragraph 13 of this AC. A Type 1 LOA does not address compatibility with intended functions or with particular avionic systems. A Type 1 LOA does not have to be associated with a specific certification project (such as a type certificate (TC), supplemental TC (STC) or technical standard order authorization (TSOA) or equipment type.

(2) Type 2 LOA.

(a) A Type 2 LOA provides recognition of a data supplier’s compliance with RTCA/DO-200A and the compatibility of its delivered data with particular avionic systems. A Type 2 LOA may be issued to a design approval holder (TC/STC/TSOA) or to a data supplier who can establish that its data requirements are identical to those defined by a design approval holder. Identicality is typically achieved by either establishing design equivalency or by a licensing agreement between the design approval holder and the entity seeking approval.

Guidance material for the application of RTCA/DO-200A to these entities is provided in paragraphs 13, and 19 – 23 of this AC.

(b) Because a Type 2 LOA recognizes compatibility with the DQRs necessary to support the intended function, the acceptance of a Type 2 data supplier must be associated with specific equipment. It may or may not coincide with the design approval of the equipment (such as a TC, STC or TSOA). Type 2 LOA letters identify the compatible equipment. Additionally, if an avionics company provides a data-packing tool to other participants in the data chain, the letter identifies that the process complies with RTCA/DO-200A subject to the use of the packing tool and any associated instructions.

(c) Many aircraft and avionics manufacturers have obtained approval for systems prior to the issuance of RTCA/DO-200A. For such systems, the DQRs for the avionics should have been identified prior to a data supplier obtaining a Type 2 LOA (see paragraphs 19 – 23 of this AC for guidance on requirements for existing systems). In lieu of identifying the DQRs, a statement of compliance to RTCA/DO-200 is acceptable, dependant upon adherence to the applicable terms and conditions of the Type 2 LOA that addresses these alternative means and verification that error reporting processes are in place and are being exercised effectively.

b. Application. A data supplier should submit an application for a LOA to the aircraft certification office (ACO) in the geographical area in which the data processing facility of the

8 applicant is located (see appendix 1, Sample application for an FAA LOA for the aeronautical data process). The application should include the following information:

(1) The name and address of the data supplier facility that will be covered by the LOA.

(2) A brief description of the type of FAA acceptance that will be sought; Type 1 LOA or Type 2 LOA. For a Type 2 LOA, the application must identify the compatible systems (make, model, series, and part number (hardware and software)). Since minor changes to the compatible system can result in a change to the DQRs, the design approval holder should coordinate any changes in advance to ensure that data suppliers update its data products to the new requirements in the same timeframe that the product is fielded.

(3) QMS Declaration. A statement that certifies the applicant has established a QMS, as described in RTCA/DO-200A, section 2.5. An application for a Type 2 LOA using compliance to RTCA/DO-200 would make a statement that certifies the applicant has established a quality assurance process, as described in RTCA/DO-200, section 4.

(4) Data Package. Regardless of the basis upon which acceptance is sought; the application data package must include information that defines the DQRs or data processes. For a Type 2 LOA, this includes substantiation that the DQRs for the aeronautical data will support the intended function and continued airworthiness of the installed equipment. For a Type 2 LOA using compliance to RTCA/DO-200, the data package requirements must be modified as specifically prescribed in the following paragraphs. The complexity of the data package will vary depending upon the critical nature of the data as it relates to the product in which it will be loaded. The data package may include, but is not limited to, the following:

(a) One copy of the applicant’s compliance plan as described in RTCA/DO-200A, section 2.2. A compliance matrix should be submitted to the FAA to simplify the review process. If a compliance matrix is submitted, it should reference the documentation explaining how each objective of this AC (and RTCA/DO-200A) is accomplished (see appendix 3 of this AC). For a Type 2 LOA using compliance to RTCA/DO-200; the applicant’s compliance package should substantiate meeting the requirements and intent of RTCA/DO-200, and if a compliance matrix or plan is submitted, it should reference the documentation demonstrating the original installed equipment airworthiness compliance and RTCA/DO-200 compliance.

(b) Data Process Description. The applicant should provide a high-level description of its data process, inspection and test procedures (including process controls and incoming supplier controls) for processing data. This should include means to address any changes to the DQRs, data processing procedures, and for implementation into the aeronautical data process. They should also illustrate the methods of traceability and configuration control for all delivered aeronautical data.

(c) Compatibility. For a Type 2 LOA only, include a list of systems for which compatibility has been established including make, model, series, and part numbers (hardware, software, and database).

(d) Tool Summary. For a Type 1 or 2 LOA using compliance to RTCA/DO-200A, the applicant must summarize the use of tools in its data process, which tools are qualified, the means used to qualify such tools, and the procedures for maintaining the tools.

For a Type 2 LOA using compliance to RTCA/DO-200, a list of tools and a description of how they are qualified must be provided.

(e) Quality Manual. A quality control manual for the QMS. For a Type 2 LOA using compliance to RTCA/DO-200, a quality assurance process manual.

(f) Data Error Handling. The applicant must have a procedure to be used in the event an unsafe condition or error is found in the data. The procedure should address the actions the applicant intends to take to develop and distribute corrective action (to be taken by customers, users of the database, inform source, and inform the FAA ACO/manufacturing inspection district office (MIDO)). Procedures must describe how to advise data suppliers of all suspected and confirmed errors with the source data, and to inform customers and the FAA ACO/MIDO of confirmed data errors that may have a safety effect on the operational use.

Procedures must also describe how to inform customers and the FAA ACO/MIDO of changes to the LOA status in a timely manner. Applicants must ensure confirmed data errors that may have a safety effect on the operational use are addressed without any delay, usually within 24 hours.

10. Post Acceptance Responsibilities.

a. Data suppliers may hold a LOA from the FAA provided the following activities are performed:

(1) Reporting Errors and Defects. The holder of a LOA for its aeronautical data process must establish a procedure to report to the FAA (ACO/MIDO from which the LOA was obtained) all confirmed errors or defects of the aeronautical data produced and distributed under the LOA that may have a safety effect on the operational use of that data. Examples of such data include but are not limited to final approach segment (FAS) data block changes, path and terminator “leg type” coding, as well as critical and essential data elements (assurance levels 1 and 2) and must be handled immediately and without delay. The initial reporting of confirmed safety related errors or defects must be timely and prompt to customers, the FAA, and to the source (Contracting State/data service provider) to ensure swift resolution. The initial reporting and handling of safety related errors or defects must be completed within 24 hours and resolution completed in a timely manner. The holder of a LOA should endeavor through data process/procedure to ensure receipt of data alerts reporting safety related errors or defects to data customers (application provider, end-user, etc.) in the aeronautical data chain and the FAA, and data customers must consider safety related data alerts prior to use of data updates.

(2) Maintain a QMS. The holder of a LOA for its aeronautical data process must maintain a quality management system as described in RTCA/DO-200A, section 2.5. Changes to the QMS that may affect the data quality objectives must be reported to the issuing ACO/MIDO before implementation. For a Type 2 LOA using compliance to RTCA/DO-200, the holder of a LOA for its aeronautical data process must maintain a quality assurance process

10 per RTCA/DO-200, section 2.4. Changes to the quality assurance process must be reported to the issuing ACO/MIDO before implementation.

(3) Changes to Data Process. The holder of a LOA for its aeronautical data process must submit minor design changes for an existing LOA in accordance with procedures agreed to by the applicant and the issuing ACO/MIDO. Major design changes must be substantiated and approved prior to implementation in the same manner as that for the original LOA. The definitions of what design changes are minor or major must be established prior to issuance of the LOA and documented in procedures agreed to by the ACO/MIDO. Procedures for reporting of changes to data process must also address changes to tools used in its data process.

(4) Internal Audits. The holder of a LOA for its aeronautical data process must perform periodic internal audits as described in RTCA/DO-200A, section 3, with the maximum time between audits (whether total or incremental) of not more than one year. For a Type 2 LOA using compliance to RTCA/DO-200, the holder of a LOA for its aeronautical data process must perform periodic internal audits as described in RTCA/DO-200, section 4.2, with a maximum time between audits (whether total or incremental) of not more than one year. Any major non-conformities as described in RTCA/DO-200A, section 3.4, must be reported to the FAA office issuing the LOA. For a Type 2 LOA using compliance to RTCA/DO-200, the holder of a LOA for its aeronautical data process must report any non-conformities to the FAA office issuing the LOA. Additionally, the FAA may perform periodic audits in accordance with procedures agreed to by the applicant and the ACO/MIDO.

(5) A LOA holder must notify the FAA (ACO/MIDO from which the LOA was obtained), when they no longer comply with the conditions of the LOA.

(6) The holder of a LOA for its aeronautical data process must provide a compliance/ release statement with each database distribution to broadcast LOA status, stating its compliance and providing information on known deficiencies.

(7) The LOA is not transferable and is effective until surrendered or withdrawn by the holder, or terminated by the FAA, as described in the LOA.

b. Notification of LOA Status Changes to Data Customers. The holder of a LOA must notify its data customers of the status of its LOA. They must also provide the status of LOAs (or foreign acceptance, including designation of the foreign authority that acknowledges the foreign source’s compliance to RTCA/DO-200A (or RTCA/DO-200) and the means of approval or acceptance) for all previous data chain participants up to, but not including, a Contracting State’s AIP. The method of notification must be timely to ensure customers can react to changes in the status of a LOA before they accept the next data update.

Note: An example of this notification requirement might consist of posting a copy of the LOA on a web site for customers, with a procedure to reference that site before updating data. This would ensure notification of any changes in the LOA status.

11. How Does This Guidance Apply to Operators?

a. Operator’s Responsibilities. This AC does not alter or affect the responsibility or authority of the operator (aircraft owner or pilot) in updating aeronautical data. The end user (operator) is ultimately responsible for ensuring that data meets the quality requirements for its intended application (Title 14 of the Code of Federal Regulations (14 CFR) § 91.503). Updating data in an aeronautical database under this AC is considered to be maintenance. The following guidelines apply to operators seeking compliance with RTCA/DO-200A:

(1) 14 CFR part 91 operators may update databases in accordance with 14 CFR §

43.3(g).

(2) 14 CFR parts 121, 125, and 135 operators must update databases in accordance with its approved maintenance program. For 14 CFR part 135 rotorcraft operators, this includes maintenance by the pilot in accordance with 14 CFR § 43.3(h).

(3) Updating “navigation” data addressed by this AC is considered preventative maintenance (ref. 14 CFR part 43, appendix A (c)(32)):

(a) No disassembly of the unit is required (disassembly does not include removal and replacement of a database memory module or card that is accessible from the front of an installed panel-mounted system and requires no tools (e.g., screwdrivers or wrenches)), and

(b) Pertinent instructions are provided.

(4) The operator must ensure the data meets the DQRs, as defined in the data supplier’s Type 2 LOA.

(5) The operator defines the completeness and timeliness requirements for the data, or accepts the requirements defined by its data supplier.

(a) The operator must validate that the completeness and timeliness requirements for the data are appropriate for the operations authorized.

Note: This validation could include the simple and effective assurance of data completeness and timeliness by the operator via a database identification page within the airborne equipment identifying the data set and period of validity.

(b) If the operator chooses to define the completeness and timeliness requirements, he must document the processes for data handling (receipt, storage or archiving, configuration management, configuration control, installation/loading, and data supplier coordination).

(6) The operator must review the status information for all previous aeronautical chain participants up to, but not including, a Contracting State’s AIP to confirm the validity of RTCA/DO-200A (or RTCA/DO-200) compliance for its supplier(s). For non-U.S. companies

12 with an approval or acceptance from their respective CAA, the FAA recognizes approvals by the CAA through bi-lateral agreement or EASA LOA.

(7) The operator must have procedures established to report back to its Type 2 data supplier any discrepancy or error in the data that may have a safety effect on the operational use of that data. The operator must also have procedures to obtain notification of errors and anomalies from their data supplier and must consider such notifications prior to use of the affected data in flight operations.

12. Operators Formatting and Altering Data. If the operator is performing data preparation and data transmission (e.g., formatting or altering information within an aeronautical database), then in order to demonstrate RTCA/DO-200A compliance, it must comply with paragraphs 13, and 19 – 23 of this AC and obtain a LOA. RTCA/DO-200A compliance toward an LOA can also be achieved if the operator uses a data selection and packing tool from an accepted data source, and that tool is referenced in the data supplier’s LOA as producing data compatible with the operator’s equipment.

Note: Data preparation and data transmission in this context pertains to altering or re-formatting of the database provided by the Type 2 LOA holder.

13. How Does This Guidance Apply to Data Suppliers?

a. The data supplier may obtain FAA acceptance of its aeronautical data process in accordance with RTCA/DO-200A and this AC. Paragraph 9 of this AC establishes procedures for aeronautical data suppliers to obtain an FAA LOA.

b. A data supplier may follow the requirements contained in RTCA/DO-200A, section 2, as a means for obtaining FAA acceptance of the aeronautical data process.

(1) Compliance Plan. The data supplier must develop a compliance plan as described in RTCA/DO-200A, section 2.2.

(2) Documentation of DQRs. The data supplier must meet the requirements of RTCA/DO-200A, section 2.3, and document the DQRs for all delivered data. Either the data supplier or the recipient can document the DQRs, but both must mutually agree. Evidence of the mutual agreement between a Type 2 LOA holder and its data supplier must be available. The only exceptions to this requirement are obtaining the data in the AIP or receiving the data through an official government source. The DQRs must be under configuration control and both parties must approve all modifications.

Note: The assurance levels identified in RTCA/DO-201A are applicable to RNAV and may not be applicable to other applications.