SAFETY CASES AND SAFETY REPORTS To my children If you can’t be safe, at least be careful Dad Safety Cases and Safety Reports Meaning, Motivation and Management RICHARD MAGUIRE B.Eng MSc C.Eng MIMechE MSaRS © Richard Maguire 2006 All rights reserved No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording or otherwise without the prior permission of the publisher Richard Maguire has asserted his right under the Copyright, Designs and Patents Act, 1988, to be identified as the author of this work Published by Ashgate Publishing Limited Gower House Croft Road Aldershot Hampshire GU11 3HR England Ashgate Publishing Company Suite 420 101 Cherry Street Burlington, VT 05401-4405 USA Ashgate website: http://www.ashgate.com British Library Cataloguing in Publication Data Maguire, Richard, 1968Safety cases and safety reports : meaning, motivation and management 1.Industrial safety - Management 2.Health risk assessment I.Title 363.1'12 Library of Congress Cataloging-in-Publication Data Maguire, Richard, 1968Safety cases and safety reports : meaning, motivation, and management / by Richard Maguire p cm Includes index ISBN-13: 978-0-7546-4649-5 ISBN-10: 0-7546-4649-1 Industrial safety Authorship Safety management Inventories Public records I Title T55.3.A87M34 2006 658.3'82 dc22 2006020647 ISBN-10: 7546 4649 ISBN-13: 978 7546 4649 Printed and bound in Great Britain by MPG Books Ltd, Bodmin, Cornwall Contents List of Figures List of Tables Preface Acknowledgements ix x xi xiii Accidents and Safety Introduction The Safety Case The Safety Case Report Health and Safety Plan System Safety Approach Documentation Control of Major Accident Hazards (COMAH) Summary 1 5 11 The Language of Safety The Concepts of Language The Language of Risk, Chance, Probability and Hazard The Origins of Chance, Risk and Probability The Origins of Hazard The Origins of Safety and Safety Case Modern use of Safety Language Development of the Safety Case in the UK Development of Safety Reports in the US Summary 12 12 13 14 15 16 17 17 19 20 The Safety Management System The Components of a Safety Management System Designing a Safety Management System Safety Management Planning Example of a UK Safety Plan Example of a US Safety Plan Safety Planning Meetings 22 22 23 25 25 26 27 The Purpose of a Safety Case Why Are You Constructing a Safety Case? The Safety Case as a Record of Residual Risk Safety Cases as a Management Tool During Change Safety Cases as a Record of Engineering Practice 30 30 30 31 31 vi Safety Cases and Safety Reports Safety Cases as a Tool in a Court of Law Safety Cases as a Marketing Tool Safety Cases as a Route to Fewer Accidents Understand your Particular Purpose(s) 32 32 33 33 The Requirement for a Safety Case Why Do You Need a Safety Case Anyway? Legislation for Safety Cases Evidence for the Need to Have a Safety Case Goal-based and Prescriptive Requirements 34 34 34 37 38 Setting a Safety Boundary What is a Safety Boundary? Deriving the Safety Boundary Boundary Diagrams When a Diagram Might Not Work Other Boundary Considerations 41 41 42 43 44 44 Measuring Safety Performance Judging Safety Performance Measurement Scales Safety Measurement Scales Event Severity Scales Event Frequency Scales The Risk Matrix for Communicating About Safety Populating a Risk Matrix Special Note The Layout of a Risk Matrix The Final Check Summary 47 47 48 49 49 52 55 56 60 60 60 61 Safety Targets The Role of Safety Targets Setting a Safety Target Quantitative Targets Target Apportionment Quantitative Targets in Use Qualitative Targets 62 62 62 63 63 64 65 So Far as is Reasonably Practicable So Far as is Reasonably Practicable The ALARP Concept Demonstrating ALARP The Accident Tetrahedron Problems with ALARP as a Safety Target Real Use of the ALARP Process in Industry The GALE Principle 67 67 68 69 70 71 72 73 Contents vii 10 Individual, Group and Population Risk Sharing Risk Individual Risk Group Risk Population Risk Use of FN Curves Worker vs Public Risk Multiple Safety Targets in a Safety Case 76 76 76 77 80 82 82 83 11 The Safety Team Why Have a Team at All? What the Team has to Do Who is in the Team? The Project Safety Committee Forming a Safety Committee Who Owns the Safety Case? 85 85 86 87 88 89 90 12 Costs in Safety The Measurements of Costs The Cost of Having Accidents The Value of a Prevented Fatality Cost Indicators from Criminal Fines Cost Indicators from Other Fines 92 92 92 95 98 98 13 Techniques and Tools for Safety Cases Introduction HAZOP Structured What-if Technique (SWIFT) Fault-tree Analysis Event tree Analysis Zonal Analysis Failure Mode Effect Analysis (FMEA) Human Hazard Analysis Human Reliability Analysis Stored Energy Analysis Summary 100 100 100 101 103 105 107 108 109 110 111 112 14 The Hazard Log The Role of the Hazard Log The Requirement for a Hazard Log The Content of a Hazard Log Examples of Real Hazard Logs 113 113 113 115 115 15 Human Factors in Safety Cases Introduction to Human Factors The Human Caused the Accident The Human Prevented the Accident 120 120 120 123 viii Safety Cases and Safety Reports Human Systems Integration Safety Documents from the Human Factors Domain Human Factors Analysis Summary 125 126 127 130 16 Software Factors in Safety Cases Introduction to Software Factors The Software Caused the Accident Commercial-off-the-shelf (COTS) Systems Software of Uncertain Pedigree (SOUP) How to Treat the Risks of Software Software Testing Methods Safety Documents from the Software Domain 131 131 131 133 134 135 139 141 17 Management Factors in Safety Cases Introduction to Management Factors The Managers Caused the Accident Managers and the Law Promoting a Safety Culture Evidence from Managers for the Safety Case 144 144 145 146 147 149 18 Independent Safety Review The Principles of a Review How Independent is ‘Independent’? A Review by the Regulators Assessor, Advisor or Auditor Competency of the Reviewer The Terms of Reference 152 152 152 153 153 155 156 19 Presentation of the Safety Case Introduction to Presenting Safety Cases The Paper-based Safety Case Recommended Layouts for a Paper-based Safety Case The IT-based Safety Case Recommended Layouts for an IT-based Safety Case Goal Structuring Notation Tool Support 158 158 158 159 162 163 165 20 Maintenance of the Safety Case What Happens to Safety Cases? Managing Change Review and Update Cycles 168 168 170 171 Epilogue Index 172 173 List of Figures Figure 6.1 Figure 10.1 Figure 10.2 Figure 13.1 Figure 19.1 Figure 19.2 Figure 19.3 Example of a Safety Boundary Diagram Typical FN Graph Typical FN Graph with Possible Real Risk Aversion Factor Example of a Fault-tree Principle Elements of Goal Structuring Notation Principle Elements of Claim Arguing Notation Example Goal Structuring Notation Structure 44 81 81 105 164 165 166 162 Safety Cases and Safety Reports Having now seen the significantly large content requirements for each of these approaches, it is not difficult to see how these documents can quickly become extensive in size and complexity This can make them very difficult to manage and maintain over time, as required in many safety case approaches The IT-based Safety Case With the advent of powerful computer technology and additional information technology tools and processes, it is now possible to present a safety case in a totally electronic format This goes much further than just being a paper document in an electronic file format, even with the template capability and section to reference hyper-linking available in many contemporary word processing packages In these situations, the safety case is still constructed and maintained with paper in mind as a presentation and recording format A digital system for constructing a safety case is now possible, where recording evidence and safety arguments can be done wholly within the IT system Presentation is done using the graphical-user-interface (GUI) of the system using dedicated notations, and the availability of external hyper-linking using shared file directories and even the (secure functionality of the) internet Together, they can provide direct access to all the required standards, test reports, and safety related reference documents from internal and other system domains Advantages of using an IT-based system include as follows: ƒ ƒ ƒ ƒ ƒ ƒ ƒ ƒ ƒ ƒ Ability to utilise all functionality of the IT system Allows direct hyper-linking to all required information and evidence IT systems are now in place at all worksites Updating and issue can be done on a one-to-many posting process Full graphics and multimedia capability supported File and data storage can be more efficient More complex safety arguments can be supported Standard notational styles may be used Can still print out on paper if required Allows more complex searching tasks The disadvantages of using an IT-based system include the following: ƒ ƒ ƒ ƒ ƒ ƒ ƒ ƒ ƒ All users have to have similar IT systems All current and future users have to be trained to use the IT system Lack of competence in the tool can erode confidence in the safety case All readers have to understand how to read/use IT systems Frailties of viruses and software bugs in IT systems can cause data loss Dedicated tools can be expensive Difficulty in introducing new systems into large organisations Tailoring to existing organisational practices requires specialist knowledge Levels of commercial security may prohibit internal/external hyper-linking Presentation of the Safety Case 163 ƒ Hyper-links may fail and cause loss of configuration control ƒ Some standards required all tool use to be subjected to the safety case Recommended Layouts for an IT-based Safety Case There are no specific standards that give advice on how to present a safety case in digital form, so if you can derive a bespoke one, by all means carry on but bear in mind the disadvantages noted above Essentially the main elements of a safety case are: ƒ Claims about a property of the system or subsystem ƒ Arguments providing reasoning and inference about the way that a claim has been satisfied ƒ Evidence providing the data and information to support the argument chain ƒ Contexts about the operating environment, standards and usage assumptions These elements enable a retrospective style of safety case to be constructed, where a claim is being made about an existing or developing system Alternatively, the safety case can be composed in a style that is more predictive in nature, where safety goals have been set for a future or developing system In the predictive case, ‘strategies’ and target ‘objectives’ are used in the structures There is no special rule that says you must use one or other style in a particular circumstance, although customers or regulators may express strong preferences Indeed it is entirely feasible to combine both styles as the safety case planning and reporting progress through time For example, the objectives in the plan could become the items of evidence in the safety report Similarly, strategies develop into arguments and goals can become the safety claims A specific graphical display system has been put forward to enable the presentation of a safety case organised in these styles, it is known as ‘Goal Structuring Notation’ or GSN [Kelly 2003] The principle elements of GSN are shown in Figure 19.1 and 19.2 These elements may then be joined together using links that show how the whole structure combines together to form a cohesive argument and justification for the demonstration of the primary goal The links can be given directional arrows to indicate whether the structure is a top-down style or a bottom-up style These two styles of representation can be used to show a decomposition and re-composition concept allowing a synergy to be developed with the system engineering ‘V’ diagram In this instance, the decomposition left-side down the ‘V’ can utilise the predictive goal based schema, and the re-composition right-side of the ‘V’ can utilise the more retrospective claim-based schema The notation is infinitely flexible and can be used to represent any complex argument, not just safety based It is particularly suited to the types of standards and regulations that are goal-based rather than prescriptive in nature, so any industry could make use of them The flexibility means that it is highly likely that completely different goal structures could be drawn to satisfy the same complex problem – and both would be correct, just from a different point of view This is one of the problems with these notation-based safety arguments, there is no 164 Safety Cases and Safety Reports formal reference or standard to check against Some work is being done in this area in terms of defining safety argument patterns that can be re-used in similar situations, this gains the risks and benefits of producing a series of black-box COTS safety arguments, that only a specialist few can potentially understand and interpret A typical GSN structure may be composed as shown in figure 19.2 There are no absolute rules governing which element should follow which element, the only rules in this area are that there should be a goal at the top and evidence items at the bottom It is recommended that the area in between the top goal and evidence should achieve clarity and understanding A strategy element should always be used to explain how proposed sub-goals or solutions satisfy the higher goal, unless this will be obvious to all readers of the safety case report Frequently networks are developed as plans mature and the safety case develops, that shown in figure 19.2 is an interim network in the course of development Goal element should contain the subject and goal condition of the safety case GOAL STRATEGY Strategy element should contain the rationale for the decomposition of the goal structure OBJECTIVE Objective elements should contain the facts, results, reports or opinions that are intended to be supplied CONTEXT Context gives appropriate reference to the operational environment, specific definitions (e.g interpretation of ‘safety’), standards or best practice etc Figure 19.1 Principle Elements of Goal Structuring Notation Presentation of the Safety Case CLAIM ARGUMENT EVIDENCE 165 Claim element should contain the subject and claim condition of the safety case (Coloured blue) Argument element should contain the rationale for the composition of the claim structure (Coloured green) Evidence elements should contain the facts, results, reports or opinions that have been obtained (Coloured red) Figure 19.2 Principle Elements of Claim Arguing Notation Goal Structuring Notation Tool Support There are a few tools available to assist in the presentation of an IT-based safety case Some of these tools e.g ASCE give very powerful functionality when composing the safety case, for example [Adelard 2006]; ƒ ƒ ƒ ƒ ƒ ƒ Information mapping that supports the generation and updating of reports including traceability of changes in core documents Summarising, reporting and tracking information held in other documents including hazard logs, requirements management tools, or other information sources such as Excel, Access, Oracle, or Word A plug-in architecture providing a unique user extensible capability - create bespoke applications using VBScript Track the impact of changes and propagate the impact visually across the network Support for an XML standard format for assurance and safety cases, this enables the exchange of case information between co-operating tools Tools to support the construction and maintenance of safety case reports, including validation of information maps and hyperlinks 166 Safety Cases and Safety Reports G 01 Shows that the product of system design is tolerably safe Safety Programme Plan CONTEXT CONTEXT GOAL G 03 Demonstrates tolerable safety of design implementation requirements (to be developed) GOAL G 02 Demonstrate the ALARP position of equipment application hazards GOAL Def Stan 00:56 CONTEXT Version build standards JSP 454 CONTEXT Demonstrate ALARP via Analysis, Cost-Benefit Evaluation and design input Safety Case Requirements CONTEXT STRATEGY G 04 All reasonable hazards are identified GOAL System Hazard Analysis Report OBJECTIVE G 05 Hazards are analysed GOAL Hazard Log Compliance matrices and audit results OBJECTIVE OBJECTIVE G 06 ALARP declarations are proposed GOAL Safety Case Report OBJECTIVE Operational limits and recommendations OBJECTIVE Figure 19.3 Example Goal Structuring Notation Structure Presentation of the Safety Case 167 Notes Adelard 2006, “The Assurance and Safety Case Environment – ASCE”, Adelard LLP, City University, London, 2006 EUROCONTROL 2005 & Fowler and Tiemeyer 2006, “Safety Case Development – A Practical Guide”, Developments in Risk-based Approaches to Safety, proceedings of the fourteenth safety-critical systems symposium, Bristol, February 2006 Kelly 2003, “A Systematic Approach to Safety Case Management”, University of York, York, UK, 2003 MoD 2004: “Safety Management Requirements for Defence Systems Part 2” Interim Defence Standard 00:56, Issue Ministry of Defence, December 2004 OSHA 1989, “Safety and Health Program Management Guidelines” US Department of Labor, Occupational Safety and Health Administration, 1989 Chapter Twenty Maintenance of the Safety Case What Happens to Safety Cases? There are generally two scenarios for safety cases – they are either used or they are not When a safety case is not used, the safety case argument will remain valid for a short while – perhaps a year or so, but then critical staff will have turned over, new products or procedures will be brought into the system, the product or equipment will be used in a different way, or there may even have been a serious incident which was not originally envisaged Eventually, the real system will have diverged so far from that represented by the safety case that the safety case is no longer valid or useful The lack of an appropriate safety case, hazard analysis or risk assessment is regularly used in legal prosecutions as demonstration of negligence This is absolutely correct, as having out of date information is actually worse than not having any information at all With nothing to rely on, there is a belief that things are ‘risky’, if all the risk analysis was done a few years ago there is a belief that nothing has changed so the safety case still applies This is extremely unlikely, there will usually have been multiple minor modifications and changes, which on their own may appear insignificant, but together could add up to a major step-change in operational use There are several areas, which deserve special attention where change can catch out the best of safety cases: ALARP arguments, operational use and improvement, legislation shift and mishap occurrence in a related field Each of these will now be considered in turn, although there is no priority implied by the order ALARP Arguments If the safety case is predicated on an argument based on risk exposure being As Low As Reasonably Practicable (ALARP), a judgement will have been made about two things – the risk profile exhibited by the system and, the resources of time, trouble and expense in reducing that risk further Over time, the perception of both areas can change, the risk profile might be viewed with more dread by the public as more research information is published; the time, trouble and expense factors may change with technological development What was once thought expensively prohibitive (e.g use of multiple remote control robots to sense for poisonous atmospheres), might become significantly cheaper over time The development of new ceramics and polymers may provide improved personal protective equipment, so that certain tasks become more possible from a risk perspective Maintenance of the Safety Case 169 However, if the ALARP judgements and the assumptions they are founded upon were not reviewed, how would anyone ever know? The decision point for the cost-benefit analysis does change with time The value of a prevented fatality, which is a fundamental criterion within ALARP justifications, does increase over time It does this in accordance with national inflation or when there is a re-calculation of some of the factors used to determine the value (see chapter 12) What was a marginal case ‘n’ years ago, may now be one where further action is required Operational Use and Improvement The system operators and original system designers are often separated by at least years, sometimes many more The poor old engineers who were undertaking the original design and constructing the first safety case had to make educated guesses as to how the system was going to be used in the field In areas where this was difficult, operational limitations were imposed or recommended Many end-users not hear about the limitations, or simply not read the full details in the instruction manual (who does?) Some piece of equipment may be perfectly acceptable in a mild, temperate environment, but take it to the desert or the frozen wastes, and the dust or ice may render critical components useless These might be obvious, but one anecdotal story I heard was of a flight guidance computer, that was told that the ‘North Pole’ would always be ‘up’ This worked fine, until the trial aircraft went over the equator Of course other operational factors change as well, in the oil and gas industry as specific oil fields run low, the compositional mix of the raw product changes – it contains more sediment and more water This dramatically effects the mass flow rate through the installation pipework One of the effects is that the pipework can then start to suffer resonant vibrations that were not there when production originally began If the operational use and environment change significantly over time, even just through continuous improvement, then the assumed states in the safety case and boundaries for the hazard analysis will be incorrect Key hazards will have been ignored, these could now show themselves and bite you very hard Legislation Shift As society tends to become more risk averse, there is pressure to increase legislation to protect society against industrial risk, or to protect the environment from industrial waste This may not necessarily lead to a fatal flaw in a safety argument, but it may mean that coverage that should be there is missing Within the UK there is new legislation due on noise-at-work, within Europe there is new legislation on heavy metals in electrical systems and in the US, the Senate will shortly consider legislation that would require colleges and universities to provide fire safety information to prospective and current students Sometimes the shift in legislation is actually called for and supported by industry In Australia, the New South Wales Government has recently passed the new Occupational Health and Safety Act 2000 and introduced new Occupational Health and Safety Regulations with effect from September 2001 The new Act 170 Safety Cases and Safety Reports has replaced several existing laws (some nearly 100 years old), including the Occupational Health and Safety Act 1983 and regulations, the Construction Safety Act 1912 and regulations and parts of the Factories, Shops and Industries Act 1962 and regulations The new Act and Regulations have been widely welcomed by industry groups, as it is seen that it updates and simplifies the laws relating to health and safety in the workplace A significant advantage is that the new laws have been written in plainer language and contain new, specific provisions that require employers to have a greater understanding of their obligations to employees in relation to safety at work A safety case that still contains only the old requirements will be viewed as missing other details It is a bad reflection on the safety case and the organisation responsible for it Mishap Occurrence in a Related Field It need not be an incident with your product, inside your boundary diagram or at your site that leads to a review of your safety case (although, if this does happen, it should provoke a review anyway) If an incident happens in a related industry or with a similar product, it is very advisable to review the incident report (if you can get it) to see if your safety arrangements would have prevented the incident from happening Aside from this there are several other important reasons why you should read and learn from accident and incident reports [Holloway 2005]; ƒ ƒ ƒ You will be less likely to believe the myths that are commonly believed concerning accident investigation and reporting You will be more likely to have a realistic understanding of the potential consequences of ‘extremely improbable’ occurrences You will have more courage to refuse to compromise safety if you encounter pressure to compromise Managing Change Change is an inevitable part of the lifecycle of a system or product, and it should be planned for and managed in a systematic way It is important that an adequate level of analysis is carried out to determine the safety impact of any change To ensure that such changes are detected and addressed, a monitoring process should be implemented as part of the safety management system A formal change control process should be put in place, such that a closed-loop system that provides feedback can be operated Change information should be recorded (e.g in the hazard log) to maintain configuration control over the system and to provide valuable data when managing future changes [MoD 2004] Effective control is impossible without adequately documented instructions for how to actually this, so it is important that a method for change management is developed and recorded Accurate and timely information is critical to effective change management All control systems are based upon the comparison of information about the situation as it is, with a predetermined standard of Maintenance of the Safety Case 171 performance that has been called for in the original operation plan Therefore, there is the requirement to have an on-going method for obtaining and communicating information about incidents and factors likely to affect risk and safety over the whole lifecycle of the system, process or product A simple regular reporting format may be utilised noting any incidents or factors that will necessitate a change, and then a change-tracking matrix can be used to follow through the changes and provide the safety case (and managers) with the relevant change closed-loop feedback Since, as we have discussed, safety is important, perhaps the default assumption should be that change always impacts safety Hence justification should be required for why it is not necessary to address safety as part of any change, rather than the other way around Review and Update Cycles The maintenance of the safety case can only occur if there is a predetermined cycle of review and update that prompts the next look at the document and argument Without this, even the best-intentioned safety team often ‘forgets’ or ‘postpones’ the review Most often the incident that has been dreaded occurs during one of the ‘postponed’ time slots The prompts for a safety case review should be listed out and agreed in the safety case document suite The normal recommendation for a review cycle is annually, which is fine for many safety cases, particularly where there has not been much changing in the operational environment and there haven’t been any notable incidents However, where change does take place, the safety case needs to be kept contemporary with the design and operational use of the product, process or system Some industries are more stable than others, so the update cycle need not be so frequent The particular frequency is best left to the safety engineers involved in each industry, as in some cases the time to review may even approach the 12 month! Additionally there are still the other mechanisms discussed above where a safety case review may be forced The program safety working group (PSWG) can be a specific forum for discussing change and monitoring operational factors The PSWG can be given particular authority to ensure actions are carried out, and it should have a recording process in place to allow tracking of tasks and concerns And although not necessarily attended by them, the group will have access to the senior managers of the organisation Notes Holloway 2005, “Why you should read accident reports”, NASA Langley Research Center, Software and Complex Electronic Hardware Standardization Conference, Norfolk Virginia, July 2005 MoD 2004, “Safety Management Requirements for Defence Systems Part Requirements”, Interim Defence Standard 00:56 Issue 3, MoD, 2004 Epilogue Since this book was first thought about, and I started to write the chapters over the end of 2005 and into 2006, several more terrifying disasters have occurred in the world – e.g the Buncefield explosion and fire, the Sago mining disaster and a number of military ‘friendly-fire’ incidents They could have easily ended up as examples and discussion points within the pages, but at some point, you have to stop writing about current events and get the ideas down on the page before the next catastrophic event happens Otherwise, the book would actually never get written – at the rate that accidents are (still!) happening, this book might not have been finished Indeed some periodicals report on and discuss the accidents or convictions that have happened between publications, and they come out fortnightly!! The safety domain may yet get stuck in and shake the corporate world awake – fortunately, some of it is already on the second coffee of the morning, having sorted through all the e-mails and letters Regretfully, some of it is still curled up in bed, dreaming that the organisation is safe Thank you for reading, even buying this book, and still reading it at the very back, I cannot guarantee that any of us will not have an accident (even if you have read all the way to here), but if just one life is saved through someone doing something that they read between these covers, it will have been worthwhile Richard Maguire September 2006 rlm@sevalidation.com Index Accident – definitions 9, 50 Accident causes 2, 120, 131, 145 Accident costs 65, 92-99 Cost components 96 Accident reports 170 Accident tetrahedron 70-71 Advisor 153, 154 Aircraft and Armament Evaluation Establishment 17, 18 ALARP 63, 68, 72, 82, 98, 168 ALARP as a safety target 71 ALARP assessment 72, 146 ALARP demonstration 69, 70, 71, 72, 97 Analysis 26, 27, 100, 103-9, 111112, 115, 161 Cost-benefit analysis 68, 69, 95, 99, 169 Hazard analysis 8, 36, 86, 115 Human factors analysis 127, 129 Risk analysis 62, 98 Safety analysis 19, 31, 37, 134, 146 Fundamentals of 43 Software analysis 135-142 Apportionment 63, 76, 80 ASCE 165 Assessor 39, 153, 154 Auditor 28, 88, 153, 154 Aviation industry disasters Concorde Florida Everglades Easyjet 2, 120-2 Kegworth Mount Erebus 133 Aviation Safety Reporting System 19 Barriers 107 Boundary diagrams 43-44, 170 Catastrophic event 51, 52, 56, 58 Causation 70, 146 Chance 13-14 Change management 31, 37, 86, 168, 169-170 Chemical industry disaster 2, 18 Bhopal 2, 145 Flixborough Piper Alpha 2, 18, 31, 145 Seveso 34 CIMAH 18 Civil Aviation Authority (CAA) Of New Zealand 64-5 Cognitive walkthrough 128 COMAH 9-10, 18, 36 Common cause failure 106, 107, 140 Competence 39, 86, 155 Confidence levels 135, 137, 140 Corporate manslaughter 145, 147 COTS 133-135, 140, 164 Criminal fines 98 Critical event 51, 52, 66 Culture 147, 148-9 Defence industry disaster 2, 18 Chinook ZD576 Dhahran Osprey at Marana Defence standards (UK) 35, 51, 115, 137 Department of Defense (DoD) 7, 50 Department for Transport 53, 95-6, 97 Duty holder 35, 88, 154, 159 174 Safety Cases and Safety Reports Duty of Care 88, 146, 147 Electronic safety case 162-3 Energy analysis 4, 111, 124 Ethnography 128 Event tree analysis 105-7 Evidence 1, 3, 5, 32, 37, 39, 47, 56, 64, 71, 88, 92, 112, 113, 114, 127, 134, 137-8, 141, 148, 149, 153, 154, 160 For the need of a safety case 37 In goal structuring notation 162, 163, 164-5 Qualitative evidence 65-6 Failure mode effects analysis 100, 107-108 Fault tree analysis 103-5, 141 Federal Aviation Authority (FAA) 19, 114, 121, 123, 126, 139 First party risks 45, 84 FN curves 80-81 Foreseeability 146 Frequency scale 49, 52-3, 59 Globally at least equivalent (GALE) 73 Goal based standards 39, 135, 163 Goal structuring notation (GSN) 162-5 Governance 149 Grossly disproportionate 68, 69, 134 Group risk 76, 77, 78 Hazard – definition 13-14, 15, 36 Hazard analysis 5, 100, 161, 168 Hazard characteristics 48 Hazard identification 100, 112, 146, 155 Hazard Log 31, 87, 113-117 BOBCAT hazard log 116 Florida State hazard list 118 Hazardously misleading 132 Managing safety 6, 19, 22, 23, 24, 69, 79, 88 MANPRINT 126 HAZOP 101-2 HAZWOPER 26 Health and Safety at Work Act 73, 90 Health and Safety Executive (HSE) 10, 48, 63, 68, 69, 72, 78, 83, 94-96, 98, 135, 153 Health and safety plan 3, 5, HEART analysis 119-111 Heuristic evaluation 128 Human factors 72, 73, 120-7, 130 Human factors analysis 127-130 Human factors integration plan 126-7, 156 Human hazard analysis 110 Human reliability assessment 109 Human system integration 125 Human system integration plan 125-7 IEC 61508 135, 156 Independence 148, 152-3, 154 Independent safety review 152-5 Individual risk 76, 83 Industrial fatality statistics 77 Interval scale 49 ISA 88, 153, 154-6, 158 IT-based safety case 162-3 Killed or seriously injured (KSI) 52-3 Language in safety 12, 13 Legislation mandating a safety case 18, 25, 30, 34 Legislation shift 169 Major accident 9, 10, 35 Maintenance of a safety case 164, 168-171 Management factors in safety cases 8, 22, 25, 31, 144-8 Managing change 31, 37, 86, 168171 Master test plan 142 MAPP 36 Media scale of incidents 51-2, 57 175 Safety Cases and Safety Reports Ministry of Defence (MoD) 4, 25, 28, 35, 69, 88, 97, 113, 115, 125, 137, 141 Mishap – definition 8, 50, 54 Mishap occurrence 170 Mission safety evaluation report 19 NASA 2, 19, 22, 128 Negligence 70, 146, 148, 168 Nominal scale 48, 51, 54 Nuclear industry disaster 2, 18 Chernobyl Three Mile Island Tokaimura Nuclear Installations Act 16, 18 Occupational Safety and Health Administration (OSHA) 19, 20, 26, 34, 36, 79, 89, 98, 153, 160, 161 Offshore Installations (Safety Case) Regulations 18 Operational use 159-60, 168, 169 Permissioning regime 30, 35 Persona analysis 128 Population risk 76, 80 Preventability 146 Probability 13, 14, 15, 54, 55, 60, 63, 82, 103, 104, 106, 109111, 135, 136 Project manager 85, 87, 156 Project safety engineer 87, 127, 150, 171 Project safety working group 27, 88, 171 Public perception 47, 65, 97 Qualitative safety targets 65 Quantitative safety targets 63, 64, 65, 79 Railway Safety Case Act 18, 35, 39, 153 Rail disasters Arizona Kings Cross 2, 18 Ladbroke Grove 153 Paddington Ratio scale 49, 50, 51 Reasonableness 146 Reasonably practicable 67, 68, 69, 70, 72, 148, 168 Residual risk 30, 32, 70, 150, 159 Requirements for a safety case 30, 34 Risk 13, 14, 15, 17, 30, 43, 47, 48, 56, 62, 63, 68, 74, 76-78, 80, 82, 88, 90, 95, 97, 113, 114, 130, 134, 135, 150, 159 Risk analysis 86, 96, 115 Risk assessment 35, 68, 72, 85, 145, 155, 168 Risk aversion 80, 83 Risk matrix 55-60, 115 Safety – definition 7, 16 Safety analysis report (SAR) 19, 37 Safety and environmental management plan 25 Safety and environmental management program 37 Safety boundary 5, 33, 41-2, 44, 45 Safety case 3-4, 16, 35, 37, 64, 83, 86, 90, 94, 101, 122, 131, 141, 144, 149, 153, 156, 158160, 161-3, 167-171 Safety case development in the UK 17-18 Safety case purpose 30-33 Safety case report 3, 5, 30, 41, 71 Safety committee 27, 87, 88-9 Safety culture 147-150 Safety limits 62 Safety management system 22-4, 32, 36, 42, 90, 113, 170 Safety management plan 25, 150, 154, 156 Safety panel 27 Safety plan 25, 26, 35, 113, 126, 150, 154 176 Safety Cases and Safety Reports UK example 25 US example 26 Safety requirements 5, 12, 25, 30, 37, 87, 137, 142, 154, 155, 159 Safety targets 59, 62-5, 83 ALARP as a, 71 UK industry targets 78 US industry targets 79 Safety team 27, 28, 85-8, 100, 127, 155, 170 Safety working group 27, 88, 171 Scenarios 41, 102, 129, 140 Serial scale 49 Serious injury 52-3, 96, 124 Severity scale 14, 49, 55 US DoD accident severity scale 50 Seveso disaster 34 Seveso Directive 35 Safety integrity levels (SIL) 135-6 So far as is reasonably practicable (SFAIRP) 68, 80 Demonstration of, 70-71 Software development plan 142, 156 Software factors 73, 131-4 Software failure 2, 12, 131, 134 Software of uncertain pedigree (SOUP) 134 Software safety case 131, 141, 142 Software safety records log 141 Software testing 139-140 Space industry disaster Arianne NASA 51-L NASA Mars probe St Pancras Station safety case 72, 85 Stored energy analysis 111, 124 Storyboard analysis 129 Structured ‘what-if’ technique (SWIFT) 101-2 Task analysis 108, 109, 129 Terms of reference 28, 89, 156 Think-aloud usability tests 129 Third party risk 45, 82-3, 84 Tolerable risk 55, 63, 80 Tourism industry disaster Herald of free enterprise 2, 144 Hyatt Hotel Indiana fun park train ride 2, 38 Units of measurement for risk 59, 96, 104 Units of measurement for frequency 52, 53, 136 Update of a safety case 113, 171 Use cases 130 Value of a prevented fatality 95-7, 169 Zonal analysis 100, 107-8 .. .SAFETY CASES AND SAFETY REPORTS To my children If you can’t be safe, at least be careful Dad Safety Cases and Safety Reports Meaning, Motivation and Management RICHARD MAGUIRE... safety - Management 2.Health risk assessment I.Title 363.1'12 Library of Congress Cataloging-in-Publication Data Maguire, Richard, 196 8Safety cases and safety reports : meaning, motivation, and. .. safety management – getting the right xii Safety Cases and Safety Reports balance between innovation and change on one hand, and avoidance of shocks and crisis on the other – is now central to