If you wish to contribute or participate in the discussions about articles you are invited to join SKYbrary as a registered user

 Actions

Corrupt Data in Distributed Integrated Aeronautical Information Package (Hz13)

From SKYbrary Wiki

<protect> Important notice This article is a demonstration of functionality under development, do not consider its contents as valid yet.


Article Information
Category: Hazards Hazards
Content source: SKYbrary About_SKYbrary
Content control: EUROCONTROL EUROCONTROL
Associated ATM Functions
Tag(s)
  • Information management-Aeronautical Information Service

Hazard Description

HAZ001 - Distributed IAIP contains valid but corrupt aeronautical data

Aeronautical Information (AI) is valid but corrupt in terms of accuracy, resolution, and format. In addition AI made available at the wrong time means essentially that the effective dates are corrupt and therefore is a case of valid but corrupt AI.

Hazard Identification Document

CHAIN Preliminary Safety Case

Context

The following points were made in relation to this hazard:

  • There are over 10,000 business rules designed to detect errors (e.g. if there is a runway threshold at 09, there should be one at 27). These rules are defined by the individual businesses, although they can use the standard EUROCONTROL data checking rules. These checks will not detect all errors. The rules can be very complex and they can find errors where data should have changed in multiple places but has not. The business rules are validated by testing, and in AIS, the person who enters the data in the Data Preparation stage (i.e. the AIS data handler) is the person who would enforce these rules. There are occasions where the rules need to be ignored in order to propagate the data. This is handled by forcing the data through by exception.
  • There can be no reliance placed on Data Originator checks as some Data Originators are not interested in reviewing AIPs. The regulator should look into enforcing this feedback.
  • The triple checking on critical/essential data is carried out by three independent people by triple, blind entry. The field is only committed when three matching entries have been made.
  • AIS can check the format and completeness of surveyed data, but not the accuracy of it. Relative inaccuracy of individual data items (in relation to other data) is easier to detect than absolute inaccuracy.

Assumptions

The case of ‘Not valid but corrupt Aeronautical Information’ was not considered because it was felt that invalid data is implicitly detected (by the definition of validity).

Causes

  • Unverified authentication and validity of status of data
  • There is no standard format of electronic or paper representations of IAIPs particularly across States, or management of different formats, due to current technical limitations (e.g. older versions of Flight Management Systems)
  • Not all States adhere to common geospatial referencing system
  • Corruption in received published AI for distribution
  • Where visual checks are carried out, the probability of visual checks carried out at within Data Distribution processes to detect errors depend on the knowledge and experience of the people performing them
  • Manual transfer of AI from Data Publication to Data Distribution
  • Published AI not reviewed by Data Originators prior to its release
  • Valid but corrupt effective dates provided by Data Origination or data accuracy errors provided by Data Origination not detected by processes within Data Publication
  • Lack of independent mechanisms in Data Preparation within Data Publication to detect corruption in raw data received from Data Originators
  • Incorrect approved Evaluated Raw Data provided to Data Preparation
  • Use of unauthorised originators as sources of providing data to Data Publication
Note
In general, the interface of origination of data to AIS has been characterised as weak There is a need for regulation of the Data Providers in recognition of the safety-related nature of the information being provided. Due to lack of regulation, there are no rules for setting up as a data provider and the success of such an enterprise rests mostly on earned reputation. Also, there are no clearly defined boundaries of responsibility for correctness of data.

Causal Prevention and Mitigation(s)

  • Include information on the source and any amendments to data as well as the validity status of the data
  • Mandate a standard digital format for AI interchange for AIS e.g. Aeronautical Information Exchange Model (AIXM), Electronic AIP (eAIP)
  • Mandate a standard geospatial referencing system
  • Develop training procedures for visual checking
  • Develop standard procedures for performing visual checks
  • Develop robust procedures for manual transfer of AI using double or triple checking
  • Produce specification for automated transfer of AI between actors
  • Define Service Level Agreements between actors
  • Mandate review of IAIP by Data Originators.
  • Develop specification for automated business/integrity checking tools
Note
  1. Application of business/integrity rules at Data Handling can be either manual or automated. Automated application of the rules increases the probability of detection of errors over manual by one order of magnitude.
  2. The probability of visual checks carried out at various points in Data Preparation (at Data Handling, Data Co-ordination, Data Edition and Data Cartography) to detect errors depend on the knowledge and experience of the people performing them. The probability of success of the check carried out by an experienced person over the probability of success of the check carried out by a less experienced person increases by one order of magnitude.
  • Develop specifications for automated initial checking of Raw Data
  • Develop specifications for validation of automated tools
Note
  1. Initial Check of Raw Data processes (within Data Publication) can be manual or automated. In both cases, errors can be generated by human error or ill-defined processes, however the more manual the process, the higher the frequency of error generation due to human error. However, not all processes can be automated
  2. Where Initial Check of Raw Data processes are fully automated or where software tools are used to enhance the manual processes, systematic faults in such tools (e.g. software bugs) can credibly corrupt AI. The frequency of corruption by such tools is high since often these tools are not subject to validation.
  • Develop standard data quality control procedures
  • Mandate standard AIS quality procedures
  • Introduce monitoring of data origination errors
  • Mandate use of authorised data originators only
  • Define Service Level Agreements between actors
  • Mandate Service Level Agreements
  • Define rules for setting up as a data provider
  • Define roles and responsibilities for Data Chain Actors

Effects

No effects were identified with respect to provision of ATM services. However if the error manages to pass undetected through the whole of the Data Chain, then there would be consequences for flights if the pilot does not detect the error. The rest of the identified consequences were all in relation to actors involved in the current Data Chain (i.e. Upstream and Downstream).

  • Evidence gathered from reported non-compliances in the supplement to Annex 15, suggests that components of the current Data Chain do not meet all of the requirements of International Civil Aviation Organisation (ICAO) Annex 15. In particular it is unclear if any AIS have demonstrated compliance with the integrity targets.
  • Within individual stages of the Data Chain, people are not necessarily familiar with the use of data at the other end, and therefore have limited understanding of the potential impact of data errors, or where their responsibility begins and ends with respect to the correctness of data.

The following identified issues are relevant to Upstream Data Chain:

  • Data Users do not always feedback data errors, but it is vital that the error is reported to the State AIS as detection of errors is not a sufficient mitigation on its own.
  • Synchronisation of data is problematic as data has got wider use than just for publication purposes and there is lack of confidence regarding usage of the latest version of data amongst all users. There is a degree of cross checking between organisations, so it is possible to detect inconsistencies through regular communications, e.g. with State AIS. However, these checking activities are not mandated. (One of the benefits of pan-European use of European AIS Database (EAD) is that AI can be cross-checked at an international level).
  • Manual transfer of information introducing a high number of errors. Processing of aeronautical data within current Upstream Data Chain can be manual or automated. In both cases, errors can be generated by human error or ill-defined processes, however the more manual the process, the higher the frequency of error generation due to human error; however, not all processes can be automated.
  • State distributed IAIP having a different representation to the representation of data used by Data Application/Integration and Data Use is currently an issue, especially where the representation is paper-based.
  • There is a need for standardised format of electronic or paper representations of IAIP across States or management of different representations across States.




Source Document

Further Reading

Commission Regulation (EU) No 73/2010 of 26 January 2010 laying down requirements on the quality of aeronautical data and aeronautical information for the Single European Sky

Flight Information Publication (FLIP)</protect>