How are avionics updates delivered?
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.




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




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.



Updating A380 navigation using flash drives