Hazards

In practice, the differences between levels A and B are small:

• Certain objectives of the software design process must be independently verified.
• Source code accuracy, consistency, and compliance with the software architecture must be independently verified.
• Robustness of object code with low-level requirements must be independently verified.
• Test coverage of software structure (modified condition/decision) must be satisfied independently for level A, and is optional for level B and lower.


Different hazard categories require different failure rates and ifferent levels of investment in varying software engineering techniques. For example, a nuclear capable US navy cruiser had ten seperate stages of analysis (eg subsystem analysis, radiation hazard analysis, inadvertant launch analysis) which overlapped and on which the development was based, rather than being added retrofitted.



Hazard Elimination

Many hazards can be eliminated by small changes in design.
• Eg Motor reversing circuit:
  
  If the switches dont move together there is a short circuit, and a fire could occur.
  The solution is to redesign so it is intrinsically safe. Intrinsically safe software is the holy grail, however this normally requires a system level approach.
  Nuclear reactors normally have mechanical fail safes as you can never completely trust software (unless it is a tiny program that you can prove mathematically). Eg pebble bed reactors which are self controlling (as the reactive pebbles and the gas around them heat up, they push each other apart)