PD CLC TR 50501-1

PUBLISHED DOCUMENT PD CLC/TR
50501-1:2007
Railway applications —
Rolling stock —
SUPPLIED BY BSB Edge Pvt. Ltd. UNDER THE LICENSE FROM BSI FOR RITES LTD. - GURGAON ON 19-02-2018 12:45:02 (103.7.128.130)
Intercommunication
between vehicles and
train/wayside —
Part 1: Data dictionary and rules for
functional standardisation
ICS 35.240.60; 45.020; 45.060.10
12&23<,1*:,7+287%6,3(50,66,21(;&(37$63(50,77('%<&23<5,*+7/$:
PD CLC/TR 50501-1:2007
National foreword
This Published Document was published by BSI. It is the UK implementation

of CLC/TR 50501-1:2007.
The UK participation in its preparation was entrusted by Technical Committee
GEL/9, Railway electrotechnical applications, to Subcommittee GEL/9/2,
Rolling stock.
A list of organizations represented on this committee can be obtained on
request to its secretary.
This publication does not purport to include all the necessary provisions of a
contract. Users are responsible for its correct application.
This Published Document was Amendments issued since publication

published under the authority
of the Standards Policy and
Strategy Committee Amd. No. Date Comments
on 29 June 2007
© BSI 2007
ISBN 978 0 580 52930 6

TECHNICAL REPORT CLC/TR 50501-1
RAPPORT TECHNIQUE
TECHNISCHER BERICHT May 2007
ICS 35.240.60; 45.020
English version
Railway applications –
Rolling stock –
Intercommunication between vehicles and train/wayside –
Part 1: Data dictionary and rules for functional standardisation
Applications ferroviaires – Bahnanwendungen –

Matériel roulant – Bahnfahrzeuge –
Communications entre véhicules Datenaustausch zwischen Fahrzeugen
et communications sol/train – bzw. Zug/Strecke –
Partie 1: Dictionnaire de données Teil 1: Datenkatalog und Regeln
et règles pour la standardisation für die funktionale Standardisierung
fonctionnelle
This Technical Report was approved by CENELEC on 2007-01-01.
CENELEC members are the national electrotechnical committees of Austria, Belgium, Bulgaria, Cyprus, the
Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia,
Lithuania, Luxembourg, Malta, the Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain,
Sweden, Switzerland and the United Kingdom.
CENELEC
European Committee for Electrotechnical Standardization
Comité Européen de Normalisation Electrotechnique
Europäisches Komitee für Elektrotechnische Normung
Central Secretariat: rue de Stassart 35, B - 1050 Brussels
© 2007 CENELEC - All rights of exploitation in any form and by any means reserved worldwide for CENELEC members.
Ref. No. CLC/TR 50501-1:2007 E

CLC/TR 50501-1:2007 –2–
Foreword
This Technical Report was prepared by SC 9XB, Electromechanical material on board rolling stock, of
Technical Committee CENELEC TC 9X, Electrical and electronic applications for railways.
The text of the draft was submitted to vote and was approved by CENELEC as CLC/TR 50501-1 on
2007-01-01.
__________
–3– CLC/TR 50501-1:2007
Contents
Page
Introduction ........................................................................................................................................ 4
1 Scope ........................................................................................................................................ 7
2 Normative references............................................................................................................... 7
3 Terms and definitions .............................................................................................................. 7
4 Reference architecture........................................................................................................... 10
4.1 Introduction ....................................................................................................................... 10
4.2 Reference Architecture concept ........................................................................................ 10
4.3 Requirement for the STD1 Reference Architecture definition ............................................ 11
4.4 Interacting objects............................................................................................................. 12
4.5 Functional Architecture ..................................................................................................... 20
5 Methods for functional modelling ......................................................................................... 24
5.3 Process of function class decomposition........................................................................... 30
5.4 Modelling accessibility of entities and functions: the pattern view...................................... 30
5.5 General modelling rules .................................................................................................... 31
5.6 Metric Evaluation Criteria .................................................................................................. 33
5.7 Testing.............................................................................................................................. 33
5.8 XML usage........................................................................................................................ 33
5.9 Deliverables ...................................................................................................................... 38
6 The Data Dictionary................................................................................................................ 39
6.1 Introduction ....................................................................................................................... 39
6.2 Structure ........................................................................................................................... 39
6.3 Requirements for management of the Data Dictionary/model repository ........................... 40
Annex A (informative) Related works ............................................................................................... 41
Annex B (informative) Functional addressing in railway specifications ........................................ 44
Annex C (informative) Process of function class decomposition .................................................. 46
Bibliography ..................................................................................................................................... 47
Figure 1 – Reference Architecture: Relation cases in the functional communication architecture ....... 17
Figure 2 – General model structure – Example................................................................................... 25
Figure 3 – UML Use case diagram – Example.................................................................................... 26
Figure 4 – UML Component diagram – Example ................................................................................ 27
Figure 5 – UML Class diagram – Example ......................................................................................... 28
Figure 6 – UML Statechart diagram – Example .................................................................................. 29
Figure 7 – UML Sequence diagram – Example .................................................................................. 30
CLC/TR 50501-1:2007 –4–
Introduction
Survey Group SC9XB/SGB1 conclusions
From the conclusion of the works of Survey Group SC 9XB/SGB1, in document CLC/SC9XB(Sec)174
(Bibliography [9]), a series of standards is to be prepared, with the following guiding principles:
• the overall objective is to develop standards for data exchange involving railway vehicle consists,
between themselves or with fixed installations;
• standardisation is focussed to what is necessary for implementing interoperability as defined in
Directive 2001/16/EC (on the interoperability of the Trans-European conventional railway system),
and as will be specified by the bodies in charge of drafting Technical Specifications for Interoperability
(TSI);
• the scope of the work is then limited to international Passenger trains and freight trains in The Trans-
European conventional rail system, excluding the signalling and control-command subsystem. This
does not explicitly exclude High Speed Trains (HST), but excludes formally trams, metros and urban
or suburban trains.
Separate functional standards will be established for freight and Passenger trains. Requirements for
interoperability, including those specified in a set of Technical Specifications for Interoperability (TSI), are
different for these two categories of rolling stock.
The series of standards has been structured as follows, with four categories:
- STD1: data dictionary and rules for functional standardisation;
- STD 2: functions in freight traffic (for a selected set of functions);
- STD 3: functions in passenger traffic (for a selected set of functions);
- STD 4: standardisation of communications procedures.
This document is the first part, in category STD1, of the series of functional standards, aiming to define a
common modelling framework, to be used for the development of the subsequent standards: common
methods and rules, a unique Reference Architecture, and common Data Dictionary.
The Trans-European conventional rail system
Trans-European conventional rail system shall be considered as defined in Article 2 of the Council
Directive 2001/16/EC on the interoperability of the Trans-European conventional railway system:
For the purposes of this Directive: "Trans-European conventional rail system" means the structure, as
described in Annex I, composed of lines and fixed installations, of the Trans-European transport network,
built or upgraded for conventional rail transport and combined rail transport, plus the rolling stock
designed to travel on that infrastructure.
The Trans-European rail system is broken down into subsystems, as described in Annex II of the
Directive:
a) structural area
- infrastructure, in particular access / egress points that define the boarders of an infrastructure
managed by a given organisation, and also shunting, freight terminals and stations,
- energy, electrification system…,
- control and command and signalling, to command and control train movement,
- traffic operation and management, including train driving, traffic planning and management,
–5– CLC/TR 50501-1:2007
- rolling stock, including all train equipment and man-machine interfaces for driver, on-board staff
and passengers.
b) operational area
- maintenance, including logistics centres for maintenance work and reserves for corrective and
preventive maintenance,
- telematics applications: freight services and passenger services (including passenger information,
reservation and payment, luggage management, connections between trains and other modes of
transport).
Examples of functions to be standardised

NOTE In the following informal function descriptions, interface ”type B” (“train level to consist level”, named also “train to consist”
for short), and interface ”type C” (train to ground) are used (see Figure 1 in 4.4.2).
1) Dynamic passenger information system. Refer to [14], a contribution of TrainCom European

Research Project (ref: IST-1999-20096), proposing a detailed XML specification of messages that are
exchanged between vehicles and with the ground. This specification covers all characteristic features of
the rail environment, including its dynamic aspects.
2) Maintenance: Euromain European Research Project (ref: IST-2001-34019) proposes detailed XML
specifications for data, and including the definition of functions for real time monitoring, data collection
and statistics.
3) Passenger emergency brake: The Technical Specification for Interoperability (TSI) relating to the
rolling stock subsystem (High Speed)) gives requirements for this function. This is a train level function. If
the train is formed by several coupled consists, an interface “train to consist” (type B) is involved. A
communication with the ground is also possible: interface “train to ground” (type C).
4) “Stabled ready for use”: This is a train level function, ensuring that a train composition is ready for
service when required. If the train is formed by several coupled consists, an interface “train to consist”,
(type B) is involved. A communication with the ground is also possible for triggering train preparation:
“ground to train” interface (type C).
5) Control of passenger lighting: Control of lighting from the driver cab, for two consists coupled
together. There are in addition some local controls in each coach.
Level of services for the lighting system may be different for the two consists
- version 1, with two levels of lighting: full, reduced,
- version 2, with three levels of lighting: full, reduced, and night.
The issue raised by this example is one problem of interoperability among a set of heterogeneous
consists.
EXAMPLE
When the driver is in the consist which is fitted with version 1, how to specify the interface between
consists, in order to have an acceptable behaviour in the other consist fitted with version 2.
Two alternative solutions are

- each consist should be able to interpret in its own way every possible command issued by another
leading consist. For instance, a consist fitted with version 1 will set “reduced level” when receiving a
“night level” command,
- the driver could control each consist after having “imported” on the cab MMI the specific control
interface of the given consist.
CLC/TR 50501-1:2007 –6–
6) Train integrity (completeness of train)

Some possible solutions to check the completeness of the train may use
- connector at the end of the train,
- with GPS + EGNOS, precision < 2,5 m possible,
- GPS with integrated inertial system.
The positions at the train extremities are measured, and compared to the train length obtained by
summing all vehicles lengths, obtained for configuration data stored in the UIC gateways. Safety integrity
requirement SIL 4 is needed for ERTMS level 3 for train integrity function.
7) Establishing and distributing time and date

A train level function. If there are several consists, clocks have to be synchronised train wide. A problem
to solve is how to take into account variable network propagation delay for synchronisation messages. An
another issue is standardisation of reference time source, and synchronisation protocols.
8) Establishing and distributing speed

