CLC/TR 50501-1:2007

SLOVENSKI STANDARD
01-oktober-2007
Železniške naprave - Vozna sredstva – Medsebojna izmenjava podatkov med
napravami na železniških vozilih ali med njimi in stabilnimi progovnimi napravami
– 1. del: Slovar podatkov in pravila funkcionalne standardizacije
Rolling stock - Intercommunication between vehicles and train/wayside -- Part 1: Data
dictionary and rules for functional standardisation
Bahnanwendungen - Bahnfahrzeuge - Datenaustausch zwischen Fahrzeugen bzw.
Zug/Strecke -- Teil 1: Datenkatalog und Regeln für die funktionale Standardisierung
Applications ferroviaires - Matériel roulant - Communications entre véhicules et
communications sol/train -- Partie 1: Dictionnaire de données et regles pour la
standardisation fonctionnelle
Ta slovenski standard je istoveten z: CLC/TR 50501-1:2007
ICS:
35.240.60 Uporabniške rešitve IT v IT applications in transport
transportu in trgovini and trade
45.060.01 Železniška vozila na splošno Railway rolling stock in
general
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

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

Matériel roulant –  Bahnanwendungen –
Communications entre véhicules Interkommunikation zwischen Fahrzeugen
et communications sol/train – und Fahrweg –
Partie 1: Dictionnaire de données Teil 1: Datenwörterbuch und Regeln
et règles pour la standardization für die funktionale Normung
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

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

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.

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

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

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;

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…
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:

- 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.
- 17 - CLC/TR 50501-1:2007
Train (4 consists)
Consist 3 (trainset)
Consist 1 (locomotive) Consist 2 (1 vehicle) Consist 4 (2 vehicles)
(B4) radio
(B3) wire
(B2) wire
D
(B1) wire
r
CFM-1 CFM-3
CFM-4
CFM-2
TFM
i
(A) (A)
(A)
v
(A)
e
r
(C-Train)
Vehicle elements
(C-Consist)
(C-Consist)
(D)
TFM Train Functional Module
(D)
(D)
Fixed
CFM Consist Functional Module
installations
Vehicle element
Figure 1 – Reference Architecture: Relation cases in the functional communication architecture

4.4.3 External entities interacting with rolling stock entities
T
...