Specification of Real-Time Systems for Protection Tasks in Automated High-Speed Transportation Systems

SPECIFICAnON OF REAL TIME SYSTEMS FOR PROTECTION TASKS IN AUTOMATED lllHG-SPEED TRANSPORTAnON SYSTEMS K. Jopke Institut fUr Regelungs- und Automatisierungstechnik, Tecbnische Universitit Braunschweig, Germany R. Knigge Siemens AG, Bereich Verkebrstechnik, Braunschweig, Germany

E. Scbnieder Institut fUr Regelungs- und Automatisierungstechnik, Tecbnische Universitit Braunschweig, Germany

Abstract. The system design method of Ward and Melior is used to describe the functional behaviour of the control and protection system of the high-speed maglev train TRANSRAPID. lbis operation control system has to control (ATC) and to protect (ATP) many vehicles. A simulation has already ~n run successfully at Siemens in Braunschweig. A substantial problem is to obtain the proof of the ATP (Automatic Train Protection) of the whole system on the functional level already. In Germany, this proof with regard to safety has to be passed at the TOv (fecbnicaJ Supervision Association). The implementation model which contains the functional behaviour is the only object which can be tested against the program code by the experts. The experts who are verifying the system should get a clearly structured specification which allows him to understand the correct relations between the program code and the implementation model. In particular. the real time aspect with regard to the method of Ward and Melior and guidelines made to interpret the system description will be considered. Keywords . Control system design; Describing functions; Real time computer systems; Safety proof; Software engineering; System analysis; Train control and protection.

The protection consists of several tasks which are responsible for vehicle (position and speed detection. monitoring . headway protection . emergency target braking vehicle propUlsion system monitoring and cutoff route safety (route locking. route proving and route release function) track points proving (track points operation. reversal. delocking. locking and proving function) safeguarding of data transmission

INTRODUcnON The German high-speed maglev system TRANSRAPID is a unique solution for the challenge of high-speed and efficient ground transportation systems. The operation of this advanced high-speed transportation system with operational speeds of more than 400 kmIh and braking distances of several IGlometres can only be managed by a fully automated operation control system. which provides all functions and facilities for protection. control and traffic guidance as well as their intercommunication (Giickel. Scbnieder. 1988). Especially the protection tasks must completely be performed by technical devices without any assistance of human operators.

All in all they guarantee a safe vehicle mission if 1) the protection tasks are functionally correct 2) implemented without failure

67

3} carried out by a highly reliable thus fail-safe operating facility

Formalized description applied once during the initial design phases Tool utilization for design. documentation and analysis during all phases Accompanying quality control On-line tests - computer assisted

Protection functions for the maglev system. i.e. all protection tasks which are carried out by vital computer systems and supported by a specially designed operation control system for vital computers are implemeated by high level computer pr0grams. The components of such a vital computer system are described by Frank (1991).

SPECIFICATION ME1HOD Scope of Application

Following the assumption that the vital computer system guarantees a highly reliable and fail-safe operation by its fault-tolerant design. only the safe behaviour of the software system must be guaranteed. This implies either the principle of a cleversion programming or an a priori failureless software! In the current application the latter principle has been chosen in accordance to the well anticipated rules and guidelines for protection systems in railway signalling. The total development of the software system for protection tasks must fulfil inordinately high demands.

In order to fulfill these high requirements imposed on the protection tasks of automation systems the respective tasks were specified according to the system design method for real time systems by Ward and Mellor (1985). The designed tasks were implemented in the target hardware via a high level language (Pascal-86) and a validated compiler. The software runs on the base of a real time operation system specifically adapted to this application. on fail-safe computers designed for railway signalling tasks.

In general. the demands must state the following

During the design phases of these automation systems, experts have already been evaluating their first results (design-accompanied expert report). Thus in the early design phases, documentation required for safety proof could already be adapted accordingly thanks to detailed discussions. Another advantage of a methodical system design as to designer teams and cooperation between designer and expert is that all of them are mastering the same descriptive language, thus making the design processes easier.