A train level function. Speed data has to be time-stamped. If there are several consists, clocks have to be
synchronised train wide (by function distributing time and date). A problem to solve is how to take into
account variable network propagation delay.
The precise requirements on this function depends of the various consumers of the speed information,
requesting various quality of service.
–7– CLC/TR 50501-1:2007
1 Scope
This Technical Report will define
- requirements for the methods to be used for functional standardisation, in the standards to be
prepared for data exchange involving railway vehicles, in two contexts
1) inter-consists communication, within a train formation,
2) communication with ground based installations.
- the Reference Architecture defining the essential functional interfaces,
- the concept of a central Data Dictionary/repository to be applied to freight and passenger traffic
functions. In this context, data are to be limited to basic information elements, which are necessary
to define standard messages required for interoperability, and displayed on the interfaces of the
communicating entities. Entering Data Dictionary will provide full definition of a data element, along
with its essential attributes at conceptual level.
The purpose, in the perspective of the standards to be prepared, is to document the data element
pertinent to the functional area and essential for interoperability, to allow the reuse of data element
among functional area systems, and facilitate data interchange among the systems.
NOTE Data Dictionary shall be designed to provide a structural framework that enables continued growth and enhancement of the
scope of defined data. Rationale for this requirement is that it is difficult, when defining the scope of a proposed system to fully
define the application domain and all included interoperability related data. In addition over time, functional requirements will
expand.
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
Object Management Group Inc. (http://www.omg.org) , July 2004, Unified Modelling Language
Specification - version 1.4.2 (OMG reference formal/04-07-02), identical to ISO/IEC 19501:2005(E).
Extensible Markup Language (XML) 1.0 (Third Edition) W3C Recommendation, 4th February 2004,
François Yergeau, Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler.
3 Terms and definitions
For the purposes of this Technical Report, the following terms and definitions apply.
3.1
abstraction
similar as view. When using the word abstraction we put into evidence that such view ignores some
details that are considered not relevant for its purposes, even if these details are still relevant for the
model
3.2
actor [class] (UML)
coherent set of roles that users of use cases play when interacting with these use cases. An actor has
one role for each use case with which it communicates
CLC/TR 50501-1:2007 –8–
3.3
attribute
named property of a class that describes a range of values that instances of that class might hold. The
perceived aspect or representation of a property. Attributes may be valued.Attributes are further
categorised as intrinsic attributes that are inherent to an entity, and extrinsic attributes that are of a
relational nature
3.4
class
collection of objects having the same attributes. A class is a named description of a set of objects that
share the same attributes, operations, relationships, and semantics. These objects can represent real-
world things or conceptual things
3.5
consist
assembly of vehicles (may be reduced to a single vehicle), which are permanently coupled while in
service, and fitted with a “vehicle communication system”, linking the devices, and providing one interface
with the train level (such a communication system may be a vehicle bus, spanning over all the vehicle of
the consist). A physical consist which is not capable of data communication with other consist or ground
installation is not in the scope of the Reference Architecture. A consist is described by a set of static
properties (as in UIC Leaflet 556 [8])
3.6
entity
anything of interest (such as a person, material object, place or process) within a given domain of
discourse. An entity class is a stereotyped class used to model long-lived information that may be
persistent. An entity is said complex when it can be described by at least two other entities. Otherwise, it
is called a simple entity or primitive
3.7
event
noteworthy occurrence that has a location in time and space. Within a state machine, the occurrence of
an event can trigger a transition. An internal event passes between objects in the system; an external
event passes between the system and an actor. An event may trigger a change in the state of an object
3.8
functional requirement
action that the new system must be able to perform
3.9
functional view
set of functions and operations that provide a system's functionality
3.10
functional specification
specification of functions performed by the entities in a given application, in a manner that is independent
of the technology adopted to implement the specified functions
3.11
method
ell-organised way of working based on a defined set of rules, practices, and procedures. A different
definition is used in UML, where a method is an implementation of an operation
3.12
model
representation of relevant aspects of a subject of interest within a given domain of discourse. The term
model is a keyword that refers to a semantically complete abstraction of a system. It represents a
simplification of the reality of that system.
–9– CLC/TR 50501-1:2007
Reasons to build models include the following:

- to communicate the desired structure and behaviour of a system;
- to visualize and control the system's architecture;
- to better understand the system and explore opportunities for simplification and reuse
3.13
object
representation of an entity for the purpose of building a model. An object is an instance of a class that
encapsulates state and behaviour
3.14
OMG (Object Management Group)
open membership, not-for-profit consortium that produces and maintains computer industry specifications
(such as UML) for interoperable enterprise applications
3.15
package
general purpose mechanism for organising elements into groups. Packages may be nested within others
packages (UML)
3.16
property
intrinsic characteristic or feature of an entity. In UML, the term property refers to a named value that
conveys information about a model element. Within the UML, attributes, tagged values, and associations
are all properties
3.17
responsibility
refers to a stereotyped comment that states a contract or obligation associated with a model element
(generally a class)
3.18
state
for a given instance, a combination of attribute’s values at a given instant of time
3.19
STD2
acronym used in this document for a series of standards dealing with Passenger train functions
3.20
STD3
acronym used in this document for a series of standards dealing with freight train functions
3.21
stereotype (mechanism)
extensibility mechanism that allows to create new kinds of model elements that are derived from existing
ones. These new elements have their own special properties (expressed as tagged values), semantics,
and notation
3.22
TCMS
train control and monitoring system
CLC/TR 50501-1:2007 – 10 –
3.23
train
assembly of coupled consists (may be reduced to a single consist), configured for autonomous operation
on the railway system. and in use for an operational mission; the train is a dynamic object, identified with
a “train running number”, existing only during its operational mission
3.24
trainset
consist (formed with more than one permanently coupled vehicles) which is capable of autonomous
operation, when configured as a train (TSI)
NOTE This definition is not the same that the one given in UIC leaflet 556, Bibliography [8].
3.25
UML (Unified Modeling Language)
standardized modeling language defined by the OMG for expressing system and software requirements,
specifications as well as architectures
3.26
XML
Extensible Markup Language, modification of the SGML standard (see Bibliography [3]). In contrast to
SGML documents XML documents may exist without having their schema described in a DTD
4 Reference Architecture
4.1 Introduction
Functional standardisation activities are producing standards for a given functional area, which are
supported by functional models. Functions which are in the scope of this series of standards are, by
definition, supported by distributed applications.
A model is a representation of the function, structure and/or behaviour of a system in a systematic way,
and showing only items relevant to the function of interest.
The development of a system architecture starts with the identification of key user needs that must be
addressed by the system and that will be rigorously traced across the different views provided by the
model.
The elaboration of functional model for a specific function of the railway system, belonging to categories
STD2 and STD3 defined in the introduction, shall use the “STD1 Reference Architecture”, as defined
below, as a starting point.
4.2 Reference Architecture concept
The object of this clause is to describe a specific view of the rail transport system, with a “Reference
Architecture”, containing only the major structuring elements that condition the functional approach from
the point of view of
- the rail business,

- the communication system,
- and the definition of data elements.
The use of this Reference Architecture substantiates all functional standardisation covered by the series
of standards addressed in the introduction of this document. The scope of the standardisation is restricted
to functions using the two categories of communications impacting vehicle interoperability:
communications between consists composing a train, and communications between a train and ground
based installations. A main objective is to identify the essential functional interfaces.
– 11 – CLC/TR 50501-1:2007
An architecture is a structured way of describing a system with a view to ensure interoperability between
its components. The availability of several different middleware technologies for the components creates
the need to tackle the problem of application interoperability at a higher level, namely that of models.
Simply stated, the vision is that a change of the middleware platform should not affect the application.
The model of the application should remain unchanged.
Two levels of architecture definitions are commonly used:
1) functional architecture, expressed by a model of the relationship between “functions” and
“information” processed in them;
2) physical architecture, which clarify the location of Subsystems and information exchanged among
them.
Whilst allowing for many different specific designs or implementations, the architecture groups a number
of common views that allow identifying and describing the necessary commonalities for interoperability
across these implementations.
4.3 Requirement for the STD1 Reference Architecture definition
The concept of “Reference Architecture”, which can be thought as the most representative architecture in
a certain domain, is used in a number of methodologies to allow a uniform modelling of systems in that
particular domain.
For this report, the domain of discourse includes entities which are providing the services implementing
the functions, involving railway vehicles, to be standardised.
The abstraction provided by this Reference Architecture should allow to easily comprehend the overall
railway system structure, its comprising elements and their interconnections. This enables reaching a
common understanding, and the ability to make decisions about the various systems aspects and
properties which should be standardised, in order to reach the stated interoperability objectives.
For those purposes, the following requirements are:
1) the Reference Architecture shall provide a common framework, upon which diverse functional
specifications can be performed by different expert teams. This includes the establishment of a Data
Dictionary, seen as a common reference repository, which shall be used in the process of production
of standard functional models;
2) functional models shall be independent of the technology adopted to implement the specified
functions. This is required to achieve independence between functional specifications and internal
structure of vehicle;
3) the Functional Architecture shall take into account one of the most challenging characteristics of
trains: its dynamics. The dynamics in operation are also in the functional model and in the
communication networks. Different types of dynamics have to be addressed:
- consists changes;
- trains start/end their run;
- coupling/decoupling;
- devices are added/removed e.g. during power up/down;
- functional changes;
- spare train takes over;
- change of used/unused driver’s cab;
- redundant device takes over;
CLC/TR 50501-1:2007 – 12 –
4) rolling stock operating states/modes shall be distinguished for functional models, as many functional
interfaces are specific to each mode. Main modes to be considered are “operational”, “maintenance
diagnostics” and “configuration”. Allowing automatic configuration of dynamic systems formed by
interacting rolling stock objects is one of the main benefits expected from standardisation by the
users. Examples taken from the railway field are the “train inauguration” concept in UIC leaflet 556
(Bibliography [8] and the mechanism of registration of functional addresses in GSM-R networks
(Bibliography [12], [13]).
From the above major requirements, the following desirable properties have been derived:
1) it should be possible to describe a system as a composition of independent components and

connections. Composition capabilities allow independent architectural elements to be combined into
larger systems (ex: coupling of two trainsets in order to prepare a train.). It should be possible to
describe the components and their interactions in the architecture in a way that clearly prescribes
their abstract roles in a system;
2) a functional addressing scheme should be provided, which permits entities to be identified by a
“name”, used as a “functional address”, representative of their functional roles rather than by
“numbers” tied to the interface equipment they are using;
3) use of functional addressing will include identifying on-train functions and other users performing
particular roles such as train driver, passenger, train conductor, etc.;
4) communications protocols not belonging to the “application levels”, which are using functional
addresses, but necessary for the implementation of communications systems, should be specified
(independently of the various functional models) in STD4, as these communication systems are to be
shared by several user functions. These protocols should be existing open industry standards.
4.4 Interacting objects
The classes, as described below, define the highest abstraction level of the Reference Architecture. They
form a complete set of classes, reflecting organisations, functions and logical or physical objects, deemed
necessary and sufficient to perform functional modelling of intercommunication between vehicles and
between train and wayside.
Each class is an abstraction representing a collection of objects having the same properties. An “object”
is a representation of an entity, for the purpose of building a model.
4.4.1 Rolling stock entities
Interacting objects belonging to “rolling stock” are defined in the model by the classes to which they
belong. Represent moveable material resources used by Railway Undertaking (or operators) to
implement transportation services.
Three different categories of classes are distinguished:
Category 1: Classes corresponding to rolling stock structural subsystems
- train,
- consist,
- vehicle.
Category 2: Classes corresponding to devices measuring properties at train level
- time and date reference,

- reference location determination of the train,
- reference speed of the train.
– 13 – CLC/TR 50501-1:2007
These particular “on board devices” classes which are defined in the Reference Architecture are then
considered to be outside of the consist model (even if they are physically located inside a consist),
because the measured properties are considered in the model as attributes for the class “train”.
NOTE The rationale for choosing this option (train level devices considered as being external to the consist) is to exhibit, in the
models, the interface between these train level devices and the train level functions. This ensure that the different train level
functions will use the same reference, even if specified independently. Standardisation of this interface will allow, if required, to give
to the device the status of “interoperability constituent”.
When several physical devices, with the capability of playing the “master role”, are available in the
elements which are assembled to form a train, only one of these shall be “confirmed” to fulfil the role at
train level, during train preparation. During the journey, the “master role” shall be taken by one (and only
one) of the other devices, if the first one fails.
Category 3: Classes corresponding to devices ensuring interfaces with “external” human actors
Are considered here interfaces with “human actors” physically present on the train: driver, conductor,
passenger (usually called “MMI devices”).
4.4.1.1 Train class
Operating unit: objects in this class are created at the start of a transport mission. This is dynamic object
resulting from a configuration process (usually called “train preparation”) and a linkage with a transport
mission defined by a Railway Undertaking entity.
From the functional point of view, the main component of train is the group of functions operating at train
level for control, communication, monitoring … This component is called “Train Functional Module”
(TFM). TFM includes control for doors, heating, lighting … These train level functions are interfaced:
- on one side with the driver and/or a fixed installation performing train control functions;
- on the other side with each “Consist Functional Module” (CFM) , via the B interfaces.
With GSM-R communication system, a train can be addressed by a functional number (train running
number), which is registered in the GSM-R network at the start of the train mission, and deregistered at
the end of the mission.
4.4.1.2 Consist class
Member of this class are set of vehicles not separable in operation. A consist may be a single vehicle.
Most common consist types are:
- locomotive;
- trainset (also called Multiple Units);
- passenger coach (when not part of a consist);
- freight wagon.
Consist level functions are usually distributed in the vehicles.
From the functional point of view a consist is represented by a set of functions, called “Consist Functional
Module” (CFM). In some case these set of functions may be split, for convenience, into subsets. Then a
“physical consist” may be represented, in fact, by several “functional consists”. For instance:
- subset of “technical functions”: traction, braking, energy;

