Notification of a Proposal to issue a Certification ......RTCA DO-272 User Requirements for Aerodrome Mapping Information ED-99/ DO-272 C/D September 2015 EUROCAE ED-98/ RTCA DO-276

EASA CM No.: Proposed CM-AS-009 Issue 01

© European Aviation Safety Agency. All rights reserved. ISO9001 Certified.

Proprietary document. Copies are not controlled. Confirm revision status through the EASA-Internet/Intranet. An agency of the European Union

Page 1 of 16

Notification of a Proposal to issue a Certification Memorandum

Certification of aircraft systems with databases

EASA Proposed CM No.: Proposed CM–AS-009 Issue 01 issued 19 June 2018

EASA Certification Memoranda clarify the European Aviation Safety Agency’s general course of action on specific certification items. They are intended to provide guidance on a particular subject and, as non-binding material, may provide complementary information and guidance for compliance demonstration with current standards. Certification Memoranda are provided for information purposes only and must not be misconstrued as formally adopted Acceptable Means of Compliance (AMC) or as Guidance Material (GM). Certification Memoranda are not intended to introduce new certification requirements or to modify existing certification requirements and do not constitute any legal obligation. EASA Certification Memoranda are living documents into which either additional criteria or additional issues can be incorporated as soon as a need is identified by EASA.

EASA CM No.: Proposed CM-AS-009 Issue 01

© European Aviation Safety Agency. All rights reserved. ISO9001 Certified.

Proprietary document. Copies are not controlled. Confirm revision status through the EASA-Internet/Intranet. An agency of the European Union

Page 2 of 16

Log of issues

Issue Issue date Change description

01 19.06.2018 First issue

Table of Content

Log of issues ....................................................................................................................................................... 2

Table of Content ................................................................................................................................................ 2

1. Introduction ............................................................................................................................................... 3

1.1. Background ........................................................................................................................................ 3

1.2. Whom this Certification Memorandum affects ................................................................................ 3

1.3. Scope ................................................................................................................................................. 4

2. References and Abbreviations ................................................................................................................... 5

2.1. References ......................................................................................................................................... 5

2.2. Abbreviations ..................................................................................................................................... 6

3. Certification of Systems using Databases EASA Policy and Guidance for TC and STC Holders ................. 7

3.1. GENERAL PROCESS ............................................................................................................................ 7

3.1.1. Identification of Databases ........................................................................................................ 7

3.1.2. Safety Assessment ..................................................................................................................... 7

3.1.3. Database Category..................................................................................................................... 8

3.1.3.1. Databases with full airworthiness approval ...................................................................... 8

3.1.3.2. Databases without airworthiness approval ....................................................................... 8

3.2. CRITERIA FOR DATABASE WITH AIRWORTHINESS APPROVAL .......................................................... 8

3.2.1. Case 1: Database covered under ETSO Authorisation (ETSO A) ................................................ 8

3.2.2. Case 2: Database qualified with the software following ED-12/DO-178 .................................. 9

3.2.3. Case 3: Database following ED-76/DO-200 ............................................................................... 9

3.2.4. Case 4: Low Complexity Database ........................................................................................... 10

3.3. CRITERIA FOR DATABASE WITHOUT AIRWORTHINESS APPROVAL ................................................. 10

3.3.1. Aeronautical Database ............................................................................................................ 10

3.3.2. Other Databases ...................................................................................................................... 11

3.4. GENERAL CRITERIA .......................................................................................................................... 11

3.4.1. Database Specification ............................................................................................................ 11

3.4.1.1. Define Data Quality Requirements .................................................................................. 11

3.4.2. Aircraft Flight Manual .............................................................................................................. 12

3.4.3. Compatibility ........................................................................................................................... 12

3.4.4. Certification Testing ................................................................................................................. 12

3.4.5. Instructions for Continued Airworthiness ............................................................................... 12

4. Remarks ................................................................................................................................................... 13

Appendix A – Databases Airworthiness Approval Flow Chart ......................................................................... 14

EASA Proposed CM No.: Proposed CM-AS-009 Issue 01

© European Aviation Safety Agency. All rights reserved. ISO9001 Certified. Proprietary document. Copies are not controlled. Confirm revision status through the EASA-Internet/Intranet.

An agency of the European Union

