This text was presented at
the 11th Safety-critical Systems Symposium,
held in February 2003 in Bristol, UK.
The original is published by Springer-Verlag London Ltd. in
"Current Issues in Safety-critical Systems"
edited by Felix Redmill and Tom Anderson,
ISBN 1-85233-696-X, pp.163-172
Odd Nordland
SINTEF Telecom and Informatics
Trondheim, Norway
Modern railway networks make extensive use of computer systems to control and monitor rail traffic in a safe and reliable way. A central element of such systems is the set of interlocking computers that control traffic and track-side equipment at stations and junctions. Here the term interlocking refers to the fact that any one computer must set the signals, points etc. that it controls in dependency of the settings at neighbouring locations. Each computer must therefore receive information from the neighbouring computers about the status of e.g. the signals and point switches that those computers control. In addition, it must get information about approaching and departing trains, and process this information together with its local data in order to set its own signals, point switches etc., and transmit appropriate data to the neighbouring systems for processing there. In addition, trains travelling in the area controlled by an individual interlocking computer must also receive up to date information.
On such networks, trains are also equipped with on-board computer systems that send data to and receive and process data from the interlocking computers. The kind of information sent to the train includes data about the train's maximum permissible speed, the distance to the next signal, the status of that signal etc. The on-board computer transmits data back to the interlocking computers, such as the train's identification, position, momentary speed and travelling direction etc.
Finally, there are rail traffic control centres that communicate with the interlocking computers to monitor and control traffic throughout the railway network, or at least a significant portion of it. If necessary, in suitably equipped networks traffic control centres can also intervene and stop trains directly. Thus, safe rail traffic is achieved with a highly distributed set of computers, both static and mobile, performing dedicated portions of the overall control task.
Clearly, the safety of a modern railway network is then highly dependent on the reliability and safety of all these computer systems and their interactions. Therefore it is natural to subject such systems to a thorough safety assessment before authorising their use. This together with European integration has given rise to a need for common principles and procedures.
One step in this direction is the adoption of European standards for railway applications, notably EN 50126 (CENELEC 1999), EN 50128 (CENELEC 2001) and prEN 50129 (CENELEC 2000). 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 prEN 50129. prEN 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 prEN 50129.
prEN 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.
The word "case" is used in a variety of contexts. We have special cases, briefcases, suitcases, 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.
The safety case must in itself contain enough information to give a clear impression of the system’s safety properties and indicate where the details can be found if this is desired.
prEN 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.
"This shall precisely define or reference the system/subsystem/equipment to which the Safety Case refers, including version numbers and modification status of all requirements, design and application documentation."
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.
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:
This is the corresponding report for safety management. As with the quality management report, the safety management report involves:
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 and design principles 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.
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.
This is more than just the statement that the product is sufficiently safe. prEN 50129 states:
prEN 50129 identifies three different categories for Safety Cases, viz.:
The underlying idea is actually fairly simple. It is assumed that railway applications are complex systems that consist of a number of less complex sub-systems that are configured to interact in a way that will fulfil the specified requirements. The sub-systems consist of even simpler "sub-sub-systems" that are configured to interact appropriately, and so the structure goes down until we reach a bottom level with "simple" products that cannot sensibly be subdivided further (i.e. we're not necessarily down to nuts and bolts). We start by "proving" that the simple products are safe, regardless of the configurations in which we use them. We then show that the configurations will be safe, provided we use safe products or configurations of products. And finally, we show that a specific configuration of explicitly identified products (or configurations of products) must be safe, because the (configurations of) products that it uses are safe, the underlying (system) configuration is safe and the way the products were incorporated into the system is safe.
In this context, the 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 (configuration of products) without specifying the actual products to be used as components. It will simply refer to the generic properties that the products should have.
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, prEN 50129 prescribes "separate Safety approval ... for the application design of the system and for its physical implementation... ", so there must be two SASCs:
Unfortunately, the boundary between GPSC and GASC is rather fuzzy, because, as was pointed out above, a complex system that can use generic products (and therefore has a GASC) can itself be deployed as a " product" in a greater, more complex system. Then the "generic application" becomes a "generic product" within the more complex application. And then a specific application that is based on that generic application becomes - what?
At this stage it becomes evident that the expressions "generic product", "generic application" and "specific application" are highly context dependent. For the purposes of producing an appropriate safety case, the name should not play a significant role, but the contents of the safety case will vary according to the context (or category, to use the term in the standards).
The expression "Generic Product Safety Case", that is used in the standard, is in itself somewhat misleading, because the word "generic" actually refers to the safety case, not to the product! In spite of the fact that the standard mentions "generic product", it is in fact a "Generic - Product-Safety-Case" and not a "Generic-Product - Safety-Case". Put another way, we have a "generic safety case for a product", not a "safety case for a generic product".
That being said, we still have a problem. Safety depends on the context in which a product is used, so presenting a generic safety case for a product without taking into account the way it will be used, i.e. its application, would appear to be a somewhat pointless task.
Take for example a microprocessor. What can be "dangerous" about a microprocessor, when you try to ignore the way it will be used? Well, it certainly has fairly sharp wires sticking out, so it might prick your fingers if you're not careful, and it could certainly do some harm to you if you swallow one. But does that require a safety case? Of course not.
However, if you intend to use a microprocessor in a safety related application, you will be able to say something about how suitable the microprocessor will be without having to go into details about the actual application. You could, for example, say something about the microprocessor's ability to perform calculations at a speed that will normally be more than fast enough for any safety related application, its reliability in performing those calculations accurately, and how robustly it will react to adverse conditions. That's what the generic safety case will be about!
In our example, you will also identify limitations to the type of safety related application that the microprocessor may be used in. This could for example relate to the processor's robustness, the need for a stable power supply, the necessary reliability of its periphery or even the maximum calculation rate for which accuracy can be guaranteed. These limitations will be demands on the application, i.e. conditions that must be fulfilled in any safety related application if the microprocessor is to be a genuine contribution to that application's safety. This is what the standard calls "safety related application conditions"!
You can also say something about the quality assurance routines that were applied in order to ensure that each microprocessor that leaves the factory has the specified properties. You can say something about the design principles that were applied and why they guarantee that the microprocessor will be the excellent product you claim it to be, and why this makes it suitable for use in safety related applications. And if you had potential safety related applications in mind when you designed the microprocessor, you can also say something about what you did to achieve those safety relevant properties.
So even without knowing anything about the intended application, you have all you need for a full scale generic safety case for your microprocessor. Or any other not too complex product: when things get complex you'll probably end up with a generic application.
In the previous section it was pointed out that "generic product safety case" should really be "generic safety case for a product". For a "generic application safety case" the situation is the opposite: this is truly a safety case for a generic application. So what is a generic application?
The idea behind the expression generic application is that using a set of products in a given configuration is an application of those products. If we don't specify exactly which particular products are being used, but keep to generic notions, then we have a generic application.
In the railway systems described in the introduction there will be some kind of system that controls the individual pieces of track-side equipment that an interlocking computer governs. Such a system will typically contain a microprocessor and some kind of interface to the track-side equipment, depending on the kinds of object to be controlled.
Even without knowing which kind of microprocessor the system will be using, it will still be possible to say something about the safety properties of such a system. This will of course involve breaking the system down into smaller parts ("products") and showing that the planned configuration of products will interact in the intended way. Since you haven't (yet) identified exactly which products you will be using, you will end up identifying requirements that the products must fulfil if the application is to be safe. Given that the products have those necessary properties, you can then go on to show that the planned configuration will indeed interact in the intended way.
Here too you will have to (and be able to) say something about the quality and safety assurance activities you performed in order to guarantee that the generic application will have the desired quality and safety properties.
In real life, some of the products to be used in a generic application will be known in advance, whilst others will still be open for discussion. In our example, the track-side equipment to be controlled is probably already there, so that part of the generic application will be known in advance. On the other hand, the microprocessor to be used may still be undecided, and this will probably influence the choice of interfacing equipment. So we'll end up with a generic application that contains specific products (the track-side equipment) and "generic products" (the unspecified microprocessor etc.).
For the specifically identified products (track-side equipment in our example) there should be generic safety cases, so the safety related application conditions that those generic safety cases identify can be explicitly fulfilled in the generic application. For the "generic products" you will end up with requirements to the generic application. These will contribute to the generic application's safety related application conditions.
So here too we have enough to produce a full-scale safety case for our generic application. If we then include this "generic track-side equipment controller" in a rail traffic control system, that rail traffic control system will also be a generic application, even if everything else is explicitly identified. For the safety case of the track-side equipment, this has absolutely no effect. The fact that that generic application is being used as a "product" in a more complex system doesn't mean we have to rename the safety case!
Nevertheless, somewhere along the line we will want to build a real system, so we will have to take decisions and specifically identify which products we're actually going to use. Now our generic application becomes a specific application.
For a specific application life should be fairly simple. You have a generic application safety case that shows that the application will be safe if you use safe products, and you have explicitly identified products with generic safety cases that show that they are suitable for safety related applications. So all you have to do is show that those products "fit" into your generic application, i.e. that the safety related application conditions for those products are fulfilled by the generic application. You must also show that the generic application is suitable for the specific use, and finally you must show that the actual job of building the real system has been done correctly, and that operating, maintaining and ultimately decommissioning it can and will be done in a safe way.
Now this involves two fairly independent safety cases. Before you actually build and operate a specific application, the standard requires you to demonstrate that what you intend to build will be safe! That is the Design Safety Case for the specific application, and is the part where you show that the generic application you will be using is suitable and that the specific products you will be using in that generic application will result in a safe specific application.
Once you've shown that the specific application will be safe, you can start actually building it! Now you must show that the safety related application conditions that the design safety case identifies really are fulfilled, that the products that you install are the ones that the design foresaw and that the installation and integration has been performed correctly. And finally, you must show that the planned modes of operation, maintenance and decommissioning will maintain the required level of safety for the rest of the system's life cycle. This is the Implementation Safety Case for your specific application.
The preceding sections describe the ideas behind the various safety case categories that are identified in the (pre-)standard prEN 50129. The explanation given in the standard is exceptionally concise, so that there is considerable confusion about which category of safety case should be used when.
From the foregoing text the answer should be clearer: a Generic Product Safety Case should be created for "simple" products that cannot be sensibly decomposed into even simpler parts, a Generic Application Safety Case should be created for (sub-)systems whose component products are not all explicitly identified, and Specific Application Safety Cases must be created for real-life systems that are actually built and used.
The standard foresees a strong coupling between the various safety case categories, so that a large amount of the work need only be done once. Generic Product Safety Cases can be reused (referenced) in any and all safety cases for applications that use those products. A generic application safety case can be reused for all actual instantiations of that application, and a specific application design safety case can be reused for all identical instantiations of a specific application.
Used correctly, the standards can result in an exceptionally effective and economical way of demonstrating the safety of a large number of railway applications.
CENELEC (1999): EN 50126:1999
Railway Applications - The specification and demonstration of Reliability, Availability, Maintainability and Safety (RAMS)
CENELEC (2000): prEN 50129:2000
Railway Applications - Safety related electronic systems for signalling
CENELEC (2001): EN 50128:2001
Railway Applications - Communications, signalling and processing systems - Software for railway control and protection systems