Software Management Control
Awareness of the restrictions on changing airborne software, and of the possible catastrophic effects of an unapproved change.
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 (Level 1)
1. Aircraft software may be changed:
Only by an approved procedureBy any licensed engineerAt the operator's discretion2. An unapproved change to aircraft software is:
An airworthiness issueA minor administrative matterAcceptable if it works3. Aircraft software is identified by:
A part number and issueThe date it was writtenThe size of the file4. After loading software onto an LRU, the technician must:
Verify the loaded part number and record the changeSimply switch the system off and onTake no further action5. The possible effect of a fault in critical aircraft software is:
Potentially catastrophicAlways minorLimited to cabin systems6. If a software load fails part-way through, the unit:
Must not be released to service until correctly loadedMay be used if it powers upShould be returned to stores as serviceable7. Software used on an aircraft must come from:
Approved media and an approved sourceAny copy that matches the part numberThe maintenance organisation's own archive8. The record of which software is loaded on an aircraft is kept in the:
Aircraft configuration record and technical logPilot's operating handbookManufacturer's sales file