Page 3 of 16

1. Introduction

This Certification Memorandum provides guidance regarding the certification of systems which use databases.

1.1. Background

Databases may be used in different aircraft or engine systems and embedded in digital pieces of equipment. The intended function of aircraft systems can be affected by the quality of the data contained in a database. As well, any corruption or error in the format or content of databases, or any incompatibility between databases and aircraft systems may have an impact on safety and should be considered when showing compliance with CS XX.1301/1309 (where applicable following AMC XX.1309) for those activities which are under responsibility of Type Certificate/Supplemental Type Certificate (TC/STC) applicants.

The data origination and processing, and therefore its quality, is in some cases not under full control of the applicant, and therefore cannot be fully covered by an airworthiness approval. However, the process to distribute and produce the database in the specified format, starting from the source data to the final upload to the aircraft or engine system, should ensure that an adequate integrity of the data is maintained. A relevant case is the aeronautical data (e.g. data provided by ICAO Member States). Organisations processing those data were initially addressed through the EASA Opinion 01/2005, Acceptance of Navigation Database Suppliers, and, more recently, regulated through the Commission Implementing Regulation (EU) No 2017/373, Air Traffic Management/Air Navigation Services. This regulation establishes common requirements for providers of data services that are processing aeronautical data and information for use in aeronautical databases on certified aircraft application/equipment. Particularly, the Type 2 addresses acceptable means of ensuring that the aeronautical data process does not corrupt data, from its origination to its application in the equipment.

The FAA has adopted an equivalent approach as provided in FAA AC 20-153B. However, compared to this Advisory Circular, regulation (EU) No 2017/373 does not address the specific guidance for holders of type design approvals (ETSOA, TC, STC) concerning aeronautical databases in the context of aircraft certification.

This CM is filling the gap and going a step further, by addressing not only aeronautical, but as well other databases, which may benefit from related published standards and recognized means to show compliance with the certification requirements.

1.2. Whom this Certification Memorandum affects

Applicants in the scope of this CM, as per Part 21, are:

Applicants for a type-certificate (TC) of an aircraft, or other product like engine, APU or propeller, which will utilize a database,

Applicants for the approval of major changes to a type-certificate or supplemental type-certificate (STC) procedures, when the change utilizes a database,

TC or STC holders that apply for approval of a new function or modification of already certified function, which will utilize a database (new or previously introduced). The function to approve may benefit from an ETSO Authorisation1 (or equivalent).

Avionics manufacturers applying for, or holding, an ETSO authorisation for an equipment with an associated database. They should consider this CM in supporting the installer (TC or STC holder/applicant).

1 In absence of an ETSO Authorisation, the TC/STC Holder becomes the equipment design approval holder under the Agency regulation.




Page 4 of 16

Unless otherwise mentioned, any of these organisations is referred to as the “applicant” in following sections of this CM.

Applicants not in the scope of this CM are:

Data suppliers applying for Data Provider Certificate or in the transition phase for EASA Letter of Acceptance (LOA)

Providers for Electronic Flight Bag (EFB) non-certified software applications with an associated database.

This guidance provides provisions to take credit for activities covered under ETSO authorisation as well as activities covered under Data Provider Certificate (or equivalent LOA).

This CM is intended to be harmonised with the AC 20-153B guidance, although that AC covers as well detailed guidance for FAA LOA applicants, not covered by this CM.

1.3. Scope

Databases in the scope of this CM are used in different aircraft or engine systems and embedded in digital pieces of equipment covering, but not limited to:

data which is not originated by the aircraft or application/equipment manufacturer: o aeronautical data, such as ‘navigation’, ‘aerodrome mapping data’, ‘obstacles data’ and

‘terrain data’, needed for the functionality of certified aircraft application(s) and does not form part of its (their) approved type design (TD)

o data such as magnetic variation, or communication parameters defined by Data Link Service Providers in certified aircraft application(s) that form part of its (their) approved type design

data originated by the aircraft or application/equipment manufacturer, such as, electronic check list data, aircraft performance parameters, or engine power settings

other purposes that may include new and novel aeronautical applications, for example, data driven charts

Databases not in the scope of this CM are:

