13
$\begingroup$

I'm idly curious to know what type of physical storage medium (e.g. is it a "mini-CD", USB key, a little hard drive, maybe a tape) is used for delivering avionics updates, for an as-recent-as-possible aircraft?

For big (e.g. commercial airliner) and/or military?

I guess you're not downloading updates from the internet?

Could you (optionally) also paint a vague public-domain picture of how the "chain of trust" works? Or is the delivery route (media passing hand to hand) not especially secure, and instead all the chain of trust is in built-in digital signatures?

$\endgroup$
8
  • 1
    $\begingroup$ used for delivering avionics - do you mean updates? $\endgroup$
    – Simon
    Aug 6, 2015 at 11:28
  • 2
    $\begingroup$ It might be too broad. I am familiar with 2 methods, but these may well be specific to manufacturers/systems. An a 1990s vintage FMC, you accessed a hidden settings page through key presses documented in the maintenance manual but not the user manual. You could update the software from a "dongle", plugged into a port in the avionics bay by providing a password code which was unique to the system and operator. I am guessing that the dongle has been replaced by USB key in more modern implementations. The data was encrypted by the manufacturer and decrypted on loading by the FMC. $\endgroup$
    – Simon
    Aug 6, 2015 at 12:00
  • 3
    $\begingroup$ Another system used line replaceable boards with the EEPROMs (read only memory that retains it's contents when powered off and can be reprogrammed) which plugged into a chassis accessed via a maintenance panel. In this way, the entire software load was replaced rather than simply being updated. If I read your question correctly, you may be assuming that updates are somehow done over a network (hence your question about chain of trust) which whilst I don't know, I suspect does not happen since security would be a big concern. $\endgroup$
    – Simon
    Aug 6, 2015 at 12:06
  • 5
    $\begingroup$ @Simon Even if they're not 100% up to date, your comments do seem answer-worthy to me. $\endgroup$ Aug 6, 2015 at 13:51
  • 1
    $\begingroup$ @ToddWilcox I am one of the "long of tooth" around these parts ;) $\endgroup$
    – Simon
    Aug 6, 2015 at 17:31

3 Answers 3

8
$\begingroup$

Different kinds of Software

We need to distinguish between several categories of software.

  • Field-loadable software (FLS) is, loosely defined, any software which can be reconfigured, updated, or uploaded by technicians and manufacturers, like the avionics software.

  • Aeronautical databases are not categorized as field-loadable software and are treated separately in regulations. These aeronautical databases may be a terrain database, a navigation database, an obstacle database, or an airport map database.

  • Factory loaded software, which is assumed not to change during without replacing the device it's on. To change factory-loaded software you often have to break a seal and flash the memory. It may also be on read-only memory like an EEPROM.

Thanks to advances in FLS practices, field-loadable software is being used in many places where factory-loaded software had been used previously and frequent software updates are becoming common on most systems. Software on virtually any part can be field-loadable if it follows safety and integrity measures.

Aeronautical databases are treated differently in part due to the difference in update frequency. An aeronautical database must change frequently (often more than once a month), while avionics updates are less frequent and may be less than once a year (especially because the entire aircraft configuration, software included, must be certified).

What steps are taken to update software?

A patent by Airbus explains the process excellently, even with diagrams in French:

The first step is managed by the manufacturer of the aircraft. The latter decides upon a required modification for the aircraft it has constructed. It develops the modification for the solution found and certifies it with the certification authorities. The manufacturer thus shows that the new configuration proposed is compatible with the environment and with the configuration of the aircraft for which the modification is destined. Once the solution has been developed and validated, the manufacturer prepares a pack, referred to as service bulletin, containing a description of the operations to conduct to perform the modification of the aircraft and also a physical element containing the software to change and furthermore containing corresponding documentation. The physical element containing the software depends on the size of the software and it may for example be a USB key (USB standing for “Universal Serial Bus”), a CD/DVD, etc. This pack is delivered physically to the company concerned that operates the aircraft. This delivery may also be performed electronically.

The second step is carried out under the responsibility of the operator of the aircraft, for example an airline company, or, when the aircraft is under heavy maintenance under the responsibility of the maintenance organization authorized for that. Similarly, this step may be performed by an authorized MRO (standing for Maintenance Repair Organization) when the aircraft is transformed for a change of operator. This is typically of the case for an aircraft hire company. The operator receives the service bulletin and transfers it to a technical center (FIG. 1) in order for the operator to allocate and verify the compatibility of the service bulletin received with the environment of the aircraft of its fleet. Once the verifications have been performed and the service bulletin validated, a work request is sent to the maintenance management department of the operator's fleet. That department then defines the times (stopover, heavy maintenance visit, etc.) at which the aircraft may undergo that update and provides the workshop with the software element to install on the aircraft (USB key, DVD, etc.).

