Presented at
SignalComm Europe 2000
16th - 17th May 2000
Birmingham, UK

UNDERTAKING A SAFETY CASE
IN A RAIL ENVIRONMENT

Odd Nordland
SINTEF Telecom and Informatics
Systems Engineering and Telematics
NO-7465 Trondheim

E-mail: Odd.Nordland@informatics.sintef.no
URL: www.informatics.sintef.no/~nordland

Abstract: The CENELEC standards for railway applications require "safety cases" as a prerequisite for approval of such applications. The paper explains the concept of a safety case and what it should contain, discusses the various kinds of safety case that the standards identify and illustrates the cost implications and benefits that can be achieved.

Keywords: CENELEC, Railway Applications, Safety Case, Standards.

1. Introduction

Automatic train protection (ATP) and interlocking systems have become more complex and rely heavily on microprocessors and software. Thus, the assessment and certification of such new systems has changed and become correspondingly more complex. In addition, European integration leads to a need for common principles and procedures, so that assessments and certifications performed in one country can be adopted by other countries.

One step in this direction is the adoption of European standards for railway applications, notably EN 50126, EN 50128 and EN 501291. They describe processes to be followed in order to be able to assure the safety of a railway application. However, whilst they describe reasonably completely what to do, they do not go into great detail on how to do it.

Now of the above-mentioned standards, EN 50126 is the top-level document that covers the overall process for the total railway system. It defines Safety Integrity Levels and sets the frame for the more detailed activities that are described in EN 50128 and EN 50129. EN 50129 is the standard that defines the activities for developers and manufacturers, but also describes the requirements that a third party assessor shall verify. EN 50128 is the software specific "subset" of EN 50129.

EN 50129 requires that a safety case shall be submitted by a manufacturer and assessed by an independent third party before the safety authorities should approve commissioning the system. The term "Safety Case" is perhaps reasonably straight forward for people with English as their mother tongue, but experience shows a large degree of confusion when non English speaking Europeans use the expression! So the term requires some elaboration.

2. Safety Cases

The word "case" is used in a variety of contexts. We have special cases, briefcases, suitcases, bookcases, court cases and - safety cases. The latter is derived from the concept of a court case: the prosecutor and defendant both "present their cases" to the court in order to convince the judge that their proposition is right.

Now for our purposes, the proposition is that a new (or modified) system is safe enough to use, and somebody has to present the case so that the "judge" - the safety authority - can reach a decision. As in legal proceedings, the "judge" will refer to an expert assessment by an independent party before relying on his own personal impression. (The word "assessor" did, in fact, originally mean "co-judge"!)

It is important to keep this analogy in mind. The safety case is a line of argumentation, not just a collection of facts. It aims at convincing a licensing authority, who does not necessarily have a deep knowledge of the specific technological questions involved, that a given product or system is safe enough to be taken into use. Or was safe enough: the safety case could well be used as evidence in genuine legal proceedings years after the system was authorised and commissioned.

One of the most common problems with safety cases is that they are too concise. It simply isn’t sufficient to just refer to dozens of documents and state that all the information is there, leaving it up to the assessor to read through them all and extract the necessary facts. Imagine a court case where the defendant claims that all the evidence of his client’s innocence is in two meters of shelving in his bookcase, so the judge just has to read through the documentation to convince himself. The judge would probably advise the client to get a new lawyer!

The safety case must in itself contain enough information to give a clear impression of the system’s safety properties and indicate where the gory details can be found if this is desired. So the safety case sections that are defined in EN 50129 must contain descriptive text rather than just a more or less complete list of references.

2.1 The Contents of a Safety Case

EN 50129 gives a fairly extensive description of how safety cases should be structured, but the information is distributed through the standard and its annexes. Experience shows that there is a need for a briefer guideline.

In the following, the sections are briefly described. It should be noted that it is perfectly legitimate to let each section be a free-standing document, provided it has the right contents.

2.1.1 Definition of System

The first section in the safety case is the Definition of System. It shall give a complete and detailed description of the system for which the safety case is being presented. EN 50129 states: This means that the definition of system shall contain: It should be noted that this section is a definition of the system, not just a description. Its purpose is to identify exactly which version of the system is meant. Any modification of a component or module will necessitate a new - or at least updated - safety case. The same applies if the documents get updated.

The author recommends that a separate "List of Applicable Documents" ("LAD") should be used. Such a document list must identify all the applicable documents, not just the directly referenced ones, by title, document number etc. and the exact versions to be used. Similarly, a "Configuration Item List" ("CIL") should be used to identify the exact versions of components and modules.

It is then sufficient to explicitly identify the valid issue and revision of the LAD and the CIL in the safety case - for all other documents and components reference can be made to the LAD and/or CIL for the necessary version data.

2.1.2 Quality Management Report

