Software Management Control
Awareness of restrictions, airworthiness requirements and possible catastrophic effects of unapproved changes to software programmes; DO-178 design assurance levels A-E, verification, validation and configuration control of loadable software.
Software management control, summary notes
- Airborne software is part of the type design. It carries a part number and issue, is recorded in the aircraft's configuration, and may only be changed by an approved process, an uncontrolled change is an airworthiness issue, not an IT matter.
- DO-178 (EUROCAE ED-12) sets the design assurance levels by the severity of the failure condition the software could cause: A = catastrophic, B = hazardous/severe-major, C = major, D = minor, E = no safety effect. The lower the letter, the more rigorous the objectives, verification and independence required.
- Verification asks "was the software built right?" (reviews, analysis and testing against requirements); validation asks "was the right software built?" (the requirements themselves are correct). Requirements traceability links every requirement to design, code and test.
- Configuration control covers loadable software aircraft parts (LSAP): approved media, controlled data loading, verification of the part number after loading, and an entry in the aircraft technical log and configuration record.
- After a data load the technician must confirm the loaded part number and issue against the approved configuration and carry out the specified post-load test before release to service.
- ⚠ Exam trap: level A is the MOST severe (catastrophic) and level E the least, the letters run from worst to harmless, which is the reverse of most grading schemes.
- DO-178 levels
- A catastrophic · B hazardous · C major · D minor · E no effect
A software load fails part-way through. What must the technician not do, and what must be recorded?
The LRU must not be released to service in its part-loaded state, the load must be repeated or the unit rejected per the maintenance data. The failed attempt, the resulting configuration and the corrective action are recorded so the aircraft's software configuration remains traceable.
Why does a flight-control computer's software attract more rigorous objectives than a cabin lighting controller's?
Because the design assurance level follows the worst credible failure condition. Loss or malfunction of flight-control software is potentially catastrophic (level A), whereas cabin lighting has no safety effect (level D or E), so far fewer objectives and less independence are required.
Software control concept map
Software Management Control
Software management control quiz
Software Management Control, quiz
1. Configuration control of aircraft software ensures that:
The correct, approved version is loaded and traceableThe software runs fasterNo documentation is needed2. DO-178 software level A corresponds to a failure condition that is:
CatastrophicMinorOf no safety effect3. DO-178 level E software has:
No effect on safetyA hazardous failure conditionA major failure condition4. Airborne software is controlled because it:
Forms part of the approved type designIs expensive to reproduceCan be copied between aircraft types5. Verification of software asks:
Was the software built correctly against its requirements?Were the requirements themselves correct?Is the source code readable?6. After a data load, the technician must:
Confirm the loaded part number and carry out the specified post-load testReset the central maintenance computer onlyRecord the load only if a fault occurred7. A software load that fails part-way through means the LRU:
Must not be released to service until correctly loaded or rejectedMay be used if it powers up normallyShould be reset and returned to service8. Requirements traceability exists to:
Link every requirement to its design, code and testRecord who wrote each line of codeTrack software licence costs