software artefacts sometimes called databases but usually named as Configuration Files, or Parameter Data Items, such as symbology, bus specifications or configuration data. They can be used to activate or deactivate software components/functions, or to adapt the software computation to the aircraft configuration. These are covered, where applicable, in the EASA AMC 20-115.




Page 5 of 16

2. References and Abbreviations

2.1. References

It is intended that the following reference materials be used in conjunction with this Certification Memorandum:

Reference Title Code Issue Date

CS XX.1301 Function and installation CS-23

CS-25

CS-27

CS-29

1 - 4

1 and up

1 and up

1 and up

---

CS XX.1309 Equipment, systems and installations

CS XX.1529 Instructions for continued airworthiness

CS 23.2625 Instructions for continued airworthiness

CS-23 5 and up 29 March 2017

CS 23.2500

CS 23.2505

CS 23.2510

System and Equipment

CS-23

5 and up

29 March 2017

EUROCAE ED-76 / RTCA DO-200

Standards for Processing Aeronautical Data

ED-76/ DO-200

-/A

A/B

October 1998

June 2015

Part 21 Annex 1 to Commission Regulation (EU) No 748/2012

Part 21 --- 03/08/2012

Commission Implementing Regulation (EU) No

2017/373

Common requirements for providers of air traffic management/air navigation services and other air traffic management network functions and their oversight

Part-DAT --- 01/03/2017

ED Decision 2017/001/R

AMC/GM to Regulation (EU) No 2017/373

AMC/GM Part-DAT

--- 08/03/2017

EUROCAE ED-12/RTCA DO-178

Software Considerations in Airborne Systems and Equipment Certification

and related supplements

ED-12/ DO-178

C January 2012

EASA AMC 20-115 Airborne Software Development Assurance using EUROCAE ED-12 and RTCA DO-178

AMC 20-115

D 19/10/2017

EUROCAE ED-77/ RTCA DO-201

Standards for Aeronautical Information

ED-77/ DO-201

-/A April 2000




Page 6 of 16

Reference Title Code Issue Date


User Requirements for Aerodrome Mapping Information

ED-99/ DO-272

C/D September 2015


User Requirements for Terrain and Obstacle Data

ED-98/ DO-276

B/C September 2015

2.2. Abbreviations

AC Advisory Circular

AMC Acceptable Means of Compliance

AFM(S) Aircraft Flight Manual (Supplement)

CM Certification Memoranda

CRI Certification Review Item

CS Certification Specification

DQR Data Quality Requirements

EASA European Aviation Safety Agency

ETSO(A) European Technical Standard Order Authorisation

EU European Union

FAA Federal Aviation Administration

GM Guidance Material

ICA Instructions for Continued Airworthiness

ICAO International Civil Aviation Organization

LOA Letter of Acceptance

NSE No Safety Effect

STC Supplemental Type Certificate

TC Type Certificate

TD Type Design




Page 7 of 16

3. Certification of Systems using Databases EASA Policy and Guidance for TC and STC Holders

The Figures in the Appendix A of this CM shows different paths for databases airworthiness approval and provide links to the relevant airworthiness criteria to be considered by the applicant.

3.1. GENERAL PROCESS

This section provides guidance to applicants on the general aspects which are common, independently of the nature of the data, and applicants selected methodology to address related databases.

3.1.1. Identification of Databases

This paragraph addresses the STEP 1 of the Appendix A flow chart.

One or more databases may be necessary for the good functioning of new equipment or applications. Some database may be new in the TD (loaded into the new hardware to be installed), but for changes to already approved TD, there could be a new equipment, system or application accessing the information in one or more databases loaded in an already certified equipment, system or application. The applicant has to identify in both cases all the databases used.

The applicant is encouraged to provide a list and a description of all databases, and to propose, for EASA review and agreement, the criticality associated to the data according to section 3.1.2, categorization of all the databases, according to the two categories defined in 3.1.3, and the process to be followed for the cases covered under 3.2.

In the case of application for TC/STC or change to TC/STC, the applicant is responsible for identifying all equipment, systems and applications making use of each new database. It is important to consider that activities associated to the required assurance level and to define the database and its contained data will be driven by the most demanding application. In particular the database definition and generation process should be consistent with the tightest requirements derived from malfunction or availability effects caused by the data at aircraft or engine level (refer to 3.1.2).

3.1.2. Safety Assessment


