Test and Development Bench for an In-borne Computing Architecture

(.4~p\lig lll

\'0

11-" .\(

C411111411. Cll l llPlllt'I",

( :41111l1ltll1i, ;lIioll .... ill

11 . 111"\HI1I ;lIi4 HI.

1'. t I i.... . " I: I! It l', I ~ I."~ I

TEST AND DEVELOPMENT BENCH FOR AN IN-BORNE COMPUTING ARCHITECTURE

J.

Bancelin and H . Bo rde nave

I(-\ FI'. I)

Abstract .

The

RATP

investigations,

(Rail)

research

1"//1 '

./lI/n \ ',,11,-. ,. ;)(1/ I 1',11;'. F I"II 11 11 '

Rolling Stock Department set in motion a whole range of

projects

and

experiments

in

1982

aimed

at defining a

computing architecture for future rolling stock . The present article describes the methods and means deployed for evaluating the computing architecture and in- borne local ne tworks for MF 88 and MP 89 rolling stock scheduled for introduction on the RATP Metro System as from 199 1. Keywords. Computing architecture, Reconfiguration , Local networks .

In

198 2 ,

the RATP (Rail) Rolling Stock Depa rt-

safe t y

informati on

(emergency

ment initiated a whole ranqe of investigation s , research projects and experiments coverinq the

closing vehicle

computi ng

distributed computing hardware.

architecture

of

rolling stock . This

operations, cahling

braking ,

door -

etc . . . ) and lim iti ng using series - connecteo

exe rcise is now entering its practical implemen-

High

tation phase, which coincides with th e recent o rder p lace d for MF 88 stock (destination: Line 7bis) and with tenders i nvi t ed for unmanned MP 89 stock ( des tination: Line 11 ). This paper problem :

will

examine

availability

levels

are

secured through

failure toleran ce . Hence the ongoing examinati on of automatic reconfigurations whereby an y function built into a failed computer is automa tically taken over by a sound computer even if performance levels are adversely affected as a

three aspects of the

result.

This

availability consequently implies

rlistribution of the computing system .

I", at lies behind the computing architecture option 7

High

maintainability

through

How

best

to

implement

and

validate this

levels should be achieved

for "first - level

ll

maintenance

architecture ?

requirements (replacement of a failed removable element) with set objectives as regards d iagno-

Development

test

sis

of a test bed for the computing

accuracy .

apparatus

This diagnosis is effected using

integrated

with

fun c tional

equipment.

architecture.

1.

cat e ring

Lastly, cost reductions are achievable thro uqh standardisation of computing hardware, in other words by reducing the number of cards, usinq

What lies behind the computing architecture option

instead cards and components available on the market duly adapted to all ow for rail - specifi c The latest genera tion o f rolling stock (MF 77 and MI 84) has become increasingly sophisti cated , difficult to develop while also o ff ering an unsatisfactory quality- of - service level.

cons traints.

The

four

ob jectives

require

development o f a

g l o bal vision o f the train, which must no lonqer he consinered as the juxtaposition of equipment ite ms studied in isolation and then assembled,

The study objectives are fourfold

but rather as a system nesigned to fulfil clearly- defined functions under optimum condi tions while ensurin g set availability l evels.

reliability improvement , availability levels c ons i s tent with int egra l

To t h is end, adopted :

automation c riteria,

the following criteria have been

maintainability improvement , functional breakdown of the train into main "themes ", by doing away with the traditional

investment and maintenance cost reductions .

physical breakdown , In

order

f or reliability to improve, two condi~ions must first be fu l filled: cabling must be simplified and the number of conne ct ing poi nts reduced. The solution l ies in replacing the different train lines by an in- borne local network

characterisation of the information exchanged between these different "themes" .

This approach fac i litates conception of a standard computer model (hardware and software)

- except for some twenty lines carrying

1.-,

.I-

16

Ibll(c lill alld 11. Bordt'Il;I\t'

f or any t rain function, the l oca l n etwork and the other links. The archi t ecture study consists then of defining the distribution of computers on the train and the distribution of functions within each computer by seeking optimisation

user applications,

regularity of message transfer nistic or probabilistic) ,

(determi-

serv i ce offered to users, of requirements, of reconfigurations, costs.

of the network load, The first two criteria (reliability, durability) lead to favouring the use of existing standards in respect of l ocal network s . This would suggest excluding specific networks wh i ch identify too closely with a manufacturer or equipment assem-

of maintenance .

2. How best to imp l ement and validate this

b l er ,

architecture

added

to

which these II factory " networks

genera lly imply using electronic manufactured by the same firm. In order to test the different computingarchitecture op tions between them, RATP decided to deve l op a range of simulation equipment designed to compare and test different computing architectures for rolling stock.

equipment

As part of this standardisation process , the functions performed by the communication system are consequent ly examined against the backqround

of the ISO's OS I reference mode l s, with these functions being broken down into 7 layer s each

The end purpose of these simulations is to obtain validation of a computing architecture in

performing a specific funct.ion .

order to achieve

In the context of these OSI l ayers , emphasis has been placed essentially on the first two (Physical layers an d Date link). In practice, these two layers are frequently obta ined using

optimisation sing

of the distribution of proces-

operat io ns

relating to the functional

themes

(driving ,

doo rs,

energy ,

safety , etc ... )

dif f erent physical the train) ,

motive assured

computers

power , by the

available on

op timisati on of the geograph ical distribution of these phys i cal computers) .

components by using

Hence

2.1 - Phase 1

Network evaluation mechanism

by

Computers,

virtue

of

their

distribution ,

intercotnrrnlnicate thr ough a "local " communication network .

This network forms the backbone of the train system. Architecture validation therefore starts with evaluations of the communications networks , followed by a choice. These evaluations address the external appearance of the netwo rk, in other

words

from

rea ction

the

with

standpoint respect

of

-

specialist

chips -

the

decision

to

limit

to subscriber behaviour

2. 1.1 - Approach to l oca l-network preselection

therefore

based

on

criteria

tions . Where

the

token rin g is concernen ,

bus) , no network was se lecte d , r easons explained below :

Selecting an industr ial l ocal network is a task that requires several criteria to be taken into consideration :

of communication - system pe rfor-

mance ,

investment (20 years in

this pa rti cu lar instance), sturdiness to cope with an aqqressive environment (ele ctromagnetic interferences, mechanical and temperature constraints) , . speed

of

information

transfer between two

the network

selected is the TORN AD (manufactured by ALSTHOM ) model adopted for the Atlantic TGV. This network, although not strictly in conformity with standard 802.5, was preferred because of its rail techn ology . Lastly ,

the

are more

\,e have selected , in standard 802 . 3 , networks ARLIC (developed by SEMAGROUP , ethernet), FACTOR (manufactured by APTOR , determinist ic ethernet) which offer guarantees of the t ype obtained with tried- and- tested existinq industrial installa-

l ocal networks which could potent ially be train installed, with the defi nitive cho ice among preselected networks being effected dur in g the next phase .

of

that

strategic than strict l y technical .

The aim of the exercise is to pre - select various

durability

examination to

networks whose base layers ( 1 and 2) arguably correspond to international standards IEEE 802 . 3 (C SMA) , IEEE 802 . 4 (token bus), and IEEE 802 . 5 (token ring). This initia l s orting process is

users (network

patterns) .

reliabili ty

much more than

software . However , the problem of hardware durabi lity is much more acute than that of software durability (comp onent obsolescence , higher cost of rep l acement due to the multiplier effect of lar ge series).

with

regard

to

standard 802.4 (token for

severa l

The IEEE 802 . 4 context is essentially linked to the MAP network , the general concept o f which (factory-oriented) is of little relevance

to

a train environment where the

MAP higher-order services ( general level, control r oom) hardly exist or do no exist at all . OUr needs would seem to identify more close l y with concepts o f the Mini - Map , Proway type , etc ••• ). (NOTE : this MAP general concept cou ld nevertheless be va lid for a Metro line. It does not ne cess arily imply using a token bus) • MAP stabilisation in version 3 . 0 is a recent

development, and doub ts exist over the l o n gterm du rabulity of an investment undertaken

IIl-horlll' ( :O IIlPllli l l~ .\rcil i ll'ctllrt'

today.

in stage one: the transfer functions of each functional theme are simulated by means of software functions. It then becomes pcssible to simulate and evaluate several computing architectures for the particular process control being studied .

All industrial references as regards MAP networks are still relatively sparse in terms of tried- and-tested sites. Last l y, various studies undertaken (by INRIA in particular) would suggest ex i stence of a weakness

in

"token"

networks

This phase ends with a choice of architecture (phase 2).

placed in a

highly-perturbed environment. While in no way wishing to get involved in technical arguments here , this finding does add weight to our contention that the validity of such networks must be demonstrated on the basis

To conclude on this point, it can be said that the MAP conceptual approach (and not standard 802.4) could prove highly pertinent in the coming years but is today somewhat premature given

our

specific

in stage two the selected architecture is developed and validated (phase 3).

2.3 - Phase 4

of existing sites.

requirements

in

terms of

durability more particularly.

2.1 . 2 - Final selection

17

A

subsequent

Reference chain

phase

consists

of

replacing

transfer-function simulations by real hardware. We then obtain a reference chain that makes it

possible to develop the actual computing architecture prior to placing of the rolling stock in service , through gradual integration of effective hardware. During the service life of this rolling stock , this same reference chain is used

to study and validate modifications. This phase involves selecting, among the three networks mentioned above (FACTOR , ARLIC, TORNAD) the model that will e ffectively be train instal led. In practive, this selection will be based on the network evaluation process described below (paragraph 3).

3 - Test bed for computing architecture

RATP has commissioned from MATRA TRANSPORT a test bed codenamed TERASA which is designed to facilitate simulation and validation of the inborne computing system throughout its main design phases as defined earlier ,

namely

The selection criteria are those already descri -

bed earlier : Speed

user

of

information

applications.

transfer between two

Application

to

Appli -

Phase Phase 2 Phase 3 Phase 4

Testing and selection of local network Computing architecture selection

Architecture validation Reference ch ain

cation message transfer time.

Reliability viour

of

communication - system

(percentage

of

lost

or

beha -

erroneous

messages) • Sturdiness ronment :

The architecture of this test bed depends necessarily on t hat of the system to be simulated . ~.Je are dea lin g here with a case of

distributed computing . to cope with an aggressive envi-

TERESA consequently ration (fig .1 ) :

has the following configu-

- Electromagnetic interferences, - Sectioning of medium/media, - Failure of connector cards.

train computing resources (actual in - borne equipment) are simulated by some 15 "real time" computers u sing MC 68020 microprocessors. Each computer simulates one or several

Message transfer regularity

functions to be performed aboard the train,

This

is the guarantee offered by the commu -

nication

system

over

delivering the

information within a set time bracket. The approach at the level of low layers can be deterministic (APTOR, TORNAD) or probabilistic (ARLIC). At application level , determi nistic greater account

regularity seems to carry much implementation uncertainty on of the combinational nature of

transfer cases and times through material and software layers. This generally leads to quasi- probabilistic operation which can be quantified thanks to the platform.

2.3 - Phases 2 and 3

Architecture evaluation and selection mechanisms

Once the network selection has been carried out, the architecture validation phase proper is set in motion in two distinct stages :

each

one

of these comput ers is linked into

the local network effectively used phase 1,

this

of the train, which is and not simulated . In

l ocal network can be anyone

among the networks ARLIC , TORNAD) ,

