A Railway demonstrator model for experimental ... - CiteSeerX

A Railway demonstrator model for experimental investigation of integrated specification techniques Dipl.-Ing. Stefan Einer, Dipl.-Ing. Harald Schrom, Dipl.-Ing. Roman Slovák, Prof. Dr-Ing. E. Schnieder Technical University of Braunschweig Institute of Regulation and Automation Engineering, Langer Kamp 8, Braunschweig, Germany {einer | slovak | schrom | schnieder}@ifra.ing.tu-bs.de

Summary: In the paper conceptual and physical realisation of a railway demonstrator model is presented. The main purpose of its design is a validation of different control algorithms specified by different project groups in real operating conditions. Conceptual tasks of the realisation are the specification of the target operational behaviour and the derivation of functional structure of the railway model. According to the users requirements several utilisation options are being considered. Furthermore the implementation concept is described.

1

Introduction

Engineering applications are determined by increasing importance of their software components. The high complexity and demand for safety of current engineering systems require the development of methodologies which integrate more or less formal techniques used in the engineering and computer sciences. To meet this requirement, the DFG has launched the priority programme “Integration of Software Specification Techniques for Applications in Engineering”[1]. This program consists of fourteen projects carried out by research teams distributed on German universities and research institutions. To establish a reference for comparison of different approaches two case studies were provided within the research program. One of them is the case study from the traffic control and protection domain, especially represented by an advanced project in specification of a radiobased railway level crossing control application [2] To validate the results of the projects, simulation in requirements engineering [3] as well as in system design and realisation is needed. The problem is that there is no real continuos way from formal paper work to real implementation. In other domains, e.g. chemical process technology, an additional step of development, also

84

called “scaling up” is widely accepted to handle this problem. It means to experiment in low scaled processes, before starting the real operation. Such experiments seems to be necessary also in the software engineering, but here experiences are being mostly missed [4]. Therefore it has been decided to build a physical railway model for validating the research results of the priority programme under nearly real operating conditions. To achieve this aim several practical problems have to be taken into account. Firstly the use of the physical model has to be efficient available for all participants of the research program. To solve this problem an internet real-time connection is planned. A concrete kind of its realisation should be investigated in the second project phase. Secondly, within diverse research projects different modelling languages supported by different software tools are used. Some of the applied formal techniques do not allow modelling of all aspects included in the case study specification. Thus a suitable tool coupling concept and a flexible architecture of the railway model control are required, which will make it possible to join model parts designed by different tools into an one virtual model. The following paper describes the specification of the target model behaviour. Further the functional concept of the railway model control is given and several utilisation options are presented. The last section gives an overview about hardware realisation of the railway model.

2

Specification of target behaviour

In system engineering a distinction between the requirements analysis phase and system design has been widely accepted. The main reason of this distinction is to optimise the technical solution according to the requirements of the user and his process flow instead of adapting the process flow to the technical system. Therefore one task is to describe the process flow exactly as a requirement of the system to develop. In engineering systems, the process flow is not only a workflow but it is also a technical process and is here called the operational process. In this chapter are introduced the main aspects of the operational process in general before the specific operational process, to be realised on the railway model, will be explained. 2.1 The operational process in engineering systems The operational process is a hybrid process consisting of technical and human parts. As fig. 2.1 illustrates for railway domain, there are essential technical and human processes and also necessary supervision- and safety-processes in all safety relevant engineering systems. Supervision- and safety- processes are necessary because of several facts: The obvious one is that as well humans as technical components can fail. Another fact is, that there is an uncertainty as well within the human actions as within the essential technical process. Therefore undesired situations may occur also in faultless operation. These situations must not lead to dangerous situations and have to be detected by the supervision and if necessary they have to be corrected by the safety procedures. A third reason for considering

85

safety processes is, that the essential process includes inherent dangerous operations, which become safe, if they are expanded by the safety processes. In this case, the safety-process is also essential. Some essential processes or some necessary supervision and safety processes are carried out automatically and belong to requirements to the control system. The control system receives information about the state of the operational process by sensors and influences it by actuators, but because of permitted uncertainty of the operational process, the control system does not determine the operational process completely. Therefore from the view of the control system the operational process belongs to the system environment, which determines the system input and leads to a special output. For proving the control software, it is necessary to specify all possible classes of scenarios, which could occur in operation and to specify how the control system has to influence them.

essential human actions

A

B supervision

essential technical process

supervision and safety processes