This section is a report that describes what has been done to ensure that the system has the required quality throughout the entire life cycle. This involves: EN 50129, paragraph 5.2, contains examples of topics (based on ISO 9000) that should be addressed, but the list should not be regarded as being exhaustive. They are examples that need not necessarily all be relevant. But in such cases it is wiser to state explicitly that a particular topic is not applicable and give some kind of explanation rather than just not mentioning it. Otherwise, there’s a fair chance somebody (the assessor!) might think that it’s been forgotten. On the other hand, there may be other aspects not mentioned in the list that are significant, so care should be taken when using the list in EN 50129 as a check list!

2.1.3 Safety Management Report

This is the corresponding report for safety management. As with the quality management report, the safety management report involves: EN 50129, paragraph 5.3, contains examples of topics that shall be addressed: Note that EN 50129 makes the use of the safety management process as sketched above mandatory for safety integrity levels 1 to 4! In particular, this means that a hazard log shall be maintained throughout the entire lifecycle of such systems. EN 50129 defines the hazard log as: So this is not just a list of hazardous events, it must identify their probable consequences and frequencies, it must include a classification (e.g. negligible, tolerable, intolerable etc.) and provide information about how the hazard was tackled (e.g. technical modifications, administrative procedures or other suitable measures). EN 50126, paragraph 6.3.3.3 defines the hazard log in detail.

Obviously, there should be no unresolved, intolerable hazards left in the log when a system is in operation.

2.1.4 Technical Safety Report

This is the section where the technical safety characteristics of the system are described. It shall describe the underlying philosophy for achieving safety and identify which safety standards have been applied. The safety relevant properties of the system shall be presented and reference made to the corresponding evidence, i.e. test and analysis results, verification and validation reports, certificates and so on.

EN 50129 prescribes a structure for the technical safety report:

EN 50129, paragraph 5.4 and Annex B (which is normative) identify the topics that shall be addressed, summing up to a total of 123 headings and sub-headings for the technical safety report! Some of the topics may not be relevant for a particular kind of safety case, but as in the quality management report, it is wiser to state this explicitly: EN 50129, Annex B, requires that the Technical Safety Report "shall be arranged" under the headings given in the standard! On the other hand, additional topics may be necessary, so the list is not necessarily exhaustive.

2.1.5 Related Safety Cases

If the system’s safety relies on the use of safe parts or components, the corresponding safety cases shall be identified here. In such cases, any restrictions or application conditions mentioned in those safety cases shall be recapitulated here.

Note that this also applies when there is a previous version of the system for which a safety case already exists. In this way, producing a safety case for an upgraded system can be considerably simplified. Since the previous version’s safety case contains all the relevant information for that version, only the changes from the previous to the new version need to be described. In addition, evidence must be provided that the modifications have not adversely affected the safety properties of the unmodified rest of the system.

"Related safety cases" can also refer to certificates for parts or components, since such certificates will themselves be based on documentary evidence of the relevant safety properties.

2.1.6 The Conclusion

This is more than just the statement that the product is sufficiently safe. EN 50129 states: This section is the plea that recapitulates the evidence presented in the previous sections and the argumentation for the system’s safety. This is where the justification shall be given that the quality and safety management activities were adequate, that the technical properties satisfy the safety requirements and that the conditions imposed by the related safety cases have been adequately taken into account. Any restrictions, limitations or assumptions that were made shall be stated here as "application conditions".

2.3 Different kinds of safety cases