- subset of “passenger functions”: doors, public address, passenger information, seat reservation, air
conditioning…
CLC/TR 50501-1:2007 – 14 –
4.4.1.3 Single vehicle
Not considered when the vehicle are part of consist. Access to a vehicle by train level functions is always
made through a consist interface. Internal vehicles within a consist are not shown in the Reference
Architecture. If the single vehicle is also a consist, it should be modelled as a consist.
4.4.1.4 Master clock device and clock synchronisation
Device providing “time & date” reference data element, to the train, then acting with the role of the train
“master clock”. A “master clock” to be used by all on board functions (for clock synchronisation, time
stamping…). The time reference shall be UTC time.
For clock synchronisation within a train, standardised protocols should be used. Among the available
protocols, two have been considered:
1) Precision Clock Synchronization Protocol for Networked Measurement and Control Systems.
(IEEE1588-2002, in short PTP, also labelled IEC 61588); defines a protocol enabling precise
synchronization of clocks in measurement and control systems implemented with technologies such
as network communication, local computing, and distributed objects. The protocol will be applicable to
systems communicating by local area networks supporting multicast messaging including, but not
limited to, Ethernet;
2) Network Time Protocol version (in short NTP). NTP is a protocol designed to synchronize the clocks
of computers over a network. NTP version 3 is an internet draft standard, formalized in RFC 1305.
NTP version 4 is a significant revision of the NTP standard, and is the current development version,
but has not been formalized in an RFC. Simple NTP (SNTP) version 4 is described in RFC 2030.
Preliminary conclusion on time distribution, to be taken into account with standardisation of the train
function ‘time and date management”.
For new systems only:
PTP shall be used for a tightly coupled domain, with NTP as a backup.
A tightly coupled domain, in the scope of this document, is typically:
- a train, with one or more consist(s);

- a consist in a fall-back strategy, when the two domains of the two consists of the train can not be
merged, for any reason.
If there are several domains, NTP could be used for synchronisation of master clock of each domain.
Some of these domains could be ground based systems.
A GPS clock could be used as the master clock required by the synchronisation protocol, when available,
in association with a local clock. The offset between GPS time and UTC time (the so-called “leap
seconds”), is also periodically provided by the GPS system.
Orders of magnitude for clock synchronisation precision are:
- less than 1 ms, inside a PTP domain. Used to timestamp fault related event, etc.;
- between PTP domains order of magnitude is 25 ms;
- for most trains functions, 100 ms seems to be enough;
- but 1 ms could be useful for precise time stamping of fault related event (this value is presently
required in some fields of automation, such as printing machines) needed in some cases to ease
diagnostic, or synchronisation of blinking lamps, for driver comfort.
– 15 – CLC/TR 50501-1:2007
4.4.1.5 Location determination device
Device providing continuously location (or train position) data.
Location information is used by several functions such as:
- tracking (for ground based information system);
- for passenger information: next stop announcement,
- for the diagnostic system, with communication with the workshop activated, depending on the
location of the train (where conditions are best for radio communications). This location information
may be part of the context for an event such as a fault detection.
ETCS on board subsystem could also be a source of location information.
Several sub-classes will be defined to take into account different level of performance required by
different functions.
4.4.1.6 Speed Measurement Unit
Device using one or more sensors (wheels, radar…) and elaborating a data element “speed”
(or “velocity”), which is as a train attribute.
ETCS on board subsystem could also be a source of speed information.
Several categories will be defined, corresponding to different performance characteristics.
Main attributes of “speed data element” (available on the interface with the consist):
- accuracy, with confidence interval;

- resolution;
- unit;
- time stamp for the speed value.
- Attributes of the speed device are:
- minimal refresh rate;
- reliability;
- availability.
4.4.1.7 Man Machine Interface
A Man Machine Interface is the interface between some in-vehicle control function and an “human actor”
(driver, conductor, crew, passenger), not a part of the “rolling stock” entities.
The goal is capture the behaviour of a generic “human sensor” within the definition of an interface.
4.4.2 Interfaces between rolling stock entities.
The interfaces considered in this architecture are described below.
4.4.2.1 Train level to consist interface (interface B)
This functional interface is between the Train Functional Module (TFM, see 4.4.1.1) and a one Consist
Functional Module (CFM, see 4.4.1.2). There are as many such interfaces as there are consists. (labelled
B1, B2, B3, B4 in the Figure 1 below). This feature allows for important capabilities:
CLC/TR 50501-1:2007 – 16 –
- usage of different “communication solutions” for each interface implementation. For instance, wired
communication, or wireless communication (as required for remote control of locomotives in freight
trains, where wagons are not equipped with a wired train bus)
- management of different kind of trainset consists by the TFM. The TFM, on each point-to-point
interface Bx with a consist, will discover the services available on the consist (and which are not part
of the “common standard part”), and then “customise” the Bx interface . The leading consist knows
the capabilities of other consists regarding a given function. So he can act accordingly, make
decisions when requested service is not available, and send appropriate command to each train set
individually (decision being made by the control system). The knowledge is acquired by an
inauguration process at the coupling stage: if decisions can be automated, or by importing MMI of
the driven consist, if the driver is to make the decisions (and is allowed to do so). This calls for the
notion of successive versions with upward compatibility, at functional level. All versions are
referenced in a tree structure, allowing to identify a common version between two consists. This has
to be further elaborated (use of XML, to describe messages exchanged…).
This is a dynamic interface, point-to-point, established during the train inauguration.
Control functions of the TFM are usually residing in the leading consist, but may be distributed.
Each physical consist includes a function (usually called a “gateway” function) which implements the
interface between the train level and the CFM of this consist. In order to simplify the representation, the
interface function is considered a part of the CFM (only for “coupled” consists)
NOTE This functional communication architecture, with a set of point-to-point interfaces, does not implies any particular
communication technical solution. In particular, it does not imply that the physical architecture has the same “star topology”. For
wired interfaces in Passenger trains, the classical implementation is using a “bus” topology (like Wired Train Bus, or WTB), each
consist being connected to this train bus.
If such a train bus has only subscriber which are the CFM, then it will be called a “inter consist bus”.
On the physical communication level, there are only Consist to Consist interfaces (passing through the
automatic coupler). On the functional level there is no Consist to Consist direct interface.
4.4.2.2 Train level to ground application interface (interface C-Train)
This interface is between the Train Functional Module (TFM, see 4.4.1.1) and a one ground based
function, under the responsibilities of a Railway Undertaking (RU).
This is a dynamic interface, point-to-point, established after the train inauguration. This interface is used,
for instance, for remote triggering of train preparation.
4.4.2.3 Consist level to ground application interface (interface C-Consist)
This interface is between the Consist Functional Module (CFM, see 4.4.1.2) and a one ground based
function, under the responsibilities of a Railway Undertaking (RU) or Rolling Stock Maintenance (RSM)
This interface is useful when the remote function needs to address the physical consist, irrespective of its
operational state.
The Figure 1 given in the following page is an illustration of a railway system compliant with the STD1
Reference Architecture.
Train (4 consists)
Consist 1 (locomotive) Consist 2 (1 vehicle) Consist 3 (trainset) Consist 4 (2 vehicles)
(B4) radio
(B2) wire (B3) wire

D (B1) wire
r CFM-1 CFM-3
TFM CFM-2 CFM-4
i (A) (A) (A)
v
e (A)
r
- 17 -
– 17 –
(C-Train) Vehicle elements

(C-Consist)
(C-Consist)
(D)
TFM Train Functional Module

(D) (D)
Fixed
CFM Consist Functional Module
installations
CLC/TR 50501-1:2007
Vehicle element
SUPPLIEDFigure
BY BSB1Edge Pvt. Ltd. UNDER
– Reference THE LICENSE
Architecture: FROM BSI
Relation FOR RITES
cases LTD.
in the - GURGAON
functional ON 19-02-2018 12:45:02
communication (103.7.128.130)
architecture
CLC/TR 50501-1:2007 – 18 –
4.4.3 External entities interacting with rolling stock entities
The external entities considered in this document are:
- Railway Undertaking (RU);

- Infrastructure Manager (IM);
- Rolling Stock Maintenance (RSM);
- Fixed Installation (FI).
It is not the objective of this document to specify the responsibilities of the above “External entities”. The
following text gives, only for illustrative purpose, a non exhaustive (and not necessarily accurate) list of
the responsibilities of these entities.
For a “rolling stock” function interacting with such an external entity, the main aspects to be considered
for describing the interaction, are summarised below, and shall be referred to, in the functional model.
4.4.3.1 Railway Undertaking (RU)
Railway Undertaking shall mean any public or private undertaking the principal business of which is to
provide services for the transport of goods and/or passengers by rail with a requirement that the
undertaking must ensure traction; this also includes undertakings which provide traction only. [Directive
2001/14/EC]
4.4.3.2 Responsibilities
- Offer transportation services to customers
- Manage transportation contracts (including sales, schedules)
- Manage resources necessary to ensure reliability of the transportation services (for example
adherence to schedule, achieving contractual deadlines, maintenance of RS…)
- Ensure safety of transportation (safety of persons, transported entities, and environment…)
according to relevant safety standards an regulations
4.4.3.3 Collaboration:
- With IM: request the path, providing necessary information
- With RS: prepare train for movement
- With RS: ensure movement
- With RS: tracking and tracing of trains and transported entities
- With RSM: give back RS for repairs
- With FI: manage movement respecting commands received from FI (signalling...)
4.4.3.4 Infrastructure Manager (IM),

Infrastructure Manager: any body or undertaking that is responsible in particular for establishing and
maintaining railway infrastructure. This may also include the management of infrastructure control and
safety systems. The functions of the infrastructure manager on a corridor or part of a corridor may be
allocated to different bodies or undertakings.
[Directive 2001/14/EC]
- Define the plan of the infrastructure, including classification of lines according to type of traffic (for
example high speed line, freight lines, participating or not in the Trans-European network)
- Define restrictions attached to infrastructure elements, which have to be respected by RU (for
example compatibility of RS and tracks, qualification of drivers…)
- Prepare offer of train paths to Railway Undertaking
– 19 – CLC/TR 50501-1:2007
- Manage resources necessary to ensure availability and safety of the infrastructure (for example,
achieving contractual deadlines, maintenance of infrastructure…)
- Manage contracts with RU (including sales, schedules)
4.4.3.6 Collaboration
- With RU: grant , or check, permit to operate a line (drivers..)
- With RU: grant time slot, and path with a given schedule
- With RS: grant or check permit allowing a given RS piece to be operated on specific part of
infrastructure
- With FI (fixed installations): to receive real time information on availability of resources
- With FI: send instructions to configure fixed installations (route settings, energy system…)
4.4.3.7 Fixed Installation (FI)
- Wayside equipment resources which are managed by an Infrastructure Manager
- Wayside equipment resources used by IM
- Ensure safety of rolling stock movement
- Supply energy
- Supply interchange facilities for transported entities (stations, loading and unloading goods…)
- With IM: see IM/FI
4.4.3.10 Rolling Stock Maintenance,
- Ensure availability and operational condition of RS according to traffic schedules
- Manage resources for necessary repairs
- Manage contract with RU including availability objective
- With RU: exchange of RS diagnostic information
- With RU: give back repaired RS
4.4.3.13 Possible derivations from these classes
(not exhaustive):
Railway Undertakings (RU), [organisation]