Fig. 2.1: The operational process in engineering systems 2.2 The operational process of level crossing case study The operational process of level crossing case study has been published in [1] and [2]. Here it is shortly discussed in relation to the general idea of operational processes in engineering systems as described above. The system is a decentralized level crossing which control process bases on radio communication between train and track. The target behaviour of the level crossing protection can be roughly described as follows (fig. 2.2): A train approaching a level crossing switches on the trackside control unit by radio communication. Consequently the level crossing control first turns on the traffic lights for the road traffic to "yellow " and later to "red". After a defined time the lowering of the barriers will be started. When the barriers have reached its down position, the level crossing is in the safe state. In a sufficient distance from the danger area, the train interrogates the status of the level crossing. When the train gets the statement that the level crossing is safe, it is allowed to pass the level crossing. After leaving the level crossing, the train activates a vehicle sensor and induces the annulment of the protection. The described process is the regular one and it includes especially the safety process to prevent collisions between the trains and the road traffic. It is an essential safety process, because the level crossing must always be in the safe state

86

when the train is crossing it. Requesting the status is a supervision process. It is only needed because a dangerous situation may occur in consequence of faults or especially operational situations. Technical faults, which have to be considered in the operational process are shown in fig. 2.3. 1) activation order

train is approaching

level crossing open 2) acknowledgement

V

3) status request

train near breaking distance V

level crossing closed

4) status report

train having passed

level crossing to be opened

V

vehicle sensor 5) deactivation signal

Fig. 2.2: The regular scenario of the operational railway process An example for an undesired situation in faultless operation is, that for operational reason the train can not reach the level crossing as fast as usually, even if there is no fault. Then after a certain time the level crossing has to be supposed as unsafe. In all cases, if the train approaches the level crossing and it gets the status report “unsafe” or no status report at all, a safety process has to stop the train automatically. Furthermore operational procedures must been defined to guarantee the train passage even if some safety processes have been applied. The example shows the complexity of the operational process. This leads to lots of test cases which have to be specified for validation of the control code. failure of radio communication

Y (2), 5

maximum closure time elapses 1, 7/8

Y

Y

barrier failure 1 … when closing 5

Y

Y

maximum arrival time elapses 5, 6

red light failure 1 … when barriers are still up 2/3, 5 … afterwards, untill status report 5

Y

Y

Y

yellow light failure 1 … during yellow light phase

V

vehicle sensor failure

Y

Y4

Y 1, (2)

1) report failure to operations centre ad 5) danger point remains under supervision, train stops, then passes crossing under driver responsibility 2) closing procedure is not started 3) closing procedure is cancelled 6) deactivation by train 4) switch to red light phase 7) deactivation by operations centre 5) level crossing not reported to be safe 8) level crossing remains closed until train has passed

Fig. 2.3: Technical faults to consider within the operational process

87

3

Functional concept of the railway demonstrator

3.1 Functional structure The figure 3.1 gives a rough overview about the railway demonstrator. Within the first project phase the physical railway model installation consisting of a vehicle and a radio controlled level crossing and the centralised demonstrator control have to be realised. The flexible architecture of the demonstrator control should allow an internal implementation of the formal control algorithms model provided by the external project partners. For the second project phase coupling of external project partners with the railway demonstrator using Internet is planned. Online- operation supervision (extern)

Vehicle control implementation (extern)

Rail .crossing control implementation (extern)

Internet

WebCam

Control algorithm implementation (intern)

Internet

Gateway

Centralised demonstrator control

Vehi cle

Rail .crossing

Project phase 1

Fig. 3.1 Demostrator in overview In order to meet all at the beginning mentioned requirements a functional structure of the demonstrator control (fig. 3.2) was derived. It consists of three main functional groups. Besides the external control algorithm model, developed according to the case study specification, these are the basic functions of the demonstrator. The group of experimenting functions is being designed after a detailed user requirement analysis. In the next sections a more detailed description to each demonstrator function block will be given. A detailed explanation of the railway model device can be found in chapter 4. The main task of the experiment control is to prepare, configure, start and stop the experiment as well as data recording and processing and finally to visualise the results obtained. Also a suitable mode of the environment control has to be chosen. Experimenting functions Experiment control

Control algorithm model

Environment control

Railway model control

Railway model device Basic functions

Fig.3.2 Functional structure of the demonstrator

88

