Safety cases maintaining

A hazard may have one or more impacts and each of these should be documented in some detail. It is reasonable in most cases to focus on the impacts which would be typical rather than the rare or incredulous. Note that in some cases it may become apparent that several hazards share the same impacts and some thought may need to be given as to how this is articulated. Duplicating identical pieces of text across multiple hazards becomes cumbersome and difficult to maintain. A better strategy is to detail commonly shared impacts elsewhere such as in the body of the safety case rather than in the hazard register. Alternatively it can be worth considering whether hazards which share identical outcomes are in fact flavours of a single hazard and could be better expressed in this way. 

To provide a further level of assurance one can undertake a formal review of those operating policies which are critical for maintaining safe operation. The outcome of the review can then be documented as evidence in the safety case. A checklist of desirable policy characteristics would be one way of demonstrating that a methodical approach had been employed in the review. 

In some cases, especially where an organisation is managing a small and single product, it may be more efficient to set out the entire CRM process within the safety case itself rather than maintain this information separately. This has the advantage that the safety case becomes a self-contained justification without requiring the reader to consult extraneous material. 

In the event that a serious incident was to occur and the system put in the frame, investigators will quickly turn to the safety case. An out of date safety case is a prime target for criticism and failing to maintain such an important report brings into question an organisation s entire safety culture. Organisations need to develop trigger points which automatically and habitually prompt a review of the safety case and elicit a possible revision. 

The safety case will become outdated if it is not maintained during live service. At a minimum, an annual review should take place. 

Unlike the U.S. Final Safety Analysis Report, which is a single safety analysis document that includes both hardware and organizational (personnel) descriptions, the British safety case is a collection of documents with a hierarchical structure. The SMP is one element of the overall safety case. When a change takes place, neither the safety case nor the SMP are rewritten per se. Rather, new documents are issued describing the change. They become part of the current safety case, much as U.S. licensees maintain a collection of commitments as part of their current licensing basis. 

A safety case has to be maintained throughout the whole lifecycle of a system as changes in the system and the environment could affect the validity of the used argumentation. Such changes could be ... 

Therefore, in order to provide a solid foundation for change, every provider of a safety-related service / facility should have, and maintain, a Unit Safety Case which shows that the on-going, day-to-day operations are safe. In order to show also that such operations will remain safe indefinitely, a Unit Safety Case should also include argument and evidence that processes are in place to ensure that all changes to the service and/or system are managed safely through, inter alia. Project Safety Cases. 

To maintain the safety case we must feedback information into the safety case from operational experience. If the safety case becomes outdated and there is a loss of relevance to the system in operation, the argument upon which the safety of the system is assured loses its validity. The safety case must be used to ensure safety of the system throughout system life and (where necessary) decommissioning. At the time of certification, strategies and procedures should be included as part of the safety case to determine how this feedback process is to be conducted. If this is not done, we cannot say that the safety case will cannot give holistic assurance about the safety of the system throughout operational life. 

It has thus been identified that there is a requirement for SoSs to be accompanied by a goal-based SoS safety case. One fiction relating to SoS safety cases is that producing and maintaining an SoS safety case for a large, very eomplex and... 

Service SMP produced and maintained. HL actively maintained in specific tool. Client involved in regular hazard review meetings. HL and safety analyses updated regularly from variety of inputs. Single safety justification document produced (e.g. safety case report) and occasionally updated. Regular safety briefings to staff. PSE is more than half time on project. 

Regulations for ICT in the healthcare sector are presented in this section, with their impact on managing safety within the Trust s ICT department, for development and operational use. The impact is in the area of formal and evidenced management of safety the safety case report is identified as a key artefact to be planned, produced and maintained. The updates to EC directives for stand-alone software as a medical device are discussed. 

A safety management trail fi om supphers to the Trust needs to be established and maintained. The suppliers user documentation and safety case need to be sufficient to support the Trust s safety case(s). 

During live operational use, the occurrence of incidents may be indicative of a threat to the existing safety case (or notional safety case for older systems). When an ICT incident occurs, several things need to happen to maintain assurance that operations are at an acceptably safe level. This is a good example of how safety management principles have been embedded into the processes established to support service management as recommended by ITIL (OGC 2007). 

One of the justifications for the use of Safety Cases is that if, in the worst case scenario, the facility does have a serious accident, then it is likely that litigation will follow. A well-constructed and maintained Safety Case provides the basis of an excellent defense. Even though an accident has occurred, the Safety Case can demonstrate that management had given serious consideration to understanding the risk that their system posed and that an appropriate Safety Management System was in place. 

First developed for the nuclear and aerospace industries. Safety Cases can be used in any activity or industry that poses high risk to workers or the community. One of the first examples was in the United Kingdom where the Nuclear Installations Act of 1965 that required covered facilities to create and maintain a Safety Case in order to obtain a license to operate. Since that time other industries that have used Safety Cases include pipelines, railways, and mining operations. Moreover, in spite of the fact that the term Safety Case is not widely used in the United States, the same approach to the development and application of Safety Management Systems is, in fact, used in other American industries. For example, the U.S. nuclear and space industries prepare Safety Analysis Reports (SARs) and Mission Safety Evaluations (MSEs), respectively. These documents have the same general intent and strucmre as a Safety Case. Within the onshore process... 

The safety case is oftentimes divided into an engineering safety case—which focuses on the design and deployment (including testing) of the system and the operational safety case—which focuses on the nominal and emergency operations of the system. Both should consider the entire life cycle from design, build, operations, maintenance, modifications, and disposal and should consider the build and oper-ate/maintain system supply chain. Figure 12.4 illustrates how the system acquisition is considered in the safety case. The illustration taken from EN 50126, Railway... 

Central to the safety case is the hazard control and risk manag ent process, ensuring that risks are well managed. ALARP is used to determine how far you should go to control the hazard. The safety case process is very thorough and highly labor intensive and, if you are not careful, could become overly bureaucratic. It is just a snapshot in time of the safety of the system, so that means that it must be maintained to still be relevant. This is where bureauCTacy can take over if not careful. 

This chapter presents the arguments that the APIOOO can be operated and maintained in accordance with the safety case. 

A safety case should always justify the safety status of the associated system, therefore it is described as a living document that should be maintained as needed whenever some aspect of the system, its operation, its operating context, or its operational history changes. However, safety goals, evidence, argument, and assumptions about operating context are interdependent and thus,... 

The paper is structured as follows in Section 2 we present background information. In Section 3 we propose a technique for maintaining safety cases using sensitivity analysis. In Section 4 we use the WBS example to illustrate the technique. In Section 5 we present the related work. Finally, we conclude and derive future works in Section 6. 

---