12.2 Software Configuration Management and Part Numbering

12.2 Software Configuration Management and Part Numbering

Once software has been classified and released, airworthiness depends on knowing exactly which programme is on the aeroplane. Configuration management is how design organisations satisfy DO-178C/ED-12C configuration objectives, and it is how Part-145 and continuing-airworthiness organisations prove that the aircraft still matches the type design. The maintenance restrictions historically detailed under topic 5.13 are enforced in the hangar through part numbers, effectivity and approved publications, not through informal filenames.

Hardware part number versus software part number

A hardware part number identifies a physical LRU, module or cabinet: the metal, connectors, circuit cards and any resident firmware that is not field-loadable. A software part number identifies a loadable software aircraft part (LSAP) — the executable, calibration file or database that is installed into that hardware. These identities are not interchangeable:

• One hardware P/N can legally host several authorised software P/Ns over its life (different software standards, operator options, or service-bulletin upgrades).
• The same software P/N may be loadable into more than one hardware dash number if the type-design holder has shown compatibility.
• Changing software does not automatically change the hardware P/N printed on the data plate, which is why software status must be read from BITE, a configuration report, a software status page or a load report, not only from the hardware plate.

Treat the approved configuration as a tuple: aircraft identity + hardware identity + software identity + modification and service-bulletin status. Recording only the hardware P/N after a software load is an incomplete airworthiness record.

Loadable software aircraft parts (LSAP)

Industry practice, reflected in documents such as ARINC 667 guidance for field-loadable software and in certification material on loadable software aircraft parts, is to treat field-loadable software as an aircraft part. That means:

• It has a unique software part number (and often a media or distribution part number as well).
• It appears in the Illustrated Parts Catalogue (IPC) or equivalent parts data for the aircraft effectivity.
• It is procured, stored, quarantined and issued under the organisation’s parts procedures, not as a casual computer file.
• Loading it is a maintenance task accomplished in accordance with the Aircraft Maintenance Manual (AMM) or other approved data, not an informal information-technology update.

Students routinely confuse four related identities in examination questions. Keep them separate:

Some manufacturers encode a software configuration index or loadable-software information in central maintenance computers so that a printout lists every resident LSAP. That printout is only as good as the last authorised load and the last successful interrogation. If the computer cannot be interrogated, the AMM will state the alternative method — often a front-face display, a dedicated status page, or a loader read-back.

Effectivity

Effectivity is the rule that says which aeroplanes a given software part may occupy. It may be stated by:

• Aircraft manufacturer serial number (MSN) or line-number ranges
• Model or variant (for example a different engine, weight variant or flight-control standard)
• Embodied service bulletin or modification number
• Operator-unique options that still sit inside the approved type design or an approved change

Loading a software part that is in the IPC for a different MSN range is an unapproved configuration even if the part is genuine, sealed and supplied by the manufacturer for another aeroplane. Effectivity is as much an airworthiness limit as the part number itself. Two aeroplanes of the same type design can legally require different software parts because one has embodied a flight-control software service bulletin and the other has not.

[!NOTE] Media is not the part. A compact disc or approved USB device is a carrier. The airworthiness article is the LSAP part number that the AMM tells you to verify on the target after loading. If the media label and the resident P/N disagree, stop; do not release the aircraft.

AMM and IPC control

The IPC (or illustrated parts data) answers: what software part is authorised for this effectivity? The AMM answers: how is it loaded, tested and recorded? Related approved data include service bulletins for software upgrades, airworthiness directives that mandate a software standard, and the operator’s approved maintenance programme references. Part-145 staff use the current revision of that approved data. A workshop notebook, a forum screenshot or a copied file from another operator is not approved data.

Typical AMM software-load tasks require the following sequence:

1. Confirm aircraft identity and effectivity.
2. Confirm target hardware P/N, location and, where specified, channel (left/right, A/B, COM1/COM2).
3. Confirm the authorised software P/N from the IPC, service bulletin or airworthiness directive as applicable.
4. Use approved media and the specified data loader (often ARINC 615 or ARINC 615A).
5. Carry out the integrity checks specified in the task.
6. Verify the resident software P/N on the target or via the central maintenance system.
7. Record the load in the technical log and aircraft records, including software P/N, media identity, date, and who accomplished and who inspected where dual inspection is required.

Configuration management also forbids uncontrolled mixing. Flight-control channels, dual flight-management databases and IMA hosted applications often have compatibility sets. Loading Channel A to one standard and Channel B to another, or mixing a navigation-database cycle with an incompatible operational programme, can produce comparator faults — or worse, undetected disagreement.

Continuing-airworthiness organisations

The CAMO (or equivalent continuing-airworthiness organisation) owns the configuration baseline for the fleet: which software standards are embodied, which service bulletins are open, and which aircraft may accept a given LSAP. The maintenance organisation executes the load. If the two are not coordinated, a technically successful load can still place the aircraft outside the operator’s approved configuration. Release to service after a software load is a statement that identity, effectivity, procedure and records all match.

Stores control belongs in the same story. An LSAP issued from quarantine with a goods-inwards check against the purchase order is a controlled part. A file copied onto a personal USB device in the crew room is not. Electronic distribution systems used by some operators are acceptable only when they remain inside the approved procedure: access control, virus checking as specified, checksum or signature verification, and retention of the issue record.

Category B3 Level 1 knowledge is the recognition that software has part numbers and must not be swapped casually. Category B1/B2 Level 2 knowledge is the ability to use AMM and IPC effectivity, distinguish hardware from software identities, and record LSAP status as an airworthiness artefact.