📖 The lesson
Why software needs special control
Software now flies, navigates and controls the engines. A fly-by-wire computer, a FADEC or a flight management computer is only as safe as the program inside it. Software also fails differently from hardware:
- It does not wear out. Software failures are design errors that were there from the start, waiting for the conditions that trigger them. Every copy contains the same error, so redundant computers running the same program can all fail together.
- It cannot be fully tested. Even a modest program has more paths and input combinations than could ever be tried, so testing alone cannot show it is correct.
- It is easy to change — a few seconds with a data loader — and a change cannot be seen by inspection.
For these reasons airborne software is part of the type design of the aircraft or equipment. It is approved with it, identified by part number, and changed only through the same approval process as any other design change.
How airborne software is approved
- Software is approved as part of a type certificate, supplemental type certificate or ETSO authorisation. The authorities (EASA, the FAA and DGCA) accept RTCA DO-178C / EUROCAE ED-12C, "Software Considerations in Airborne Systems and Equipment Certification", as the means of compliance (EASA AMC 20-115D, FAA AC 20-115D).
- DO-178C does not specify a programming language or method; it sets objectives for planning, requirements, design, coding, verification, configuration management and quality assurance, and requires evidence that each objective has been met.
- Complex electronic hardware (programmable logic) is assured to DO-254 / ED-80, and aeronautical data such as navigation databases to DO-200.
- The software level (development assurance level, DAL) is set by the worst effect a software error could have, found by the system safety assessment. Level A covers software whose failure could be catastrophic; level E software has no safety effect.
- Higher levels need more objectives and more of them verified independently — by someone other than the developer.
Part numbers and configuration
- Every approved software version has its own part number, separate from the hardware part number of the LRU. Many LRUs show their hardware part number and modification status on the nameplate, and their loadable software part number on a separate label and on an ident page displayed through the MCDU or maintenance terminal.
- Only certain hardware/software combinations are approved. The illustrated parts catalogue (IPC), service bulletins and the AMM define which software may be installed in which hardware on which aircraft, and any intermix rules — for example whether the left and right engine controls or flight management computers may run different versions.
- The operator's continuing-airworthiness management records the configuration of every aircraft. After any software change, the records must match exactly what is installed.
Kinds of software and data
| Type | What it is | Who may change it |
|---|---|---|
| Field-loadable software (FLS) | Software that can be loaded into an LRU while it is installed on the aircraft, using a data loader | Maintenance staff, only with the approved part number and per approved data |
| Option-selectable software (OSS) | Approved options built into the software, selected by program pins or a configuration file (for example engine thrust rating or equipment fitted) | Only the options approved for that aircraft |
| User-modifiable software (UMS) | Parts of the software the approval lets the operator modify within defined limits, without re-certification — for example ACARS company message formats or condition-monitoring reports | The operator, under its own controlled procedures, without affecting the certified functions |
| Databases | Navigation database (updated every 28-day AIRAC cycle), terrain and obstacle databases, magnetic variation tables, airport maps, performance data | Loaded on schedule from approved data suppliers; the correct cycle must be active |
Navigation database
The FMS holds two navigation database cycles: the active one and the next one, which becomes active on its effective date. Loading the wrong cycle, or flying with an expired database, can lead to wrong routes, procedures or approaches — and therefore to controlled flight into terrain. The FMS ident page shows the active cycle and its dates.
Loading software
- Confirm that approved data (a service bulletin, engineering order or AMM task) calls for the change, and identify the exact software part number required.
- Use only media or files from an approved source, kept under control — write-protected, virus-checked, and today often distributed electronically with digital signatures.
- Load with the specified equipment — portable data loader (ARINC 615), onboard or laptop network loader (ARINC 615A) — following the AMM. Do not interrupt power during the load.
- Verify: the loader checks the files' integrity (CRC or digital signature); then confirm the loaded part number on the ident or configuration page and check any intermix requirement.
- Test as the AMM requires — BITE or an operational test.
- Record the change (old and new part numbers) in the aircraft records and issue the certificate of release to service.
Restrictions and airworthiness requirements
- Install only approved software, of the exact part number specified, from an approved source. Never load software that is merely "newer", from another aircraft, or from an unofficial copy.
- Maintenance staff must not modify software, or use unapproved tools or laptops on aircraft networks.
- Software loading is a maintenance task that must be performed and certified by authorised staff, and recorded like any part change.
- Respect intermix rules between redundant units, and check that the hardware is compatible with the software.
- Protect the integrity of software and data: controlled storage of media, access control to loaders and networks, and the newer information-security (cyber-security) requirements.
Possible catastrophic effects of unapproved changes
- An unapproved or wrong version can disable or corrupt a function the crew depends on — engine control, flight controls, navigation, warnings — in ways that are not visible until the conditions arise in flight.
- Mismatched versions in redundant computers can cause disagreements, nuisance disconnections or loss of both channels.
- Wrong configuration or calibration data can make a correctly working program command the wrong thing. In 2015 an Airbus A400M crashed shortly after take-off on a test flight after engine-control calibration data had been inadvertently erased during software installation, so that three engines did not respond correctly to the throttle levers.
- Latent design errors exist even in approved software: in 2015 the FAA required Boeing 787 generator control units to be powered down periodically, because an internal software counter would overflow after 248 days of continuous power and could cause loss of all AC electrical power. Strict configuration control is what allows such problems to be found and fixed across the whole fleet.
Remember
Software is a part: it has a part number, it must be approved for that aircraft, and changing it is a maintenance action that must be verified, tested, recorded and certified. "It loaded successfully" is not the same as "it is the approved configuration".