Aircraft Software Management Control

Aircraft Software Management Control

Aircraft software cannot be seen or touched, yet it must be treated like any other aircraft part. An unapproved software change can lose an aircraft. This module answers four questions: how bad a software failure must be to count as dangerous (five levels A to E), which documents and traceability DO-178B/C require, how software and data are loaded onto the aircraft (FLS, LSAP, UMS, OSS, DFLD), and how to know a loaded file is not corrupt (checksum, CRC), with two live demos.

Tooley ch.13 (p.207-217) · EASA Part-66 Module 5.13 lecture notes (6 pages) · Floyd ch.2 section 2-12 and ch.11 section 11-11

Software is an aircraft part

According to Tooley (ch.13), software covers executable code (programs), the data the programs use and the embedded operating systems. All of it needs periodic upgrading and fixes for problems found in service. The consequences of failure range from insignificant to catastrophic (a major avionics failure, engine faults).

An Airworthiness Directive demanding a software fix: a real example

Tooley Figure 13.1 quotes an Airworthiness Directive (ATA 73, fuel and control, EEC software modification). Six in-service events had occurred: loss of engine parameters in the cockpit together with a frozen power setting on that engine. Investigation traced it to a fault in the engine software. A safety assessment found it could cause hazardous asymmetric thrust if it happened during the take-off roll and the crew tried to abort. The directive requires introducing revised engine software.

The five software levels A to E

Example applications by level (Tooley Table 13.2)

Certification: software, hardware and system safety

Tooley Figure 13.2 shows that the hardware and software life cycles are tightly interrelated: a hardware configuration change always requires a software configuration change. The safety assessment process (SAP, AMC 25.1309 and ARP 4761) runs in parallel with the system development process (ARP 4754), which splits into hardware development (DO-254) and software development (DO-178B).

Initial certification requires the design organisation (DO) to provide evidence that the software was designed, tested and integrated with the hardware to DO-178B/ED-12B. A software configuration management plan (CMP) must be effective throughout the life of the equipment.

Who may change software after certification?

Post-certification modification of equipment at levels A, B, C (catastrophic, hazardous, major) must not be made unless first approved by the DO. Hence all software upgrades and modifications are subject to the same approval procedures as hardware modifications. Every modification must be identified and controlled in accordance with the CMP; guidance is in DO-178B/ED-12B and DO-178C/ED-12C (2011).

DO-178B/ED-12B: the standard and its required documents

"Software Considerations in Airborne Systems and Equipment Certification" was published by RTCA in 1992 (DO-178B) and by EUROCAE (ED-12B). FAA and EASA use it as certification guidance to decide whether software will perform reliably in aircraft systems. It establishes design assurance levels from a safety assessment process and hazard analysis, examining the effect of a failure condition in each system.

Beyond code: the documents that must exist

Besides source code and executable object code, the standard demands documents and life cycle artifacts (question 13-1): airworthiness certification plan, software quality assurance plan, software configuration management plan, configuration control procedures, code standard, design standard, requirements standard, development plan, verification plan, design document, requirements document, traceability, test cases and test procedures, verification results, quality assurance records, configuration management records, problem reports and a software accomplishments summary.

Level A for flight control and navigation; ARINC 653

Flight control and navigation are flight critical and so need Level A certification: failure may cause multiple fatalities and loss of the aircraft. Cabin entertainment sits at the other end (Level E), except that the crew must be able to override it for announcements. Normally different levels do not run on the same processor, unless an approved software partitioning scheme such as ARINC 653 is used.

ARINC 653 (Avionics Application Standard Software Interface) is a specification for space and time partitioning in a real-time operating system, letting one processor host applications of different levels. Used in IMA systems, it isolates critical functions from non-critical ones so one failing application cannot take down the whole IMA system.

DO-178C and its supplements

When DO-178B was published, most software was hand-coded. Later automatic code generation from models became common, so the boundary between high-level system requirements and low-level software requirements needed clarifying, and a way to verify model-based software was needed (can simulation or formal methods replace part of testing). Hence DO-178C in 2011. In July 2013 the FAA issued AC 20-115C recognising it.

