Safety case

A safety case aims to show that specific safety claims are substantiated and, in the UK, that risks are kept 'As Low As Reasonably Practicable' (ALARP). In the USA, the FDA issued a guidance document in 2010 to require infusion pump manufacturers to submit safety cases as part of the 510(k)s.[2]

A definition by UK Defence Standard 00-56 Issue 4 states:[3] Such an evidence-based approach can be contrasted with a prescriptive approach to safety certification, which require safety to be justified using a prescribed process. Such standards typically do not explicitly require an explicit argument for safety and instead rest on the assumption that following the prescribed process will generate the required evidence for safety. Many UK standards are non-prescriptive and call for an argument-based approach to justify safety, hence why a safety case is required.

Safety cases are typically documented in both textual and graphical notations, e.g. using the Goal Structuring Notation (GSN).[4]

Safety Cases are becoming more popular on civil/commercial aircraft and Department of Defense (DoD) weapon systems as complexity and criticality increase. A paradigm shift is often necessary to accept Safety Cases as traditional system safety and software safety analysis and verification approaches and processes are not adequately structured to present an effective safety argument on some more modern architectures using modern development tools and formal methods.

Some major programs in the US Department of Defense, such as the F-35 Vehicle Management System (VMS) are using Model Based System Engineering (MBSE) effectively on highly complex, software intensive and safety-critical airborne system functions, along with Goal Structuring Notation (GSN). Safety Assessments and more elaborate and comprehensive Safety Cases with GSN are effective so long as Refuting Arguments and much scrutiny using traditional hazard analyses and safety approaches are included and models used to depict system behavior. More elaborate models and formal methods are being used for collective safety evidence. In the UK, GSN as part of Safety Cases have proven to be useful for providing objective safety evidence. A Safety Case is an ideal way to reflect the MBSE model, software use cases, safety architecture, safety critical functional behavior, safe states, and sequencing in the safety domain. Functional behavior is often better understood, expressed and defended when graphically displayed every step of the way in MBSE vs. traditional development with enormous paperwork that is very difficult to correlate into an effective Safety Case.

The SAE International G-48 System Safety Committee held The Safety Case Workshop at APT Research in Huntsville, AL on 15 January 2014 with several DoD agencies and leading contractors present to further study and capture the Safety Case process and methods for refinement and possible future promulgation in several Safety Standards,[5] as several already use as part of internal best practices. "There is now increasing evidence that some organizations in the U.S. are moving in the safety case direction."[6] The G-48, composed of a NASA safety Office, DoD Agencies and several leading defense contractor representatives, cite several evidence based safety advantages of Safety Cases over ANSI/GEA-STD-010 and MIL-STD-882, including 1. Upfront articulation of Arguments (rationale and claims) to be used and (2) independent review to verify and validate. Since Safety Cases are structured, evidence based approaches to satisfy the safety argument established at the start of programs, they may find a good fit in augmenting existing and proven hazard analyses methods and techniques. It is envisioned as Safety Cases gain popularity and are included in current best practices they will not replace any current effective safety methods, such as Functional Hazard Assessments (FHA), but may be included in those up front and in more comprehensive and blended safety methodologies to argument and improve capturing and documenting objective safety evidence through the program. A final Safety Case should have all of the necessary and required specific artifacts such as test evidence supporting safety claims. A well balanced Safety Case must also allow for special safety directed verification, such as testing of credible failure conditions, testing of malfunctions to observe predicted safe states and planned behavior, fault insertion for expected functionality under worse case conditions, failure immunity to ensure system ignores corruption and rouge threats, and off nominal or modified conditions, out of bounds, and other type test results to prove safety requirements are met outside normal operation.

