A Problem Oriented Approach to Reliable Train Tracking Software

Copyright © IFAC Control Science and Technology (8th Triennial World Congress) Kyoto, Japan, 1981

A PROBLEM ORIENTED APPROACH TO RELIABLE TRAIN TRACKING SOFTWARE K. Fukuoka*, Y. Suzuki* Y. Ueda* and Y. Kawai** *Systems Development L a boratory, H itach i Lt d., Tama-ku, Kawasaki, japan **Mito Works, H itachi Ltd., Katsuta, I baraki, j apan

Abstract. A system of producing train tracking software is presented . The system, called SPRINT , facilitates software maintenance and enhancement by eliminating imperfect requirement specifications and simplifying software structures. SPRINT provides a language to describe requirements for train tracking software . The language consists of only railway terms so that it can be readily understood by anyone . SPRINT draws railway line diagrams from requirements de scribed by t he language . The diagrams are t he same as original ones so that the requirements are easily examined. SPRINT trans forms the requirements into t rain tracking software. Therefore , the software can be updated by only maintaining the requirements. Keywords. Train traffic control system; process control system; software r eliability ; software maintenance ; software engineering.

INTRODUCTION

find what programs should be modified .

The importance of software maintenance has been pointed o ut by many authors [1][2][3] [ 4] . The r e have been two reasons for the difficulty in software maintenance.

This paper presents a system which produces maintainable and reliable programs with structures that correspond to requirements . The system is Called SPRINT (Software Producti on System for Int eg rated Train Traffic Control). It can be applied to train traffic control systems [7][8].

The first reason has been the imperfection of software requirement specifications . Several technologies for requirement speci fications have been developed in order to make sof t ware requirements less ambiguous and more understandable. SADT [ 5] and SREM [ 6 ] are examples of such technologies . These technologies have permitted system designers to specify their requirements completely and consistently. However, these technologies do not provide how to transform their requirements into programs, and do not force designers to minimize the semantic gap between requirements and programs .

BACKGROUND OF TRAIN TRACKING SOFTI-lAKE. Train traffic control systems perform several jobs, such as the control of train routes, the optimization of train traffic schedules, and the display of train traffic information . All these jobs always require train position data . The data are produced by train tracking programs . Features of the train tracking programs are shown in Fig . 1. The programs receive in formation on the present states of railway equipment from railroad hardware periodical ly and trace train positions in accordance with tracking rules.

The second rea son ha s been sop hi stica ted software structures. Most designers have tried to implement application programs with high performance . However , they have not tried to make program struc t ures cor respond to requirements . Therefore, it is difficult to perceive requirements from the programs . Thus , when designers want to update the requirements , it is not easy to

Tracking rules for train tracking programs are determined by railway line diagrams . In previous systems, rules were made by hand It took a long time to modify or maintain

240 1

K. Fukuoka et a l .

2402

rules even by high-grade engineers because they were very complicated. Therefore, simplification of tracking rules was con sidered important.

TRAIN TRACKING MODEL Properties of Railway Equipment Railway equipment includes signals, trackcircuits, and railway switches. Their relations are usually expressed in railway line diagrams. Tracking rules for train tracking programs are made from the equipment relations in railwa y line diagrams. In previous systems tracking rules included relations among signals, track-circuits and railway switches. However, we found out that the rules could b e represented by only the relations between signals and track-circuits, excluding railwa y switches. In order to clarify the relations between signals and track-circuits, explanat i ons of their properties are required. (1) Track Circuits Railway lines form a complicated network. Th ey are electorically divided into many segments which are utilized for detecting train positions. Each segment is called a "track-circuit". Features of track-circuits a re a s follows: (a) A track-circuit state becomes "1" if a train exists o n the track-circuit and "0" if not. (b) If a train crosses on the boundary of two adjacent track-circuits, both trackc ircuit states become "1". (c) Two or more trains can not exist on the same track-circuit at the same time. (d) Trains can not enter a track-circuit bef o re a constant time elapses after another train leaves the track-circuit. That is, it is possible to detect all transitions of tr ac k-circuit states generated by movements o f trains. (2) Signals Si gnals dir ec t train dri v ers to go or stop b y their col o urs. Signals a re placed on the bo undaries o f two adjacent track-circuits. However, all boundaries do not have signals. Fe atures of signals are as follows : (a) A signal state becomes "green" if the s ignal direc t s to go and "red" if to stop. (b) Signal states are controlled by opera When a train passes the t o rs o r computers. bo undary on which a signal exists, the signal state unconditionally turns "red". Re l a tions Between Railway Equipment and Route