specific requirements: - transparency (modularisation) - correctness (of the tasks specification) - consistency proof of (functional) safety The following constructional elements and development method assure this a priori correctness of the complete programming system. I} Model of correct multi-level machines basis machine: fault-tolerant hardware core machine: modular operating system core (Input-Output interface) shell machine: modular shell interface (lIO driver. timing, multitasking, interrupt, memory administration) periphery machine: modular application programs

Method The system design method by Ward and MelIor (1985) contains means of description for the different design phases. In this paper. the Structured Analysis with Real TlIDe Expenditure shall be discussed only. In the system design, the EntityRelationship Diagram, the Essential Model (SA) and the Nassi-Shneidermann-Diagrams (in the programming process) were also applied.

2) Software developing environment High level programming languages for all machine levels Validated compiler Strict program development guidelines Structured programming technique

In the following. the transition from a global system representation to an examplary detail problem shall be presented. Fig. 1 shows a part from a possible maglev train system. which is not very abstract yet. The ATC and ATP systems are located on the vehicle and along the track on decent.raliz.ed equipments. Fig. 2 shows a formalized description of a decentralized OCS-Subsystem wherein the single processes represent fail-safe 2v3-<:omputers for transmission. protection. and control tasks.

3} Structured and computer-assisted software engineering Phase model, development processing plan Special design methodology

68

Task Control

Intemretation

Before presenting the use of control processes and their related state-transition-diagrams in an example, Fig. 3 shall demonstrate how the operation system for the OCS-computer applied here controls the tasks in principle. At first a task is in its basic state ("terminated"). As the automation system starts up each task is set in the "ready" state. Then the tasks are called in their priority assignment and set in the "computing" state (in doing so, system variables are set). After having computed the task initiation each task finally takes on the "waiting" state.

The transformation graph in Fig. 4 shall represent those tasks which have been priority-assigned (shown as p = x within the task). If the priorities are left out the following consideration is simplified by the fact that the inputs I. are no more functioning if another task is already active. The following definitions for the data flows are provided to explain the mode of interpretation: 1. All inputs Ix can provoke reaction of the control process at any time 2. All internal connections Oxy (x = source, y = sink) only provoke reaction if Task x has just been "computing" 3. All outputs O. are leading to the "waiting" state

The system designer or the programmer can only control the tasks between the two states "waiting" and "ready". Thus he can only determine whether the task shall compute or not! The operation system then calls the task if no other prior task is "computing" at that moment. In order to ensure operation of the automation system, control tasks make sure that the system consistency is always kept in and that no task is blocking the computer for too long. Thus two task states result for the user, i.e.

Thus, by taking into consideration the priorities, results the state-transition diagram in Fig. 5, whicb will be abbreviated in tbe following by "STD". In this application the highest priority bas the lowest number. Furthermore means the state "computing" in Fig. 5 that the considered task shall compute. In case of a called task with a higher priority the task will obtain the state "ready". For further testing of the STD, linkage between states and events is represented in Fig. 6 by a Mealy machine. The horizontal line in Fig. 6 represents states and the vertical line events. Within the Mealy machine, the respective states resulting from the linkage of one state and one event are set up.

1. "waiting" 2. "active" = "ready" or "computing"

Fig . 4 sbows three tasks with altogether two data inputs and three data outputs respectively as well as internal data flows . Here memories were encapsulated because of their insignificance in this consideration. Without any supplementary information the transformation grapb does not sbow bow the control process sball run in detail. Each data flow represents also a control flow because the receiving task must always react on the input data flow . For this reason, control flows going to the control process were left out because this fact bas been defmed once . The control flows shall only demonstrate whicb tasks are controlled. If Tasks I and Task 3 were the only ones whicb existed the control process would not be necessary because the causal reference would be sufficiently demonstrated by tbe data flows (with control effect) .

