SIST-TP CLC/TR 50501-1:2007
(Main)Railway applications - Rolling stock - Intercommunication between vehicles and train/wayside -- Part 1: Data dictionary and rules for functional standardisation
Railway applications - Rolling stock - Intercommunication between vehicles and train/wayside -- Part 1: Data dictionary and rules for functional standardisation
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, alongwith 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.
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 règles pour la standardisation fonctionnelle
Ž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
General Information
Standards Content (Sample)
SLOVENSKI STANDARD
SIST-TP CLC/TR 50501-1:2007
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
SIST-TP CLC/TR 50501-1:2007 en
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
---------------------- Page: 1 ----------------------
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
---------------------- Page: 2 ----------------------
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.
__________
---------------------- Page: 3 ----------------------
- 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
---------------------- Page: 4 ----------------------
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,
---------------------- Page: 5 ----------------------
- 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.
---------------------- Page: 6 ----------------------
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.
---------------------- Page: 7 ----------------------
- 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
---------------------- Page: 8 ----------------------
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.
---------------------- Page: 9 ----------------------
- 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
---------------------- Page: 10 ----------------------
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.
---------------------- Page: 11 ----------------------
- 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;
---------------------- Page: 12 ----------------------
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
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.