The environment control has to simulate the possible influence of the environment. On the one hand these are the inputs resulting from potential train driver behaviour and from possible actions initiated by the operation inspector supervising the functionality of the level crossing. On the other hand the hazardous occurrence of failures has to be simulated. Failures of yellow or red traffic lights (to be regarded separately), barriers, the vehicle sensor and the delay or loss of telegrams on the radio network are considered. One of three possible modes of environment control has to be selected before starting an experiment. Concretely a manual environment control using the command desk or the control computer can be replaced by a concrete scenario or by a hazardous environment influence. The railway model control stands for a direct interface to the railway model device. Its task is to bring together all control commands from higher functional layers, to test their admissibility and to adapt them to the model device requirements. On the other way the actual operating states of the model device components are to be acquired and transmitted in a suitable form to the experiment or environment control as well as to the external control algorithm model. 3.2 Utilisation options As already mentioned, the control algorithm models are being designed by different external project partners participating in the research program. The model functions which have to be implemented in accordance with the case study specification can be dedicated to three functional parts: trainborne control system, trackside level crossing control system and the operations centre. Modelling of this functional blocks can be realised as an unique model or it can lead to three separate models. Such a separate solution allows to combine different parts of the control algorithm model from different projects using also formal modelling languages which are not suitable to model all required system aspects. Operartion A centre P Control algorithm I model (I)

Experiment control

User computer 1 I T C

Trainborn control system A P I

Control algorithm model (II)

User computer 2

Level crossing control system Control algorithm model (III)

A P I

User computer 3

f r a m e w o r k

A P I

Failure occurrence simulation

Simulation of operating inspector behaviour

Radio communication simulation

Simulation of train driver behaviour

Environment control

R a i l w a y m o d e l d e v i c e

A P I

Railway model control

Radio interface

Demonstrator computer

Fig. 3.3: Realisation of the demonstrator control using a distributed control algorithm model

89

In order to realise the coupling of the user control algorithm models with the demonstrator control an interface definition containing 27 data telegrams has been specified. On the middleware level an API (Application Protocol Interface) specification is available in order to establish an on-line connection among different software tools using a special ITC Framework [6]. Experiment control

Operartion centre

I T C

Trainborn control system (whitout positioning function)

A P I

f r a m e w o r k

A P I

Failure occurrence simulation

Simulation of operating inspector behaviour

Radio communication simulation

Simulation of train driver behaviour

Environment control

A P I

Digital track map

Level crossing control system

Control algorithm model

User computer

Railway model control

m o d e l d e v i c e

Positioning

Demonstrator auxiliary functions

A P I

R a i l w a y

Radio interface

Demonstrator computer

Fig 3.4: Realisation of the demonstrator using unique control algorithm model missing positioning function The fig 3.3 shows one option of the connection, where the user control model is realised by three separate parts running on three different computers. If the users modelling language do not allow to describe all the functional aspects of the case study specification, it is possible to add the missing functions by activating one of the demonstrator auxiliary functions. The fig 3.4 illustrates the demonstrator configuration where an unique user control model is used and the missing positioning and digital track map are added from the demonstrator auxiliary functions.

4

Railway demonstrator of a wireless railroad crossing

The railway demonstrator is made of three trains of the type “Cargo Sprinter” on a ten meters round double track in the scale of 1:22,5 (IIm). A railroad crossing module and a switch are communicating with the three trains and the Demonstrator control computer via wireless DECT connections (see fig 4.1). The control computer gets its instructions from one or more user computers that may be connected via internet. This control computer supervises the operation on the model installation and exchanges data with a communication module operated by a C167 microcontroller. This module establishes a wireless DECT link to the first train.

90

Every train holds a communication module too, equipped with two DECT devices. Telegrams addressed to the train are forwarded to a train PC via a serial link. The PC is doing the data processing. The instructions for the physical motor are given via another serial link to the motor- and sensor-module. The microcontroller of this module determines the movement of the train and serves the odometer (a mileage indicator) and the balise antenna to obtain the location information which is reported back to the train PC. Information that is not valid for the fist train is forwarded to the next train, switch or railroad crossing. Response information is routed back to the control computer. The switch module only controls a motor that is the drive assembly of the switch. The railroad crossing module transfers the corresponding information to a fieldbus system which realises the communication within the railroad crossing track module. The communication modules are forming a data transmission comparable to a local area network (LAN). 8VHU&RPSXWHU

6HULDOOLQN :LUHOHVV'(&7FRQQHFWLRQ (WKHUQHW 0 0RWRU 2 2GRPHWHU %DOLVHDQWHQQD