The Mealy machine can be subdivided into three blocks as follows : 1. Bebaviour on input flows 2. Bebaviour on internal flows 3 . Bebaviour on output flows Because of the fact that the tasks are self-terminating (according to Ward and Mellor they are only triggered), the third group does not give very relevant information. The second group describes the internal bandling of tbe tasks. In this case, partial results are transmitted whicb are not necessarily required because these tasks can also be controlled externally (via Ij. Due to the fixed priorities of the tasks (see the first group), Task 2 and Task 3 can be interrupted while being in the ·computing· state by the first task or, in one case, also by the second task.

The following definition underlines the distinction betwenn data and event of a flow: Input.

= Data,.

+ Event;.

This means that an input flow possesses both data and event with control effect. This is worth in analogy to output flows.

69

Definitions and Guidlines

and other aspects are provided by Petri-Nets which were proposed by Petri (1962).

The following definitions and guidelines were made during the developmnet accompanied examination.

All in all it can be said that. with special regard to expert reports, the design process of a highly complex system with high safety requirements can be accelerated by a methodical procedure which is conaequently carried out. This acceleration is especially due to the better information exchange between the designer and the expert who talk and understand the same language when a design method shall be applied.

1) A Flow contents Data and Events Ix = 011 + E... Ox = Dca + E.. 2) A Task is terminated ... a) ... regular by producing an output (following state: "waiting") b) ... irregular because there exist a higher priority (following state: "ready·)

REFERENCES Frank, W. (1991). Die Zukunft elektronischer Steliwerke. ErR Eisenbahnlechnische Rundschau, Vol. 40, 575 - 584.

3) Control processes and flows are only hints for a further description 4) Every control process leads to a state transition

diagram (parallel description)

Glickel, H., E. Schnieder (1988). International Symposium on research and new technologies in transport and traffic. Betriebsleittechnilc jUr Magnetschnellbahnen. Hamburg

5) A transformation graph describes the data por-

tion of the flows

Petri, C. A. (1962). KommuniJr.alion mit Automaten. Schriften des Institutes fUr Instrumentelle Mathematik, Bonn.

6) A state transition diagram describes the control portion of the flows (event) 7) A task is labeled with its priority (p

= x)

Ward, P. T. and S. 1. Melior (1985). Structured development/or real time systems, Vol. 1- m. Prentice-Hall, Englewood Cliff, New Jersey.

EVALUATION All these considerations include the fact that the comprehension of a task control can only be provided in an adequate manner if the output data flows 0. and 0.,. are concretely named, and if the tasks are described textually for any person (eg. experts, owners) who did not participate in the design process. The guidelines for the specification of the OCS, which were worked out together, are leading to a system documentation which represents the base for the safety proof on the functional level. Due to the early cooperation with the experts the following design processes were very much simplified because the experts did already know the method of Ward and MelIor and were operating with the corresponding tools. Thus specifications of any design stadium could be transmitted to the experts for test purposes via diskettes. Yet it must be admitted that the method of Ward and Mellor does not provide a mathematical base for automatic analysis. Also simulation is only possible with a simple representation, i.e. by marking the data processes (tasks). Dynamic analyses with respect to deadlocks, reachabilities of states

70

-- -- - - I OCS

OCS

-,

OCS

1

1

I station

1

<:

/')

vehicle

T

/

1

1

.~/

radio control

L/ L/ L/

- --

OCS

OCS

OCS /

- - - -ISuper-1 vision

Fig. 1 Maglev train system

vehicle

other ~_OC~S~__~~~protec-~~__~

tion

swit.ch

propulslon supervlsion

Fig . 2 DCS - Control and protection

r -

- 1

I I

I

L -

~ f- - -

r.ady

..J .

-

1-

t erwlnat.-d

- - - -

-

-

r""

- - - - "'-1

