Implementing a Safety Case

So far we have only discussed the structure of the safety case, and now we need to consider the process for producing the safety case. Many of the problems in producing an acceptable safety case arise from an attitude that regards the safety case as a "bolt-on" accessory to the system (often produced after the system has been built). At this stage it is often discovered that "retro-fitting" the supporting safety case is both expensive and time consuming. We recommend a different approach where the safety case is considered throughout the project. In our approach we advocate:

• Integration of the safety case into the design and development process
• "Layered" safety cases, i.e. a top-level safety case with subsidiary safety cases for subsystems
• Traceability between system and subsystem levels
• "Design for assessment" which takes into account the costs and complexity of the safety case as well as the design.

The following sections describe processes for implementing a safety case. [confirm this text...]

        ▪ Elements of a layered safety case
        ▪ Traceability between levels
        ▪ Design for assessment
        ▪ The Safety Case life-cycle
        ▪ Safety Case contents

 
Example of a layered safety case
An example of a layered safety case is shown below. This starts at the top-level with the overall safety target (a worst case accident rate). This top-level requirement is progressively transformed into derived requirements for subsystems.






Traceability between levels
As shown in the figure above, the top-level requirements are transformed into derived requirement. Initially these might be attributes such as "security" or "maintainability", but at a more detailed level of implementation these requirements will be converted into design requirements that are implemented in one or more subsystems. It is important that there is traceability between these levels so that there is a clear link between the design features and the safety attributes. The subsidiary safety cases for the subsystems should identify the design features and present arguments to support claims that they implement the safety attributes. The traceability between levels is illustrated in the figure below:






Design for assessment
"Design for assessment" integrates the production of the safety case with the design of the system. Typically, some candidate design options will be identified and a preliminary safety case will be constructed. This will normally be an iterative process, which involves the identification of hazardous subsystem states (e.g. through some form of hazard analysis), and appropriate countermeasures (elimination, reduction and failure mitigation). The design and safety case are then assessed to establish whether:

• the design implements the safety functions and attributes
• the design criteria are satisfied
• the design is feasible
• the associated safety arguments are credible
• the approach is cost-effective

In this assessment process, the costs of implementing the safety system the associated safety case should be considered during the architectural design phase. This analysis should also include a consideration of the long-term safety risks and lifecycle support costs (e.g. changing the safety functions, changing the hardware, maintaining the equipment, maintaining the associated safety case, etc.)

By integrating the safety case into the design, the feasibility and cost of the safety case construction and maintenance can be evaluated in the initial design phase. This should help exclude unsuitable designs and enable more realistic design trade-offs to be made. It is difficult to be specific about the choice of appropriate design and safety case options that are likely to be both cost effective and convincing, but some general "rules of thumb" for minimising costs and risk are:

• use a simple design (eases analysis)
• avoid novelty (use established designs or components with known performance)
• ensure supporting evidence is readily available

The Safety Case life-cycle
As noted earlier, the safety case life-cycle should be an integral part of the overall system development, and this should continue throughout the lifetime of the system. Quite often, the safety case will include assumptions about the behaviour of components (e.g. reliability or fail-safe bias) which are plausible but unverified at the time the system is accepted. In this case there may be a conditional acceptance of the system, and certain "areas of concern" may need to be explicitly monitored during actual operation. The main stages of safety case evolution are listed below: 

    □ Safety functions and top-level safety attributes identification

    □ System architecture and outline safety case identification

    □ Preliminary assessment of design options:
        ▪ costs and risks (implementation and safety case)
        ▪ long-term support

    □ Progressive elaboration of the design and safety case in parallel:
        ▪ safety case requirements part of subsystem specifications
        ▪ reviews of subsystem safety cases

    □ Integration into final safety case

    □ Long-term support infrastructure plans

    □ Approval

    □ Long-term monitoring and audits
        ▪ areas of concern
        ▪ support processes
        ▪ gathering field evidence to support assumptions

    □ System updates and corrections

Safety Case contents
The safety case is "living document" which evolves over the safety life-cycle. Since it records the safety argument, the basic structure should remain broadly similar over time, but the status of the evidence will change. For example, planned levels of test coverage are replaced by test evidence on the achieved level of coverage. In practice of course the safety case could be split into several documents (e.g. covering specific subsystems) and would also refer to supporting documents (e.g. design documents, analysis reports, test reports etc.).

The following items should be included in the safety case document:

    □ Environment description
        ▪ external equipment, interfaces, failure modes, hazardous/safe states, potential changes

    □ PES safety requirements
        ▪ safety functions, reliability and other safety attributes, anticipated changes

    □ PES system architecture
        ▪ subsystems, interconnections, subsystem derived functions, integrity levels, design constraints, evidence

    □ Planned implementation approach
        ▪ PES system architecture safety argument
        (at least one safety argument for each requirement)
        ▪ identify all design assumptions used in the argument (e.g. claim limits, failure modes)
        ▪ identify supporting evidence and analyses (e.g. SHA, HRA, RAMS)

    □ Subsystem design and safety arguments
    (similar to the main safety case)

    □ Long term support requirements

    □ PES maintenance and operation procedures
        ▪ safety case support infrastructure

    □ Status information
        ▪ safety case evidence, design assumptions, outstanding concerns for subsystems, unresolved hazards

    □ Evidence of quality and safety management
        ▪ results of QA audits, safety audits, evidence that identified problems are resolved

    □ References

Note that evidence of quality and safety management is included because it is important to have confidence in the validity of the underlying evidence supporting the development of the system and its safety case.