Requirements traceability by level (Figure 13-1)

Figure 13-1 draws the traceability required between certification artifacts under DO-178C. Red: level A software only. Purple: levels A, B, C. Green: levels A to D. Level E: no traceability, because it is non-critical. Level A executable object code must be "robust" with respect to the software requirements, i.e. respond correctly to abnormal inputs and conditions.

Demo: which traces does each level demand?

Choose a level in the box at the bottom of the page (Demo 2) to see the allowed probability, typical applications and required traces. Suggestion: compare level A with level B to see exactly the two red traces that differ, then B with C to see they share one set.

Rule drawn from Figure 13-1: the number of required traces grows with severity: D (green) is smallest, B and C (green and purple) are equal, A (red, purple, green) is largest.

Field loadable software (FLS)

FLS is executable code that can be loaded into a computer while it is installed in the aircraft, by a mechanic/technician following maintenance manual procedures. Three main types:

• LSAP (loadable software aircraft part): software meeting a specific airworthiness or operational requirement; not part of the approved design, so it is an aircraft part needing formal release documentation. Examples: EEC, DFDAU, APU ECU, flight guidance computers (FGC).
• UMS (user modifiable software): declared by the type certificate holder as intended for modification within the constraints set at certification; operators usually upgrade it themselves. Examples: ACMS, IFE.
• OSS (option selectable software): approved components the operator may activate within boundaries defined by the certificate holder. Examples: IMA units.

Database field loadable data (DFLD) and why it is treated like code

DFLD is data that can be field loaded into the databases of target hardware. The database itself is an embedded item residing in the hardware and is not field loadable; "loading" is merely writing new data or overwriting old data from a file. The file may be natural binary (most compact but unreadable by people), BCD or hexadecimal (more readable).

Updating a database usually affects aircraft performance; invalid or corrupt data may cause erratic or out-of-range behaviour. So a DFLD needs its own unique part number and release documentation, like an LSAP. Example hardware: FMC, TAWS, IMA.

Distribution and release: Form 1, Certificate of Conformity

Three ways to distribute: storage media (floppy disk, PCMCIA card, CD-ROM, onboard replaceable module OBRM), electronic transfer (laptop, hand-held or portable data loader over a serial link or temporary bus connection), electronic distribution (no intermediate media).

The register and the quarantine rule

The operator must keep a register recording: the current version of the FLS/DFLD installed; which aircraft have it; which systems it applies to; its functions; where and on what media it is stored, who is responsible and who may access it; who decides an upgrade is needed and authorises it; a record of every copy traceable to the original source.

Loading EEC software with a PDL

1. Make sure electrical power to the EEC is off.
2. Connect one end of the PDL cable to the loader.
3. Disconnect the EEC electrical connector.
4. Connect the other end of the PDL cable to the EEC.
5. Connect the 28 V DC source to the loader cable: brown (+), black (−), shield (chassis ground).
6. Load: the correct disk for channels A and B (NVM and operating program); turn on 28 V DC to the loader; turn on 115 V AC (400 Hz) to the EEC; the same version for left and right engines; disk not write-protected; insert the disk within 5 minutes; the PDL loads automatically in about 12 to 16 minutes and shows LOAD COMPLETE; on failure the transfer-fail lamp lights, check the cables, remove power and retry, no more than three attempts.
7. Remove all power from the EEC and loader.
8. Remove the loader and reconnect the EEC cables.
9. Run the memory verification program: PASS for the EEC part number and checksums is correct; FAIL usually means the hardware part number did not match the software part number.
10. Write the software version, Service Bulletin number and date on the EEC's metal plate.

Checksum and CRC: two ways to detect a corrupt file

Checksum: add the values of consecutive bytes (or words) and append the result to the file. When preparing to load, recompute and compare; if different, do not use the file.

CRC: divide consecutive blocks of binary data by a fixed number; the remainder is appended as check digits. On re-checking, if there is no remainder the file is assumed error-free.

Tooley: both only indicate that a file has become corrupt, but neither is completely fool-proof.