The safety assessment defined in CS XX.1309, CS 23.2510 and associated AMC XX.1309 and AMC to CS 23.2510 should include the determination of the failure condition criticality associated to incorrect data or loss of data of the database. The risk of an unintended and undetected activation of a function, or misbehaviour of a system, due to a data error should be assessed as part of the process.

The required assurance level for the data process should be identified, based on the overall system architecture through allocation of risk. Since integrity of a process cannot be numerically quantified, the integrity requirement may be defined by a quality assurance level. For the particular case of aeronautical data, but extensible to other databases, ED-76/DO-200 Appendix B provides guidance on the determination of the assurance level. The applicant should ensure that the database specification is consistent with the conclusions of the System Safety Assessment.

For TC/STC applicants/holders, when the equipment installed is approved through an ETSO Authorisation and the possible effects at system and product level are consistent with the ETSO stated failure classifications (or in absence of this information in the ETSO or for non-ETSO functions, the failure classifications assumed by the ETSO holder), the applicant does not need to further assess the effect of database errors or define the required assurance level for the data.

When it is concluded as result of this analysis that a database contain only routine data (i.e. any discrepancy or error has No Safety Effect (NSE) on the operational use of the data), compliance with the criteria in this




Page 8 of 16

CM is not required but the applicant is recommended to provide guidelines for operators on the use of NSE databases.

3.1.3. Database Category


The applicant should categorize each database according to the following criteria.

3.1.3.1. Databases with full airworthiness approval

These are databases which are embedded in digital equipment and certified as part of it. This equipment may be an ETSO article, but not necessarily. These databases may be controlled by their own part numbers or by the equipment part number, but they require a design change approval for the equipment and its installation at each database update.

In principle, all databases for which the applicant can retain full control of the source data (e.g. aircraft model performance database) should normally be part of the type design and should follow a full airworthiness approval process.

Acceptable procedures and interpretative material for the airworthiness approval of such databases are specified in section 3.2 below.

3.1.3.2. Databases without airworthiness approval

When the source data is not controlled by the applicant or when databases are needing frequent update, it could be impractical to grant to such database a full airworthiness approval and including them formally in the type definition of the aircraft. Yet, some safety precautions and limitations need to be identified, as part of the type certification. Some specific considerations are provided in 3.3 below.

3.2. CRITERIA FOR DATABASE WITH AIRWORTHINESS APPROVAL

For each database subject to an airworthiness approval, the applicant should propose one of the following approval processes to be followed, or alternative means for EASA review. EASA will decide if the proposed approval process is consistent with the nature and the complexity of the database.

There are four possible cases or generally accepted processes for databases under 3.1.3.1 category:

Case 1: Database covered under ETSO Authorisation

Case 2: ED-12/DO-178 approval process.

Case 3: ED-76/DO-200 approval process.

Case 4: Specific approval process for low complexity databases. In this case, the applicant can use a simple method to ensure the quality of the installed database (e.g. complete verification and validation of the data, system tests to qualify the data in the context of the certified application, etc.)

The proposed approval process should be identified in the relevant system certification plan. Whatever the approval process chosen, the applicant should document a compliance statement.

3.2.1. Case 1: Database covered under ETSO Authorisation (ETSO A)

This paragraph is applicable to the TC/STC applicant installing an equipment with ETSOA. ETSO applicants may consider this material to support the equipment installer’s needs.

The equipment or application to be installed may benefit from the ETSO authorisation activities. In this case, the installer can take credit from this authorisation to demonstrate that the installation complies with the applicable certification specifications for the product. However, the TC/STC applicant should:

Demonstrate that the equipment or application has been installed and is intended to be used in the aircraft according to the instructions and limitations provided by the ETSO A holder and therefore




Page 9 of 16

the database specification and associated data quality and processing assurance level, as defined by the ETSO A holder, are appropriate without changes;

or

Identify the areas which may be impacted by the particularities of the system as installed in the product, and its impact on the definition of the databases. For example, the applicant may need that the content of a database is appropriate to the performance of the aircraft, or impose requirements to ensure there is no confusing information presented to flight crews due to the cockpit arrangement (e.g. legacy cockpits with limited display capabilities).