- Fleet Managers
- Train drivers
Infrastructure Managers (IM), [organisation]
- Traffic Operators
Fixed Installation (FI)
- Train station
- Tracks
- Depot
- Control centre
CLC/TR 50501-1:2007 – 20 –
4.5 Functional Architecture
The classes, as described above, define the abstraction level of the Reference Architecture, regarding
rolling stocks entities.
A functional model shall only use objects derived from the classes which are part of the Reference
Architecture, and classes derived from them.
The following aspects have to be considered for producing functional models:
4.5.1 Communication and business aspects
At its top-most level, the communication system in the interoperable Trans-European network presents
interfaces between different subsystems, interfaces with customers, and processing and storage
capabilities.
The following aspects of the communication system shall be considered for the definition of any standard
function:
- the exchange, storage and processing of information at interfaces with structural subsystems or with
operational subsystems;
- the level of authorisation required to exchange, store and process information, including security and
confidentiality aspects;
- the state of the entity or entities being affected by the exchange, storage and processing operations;
- the state of the entity or entities offering capabilities to perform the operations of exchange, storage
and processing, including function binding, discovery and resilience;
- quality of service , such as:
1) availability of functions (24H/24H, 99,99% of time, etc.);
2) reliability of functions (guarantee of completion, etc.);
3) communication channel performance indicators (maximum amount of data transmissible in a
given period of time, etc.);
4) time constraints, for exchange, storage, or processing of information;
5) geographic limits, for exchange, storage, or processing of information.
The following business aspects shall be considered for the definition of any standard function:
- traffic planning;
- rolling stock planning;
- rolling stock maintenance;
- access to infrastructure;
- loading, tracking, tracing and unloading, in the case of freight trains;
- embarking, ensuring comfort and information, and debarking, in the case of Passenger trains;
- train driving (relates to the activities of a train driver);
- controlling train movement (relates to the activities of a control centre).
The functional model shall explicitly address all communication and business items above, when relevant.
Aspects that are deemed non-relevant shall be explicitly indicated as such.
– 21 – CLC/TR 50501-1:2007
4.5.2 Management level for In-Vehicle functions
To describe the train wide management of the different connected subsystems, different management
levels have to be considered:
- train management level - includes train wide functions (e.g. door – release, open, close, left/right
side);
- consist management level - includes consist wide functions (e.g. door – side correction depending on
direction of the consist in relation to the whole train with the input from train inauguration);
- vehicle/System management level - manages a subsystem inside the vehicle, typically part of the
managed system, in TCMS software just an interface (e.g. door – doors locked for the vehicle);
- subsystem management level - typically part of the to managed system (e.g. door control unit only
responsible for a part of the doors in the vehicle).
To ensure proper control and monitoring most subsystems have one logical interface on consist as well
as on train level.
Depending on the regarded subsystem certain management level(s) can be empty.

Ex: Diagnostics are typically handled on “consist level” and there are stored in a database. The
transmission of control and monitoring data as well as diagnostic results and their visualisation for driver
and train crew are “train level” functions (refer to scopes of UIC647 [15], UIC 556 [8], UIC 557 [1’], and
UIC 652 [16]).
4.5.3 Operating states/modes
From the functional point of view, several operating states have to be distinguished:
- operational functionality (control and monitoring);

- maintenance functionality (including diagnostics);
- parameterisation, configuration.
For a given function a functional requirement specification will be edited. Each requirement shall specify
to which management level it pertains, and to which operating state it belongs.
For instance, the train configuration process, which is at train management level, will have to distinguish
among the different consists a special class, corresponding to the functional role of the “leading consist”.
This class “leading consist” is distinguished from other consist classes by several properties, such as:
- allowed only for the operational state;

- includes the only active driver cab control;
- active Interface C for train operation with the ground;
- active “Control-Command signalling” (ETCS….) on board functions.
4.5.4 Exchange of information among functional elements
4.5.4.1 Managing the dynamic context
An important concept within the Reference Functional Architecture is how a functional element is
accessed in the railway vehicle dynamic environment. Even if this document deals primarily with the
definition of functional model, this abstraction shall lead later to concrete realisation. Moreover railway
vehicles are mobile, and communicate with ground stations using wireless communication, which implies
the existence of a ground based communication infrastructure.
CLC/TR 50501-1:2007 – 22 –
The current state of the art suggests that such communication infrastructures would probably adopt the
so-called “Internet” protocols, such as:
- the Hypertext Transfer Protocol (HTTP) for coding text appearance on computer screens;
- the Transmission Control Protocol (TCP) for the management of data exchange between computers;
- and the Internet Protocol (IP), for addressing data to a well-defined computer connected to the
communication infrastructure.
Reaching a Functional Element implies the use of communication path. It is then necessary to associate
to each relevant element:
- its identification, or name;

- its location, or address;
- and a route leading to this address.
The name shall not be bound to the address until a specific mapping process takes place. This mapping
takes all its relevance in the railway transport context, where mobility may imply address changes over
time.
Also, the address does not need to be bound to the route until this mapping takes place; the choice of an
“appropriate” route may change over the time.
Further, the route may only require one step to reach destination (a direct route), or may impose a
succession of intermediate transmission steps to the information that is being forwarded. This implies the
adoption of some “routing” process.
For the purpose of a functional model, only a “functional address” (an identification) shall be used, as the
identifier of a functional element. The mapping processes described above shall be performed by the
communication system, according to the definition a “standard functional addressing scheme for railway
vehicles”.
4.5.4.2 Dynamic Insertion of a Node Object
Dynamic Insertion of a Node Object (DINO) is a specific model for rail applications, which accounts for
dynamics involving communication entities. This concept has been first proposed by the TrainCom project
(ref: IST-1999-20096), and fits well to XML and UML modelling practices.
In the World Wide Web, resources are named by their Uniform Resource Locator (URL); this name is
converted into a numeric, hierarchical address (the IP address), that is easily handled by all computers
connected to the network. Communication systems may be said static or dynamic. In the case of static
systems, a given resource will keep its Internet address for quite a long time, implying a long-term binding
between the URL and the IP address. This binding is said static, or early binding.
Early bindings form a simple and logical architecture, very similar to an address book: associated to each
person’s name one can find person’s address. It works fine primarily because people normally have long-
term addresses.
If addresses are changed frequently, there is a need of some mechanism for updating the address book
often enough to catch every change. These types of dynamic bindings are referred to as late bindings.
– 23 – CLC/TR 50501-1:2007
Trains have this dynamic behaviour, and may change network bindings and topology quite often:
- first of all, because a train moves, and will connect to different ground-based wireless stations along
its road. To establish a connection with a moving train, we will need to know its location, and use a
communication path that includes the ground station to which the train is currently connected.
- secondly, consists are coupled and uncoupled, which imposes changes in the network topology
associated to each configuration.
- thirdly, a “train number” is associated to a given rolling stock only for the duration of a given journey.
Considering the number of trains involved daily, the maintenance of address binding could be a resource-
consuming task. Rail environment calls for components that are able to join and leave the network,
possibly unsupervised, in a ad-hoc fashion.
Different modes of access to rolling stock resources are envisaged, corresponding to different operational
situations:
- physical addressing: direct access to a specific consist or vehicle regardless of its geographical
location, and is position in a train composition;
- operational addressing: access to a specific running train, regardless of the physical rolling stock on
duty.
The functional model of accessing entities (such as vehicle, trains, and equipment) shall be taken into
account. For those reasons the information exchange infrastructure shall guarantee:
- geographic independence: an entity and its functions are reachable independently of vehicle
location;
- function binding: an entity and its functions are made available (published) in the communication
network as soon as a communication path is available;
- function discovery: a specific function of a specific entity may be discoverable upon request from a
potential user (a client);
- function security and privacy: a specific function of a specific entity needs to offer, upon request from
a client, guarantees against actions that violate well-defined security or privacy levels.
4.5.4.3 Existing functional addressing schemes
There are presently two important existing functional addressing schemes for railway vehicles, which
have to be taken into account, both defined by UIC organisation in:
- UIC Leaflet 556: UIC 556 (Bibliography [8]) and the accompanying UIC codes define the operator's
view on the train, the framework for the coordination of the different applications and the operational
handling to ensure interoperability between vehicles from different manufacturers;
- UIC EIRENE specifications for GSM-R (Bibliography [10], [11]). The EIRENE Specifications provide
the framework for interoperability (for mobile communications). They underpin the EC Directive on
the Trans-European High Speed Rail Network, along with other specifications being developed by
the ERTMS User Group.
A brief description of both schemes is given in Annex B.
We have also to consider the Internet technology, where an HTTP URL is translated to an IP address by
a Domain Name Service.
CLC/TR 50501-1:2007 – 24 –
5 Methods for functional modelling
5.1 Functional modelling framework
The adopted method for functional standardisation provides a standard framework that shall be used for
modelling functions in the field of intercommunications between rail vehicles and train/wayside.
This method shall be adopted for all functions which will be considered in other parts (in categories STD2
and STD3) of this series of standards.
Function standardisation in this field of application implies dealing with complex interactions between
actors in the rail market. In order to address all relevant impacts of the proposed standard functions, a
uniform process of function class decomposition shall be applied.
For functional modelling, the Object Orientation (OO) paradigm is adopted: a method for system definition
and description where a system is defined to comprise objects or groups of objects with similar
characteristics (Classes) where the characteristics of the Class (object) and data associated with the
Classes are well defined and the interactions between classes and actors are defined in terms of
interactions, behaviour and data. The behaviour is described through interaction instances (Use Cases).
OO methodology is normally developed and managed using computer based OO modelling tools; the
most widely used modelling tools are based on the Unified Modelling Language (UML).
The process, detailed below, includes the establishment of a functional model that supports the definition
of the function. This model shall be built starting from the Reference Architecture defined in Clause 4.
5.1.1 UML usage
The standardised language adopted for this modelling framework is the “Unified Modelling Language”
(UML) as defined by OMG specification version 1.4.2 (see Clause 2).
NOTE This document has not the objective to be a tutorial on UML, nor on design methodology. Care has be taken to allows
readers without UML knowledge to understand most of the text.
UML defines graphical languages to describe the artefacts of distributed object systems.
The most relevant diagram types for our modelling purposes are:
- use case diagrams, for elaboration and structuring of the use cases defined in the requirement
analysis phase. Use cases can be structured according to their relations to each other and to actors.
Also common parts of use cases can be factored out into own use cases;
- class diagrams and component diagrams, for defining components and their (functional) interfaces;
- sequence diagrams, for specifying testable use case realizations thus defining functional test cases;
- statechart diagrams, for behavioural modelling of systems and components with ‘reactive’ behaviour.
5.1.2 Model structure
This clause defines a common structure for all functional models, using UML “packages” (general
purpose mechanism for organising elements into groups). Packages may be nested within others
packages. Dependencies relation between packages are also indicated.
The models for functions and devices shall be structured into the following packages (‘device’ refers both
to the device and the sub-functions it carries):
– 25 – CLC/TR 50501-1:2007
- actors package, contains relevant actors for the functions – if they are not already defined in Data
Dictionary “common actors” package. This package contains two sub-packages, one for “human
actors” (driver, conductor, passenger, dispatcher…), and one for “system actors” (devices…). An
actor is a role of an object or objects outside of a system that interacts directly with it, as part of a
coherent work unit (a use case). An actor element characterises the role played by an outside object;
one physical object may play several roles and therefore be modelled by several actors;
- use cases package; contains use cases for the function. The requirements which are relevant for the
functions, structured and detailed. The definition of additional use cases, for example for handling
errors might also be necessary;
- ‘Logical’ package; contains classes for interfaces and data structures and the definition of behaviour
for the function;
- ‘Use Case Realizations’ package; contains scenarios and interaction sequences for each use case
using the elements from the ‘Logical’-Package;
- standard interface package; contains classes for standard interfaces;
- components package; contains the components, their interfaces and dependencies. (optional, as it
results from a design process for the realisation of the function).
The following diagram shows an example of a model structure for the “Passenger emergency brake”
function. This sample model is only for illustration purpose, and was used by WG B14 and further
elaborated in MODTRAIN European Research project (ref: TIP3-CT-2003-506652).
The package “Common Definitions” is typically an extract from the Data Dictionary (see Clause 6). In all
diagrams below, the small black arrow ‘!‘ indicates a cross-model-dependency.
CommonDefinitions
Actors Interfaces Types
«import»
«import»
«import»
EmergencyBrake
EmergencyBrake_ Actors EmergencyBrake_UseCases EmergencyBrake_Logical EmergencyBrake_Components