Each signal indicates the route along which trains should go. An example of a route is shown in Fig. 2. A route is composed of a sequence of track-circuits. The first track-circuit of a route is called the source of the r o ute, and the last one is called the destination. So long as a signal is "red", a train on the source of the route will not go forward . If a signal is "green", the train may proceed to the destination of the route. Once a train has entered the seco nd track-circuit of a route, the train has to go to the destination of the route. Routes link together, that is, the destination of any route is the source of other routes. Trains run on a railway line network by selecting routes one after another .

TRAIN TRACKING STRATEGIES Expressing Train Positions In previous systems, the rules to express train positions were complicated, so it was very difficult for designers to describe them. We propose a simple rule to describe them from railwa y line diagrams easily. A track-circuit state indicates whether a train exists on it or not. It is natural that the present position of a train should be represented by the track-circuit on which it exists. The track-circuit on which a train exists is one of the track-circuits which a route is composed of. The train proceeds to the destination of the route. So, the present position of a train should be represented by the route along which the train goes. Thus, our rule represents the present position of a train by . the route along which the train goes and the track-circuit on which it exists. Tracking Train Positions (1) Train Positions Represented by Trackcircuit In the case that a train is going to move from a track-circuit to the adjacent one, it is explained with Fig. 3 how to trace train positions represented by track - circuit. It is supposed in this figure that the tr a in moves from right to left. At time T , train P exists on track - circuit l X. At time T2, it has just entered trackcircuit Y and the state of track-circuit Y has turned "1". At time T3, it has just left track-circuit X and the state of trackcircuit X has turned "0". If the above sequence was detected, the train position of train P represented by track-circuit is changed from track-circuit X to track-circuit Y. In this tracking

Approach to Reliable Train Tracking Software sequence, only track-circuit states are used but not railway switch states. (2) Train Positions Represented by Route It was supposed in the above explanation that the train moved from left right. However, if the track-circuit states have been changing as Fig. 4a, it is impossible to judge which cases in Fig. 4b happened. These cases often take place in railway systems. It is necessary to detect the directions in which trains run. A train runs in the direction indicated by a route along which it goes. An example of a train movement from one route to another is shown in Fig. 5. Track-circuit X is not only the destination of route A but also the source of route B. The sequence of track-circuit states in Fig. 5 is the same as in Fig. 3. At time Tl' the state of signal S is "green" and directs train P on track-circuit X to go along route B. At time T2, the state of signal S changes from "green" to "red". The train position of train P represented by route is changed from route A to route B when the state of track-circuit X has just turned "0" after the state of signal S turned "r ed" . In the above tracking sequence, railway switch states are not used either. Possibility of Mistracking Train tracking programs do not always receive correct states of signals and track-circuits. Error data often let the programs mistrack trains. There are two cases of mistracking. One is the deficient shifting. A train position has not been changed in the computer though the train has already moved to the next place in the real process. The other is the excessive shifting. A train position has changed to the next place in the computer though the train has not yet moved in the real proce ss. Mistrackings might make trains go to the wrong directions. In order to trace the train position of train P represented by route in Fig. 5, the states of signal Sand track-circuit X are needed and the state of track-circuit Y is available. Probabilities of mistrackings are given as follows. / Definitions of symbols / e: solid error rate; The state of a signal or a track-circuit has permanently been holding the same value . t: transient error rate; The state of a signal or a track-circuit temporarily changes to the incorrect value . (1) Case 1: Use s the sta te s of signal Sand track-circuit X.