EN 50129 identifies three different categories for Safety Cases:
  • Generic product Safety Case (independent of application)

    • A generic product can be re-used for different independent applications.
  • Generic application Safety Case (for a class of application)

    • A generic application can be re-used for a class/type of application with common functions.
  • Specific application Safety Case (for a specific application)

    • A specific application is used for only one particular installation.
    The underlying idea is that a Generic product Safety Case (GPSC) will present the safety case for a product, regardless of how it is used, so that it can be deployed in a variety of different safety related applications. The Generic application Safety Case (GASC) will present the safety case for an application without specifying the actual products to be used as components. It will simply refer to the generic product properties that the components should have.

    Unfortunately, this makes the boundary between GPSC and GASC rather fuzzy, because a complex system that can use "generic" components (and therefore has a GASC) can itself be deployed as a component in a greater, more complex system. Then the "generic application" becomes a "generic product" within the more complex application.

    For example, a controller for wayside objects could be a generic application that can control a variety of different objects without specifying exactly which "brands" must be used. Using a particular kind of controller in an interlocking system would make it a generic product within that system. However, this should not influence the evidence for the controller’s safety properties.

    Finally, the Specific application Safety Case (SASC) presents the safety properties of a particular combination of products in a given application. It will, of course, draw on the underlying GPSCs and GASC, but in particular, the details of planning and operation will be relevant here. In fact, EN 50129 prescribes "separate Safety approval ... for the application design of the system and for its physical implementation... ", so there must be two SASCs:

    EN 50129 requires the same structure for all the above kinds of safety case, although the contents of the various sections will depend on the kind of safety case that is involved.

    3. Cost Implications

    3.1 Getting started

    The amount of documentary evidence that the CENELEC standard requires is formidable, and producing a safety case looks like an intimidating task. But it is much simpler - and cheaper - that it would appear to be at first glance. Remember that a safety case is really a line of argumentation, and most of the necessary information will already exist.

    Let’s look at the various sections of the safety case. The Definition of System contains the kind of information that you have to provide to your engineers so that they will know what to build. A brief description of the concept has probably been produced for presentation to management, in order to get the budget authorised. Specifications, interface descriptions and the like are part of normal engineering work, and producing and maintaining the list of applicable documents is a normal configuration management task. So the task of producing section one of the safety case boils down to a cut-and-paste exercise with a bit of editorial polishing afterwards.

    For the quality management report the situation is even easier. The Quality Manager will normally be expected to report to e.g. the board of directors at least once a year, explaining what he has done, what he hasn’t done and why. He will be well advised to identify the documents that prove that he really did his job and that the results were acceptable. So the Quality Management Report already exists!
    There may still be a bit of editorial polishing necessary, because the Quality Manager might have reported for all projects in one go, so the non applicable sections must of course be removed.

    For the Safety Management Report we have the same situation: the Safety Manager must report to somebody, so the report already exists. It, too, may need some editorial polishing.

    The Technical Safety Report is a bit more work. However, it contains basically the information that a manufacturer would supply to his customers in e.g. data sheets etc. Identifying where the proof can be found that the product really does have the technical properties that are claimed is something that the legal department should be very interested in. It’s what will be needed to ward off any liability claims that might arise. So if the data hasn’t already been compiled, it’s high time it was!

    As can be seen from the description of the technical safety report, this could be more than a cut-and-paste exercise. But it doesn’t require producing documentation that wouldn’t be produced otherwise.

    The section on related safety cases is basically part of the design documentation. If "safe" components are used, the corresponding documentation can be identified by the configuration manager. And summarising the conditions under which the components remain safe is a necessary input for the design engineers.

    Finally, the conclusion is something "new". But we have seen that most of the safety case already exists, so that producing one is mostly an editorial exercise with a very limited amount of new text!

    3.2 Re-use

    Much of the work invested in generating one safety case can be re-used in another. Certainly the descriptions of what was intended for quality and safety management will not change substantially, so only the corresponding evidence of what was actually done needs to be updated. But the potential for re-use can be much greater than that.

    Complex technical systems are made up of less complex components, which in turn will consist of parts which are even less complex. This inevitably leads to a hierarchical structure of products. When safety cases have been produced for the bits and pieces in the bottom row of such a hierarchy, they can be used over and over again, in all higher level combinations. The same will apply to the products on the next hierarchical level, all the way up to the final products. In other words, for each product the safety case has to be produced exactly once. And the further up you get, the less you have to prove, because most of the proof is already contained in the lower level safety cases.

    Similarly, if a product, for which a safety case already exists, is modified, the new safety case can be based on the already existing one. Only the changes and their effects need to be argued for. This is evidently considerably less work than producing a whole safety case every time.

    4. The benefits of the CENELEC approach

    4.1 Cross acceptability

    The CENELEC standards foresee a very clear and uniform way of presenting the evidence that a given product or application is safe to use. So at least for the Generic product Safety Case and the Generic application Safety Case, one safety authority will be able to accept a safety case that has been accepted by another authority. The only additional requirement could be to assure that the safety requirements and application conditions are still applicable or compatible.

    For specific applications it is reasonable to expect that only local authorities will be responsible for granting approval, so the question of cross acceptance should not arise.

    4.2 Efficiency of the approval process

    The approval process will require at least the presentation of a safety case and an assessment report. For the assessor, a well-structured and complete safety case will greatly simplify his task, shortening the time he needs to produce his report.

    For the authorities matters will also be simplified. When the safety case is clear and easy to understand, all they need to look for is an assessment report confirming that what they have read in the safety case is, in fact, true. It is unlikely that they will require further documentation in order to become convinced of the product’s safety. And if the hierarchical structure described above is used, the safety cases will become simpler and simpler as time goes by.

    5. Conclusion

    A safety case is a line of argumentation and not just a collection of documents. The CENELEC standards prescribe a clear structure for the contents that can draw on reports and other documentation that are produced as a part of normal work.

    The CENELEC approach enforces a transparent and effective way of producing and documenting safety related products. In return, it leads to efficient approval processes that can often be quite widely applicable.

    In the course of time it can be expected that safety cases will become simpler and simpler because they will be based on already existing and approved safety cases. This will facilitate and accelerate both the production and the authorisation processes.
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     

    1 At the time of writing, only EN 50126 has been adopted as a standard. The others are still pre-standards. For simplicity, they are also referenced as standards (EN instead of prEN resp. ENV).
    [back to text]

     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     

    2 For simplicity, the term "system" will be used in a very generic sense that includes subsystem, equipment, product etc.
    [back to text]