«access» «import»
«access»
«access»
EmergencyBrake_UseCase
Realizations
Figure 2 – General model structure – Example
5.2 Functional modelling activities
5.2.1 Initial step
This initial step in the process is triggered by a “mandate for standardisation” for a given function.
CLC/TR 50501-1:2007 – 26 –
Activities:
- input document (provided with the “mandate for standardisation”) analysis: functional requirements,
constraints, specification for similar function existing implementations….);
- check definitions (reference to standard definitions, UIC dictionary of terms…);
- identify ambiguities, decide if acceptable or not;
- estimate the complexity of the model to be produced, referring to relevant metrics;
- submit results of analysis for approval to the appropriate CENELEC body.
A result of this step is an agreed set of requirements.
5.2.2 Step 1 - Definition of actors and use cases
The result of this step is a set of use case definitions in the UML model, together with their relevant
actors.
Activities:
- explicit use cases from the requirements analysis (descriptions, basic flow, alternate flow);
- structure use cases using ‘generalization’, ‘include’ and ‘extend’ relations;
- add relations between use cases and their actors, add actors if necessary;
- check for completeness: Are all relevant use cases defined? Do the use cases also cover situations
of failure that must be specified? (Add use cases and actors, if necessary).
The following use case diagram is an example related to the function “Passenger emergency brake”:
Apply emergency brake
«include»
«include»
acoustical alarm «extend»
Activation
Passenger
Timout
Initiate braking
brake operation Driver
«System» communication errors

RT-Communication
ErrorDuringOperation
controller error
«System»
PLC-Status-Control
Figure 3 – UML Use case diagram – Example

– 27 – CLC/TR 50501-1:2007
5.2.3 Step 2 - Components and their interfaces (UML-Model)
The result of this step is a modular view of the realization of the function
Activities:
- define components for the realization of a function. The coarsest granularity for building components
should be the realization of a single sub-function on a single device;
- - components can have multiple interfaces. Define interfaces the components realizes by
considering their functional roles, like an interface for ‘passenger input’ or like separate
interfaces ‘status’ or for ‘commissioning’ or ‘service access’, etc.;
- - a component depends on all those interfaces it uses;
- - a component can only interact with others through its interfaces.
The exact specification of the contents of an interface and the behaviour will be defined in 5.2.4
Check of interfaces for completeness: Are they sufficient for defining all necessary dependencies and
communication to realize the use cases? (If not, add interfaces and dependencies as needed.)
Check if interfaces are ‘orthogonal’: Do different interfaces have non-overlapping functionality? (If not,
refine interface definition.)
The modular view of the realisation is shown in the following component diagram:
Comment: Multiple Instances of

the Passenger Emergency Handle
Unit.
PEHU EmergencyBrakeControl
PEHUInput
DriverEB
AlarmOutput
Interfaces supplied by other

EmergencyBrakeStatus functions
Figure 4 – UML Component diagram – Example
5.2.4 Step 3 - Interfaces, data structure and behavioural specifications (UML-Model)
The result of this step is the definition of interfaces, all necessary data structures and parameters, and
<<Control>>-classes defining the behaviour.
CLC/TR 50501-1:2007 – 28 –
Activities:
- for each interface: define functions for the received messages;

- for each interface: define attributes for data exchanged through the interface periodically. (Formally,
the use of attributes in an interface is a violation of the UML 1.4 definition, but with UML 2.0 this will
also be allowed. It is also allowed presently by some UML tools);
- define <<Data Type>> classes for all data structures used as parameters or structures that are used
for configuration;
- define <<Control>> classes which realize the component’s interfaces, with all necessary attributes
and functions;
- the class diagram below, in Figure 5, shows the detailed interfaces of the EmergencyBrakeControl-
component from above;
- the interfaces are identical to those shown in the component diagram above;
- the classes shown below all reside in the component EmergencyBrakeControl and the class
BrakeControl realizes the EmergencyBrakeControl’s interfaces;
«interface»
«interface» «interface» «signal»
DriverEB
AlarmOutput PEHUInput Error
+ activateEmergencyAlarm ( ) + code : UINT
+ activateAlarm ( ) + handleOperationDetected ( )
+ recordAlarmMessage ( )
+ activateBrake ( )
+ releaseBrake ( )
«interface»
EmergencyBrakeStatus
«Control»
BrakeControl + «readOnly» brakeApplied : BOOL
+ currentStatus : BrakeControlStatus + setParameters ( [in] p : EBControlParams ) : BOOL

+ timeoutAlarmMSec : UINT = 1000
«signal» Error(code : UINT)

«enumeration»
BrakeControlStatus
Active
Inactive
1 + activeParameters Error
«Data Type»
EBControlParams
+ suppressAlarm : BOOL = FALSE
+ suppressRecording : BOOL = FALSE <Double click to open BrakeControl
Behaviour>
Figure 5 – UML Class diagram – Example
- add behavioural definition of classes: define state chart for <<Control>> classes (see diagram below);
- use states for defining activities (such as ‘waiting’, ‘alarming’…);
- only use interface function-calls, signals and changes of attribute values, signals or timeouts as state
transition triggers;
- use actions (preferably not at transitions, only within states) to precisely define the activities
associated with a state or a state transition (such as changing values of variables or sending
messages or calling other functions).
– 29 – CLC/TR 50501-1:2007
The state chart diagram below shows the behaviour of the class BrakeControl.
Operating
BrakeControlInactive enable=TRUE
Entry/brakeApplied=TRUE
Waiting
Entry/brakeApplied=FALSE activateEmergencyAlarm ( )
enable=FALSE
Alarming
releaseBrake ( ) Entry/activateAlarm
activateBrake ( )
activateBrake ( )
Brakeing
Entry/brakeApplied = TRUE
Error
Error
\after timeoutAlarmMSec\
Figure 6 – UML Statechart diagram – Example
5.2.5 Step 4 - Use case realizations (UML-Model)
The result of this step is a set of use case realizations described by sequence-diagrams. They describe
how the use cases are realized by the components and interfaces that have been defined in the steps
before. These sequence diagrams will also be used for test cases in the test specification later.
Activities:
- for each use case, define use case realizations (as many as needed to model basic and alternate
flows thru the use cases);
Activation ErrorDuringOperation
ErrorScenario
ActivationScenario
- for each use case realization, define the sequence of interaction between the interfaces: the input
from actors and the communication between the components by sending messages or by changing
variable values;
- for time constraints, use the annotations, see sample diagram below;
- if a state chart has been defined: check for consistency with the statechart.
Prerequisite for this step is that the level of formality of statechart and sequence diagram match, like in
this example.
CLC/TR 50501-1:2007 – 30 –
: Passenger : Driver : PEHU : PEHUInput : AlarmOutput : DriverEB
1 : \handleOperation\ {RTend < (3000,ms)}
2 : handleOperationDetected ( )
3 : activateAlarm ( )
{RTstart = (0,ms)} 4 : activateEmergencyAlarm ( )
{RTend-RTstart<(1000,ms)}
{RTstart < (4000+timeoutAlarm

MSec,ms)}
5 : activateBrake ( )
Figure 7 –UML Sequence diagram – Example
5.3 Process of function class decomposition
The process description given in the above Introduction corresponds to a rather “linear view”, with
successive steps. In practice, modelling is often an iterative process, with several phases of refinement.
The text given in Annex C present such a procedure, which is giving a more “dynamic view” of the same
process.
5.4 Modelling accessibility of entities and functions: the pattern view
The accessibility is a property that covers many points, from the permission to have access to a function
to the capability of an equipment to provide the function in the standardised way we are describing, or to
sustain some performance aspects.
Patterns offer solutions to generic problems. Usually, these solutions were obtained by trial and error, and
refined over a substantial period of time. Patterns are in general described by a name and intent. Pattern
descriptions also include its applicability, structure, participants (classes, interfaces, objects, and so on),
and the co-operation between these participants.
For our purpose, two patterns are relevant:
a) composite pattern;
b) proxy pattern.
5.4.1 Composite pattern
A typical composite is a vehicle: it contains other entities, such as brakes and doors. It would be useful to
manipulate composites exactly the same way we manipulate simple (primitive) objects. For example, we
may assume that self-diagnostics of brake controller can be accessed, downloaded, and scanned to
extract faults.
– 31 – CLC/TR 50501-1:2007
We would also want to perform the same operation on the whole vehicle (a composite), and expect to
have access to self-diagnostics of each composing entity (components), without taking care of
establishing list of components and then addressing each one individually. If we need to distinguish
between primitive objects and composites to perform the same operations on those two types of objects,
our functional model will become complex and difficult to implement, maintain, and extend.
In their book “Design patterns”, Gamma, Helm, Johnson and Vlissides define composite patterns
(Bibliography [5] : compose objects into tree structures to represent part-whole hierarchies. Composite
lets clients treat individual objects and compositions of objects uniformly.
The composite class maintains a collection of components. Typically, composite operations are
implemented by iterating over that collection and invoking the appropriate operation for each component
in the collection.
The composite class extends the component class, so you can use a composite where a component is
expected.
5.4.2 Proxy pattern
The proxy pattern is a milestone for the functional model, because it forces visibility of a functionality to
occur indirectly through the proxy object. As its name indicates, the proxy object acts as a surrogate for
another object, which delegates functionality to it. Proxy objects are declared in a way that usually
eliminates user (client) awareness that they are dealing with a proxy.
For example, an equipment may have its own a wireless link to communicate with the ground;
alternatively, it may establish communication with the ground using a wireless link available in another
equipment.
The second approach is an example of a proxy. The proxy can be either a dedicated equipment or a
piece of software: in both cases it offers the possibility for an already equipped communication network to
be accessed without refurbishing all equipment items in that network.
As functional addressing is used in the communication architecture, the proxy will perform the translation
of functional address into physical address. This is an important advantage for the proxy concept.
Related patterns are
- access proxy: this pattern uses a proxy to enforce a security policy on access to a service,
- façade: uses a single object as a front end to a set of interrelated objects,
- virtual proxy: uses a proxy to create the illusion that a service exists before it has actually been
created. It is useful if the object is not yet present and if its services are not needed immediately,
- decorator: this pattern is structurally similar to the proxy pattern in that it forces access to a service to
be done indirectly through another object.
5.5 General modelling rules
General rules given below, aiming in particular to allow consistency between different successive
versions functional models, are applicable to the process of model elaboration.
5.5.1 Expandability
All data structures should be expandable (adding new data elements).

CLC/TR 50501-1:2007 – 32 –
5.5.2 Versioning
If the meaning of data elements could change over time a version-numbering scheme is required for
identification of old versus new versions. A better solution, when applicable, is to find an abstract class
that allows for unforeseen developments, e.g. like "retaining device" instead of "brake" so that some day
you might be able to develop "reverse thrust" systems for trains.
5.5.3 “Private” extensions
When appropriate allow for several layers of "private" extensions to objects, such as:
- country;
- railways undertaking;
- a specific homogeneous fleet;
- manufacturer.
(This allows for transferring data that are not interpreted by a third party as well).
5.5.4 Definitions of model elements
5.5.4.1 New class definition
Already existing standard definitions (which can be found in the Data Dictionary, see Clause 6) must not
be changed. If something new must be defined, a new definition has to be added.
Any new definition should be a special case of one other existing definition, whenever possible. Only the
base definitions (= most general definitions) predefined by the Reference Architecture (in Clause 4) are
not special cases of any other definitions.
Specialization and inheritance: as a default, a new definition inherits all attributes and parts from the more
general definitions (parent definitions).
The new definition is used to specialise the parent definition by:
- adding new attributes;

- restricting parts or associations, i.e. restrict the multiplicities of parts or define parts more precisely;
- restricting value-ranges of attributes.
To be useful, a new definition should do at least one of the things above. Otherwise this new definition
might not be needed at all.
If some attributes and parts are inherited without any restrictions, they are not repeated in the new
definition. They can be found by the reference to the more general definition.
5.5.4.2 Consistency
A new definition must not contradict with the more general definition.
5.5.4.3 Completeness
Definitions which are referred to (as generalization or by associations) must exist.
5.5.4.4 Basic class definition
Any proposed extension of the base definitions must also fulfil the above criteria. This corresponds to an
extension of the Reference Architecture.
– 33 – CLC/TR 50501-1:2007
5.6 Metric evaluation criteria
Before finalising the draft model to be submitted for the testing phase, developers must be able to focus
on the quantification of the quality of the functional model. The metrics shall be able to measure:
- attributes;
- class;
- cohesion;
- coupling;
- inheritance;
- instantiation;
- operation.
From the state of the art, it seems not possible to fix limiting criteria for the measurements (count,
percentage, ratio, etc.). However, model complexity shall be estimated in the initial step of each functional
standardisation project.
It is an element of a workflow for producing the deliverables of 5.9
As far as the appropriate standardisation body shall put in place a management of the Data Dictionary
(see 6.3), these criteria could be used by this management as acceptance criteria. This same
management shall set targets and revise them periodically.
5.7 Testing
Testing is a difficult subject matter. The goal is to prove that the model derived by the process of function
class decomposition is a correct model.
First, syntax checks need to be applied to test that a formally correct model is achieved. But this testing
step is already incorporated within state of the art modelling tools. Therefore it is assumed that only
syntactically correct models are subject to the standardisation process.
To test that a draft of a model fulfils all requirements resulting from the use cases used to derive the
model an implementation of the model is needed. This can either be an implementation within the real
world or a suitable simulation environment. Functional test cases are derived from UML-sequence and
class diagrams.
For each function within a draft model a suitable test environment for the function in the context of the
Reference Architecture needs to be provided to the body of standardisation. Also a complete test plan
needs to provided. The body of standardisation has to approve the test plan. After successful execution of
the test plan the corresponding test protocol has to be inspected by the body of standardisation. After
approval of the test results the draft model is promoted to the state of an approved model an incorporated
in to the standard.
5.8 XML usage
The adopted exchange mechanism between involved parties is the Extensible Mark-up Language (XML).
It describes a class of data objects called XML documents and partially describes the behaviour of
computer programs that processes them.
NOTE This document has not the objective to be a tutorial on XML, nor on XML documents design methodology. Care has be
taken to allows readers without XML knowledge to understand most of the text.
5.8.1 Recommendation for construction of XML documents
Presently, for many technical domains, set of “best practices” are recommended to the users.
CLC/TR 50501-1:2007 – 34 –
5.8.2 General rules for describing data elements in XML

NOTE The rules given below are derived from recommendations found in a “best practices” document prepared by UIC/EDIFER
(UIC/XML working group, Bibliography [7]). These rules are also considered as being the “best practices”, relevant for the purpose
of this document.
In short, the main scope of these rules is to prescribe common rules for defining the various structures to
be used in the documents. When there are different possibilities for a given problem, the one better suited
to the context of “international standardisation” is selected. Some of these rules, are given below:
5.8.2.1 Measurement units
5.8.2.1.1 System of units
Measurement units are a representational property which designate the units (meters, seconds,
kilograms) in which a measured property is expressed. Conversion among measurement units is usually
multiplicative. Units are, in effect, scale factors for numeric values of measurements.
To specify the various aspects of measurements we consider the following concepts:
- measured property, e.g., length, mass, area, speed;

- measurement dimensionality, e.g., length/time for speed;
- measurement units, e.g., meters, kilograms, square meters, meters/second.
We also distinguish between:
- measures, (physical quantities), e.g., 50 meters/second (a composite of numeric value and units);
- coordinates (locations), e.g., absolute temperature, spatial or temporal locations (e.g., (latitude,
longitude)) specified with respect to some coordinate system.
Measured property and measurement dimensionality are semantic (conceptual) properties of the data,
while measurement units are representational properties.
Date-Time-Stamps (April 3, 2004 6:00 PM MET-1) are temporal coordinates, whereas duration of a
temporal intervals (e.g., 5 hours 15 minutes 12 seconds) are temporal measures. The distinction between
measures and coordinates is semantic, not simply representational.
The fundamental units of measure developed by the International Bureau of Weights and Measures (Le
Système International d'unités or SI) shall be used.
In all there are seven SI base units:
1) the meter for distance;

2) the kilogram for mass;
3) the second for time;
4) the ampere for electric current;
5) the kelvin for temperature;
6) the mole for amount of substance; and
7) the candela for intensity of light.
Other SI units, called SI derived units, are defined algebraically in terms of these fundamental units.
Currently there are 22 SI derived units. They include
1) the radian,
2) steradian for plane and solid angles, respectively,
3) the newton for force,
– 35 – CLC/TR 50501-1:2007
4) the pascal for pressure,