&RPP X&&

0RWRU6HQVRUV X&& 5DLOURDG FURVVLQJ

FRQWURO FRPSXWHU &RPP X&&

&RPP X&&

&RPP X&&

&RPP X&&

&RPP X&&

7UDLQ3& ZLWK41;

7UDLQ3& ZLWK41;

7UDLQ3& ZLWK41;

0RWRU6HQVRUV X&&

0RWRU6HQVRUV X&&

0RWRU6HQVRUV X&&

0RWRU6HQVRUV X&&

0

0

0

0

6ZLWFK

2 7UDLQ

2 7UDLQ

2 7UDLQ

Fig 4.1: System architecture The realisation of the trainborne equipment can be seen in fig 4.2. On the chassis of a “Cargo Sprinter” the electronic boards are mounted. On the bottom the motor module with the plugged in microcontroller is placed. Above the communication module with its two antennas of the DECT devices and another plugged in microcontroller is located. On the top a pentium PC together with a hard disk and the PC power supply is put on. The power for the operation of all units is supplied from the metal rail track. This compact unit is therefore a nearly autonomous train vehicle. The relevant trackside equipment is shown in fig 4.3. The railroad crossing module consists of two barriers, four traffic lights, four axles counters, one building for the wireless communication and one command panel. Every component is placed in a slot which are spread around the module. The slots communicate with each other by the use of a fieldbus system that provides the local communication.

91

The barriers can be controlled separately. They can move up and down and can be stopped at every position. When reaching the end position, the motor is stopped and a message is generated. The motor can be set into a disturbed state what stops the barriers immediately and produces an error message. This error message holds the same information, no matter if the message is generated because of a hardware error, e.g. a physical obstacle is blocking the barrier, or generated by a software induced disturbance. This makes it possible to run independent error scenarios. An hardware error is detected by checking the motor torque.

Fig 4.2: Electronic equipment The traffic lights can be set into red, yellow or off status. The combination of red and yellow light contemporary is not allowed. The correct function of the traffic lights is checked and disturbance messages can be received and generated as already described for the barriers. The axles counter is realised by the use of three light barriers. Two of them are necessary to determine the amount and the direction of the axles passing. This information is reported. If all three barriers are cut off, an error is detected and reported as a disturbance. Two of these axles counters can be used to form a vehicle sensor that produces a signal when the train left and the railroad crossing is cleared. The building for wireless communication holds the communication module equipped with DECT devices as described before. It also powers the fieldbus system and is shifting the information between wireless and the fieldbus. The command panel is useful for local control of the railway demonstrator installation and failure injection . The push buttons can be associated with every function and display any condition desired.

92

Fig 4.3: Railroad crossing track module

5

Conclusion and Perspective

The realisation of the operational process is a very complex task. A physical railway demonstrator model seems to be a suitable mean to depict all aspects of real operational system behaviour. Considering the software validation real operational conditions can be offered. The railway model has been conceived and is under construction. After a complete hardware implementation a good base for experimental integration of specification techniques and for the validation of models designed will be established.

6

References

[1] Ehrig, H., Geisler, R., Klar, M.: Integration von Techniken der Softwarespezifikation für ingenieurwissenschaftliche Anwendungen. Informatik - Forschung und Entwicklung, 13(1):43-46, 1998 [2] Schnieder, E., Jansen, L.: Traffic Control Systems Case Study: Problem Description and Note on Domain-based Software Specification In: Integration of Specification Techniques with Applications in Engineering; extended abstracts. Forschungsbericht des Fachbereichs Informatik der TU Berlin, 2000. [3] Krone, M.: Visual Formal Specification in Railway Systems Development. In Doctoral Consortium of ISRE 97. Annapolis, USA, 1997. [4] Snelting, G.: Paul Feyerabend und die Softwaretechnologie. InformatikSpektrum, Oktober 1998, pp. 273-276. [5] Referenzfallstudie Verkehrsleittechnik: funkbasierte Bahnübergangssteuerung In: Forms 2000 - Formale Techniken für die Eisenbahnsicherung; VDIFortschrittbericht, Reihe 12, Nr.441; Hrsg.: E. Schnieder, 2000. [6] König, S., G. Bikker, G.: Developing and Implementing a Framework for Case Tool Coupling: Object Orientation upon Tool Level“, Proc. ECEC Leicester, April 2000, pp. 143-153

93