Book reviews

Professor Tom Anderson, (LinkedIn), Newcastle University:

The development and creation of a safety case for any realistic system is a major task, and will normally generate a (very) large collection of documents. When faced with such a considerable volume of highly technical material, the challenge of producing a safety case report may seem very daunting – given the need to succinctly represent all facets of the safety case: requirements, mechanisms, achievement, assumptions, rationale, evidence etc. The suggested format, structure and guidance presented in this book provide a way of addressing that daunting challenge. The route it proposes to complete the task is hardly short and simple, but that route is mapped out meticulously, augmented by many a signpost along the way. If the book is consulted, digested and followed it should render considerable assistance; even if read and not followed, a reader should acquire much valuable insight. 

John Stelfox, Nanaimo Search and Rescue, Vancouver Island (retired)

“Excellent, well written and presented. Every Safety Manager should have a copy of this book.”

John Spriggs, Safety-Critical Systems eJournal Editor

“A safety case needs to be readable by the intended audience who need to be assured, but also by those who are required to verify its content. Both require clarity and detail, but with different emphases. This requirement often leads to a complex document with multiple appendices and external references. This book offers an alternative approach wherein those who need the assurance are presented with a Safety Case Report summarising the arguments and evidence that are detailed in the safety case itself. The book provides a tailorable format for such a Report. It is a useful resource that can also serve as a check on the completeness of your safety case; if the Safety Case Report format asks for something you don't have in your safety case, can you write a compelling justification as to why it is not needed, or did you miss something?”

Steve Kinnersly B.Sc. D.Phil. MRSC  (Biography) reviewed the book for the Safety Critical Systems Club Newsletter Volume 33 Nos 1 - Feb 2025: 

Having agreed to write this review, I asked a friend who has decades of experience in safety matters whether he had any thoughts on Safety Case Reports (SCRs). “I’ve read hundreds of them,” he replied, “that’s why I’m now a cynical old #*#*#*!” 

In case you are wondering what these seemingly hazardous documents are, an SCR is a document that summarises the arguments and evidence of a safety case. It is not the safety case itself but rather a high-level guide and a gateway into the full safety case. Interim SCRs may be used to document progress against a project’s safety programme. 

As an Independent Safety Assessor (ISA) for projects that have often lasted years, I have seen many grow from initial outline to full and final fruition. From this has emerged a personal wish list for an SCR. It should be: 

1. Clear – in both writing and structure

2. Concise – not verbose, avoiding what is not necessary

3. Comprehensible – for the intended readers

4. Comprehensive – addressing all relevant aspects of the system (or service etc.) and its intended uses

5. Complete – addressing all the evidence and argument needed to reach its conclusions

6. Coherent – logical and balanced

7. Correct – a faithful summary of the safety case 

If it fails on one or more of those points then it might not be as convincing as the author hoped – and who writes a SCR and does not want it to be convincing? Anything that helps SCR authors to satisfy these seven points must surely be a good thing. 

‘A Safety Case Report Format’ aims to “help people to understand your safety case”. It mainly addresses the argument and evidence needed for an SCR to be comprehensive, complete and coherent. The focus throughout is technical; it is not a style guide so has little to say about points 1-3 in my wishlist. A generic, high level contents list for an SCR is given and used as a framework for a thorough, detailed, reasoned and logical presentation of what an SCR should address and how it should be structured. As befits a book that is aimed at the full range of possible SCRs, the emphasis is on recommendations and guidance: the writer of an SCR must decide whether and how they apply to their situation. 

The authors, Andrew Eaton and Stephen Barker, each have more than two decades experience working for the UK Civil Aviation Authority (CAA), chiefly on the safety of air traffic control systems. Their background is reflected in how they have approached the book. It is written from an assessor’s top-down viewpoint of what needs to be in an SCR in order for them to be convinced, rather than from a project safety engineer’s bottom-up viewpoint of how to summarise all the available safety argument and evidence in a single document. Put simply, an SCR produced in accordance with ‘A Safety Case Report Format’ should provide an assessor with all the information needed for their assessment. Indeed, the authors have used as a reference point the CAA document CAP 1801 ‘Assessment of Change Safety Cases’ (for which they were joint authors), which provides guidance for assessing a generic (not aviation specific) safety case. 