In the first bullet case, the equipment or application ETSO A holder may have followed for the database approval the guidance provided in case 2, 3 or 4 below, but the compliance finding would be covered by the ETSO Authorisation and it is not under the direct responsibility of the installer.

When the particularity of the installation requires specific or limited database content, more stringent quality or assurance level, or additional limitations, the applicant remains responsible to ensure that the content and quality of the database is appropriate.

Consideration should be given to the applicable aspects of section 3.4. In particular, as part of the compliance documentation, the applicant should give consideration (when applicable) to potential necessary inputs to the:

Aircraft Flight Manual (AFM) (refer to 3.4.2)

Instructions for Continued Airworthiness (ICA) (refer to 3.4.5)

One possible example of the impact on the AFM is the necessity to transpose limitations at equipment level into operational limitations in the AFM (e.g. only for use during taxi) or to address through ICA the necessity to update the database content periodically (e.g. magnetic variation tables).

3.2.2. Case 2: Database qualified with the software following ED-12/DO-178

No specific guidance is provided for the ED-12/DO-178 approval process, since EASA AMC 20-115 (latest revision) should be followed where this approval process is retained.

Consideration should be given to the applicable aspects of section 3.4.

3.2.3. Case 3: Database following ED-76/DO-200

The applicant has to consider that the ED-76/DO-200, Standards for Processing Aeronautical Data, was written in order to address specifically the needs of aeronautical data. The applicant may consider whether these standards (or relevant part of it) may be appropriate for other databases.

This approval method may not be effective for databases needing frequent update (e.g., more frequent than one update per year). The update to a database with a failure effect other than NSE will be a change to the approved TC/STC. Revisions of the databases should follow the same approval process.

The applicant should submit to the EASA the compliance documentation (refer to ED-76/DO-200, section 2.2). As part of this compliance documentation, the following must be addressed:

Define DQRs (refer to 3.4.1 or ED-76, section 2.3 and Appendix B);

Define the verification methods for the data and validation methods for data not coming from authoritative source (ED-76 Appendix C);

Define the data process techniques and procedures documented and maintained through the lifecycle of the aircraft (including tools used and when necessary their qualification);

Define the requirements and conditions for updating and verifying the database within the ICAs.

And consideration should be given to the additional aspects of section 3.4, when applicable.




Page 10 of 16

3.2.4. Case 4: Low Complexity Database

The applicant can use an alternate method to ED-76/DO-200 or ED-12/DO-178 if the database could be demonstrated as a “low complexity” database. This low complexity means that the amount of data is really limited and the structure of the database is simple.

For this, the applicant should demonstrate in particular that each of the elements or records of the database can be validated and verified through “traditional” process (i.e. basic equipment testing as per section 3.4.4, manual verification of every data record…). Full database content should be validated and verified by the applicant.

Therefore, the applicant should clearly define in the certification plan the approval process and/or demonstration methods that will be used.

3.3. CRITERIA FOR DATABASE WITHOUT AIRWORTHINESS APPROVAL

For the databases that are not approved through the airworthiness process (not part of the type design) but that can impact aircraft safety, the applicant should consider whether the database is containing aeronautical data or not.

3.3.1. Aeronautical Database

For aeronautical databases containing other than Assurance Level 3 or routine data (NSE), the Type 2 DAT provider certificate, or equivalent, will be mandatory when Article 6 of Regulation (EU) No 2017/373 becomes applicable i.e. from 1 January 2019.

NOTE: There is a possible exception for aircraft certified for visual flight rules (VFR) operation only and their installed systems applications/equipment. Refer to Part DAT GM1 DAT.OR.100(b)(3).

When this Type 2 DAT provider certificate, or equivalent, is already available the responsibility of the applicant is limited to:

Define the database specification and associated Data Quality Requirements according to section 3.4.1, by ensuring that the Type 2 DAT certificate holder is aware of every evolution, coming from the in service experience, continued airworthiness, or the certification of new applications using the data.

Include a disclaimer in the relevant documentation (aircraft flight manual or other EASA approved document associated to the type certificate).

Example of disclaimer: The airworthiness approval of [equipment XXX] is based on using a [database XXX] from a provider with a Type 2 Data Provider Certificate (or an equivalent means of compliance) and the operator / end-user verifying the database release statement.