2403

(a) Probability of deficient shifting:[solid error rate of signal S] OR [solid error rate of track-circuit X] = e+e = 2e. (b) Probability of excessive shifting:[transient error rate of signal S] = t. (2) case 2: Uses the states of signal S, track-circuit x and track-circuit Y. (a) Probability of deficient shifting:[solid error rate of signal S] OR [solid error rate of track-circuit X] OR [solid error rate of track-circuit Y, but not counted in case that whose state holds "1".] = e+e+e/2 = 2.5e. (b) Probability of excessive shifting:[transient error of signal S] AND [time rate (=k) while the state of track-circuit Y is "1"] = kt (O
PRODUCTION AND MAINTENANCE OF TRAIN TRACKING SOFTWARE SPRINT has several features to improve the maintainability of train tracking software (Fig. 6). These features are as follows. (a) It provides a language to specify requirements of train tracking software. (b) It tests the validity of requirements. (c) It produces tracking rules for train tracking programs. A Requirement Specification Language SPRINT provides a format to specify signals which indicate routes and sequences of track-circuits which the routes are composed of . Many actual routes are specified by the format in Fig. 7. Signal names are described on the first column of the format, and track-circuit names are described on and after the second column . A line of the format implies [The route of signal ( ) starts from track-circuit ( ), passes through track-circuits ( ), . •• ,( ) and terminates at track-circuit ( ).]. The language has the following effects. (a) System designers are able to describe their train tracking requirements using only railway terms. They need not worry about programs. (b) System designers are able to describe their requirements correctly and unambiguously. (c) Anyone can understand the requirements easily. Validity Checking of Requirements SPRINT detects careless mistakes and tests

K. Fukuoka e t al .

2404

the consist ency of requirements described in t he language. Route slink toget her, that is, the destination (the source) of a route is the source (the d es tination) of other routes. By using the relations between sou r ces and destinations, SPRINT detects sources at which no route t ermi nates and destinations from which no rout e starts . SPRINT not only executes the syn tacti c testing of r outes but also supports seman tic testing b y system des igners. SPRINT can draw railwa y line diagrams from requirements. An example of a railway line dia gram drawn b y SPRINT is shown in Fig. 8. This diagram is the same as the original railway line diagram. Designers will be able to check whether or not their r oute specifications were described and interpreted correc tl y, by comparing the SPRINT diagrams and the original ones . Production and Maintenance of Tracking Rules SPRINT transforms requirements into trackin g rules for train tra cking programs . Sys tem designers will be able to update and repair the tracking rules by only maintaining their requirements. CONCLUS IONS This paper has described SPRINT, a system which makes train tracking softwa re maintainable and reliable. It provides a r e quirement specificati on language, t ests the va lidit y of r eq uirements and produces tracking rules f o r train tracking programs. ACKNOWLEDGEMENT The authors would like to thank Dr. Takeo Miura and Dr. Sadamichi Mitsumori of Hitachi, Ltd. for their guidance and enco uragement in this work. REFERENCES [1) Swanson , E. B., "The Dimensions of Maintenance", Proc. 2nd Int. Conf. Software Eng., pp .492-497, Oct. 1976. [2) Boehm, B. H., "So ftware Engineering", IEEE Trans. Comput., pp. 1226-1241, Dec. 1976. [3) Lientz, B. P., Swanson, E. B., and Tompkins, G. E., "Characteristics of Application Software Maintenance", Communications of the ACM, pp. 466 - 471 , June 1978. [4) Gunderman R. E., "A Glimpse into Program Maintenance", Datamati on, pp . 99-101, June 1973. [5) Ross, D. T., "Stru c tured Analysis (SA): A Language for communicating Ideas", IEEE Trans. Software Eng., pp. 16-34,

Jan. 1977. [6) Alford, M. W., "A Requirements Engineering Methodology for Real-Time Processing Requirement s", IEEE Trans. Software ~, pp. 60-69, Jan. 1977 [7) Ozeki, M., Naganuma, S., and Inada, N., "Railway Traffic Control System", Information Processing 74, pp. 802-806, 1974. [8) Ihara, H., Fukuoka, K., Kubo, Y., a nd Yokota, S., "Fault -Tolerant Computer System with Three Symmetric Computers", Proceedings of the IEEE, pp. 1160-1177, Oct. 1978.

App r oach t o Re li abl e Train Tr acking Softwa r e

Railroad hardware

\VI Present railway

states of equipment

Train tracking programs

~----~

~

.fI Present train positions

Tracking rules

----~

rain traffic ontrol syste

Fig. 1

Features of train tracking programs

r

Trackcircuits

Source

2405

x

y

Z

U

1

0

1

0

1

1

1

1

0

1

0

1

x

z

(a) Transitions of track-circuit states

o o

Case 1

~->

Case 2

c::===>

o o

(b) Train movements

Destination

L.....-_ _ _ _ _

>

Fig.

~

An example in which two different

train movements bring about the same transitions of track-circuit states

Route S indicated by signal 5

Fig. 2

x

Fig. 3

Relations between railway equipment and route

y

x

y

x

y

5

1

0

1

0

green

1

1

1

1

red

0

1

0

1

red

Transitions of track-circuit states caused by a train movement

Fig. 5

A train movement from one route to another

2406

K. Fuku oka et aL .

Original railway line diagram

Designers

;.

Describe in a language given by SPRINT

Requirements for train tracking software

{ChOCkOd by designers

Railway line diagram drawn by SPRINT

<

SPRINT

r-________________

--,~PRINT

Tracking rules for train tracking programs

Fig. 6

Features of SPRINT

1280 lIEO 6140 6150 6160 16AO 15AO HAD 04AO 05AO 06AO 2RAO 2RFO JR10 3R20 3R30 3RUO 6R80 5R80 5REO 4R80 4REO 3R40 31150 3R60 1480 14E0 1580 15E0 1680 311 0 3UO 3130 3820 3850 3920

UHO UHO 1HO 12TO 1HO 1360 1350 1340 JR30 JR20 3R10 D1TO D1TO 51AO 51A0 51A0 51A0 3R10 3R20 3R20 3R30 3R30 5180 5180 5180 1340 1340 1350 1350 1360 1020 1020 1020 S1TO S1TO S2TO

Fig. 7

68TO 68T0 66TO 66TO 66TO 57T0 57TO 56TO 55TO 58TO 58TO 51AO 5lAO 5280 52BO 5280 52BO 1030 60TO 60TO 59TO 59 TO 52AO 52AO 5lAO 62TO 62TO 61TO 61TO 3310 65TO 65TO 65TO 6410 64TO 63TO

1HO 67T0 61T0 61T0 33TO 52AO 52AO 52AO 56TO 5280 5280

1020 6HO 1350 1360 5180 5180 5180 52AO 52AO 52AO

5180 58TO 58TO 55TO 5510 65TO 65TO 59TO 60TO 6410 56TO 57T0 57TO 61TO 6310 66TO 62TO 66TO 1030 60TO 60TO 59TO 63TO 6410

JR10 H2O JR30 56TO 1020 1020 6410 65TO S1TO 1340 1350 1360 66TO SHO 12TO 6310 1210 3R10 31120 59TO 60TO 62TO 59TO

1340 U1TN U1TN U1TN 5180 U1TN 5180 UHN 5180 U1TN

1340 67T0 DHP 67T0 DHP S1TO 1020 67TO OHP

12TO 68TO 67T0 OHP 68T0 67TO DHP SHO 68TO 67T0 OHP 3R30 3R20 61T0 1350 60TO 3R20

examples of route specifications

DITO

OITP

U1TN

UlTO

I - --+-~'-t-+--+---'-'--'L----'-+-----+-r--rl-L---'--+----i

16AO

Fig. 8

A railway line diagram drawn by SPRINT