This FAQ page is intended to answer questions that you might have about the applicability of the book to your circumstances. To suggest further FAQs please email mail@barker-eaton.co.uk.
Technical background is provided elsewhere on this website. If you are seeking a detailed technical understanding of how the format came about, then our workshops are the place for you.
No. The book does not define what a complete and correct safety case is, nor how to generate one. It just gives a format that, in the opinion of the authors, should present most or all of the material necessary to satisfy a reviewer, when it is populated with information from a valid safety case. So, given that the book defines what should be extracted from a safety case to populate a Safety Case Report (SCR), this should provide a good few hints!
Or, as one reviewer of the book put it:
"... 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."
Yes. The Safety Case Report format is applicable to systems and their safety cases that might not traditionally be regarded as services. For example, a production facility might have traditionally been considered as producing a product rather than providing a service. However, in our view, providing the product can be regarded as a service. It also highlights the issues associated with exactly where the product is delivered to!
Whilst the safety risk (potential for causing harm) can only truly be known if the environment is defined, we recognise that you may find yourself in a situation where you have an authoritative definition of acceptably safe performance for your 'thing'. In these cases, the format can still be used, by changing the nature of the material in the sections that deal with identifying the safety criteria that define acceptable safety performance. Another FAQ will discuss the issues associated with arguing safety on the basis of compliance with standards.
No. The format has been designed to cover as many scenarios as possible. A valid safety case will provide material to populate the sections relevant to your scenario, and those not relevant can be noted to not apply.
In considering scenarios like new services, a change to a service, justifying an existing service, and decommissioning, we recognised that the case that required the widest range of safety case material was a change to an existing service, and so the format is framed in these terms. So whilst at first sight it may appear that the format does not apply to a new service (for example), using the format remains a matter of populating just the relevant sections.
The format allows the use of whatever Risk Acceptance Principles are applicable (e.g. ALARP) to be used. A section of the format is used to present the applicable principles and show the derivation from them of the Safety Criteria that define acceptance safety performance.
No. The format takes information from the safety case regardless of how it is specified or recorded. It doesn’t assume any particular structure, architecture or notation for the safety case.
It is important that the Safety Case Report reflects the safety case accurately, otherwise it no longer forms a suitable vehicle for the basis of an approval. Therefore the presentation of the safety arguments in the Safety Case Report should be exactly the same as in the safety case.
Yes. Many people fail to consider the potential for installation activities, which take place during operation, to impact the safety of the services provided by the functional system. Sometimes these activities may be covered by established 'Permit to Work' procedures, but if not they may require careful analysis to determine whether they can impact the operational services, including considering credible deviations from the intended installation activities.
The format allows for full analyses of installation activities to be included, if they form part of the safety case.
There are often support activities that take place to enable the operation of the functional system: data preparation, maintenance activities, provision of consumables, etc. They clearly have the potential to impact the safety of the services provided, but usually are judged to require a lesser level of assurance than those parts of the functional system that directly provide the service.
The format reflects this by separating the functional system into the 'operational system' and the 'support systems', and so allows for the safety assurance for the support systems to be included, if this has been included in the safety case.