0 U.S. Department of Transportation Federal Aviation Administration Advisory Circular
Subject: Acceptance of Aeronautical Data Date: 4/19/16 AC No: 20-153B Processes and Associated Databases Initiated by: AIR-130 1 PURPOSE OF THIS ADVISORY CIRCULAR (AC).
1.1 This AC describes an acceptable means, but not the only means, for showing compliance with the applicable airworthiness regulations for equipment with an installed aeronautical database. This AC is not mandatory and is not a regulation. However, if you use the means described herein, you must follow it in all important respects. The term “must” indicates mandatory requirements when following the guidance in this AC. The terms “should” and “recommend” indicate recommended guidance, but are not required for meeting the objectives of this AC. The term “objectives” identifies requirements when used in this AC.
1.2 We, the Federal Aviation Administration (FAA), wrote this AC to help:
1.2.1 Assess compliance regarding aeronautical data processing using the requirements of RTCA, Inc. document (RTCA/DO)-200B, Standards for Processing Aeronautical Data, when you are applying for and obtaining an airworthiness approval.
1.2.2 Explain the use of RTCA/DO-200B when seeking technical standard order authorization (TSOA) and installation approval under type certification (e.g., type certificate (TC) or, supplemental type certificate (STC)) for equipment with installed aeronautical databases.
1.2.3 Obtain a Letter of Acceptance (LOA) from the FAA acknowledging an applicant’s aeronautical data process meets the objectives of this AC. An LOA confirms compliance with RTCA/DO-200B. For LOA applications, this AC contains three appendices;
appendix 1 contains sample cover letters for LOA application(s), appendix 2 contains sample FAA LOAs, and appendix 3 contains an objectives matrix capturing the mandatory requirements of this AC.
2 TO WHOM THIS AC APPLIES. We wrote this AC for aeronautical data suppliers
(e.g., data providers, application integrators, etc.), aircraft manufacturers, avionics manufacturers, and operators / end-users demonstrating compliance to RTCA/DO-200B and using this means toward airworthiness and operational approvals. 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, Aeronautical Information Services. This AC does not apply to software programming pins (for option selectable software), configuration files, aircraft personality modules, registries, parameter data items, or other lookup tables used by airborne systems and equipment to adapt equipment to the aircraft (i.e., airborne system databases).
SUMMARY OF MAJOR CHANGES AND SCOPE.
3.1 This AC provides a means for organizations to obtain FAA acceptance of their aeronautical data processes demonstrating compliance with RTCA/DO-200B. An LOA issued by the FAA or database acceptance as part of the equipment design approval under TSOA, TC, or STC substantiates the terms and conditions, and meets the objectives of this AC. For TSO and installation approvals with an associated database, RTCA/DO-200A is no longer an acceptable means of compliance after the publication date of this AC, except if already part of an applicable aircraft certification basis.
Maintenance of an existing LOA under AC 20-153A, or previous versions, can continue as long as there are no major changes to the LOA. We will accept new applications for an LOA, including major changes to existing LOAs using an alternative means of compliance based on AC 20-153A using RTCA/DO-200A, Standards for Processing Aeronautical Data, for a period of up to 36 months after the publication date of this AC provided you:
• Make application requesting use of the alternative means of compliance,
• Satisfy the mandatory objectives referenced in AC 20-153A, appendix 3,
• Satisfy objectives 1-14, 1-15, 1-16, 2-2, 2-3, 2-4, and 2-5 referenced in appendix 3 of this AC.
3.2 RTCA/DO-200B updates include:
• Revisions to the standard reflecting integrity provisions and lessons learned from previous LOA activities,
• Expansion from a navigation data-centric focus to include all types of aeronautical data (e.g., navigation, terrain, obstacle, airport mapping, and other purposes),
• Revisions to improve linkages with current industry and regulatory activities (e.g., Single European Sky ATM Research (SESAR) / Next Generation Air Transportation System (NextGen), Performance Based Navigation (PBN), System Wide Information Management (SWIM), Aeronautical Data Quality (ADQ), etc.) and other updates,
• Improved characterization of data quality requirements (DQRs),
• Adapted RTCA/DO-330, Software Tools Qualification Considerations, to provide better structure and consistency for database production tool qualification,
• Improved content and guidance on validation and verification activities,
• New requirements and guidance on security for aeronautical data processing,
• Improved guidance on documentation and evidence of compliance, 2
• A consolidated compliance matrix listing all requirements (“list of shalls”) to aid and streamline demonstration and verification of compliance.
3.3 This AC requires data suppliers to provide a release statement (reference paragraph
10.2.6 of this AC) with each database distribution for all new and existing LOAs when utilizing the means provided in this AC.
4 CANCELLATION. This AC cancels AC 20-153A, issued on September 20, 2010.
However, LOAs issued under AC 20-153 or AC 20-153A remain effective after the publication date of this AC, unless they are superseded, surrendered, withdrawn by the holder, or terminated by the FAA. New applications for LOA or new airworthiness approval applications made after the publication date of this AC must utilize the means provided in this AC, or an equivalent means as provided in paragraph 3.1 of this AC, except if already part of an applicable aircraft certification basis.
Note: This AC requires aircraft manufacturers, avionics manufacturers, or systems integrators to use the airworthiness guidance in paragraph 12 of this AC for all new LOAs, major changes to existing LOAs, as well as all new airworthiness approvals and major changes to existing airworthiness approvals.
5 WHAT IS AERONAUTICAL DATA? Aeronautical data is data used for aeronautical applications such as navigation, flight planning, flight simulators, terrain awareness, and other purposes (e.g., navigation data, terrain and obstacle data, and airport mapping data).
Other purposes may include new and novel aeronautical applications (e.g., dynamic electronic charts, etc.) where definition of the data quality requirements and intended function may require new policy development, or issue papers.
6 RTCA/DO-200B COMPLIANCE.
6.1 RTCA/DO-200B is the standard used to develop, assess change and support implementation of data quality management. Implementing a process as described by RTCA/DO-200B provides a level of assurance for maintaining data quality throughout all phases of the data handling process. Several characteristics define data quality including accuracy, resolution, assurance level, timeliness, completeness, traceability and format.
The scope of this standard includes the interface to a data supplier, receipt of the data, processing of the data, database distribution, and the interface to a customer (user). It is not the intent of RTCA/DO-200B to ensure the quality of Contracting State-originated data addressed through other means such as ICAO standards. The ultimate responsibility for ensuring data meets the quality for its intended use rests with the end-user of the data (reference paragraph 13 of this AC). The end-user can partially meet this responsibility by obtaining data from a supplier accredited against RTCA/DO-200B.
6.2 The intent of RTCA/DO-200B is to address the specific issues of the aeronautical data process by requiring organizations to have in place a quality management system (QMS) including the requirements associated with the aeronautical data process.
•Ir
- -~ ~ ~ ~ ~ ~ . . .
7 8 4/19/16 AC 20-153B
WHAT IS THE AERONAUTICAL DATA CHAIN?
7.1 RTCA/DO-200B, section 1.5.4 describes the aeronautical data chain as a conceptual representation of the path aeronautical data takes from its origination to its end use. The aeronautical data chain is a series of interrelated links where each link provides a function facilitating the origination, transmission, preparation, application integration, and end-use of aeronautical data for a specific purpose. Because an organization may perform one or all of the functions comprising the aeronautical data chain, it may be responsible for data preparation and data transmission for more than one chain link.
7.2 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 OEM, Applicant for Aircraft Type Design Approval
(e.g., TC or STC) DQRs DQRs DQRs DQRs Avionics Operator AIP (State) Data Provider Manufacturer (End-User, Data (Application Data Airline) Integrator) Data WHAT IS A DATABASE LOA?
8.1 Database LOA provides evidence of database integrity. A database LOA is a formal letter issued by an FAA aircraft certification office (ACO) documenting a data supplier has met the requirements of this AC. For those applications requiring database integrity
(e.g., Area Navigation (RNAV), Required Navigation Performance (RNP), Synthetic Vision System (SVS), terminal procedures, airport moving map displays, Terrain Awareness and Warning System (TAWS), etc.), the LOA may be used as evidence of compliance with RTCA/DO-200B. You can use the LOA in support of an application for operational approval, or in support of a maintenance task per the installation instructions of the equipment, or in of support instructions for continued airworthiness (ICA) of the aircraft.
8.2 We developed the database LOA framework in response to the need for performancebased operations requiring database integrity. Since the 1970s, installed systems relied on navigation databases to support their intended function. Prior to issuance of AC 20-153 in 2005, the FAA had no means to provide oversight of these databases or verify their compatibility with the equipment. Before this guidance, data suppliers had 4
no means to obtain FAA acceptance of their delivered data with formal verification and recognition of their processes. AC 20-153A expanded the LOA framework to include airport mapping, terrain and obstacle data in addition to navigation. It is important to emphasize the database integrity requirement for navigation data is typically driven by the operation (e.g., RNAV and RNP) while for other types of databases (e.g., airport mapping, terrain, and obstacle), the database integrity is determined at the time of airworthiness approval.
8.3 The objective of the database LOA is to provide evidence your aeronautical data processes meet the objectives of this AC, and in the case of a Type 2 LOA (see paragraph
9.1.2), it also provides installation eligibility privileges with the associated installation approval. Further, the LOA affords users an assurance of integrity based on increasing levels of process rigor. With the database LOA, we evaluate the data quality requirements and data processes used by you, rather than treating a database as a part approval, or having you verify the vast amount of data in a database. Verification of robust data processes allows updates to the data on aircraft without having to go through the change approval process.
8.4 A database LOA (Type 2) is the recommended means to manage an aeronautical database under an airworthiness approval (e.g., TC, STC, TSOA, etc.), rather than applying for a design change for the installed equipment at each database update. Additionally, when avionics policy states a RTCA/DO-200B requirement, we recommend obtaining a Type 2 LOA for change management, especially when data quality requirements need verification for integrity. Otherwise, we expect use of the current change control processes for TSO and STC/TC when there are changes to the data, including database updates.
8.5 The LOA identifies organizations within the aeronautical data chain able to demonstrate established data processes related to the preparation and transmission of aeronautical data per their defined data quality requirements.
FAA ACCEPTANCE OF AERONAUTICAL DATABASES. There are three separate ways to gain FAA acceptance of your aeronautical database associated with a TSO, TC, STC, or LOA project utilizing this AC (see Figure 2):
Note: It is not necessary to obtain FAA acceptance of an aeronautical database when failure to meet the DQRs has no safety effect (i.e., routine assurance-level data, Visual Flight Rules (VFR)-only navigation database, etc.).
Obtain a database LOA.
TSOA with an associated database (i.e., for a TSO requiring RTCA/DO-200B compliance (or earlier version)).
Installation approval with an associated database (e.g., TC, STC).
FAA acceptance of an aeronautica l database Yes Yes project?
No TSOA project ?
No Use AC 20- 115C or No ..
alternative mean s DPAL 3, no No_. approval neces sary ( 11.2.1.2) Go to Yes paragraph Yes Yes
9.1 Go to paragraph
9.2. Meet .2.1.2?
No System verification req 'd (9.2.3 /
9.3.3) No Go to paragraph
9.3. Meet
9.3.1?
Yes Pass Yes Database upd ates follow design approva l change proce ss 4/19/16 AC 20-153B
Figure 2. FAA acceptance of an aeronautical database 6
9.1 Obtain a database LOA. We recommend a database LOA to gain FAA acceptance of a data supplier’s aeronautical data processes. There are two types of data supplier LOAs issued by FAA. Type 1 LOAs are based on data requirements agreed upon between a data supplier and their customer (typically an avionics manufacturer) with no identified compatibility with an aircraft system or equipment. Type 2 LOAs ensure compatibility of the data requirements with installed systems or equipment (avionics manufacturers / application integrators). An end-user can utilize a Type 2 LOA as evidence of database integrity during the operational approval process or for an approved maintenance program. While RTCA/DO-200B applies to both types of LOAs, the Type 2 LOA 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. Guidance material regarding the application of RTCA/DO-200B is in paragraphs 10, 11, and 12 of this AC.
9.1.1 Type 1 LOA. A Type 1 LOA provides recognition of your meeting the objectives of this AC with no identified compatibility with an aircraft system or equipment. A Type 1 LOA ensures the processes for producing the aeronautical data meets the objectives of this AC. This LOA applies to data suppliers, operators / end-users, avionics manufacturers, or others. A Type 1 LOA is not associated with a specific certification project (such as a TC, STC, or TSOA) or equipment type. DQRs can be defined by the data supplier and accepted by their customer, or can be agreed upon between them.
9.1.2 Type 2 LOA.
9.1.2.1 A Type 2 LOA provides recognition of your meeting the objectives of this AC and the compatibility of its delivered data with particular avionic systems supporting an intended function. A Type 2 LOA recognizes compatibility with the DQRs necessary to support an intended function by listing the associated equipment.
Note: A Type 2 LOA is only applicable for the equipment listed on the LOA, and the applicant is responsible for identifying all equipment using the associated database.
9.1.2.2 A Type 2 LOA applies to a design approval holder (DAH) (TC/STC/TSOA) or to a data supplier who can establish its data requirements are identical to those defined by a DAH. You achieve this identicality by either establishing design equivalency or by a licensing agreement between the DAH and the entity seeking approval. Regardless, identicality requires formal agreement between all participants (e.g., agreement to DQRs, licensing agreements, etc.). When under license or using design equivalence, the DAH remains responsible for demonstrating (e.g., using system verification tests, sampling checks, etc.) the DQRs are consistent with the intended function of the equipment (see paragraph 12 of this AC).
9.1.2.3 Many aircraft and avionics manufacturers have obtained approval for systems prior to the issuance of RTCA/DO-200B. For such systems, you must identify the DQRs for the avionics prior to application for a Type 2 LOA.
9.1.2.4 Many organizations seeking a Type 2 LOA as an application integrator employ another organization to do certain phases of their aeronautical data processing. A typical model for this arrangement would entail creating a packing tool for the other organization to use to prepare and distribute your data. However, regardless of whether we recognize the other organization as RTCA/DO-200B compliant for their processes, the processes used for your data processing must be your own. You must demonstrate your defined processes are effective and have the appropriate approval, control, and oversight mechanisms to ensure compliance when being performed outside of your organization. For organizations working for you, the processes they use, as well as the records they maintain, must be under your control and accessible in order to hold a Type 2 LOA.
9.2 TSOA with an associated database.
9.2.1 When a TSO states a requirement for RTCA/DO-200B compliance (or earlier version), use of database LOA (Type 2) is recommended. No further demonstration is necessary for the TSOA (related to the aeronautical database) when you apply for and obtain a database LOA (Type 2). If you do not obtain a database LOA (Type 2), then you must address the following as part of your TSO application:
9.2.1.1 Many FAA TSOs do not specify RTCA/DO-200B for aeronautical database assurance. For TSOs specifying a version prior to RTCA/DO-200B, or not specifying any version of RTCA/DO-200, we recommend you use RTCA/DO-200B. If you use RTCA/DO-200B in lieu of a specified earlier version, request a deviation in accordance with the requirements of 14 CFR part 21, subpart O.
9.2.1.2 As part of the compliance documentation (reference RTCA/DO-200B, section 2.2) submitted with the TSO application, you must address the following:
Define the DQRs; ensure they are consistent with the intended function of the TSO (see RTCA/DO-200B appendix B).
Define the verification methods for all data and validation methods for data not coming from authoritative source (reference paragraph 11.2.1).
Define the data process techniques and procedures (i.e., Quality Management (QM) process) from origination of the data through loading the data into the application, of ensuring the quality of the data. Further, 8
you must document how you will maintain these data processes (for all suppliers in the aeronautical data chain) throughout the lifecycle of the installed article.
Note: You may use an LOA from a previous data chain participant as evidence the data received meets the agreed DQRs.
Note: As part of the process definition for change management, define the level of system verification testing appropriate for major and minor changes to the items in paragraph 9.2.1.2 (e.g., DQRs, process documentation, etc.).
Define the requirements and conditions for updating and verifying the database in the installation instructions.
9.2.2 The AFM supplement or installation instruction must identify any restriction/limitations concerning operating with aeronautical databases (e.g., expired, etc.).
9.2.3 Without a database LOA, database updates with a failure effect other than no safety effect are a change to the TSO article. Additionally, if you do not satisfy the items in paragraph 9.2.1.2, then you must perform system verification tests to verify the database in the context of the functional software (reference AC 20-115C and AC 20-174).
Note: The intent of this paragraph is to allow database approval for applicants who do not seek an LOA or do not meet the items in paragraph 9.2.1.2, but rather are relying on system verification tests to ensure the quality of the installed database.
9.3 Installation approval with an associated database. We do not expect this approval method to be effective for large data sets or databases needing frequent update (e.g., more frequent than one update per year).
9.3.1 There are three types of installed databases: (1) aeronautical databases, (2) airborne system databases, and (3) other databases, which are not part of the type design of the aircraft (e.g., Electronic Flight Bag (EFB) Type A and B, Electronic Checklist (ECL), user modifiable, etc.). This AC provides guidance related only to “aeronautical databases” and highlights your responsibility for showing compliance to all applicable 14 CFR part 23/25/27/29 sections for installed aeronautical databases. This responsibility is more straightforward within the LOA framework (or if the database is associated with TSOA); however, if you do not obtain an LOA, then as part of the compliance documentation (reference RTCA/DO-200B, section 2.2) submitted you must address the following at time of installation approval:
• Define the DQRs; ensure they are consistent with the intended function (see RTCA/DO-200B appendix B).
• Define the verification methods for all data and validation methods for data not coming from authoritative source (reference paragraph 11.2.1).
• Define the data process techniques and procedures (i.e., Quality Management (QM) process), from origination of the data through loading the data into the application, of ensuring the quality of the data. Further, you must document how you will maintain these data processes (for all suppliers in the aeronautical data chain) throughout the lifecycle of the aircraft.
Note: You may use an LOA from a previous data chain participant as evidence the data received meets the agreed DQRs.
Note: As part of the process definition for change management, define the level of system verification testing appropriate for major and minor changes to the items in paragraph 9.3.1 (e.g., DQRs, process documentation, etc.).
• Define the requirements and conditions for updating and verifying the database within the ICAs.
9.3.2 The AFM must state any restriction/limitations concerning operating with aeronautical databases (e.g., expired, etc.).
9.3.3 Without a database LOA, we consider updates to a database with a failure effect other than no safety effect to be a change to the installation approval. Additionally, if you do not satisfy the items in paragraph 9.3.1, then you must perform system verification tests to verify the database in the context of the functional software (reference AC 20-115C and AC 20-174).
Note: The intent of this paragraph is to allow database approval for applicants who do not seek an LOA or do not meet the items in paragraph 9.3.1, but rather are relying on system verification tests to ensure the quality of the installed database.
10 LOA APPLICATION PROCESS AND POST-ACCEPTANCE RESPONSIBILITIES.
10.1 Application. Submit your application for an LOA to the ACO in the geographical area in which your data processing facility is located (see appendix 1, Sample application for an FAA LOA for the aeronautical data process). An application includes the following:
10.1.1 Facility. The name and address of your facility.
10.1.2 Type 1 or Type 2 LOA? A brief description of the type of FAA acceptance sought: Type 1 LOA or Type 2 LOA. For a Type 2 LOA, the application must identify the compatible systems part/model numbers (hardware, software, and database). Since changes to the compatible system can result in a change to the DQRs, you should coordinate those 10
changes with the DAH early, to ensure updates to data products meet the new requirements at the same time the product is reviewed.
10.1.3 Data set. A brief description of the type of data set included in the scope of the application (e.g., navigation, terrain, obstacle, airport mapping, etc.).
10.1.4 Data package. The application data package must include authorized versions of all of the plans and procedures for the processing of aeronautical data and quality management requirements. For a Type 2 LOA, you must include substantiation of the DQRs, demonstrating the aeronautical data will support the intended function of the installed equipment and are part of the airworthiness approval documentation. 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 must include, but is not limited to, the following:
10.1.4.1 One copy of your compliance documentation as described in RTCA/DO-200B, section 2.2. This includes a compliance plan as described in RTCA/DO-200B, section 2.2.1, as well as all documentation supporting your compliance as described in RTCA/DO-200B, section 2.2.2.
Preparation of the compliance plan simplifies the review process and provides reference to all other plans and procedures supporting your compliance. The compliance plan includes a completed RTCA/DO-200B compliance matrix (see RTCA/DO-200B, appendix F), as well as a completed objectives matrix found in appendix 3 of this AC (to cover AC objectives). It provides reference to the other documentation showing where in the plans and procedures the objective evidence required by this AC and RTCA/DO-200B is accomplished.
10.1.4.2 Data process description. Provide a high-level description or process diagram of the data process, inspection and test procedures (including process controls and incoming supplier controls) for processing data in the Data Processing Procedures as described in RTCA/DO-200B, appendix E, item 3. This includes means to address any changes to the DQRs, data processing procedures, and implementation into the aeronautical data process. Additionally, illustrate the methods of traceability and configuration control for all delivered aeronautical data.
10.1.4.3 Compatibility. For a Type 2 LOA, you must include a list of systems for which you will ensure compatibility with intended use including part/model numbers (hardware, software, and database) by demonstrating (e.g., using system verification tests, sampling checks, etc.) the DQRs are consistent with the intended function of the associated equipment (see paragraph 12 of this AC). This is always done through an appropriate arrangement with the original equipment manufacturer (OEM) / DAH at time of first listing on the LOA or when proposing additions to the compatible equipment list. We also recommend performing periodic sampling checks on individual data 11
sets (e.g., via simulation, test bench environment, etc.) to confirm continued compatibility.
10.1.4.4 Data error handling and reporting. We consider a data error an escape from the supplier’s quality system and a failure to meet DQRs. The applicant must have a procedure to address an unsafe condition or error found in the distributed data. The procedure should address the actions you intend to take to develop and distribute corrective action to all affected parties (e.g.
source, users of the database, FAA ACO/manufacturing inspection district office (MIDO)). Procedures must describe how to communicate with data suppliers for all suspected and confirmed errors with the source data, and how to inform customers and the FAA ACO/MIDO of confirmed data errors having potential to adversely affect the safety of operational use.
Your procedure must describe how to communicate without undue delay (within 72 hours of detection/knowledge) change in LOA status and any confirmed data errors having potential to adversely affect the safety of operational use. Examples of data errors with potential to adversely affect safety 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.
10.2 LOA post acceptance responsibilities. The requirements for maintaining your LOA privileges are:
10.2.1 Error reporting. You must report to customers (application provider, end-user, etc.), the FAA and to source (if applicable) any failure, malfunction, or defect in the distributed data having potential to adversely affect the safety of operational use. The initial reporting of confirmed safety-related errors or defects must be timely and prompt (within 72 hours of detection/knowledge) to ensure swift resolution. You must endeavor, through documented procedure, to ensure receipt of data alerts reporting safety-related errors or defects. You must consider any safety-related data alerts prior to use of the affected data.
10.2.2 Maintain a QMS. You must maintain a QMS as described in RTCA/DO-200B, section
2.5. You must report all changes made to the QMS affecting the data quality objectives to the issuing ACO/MIDO before their implementation.
10.2.3 Changes to data process. You must submit minor design changes for an existing LOA in accordance with procedures agreed to with the issuing ACO/MIDO. You must substantiate major design changes, and the ACO/MIDO must accept them prior to their implementation. Procedures for reporting of changes to the data process must also address changes to tools used in its data process.
10.2.4 Auditing. You must perform periodic internal audits of both AC 20-153B and RTCA/DO-200B objectives as described in RTCA/DO-200B, section 3, with the maximum time between audits not to exceed one year. Audits may be total or conducted 12