Have you ever heard of “CRC” and “RTCA DO-200”?
These things are critical for airborne navigation, as they ensure we get to the place we actually want. This post is all about getting navigation data from the "books" to the aircraft in order to successfully navigate the globe...
The provision of aeronautical data and its distribution are generally governed by ICAO Annex 15 [1]. This Annex was introduced in 1953 and has evolved ever since. ICAO member states historically also got their guidance for publishing aeronautical data from the Aeronautical Information Services (AIS) manual, ICAO document 8126 [2]. The introduction of RNAV waypoints and later the PBN concept have dramatically elevated the importance of data handling. Back in 2008, the ICAO Air Navigation Commission initiated a transformation of the guidance material, changing the terminology from “Aeronautical Information Service” to “Aeronautical Information Management” [3]. The efforts culminated in the publication of a new document, called PANS Aeronautical Information Management (PANS-AIM, ICAO document 10066) [3]. It is undoubtedly targeted at a more digital infrastructure and contains quite specific instructions for software coding. In parallel, the avionics industry developed standards for data handling, such as RTCA DO-200, as we shall see later.
What is the matter?
In the early days of aviation, pilots used landmarks and light beacons to navigate. They were later replaced by radio beacons, such as NDB or VOR. The pilot or navigator would look up a beacon’s parameters on a map and then tune the specific frequency on the receiving equipment. He would then listen for the identification (a Morse code) and subsequently use the readout to determine the aircraft position. This paradigm imposed a heavy mental workload on the flight crew, but the “navigation data” (i.e. the maps) were quite primitive.
Today, the opposite is true: The creation of “navigation data” has become a complex undertaking and at the same time, the mental workload for the flight crew to find the way from Paris to Moscow is quite low, as pilots can simply enter the destination using a dedicated interface (see Figure 2). There is just one problem: What if the waypoint in the aircraft database would be in a different location than the same waypoint on the map? This would obviously be a recipe for trouble and therefore it is vital that the integrity of our navigation data is ensured. But let us look in a step-by-step manner at how the aeronautical data is promulgated:
Data distribution
Traditionally, aeronautical data is distributed via a system of common effective dates, known as “Aeronautical Information Regulation And Control” (AIRAC) [1]. ICAO document 10066 specifies an aeronautical data catalogue, in order to facilitate the creation and distribution of digital data sets by the AIS of each member state [3]. This also serves as an effort, to enable the transition from “paper AIP” as a reference to digital sources including meta data [3].
In a simplified way, the flow can be described as in Figure 3 above. The states publish official data in their AIP. It is then “translated” into a code which is "machine readable", in this case: ARINC424. Then it is up the equipment manufacturer to format the data so that it can be stored on a particular memory of a product. Starting with the creation of "raw data" there are many steps involved and also multiple entities. So there are several occasions for the data to be corrupted...
Not everything is equally important
It is obvious that the coordinates of a runway threshold as part of an RNP approach need to be strictly protected against corruption, while the radius of an en-route Fix-Radius-Transition (FRT) is less critical. ICAO Annex 15 stipulates three categories of data: Critical, essential and routine [1]. If we dig deeper into the industry standards, we find that there are associated probabilities for “undetected corruption” [4]:
Critical data: Less than 10^-8
Essential data: Less than 10^-5
Routine data: Not specified
The magnitude of these numbers will look familiar to everyone involved in aircraft safety assessment. It is important to understand that these numbers are applicable across the entire process and therefore also include any automated processes used for translation or formatting. As an example of "critical data", we will look at the code of an RNP approach:
Industry standards require national authorities to publish a so-called Final Approach Segment (FAS) data block for type B approaches, including its "CRC remainder" (more on that in the next paragraph…)
The FAS data block is essentially a table of all the key properties of an approach.
Cyclic Redundancy Check (CRC) (for the mathematically inclined)
The CRC process was proposed in the 1960’s and has been adopted in many communication applications since. It is quite simple to implement in hardware, as it relies on polynomial division and modulo 2 arithmetic [7]. The idea is brilliant: At the transmitter side, the data is divided by a so-called “generator polynomial”, which creates a remainder. (There are many rules as to how to choose the generator polynomial, but that would be beyond the scope of this article…). The CRC remainder is then “added” as a bit-sequence to the data. On the receiver side, the data string together with the CRC remainder are now divided by the same generator polynomial. This division will have no remainder, if all worked correctly. The reason for this is, that we are using binary division and modulo 2 arithmetic. Should there be a new remainder, the data would have been corrupted [7]. A single changed bit will therefore be immediately detected.
There are significant drawbacks of CRC though, and it is being replaced more and more by Reed-Solomon codes and hash functions [7]. The two major problems are that it does NOT protect against intentionally introduced errors and it’s capability to be used for error correction is quite limited [7]. The former being increasingly relevant as aircraft data management is getting in the focus of cyber-security…
The pilot – last line of defence
No matter what computer and algorithm we use, they all have one thing in common: The old programmer mantra: “GIGO” Garbage in – garbage out. So even the most sophisticated hash function will not prevent errors that are made right at the start of the process, during the data definition phase.
Therefore it is absolutely vital for every pilot to have a healthy level of skepticism towards the “green line” on the navigation display. A good practice can be to compare “desired tracks” and distances and to speak up and take action if something does not look right…
Revision/20191009
References:
[1] ICAO Annex 15, 16th edition, 2018
[2] ICAO AIS Manual, doc 8126, 6th edition, 2003
[3] ICAO PANS-AIM doc 10066, 1st edition, 2018
[4] RTCA DO-200A, standards for processing aeronautical data, 1998
[5] RTCA DO-201A, standards for aeronautical information, 2000
[6] AIP Germany AIRAC 07/17
[7] Matloff, Cyclic Redundancy Checking, Dept. of computer science, University of California, 2001