A maintenance workshop of the airline company or of a maintenance repair organization performs the requested task and downloads the software which is in the DVD or USB key (or other medium). The action is recorded and the configuration repository of the aircraft is updated. Of course, the technical center (and possibly other departments concerned) is kept informed of the upgrade which has just been carried out.

schematic showing how software gets to an airplane over USB, LAN, or disks

Navigational database updates were traditionally updated using a similar process according to this Honeywell patent:

... the information contained in the navigation database changes on a very frequent basis as new navigation aids are created, old navigation aids are retired, airports add or retire runways, or the like. Accordingly, government agencies such as the United States Federal Aviation Administration (FAA) typically require that aircraft update navigation databases on a regular basis, such as every twenty-eight days. Other components (such as global positioning systems (GPS)) may also make use of periodic data upgrades.

Conventional techniques of updating databases have been cumbersome and time consuming. Typically, a customer (such as an airline) obtains a diskette containing the upgrade for a particular aircraft type from a database or component vendor. The customer then duplicates the diskette and distributes copied diskettes to service technicians, who then go to individual aircraft and manually load the data update using a specialized data loader...

See also https://www.google.com/patents/US20030208579 for an example of how in-flight entertainment systems are traditionally updated.

What media is used?

A variety of media has been used over time since storage media changes quickly. Physical media like CD's are quickly being replaced by high integrity network updates due to the cost benefits involved.

A patent for a "Method for controlling customer-implemented data updates" explains how this process was done historically:

Originally, airline maintenance personnel upgraded flight management computers by using an ARINC standard 603 portable tape upload device, but such tape loaders were clumsy and slow. Manufacturers then progressed to data loading computers that were based on ARINC standard 615 (Data Loader standard), which is in essence a software protocol layered onto an ARINC standard 429 data bus. ARINC 615 data loaders abandoned the tape format of ARINC 603 in favor of a 3.5-inch floppy diskette medium for transferring data and software... The software or data for these updates has grown increasingly more complex as the systems in aircraft provide more functionality to the cockpit crew and traffic control.

In more recent history, "The media used to load FLS changes with time. In the early 1990's, 3.5 inch diskettes were used. For example, the original Boeing 777 carried around binders full of floppy disks. The technology has moved on to compact disks (Cds), digital video disks (DVD's) thumb drives, mass storage devices, and even local area networks (LANs)" source

Another patent discusses in detail the way that software can be loaded over LAN. The image below is from the patent. The principles are much the same:

  • The software must be part of a certified aircraft configuration
  • Aircraft in the fleet are checked over the network to see if their configuration is out of date or incorrect
  • Aircraft are updated to a new configuration when and only when the operator initiates the update
  • A reliable integrity check like a CRC is in place to make sure the update over LAN was successful

flowchart of the process for updating software

What safety and integrity measures are taken?

Fun fact: Field loadable software is considered a part, and therefore the configuration management that applies to parts also applies to software updates. The updated software must be certified for the aircraft configuration it's on, must have a part number which can be verified, and must appear on the bill of materials for the new aircraft. Sometimes an entire device will have a new part number when its software is updated, or sometimes the software has a separate part number that's updated while the hardware retains its own part number. Any modifications to the software must go through a change-impact analysis and recertification.