5) the joule for energy,
6) the watt for power,
7) the degree Celsius for everyday measurement of temperature,
8) electrical units the coulomb (charge),
9) volt (potential),
10) farad (capacitance),
11) ohm (resistance),
12) siemens (conductance),
13) units for measurement of magnetism the weber (flux),
14) and tesla (flux density),
15) henry (inductance),
16) lumen for flux of light,
17) lux for illuminance,
18) hertz for frequency of regular events,
19) the becquerel for rates of radioactivity and other random events,
20) the gray,
21) and sievert for radiation dose,
22) katal, a unit of catalytic activity used in biochemistry.
From current practice (such as UIC556, Bibliography [8], and other relevant standards), two other
elements need to be considered:
23) quantity (dimensionless measure of units);

24) percent to facilitate the communication of common dimensionless values.
Measurement units can specified as a further kind of derived data type with the addition of a units facet
(Bibliography [2]).
An example is the speed declaration in XML:
<typedcl ID="speed" />

<name> speed in meters/second </name>
<typefacets>
<basetype> float32 </basetype>
<units> <A xml:link="std1\railwayunits" HREF="#meterspersecond" /> </units>
</typefacets>
</typedcl>
More complex kinds of units can be defined in a systematic way. Units can either be basic units, derived
units, composite, or multi-radix units.
5.8.2.1.2 Shared registry for systems of units
Functional model developers should rarely, if ever, need to construct or even see the complete
specification for particular units and related properties. But interoperability requires additional standards
for such specifications.
CLC/TR 50501-1:2007 – 36 –
It is recommended that the standards organizations would package complete sets of units declarations
(basis units, dimensions/properties, and coordinate definitions) into web accessible XML documents
which could be referenced by individual schemas. Reference to such units definitions would be facilitated
if namespace prefixes (abbreviations) could be reliably used in attribute and element content.
This proposal envisions the use of canonical names for measured properties and measurement units.
This shared registry is a part of the Data Dictionary.
5.8.2.2 Tag naming conventions
The elements and attributes have to have a name: the “tag”. In summary, there are two possibilities for
naming a tag: human readable tag and coded tag:
1) a human readable tag has only two advantages: human readable and simpler. The main
disadvantages are: limitation in the presentation, limitation to one language, overhead treatment (to
be readable, often a very large tag is necessary), difficulties to reuse the names and … human
readability is not interesting for the computer;
2) the "not human readable" or coded tag solution solves the problems of the first solution. Indeed, the
human readability is realised by using techniques that enable a lot of presentations format. The
problem of multi-language presentation is also solved. This is particularly important in the framework
of international standardisation.
As it is required that the semantics of element and attribute tags (readable or coded) have to be
described in a repository or Data Dictionary, the choice between the two possibilities for naming a tag is
not necessary.
Indeed, the Data Dictionary will make the link between the coded tag and the human readable tag. Based
on this table of correspondence, software can generate XSL style sheets that will transform a XML
document using coded tags in a “human readable” version and vice versa:
- the coded version of the document shall be used for the message exchange;
- for the coded tag, use the format of ebXML UID: six characters beginning with a letter.
For the “human readable” tag name, it is necessary to define some recommendations about the length,
use of upper case or lower case, use of abbreviations or acronyms.
In summary, these recommendations are:
- use Upper Camel Case (UCC) format that use mixed case tag names, with the leading character of
each word in upper case and the remainder in lower case without the use of hyphen between words.
Examples: <TrainLocation> <TrainRunningNumber>;
- acronyms have to be avoided but where needed, use all upper case. Example: <GSMR>;
- abbreviations are discouraged, however where needed, word abbreviation should use UCC Upper
Camel Case;
- use underscore to separate acronym and text. Example: <UIC_Codex>.
– 37 – CLC/TR 50501-1:2007
5.8.2.3 Elements vs. attributes
A piece of information can be associated either to an element or to an attribute.
The following examples shows the two possibilities:
<Person Gender="female">
<FirstName>Anna</FirstName>
<LastName>Smith</LastName>
</Person>
<Person>
<Gender>female</Gender>
<FirstName>Anna</FirstName>
<LastName>Smith</LastName>
</Person>
In the first example "gender" is an attribute. In the last, "gender" is a child element. Both examples
provide the same information. There are no rules about when to use attributes, and when to use child
elements.
The attribute’s use simplifies the document and reduces the overall message size.
Here are some of the problems using attributes:
- attributes cannot contain multiple values (child elements can);

- attributes are not easily expandable (for future changes);
- attributes cannot describe structures (child elements can);
- attributes are more difficult to manipulate by program code.
If we use attributes as containers for data, we end up with documents that are difficult to read and
maintain.
Usage of child elements is recommended, except when the objective is to provide additional information
about an element. Attributes should only be used for giving metadata (data about data).
5.8.2.4 An element must contain atomic information
An information could be composed of several data. For example, a date contains information about the
day, the month and the year or a postal address contains information about the country, the town, the
street and the house or flat.
In a XML document, we have to choose to represent this "composed" information in only one element or
to decompose it in elements containing indivisible information.
It seems easier to manipulate indivisible information (query, sorting) and information becomes more and
more independent of the format (no structure).
Examples for each solution are given below:
<TelephoneNumber>003225259152 </TelephoneNumber>
CLC/TR 50501-1:2007 – 38 –
or
TelephoneNumber>
<InternationalInd>00</InternationalInd>
<CountryInd>32</CountryInd>
<RegionInd>02</RegionInd>
<Number>5259152</Number>
</TelephoneNumber>
Both examples provide the same information. The first is compact and must be linked to a format. The
second is expanded and allows, for instance, to sort easily the information by country. Once again, the
problem of expanded solution is the size of XML document that will be more important.
The recommendation is to use the expanded version. Only if the structure of the composed information is
unique and worldwide accepted, this information could be considered as atomic.
5.8.2.5 DTD vs. XML Schema
To describe the structure of a XML document, two techniques exist: DTD (Document Type Definition) and
XML Schema. We do not explain the difference between them but only give the main reasons why we
recommend using only XML Schema.
The recommendation is to use XML Schema recommendations from W3C to provide the structure of a
XML document. The main reason is that DTD is not a XML document and does not support all XML
associated techniques.
5.8.3 Translation of functional model into XML
The functional model provides entities, attributes, and relationships as main modelling primitives. The
model also incorporates the notion of inheritance, however, requires their explicit definition. We can
sketch also a procedure that translates a high-level conceptual description of a domain into a specific
document definition via XML Schemas.
1) Materialise the hierarchy:

