There are two things that characterise the development of software for critical systems: their importance and their difficulty. These are systems in which a failure or an error in their operation may result in the loss of human life, loss of the equipment itself or significant damage to the environment. These systems are known as a safety-critical system (SCS) or a life-critical system.
Critical systems in aeronautics
One of the sectors where this type of software is most relevant is aeronautics, although it is also common in other types of industries such as automotive, medicine, nuclear, etc.
Given the possible implications of a software malfunction in an aircraft, it must be developed with special care; inspecting, documenting, testing and verifying the system adequately. The aim is to improve the quality of critical system software to minimise the possibility of a bug that could potentially have serious consequences.
The reference document used by the main authorities (such as the FFA and EASA) to ensure the quality of software installed on aircraft is DO-178C. Certification authorities require compliance with the level of criticality that this standard specifies in accordance with the Design Assurance Level. These levels establish the rigour that is required in order to comply with DO-178C.
Criticality levels according to the Design Assurance Level (DAL)
The software level, also known as the Design Assurance Level (DAL) or Item Development Assurance Level (IDAL) is set according to safety criteria and risk analysis, taking into account the possible consequences in the event of a system failure. The function of the DAL is therefore to define the level of requirements to be applied to the different components of the electronic system. The higher the severity of the consequences, the more secure the system must be.
This severity and the associated safety requirements are divided into five levels according to the possible consequences that the failure could have for the equipment and the people on board:
- Level A – Catastrophic: a component failure would significantly affect the operability of the aircraft (flight and landing) and could cause its destruction and the loss of life. For example: a failure of the flight controls.
- Level B – Hazardous: a failure in these systems would pose a major threat to the lives of those on board. It would also affect the controllability of the aircraft personnel because they would have to work under enormous stress and/or workload. This could lead to serious injury or even death. For example: a failure of the aircraft braking systems.
- Level C – Major: a failure in this system would reduce the safety margin, significantly increasing the workload of personnel to operate the aircraft. This could lead to passenger discomfort or even minor injuries. This is similar to the previous level, but less severe. For example: a failure of backup systems.
- Level D – Minor: the consequences of the failure would have a minimal effect, causing no more than a nuisance among passengers or staff, who could remedy the situation. It could involve a change to the flight plan. For example: a failure of ground navigation systems.
- Level E – No effect: a failure would have no effect on safety, aircraft operability or personnel workload. For example: a failure in the aircraft entertainment systems.
Criticality levels and failure rates
In hardware equipment, it is possible to quantify the safety of an item by calculating its probability of failure over a given period of time. This type of measure cannot be applied to software.
Therefore, instead of specifying the failure probabilities of critical system software, a rate per flight hour is set, in line with the DAL level (levels A – E). As can be seen below, the higher the level, the higher the requirement for this failure rate:
- Level A – Catastrophic: probability less than 1×10-9 per flight hour
- Level B – Hazardous: probability less than 1×10-7 per flight hour
- Level C – Major: probability less than 1×10-5 per flight hour
- Level D – Minor: no safety metric
- Level E – No effect: no safety metric
Importance of Safety-Critical Systems Integrity
The ultimate goal of critical software development is to achieve a level of safety whereby all software functions perform as expected during the operation of the aircraft. As mentioned above, this task is complex and, from a development point of view, it is important to achieve it within reasonable timescales and cost.
The task becomes even more complex when several systems interact with each other. It is therefore important to analyse both the functions of the critical software and the potential risks beforehand in order to carry out the development with all this information in mind. Once this process is carried out, all causes of potential failures and their consequences will be identified, evaluated and eliminated, or at least reduced to acceptable safety levels.
Other methods used to establish criticality levels
Safety Integrity Level
The Safety Integrity Level (SIL) is a similar system that measures the performance required for certain safety levels. For example, in the European safety standards, 4 SILs are defined, with level 4 being the most severe and 1 the lowest.
The SIL is determined by evaluating the development process, safety lifecycle management, risk analysis, etc. As with the DO-170C standard, for each SIL level, a probability of failure occurrence is required, called Probability of Dangerous Failure per Hour (PFH).
Centum: experts in critical software development
At CENTUM we have more than 10 years of experience providing design, development and software certification services for critical, embedded and real-time systems (DO-178B/C, DO-254, ABD-0100, ABD-200, ARP4754, ARP4761). We have our own software laboratory that operates according to one very simple paradigm: error is not an option. If you would like more information, please do not hesitate to contact us.