The field loadable software must be certified for the device and aircraft it's being loaded on and there must be checks on the software loading process, the software itself, the software part number. DO-178C specifically specifies that:

  • there must be protection from inadvertent loading (which also means that unlike Windows, it won't force you to update at the worst possible time)
  • there must be detection of failed, partial, or corrupted loads
  • you must be able to reliably determine that the currently loaded software and all its files are correct (for example, by using a CRC)
  • if a display mechanism is used to display the software load, the display must be accurate and reliable

Integrity checks must have a level of reliability, similar to other reliability check in aircraft. This often means that the software loading must have a 10^-9 chance of corrupting software or incorrectly indicating the software load is correct. You can instead qualify the tool used to load the software, but this is less common than showing that the integrity checks are reliable.

Chain of Trust for Aeronatuical Databases

For aeronautical databases, safety levels and error checking are also seriously considered. Each particpant in aeronautical database creation and transmission must have a compliance plan, configuration management, error checking, a method to ensure unauthorized changes don't occur, and quality management. As outlined in AC 20-153, The FAA will provide a Letter of Acceptance (LOA) to each particpant in this process indicating their compliance with regulations like DO-200A. Aeronautical data must meet various standards as applicable like ARINC 424 and DO-291B, but a discussion of those is out of scope of the question.

For more information:

Chapter 5 of FAA Order 8110.49 specifically addresses approval of field-loadable software. RTCA's DO-200A is the standard for preparing and transmitting Aeronatuical databases from a regulated data provider to the operator of the aircraft. See also FAA AC 20-153 for certifying compliance and granting letters of Acceptance to DO-200A. I have heavily referenced "Developing Safety-Critical Software" by Leanna Rierson. I suggest you reference this or another book.

Disclaimer: I am not a DER or engineer for the data loading process and so this information is for reference only. For technical work please consult the source documents and a DER instead of relying on this information.

enter image description here

Updating A380 navigation using flash drives

$\endgroup$
2
$\begingroup$

The Rockwell Collins FMS units found in many large airliners are updated via USB stick. you can find a nice video here on how its done. Most GA planes use SD cards (or other similar card formats) these days. Some people chose to use apps like ForeFlight on their iPad which is updated via the internet.

As for the "chain of trust" Rockwell Collins requires a subscription to their FMS database downloads however they are downloaded straight from the internet. There is a list of addendum and alterations which some airlines apparently have. In reality the medium is not "secure" as you mention but tampering with it would be in violation of some FAR (I'll try and find the one) since you would potentially create a hazardous situation. I'm sure airlines and A&P shops are diligent about these updates the same way they are about any maintenance. I'm not sure if there is any software level encryption on the data.

For apps like ForeFlight and some of the more GA directed markets (that are not using full FMS systems) the FAA makes all of their charts available in digital form for free. I would assume this is where places like ForeFlight get their data and then, as a user, you download it from the ForeFlight servers. Again you pay a subscription to ForeFlight to guarantee that these things are on line and up to date. Again this is all not very secure (in a manner of speaking) and you are relying on ForeFlight to not tamper with the maps. When talking about updating the maps in a GA plane chances are it's your plane and you are responsible to ensure its safe operation. Garmin seems to make their downloads available right on their site.

$\endgroup$
3
  • 1
    $\begingroup$ I'm confused as to how this answer is correct. The question specifically asks about Avionics (like EFIS for example) and this answer is all about maps for the FMS. They aren't really the same thing and very very different standards for quality assurance. I really don't think this answers the question as stated. $\endgroup$
    – Jay Carr
    Aug 19, 2016 at 17:06
  • $\begingroup$ FMS was used as an example, being one of the older digital units out there its a nice example of how things have changed over time as well. Take for example the G1000 Flight deck, that is updated all via SD cards following a similar method as the FMS. $\endgroup$
    – Dave
    Aug 23, 2016 at 5:17
  • $\begingroup$ It most likely doesn't use encryption, but digital signatures which would prevent tampering. It might use obfuscation though to make analysis (and theft of intellectual property) more difficult, though. $\endgroup$
    – forest
    Jun 23, 2019 at 6:09
1
$\begingroup$

In general aviation applications, navigation database and software updates are downloaded over the internet from the avionics manufacturer, and stored on an SD card, which is later inserted into an SD card slot in the bezel of the avionics in the aircraft.

Downloads are restricted to registered subscribers.

$\endgroup$
4
  • $\begingroup$ So, the update is essentially delivered over the internet. This raises an important question, is there any cryptographic signature on those software package; and the equivalent of Secure Boot mechanism, that is now common on new PCs. $\endgroup$
    – Lie Ryan
    Sep 8, 2015 at 12:39
  • $\begingroup$ @mins: I don't see what's your point with the link. That link seems to show an implementation bug in some Secure Boot implementation, which has nothing to do with the idea of Secure Boot itself. $\endgroup$
    – Lie Ryan
    Aug 19, 2016 at 12:32
  • $\begingroup$ @mins: The core idea of Secure Boot is to prevent users from unknowingly install/run malicious/tampered OS. Secure Boot isn't intended to prevent the device user/owner from intentionally installing/running uncertified OS. $\endgroup$
    – Lie Ryan
    Aug 19, 2016 at 12:38
  • $\begingroup$ @LieRyan : If you want to discuss on the chat, as here is not the place to. I'm going to post my answer. $\endgroup$
    – mins
    Aug 19, 2016 at 13:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.