Collect all complex classes that are used in subclass definitions making all classes and subclasses
explicit. This is necessary because XML Schemas lack any notion of implicit hierarchy.
2) Create a complex type definition for each class:
Add elements with names domain and range if the domain and range components are present in the
definition. Both elements get an anonymous type definition consisting of the reference to the class which
forms the domain or range.
5.9 Deliverables
At the end of the process, the resulting UML model and derived XML classes shall be added to the Data
Dictionary:
- XML deliverables;
- XML files; and
- XML schema files;
- testing instructions are also needed.
The UML model serves as documentation for the collection of XML classes and shall contain, as a
minimum:
- class diagrams;
- sequence diagrams;
– 39 – CLC/TR 50501-1:2007
- use-case diagrams;
- and any other relevant UML diagram needed to understand and use the XML classes;
- test plan and test protocol of the UML model;
- results of recommended metrics (see 5.6) evaluation.
6 The Data Dictionary
6.1 Introduction
The Data Dictionary is a central component necessary for development of consistent families of functional
standards such as STD2 and STD3.
Its purpose is:
- to document elements pertinent to the functional areas and essential for interoperability;
- to allow the reuse of element among functional areas; and
- to facilitate data interchange.
Main elements types are:
- model elements;
- data elements;
- messages.
6.2 Structure
The “Data Dictionary” is designed to provide a structural framework that enables continued growth and
enhancement of the scope of defined UML models and data elements. Rationale for this requirement is
that it is difficult, when defining the scope of a proposed system, to fully define the application domain and
all included interoperability related data. In addition, functional requirements will expand over time.
6.2.1 Data elements
The general purpose of the Data Dictionary is to define all data objects which are needed for
interoperability in the functions "freight" and "passenger" as specified by the corresponding TSIs for
interoperability. These objects will be exchanged according to the basic communication architecture as
given in "standardisation of communication procedures", Bibliography [9] , 6.4.2001, by the means of
interfaces specified in this document.
Data Dictionary provides full definition of a data element, along with its essential attributes at conceptual
level. In this context, data are limited to basic information elements, which are necessary to define
standard messages required for interoperability, and handled on the interfaces of the communicating
entities.
Only objects which can be found in the Data Dictionary can be exchanged in an interoperable fashion.
But, just defining the data objects without a reference to the associated semantic meaning does not yield
in interoperability. Therefore the complete modelling approach needs to be considered.
6.2.2 Shared registry for system units
See 5.8.2.1.2.
CLC/TR 50501-1:2007 – 40 –
6.2.3 Models
UML models may be stored and manipulated with the support of model repositories. A model repository is
a (possibly distributed) component that stores models (persistently) and provides access to these models
through well-defined interfaces. Model repositories are considered, only for the purpose of this document,
as parts of the “Data Dictionary”.
6.3 Requirements for management of the Data Dictionary/model repository
The “Data Dictionary/model repository” has to be managed and operated by a single entity.
Object Management Group (OMG), is dedicated to setting vendor-neutral software standards, and
enabling distributed enterprise-wide interoperability. One of the OMG standards is the MOF, or Meta-
Object Facility, which defines a standardized repository for meta-data such as definitions of data types or
UML models.
The XML Metadata Interchange (XMI) is used as a standard interchange mechanism between various
tools, different model repositories and middleware platforms. It defines how XML tags are to be used to
represent models in XML.
A Software Engineering tool is necessary to manage the Data ictionary/model repository. Compliance
with Object Management Group MOF standard is required. Currently, some UML-tools use such
repositories with standardized interfaces.
The following text is extracted from a UIC/EDIFER document: “Strategy and initial actions for the UIC’s
standardised use of XML in electronic commerce” (Bibliography [6], and suits also well for our purposes:
WHAT SHOULD BE DONE TO STANDARDISE THE USE OF XML MESSAGES?
In order to exchange information in a standardized way, it is recommended to use:
- a repository of terms that have a commonly accepted meaning and are used in messages. This does
not exclude other terms that one might consider as belonging to a specific environment (sectorial
and/or company). In this case, it is also important to have a repository of specific terms;
- a repository describing the structures of messages exchanged (diagrams containing the tree of
information fragments, the names of the different tags, specific constraints, etc.);
- a repository describing the modelling of the business processes (i.e. possible sequences of
messages exchanged between partners with the succession of messages exchanged (sequential,
event-driven) for each of these interactions);
- a repository containing conditions to be satisfied for a partner to be registered in one of these

interactions;
- a common approach to the structure of an interchange (series of messages transmitted on a single

occasion), as regards the distribution of the various messages transmitted (presence of the content
in the interchange, or a pointer to a file located on a specific web site indicated, or parameters for the
interpretation of a sub-unit by a standard application, etc.);
- a common approach targeting standard use of the possibilities offered by Internet (in the broad
sense of the term), without, however, giving preference to certain actors (for example, one should
not base everything on the capabilities on Microsoft’s Internet Explorer browser, even if it is the most
commonly used);
- an organisation offering strict control of the application of rules concerning the aforementioned
points, rules that still must be defined. Needless to say, this organisation must have a high level of
recognition.
– 41 – CLC/TR 50501-1:2007
Annex A
(informative)
Related works
This annex gives information on related standardisation works in the transport domain.
A.1 ISO TC204 WG1 Architecture, taxonomy and terminology
This Working Group is producing standards for developing data dictionaries and data element
registration, the methodology is to be adopted by the other ISO TC 204 Working Groups. Scope is road
traffic.
WG1 have produced a standard that identifies 32 fundamental services within the Transport Information
Control Systems (TICS).
Architecture standards are being produced that define then fundamental services using Unified Modelling
Language (UML).
WG1 has a sub Working Group which has been formed to provide a European input into the ISO work,
this sub Working Group has links with the Karen project.
CEN TC278 WG13 Architecture and Terminology. Work items are led by ISO:
- terminology and glossary of terms;

- reference model architecture;
- data modelling for TICs (Traffic Information Control system).
A.2 Technical Specification for Interoperability: "Telematic Applications for

Freight Services" Subsystem
Care has been taken in this report to avoid overlap and maintain consistency with this TSI, because some
similarities exist between the two scopes. However it is to be noted that the present version of this TSI (as
approved by Article 21 committee). Telematic Applications subsystem has no interface with rolling stock.
The scope of this TSI the Telematic Applications Subsystem for freight.
Of particular interest for our purposes is the Chapter 4: Characterisation of the subsystem. This chapter
establishes the functional and technical specifications to be met by the subsystem and its interfaces vis-à-
vis other subsystems.
Regarding functional specification
The following is a sample of two functions, with possible future interface with rolling stock, and their
defined messages:
4.2.3 Train Preparation

4.2.3.1 General Remarks
4.2.3.2 Train Composition message
4.2.3.3 Train Accepted message
4.2.3.4 Train not Suitable message
4.2.3.5 Train Ready message
CLC/TR 50501-1:2007 – 42 –
4.2.3.6 Train Position message

4.2.3.7 Train at Start message
4.2.3.8 Train Running Information
4.2.6 Train Location

4.2.6.2 Enquiry about the Train Running messages
4.2.6.3 Enquiry about the train delay / performance messages
4.2.6.4 Enquiry about Train Identifier messages
4.2.6.5 Enquiry to IM about the Train Forecast messages
4.2.6.6 Enquiry to IM about Trains at Reporting Location messages
Mandatory specifications accompanying the CR Telematic Applications for freight TSI are:
- data definitions and messages;

- the infrastructure data and the rolling stock data;
- the consignment note data and description;
- the train path data and description;
- figures and sequence diagrams of the messages.
The following paragraphs are of interest four our scope:
Regarding the Interfaces
4.3.3 Interfaces with the rolling stock subsystem
The subsystem Telematic Applications for freight identifies the technical and operational data, which must
be available for the rolling stock.
The rolling stock TSI specifies the characteristics of a wagon. If the characteristics change for a wagon,
this must be updated in the Rolling Stock Reference Databases within the normal maintenance process
for the database. Thus there is no direct interface exists between this Telematic Application TSI and the
TSI for rolling stock.
Regarding communication:
4.2.14 Networking & Communication
4.2.14.1 General Architecture
This subsystem (Telematic Applications for freight services) will see, over time, the growth and interaction
of a large and complex Telematic rail interoperability community with hundreds of participating actors
(RUs, IMs...), which will compete and/or co-operate in serving the market’s needs.
The Network & Communication infrastructure supporting such rail interoperability community will be
based on a common Information Exchange Architecture, known and adopted by all participating actors.
The proposed Information Exchange Architecture:
- is designed to reconcile heterogeneous information models by semantically transforming the data

that is exchanged between the systems and by reconciling the business process and application-
level protocol differences;
– 43 – CLC/TR 50501-1:2007
- has minimum impact on the existing IT architectures implemented by every actor;

- safeguards IT investments made already.
The Information Exchange Architectures favours a mostly Peer-to-Peer type of interaction between all
actors, while it guarantees the overall integrity and consistency of the rail interoperability community by
providing a set of centralised services.
4.2.14.2 Network
Networking in this case means the method and philosophy of communication and does not mean the
physical network.
Rail interoperability is based on a common Information Exchange Architecture, known and adopted by all
participants, thus encouraging and lowering barriers for new entrants, especially customers.
Over the public Internet network it is possible to implement a hybrid Peer-to-Peer model with a central
repository and a common interface at each actors’ node.
The central repository is approached first to obtain meta-information, such as the identity of the peer
(actor) on which some information is stored, or to verify security credentials. Afterwards, a Peer-to-Peer
communication is performed between involved actors.
4.2.14.3 Protocols
Only protocols belonging to the full Internet Protocol suite must be used.
Regarding the Data Dictionary:
4.2.14.6 Central repository
The central repository must be able to handle:
- metadata – structured data describing the content of messages;

- Public Key Infrastructure (PKI);
- Certification Authority (CA);
- directory (“phonebook”) – it contains all needed information about the participating actors for
exchanging messages.
The management of the central repository should be under the responsibility of a non-commercial co-
european organisation.
4.4.2 Operating the central repository
The functions of the central repository are defined in 4.2.14.6 (central repository). For data quality
assurance purposes, the entity operating the central repository should be responsible for the updating
and the quality of the metadata and the directory, and also for the administration of the access control
(public keys). Regarding the quality of the metadata a percentage of 100 % must be reached for
completeness, consistency, timeliness and accuracy.
CLC/TR 50501-1:2007 – 44 –
Annex B
(informative)
Functional addressing in railway specifications
B.1 UIC Leaflet 556 functional addressing
In the Leaflet UIC 556, functional addressing is based on a user view of a train architecture, considering
“the actual train composition, this means the vehicles present in the train with their special properties”.
For independence of internal vehicle structure, information is exchanged between functions. This
provides for “a clear interface between the train bus node and the vehicle internal structure” All
considered functions, are given function addresses, which is made in UIC Leaflet 556 by numbering
functions in a standard way. A function is identified by 2 digits, 1 to 21 being presently allocated. Number
22 to 99 are reserved (see Bibliography [8]).
Vehicle are identified by their “UIC address”, corresponding to the vehicle sequence established after UIC
inauguration. A functional address is then by defined by two numbers: a UIC address (or a group), and a
function address. Functional addresses for source and target are included in E-telegram messages.
This functional addressing scheme is established after UIC inauguration, and may change after each new
inauguration.
B.2 GSM-R functional addressing
It may be interesting to compare LL556 scheme with the one defined in the UIC project GSM-R, as these
two schemes, both based on association of a vehicle and a train function, are overlapping.
Functional addressing is the GSM-R feature that allows calling users by their Functional Number, where
Functional Numbers identify both functions and applications. From a logical point of view EIRENE system
can be seen as a set of applications/functions running over a number of physical terminations. Every
application/function makes use of a basic telecommunication service (bearer service or teleservice). One
physical termination can be either a mobile terminal or a support of a mobile terminal. A Functional
Number identifies the user's function rather than the number of its terminal; for instance a certain
functional number identifies the driver of a certain train and not the number of the phone of the cab radio
installed in the locomotive.
This feature guarantees the independence of the number known to the user from the physical terminal
used to answer.
GSM-R addressing plan identify three “rolling stock” objects:
- “train”, a dynamic object identified by the “train running number”, which is “alive” only during a
specific mission;
- “engine”, a static object, identified by the “engine number”, derived from the UIC ID;
- “coach”, a static object, identified by the “coach number”, derived from the UIC ID.
Each kind of object has its own syntax for the functional address, defined by the field CT (for a train,
CT=2, an engine, CT=3, a coach, CT=4.
“Function addresses” are also standard, and coded by 2 digits (but not like in LL556).
– 45 – CLC/TR 50501-1:2007
A sample is given below:
UIC LL556 UIC GSM-R

Intercom Not defined 07
Public address 12 08
Diagnostics 09 51
Train protection 17 40 (ERTMS/ETCS)
Train data bus 21 52 (Train data bus)
EXAMPLE
A dispatcher, equipped with a GSM-R terminal, needs to send an text message to be seen by passenger
of a given coach identified by its coach number. This person may not know in which train the coach is.
He/she then make a phone data call, by dialling: 4 <Coach number> 61 (Function 61 being “displayed
passenger information unit”).
This call is received by a cab radio, the target functional number is also transmitted, to allow the cab radio
to route the message, to the coach display, (via the appropriate train bus, after translation of the UIC
GSM-R address into UIC LL556 address, with a difficulty for the coach number which has not the same
coding).
GSM-R functional addressing is more flexible:
- different categories of functional number possible;

- train level (dynamic identification) and vehicle level (permanent identification);
- a GSM-R functional number is mapped to a GSM-R telephone number (MSISDN) by explicit
registration and deregistration operations;
- inside the train, each device could also make a “registration” through the cab radio.
CLC/TR 50501-1:2007 – 46 –
Annex C
(informative)
Process of function class decomposition
Deriving a functional decomposition is an iterative process. A top-down approach is adopted to

decompose a system while simultaneously identifying and grouping classes into functional modules. Each
module represents a specific functionality. The Function-Class Decomposition Procedure, described
below, summarises this iterative process:
a) specify high-level requirements and their related use-cases, referring to the Reference Architecture
in Clause 4;
b) use requirements and use-cases to identify an initial set of classes that fulfil the basic high-level
requirements. Use UML notation to represent these classes within the functional model;
c) within each functional model, observe responsibilities and collaborations of each class and place
classes into the subgroups that appear to maximise internal cohesion and minimise external
coupling. Express collaboration and responsibilities in UML interaction diagrams. Interaction
diagrams are models that describe how groups of objects collaborate in some behaviour;
d) develop use-case diagrams for each functional model. Select key scenarios and analyse their paths
to assess each subgroup’s cohesion and coupling. Rearrange classes within the subgroups to
minimise external coupling and maximise internal cohesion, if necessary;
e) for each group of classes, form a functional model at the next hierarchy level and name it
meaningfully. Each new functional model will initially contain only the classes grouped together at the
previous level;
f) allocate to each new functional model the requirements and scenarios it can completely fulfil.
Inferred requirements and use-cases that span functional models at the new level should remain
attached to the parent functional model;
g) for each functional model at the new level, analyse and refine the requirements and use-cases
allocated to the module, using them to identify additional classes;
h) repeat steps c) through g) until the system requires no further decomposition, usually after all
relevant functions have been identified. We are interested in interoperable entities: the
interoperability aspect stops the decomposition of an entity up to a point that best represents an
interoperable element;
i) generate UML class diagrams for each leaf node. Once the class diagrams are generated, additional
support classes may be added;
j) Starting at the lowest level of the hierarchy, use scenarios allocated to the functional model to define
functional model interfaces. Move up the hierarchy systematically, considering only the intermediate-
level functional models with child modules that have already defined class diagrams. Continue the
process until it reaches the high-level functional model. At this stage, the entire system is integrated.
NOTE The description of the above process is drawn from a document prepared by the Euromain project (Bibliography [17]).
– 47 – CLC/TR 50501-1:2007
Bibliography
This bibliography gives a non-exhaustive list of International Standards and relevant documents that may
help understanding the basic concepts that are used in this Technical Report.
[1] Specification of the Dynamic Passenger Information System (DPIS), TrainCom Internal code: TC1-D-
BTG-021-07, 02/07/03.
[2] Multi-faceted Datatype Specification for XML Schemas, Frank Olken and John McCarthy, 5 March
1999.
[3] ISO 8879:1986, Standard Generalized Markup Language.
[4] IEEE Std 1489:1999, IEEE Standard for Data Dictionaries for Intelligent Transportation Systems.
[5] Gamma E., Helm R., Johnson R., and Vlissides J., Design Patterns, Addison-Wesley Publishing Co.,
1995; ISBN: 0201633612.
[6] “Strategy and initial actions for the UIC’s standardised use of XML in electronic commerce”,
UIC/EDIFER document, 15 March 2001.
[7] UIC/XML working group “Best practices” document, 12 August 2002.
[8] UIC leaflet 556: Information transmission in the train (train-bus), 4th edition, August 2005.
[9] SC9XB_SGB1_proposal_report (sec) 174.doc- Proposal for new standardisation work for
interoperability, April 2001.
[10] EIRENE Functional Requirements Specification, Version 6, February 2004.
[11] EIRENE System Requirements Specification, Version 14, February 2004.
[12] MORANE FFFS for Functional Addressing, Version 3, August 2000.
[13] MORANE FIS for Functional Addressing, Version 4, September 2000.
[14] UIC Leaflet 557 - Diagnostics on passenger rolling stock - 2nd edition of 01.01.98.
[15] UIC Leaflet 647 - Functional model for the remote control of power cars (EU-Remote-Control)
1st edition, March 2006.
[16] UIC Leaflet 652 - Diagnostics on railway vehicles with traction functionality (in preparation).
[17] Proposal for Functional Standardisation Modeling using UML and XML - EuroMain internal code:
ERM-T-FAR-004-03, March 2003.
PD CLC/TR
50501-1:2007
BSI — British Standards Institution
BSI is the independent national body responsible for preparing
British Standards. It presents the UK view on standards in Europe and at the
international level. It is incorporated by Royal Charter.
Revisions
British Standards are updated by amendment or revision. Users of
British Standards should make sure that they possess the latest amendments or
editions.
It is the constant aim of BSI to improve the quality of our products and services.
We would be grateful if anyone finding an inaccuracy or ambiguity while using
this British Standard would inform the Secretary of the technical committee
responsible, the identity of which can be found on the inside front cover.
Tel: +44 (0)20 8996 9000. Fax: +44 (0)20 8996 7400.
BSI offers members an individual updating service called PLUS which ensures
that subscribers automatically receive the latest editions of standards.
Buying standards
Orders for all BSI, international and foreign standards publications should be
addressed to Customer Services. Tel: +44 (0)20 8996 9001.
Fax: +44 (0)20 8996 7001. Email: orders@bsi-global.com. Standards are also
available from the BSI website at http://www.bsi-global.com.
In response to orders for international standards, it is BSI policy to supply the
BSI implementation of those that have been published as British Standards,
unless otherwise requested.
Information on standards
BSI provides a wide range of information on national, European and
international standards through its Library and its Technical Help to Exporters
Service. Various BSI electronic information services are also available which give
details on all its products and services. Contact the Information Centre.
Tel: +44 (0)20 8996 7111. Fax: +44 (0)20 8996 7048. Email: info@bsi-global.com.
Subscribing members of BSI are kept up to date with standards developments
and receive substantial discounts on the purchase price of standards. For details
of these and other benefits contact Membership Administration.
Tel: +44 (0)20 8996 7002. Fax: +44 (0)20 8996 7001.
Email: membership@bsi-global.com.
Information regarding online access to British Standards via British Standards
Online can be found at http://www.bsi-global.com/bsonline.
Further information about BSI is available on the BSI website at
http://www.bsi-global.com.
Copyright
Copyright subsists in all BSI publications. BSI also holds the copyright, in the
UK, of the publications of the international standardization bodies. Except as
permitted under the Copyright, Designs and Patents Act 1988 no extract may be
reproduced, stored in a retrieval system or transmitted in any form or by any
means – electronic, photocopying, recording or otherwise – without prior written
permission from BSI.
This does not preclude the free use, in the course of implementing the standard,
of necessary details such as symbols, and size, type or grade designations. If these
details are to be used for any other purpose than implementation then the prior
BSI written permission of BSI must be obtained.
389 Chiswick High Road Details and advice can be obtained from the Copyright & Licensing Manager.
London Tel: +44 (0)20 8996 7070. Fax: +44 (0)20 8996 7553.
Email: copyright@bsi-global.com.
W4 4AL