For example, the STC/TC applicant may impose requirements to ensure there is no confusing information presented to flight crews due to the cockpit arrangement (e.g. legacy cockpits with limited display capabilities) or based on operational considerations. Procedures, not supported by the installation, should not be accessible to the flight crew. In this case, the installed equipment should have the functions inhibited through configuration settings (e.g., strapping, software, etc.) or removed from the navigation database. An EASA DAT Type 2 certificate of the database provider may be a suitable means to ensure that the database conforms to the specification, provided that the DAT certification covers the suitable specification document (DQRs). For aeronautical databases containing only Assurance Level 3 (routine) data, the Type 2 DAT certificate is not required but the applicant is recommended to provide guidelines for operators on the use of the database.




Page 11 of 16

Note: Until 1.1.2019 an EASA Letter of Acceptance or equivalent is an accepted alternate to a DAT provider certificate.

3.3.2. Other Databases

This CM is not containing specific criteria which may be very dependent on the nature of the data. One particular example could be an Electronic Check List application (or equivalent) with an associated database.

EASA may establish specific criteria through a Certification Review Item (CRI), adapted to the specificities of each project, to address particular cases like the electronic checklist applications. When the database can be modified by the operator/end-user, the applicant should define, as necessary in the compliance documentation, the methods and mitigation means, defining the perimeter of the changes under the operator responsibility, and ensuring that there is no airworthiness impact. This would normally require to develop specific guidelines for the operator.

The use of a tool, and associated suitable practical means, may help to ensure that the database comply with its specifications and will be compatible with the certified system.

Consideration should be given to the additional aspects of section 3.4, when applicable.

3.4. GENERAL CRITERIA

The criteria in this section are to be considered when referenced in the previous sections.

3.4.1. Database Specification

The applicant should produce a detailed database specifications document, which would be approved as part of the product type design, and would contribute to the demonstration of compliance with Certification Specifications (CS XX.1301, XX.1309, CS 23.2500, CS 23.2505 and CS 23.2510) for the relevant systems.

In particular, data dependencies (refer to ED-76A Appendix B, section B.1.7.1) should be defined in terms of the ability of the data to satisfy the requirements for its safe application in the system where the database is intended to be used.

The applicant has to consider that any change in the associated equipment or applications, or certification of new functions using the data, can result in change to the database specification.

3.4.1.1. Define Data Quality Requirements

The quality of the data and the way it is processed should be characterised by Data Quality Requirements (DQR), refer to ED-76/DO-200 section 2.3. Ultimately, DQRs are to be agreed and coordinated with the equipment design approval holder or with the DAT Type 2 provider, to determine the compatibility of these DQRs with the intended use. The DQRs should be under configuration control.

If available, a Type 2 DAT provider certification or ETSOA may provide sufficient evidence that the DQRs are specified, and appropriate to meet the intended functions for standardized use and operations (like equipment certified for RNAV operations or GPWS). In some cases, standards such as ED-77/ DO-201, ED-98/DO-276, or ED-99/DO-272 provide guidance for defining the data quality requirements.

For other cases, DQRs are to be determined at time of airworthiness approval, in particular, the DQRs need to be re-examined (reviewed and adjusted) for operations not previously addressed (e.g. low RNP operations) or if data is being used for new or novel functionality compared to what was previously certified (e.g. overlay of terrain on attitude indicator).

The applicant remains ultimately responsible that DQRs are defined, including a change control process. If DQRs are defined and assessed under ETSO authorisation, the applicant should have access to the equipment supplier’s document if necessary, refer to 3.2.1.




Page 12 of 16

Where the new functionality foresees the use of data, which is not from authoritative source or not validated (i.e. data not published by ICAO member states, tailored data), the applicant should inform the operators regarding their responsibility to verify and validate the data. This should be reflected in the AFM, as appropriate, refer to 3.4.2.

3.4.2. Aircraft Flight Manual

The AFM(S) should contain all appropriate limitations or restrictions concerning the use of the equipment and applications or associated aeronautical databases (e.g. expiration, prohibited operations, etc.).

For aeronautical data, this disclaimer should state that the aircraft systems have been approved for use under the condition that the databases are compliant with the relevant specification document, or by receiving the database through DAT Provider Type 2, or equivalent.

3.4.3. Compatibility