Ideally, future Safety Case concepts, that are evolving as software intensive and high technology systems of systems gets more complex, must contain a focused data package with comprehensive safety artifacts and must be inclusive of all safety analyses, findings and determination of total summation of system risk. Safety Cases must go beyond the current MIL-STD-882 Safety Assessment Reports that are more general summary of hazard and risk based findings. Safety Cases with structured arguments, goals and objectives need to be more inclusive of various modern safety aspects, usually including requirements based safety (INCOSE), model based safety, software based safety (IEEE STD-1228), function based safety (IEC-61508, design based aerospace recommended practices for safety (SAE ARP 4761/4754A).

Agile development methods have been applied to safety case production.[7]

The review of safety cases is an important activity in the safety engineering process, performed throughout development, operation and maintenance, in which the safety case argument and evidence are scrutinized and challenged. PC: 1 Conduct Ishikawa’s Fishbone Analysis to assess the relative impact of different failures. The accident we have investigated is the fall of an employee from the third last step of the staircase. We have thoroughly investigated the accident and here are the facts and information gathered during the detailed investigation process. • Location of incident: stairs leading to the conference room • Time of Fall: Evening at approximately 9:45 PM • The witness of the accident: two employees Background of the incident • An urgent meeting was called upon; the employee was moving towards the conference room when he slipped from the third last step of the staircase. Information from Interviews • The accident area had an oil spill that was not cleaned by the cleaning staff. • The employee didn’t use the lift since the battery was being recharged and he had no other option than using stairs. • The lighting in the balcony and stairs was not as adequate as required. • There was no communication tool at the site of the incident to immediately contact medical service. • The employee was not trained on workplace safety. • Night shift work stress. • Lack of supervision by the safety warden.

PC: 2 Apply the principle of “5 Whys” for investigation of incidents.

In this step, we have used the 5-Whys technique to figure out the root cause of accident. 1st Why: Employee didn’t use the lift since it was being recharged and there is no particular procedure to make sure that every lift in the building is always working. 2nd Why: There was a little amount of oil on the staircase and floor which reflects the sub-standard cleaning system and supervision of the workplace. 3rd Why: Oil has leaked from a compressor that shows the compressor is not being inspected on regular basis. 4th Why: There is lack of machinery or equipment maintenance and repair as required. 5th Why: The employee was unable to see the oil spill due to poor lighting. Incident details Incident date 15th June, 2022 Incident time 9:45 PM Date / time reported 15th June, 2020 10: 12 PM Reported by Mr.Khilji, Finance Officer Employer of person reporting Abdullah Shaikh

Details of Injured Person(s)( if Applicable) Name Muhammad Khilji Usman Age /Sex 30 Years - Male Position Operations Officer Nationality UAE Date of hire/ ID 15 – 04 - 2017 Contact details

Witness 1 Witness 2 Name: Awais Bin Masood Name: Moiz Ali Designation: Marketing Expert Designation: Security Person Contact Details: Contact Details:

Injury Leg Fracture, Back Pain Treatment Given First Aid, Medical Examination and Treatment by Doctor Accident Mr. Khilji was moving towards conference room through stairs at approximately 9:45 PM when he fell due to oil on the surface that was leaked from a compressor.

Analysis – Highlight factors which are thought to have contributed to the cause of the incident

Task Environment Organizational Human factors Equipment

Lifting Housekeeping Poor communication Lack of experience Faulty equipment Walking Slippery conditions No policy/ procedures Lack of competence Lack of equipment Repetitive movement Excessive noise Poor job design Stress / fatigue Poor maintainance Twisting Lighting /visibility Hazards not identified Procedures not followed Wrong for task Equipment Operation Heat / cold Lack of training Improper technique Lack of signage Lack of supervision Physical limitations

Corrective Actions Supervision and maintenance to ensure lift is always in working condition. Machinery repairs and maintenance. Quick communication system to help employees communicate emergencies immediately. Safety drills. Building cleanliness and supervision to ensure there are no spills or anything that may cause such accidents Sufficient lighting equipment should be immediately installed.

PC: 3 Analyze incidents by using Ishikawa’s model for final outcome of RCA.

For the analysis, we have categorized the model into equipment/supplies, environment, policies and procedures, and human factors. We have found that every category has contributed to the accident. Firstly, the equipment contributed to the accident is oil leakage from the compressor and lift battery that was not charged. The employee was unable to use the lift and opt for stairs. On the third last step, there was an oil leaked from a compressor nearby and he slipped over it. Since there was not an emergency communication system at the site, the arrival of first aid was relatively late that further worsen his condition. The second factor is the environment and we have found insufficient lighting in a very sensitive area. Also, if the floor and staircase were cleaned properly the incident could have prevented. In terms of policies, the maintenance of equipment is lacking. Also, the employees are not well-trained on how to handle such emergencies. Finally, the information from the victim shows that he was quite stressed and also in a hurry which made him walk somewhat carelessly.

PC: 4 Produce an RCA map of the example/scenario of the incident. Considering both models, here we have listed the four differences. 1 The Fishbone diagram has helped in identifying the scenario of the accident and all possible causes in the form of systematic and graphical format. On the other hand, 5-Whys has entirely focused on the actual causes of the accident. 2 The major difference between the fishbone and 5-Whys model is the way of execution. The former is a way forward to apply the latter. 3 The main branch and sub-branches of the fishbone technique are used to organize all the “whys” to understand the root causes in an illustrative form. 4 With the fishbone technique, it’s easier to focus on the scenario of accident and symptoms. Whereas the 5-Whys model focuses on identifying the root causes instead of paying attention to history and symptoms.

• English-speaking safety case course
• French-speaking safety case course (in France)
• Spanish-speaking safety case course (in Spanish)
• Italiano-speaking safety case course (in Italiano)
• German-speaking safety case course (in German)