‘A Safety Case Report Format’ claims to be “generically applicable, not specific to any regulatory regime or legislation”. The range of possible safety cases and thus SCRs is, of course, huge. This challenge is addressed by including everything which might be needed for what the authors consider to be the most complex situation for a safety case to address, specifically a change rather than a new build since “a change ... has the most topics to address”. The user must then tailor the contents to their situation by selecting and adapting. While this is a reasonable approach in principle, it remains to be seen how well it works in practice. The authors note that a user needs to have “adequate competence in safety assurance and the subject of the safety case”. The absence of examples does not help here – perhaps something for the authors to address in a Part 2?

Given that the book aims (and appears) to be comprehensive, a user intending to write an SCR is faced with an important question: since an SCR must be a faithful summary of the safety case, what if something the book identifies as needed is not in the safety case itself? The answer given in the book is that it must be decided whether this “can be justified or whether the safety case needs to be enhanced before the SCR can be produced”. It is hard to disagree with that. It is also hard to avoid concluding that the book is as much about what needs to be in the safety case itself as it is about the corresponding SCR. Why not use the book at an early stage in a project to help design a convincing safety case and thus ensure that all necessary evidence is produced by the safety programme? There should then be no gaps when summarising the arguments and evidence in the SCR. 

A key question for a ‘how to’ book such as this is how well it works in practice. There are no examples in the book and, being newly published, there is not yet any evidence from ‘real world’ application. From personal experience, the recommendations and guidance given in the book appear to be reasonable and consistent with good practice in safety. As an ISA, I would have been happy to see a project following them (suitably interpreted and only if they apply to that specific project, of course). However, I would want to see that the project treated them as they are intended: prompts for careful consideration rather than instructions to be followed blindly. 

The authors’ background in air traffic control safety is no doubt responsible for some idiosyncrasies which seem at first sight to limit the book’s scope of application. Air traffic control safety is primarily concerned with the safety of a service. This is presumably why the book is written in terms of an SCR for the safety of a service. Someone responsible for an SCR for something other than what is normally considered a service might reasonably wonder whether this book is for them. This is addressed in the book as follows: 

1. ’Service’ is defined very broadly as “an output from a functional system that is intended to be of use”, the output “may be either intangible… or tangible (e.g. a product, commodity or function)” and protection against harm “is itself a service”. 

2. Harm is not restricted to what might be caused by a service itself, it also includes harm that might be caused by the system which delivers the service (called ‘local harm’ in the book). 

The authors note that this “may require some adjustment of perspective for some people”. Whether it is sufficient to cover all situations for which an SCR is needed remains to be seen – probably yes, but this reviewer has struggled here and is still hiding in the long grass! 

A substantial part of the book is concerned with what needs to be in the SCR for each transition stage during a change. This might reflect the fact that an essential part of air traffic control safety is maintaining safety during the transition stages involved in implement ing a change. Someone producing an SCR for something that is not a change to an existing system or service might reasonably wonder why that part of the book is relevant to them. The answer is that in the book a transition stage is regarded as any stage in which the system is operating in state that is not a final operating state. This implies that, for example, commissioning tests might be a transition stage. My advice to a potential user is to think carefully about whether you can dismiss this part of the book: you might actually know transition stages by a different name. 

A background in air traffic control safety might or might not be responsible for a third idiosyncrasy. As an ISA, I always expected an SCR to include a clear and prominent statement of and justification for top level safety requirements which then flow down into lower level requirements (derived requirements etc.). It was therefore a surprise to find that this did not seem to be required here. A trip to the Index and Glossary was needed to find the reason. Top-level safety requirements are ‘Risk acceptance principles’, ‘safety criteria’ (etc.), with ‘safety requirement’ being used only for lower level requirements. This appears to be a matter of terminology rather than substance. However terminology is important. The reader is advised to read the introductory material and glossary carefully to ensure that they understand the meaning of terms and concepts as used in the book rather than assume that it follows conventions used in their own domain.

In conclusion, ‘A Safety Case Report Format’ is a thorough, logical and reasoned treatment of an important topic. It provides comprehensive recommendations and guidance on what should be considered for inclusion in an SCR. As such, it can help not just with writing an SCR but also with designing and developing the safety case itself. 

The aim of being generic and thus applying to any and all domains and possible safety cases appears to have been met. However, a consequence is that a user must exercise considerable judgement in interpreting, selecting and tailoring the contents to their own situation. This is therefore a book for experienced safety professionals to use. Indeed, it is arguable that it might best be used as a basis for developing domain-specific versions that can be used with less tailoring. 

Finally, would ‘A Safety Case Report Format’ have stopped my friend becoming a “cynical old #*#*#*!” ? Ah, that is not for me to say…