Odd Nordland
SINTEF Telecom and Informatics
Systems Engineering and Telematics
NO-7465 Trondheim
E-mail: Odd.Nordland@informatics.sintef.no
URL: www.sintef.no/~nordland
Abstract: Rail traffic is controlled by a set of interlocking computers distributed within the railway network and on-board computers on the trains. The safety assessment and validation of such computers shall not depend on the system architecture, so common assessment criteria are needed. The ACRuDA project consisted of identifying the state of the art, defining a common method and common criteria for assessment, applying them in case studies and refining them in the light of the case study experiences. The project succeeded in defining a common set of criteria that are applicable to all currently implemented digital architectures. Copyright © 2000 IFAC
Keywords: Distributed computer control systems, Railways, Safety
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 trackside 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. However, this task is complicated by the fact that there are different system architectures that can be used to achieve a safe system.
A safety assessment should concentrate on the functions that the systems are to perform and not on the internal structure of the system performing those functions. In addition, safety assessments of differently structured systems should be comparable with each other, so that also the differently structured systems can be compared with each other. This gave rise to a need to identify assessment methods and criteria that were not dependent on the system's architecture.
ACRuDA, "Assessment and Certification Rules for Digital Architectures" is a project that was partially funded by the Commission of the European Communities (CEC) under the Framework IV research program. The aim of the project was:
The scope of the work encompassed both the application level and the computer platform level.
Participants were recruited from suppliers, operators and assessment bodies in various European countries. The suppliers were:
Operators were:
Finally, the following assessor organisations participated:
The project was led by MATRA and divided into six work packages, under the leadership of different participants. Within each work package, tasks were defined and task leadership was allocated to various other participants, so responsibilities were fairly evenly distributed in the project. In the following sections, the task leaders are identified in brackets in front the task description.
This work package was under the leadership of INRETS. The objective was to gather all relevant information on current safety architecture designs and assessment methods. The following activities were defined:
The work resulted in two reports describing the state of the art that were an excellent starting point for the next work package.
The first report, deliverable D1, provides a description of the currently used safety critical digital architectures and a survey of the state of the art in assessing the safety of such systems. It concluded that European train control equipment could integrate various types of safety critical architectures used in different countries.
The second report, deliverable D2, was more concerned with the use of standards and their application in various countries. The standards can be viewed as a collection of requirements that developers have to fulfil. The report provides recommendations on how to cope with unclear requirements, gaps in the standards and how to determine suitable measures.
This work package, under the leadership of MATRA, aimed at defining a common method for validation and certification by analysing the methods and tools that had been identified in the previous work package. It contained the following tasks:
The work resulted in a report, deliverable D3, describing a mutually agreed method for assessing the safety properties of digital architectures and an agreed set of criteria to be applied. It provides information on the way a product or process is to be assessed by a third party and identifies top level criteria from which an assessor can derive detailed architecture specific criteria to be fulfilled.
It starts with a brief description of the background in terms of the certification requirements that result from the relevant EU directives. Then the principle concepts involved in the assessment and certification process are elaborated. The development process for a product is described, mainly based on the description given in the relevant CENELEC standards. This is the framework for the assessment and certification processes.
The recommended assessment and certification processes are then elaborated. This covers
Finally, the assessment criteria and the terminology round off the report. Deliverable D3 is the key result of the project.
SNCF was responsible for this work package. Its objective was to determine how effective the assessment process that had been defined in the previous work package actually was by applying it to real cases. The tasks performed were:
Three digital architectures were selected:
The criteria and methods that had been identified in the previous work package were applied to selected portions of DIGISAFE and SARA in order to demonstrate the methods' effectiveness.
This exercise revealed some shortcomings in the processes and criteria that had been defined. Applying the processes revealed that a considerable amount of supplementary information is necessary in order to perform a complete assessment. Deliverable D3 could not be used as a standalone document, but it was evidently a good place to start.
For ELEKTRA, a more global approach was adopted. Instead of performing an assessment on a limited portion of the system, all of the criteria were examined to determine if they were applicable to at least some part of the system.
This revealed certain weaknesses in the criteria, such as the use of qualitative expressions that required interpretation. There were also criteria that were phrased too concisely, assuming additional information (such as context, environment) that was not explicitly mentioned. Such criteria could be misunderstood.
Finally, some missing criteria were identified. These were criteria that were so "obvious" that nobody had thought of mentioning them, criteria that were implicitly included but not elaborated in detail or they were criteria that had indeed been overlooked, such as for example criteria for assessing validation and plans.
Some of these shortcomings could be rectified in the final version of deliverable D3, but unfortunately not all. Time and budget constraints left some questions unresolved.
The objective of this work package was to gain recognition for the certification scheme from the railway community. To this end, a Users’ Group, consisting of about fifty representatives from suppliers and operators throughout Europe, was convened annually to discuss the results. This not only provided valuable feedback to the project, but also contributed to dissemination of the results of the project.
In addition, the project participants presented the project in a variety of fora and papers. This work package, under the leadership of Lloyd’s register, is summarised in deliverable D6.
The work packages to date had produced a number of individual documents describing various aspects of the certification and assessment process. TÜV Rheinland was responsible for the synthesis of these documents into a single document, deliverable D7, which covered those aspects that were not contained in other deliverables. It provides background knowledge that is necessary to understand the functionality, design and safety properties of different types of architectures.
This work package was the "bracket" that held everything together. MATRA Transport International had the overall responsibility for the project. The tasks, all of which were performed by MATRA, were:
The deliverables D8 and D9 are the visible results of this work package.
The principle results of the ACRuDA project are contained in a total of eleven deliverables, which are:
Deliverables D1, D2 and D3 are public documents that can be obtained through the CEC or from the participants. They are also available on the Internet at www.informatics.sintef.no/~nordland/ACRuDA/ as HTML files. D10 does not exist as a separate document; it was incorporated into D3. Deliverables D6, D8 and D9 are of little interest outside the project, because they deal mainly with project management matters. They are restricted documents that may only be made available to the participants. The remaining reports D4, D5 and D11 contain proprietary information that is not freely accessible without express consent from the affected companies.
Deliverables D1 and D2 give a description of the state of the art at the time they were written (see also section 3 of this paper). Things have not changed substantially since then, so they will remain useful for some time to come. Deliverable D3 is a good reference to use when performing an assessment, although it’s not a stand-alone document: supplementary information is necessary.
Nevertheless, the ACRuDA project has succeeded in defining a common set of criteria that are valid and applicable for all digital architectures that are currently implemented. The publicly accessible results of the project are a good starting point for performing an assessment and give a comprehensive survey of the formidable task of determining the safety characteristics of a microprocessor based safety system.
The ACRuDA project brought together suppliers, operators and assessors from a number of European countries. The exchange of knowledge and experience that this process produced was in itself a justification for the project. The participants would have liked to "polish" the results of the project and in particular resolve remaining open questions. Time and budget constraints prevented this. So there is still work left for an eventual follow on project!