The certification documentation should define the system function and any dependencies on the data, in particular implemented mitigation means to ensure that the operational software does not use data from databases if the data is corrupted or not compliant with specified formats or parameter ranges. These mitigation means should be documented, i.e. automatic detection mechanisms to ensure compatibility.

The requirements and conditions for updating and verifying the database should be defined in the aircraft operating instructions or equivalent document.

In the case of data covered by Type 2 DAT provider, the applicant should include a list of systems for which compatibility with intended use is ensured, including part/model numbers (hardware, software, and database) and demonstrating (e.g., using system verification tests, sampling checks, etc.) that the DQRs are consistent with the intended function of the associated equipment (see 3.4.1). This is mostly done through an appropriate arrangement of the applicant with the original equipment manufacturer (OEM) or the Type 2 DAT certificate holder at time of first certification or when proposing additions to the compatible equipment list.

It is also recommended that the applicant supports the Type 2 DAT certificate holder with periodic sampling checks on individual data sets (e.g., via simulation, test bench environment, etc.) to confirm continued compatibility.

3.4.4. Certification Testing

Equipment or applications using a database have to be shown to function properly when the loaded database is compliant with the defined DQRs. When testing is proposed for certification purposes, the applicant should perform these activities with representative databases to show that the equipment functions as intended and ensures that the testing provides full coverage of all the capabilities/options supported by the database.

3.4.5. Instructions for Continued Airworthiness

TC/STC applicants/holders should also define instructions for continued airworthiness associated to databases especially their validity when it is limited to a period of time (e.g. magnetic variation table). Minimum scheduled maintenance tasks required for securing the continued airworthiness of the system and installation are identified and published as part of the CS XX.1529/CS 23.2625 compliance.

For those databases that are time limited, the maintenance procedures necessary to update the database or suitable AFM limitations must be identified. In particular, means should be provided to check the database validity, and to inform the operator about:

When the database needs to be updated.

How this update is to be implemented.




Page 13 of 16

For databases that have the capability of being loaded with data loaders or portable devices, any considerations and required precautions associated with the loading process, including those established by the ETSOA holder, have to be properly reflected in the ICA documentation.

4. Remarks

1. This EASA Proposed Certification Memorandum will be closed for public consultation on the 30th of July 2018. Comments received after the indicated closing date for consultation might not be taken into account.

2. Comments or suggestions regarding this EASA Proposed Certification Memorandum should be referred to the Certification Policy and Safety Information Department, Certification Directorate, EASA. E-mail [email protected].

3. For any question concerning the technical content of this EASA Proposed Certification Memorandum, please contact:

Name, First Name: BONILLO-MARTINEZ, Carmen

Function: Avionics Systems Expert

Phone: +49 (0)221 89990 4147

E-mail: [email protected]

mailto:[email protected]




Page 14 of 16

Appendix A – Databases Airworthiness Approval Flow Chart

STEP 1:Identify all the Databases

in the TC/STC scope

STEP 2:Perform a Safety Analysis

(Ref. 3.1.2)

For each database

Is error in Database NSE?

Operators Guidance Recommended

End of Process

Database changes are not impacting airworthiness

Is the Database airworthiness

approved?

Goto 2Goto 3

No

Yes

No Yes

STEP 3:Database Classification

(Ref. 3.1.3)




Page 15 of 16

2

CASE 1:ETSOA

CASE 2:ED-12

CASE 3:ED-76

CASE 4:Simple DB

Refer to 3.2.1

Refer to 3.2.2

Refer to 3.2.3

Refer to 3.2.4

End of Process

No

Yes

No

Yes

No

Yes

Yes

Airworthiness approval for

each release of the database




Page 16 of 16

3

Is Database Aeronautical

Data?

Defineperimeter of the changes

under Operator responsibility

(refer to 3.3.2)

Reg 373/2017DAT Provider

Certificate Type 2 required

(Refer to 3.3.1)

Define DQRs(refer to 3.4.1)

Define use of Tools, if applicable

AFM Statement (refer to 3.4.2)

End of Process

No Yes

Documents

Notification of a Proposal to issue a Certification ......RTCA DO-272 User Requirements for Aerodrome Mapping Information ED-99/ DO-272 C/D September 2015 EUROCAE ED-98/ RTCA DO-276