Try Demo 1 at the bottom of the page: press "Swap two bytes" and "Two errors that cancel" to see exactly why.

Floyd: parity, CRC and the ROM checksum

Parity (Floyd 2-12, p.110): a parity bit makes the number of 1s always even or always odd; it detects a single bit error (or any odd number of errors) but not two errors in one group. ARINC 429 (Module 05) uses odd parity.

CRC (Floyd 2-12, p.111 to 114): a seven-step process. Example 2-41: D = 11010011, G = 1010. Append four 0s to get 110100110000; divide modulo-2 by 1010 for a remainder of 0100; the transmitted code is 110100110100 and dividing it again leaves 0.

ROM checksum (Floyd 11-11): the checksum is the XOR sum of each column of bits, carries discarded; the test flow is Figure 11-75. Chapter 11 Problem 37 (already in Module 04) asks whether a ROM's contents are correct.

Wrap-up: the control chain from requirement to aircraft

1. Classify the failure consequence: levels A to E.
2. Standard DO-178B/C: documents and traceability by level.
3. CMP: identify and control change through the life cycle.
4. Approval by the DO for levels A, B, C.
5. Release LSAP/DFLD with records: Form 1, Letter of Acceptance.
6. Load by procedure, same version, quarantine when in doubt.
7. Verify with checksum/CRC and the verify program.
8. Record: version, SB, date, register.

Checksum, CRC and probability levels

• b_ivalue of byte i of the file
• mod 256keep only the low 8 bits, because the checksum is one byte
• Ggenerator code, known in advance to both sender and receiver
• modulo-2addition/subtraction without carry, i.e. the XOR gate (Floyd Table 2-9)

📜 Theory and historical background

According to the lecture notes, the need for software control arose when modern aircraft came to contain millions of lines of code across dozens of computers. RTCA published DO-178B in 1992 and EUROCAE the equivalent ED-12B; FAA and EASA use them to judge whether software will perform reliably on aircraft. Early software was mostly hand-coded; later, automatic code generation from models (MATLAB, Simulink, Embedded Coder) became common, so the boundary between high-level system requirements and low-level software requirements needed clarifying, and a way to verify model-based software was needed. DO-178C was therefore developed in 2011; in July 2013 the FAA issued Advisory Circular AC 20-115C recognising DO-178C as a means of compliance for the software aspects of airborne systems.

🔎 Case study: loading software into an electronic engine controller (EEC)

Tooley describes the EEC loading procedure with a portable data loader (PDL). Switch off power to the EEC, connect the PDL cable to the loader and to the EEC, supply 28 V DC to the loader, switch on 115 V AC (400 Hz) to the EEC, check the correct software version disk (the same version for the left and right engines) and that the disk is not write-protected, then load for about 12 to 16 minutes. If it succeeds the PDL shows LOAD COMPLETE; if the transfer-fail lamp lights, check the cables and try again, at most three attempts. Finally run the memory verification program: PASS for the hardware part number and checksums means the EEC is correctly programmed, then write the software version, Service Bulletin number and date on the EEC's metal plate. Each step maps to a principle of this module: correct version (traceability), integrity check (checksum), record keeping (controlled release).

⚠️ Common traps (and where the lecture notes are incomplete)

General trap: believing that a checksum or CRC proves the software is correct. They only detect that a file changed; Tooley states plainly that neither method is completely fool-proof (see Demo 1: swapping two bytes or two cancelling errors fool the checksum). Second trap: mixing up FLS and DFLD; DFLD is data, but it still needs its own part number and release documentation like executable code. One place where the lecture notes are incomplete: Question 13-6 asks which trace is required only at level A, and the printed answer names only source code to executable object code, yet the notes' own Figure 13-1 draws two red arrows (level A only): besides source code to object code there is also software architecture to high-level requirements. Tooley itself uses both "Level" (Table 13.1) and "Class" (multiple-choice question 4) for the same concept. On the Floyd side: the CRC division in section 2-12 appends as many zeros as the generator has bits (4 bits means 4 zeros), whereas the standard CRC appends the generator length minus one; both give a zero remainder on a correct reception, so this is a difference of presentation, not an error.