Software

• Published in: System Health Management pp. 513 - 519
• Main Author: Scandura, Philip A
• Format: Book Chapter
• Language: English
• Published: Chichester, UK John Wiley & Sons, Ltd 15.07.2011
• Subjects: data capture; defensive software design; exception handling; multi‐version software; poor requirements; recovery blocks; RTCA/DO‐178B; software failure tolerance; software‐related accidents
• ISBN: 9780470741337; 0470741333
• DOI: 10.1002/9781119994053.ch32

The chapters in this part have discussed in depth the role of subsystem health management as implemented by various aircraft and spacecraft subsystems, such as propulsion, structures, power, avionics, flight control, and life support. Generally speaking, each of these subsystems consists of a collection of hardware and software components, all operating in a coordinated fashion to provide the desired functionality. Faults occurring in a subsystem can affect its ability to correctly provide that functionality, unless they are mitigated by some means such as failure‐tolerant designs, redundancy management, etc. Experience suggests that the faults specifically addressed by these means are hardware faults, while those occurring in software are covered somewhat serendipitously. There are those who maintain that, unlike hardware, software does not break (i.e., it does experience physics of failure or wearout mechanisms) and therefore diagnostic methods are not necessary. That having been said, software is subject to implementation failures caused by shortcomings in requirements, coding, testing, etc., resulting in in‐service problems that can play havoc with fielded systems. In this chapter we explore the concept of software as a subsystem, and the role it plays in subsystem health management.