Guidance documentation for development and testing of Safety Critical Aircraft Software. It covers the planning process, development process and integration process of software in aircraft systems, this is a similar framework as the ARP4754A but more specified towards software development.
- Objectives for software life cycle processes.
- Descriptions of activities and design considerations for achieving those objectives
- Descriptions of the evidence that indicate that the objectives have been satisfied.
As described in ARP4754A, an extensive hazard analysis is required. In the DO-178C, the severity of these failure conditions are used to determine the DAL (Design Assurance Level)
- A – Catastrophic – Multiple casualties, usually loss of aircraft
- B – Hazardous – large reduction in safety margins, flight crew cannot operate as normally, small number of casualties other than the flight crew
- C – Major – Same as above but only physical distress or possible injury to occupants
- D – Minor – Routine flight plan changes, some physical discomfort
- E – No Effect – No effect on safety
This means that effort and expense can be assigned adequately to software systems across the aircraft, from system critical software to software which would only have a minor impact. These levels are used to inform the software requirements, verification, testing and many more aspects of the development process.
Software Life Cycle
- Software Planning – Outlines the software development and integral processes.
- Software Development – Requirements, Design, coding and integration.
- Integral Processes – verification, configuration management, quality assurance, certification liaison.
Software Planning
Using the DAL (Design Assurance Level) and related Software Level, and a technique known as partitioning; systems which are functionally independent can be isolated. This reduces effort required during the software verification process and can contain faults within isolated systems.
Another method of reducing workload in the verification process is known as safety monitoring; by implementing a system which monitors function for failures, the DAL of that failure can be reduced, as long as the monitoring software is assigned the same level as the monitored function originally. It makes sense that being aware of a failure would reduce the risk that this failure presents.