[~ "J

-

-

L~

-

- - -

controlla.bj.~

C'o-.put

1 nQ

- -

I

- - - - - - - - - - - - -- - I..., r

actl

1

wa'tlne;;'

I'

Fig. 3 Task states

71

~Data of ___ ~ .......Ou ___tPut 1

1"",,,1<

1

~

Data of

Input 1

- -

-I-~-l

'Task - ·1

Data of Outp. 13

IControll

Data of Outp . 21

l ;'--r

I

;'

Data of Outp . 12

I I

;' ;'

<::;,

~t7

.,.,. ....

.... Data of

Data of Outp. 23

P • 2

Input 2

p

~

Data of Output 3

=3

I

Data of "rOutput 2

Fig. 4 Transformation Graph

Initial ~.t.

ot

~nt

Input 2

~t

ot

OUtput J ~nt

ot

~nt

OUtput 2

ot

~nt

ot

OUtput 1

Input 1

ot

~nt

OUtput 12

~nt

OUtput

~nt

ot

~nt

ot

OUtput 1 J

n

ot

Input I

COMput

COIIlpUt 1 nq

inq Event or

Input 2

Fig. 5 State Transition Diagram

waiting

E,I

Ey:

Task 1

Task 2

Task 1 is computing Task 2 is computing

Task 1

Task 3 is computing

Task 1

Eol2

Eon

Task 2

Task 3

Eml

Eo.n

Em

Eo)

W&!ting Task 1

Task 3

w&!ting w&!ting

Task 2

Block 1 (Inputs)

EoI

Block 2 (Internal Outputs)

Prioties (see block 1): p (Task I) > P (Task 2) > p (Task 3) Fig. 6 Mealy Machine 72

Block 3 (Outputs)

---

ocs

ocs

- - - I ocs

I

1

1

1

st.at.ion

<-

1

/')

vehicle

I

/

1

1

~/

L./ L./

--

-

OCS

radio cont.rol

L./ /

OCS

OCS

- - - --

I

super-, vision

I

Fig. 1 Maglev train system

vehicle

ot.her ~~oc~s~

__~-4~prot.ec-~~~~ tion

swit.ch

'+-____-4~cont.rollE:J~~~

propuls ion superv ision

Fig. 2 OCS - Control and protection

te"lnate d

,..J

L. .

I' - - - - - - - - - - -,;;;>

r - - - r~17

-

I

I

L

- - - - -

.....

r •• dy

L~

'"I

I.." ....,

- - - - J

controlla ble

l

-

- - -

C'o~utlnQ

- - - - - - - 1...

•• lt1OO

by progra-e r

Fig. 3 Task states

73

I ....

f- -

f- -

- -

I -Actl-

&Data of

~...I... I 'OU=;tPUt 1

1

'T'>o"k: 1

Data ofp 1 Input 1 '---,,..........-'~

= ~

- - - ,-R1u -) 'Task - i

Data of OUtp. 12

l -, ,,-

I

,,"

~~

/1S "

Data of OUtp. 13

!controll

Data of OUtp. 21

I I

"

~17

0

I"",,,,,, ,

....

..... Data of Input :2

P

Data of OUtp. 23

=2 I Data

Data of OUtput 3

p '"' )

of 'OUtput :2

Fig. 4 Transformation Graph

_t

{DiU.l

nu.

of

Input l

~t of OUtput 3

Event of OUtput l

Event of Input 1

Event of OUtput 1

Event of OUtput 12

~t of OUtput 13

Event of OUtput 21

~of

InpIt 1

Fig. 5 State Transition Diagram

waiting

Et!

~

Task I

Task 2

Task I is computing Task 2 is computing

Task I

Task 3 is computing

Task I

I;m

Eo!3

Task 2

Task 3

~!

~

Eol

Em

Eo3

waiting Task I

Task 3

W8J.-

ting Task 2

W8J.-

ting Block I (Inputs)

Block 2 (Internal Outputs)

Prioties (see block 1): p (Task I) > P (Task 2) > P (Task 3) Fig. 6 Mealy Machine

74

Block 3 (Outputs)