Safety Demonstration
How is a safety requirement covered ?
After defining the safety requirements, they need to be demonstrated.
Three types of proofs can be used to properly cover a requirement:
Code of Practice:
- This involves norms, standards, good practices, tests, etc. It is qualitative and must unambiguously justify risk mitigation.
Explicit Demonstration:
- Determining a failure rate and Safety Integrity Level (SIL) is required. These are meant to be demonstrated later in the project as new data from the design phase becomes available. SIL includes qualitative good practices, particularly for Electronic and Programmable Electronics (especially in software development). The Failure Rate is later determined through a Failure Modes, Effects, and Criticality Analysis (FMECA) or a Fault Tree Analysis (FTA) depending on the system’s nature.
Reference to an Existing Product in Service:
- This method is challenging to implement due to the heavy impact analysis between both products. The mere fact that a mission profile could be less favorable for the new product could further complicate the process. It is to be avoided whenever possible.
If a requirement generated from our allocation analyses is not our responsibility, it can be exported in a document called Safety Related Application Condition (SRAC). It must be accepted by the concerned party. The requirements, also called exported constraints in this case, are then considered out of our scope.
In the case of simple products for individuals, it is harder to rely on an eventual exported constraint. For instance, a car dealer does not make you sign an SRAC document as a safety-related responsibility discharge for them. Instead, norms and standards are references to consider to cover safety requirements independently.
However, for products meant to be integrated into another system with a strong functional interaction, SRAC becomes, in some ways, the safety integration contract. Examples include:
- “The main transformer shall be replaced every 5 years in maintenance,” to be exported to the maintenance team or contractual company.
- “The conveyor belt shall stop whenever the stop signal is sent to it with a SIL2 and a failure rate under 3E-7/h,” considering a conveyor belt as part of the system ours is meant to be integrated into.
Naturally, SRAC is not a one-way document; we can also receive some. In this case, once accepted, it becomes our responsibility, integrates our requirement synthesis, and needs to be covered/proven by ourselves.
How to demonstrate a safety requirement?
Let’s remind what has been allocated from the Wiper Preliminary Risk Analysis (See chapter Safety Allocation)
- The wiper system shall be tested in accordance to the SAE J 903
- The function to wipe the windscreen, shall be SIL4 and have a failure rate under 1E-9/h
Let’s consider hypothetic SRAC the client would have exported to us:
- A light indication of the chosen speed shall be displayed to the driver with a Basic Integrity Level (SIL0) and a maximum failure rate of 1e-5/h
How to demonstrate a safety Requirement with a COP?
The demonstration of a qualitative requirement referring to a norm or good practice shall be supported by a test report, a calculation note, an audit, or any other proof of conformity.
In the example “The wiper system shall be tested in accordance to the SAE J 903”, the norm SAE J 903 will be followed as a guideline along with the corresponding test reports.
A comprehensive technological qualitative analysis may be conducted if the submission of a simulation report or test report alone does not adequately cover the risk. This analysis aims to explain why the feared failure is highly unlikely to occur. It focuses on each component that could lead to the feared event, and each link in this safety chain is thoroughly reviewed in this manner.
How to demonstrate a safety Requirement from a similar product already in service?
There is no standard method for this case. It may be chosen when the explicit demonstration cannot achieve the expected target. The form will depend on available data, use cases, and assessor advice. A deep understanding of the safety process is crucial to providing consistent information to the assessor and facilitating more constructive exchanges. This enables the quick assembly of appropriate information.
How to demonstrate a safety Requirement with an explicit demonstration?
The explicit demonstration of safety requirements constitutes the core activity of the safety engineer in the second part of the design phase. It represents the most calculatory aspect, often executed with dedicated software. The most commonly employed modeling method is the Fault Tree Analysis (FTA), highly appreciated for its ease of implementation.
The previously quoted requirements will preferably be demonstrated with an explicit demonstration :
- The function to wipe the windscreen, shall be SIL4 and have a failure rate under 1E-9/h
- A light indication of the chosen speed shall be displayed to the driver with a Basic Integrity Level (SIL0) and a maximum failure rate of 1e-5/h
How to demonstrate the global safety of a system?
In addition to demonstrating safety requirements, the overall safety of a system can be assessed with a Safety FMECA. In certain processes, a Safety FMECA can be considered as already covered by the Preliminary Risk Analysis if there is extensive return on experience with hazards. The assumption here is that a “perfect” allocation should export all the necessary requirements to cover the system’s safety comprehensively.
However, an FMECA is particularly meaningful in simplex systems, meaning systems that are not safety redundant. In other words, these systems contain a significant proportion of components that can directly lead to safety-related failures.
Furthermore, on products that function as subsystems within a larger system and are assessed separately, an FMECA is often desired by the integrator. This is because the supplier may not always have the same level of return on experience as the integrator, making it challenging to create a robust enough allocation without a detailed FMECA analysis.