White Paper

3 Safety by Design The most important aspect when designing safety certifiable COTS building blocks is that safety must be built-in by design, from the start. In other words, the design process of a safety certifiable COTS building block must follow DO-254 / DO-178 process respectively for hardware and software. It is extremely difficult, if not impossible, to build-in safety retroactively if the design has not started out with safety considerations in mind. There are a number of design considerations that need to be taken into account right from the start when developing COTS safety processing building blocks, including: Determinism Safety critical products must have a deterministic behavior. Determinism is more important than pure performance. A system can be optimized to transmit a data packet in a minimum amount of time, but if it is a minimum amount of time in 99% of the cases and a very long time in the remaining 1%, that would compromise the strict order in which opera- tions are performed. Potentially a decision could be made based upon outdated information which can lead to dramatic consequences in safety critical applications. Component Selection Components are selected carefully. The complexity of components must be reduced to a minimum. For example, components with a state machine will be privileged over components with a CPU executing a firmware. In any case, certification evidences must be available for the selected components. This requires working closely with suppliers to understand their plans and roadmaps to support certification. Fault Tree Analysis Fault tree analysis is obvious but crucial to know which part of a system contributes in which way to the probability of errors. Error Detection Equally important to avoiding errors is the system ability to detect errors when they do occur. If errors cannot be avoided, they must be detected so they can be overcome by system redundancy to increase safety. An example of this is witnessed when a display projects Hazardously Misleading Information (HMI). If a display stalls and displays misleading information, the operator must be informed that it is stalled in order not to rely false data (e.g. false altitude level while in reality the aircraft is already changing its height. Data Requirement List Developing processing subsystems for flight safety certification is more than hardware and software. A major part of the safety development effort is required to document the process. These documents, called ar- tifacts or Data Requirement List, are required to prove to a certification authority that the overall system has been designed according to a pro- cess, which leads to a safe system. As a result, all of the system require- ments need to be documented: - these requirements need to be traced throughout the system development. Any change to these requirements also needs to be documented and traced, as well as the consequences of these changes. Quality Management A well-developed quality management system has to be in place. It must be able to monitor the safety development process and deal with changes that may be subsequently required.

• Cover