PD CLC TR 50501-1

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

PD CLC TR 50501-1

Uploaded by

Copyright:

Available Formats

PUBLISHED DOCUMENT PD CLC/TR

ICS 35.240.60; 45.020; 45.060.10

This Published Document was published by BSI. It is the UK implementation

This Published Document was Amendments issued since publication

ISBN 978 0 580 52930 6

ICS 35.240.60; 45.020

Applications ferroviaires – Bahnanwendungen –

This Technical Report was approved by CENELEC on 2007-01-01.

Central Secretariat: rue de Stassart 35, B - 1050 Brussels

Ref. No. CLC/TR 50501-1:2007 E

Survey Group SC9XB/SGB1 conclusions

- STD1: data dictionary and rules for functional standardisation;

- STD 2: functions in freight traffic (for a selected set of functions);

- STD 3: functions in passenger traffic (for a selected set of functions);

- STD 4: standardisation of communications procedures.

The Trans-European conventional rail system

Examples of functions to be standardised

1) Dynamic passenger information system. Refer to [14], a contribution of TrainCom European

Two alternative solutions are

6) Train integrity (completeness of train)

7) Establishing and distributing time and date

8) Establishing and distributing speed

This Technical Report will define

- the Reference Architecture defining the essential functional interfaces,

3 Terms and definitions

Reasons to build models include the following:

4.2 Reference Architecture concept

- the rail business,

Two levels of architecture definitions are commonly used:

4.3 Requirement for the STD1 Reference Architecture definition

For those purposes, the following requirements are:

1) it should be possible to describe a system as a composition of independent components and

4.4 Interacting objects

4.4.1 Rolling stock entities

Three different categories of classes are distinguished:

Category 1: Classes corresponding to rolling stock structural subsystems

Category 2: Classes corresponding to devices measuring properties at train level

- time and date reference,

4.4.1.1 Train class

4.4.1.2 Consist class

Consist level functions are usually distributed in the vehicles.

- subset of “technical functions”: traction, braking, energy;

4.4.1.3 Single vehicle

4.4.1.4 Master clock device and clock synchronisation

For new systems only:

A tightly coupled domain, in the scope of this document, is typically:

- a train, with one or more consist(s);

Orders of magnitude for clock synchronisation precision are:

4.4.1.5 Location determination device

Device providing continuously location (or train position) data.

Location information is used by several functions such as:

- tracking (for ground based information system);

ETCS on board subsystem could also be a source of location information.

4.4.1.6 Speed Measurement Unit

ETCS on board subsystem could also be a source of speed information.

Several categories will be defined, corresponding to different performance characteristics.

- accuracy, with confidence interval;

4.4.1.7 Man Machine Interface

4.4.2 Interfaces between rolling stock entities.

The interfaces considered in this architecture are described below.

4.4.2.1 Train level to consist interface (interface B)

This is a dynamic interface, point-to-point, established during the train inauguration.

4.4.2.2 Train level to ground application interface (interface C-Train)

4.4.2.3 Consist level to ground application interface (interface C-Consist)