Background

The Robens Report [Robens 1972] and the Cullen Enquiry [Cullen 1990] were major drivers behind the UK Regulatory agencies exploring the benefits of introducing goal-based regulations. The reports noted several shortcomings with prescriptive safety regulations.

Firstly, with prescriptive regulations, the service provider is only required to carry out the mandated actions to discharge his legal responsibilities. If these actions then prove to be insufficient to prevent a subsequent accident, it is the regulations and those that set them that are seen to be deficient. Thus safety is viewed as the responsibility of the regulator and not the service provider whose responsibility, in law, it actually is.

Secondly, prescriptive regulations tend to be a distillation of past experience and, as such, can prove at best to be inappropriate and at worst to create unnecessary dangers in industries that are technically innovative. It is the innovator that is best placed to ensure the safety of their design, not the regulator. Clearly prescriptive safety regulations are unable to cope with a diversity of design solutions. 

Thirdly, prescriptive regulations encode the best engineering practice at the time that they were written and rapidly become deficient where best practice is changing e.g. with evolving technologies. In fact it is quite probable that prescriptive regulations eventually prevent the service provider from adopting current best practice. Another driver for adopting goal-based regulation, from a legal viewpoint, is that overly-restrictive regulation may be viewed as a barrier to open markets. Various international agreements, EC Directives and Regulations are intended to promote open markets and equivalent safety across nations. Whilst it is necessary to prescribe interoperability requirements and minimum levels of safety, prescription in other areas would defeat the aim of facilitating open markets and competition. 

Finally, from a commercial viewpoint, prescriptive regulations could affect the cost and technical quality of available solutions provided by commercial suppliers. So there are clear benefits in adopting a goal-based approach as it gives greater freedom in developing technical solutions and accommodating different standards. However, in order to adopt a goal-based approach, it is necessary to provide a coherent and convincing safety justification.

A safety case is now a requirement in many safety standards. Explicit safety cases are required for military systems, the off shore oil industry, rail transport and the nuclear industry. MOD Def Stan 00-55 was the first standard to explicitly require a software safety case and it can be downloaded from the DStan Web site. More recently the UK CAA Safety Regulation Group has developed a goal based approach to the regulation of air traffic management systems and its proposals are contained in CAP670 SW01, "Requirements for Software Safety Assurance in Safety Related ATS Equipment". A generalisation of the safety case concept also appears in Def Stan 00-42 Part 3 which is on the Reliability and Maintainability Case and Part 2 deals with the software reliability case. Similar requirements appear in equivalent NATO standards. Furthermore, related  requirements can be found in other industry standards, such as IEC 61508 (which requires a "functional safety assessment") the EN 292 Machinery Directive ( which requires a "technical file") and DO 178B for avionics (which requires an "accomplishment summary"). In the railway sector the Office of Rail Regulation publishes assessment guidelines for safety cases, but these are generic and not PES specific.

Safety cases are important  to minimise safety risks and commercial risks. In regulated industries such as the nuclear industry, the need to demonstrate safety to a regulator can be a major commercial risk. For example the computer-based Darlington Reactor Protection System in Canada required around 50 man years of software assessment effort which was probably more than the effort required to develop the software. In addition the assessment delayed reactor start up so that many millions of dollars of income were lost. So the need to demonstrate safety can involve significant direct costs and indirect costs if the overall project is delayed.

So to sum up the motivation for a safety case is to:

• provide an assurance viewpoint - for efficient review
• provide a focus and rationale for safety activities - leading to efficient analysis and evaluation
• provide a reviewable approach - so that all stakeholders can be involved
• demonstrate discharge duty to public and shareholders
• allow interworking between standards and innovation

So in a safety case the emphasis should be on the behaviour of product not just the process used to develop it: a useful slogan is "What has been achieved not how hard you have tried".

References
    □ [Cullen 1990] Lord Cullen, The public inquiry into the piper alpha disaster.HMSO Cm 1310, 1990
    □ [Robens 1972] Lord Robens, Safety and Health at Work. Report of the Committee 1970 - 72. HMSO Cmnd 5034, 1972

---------------------------------------------
This page is based on:

Aspects of Safety Management: Proceedings of the Ninth Safety-Critical Systems Symposium Bristol, UK, 6-8 February 2001, Felix Redmill and Tom Anderson (eds.) London; New York: Springer, 2001 ISBN: 1-85233-411-8, pages 35-48.