to

be tested (FACTOR,

the whole set of 15 computers is linked to a SUN/UNIX - type work station via an Ethernet/ TCP - IP service network. This station then acts as IIban d-leader " for the whole simulation exercise, and repatriates the measurements carried o ut by each II rea l-time" computer .

Analysis and recording of measurements taken are performed at this work station . Selective search for a particular test or group of tests is performed with a SGBD (Oracle). In practice, Phases 1 to 4 described above are implemented as follows :

.1.

IH

Ildll( "Iill

;tile!

11. H()nkll;II('

Phase 1 (test network) : the operator specifies the traffic to be generated on the network (volume of date for transmission, message type, transmission moment) for each transmitterreceiver pair involved in the simulation. Performance measurements are obtained by notinq the moment of issue of messages from their

transmitter

application,

and

that

of

their

arrival to the receiver application. The communication system transfer time is then deduced.

Phases 2 and 3

(architecture

test) : the func-

tionalities to be assured by software tasks are simulated. Moreover, the physical environment of

the

system

is

also

the object of a computing

simulation (mechanical inertia of train during a

speed measurement phase). Phase 4: equipment

in this phase, the actual train systems are mounted. They dialogue

with environment sirnulations performed during phase 3, via an interface electronic device so as to recreate a complete looped system representing the equipment of a train in service.

Station

XMS 30tO VME

Int eractive

Temps reel

Reseau de pilotage ...------------ Et h e rn e t