I recently discovered something interesting about ACARS. There’s no error detection or correction. None. To be honest, when I was told this I wasn’t exactly surprised, but now that I’ve had time to think about it – I’m somewhat appalled.
Note : I have recently received feedback that some of my contentions in this article are incorrect, specifically that CPDLC messages are in fact NOT encrypted. I am endeavouring to souce more accurate information and will update when I have it. For the moment – Caveat Emptor.
Some background – ACARS
ACARS : Aircraft Communicatons Addressing and Reporting System
ACARS is ubiquitous in most of today’s aircraft. Originally developed by ARINC in the late 70’s, this system is subsequently maintained by SITA and facilitates the communication of relatively short, heavily proscribed (no emoji’s!) text only messages between the aircraft and ground. Think SMS for Aircraft.
Fundamentally an Aircraft to Operator (and back) system, the infrastructure was co-opted to support the FANS CPDLC (Future Air Navigation System – Controller to Pilot Datalink Communications) initiative in the last decade. However messages sent by ATC to the aircraft are not only error checked – but encrypted as well. While no system is 100%, the likelihood of a message from ATC to the Aircraft using CPDLC (or the reverse) being eavesdropped or interfered with is extremely remote, if not impossible.
On the other hand – messages sent between the Company and the Aircraft are not, and this is an inherent weakness in the system. Rarely are these messages (or more correctly the accuracy/privacy of them) a personal concern – Weather, NOTAMS, ETA’s, Parking Bays, Messages about the Football) – all of these are zipping their way back and forth in real time, all the time. And can be read by anyone – such as here or here.
As you can see from the image included, not all messages are official. In fact when I write my memoirs, I have several anecdotes to include that refer not only to pilots (and company agents) forgetting not only that messages sent over ACARS are liable to be eavesdropped by a third party, but that messages sent to “Ops” go not only to an Operations Controller, but are often copied to an ever widening email distribution list that includes a wide array of line managers, training/standards managers, technicians and other parties …
A quick note on error checking for the technicaly interested (challenged).
CRC – Cyclic Redundancy Checking
CRC is an acronym I mentally associate with disk errors. In the old days of DOS and early versions of windows – CRC messages after a Chkdsk (Check Disk) occurred where I was given information that did not really need to be actually understood in order to communicate clearly to me that I needed a new (bigger, faster) hard drive.
In essence CRC when applied to messages sent to/from an aircraft is part of the ARINC 702 A standard for FMS communications on transport category aircraft. The ASCII contents of the message are subject to a complex algorhythm that results in a short string that reflects the content of that message. As such any changes in the message can be detected by comparing the calculation result for the message received.
So apart from sending the message, the sending system also sends a form of “checksum” result of the CRC check along with the message. The receiver subjects the message part to the identical algorithym – and compares the calculated resulting checksum with the one sent alongside the message. If the checksums don’t compare (can you hear the FMC saying “check”?) there’s a problem and the message is rejected by the receiving system.
All messages sent to the FMC Flight Management Computer (Flight Plans, Wind Uplinks, Performance Data) in the aircraft are subject to this CRC process, and validation fail is indicated by the scratchpad message “INVALID (ALTN / TAKEOFF / ATC / FLT NO / FORECAST / PERF INIT / ROUTE / WIND DATA) UPLINK”. There are other reasons for the INVALID … UPLINK message, but a CRC fail is the main one.
I’m told that the requirement for CRC dates back to the early days of the system when the ARINC/SITA system was less “Robust” and is less applicable today, although still enforced for the more critical uses of the system – such as data sent straight to the FMC, of CPDLC comunications. For a somewhat cynical view of the concept that complex systems increase in reliability over time – see below.
But in essence, messages sent between the aircraft and the airline using the ACARS system (which despite some pre-formatting options are fundamentally free text messages) for all sorts of purposes – are unsecure (not encrypted) and not subject to any sort of data validity checking.
OK – so why is this a concern?
Takeoff Performance & ACARS
Most airlines have progressed away from referencing paper manuals to determine critical takeoff performance and instead rely on some form of computer based system. While the administrative burden and cost to the company (and environment) of printing and flying around all those manuals cannot be under estimated – a number of compromises have to be made to produce a relatively simplistic set of printed solutions to the incredibly complex set of calculations that takeoff performance is in a modern aircraft – so the result is by it’s nature less than optimal. Additionally while the administrative burden of maintaining this system is clear, the potential for aircraft to be carrying around out of date manuals for months is not just folklore …
The newer computer solution can be a tablet/PC (but not a Mac!) on the flight deck used by the pilots themselves, or via a remote system where the pilots use ACARS to request a takeoff solution, specifying in the message the various parameters of Airport, Runway, Takeoff Weight, Ambient Conditions, etc. A person at Ops with a tablet/computer or (ideally) a computer server uses these values to calculate a solution and sends them back to the aircraft as a pre-formatted display on either a screen or a printout – again via non secure, non error checked ACARS. Can you see where I’m going with this?
Why not use onboard tablets/computers exclusively? As usual the devil is in the detail. Just like having books on the flight deck, keeping all those laptops/tablets up to date with a host of airport/runway and most particularly obstacle data is a significant burden – and a significant opportunity for error. Maintaining a central repository for this information reduces the cost as well as the complexity. Hence airlines save money and produce safer results with the ACARS system.
But …
If this system is used to send this takeoff performance information directly to the FMC, then as mentioned the message itself is subject to CRC and the possibility of an error being introduced is extremely remote. But (as I’ve recently discovered) – very few airlines (none that I’ve found so far …) use this option. Instead the message comes to the pilot as a pre-formatted screen/printer text display which the pilots review and manually enter into the FMC. Apart from the manual entry error problem (don’t get me started) – there’s an inherent assumption on the veracity of the ACARS system which so far I haven’t been able to evaluate.
Complex Systems get Worse, not better, with Time.
At a recent discussion, CRC was referred to as a system that was required when ACARS was in it’s infancy, rather than the developed, robust system we have today. While that’s fine as far as it goes – but in general computer based systems don’t improve with time. As time goes on, complexity invariably increases as systems once developed to achieve a pre-determined scope and volume, are forced to work outside those limits and are (eventually) expanded and developed to deal with such changes and basic growth. Those change programs are rarely projects that are well scoped/funded and rarely involve any of the programmers who built the system in the first place. If you have any interest in this at all, I strongly recommend reading through to the end Quinn Norton‘s missive “Everything is Broken“. I’ve been reading Quinn’s stuff since the early days of Boot Magazine, and she is awesome – but this particular post should resonate strongly with anyone connected to a computer (and who of us is not?)
“Your average piece-of-shit Windows desktop is so complex that no one person on Earth really knows what all of it is doing, or how. Now imagine billions of little unknowable boxes within boxes constantly trying to talk and coordinate tasks at around the same time, sharing bits of data and passing commands around from the smallest little program to something huge, like a browser. That’s the internet. All of that has to happen nearly simultaneously and smoothly, or you throw a hissy fit because the shopping cart forgot about your movie tickets.”
“NASA had a huge staff of geniuses to understand and care for their software. Your phone has you.”
“When we tell you to apply updates we are not telling you to mend your ship. We are telling you to keep bailing before the water gets to your neck.”
You get the idea …
This seems to me to be a very good reason to move towards using the system as it would seems to have been intended – Secure, Checked Data, straight into the FMC computer that needs it, skipping the Human altogether.
After all – when has that ever gone wrong?