12.3 Data Loading, Integrity Verification and Unapproved Changes

12.3 Data Loading, Integrity Verification and Unapproved Changes

The pre-12 June 2024 detailed description for topic 5.13 closed on the possible catastrophic effects of unapproved changes to software programmes. The current Appendix I retains the broad Software management control heading and levels without that detailed sentence. This section is the practical half: how approved data loading is meant to keep the resident image identical to the released LSAP, which integrity tools are typically used, and why a wrong database or a wrong control-law load can be a catastrophic airworthiness event. The worked cases below are hypothetical maintenance scenarios used for teaching. They are not reconstructions of a named accident investigation.

Field-loadable software and approved media

Field-loadable software (FLS) is software that can be loaded into the target without removing the LRU to a workshop bench, using a portable data loader or an onboard loading function. Common industry loader protocols taught in Module 5 are ARINC 615 (often a portable data loader with storage media) and ARINC 615A (Ethernet-based loading). Older fleets used floppy discs; current fleets use optical discs, approved solid-state media or airline electronic-distribution systems that still deliver a controlled file set.

Approved media means the disc, cartridge, USB device or electronic package that the type-design holder or the operator’s approved procedure specifies. Approval covers:

• The file content (the LSAP, not a look-alike)
• The physical or electronic carrier (some USB devices are not authorised even if they electrically fit)
• Labelling, revision and quarantine in stores
• Access control so that workshop personal computers cannot silently add files

An unofficial copy made “so we have a spare in the toolbox” is unapproved media, even if the original was genuine. Copies pick up corruption, the wrong cycle, or extra files. Electronic files downloaded from an unofficial internet source are likewise unapproved. Password protection on a loader is a control against casual use; it is not permission to load unofficial content once the password is known.

Integrity verification: CRC, checksums and identity

A loader that reports “complete” has only reported that bits were written. Airworthiness needs evidence that those bits are the intended bits. Typical integrity tools specified in AMM tasks and loader design include:

[!WARNING] A CRC that passes means the image is internally consistent with the CRC that travelled with it. If the whole unofficial file was copied, the CRC may still pass. Integrity tools complement, and do not replace, part-number and effectivity control.

Interrupted loads, power loss, pulling the media early, or concurrent maintenance on the same bus can leave a partial image. AMM procedures specify recovery: do not dispatch; reload from approved media; follow the fault-isolation task if the target will not accept the load. Dual-channel systems may require both channels to be loaded and then compared. Independent inspection, where the task or the organisation’s procedure requires it, is another integrity layer: a second person confirms identity and result, not merely that a progress bar reached 100%.

Hypothetical scenario 1 — wrong navigation or terrain database

A technician is handed media labelled with a database cycle date that looks current. The files are loaded into a flight-management or terrain-awareness computer. After load, the CRC passes and BITE is green. Later it is found that the database was compiled for a different aeroplane type (different procedure set, different magnetic-variation model, or different terrain and obstacle coverage).

Possible effects in this hypothetical case:

• The crew is presented with incorrect procedures, waypoints, or terrain or obstacle cues.
• Map shifting or missing obstacles reduce the safety margin of a night or instrument-meteorological-conditions arrival.
• In the worst credible case, misleading terrain-awareness or navigation data can contribute to controlled flight into terrain, which is a catastrophic failure condition.

The DAL of the operational programme does not rescue a wrong data load. Operational databases are controlled software/data loads in maintenance practice: unapproved or incorrect data can change the aircraft’s functional behaviour even when the executable code is unchanged. Cycle control (the database effective date) is part of the same restriction: an expired cycle can omit new obstacles, temporary procedures or magnetic-variation updates.

Hypothetical scenario 2 — wrong flight-control law load

A dual-channel fly-by-wire computer accepts field-loadable operational software. Media for a different weight variant or engine standard physically fits the loader. The technician loads Channel A. Channel B still contains the previous authorised standard. Comparator monitors may trip — which is a detectable failure — or, if the mismatch is not covered by monitors for that particular difference, the aircraft could leave the hangar with asymmetric or unintended control laws.

Possible effects in this hypothetical case:

• Incorrect stick-to-surface gearing, protection envelopes or limiter schedules.
• A channel-fail reversion to a law that was never the approved law for this aeroplane.
• In the catastrophic case, loss of control because the software that satisfied DAL A objectives is no longer the software that is flying the aeroplane.

The correct hangar behaviour is: confirm IPC effectivity and service-bulletin status, load all required channels to the same authorised P/N, verify resident P/N and CRC or signature results, and do not release if any channel disagrees.

Unapproved changes: the syllabus catastrophe

Unapproved changes are not limited to rewriting source code. In maintenance they usually look ordinary:

• Using another aircraft’s media because “it is the same fleet”
• Loading an expired navigation-database cycle to get the aircraft out on time
• Editing a configuration file on a laptop to “clear a nuisance fault”
• Skipping independent inspection on a critical software load
• Accepting a 100% progress bar without reading the software status page

Each of those actions can place catastrophic-level functions (flight path, thrust, terrain awareness, stall protection) under software that has not been shown to meet its DAL. The continuing-airworthiness regulations then say the aircraft is not airworthy. The human and operational consequence can be loss of the aeroplane.

B1/B2 Level 2 application: refuse unofficial media, follow AMM integrity and identity steps, record the LSAP, and report any suspected unauthorised software as an occurrence. B3 Level 1: know that unapproved software changes can be catastrophic and must be prevented. The classification framework in section 12.1 and the part-number discipline in section 12.2 exist so that a loader session cannot silently defeat DAL A–E.