X2R2-WP6-D-BTS-051-01 - System Requirements Specification (SRS) For Integration Layer

X2Rail-2
Project Title: Enhancing railway signalling systems based on train

satellite positioning, on-board safe train integrity,
formal methods approach and standard interfaces,
enhancing traffic management system functions
Starting date: 01/09/2017
Duration in months: 36
Call (part) identifier: H2020-S2RJU-CFM-IP2-01-2017
Grant agreement no: 777465
Deliverable D6.1
System Requirement Specification (SRS) for the
Integration Layer
Due date of deliverable Month 30

Actual submission date DD-MM-YYYY
Organization name of lead contractor for this deliverable SIE
Dissemination level PU
Revision Draft
Deliverable template version: 05 (13/02/18)

X2Rail-2 Deliverable D6.1
System Requirement Specification (SRS) for the Integration Layer
Authors
Author(s) INDRA Sistemas S.A. (INDRA)

Ana Alves Pires
Carlos Montón Gómez
José Antonio Sánchez Pérez
Javier Monje Rubio
Contributor(s) Hitachi Rail STS (STS)
Giusy Formato
Giuseppe Gotelli
Gian Luigi Zanella
CAF Signalling
Laura González Suarez
Carlos Sicre Vara de Rey
Carlos Montón Gómez
AŽD (AZD)
Michal Žemlička
Martin Bojda
Bombardier Transportation (BTSE)
Roland Kuhn
José Luis Miguens
Zbigniew Dyksy
Deutsche Bahn (DB)
Renato Rodrigues
HaCon (HC)
Rolf Gooßmann
Mahnam Saednia
SIEMENS (SIE)
Stefan Wegele
Network Rail (NR)
Imtithal Aziz
Trafik Verket (TRV)
Anna-Maria Östlund
Peter Olsson
Thales (THA)
Christoph Buecker
Cem Ormesher Hussein
Allan Young
1 EXECUTIVE SUMMARY
The overall aim of the X2Rail-2 project is to set the foundation for a resilient, cost-efficient, high
capacity and digitalised European rail network.
A key enabler for innovative solutions in TMS market is an evolutionary shift of the TMS
architecture from single vendor solutions with proprietary interfaces towards frameworks running
multivendor services according to micro-service architecture.
One main aspect for integration of multivendor services is standardized access to the data. The
Integration Layer providing a standardized high-performance communication platform for data
management and distribution covers this. In the evolution, process to multi-vendor TMS this
platform represents the inevitable component. A TMS setup with just several components can be
managed manually and deployed on separated hardware.
This document, Deliverable D6.1 System Requirement Specification (SRS) for the Integration
Layer is focused on the review of the functional and non-functional Requirements for Integration
Layer stated within the In2Rail project (http://www.In2Rail.eu/), and the identification of the
required data structures for allowing the integration of the real-time traffic management operations.
Deliverable D6.1 is the result of the activities performed in the Task 6.2 Integration Layer, led by
INDRA and with active participation of the following partners: STS, AZD, BTSE, CAF, DB, HC,
NR, SIE, TTS and TRV.
Task 6.2 comprises the works to specify and to start the development of the communication
backbone of the Rail Operations System - the Integration Layer (IL).
Based on the results of In2Rail WP8 the functional and non-functional requirement specification
addressing Data Structures, Data Management processes and Interfaces able to integrate real-
time status and forecast data from sub-systems and applications like the Railway Infrastructure,
trains, CCS, Systems for Passenger Information, Fleet Management, Staff Management and
Weather Monitoring were specified collaboratively by the partners.
Included in the scope of this document is the evaluation of state of the art “Middleware” to allow
the partners to start the design of their proposed complementing prototypes of constituents or
processes of the Integration Layer within X2Rail-2 project.
GA 777465 Page 3 of 197

2 TABLE OF CONTENTS
1 EXECUTIVE SUMMARY ................................................................................................................................... 3
2 TABLE OF CONTENTS ...................................................................................................................................... 4
3 ABBREVIATIONS AND ACRONYMS ................................................................................................................. 7
4 BACKGROUND ............................................................................................................................................... 9
5 OBJECTIVE / AIM .......................................................................................................................................... 10
AIM .............................................................................................................................................................. 10
DOCUMENT STRUCTURE ................................................................................................................................... 10
SCOPE ........................................................................................................................................................... 11
6 REQUIREMENTS FOR THE INTEGRATION LAYER ........................................................................................... 12
FUNCTIONAL PURPOSE OF THE INTEGRATION LAYER ............................................................................................... 12

NON-FUNCTIONAL REQUIREMENTS ..................................................................................................................... 12
6.2.1 Communication ...................................................................................................................................... 12
6.2.2 Availability .............................................................................................................................................. 13
6.2.3 Quality of Service (QoS) .......................................................................................................................... 14
6.2.4 IT Management ...................................................................................................................................... 14
6.2.5 Implementation of IL .............................................................................................................................. 14
FUNCTIONAL REQUIREMENTS............................................................................................................................. 15
6.3.1 Security & Accounting ............................................................................................................................ 15
6.3.2 Data Access Patterns .............................................................................................................................. 16
6.3.3 Messaging .............................................................................................................................................. 16
7 MIDDLEWARE STATE OF THE ART EVALUATION ........................................................................................... 18
MIDDLEWARE ASSESSMENT CRITERIA .................................................................................................................. 18

MIDDLEWARE PRODUCTS SELECTION................................................................................................................... 20
EVALUATION RESULTS ...................................................................................................................................... 21
7.3.1 Comparison of Middleware Products ..................................................................................................... 21
7.3.2 Weaknesses and Strengths of analysed Middleware Products .............................................................. 21
EVALUATION CONCLUSIONS ............................................................................................................................... 31
8 DATA STRUCTURES ...................................................................................................................................... 34
INFRASTRUCTURE............................................................................................................................................. 36
8.1.1 Topology ................................................................................................................................................. 37
8.1.2 Positioning .............................................................................................................................................. 39
8.1.3 Line / track section ................................................................................................................................. 39
8.1.4 Route body ............................................................................................................................................. 40
8.1.5 Point ....................................................................................................................................................... 41
8.1.6 Signal ...................................................................................................................................................... 42
8.1.7 Operational control point ....................................................................................................................... 43
8.1.8 Bridge ..................................................................................................................................................... 43
GA 777465 Page 4 of 197

8.1.9 Tunnel ..................................................................................................................................................... 44
8.1.10 Embankment ...................................................................................................................................... 44
8.1.11 Level crossing ..................................................................................................................................... 45
8.1.12 Station ................................................................................................................................................ 46
TRAFFIC MANAGEMENT SYSTEM (TMS): TRAINS................................................................................................... 48
8.2.1 Data ........................................................................................................................................................ 48
8.2.2 Requests ................................................................................................................................................. 73
8.2.3 Alarms .................................................................................................................................................... 76
8.2.4 Data Received from External Systems .................................................................................................... 79
TRAFFIC MANAGEMENT SYSTEM (TMS): ROUTING................................................................................................ 80
8.3.1 Data ........................................................................................................................................................ 80
8.3.2 Requests ................................................................................................................................................. 80
8.3.3 Alarms .................................................................................................................................................... 81
8.3.4 Data Received from External Systems .................................................................................................... 82
TRAFFIC MANAGEMENT SYSTEM (TMS): TEMPORARY SPEED RESTRICTIONS ............................................................... 82
8.4.1 Data ........................................................................................................................................................ 82
8.4.2 Requests ................................................................................................................................................. 83
8.4.3 Alarms .................................................................................................................................................... 85
CONFLICTS ..................................................................................................................................................... 86
8.5.1 Data ........................................................................................................................................................ 86
8.5.2 Conflict definition ................................................................................................................................... 86
8.5.3 Conflict resolution .................................................................................................................................. 87
8.5.4 Railway specific examples ...................................................................................................................... 88
8.5.5 Conflict management module ................................................................................................................ 90
POSSESSIONS .................................................................................................................................................. 91
8.6.1 Data ........................................................................................................................................................ 91
8.6.2 Requests ................................................................................................................................................. 97
8.6.3 Alarms .................................................................................................................................................... 99
8.6.4 Data Received from External Systems .................................................................................................. 100
INTERLOCKING .............................................................................................................................................. 100
8.7.1 Data ...................................................................................................................................................... 100
8.7.2 Requests ............................................................................................................................................... 108
8.7.3 Alarms .................................................................................................................................................. 113
RADIO BLOCK CENTRE (RBC)........................................................................................................................... 114
8.8.1 Data ...................................................................................................................................................... 114
8.8.2 Requests ............................................................................................................................................... 115
8.8.3 Alarms .................................................................................................................................................. 116
8.8.4 Data Received from External Systems .................................................................................................. 116
TRACKSIDE AUTOMATIC TRAIN OPERATION (ATO) .............................................................................................. 117
8.9.1 Data ...................................................................................................................................................... 117
ENERGY GRID ............................................................................................................................................... 140
8.10.1 Data ................................................................................................................................................. 141
FLEET & CREW .............................................................................................................................................. 144
8.11.1 Data ................................................................................................................................................. 144
GA 777465 Page 5 of 197

8.11.2 Requests ........................................................................................................................................... 162
8.11.3 Data Received from External Systems.............................................................................................. 162
ASSET MANAGEMENT .................................................................................................................................... 163
8.12.1 Data ................................................................................................................................................. 163
DRIVER ADVISORY SYSTEM (DAS) .................................................................................................................... 168
8.13.1 Data ................................................................................................................................................. 168
PASSENGER INFORMATION SYSTEMS (PIS) ......................................................................................................... 188
8.14.1 Data ................................................................................................................................................. 188
8.14.2 Alarms .............................................................................................................................................. 188
PUBLIC WEATHER INFORMATION SERVICES......................................................................................................... 191
8.15.1 Data ................................................................................................................................................. 191
8.15.2 Alarms .............................................................................................................................................. 192
9 REFERENCES................................................................................................................................................193
APPENDIX A: COMPARISON OF MIDDLEWARE PRODUCTS ........................................................................................... 194

APPENDIX B: OWNERSHIP OF RESULTS .................................................................................................................... 197
GA 777465 Page 6 of 197

3 ABBREVIATIONS AND ACRONYMS
Abbreviation / Acronyms Description

AF Application Framework
API Application Programming Interface
ARS Automated Route Setting
ATO Automatic Train Operation
ATP Automatic Train Protection
CCS Control Command System
CTC Centralized Traffic Control
CDM Canonical Data Model
DAS Driver Advisory System
EIP Enterprise Integration Patterns
EOA End Of Authority
ERTMS European Rail Traffic Management System
ESB Enterprise Service Bus
ETCS European Train Control System
FOD Fallen Object Detector
GNSS Global Navigation Satellite System
GRASP General Responsibility Assignment Software Patterns
IMDG In Memory Data Grid
IL Integration Layer
ILX Interlocking
IP Innovation Programme
JP Journey Profile
JSON JavaScript Object Notation
KMS Key Management System
MA Movement Authority
MOM Message Oriented Middleware
MTBF Mean Time Between Failures
MTTR Medium Time To Repair
OCP Operational ControlPoint
PICOP Personal In Charge Of Possession
PIS Passenger Information System
QoS Quality of Service
RBC Radio Block Centre
SIL Safety Integrity Level
SQL Structured Query Languaje
SLA Service Level Agreement
SRS System Requirement Specification
STR Status Report
SP Segment Profile
SSP Specific Speed Profile
TCP Transmission Control Protocol
GA 777465 Page 7 of 197

TD Technical Demonstrator
TMS Traffic Management System
TP Train Position (169)
TSR Temporary Speed Restriction
UDP User Datagram Protocol
UIC Union Internationale des Chemins de Fer
UTC Universal Time Coordinated
UUID Universally Unique Identifier
VM Virtual Machine
VPC Virtual Private Cloud
GA 777465 Page 8 of 197

4 BACKGROUND
The present document constitutes the first issue of Deliverable D6.1 “System Requirement
Specification (SRS) for the Integration Layer” in the framework of the Project titled “Enhancing
railway signaling systems based on train satellite positioning, on-board safe train integrity, formal
methods approach and standard interfaces, enhancing traffic management system functions”
(Project Acronym: X2Rail-2; Grant Agreement No 777465).
This document covers the Integration Layer requirements review and it is mainly focused in the
identification of the required information to be available on the Integration Layer for the Traffic
Management functionalities. This information is divided into data provided by the Traffic
Management functions and the rest of involved systems, the available requests and the generated
alarms.
The specified data structures have been identified and reviewed by all the partners in this task
with the goal of detecting all the information required, but also with the goal of covering the systems
or functions which shape the proofs of concepts and prototypes to be defined within this Work
Package WP6 of the X2Rail-2 project.
GA 777465 Page 9 of 197

5 OBJECTIVE / AIM
Aim
The objective of this deliverable is to continue with the Integration Layer specification based on
the works previously performed in the In2Rail project.
After the first approach to the Integration Layer requirements, the selection of the In Memory Data
Grid principals and the first guidelines to the API required to be exposed by the Integration Layer,
the works performed in the Task 6.2 and included in this document aim at achieving the followings
goals:
• To review the initially identified Integration Layer requirements according to the technological
approach based on In Memory Data Grid principals.
• To detail the API requested for the Integration Layer in order to allow the integration of the
prototypes introduced in the project and to be continued and integrated during the X2Rail-4
project.
• To analyse the middleware software products available on the market in order to detect the
alignment of the market with the Integration Layer requirements.
• To identify the data to be exchanged through the Integration Layer for allowing the Traffic
Management functionalities. This topic constitutes a new step in the specification of the
Integration Layer, taking into account the needs of the business logics and setting the identified
required information to be included in the on-going Canonical Data Model from the point of
view of the Traffic Management.
Document Structure
This section describes the structure of the document, including a brief description of each chapter
for introducing the content along the deliverable.
Section Title Description
4 Background Background of the task and the alignment of the
deliverable with the goals of the project.
5 Objective / Aim Scope of the task and overview of the content of the
document.
6 Requirements for the Review and filtering of the Integration Layer
Integration Layer requirements for selecting the main requirements
aligned with the In Memory Data Grid principals and the
API specification.
7 Middleware State of the Evaluation of relevant middleware software products
Art Evaluation currently available on the market, based on the
Integration Layer requirements, including the
conclusions arisen from the exhaustive individual
analysis of each selected product and the comparison
and global evaluation among them.
GA 777465 Page 10 of 197

8 Data Structures Identification and detail of the information required to

be exchanged through the Integration Layer ordered by
system provider and classified in data generated,
requests allowed and alarms created.
It constitutes the main chapter of the deliverable and
implies the main goal achieved by the task.
Appendix A Comparison of Middleware Resume tables of the comparison of middleware
Products products on the evaluation criteria defined.
Appendix B Ownership of Results Table with the ownership of results for this deliverable
Table 5.1: Document Structure
Scope
Once analysed and defined the main functional and non-functional requirements and the
characteristics of the Integration Layer (by analysing the different middleware possibilities), the
main goal of the document is to provide a common set of data structures to be exchanged through
the Integration Layer between the different systems involved (Traffic Management, Possession
Management, Interlocking, RBC, ATO, Energy Grid, Fleet & Crew Management, Asset
Management, Driver Advisory System, Passenger Information System and Public Weather
Information) in the Traffic Management to be useful for:
• Using common data structures in the X2Rail-2 Proof of concepts to be performed individually by
each partner.
• Being the basis for the data required from the Traffic Management point of view in the Canonical
Data Model.
The identified data structures cover the exchanged data, but also the requests of commands and
the alarms notified through the Integration Layer.
• Definition of the Integration Layer API to be exposed to the systems to be connected. This API is
the basis for the future Integration Layer implementation to be used in the X2Rail-4 project and
it can be considered at the moment like a guideline for the design and testing of the systems to
be connected to the Integration Layer and for the Integration Layer itself.
Based on the identified information and outside the scope of this deliverable and task the following
topics are identified to be faced in the X2Rail-4 project and in the Canonical Data Model group:
• To split between static and dynamic data.
• To define the level of dynamism of the dynamic data, that is to say, for each dynamic data to
identify how often it is expected that this data could be modified.
• To define relations and to organise the identified data in a global schema or data tree.
• To define relations with the identified data in the framework of the Traffic Management with the
identified data in other railway frameworks.
• To unify the identification rules of the elements and the available data formats.
• To define the persistency of the data elements in the Integration Layer.
GA 777465 Page 11 of 197
6 REQUIREMENTS FOR THE INTEGRATION LAYER
Functional Purpose of the Integration Layer

The functional responsibility assigned to Integration Layer has a long process of evolution. In the
context of the Int2Rail it started 2015 as a pure communication platform for TMS applications
[In2Rail D8.1]. Later it received the responsibility for the data persistence as well [In2Rail D8.2].
This opens the way to develop stateless services on TMS supporting modern micro-service-
architectures. The Integration Layer shall ensure, that the data survive defined types of failures
and provide publish-subscribe access to the data managed.
The IT industry developed products with these two responsibilities coming from two directions:
- From communication point of view – Data Distribution Service (OMG Standard [OMG DDS])
- From NoSQL data management systems – In-Memory-Data-Grids (with various products).
In the context of In2Rail both approaches were analysed and a concept of a wrapper-API was
introduced, which shall cover specific technology and product from TMS applications [In2Rail
D8.4]. As a concept the term “In-Memory-Data-Grid” was taken as a methapher as it covers well
the assigned functionality. It is clearly stated, that any technology can be used for the
implementation of Integration Layer, as long as it fulfils the wrapper-API.
The other aspect of Integration Layer is the separation between data definition and data
management and distribution. The Wrapper-API covers only data management and distribution.
The definition of the data structures was separated into another responsibility and named
Canonical Data Model:
- Integration Layer manages data as blackboxes, without “understanding” the content of the data.
This allows usage of different products from the market for the IL-implementation.
- Canonical Data Model specifies the data structures (classes and their serialisation) managed by
the IL.
In this document both aspects of the Integration Layer are covered:

- The Integration Layer as a communication and data management system is covered by the
requirements defined in section 6. They mostly originated from [In2Rail D8.2]. In section 7
current state of the products able to cover the IL-requirements were analysed.
- The requirements on Canonical Data Model are defined in section 8
Non-Functional Requirements
6.2.1 Communication
1. Connect consumer and provider: The IL shall be able to take a service call and messages to the
end-point; i.e., to enable a service consumer to connect/interact with service providers. The
connection is by publish-subscribe pattern.
GA 777465 Page 12 of 197

2. Support of Different Transport/Application Layer (OSI) Protocols: IL shall provide the same
interface to its users, but may use different protocols to deliver messages. IL users are unaware of
how data are moved inside the IL. There is full separation between data delivery method and data
representation formats in IL from client application.
3. HTTP oriented: The IL shall also provide HTTP Interface methods.
4. Routing: The routing of Information Items from sources to destinations in respect of envisioned
messaging patterns (i.e. Publish/Subscribe, Request/Respond). The IL-clients are fully separated
from each other - no direct communication is possible - only over IL. The concept allows for a
specific IL implementation for configuration of communication routes. It is transparent to the
clients and is not part of API.
5. Route to correct provider: The IL shall be able to route requests and messages to the correct
service provider. The IL shall dispatch the request to the right service provider. A data centric
approach is selected: the services connect to standardized "service-request-topics", so the
requests are automatically routed to the service providers.
6. Dynamic end-point handling: The IL shall provide 'virtualisation', i.e. dynamic handling of end-
points (change of location of consumer and/or provider). This means that IL is in charge of
reconnecting service provider. The IL separates client application from the data transport protocol.
7. Message queuing: The IL shall be able to use message queuing to store and forward messages. A
data centric approach is selected: all messages are managed inside of IL.
8. Service registration: The IL should provide a mechanism for Service Registration. A client
application intended to provide a service registers itself at IL.
9. Service discovery : the IL provides standardized Topics for service requests: services discover
client requests, and not clients discover services and send them requests :
- Fail over: The IL should provide a mechanism for Handling failover of service instances.
Requests are managed by IL in a reliable manner. Restarting of services is transparent to the
client.
- Handling of unreliable network: The IL should provide a mechanism for handling issues
arising due to unreliable network by session management.
10. Configuration Control: The IL communications infrastructure shall be kept under configuration
control. Specific to IL implementation, the IL-API manages access control to the topics by
configuration.
11. Message integrity: The IL shall provide measures to ensure that for data messages integrity is
maintained. It can be implemented in IL-product or as part of the API-wrapper.
6.2.2 Availability
12. Availability 24x7: The operating environment hosting the IL, and the middleware part of the IL
itself, shall be designed to enable operation 24 hours a day, 365 days per year.
13. Guaranteed performance: The operating environment shall ensure that any connection to
administrative tasks or tools outside the IL environment will not compromise the IL’s performance.
14. Transmission service: The transmission part of the IL shall be capable of running continuously.
15. Switchover: The IL architecture shall provide switchover functionality in case of failure.
GA 777465 Page 13 of 197

16. Minimum unplanned unavailability [MTBF|MTTR]: The middleware part of the IL shall be capable
of running continuously.
6.2.3 Quality of Service (QoS)

17. QoS for Performance:
- Standard: It shall be possible that delivery order cannot depend on priority. (e.g. normal
FIFO queue). Instead of queues map are supported.
- Message priority: It shall be possible that delivery order can depend on the priority of each
topic message.
- Queuing policies: It should be possible that delivery order can depend on a scheduler
algorithm. Example: FIFO, LIFO, Round Robin.
18. QoS for Data Delivery:
- Guaranteed delivery: It should be possible to configure the guarantee of the delivery
among at least the following cases :
− Best effort delivery: It does not guarantee the delivery, as the topic message is
unacknowledged. Message may be lost.
− Reliable delivery - Exactly once: Exactly one delivery is made for each topic message.
Message can neither be lost nor duplicated.
19. QoS for Special Needs:
- Security: It should be possible to send security credentials in order to identify, authenticate,
authorize and encrypt topic messages.
6.2.4 IT Management
20. Configuration: Reliability and Integrity
- Network configuration monitoring: The configuration of all communications infrastructure
shall be monitored outside the IL.
21. Monitoring & Measurement: The IL shall provide tools for monitoring, analysing, debugging and
tracing of Interface and Network activities. The IL shall provide Monitoring Topics and related
canonical model items shall be available. The configuration of all communications infrastructure
should be monitored and controlled to ensure that no unauthorised connections are made. Any
communication on IL is observable.
22. Alarms:
- Informing: The administrator of the IL should be informed about each event.
- Alarm format requirements:
− Real-time: The monitoring process should be in real-time.
− Communication monitoring: The communication mechanism provided by the IL shall
provide monitoring and measurements facilities for faults and performances.
6.2.5 Implementation of IL
23. Compliance with existing standards (e.g. EN.50159, EN.50129).
GA 777465 Page 14 of 197

24. Public specification of middleware part of the IL: The middleware part of the IL shall be based on
publicly available specification, allowing a complete development of compatible implementation
of the IL by an independent party.
25. Run the IL in a virtual environment: It shall be possible to run the IL in a virtual environment.
26. SIL2: Most of the TMS functionality is not safety relevant, but it shall be possible to develop small
SIL2 components implementing at least validation of specific safety relevant aspects. Restrictions
the IEC 50128 defines for the pre-existing software in SIL2 (in this case middleware of application
framework) are:
- Documentation of requirements to this component, interfaces to other parts
- It must be included into validation process of the whole system
- It shall provide sufficient documentation.
The application layer shall enable development of SIL2 components according to EN 50128. Some
IMDG products already have safety and security certification.
27. SIL Apportionment: The IL shall allow the combination of plug-in in order to obtain the requested
SIL level.
28. Requirements related to API-Type:
- Library and framework APIs: The IL middleware shall support APIs based on software
libraries and software frameworks.
Functional Requirements
6.3.1 Security & Accounting
6.3.1.1 Authentication
29. Authentication mechanism: The IL shall provide an authentication system.
30. Access control: The IL shall prevent unauthorised usage of the IL.
31. Authorisation model: All functionality in the IL shall use the same authorisation model to
determine permissions.
32. Roles in the system: The IL shall allow managing and defining roles in the IL.
33. Users and Roles should be password protected: The IL shall allow for password protection of
users and roles and shall follow state-of-the-art rules for password management like e.g., "C2-level
Security" standard."
6.3.1.2 Permissions (authorization)

34. Permission granularity: Permission shall be given at topic level.
35. Access rights: The IL shall allow associating specific access rights.
6.3.1.3 Message Security, Confidentiality and Integrity

36. Restriction to physical port: The IL shall allow restricting some authentication to specific physical
port of the system.
GA 777465 Page 15 of 197

37. Compliance with ISO27001: The IL shall not prevent to be compliant with ISO27001 standards
(Information security management).
38. Compliance with ISO27002: The IL shall not prevent to be compliant with ISO27002 standards
(Information technology – Security techniques – Code of practice for information security
management).
39. IDS- Checks against malicious software: Checks against malicious software: The IL should support
an intrusion detection system.
6.3.1.4 System Protection

40. Buffer overflow protection: The IL shall be protected against buffer overflows caused by interface
plug-ins. Besides secure programming practices in the development of the IL, the platform hosting
the middleware part of the IL should be able to run security check system.
41. SQL injection protection: The IL shall be protected against SQL injections.
42. Encryption and Key Management: The IL shall support an encryption and key management
mechanism.
43. Encryption: The IL shall be able to provide encryption functionality. Encryption shall be possible
for setup of connections and message payloads.
44. Key management): The IL shall support key management based on open source or COTS KMS
software.
6.3.2 Data Access Patterns

45. Connection/Authorization: All the data exposed via the IL shall be available after successfully
establishing a connection to the IL itself. The IL shall apply policies to authorize (allow or deny) the
access of the exposed data to the connected user according to configured access rights.
46. Publish/Subscribe: The IL shall provide data access according to the configured access rights to
any of its exposed data through Publish/Subscribe. An API shall be available to support this data
access pattern.
47. Request/Reply: The IL shall provide data access according to the configured access rights to any of
its exposed data through Request/Reply. An API shall be available to support this data access
pattern.
48. Tagging on write access: The IL shall provide mechanism to tag data on write access. An API shall
be available to support this feature.
49. QoS: The IL shall provide data access with different delivery priority, under different safety and
security constraints, and on the selected communication channels. An API shall be available to
support these features.
6.3.3 Messaging
6.3.3.1 Messaging Channel Patterns

50. Publish-Subscribe: The messaging system shall support the Publish-Subscribe Channel pattern. It is
basic for IL.
GA 777465 Page 16 of 197

51. Point-to-Point: The messaging system shall support the Point-to-Point Channel pattern by private
topic for information receiver. As a particular case of the publish-subscribe pattern.
6.3.3.2 Message Construction Patterns

52. Command message: The messaging system shall support the Command Message pattern.
53. Document message: The messaging system shall support the data set Message pattern. Messages
managed by IL can represent any document. Encoding could be based on JSON-philosophy.
54. Event message: The messaging system shall support the Event Message pattern.
55. Request-Reply: The messaging system shall support the Request-Reply pattern by two topics: one
for requests, one for replies (private to the receiver).
56. Message expiration: The messaging system shall support the Message Expiration pattern.
Implemented as part of API per topic - providing validity interval.
6.3.3.3 Message Payload Format

57. Structured message model: Message payload shall conform to a structured message model.
Several message format representations shall be automatically generated from CDM.
58. Canonical data model: The message payload model shall comply to the Canonical Data Model of
the system.
59. Schema: The message payload model shall be described in a standardised schema language.
60. Self descriptive: The schema language shall support self-descriptive messages.
61. Polymorphism: The schema language shall support polymorphism through subtyping.
6.3.3.4 Message Model Versioning

62. Version control: The message payload model shall be version controlled. Data version is part of
Topic specification.
63. Version coexistence: The IL shall be able to handle data according to different versions of the
message payload model in the same system instance. Data is managed by IL as black box.
Compatibility information: The message payload model shall provide rules for documenting and
communicating compatibility breaking model changes.
GA 777465 Page 17 of 197

7 MIDDLEWARE STATE OF THE ART EVALUATION

The Evaluation of the State of the Art regarding the middleware products allows having a global
view of the different available products and the level of compliance with the Integration Layer
requirements.
The evaluation is composed by the following activities:
Middleware Assessment Criteria: Selection of criteria for being evaluated based on the
Integration Layer’s most relevant requirement defined in the In2Rail documentation. They cover
also the requirement for the interfaces of the Integration Layer.
Middleware Products Selection: Selection of products available on the market for being analysed
according to the available information and expertise in their use.
Evaluation Results: Identification of the weakness and strengths of the analysed products and
their compliance with the Integration Layer requirements.
Evaluation Conclusions: Conclusions emerged from the evaluation.
Middleware Assessment Criteria

The Criteria selected for performing the evaluation of the middleware products proceed from the
requirements defined for the Integration Layer and its interfaces in the In2Rail documentation
([In2Rail D8.1], [In2Rail D8.2 & D8.3] as well as the Integration Layer API and the decisions taken
regarding the most appropriated base technology to be used.
Requirements for the Integration Layer:
- General:
− Be message-oriented.
− Ability to run in a virtual environment.
− Support APIs based on software libraries and software frameworks.
− Be platform-independent.
− Be scalable.
− Be fault-tolerant (high availability).
− Provide high throughput.
− Provide low latency.
− Provide loosely coupling.
− Provide 'virtualisation', i.e. dynamic handling of end-points (change of location of
consumer and/or provider)/Location transparency.
− The middleware part of the IL shall be based on publicly available specification,
allowing a complete development of compatible implementation of the IL by an
independent party.
- Messaging:
− Use message queuing to store and forward messages.
− Support the point-to-point exchange pattern.
− Support the publish-subscribe exchange pattern.
GA 777465 Page 18 of 197

− Support the request-reply exchange pattern.

− Support for message expiration.
− Support for message selectors (filtering).
− Deal with message priority.
− Support for message persistence.
− Support for load-balancing/distributed delivery.
− Support for transactions.
− Support for self-describing and structured data formats such as XML.
− Deal with message compression.
− Deal with QoS (at least reliable and guaranteed delivery modes).
− Support for identification of message source.
- Mediation:
− The IL shall provide measures to ensure that for data messages integrity is maintained.
− The IL shall be able to provide encryption functionality (confidentiality).
− The IL shall be able to handle errors from faulty messages.
− The IL shall be able to route messages based on their content.
- Management:
− Manage access control (permissions) at topic level.
− Configure the amount of memory allocated to topics.
− Configure the use of network resources (port, multicast…).
− Provide tracing information (specific topics, log files…).
− Include a monitoring tool.
− Include an administration tool.
Requirements for Interfaces:
- General:
− It should be possible to develop an IL-Wrapper for the implementation of the data
warehouse.
− APIs for C, C++, Java and C# should be available.
− It should support the publish/subscribe pattern.
− Providers and consumers should be loosely coupled.
− It should support configurable logs.
− It should support content-transparency.
− It should support both simple and complex data types.
− Be message-oriented.
- Data access:
− It should permit applications and modules to access (read or write) individual
Key/Value Pair content in their binary serialised form.
− It should permit applications and modules to access (read or write) groups of Key/Value
Pairs of the same type.
− It should be possible for modules to be notified of values changes (change of the
serialised data) of given Key/Value Pairs.
GA 777465 Page 19 of 197

− It should be possible for modules to be notified of apparition and suppression of given

Key/Value Pairs.
− It should be possible to remove data by expiry date or explicitly.
− It should be possible to control access to data by application or by person via topics.
− Topics can be static or dynamic.
− It should log all failed access trials due to insufficient permissions.
− It should permit access to the history (with a configurable depth) of key-value pairs per
topic.
− Subscription to topics can be either permanent or periodical.
− It should permit filtering of subscribed data.
Additional criteria:
- Economic criteria.
− List price for unit license.
− List price for annual maintenance.
− License types (educational, development, research, production…).
− License metrics (instance, processor, connected processor…).
Middleware Products Selection

The selection of products is performed attending to the following factors:
To cover different approaches: Message Oriented Middleware, Enterprise Service Bus and In
Memory Data Grid principals. Although different products have been analysed in order to have
an overview of the available characteristics of the products (MOM, ESB or IMDG), it was settled
in the IN2RAIL project [D8.3] that the technology employed is IMDG principals.
To take into account commercial and freeware solutions.
To reflect the most used products at the moment in the market.
The analysis of each product is completed by one partner or by the collaboration of a pair of
partners attending to the acquired knowledge by the use of the product or by accessing the
available documentation.
The following table includes the analysed products, its associated technology and the partner or
partners in charge of the analysis.
Middleware Product Site Reference Technology Assigned
Partner
Apache Kafka kafka.apache.org/ ESB STS / CAF
Infinispan (Red Hat) infinispan.org/ IMDG STS / BTSE
Hazelcast hazelcast.com/products/ IMDG BTSE / HC
JBoss Fuse (Red Hat) redhat.com/es/technologies/jboss- ESB CAF
middleware/fuse
Redis redis.io/ IMDG STS
Tibco ActiveSpaces www.tibco.com/products/tibco-activespaces IMDG IND
Tibco Rendezvous www.tibco.com/products/tibco-rendezvous MOM IND
Vortex DDS (Adlink) www.prismtech.com/vortex IMDG AZD
GA 777465 Page 20 of 197
Table 7.1: Selected Middleware Products
Evaluation Results
7.3.1 Comparison of Middleware Products

The comparative table including the compliance for the requirements of all the analysed products
is available in the Appendix A: Comparison of Middleware Products of the present document.
7.3.2 Weaknesses and Strengths of analysed Middleware Products

Once the middleware products and the main characteristics that these software products must
achieve are defined, the individual strengths and weaknesses for each product are summarised
below in order to obtain an overview of the advantages and disadvantages of using them for data
management. In order to focus on the most relevant characteristics of each software, strengths
and weakness will be grouped as above, in requirements of integration layer and requirements for
interfaces.
It is important to highlight that the data structure established in the IN2RAIL project [In2Rail D8.3]
is an "In Memory Data Grid" (IMDG) principals, despite this we analyse other software that are not
IMDG. These analysis help to compare with the different possibilities available for middleware
solutions.
7.3.2.1 Apache Kafka

Apache Kafka is a distributed streaming platform with a free and open source license. The Confluent
Platform is Kafka plus various extras such as the schema registry and database connectors.
7.3.2.1.1 Strengths
Related to the requirements for the integration layer, Apache Kafka is able to run in a virtual environment
and support APIs based on different frameworks as:
• Connect API: development of connectors that continually pull from some source data system
into Kafka or push from Kafka into some sink data system
• Producer/Consumer API
• Streams API: continuous computation on input coming from one or more input Kafka
Additionally, it is platform-independent, being available for Linux, UNIX/BSD and MS Windows; and
scalable, providing topics as a category or feed name to which records are published/subscribed to. For
each topic, the Kafka cluster maintains a log partitioned between cluster servers, which means that the
log is able to scale beyond a size that will fit on a single server. Each partition is also replicated across a
configurable number of servers for fault tolerance.
Between its qualities highlight low latency, loosely coupling and virtualisation, allowing a complete
development of compatible implementation of the IL by an independent party.
GA 777465 Page 21 of 197

In the context of messaging, although it is designed as a publish-subscribe system, it can be configured to

use message queuing to store and forward messages, supporting the point to point, publish-subscribe and
request-reply exchange patterns (producers publish their records to a topic, and consumers subscribe to
one or more topics). Instead of attempting to delete messages as soon as they are consumed, messages
can be retained for a long period, supporting for message expiration, priority and selector (filtering).
Converter class is used to convert between Kafka Connect format and the serialized form that is written
to Kafka, is independent of connectors, and it allows any connector to work with any serialization format
like XML, JSON or Avro.
End-to-end block compression feature may be enabled, which means that data can be written in
compressed format on the server by the producer and then decompressed by the consumer. Compression
will improve the consumer throughput for some decompression cost, and it is especially useful when
mirroring data across data centres.
Finally, encryption and authentication are functionality options available, and manage access control
(permissions) at topic level are defined by a pluggable and an out-of-box authorizers. Configuration of the
amount of memory allocated to topics, the use of network resources and tracing information provision
are also capabilities of this software, as well as monitoring and administration tools, which also provide a
set of APIs to enable the administration of the cluster.
On the other hand, and focussing on the requirements of the interfaces, Kafka supports different APIs for
C, C++, Java and C# as well as configurable logs and content transparency, supporting both simple and
complex data types. Related to exchange and data access, Kafka allows applications and modules to access
(read or write) groups of Key/Value Pairs of the same type, being possible for modules to be notified of
values changes. Also, it is possible to remove data previously stored by expiring date or explicitly, which
means that access to the history of key-value pairs per topic is permitted.
To sum up, the control access to data is possible by application or by person via topic, being all failed access
trials due to insufficient permissions logged, and the subscription to topics can be permanent or periodical,
allowing filtering of subscribed data.
7.3.2.1.2 Weakness
The main disadvantage to overcome using Kafka is being an Enterprise Service Bus (ESB) and not IMDG
software, as it was agreed in the IN2RAIL project.
Kafka is not message-oriented, it can be configured as a MOM without providing measures to maintain
messages integrity, so it needs to be implemented on the top of the middleware. Also, despite of the IL
shall be able to route messages based on their content, topic records may be routed to another topic via
the transformation mechanism, which are being evaluated.
7.3.2.2 Infinispan (Red Hat Data Grid)

Infinispan (Red Hat Data Grid) is a distributed in-memory key/value data store with optional schema fee
for Red Hat Data Grid (IMDG), in terms of maintenance, which depends on the type of SLA and the license.
GA 777465 Page 22 of 197
It is available under Apache Software License 2.0: a permissive free software license written by the Apache
Software Foundation.
7.3.2.2.1 Strengths
Related to the requirements for the integration layer, Infinispan (Red Hat Data Grid) runs in a Java Virtual
Machine and allows execution both in a virtual environment and in containers. It supports both the built-
in library and the Java Application Server solution, and it is scalable, supporting the duplication and
fragmentation of key-value elements.
Additionally, it is platform-independent with a Java based implementation, Linux as preferred host system
and supporting MS Windows in its server implementation. It is also scalable and fault-tolerant with a high
availability, which means that supports duplication and sharding of key-value elements. Between its
qualities highlight low latency, loosely coupling and virtualisation, allowing a complete development of
compatible implementation of the IL by an independent party.
In the context of messaging, it allows exchange in different ways as point-to-point, publication-

subscription and request-response through the notification/listening mechanism, supporting for message
expiration and selectors (filtering) based on continuous queries. Related to message transactions, it allows
transactions in key-value, not in the sense of the transactional client EIP, allowing the use of different data
formats as XML.
Finally, manage access control (permissions) at topic level are available on a per Cache Container basis,
which store sets of key-value pair, providing tracing information (specific topics, log files…) and including
both monitoring and administration tools.
On the other hand, and focussing on the requirements of the interfaces, Infinispan (Red Hat Data Grid)
supports different APIs for C, C++, Java and C# as well as configurable logs and content transparency,
supporting both simple and complex data types and supporting the publish/subscribe pattern by the
implementation via Notification/Listener mechanism or through continuous queries. Regarding the
exchange and data access, Infinispan (Red Hat Data Grid) allows applications and modules to access (read
or write) both individual Key/Value Pair content in their binary serialised form and groups of Key/Value
Pairs of the same type, being possible for modules to be notified of values changes. Also, it is possible to
remove data previously stored by expiring date or explicitly.
To sum up, the topics can be static or dynamic. New topics can be added simply by creating a new element
with a key that represents the new name of the topic, and subscriptions to the topics can be permanent
or periodic. The subscription of the notification mechanism for the elements is cancelled simply by deleting
the key/value. Subscribed data can be filtered enabling Hadoop Query Language.
7.3.2.2.2 Weakness
Although Infinispan (Red Hat Data Grid) is not message-oriented, some message patterns can be emulated
using the Notification mechanism. The impossibility of using message queuing to store and forward
GA 777465 Page 23 of 197

messages or the lack of support for message expiration as well as not dealing with message priority or
message compression are some of the problems that this middleware has to deal with.
Also, Infinispan (Red Hat Data Grid) does not provide measures to ensure data messages integrity is
maintained, and does not provide encryption functionality or route messages based on their content, so
these features need to be implemented on top of the middleware.
7.3.2.3 Redis
Redis is an open source, In Memory Data Grid (IMDG) structure store, used as a database, cache and
message broker. It is free for community edition, although there are other types of licenses like Cloud, VPC
(database as a service, managed), company, community, etc.
7.3.2.3.1 Strengths
Related to the requirements for the integration layer, Redis runs in C language and allows execution both
in a virtual environment and in containers. It supports the built-in library and it is scalable, supporting
scalability via Sharding and zero-latency proxy.
Additionally, Redis is platform independent, fault tolerant, and enterprises editions enable high availability
systems. . Also, Redis provides high throughput via different mechanisms command pipelining or multi-
core execution, highlighting low latency, loose coupling and virtualisation, allowing a complete
In the context of messaging, it allows exchange in different ways as point-to-point, publication-

subscription and request-response through the notification/listening mechanism, supporting message
expiration and selectors (filtering), which is enabled by different mechanisms as sorted sets, geospatial, or
via custom plug-in.
Related to message transactions, they allow the execution of group of Redis commands in a single step,
not in the sense of the Transactional Client EIP. Either all the commands of a transaction or none of them
are processed, so Redis transaction are atomic. In addition, this software supports self-describing and
structured data formats such as XML or JSON and deals with message compression via additional plug-in.
Finally, access control (permissions) at topics level are available on a per database basis, which stores sets
of key-value pair, and port and network settings are available to configure the use of network resources,
but multicast is not provided. Redis also include both monitoring and administration tools (SLI natively
available).
On the other hand, and focussing on the requirements of the interfaces, Redis supports different APIs for
C, C++, Java and C# implementing Redis command set protocol towards brokers, as well as configurable
logs and content transparency (binary safe strings), supporting both simple and complex data types and
supporting the publish/subscribe pattern by the implementation via Notification/Listener mechanism.
Regarding the exchange and data access, Redis allows applications and modules to access (read or write)
both individual Key/Value Pair content in their binary serialised form and groups of Key/Value Pairs of the
GA 777465 Page 24 of 197

same type, allowing modules to be notified of values changes (change of the serialised data) of given
Key/Value Pairs through pipeline commands. In addition, it allows the possibility to remove data by expiry
date or explicitly, being the modules notified of apparition and suppression of given Key/Value Pairs, and
it is possible to control access to data by application or by person via topics, so access control is limited to
authorization and failed access trials due to insufficient permission are logged.
To sum up, the topics can be static or dynamic, and new topics can be added simply by creating a new
element with a key that represents the new name of the topic, and subscriptions can be either permanent
or periodical, just unsubscribe the notification mechanism for K/V elements.
7.3.2.3.2 Weakness
Although it is not message-oriented, Redis can emulate some message patterns using the Notification
mechanism. The impossibility of using message queuing to store and forward as well as not dealing with
message priority or the lack of support for identification of message source are some of the problems that
this middleware has to deal with.
Also, Redis does not provide measures to ensure data messages integrity is maintained, and does not
provide encryption functionality or route messages based on their content, being unable to handle errors
from faulty messages, so these features need to be implemented on top of the middleware.
Finally, Redis does not configure the amount of memory allocated to topics and it does not allow access
to the history (with a configurable depth) of key-value pairs per topic, including not filtering the subscribed
data.
7.3.2.4 IMDG Hazelcast

Hazelcast IMDG is a data centric framework to build In Memory Data Grid (IMDG) solution that can be
used on server side as well as in client application. With a minimum of three purchases in different virtual
machines (yearly license fee), different licenses are available to cover the requirements (enterprise license,
enterprise HD license…).
7.3.2.4.1 Strengths
Related to the requirements for the integration layer, IMDG Hazelcast is able to run in a virtual
environment and it supports the built-in library and software frameworks. It is also scalable and platform-
independent, working on a Java Virtual Machine, providing high throughput, low latency and loosely
coupling by providing APIs and mechanism to use. Additionally it provides virtualisation, allowing a
complete development of compatible implementation of the IL by an independent party.
In the context of messaging, it uses message queuing to store and forward messages, supporting the point-
to-point exchange pattern by using queues and the publish-subscribe exchange pattern by using topics,
but the request-reply exchange pattern can be only emulated by pair of queues. In addition, Hazelcast
offers support for message expiration and selector (filtering) by using predicate pattern, allowing
GA 777465 Page 25 of 197

transactions and dealing with message compression (with default java serialization) and QoS, supporting
the identification of message source.
In addition, encryption and authentication are functionality options available, which guarantee data
message integrity is maintained and errors from faulty messages are handle. Related to data management,
access control (permissions) at topic level can be granted, allowing the configuration of network resources
(port, multicast ...) and providing monitoring and administration tools.
On the other hand, and focussing on the requirements of the interfaces, although Hazelcast is written in
java, it supports different APIs for C, C++, Python and C#, allowing the possibility to develop an IL-Wrapper
for the implementation of the data warehouse. Also, it supports configurable logs and content
transparency, allowing applications and modules to access (read or write) both individual Key/Value Pair
content in their binary serialised form and groups of Key/Value Pairs of the same type by implementing
extension of permission. Notifications of values changes and the apparition and suppression of given
Key/Value pairs can be achieved by listeners events, and the possibility to remove data by expiry date or
explicitly is also possible.
Control access to data by application or by person via topic is also a possibility with an implementation via
software, and dynamic and static topics can be created programmatically and configured in the same way.
7.3.2.4.2 Weakness
Although IMDG Hazelcast is not message-oriented, it is a classical Data Grid, so message communication
via queues and topics is possible, as well as a publish-subscribe mechanism. In addition, it does not support
request-response operation although a couple of queues can emulate it, and there is no message priority
or persistence.
Finally, the other problems this software presents are that it does not support for self-describing and
structured data formats such as XML, not allowing memory allocation for topics or maintain historical data.
7.3.2.5 JBoss Fuse (Red Hat)

JBoss Fuse (Red Hat) is a distributed, cloud-native integration solution that has the flexibility to service
diverse users - including integration experts, application developers, and business users - each with their
own choice of deployment, architecture, and tooling. It is free and open source for unit license, although
the price for annual maintenance include some costs.
7.3.2.5.1 Strengths
Related to the requirements for the integration layer, JBoss Fuse (Red Hat) is message oriented, with the
abilities of being run in a virtual environment and supporting APIs based on software libraries and
frameworks. Also, it is platform independent, scalable, and fault-tolerant (with high availability), providing
high throughput, low latency and loosely coupling, and allowing virtualisation and a complete
GA 777465 Page 26 of 197

to-point, the publish-subscribe and request-reply exchange patterns, as well as message expiration and
selector (filtering). JBoss Fuse (Red Hat) also deals with message priority, giving support for message
persistence and transactions and allowing self-describing and structured data formats such as XLM. It also
deals with message compression and QoS, providing encryption functionality and routing messages based
on their content.
In addition, and in terms of management, it is both configurable in terms of memory allocated to topics
and network resources as port or multicast, providing tracing information for specific topics or log files
and including monitoring and administration tools.
On the other hand, and focussing on the requirements of the interfaces, JBoss Fuse (Red Hat) supports
different APIs for C, C++, Python and C#, supporting configurable logs, content-transparency and the
publish-subscribe pattern. It is also loosely coupled, and supports both simple and complex data types. In
addition, the software allows the possibility to remove data by expiry date or explicitly, being possible to
control access to data by application or by person via topics. Also, it allows applications and modules to
access (read or write) individual Key/Value Pair content in groups of Key/Value Pairs of the same type,
notifying the apparition and suppression of given Key/Value Pairs.
To sum up, the topics can be static or dynamic, and subscriptions can be either permanent or periodical,
allowing the filter of subscribed data for current and previous values of data that has changed and the
access to the history with a configurable depth of key-value pairs per topic.
7.3.2.5.2 Weakness
The main disadvantage to overcome using JBoss Fuse (Red Hat) is being an Enterprise Service Bus (ESB)
and not IMDG software, as it was agreed in the IN2RAIL project. Between the weaknesses points of JBoss
Fuse (Red Hat) highlights the lack of capacity to provide measures to ensure that the integrity of the data
messages is maintained, neither supporting the identification of message source.
Also, there is no access control management (permissions) at topic level, and it does not allow applications
and modules to access (read or write) individual Key/Value Pair content in their binary serialised form, so
developing an IL-Wrapper for the implementation of the data warehouse is not possible.
7.3.2.6 Vortex DDS (ADLINK)

Vortex DDS is the Intelligent Data Sharing Platform for Business-Critical Internet of Things (IoT)
applications. Vortex DDS helps system integrators, OEMs, device platform vendors, and Cloud service
providers (IaaS, PaaS, SaaS, DaaS) deliver ‘Smart’ solutions for many vertical markets. It is free and open
source, so the number of installations is not limited and it is an IMDG platform, so the primary requirement
is successfully accomplished.
7.3.2.6.1 Strengths
GA 777465 Page 27 of 197

Related to the requirements for the integration layer, Vortex DDS supports the built-in library and software
frameworks, being platform independent and available in different platforms as Windows or Linux. It
provides low latency when exceeded, and loosely coupling by publish-subscribe, restricted by topic
definition.
to-point exchange pattern in a special case of publish subscribe, supporting message expiration as part of
QoS and message selectors (filtering) as complex expressions. Also, the software can deal with message
priority and supports message persistence as part of QoS. Additionally, Vortex provide measures to ensure
that data message integrity is maintained, providing encryption functionality and handling errors from
faulty messages by implementing additional services. Related to data management, the configuration of
the use of network resources as port or multicast is done automatically, including monitoring and
administration tools.
On the other hand, and focussing on the requirements of the interfaces, Vortex supports different APIs for
C, C++, Python and C#, allowing the possibility to develop an IL-Wrapper for the implementation of the
data warehouse. Also, it allows applications and modules to access (read or write) individual Key/Value
Pair content in groups of Key/Value Pairs of the same type, notifying the apparition and suppression of
given Key/Value Pairs. Removing data by expiry data or explicitly is also possible by removing it from cache,
so it is possible to set up history depth and to query the received data, allowing to subscribe to topics and
filter.
7.3.2.6.2 Weakness
Not allowing message-orientation and the inability of being run in a virtual environment, added to not
providing virtualisation not allowing a complete development of compatible implementation of the IL by
an independent party are some of the disadvantages of Vortex DDS.
Related to messaging capacity, it does not support the request-reply exchange pattern or the load-
balancing/distributed delivery, not supporting structured data formats as XML and not supporting
identification of data sources and, therefore, not being able to route messages based on their content.
Finally, the software does not provide a mechanism to manage access control (permissions) at topic level,
not supporting configurable logs and not logging all failed access trials due to insufficient permissions.
7.3.2.7 Tibco ActiveSpaces

TIBCO ActiveSpaces is a TIBCO application that provides a distributed In Memory Data Grid for an increase
in performance by reducing reliance on costly transactional systems. It is free of charge, with unlimited
number of product instances for enterprise edition. It is an IMDG platform, so the primary requirement is
successfully accomplished.
7.3.2.7.1 Strengths
GA 777465 Page 28 of 197

Related to the requirements for the integration layer, Tibco ActiveSpaces is message-oriented and can be
run in a virtual environment, supporting APIs based on software libraries and software frameworks. It is
also independent of the platform (Apple Mac OS X, Microsoft Windows, Microsoft Windows Server and all
Linux distributions equivalent to RHEL), scalable with nodes that can be dynamically added or dropped,
and fault-tolerant through synchronous replication, storing data backups and status information on
several nodes. Additionally, Tibco ActiveSpaces provides high-throughput, maintaining several servers in
an active-active configuration, and provides loosely coupling and low latency by caching for fast data
access, providing virtualisation as well.
In the context of messaging, it supports the publish-subscribe exchange pattern, as well as message
expiration and selection (filtering), allowing persistence of messages by database or files and supporting
load-balancing messages thanks to a distributed dynamic architecture for transactions, storing complex
data types in its serialized from using simple types as XML. Related to data management, the configuration
of the use of network resources as port or multicast is possible, including monitoring and administration
tools.
On the other hand, and focussing on the requirements of the interfaces, Tibco ActiveSpace supports
different APIs for C, and java, allowing the possibility to develop an IL-Wrapper for the implementation of
the data warehouse. It allows applications and modules to access (read or write) both individual Key/Value
Pair content in their binary serialised form and groups of Key/Value Pairs of the same type, allowing
modules to be notified of values changes (change of the serialised data) of given Key/Value Pairs. In
addition, it allows the possibility to remove data by expiry date or explicitly (data purging is also
configurable), being the modules notified of apparition and suppression of given Key/Value Pairs, and it is
possible to control access to data at data grid level.
To sum up, the topics can be static or dynamic, and subscriptions can be either permanent or periodical,
allowing the filter of subscribed data for current and previous values of data that has changed.
7.3.2.7.2 Weakness
Between the disadvantages that Tibco ActiveSpace presents highlight these related to messaging, not
using a message queue to store and forward messages and not supporting the point-to-point or request-
reply exchange patterns. Also, it does not deal with message priority as well as message compression
(messages can be compressed, but this product does not deal with compression), neither dealing with Qos
or supporting the identification of message sources.
In addition, this software does not provide measures to ensure data messages integrity is maintained, and
does not provide encryption functionality or route messages based on their content, being unable to
handle errors from faulty messages, so an additional processing layer is required for this requirement.
Finally, Tibco ActiveSpace does not manage access control (permissions) at topic level (it can be managed
at data grid level). It does not configure the amount of memory allocated to topics and it does not allow
access to the history (with a configurable depth) of key-value pairs per topic, both characteristics
important to the correct functionality of the data management.
GA 777465 Page 29 of 197

7.3.2.8 Tibco Rendezvous

TIBCO Rendezvous is a TIBCO application platform for high-speed data distribution using a fully distributed
daemon-based peer-to-peer architecture that eliminates bottlenecks and single points of failure. It is free
of charge, with license metrics per instance.
7.3.2.8.1 Strengths
Related to the requirements for the integration layer, Rendezvous is message-oriented and can be run in
a virtual environment, supporting APIs based on software libraries and software frameworks. It is also
independent of the platform (Apple Mac OS X, Microsoft Windows, Microsoft Windows Server and all
Linux distributions equivalent to RHEL), scalable and fault-tolerant. Additionally, Tibco Rendezvous
provides high-throughput, loosely coupling and low latency, providing virtualisation and allowing a
complete development of compatible implementation of the IL by an independent party.
In the context of messaging, it allows exchange pattern in different ways as point-to-point, publication-
subscription and request-response, offering support for message expiration and persistence in certified
delivery mode (reliable delivery mode offers persistence in memory and time limited). It also supports
load-balancing/distributed delivery and structured data format as XML, dealing with QoS in reliable and
certified delivery modes and supporting source identification.
Related to data management, access control (permissions) at topic level can be granted by another TIBCO
product, and the configuration of the use of network resources as port or multicast is possible, including
monitoring and administration tools, and providing tracing information as specific topics or log files.
On the other hand, and focussing on the requirements of the interfaces, Tibco Rendezvous supports
different APIs for C, Cobol, COM, C++, .NET and Java, supporting the publish-subscribe pattern,
configurable logs (file size, file number) and content transparency, and allowing both simple and complex
data types. In addition, it is possible to control data by application or by person via topics, being the
subscription to topics permanent or periodical.
7.3.2.8.2 Weakness
The main disadvantage to overcome using Tibco Rendezvous is being a Message Oriented Middleware and
not IMDG software, as it was agreed in the IN2RAIL project.
Also, other disadvantages added to this software are related to messaging, not using a message queue to
store and forward messages and not supporting for filter selectors or message priority, both of them can
only be done by topic. Also, it does not support transactions or message compression (messages must be
de/compressed at both ends).
In addition, Tibco ActiveSpace does not provide measures to ensure data messages integrity is maintained,
and does not provide encryption functionality or route messages based on their content, being unable to
handle errors from faulty messages, so an additional processing layer is required for this requirement. It
does not configure the amount of memory allocated for topics, and does not support configurable logs.
GA 777465 Page 30 of 197

Finally, it does not allow applications and modules to access (red/write) the contents or history of the
Key/Value pair, not permitting filtering of subscribed data.
Evaluation Conclusions
After having studied and analysed the main characteristics that the different available middleware
solutions offer, it can be concluded that although none of the products covers all aspects 100%,
most of them cover a high number of the main requirements requested, so they can be employed
to check the different prototypes. Additionally, the IL allows different middleware to manage data,
so even though some of the analysed middlewares might have functionality lacks, these lacks can
be covered by other middleware specialised in these functionalities.
According to the requirements for middleware products defined for X2Rail-2 project, the main
aspect to be addressed by the different possible software is to present a platform compling with
In Memory Data Grid principals. This requirement belongs to the metadata management, which
encompasses the aspects to be considered for a successful data traffic management [In2Rail D8.2
& D8.3].
Due to this, the middleware software products that are based on an IMDG platform are (is possible
other):
Infinispan (Red Hat).
Redis.
Vortex (DDS).
IMDG (Hazelcast).
Tibco ActiveSpaces.
As it has been explained from section 7.1 to section 7.3, conclusions can be grouped as If the
middleware functionalities cover the main requirements (see Appendix A:) or not, which can be
summarised as:
Requirements for integration layer:
- General requirements for integration layer as the ability to run in a virtual environment
or the capability to support APIs based on software libraries/frameworks are successfully
covered by most of the proposed middleware; but other as being message-oriented or
the characteristic of being platform-independent, which are not completely covered by
the software, can be completed with the implementation of additional middleware.
- Related to messaging, the main characteristic covered by the middleware are the
support for message expiration, persistence, transactions and selector (filtering). On the
other hand, some common fields as the use of message queuing to store and forward
messages or dealing with message compression or priority cannot be fully covered by
the middleware, but they can be supported by other software as well.
- In terms of mediation with the IL, this is the weakest point for every middleware
proposed, only highlighting the encryption functionality and the ability to handle with
GA 777465 Page 31 of 197

errors from faulty message in some software. To overcome these aspects, an additional
processing layer would be required.
- Finally, while some of the data management requirements are successfully achieved due
to the importance of this field as can be the incorporation of the monitoring and
administration tools, other important aspects like the configuration of the amount of
memory or the management of access control (permissions) at topic level are not fully
covered, but can be addressed by using different middleware.
Requirements for interfaces:
- General requirements for interfaces as the availability of using APIs for different
programming languages as C, C++ or java, or capability of supporting configurable logs
and support both simple and complex data types are successfully achieved by most of
the middleware. However, others as the possibility of the development of an IL-Wrapper
for the implementation of the data warehouse are hardly covered.
- On the other hand, most of the middleware have the tools to permit applications and
modules access and notify changes on groups of Key/Value Pairs of the same type.
Otherwise, control access to data via topics or history (with a configurable depth) are
some characteristics that are not reached by most of the middleware.
As result of all the characteristics explained above, it can be concluded that although not every
requirement is covered by each of the proposed middleware, the final goals of the middleware are
allowing the storage and exchange of information using unified formats between the applications
involved in the traffic management, stablishing different options related to message
communication and management, which are successfully reached.
Based on the analysis performed which provides an overview of the market, it can be concluded
that some of the In Memory Data Grid products comply partially with most of the main Integration
Layer requirement. The complete compliance would imply additional modules or adapters
covering specific requirements.
In the framework of the X2Rail-2 WP6 proofs of concept and prototyping activities, these products
can be used by the partners for implementing its own Integration Layer concepts. In order to align
the next prototyping activities in the X2Rail-4, in addition to use a common or a set of a reduced
common APIs, it would useful to use a common Integration Layer provided by an independent
partner.
GA 777465 Page 32 of 197

The following table displays the results of testing the commercial products againts 57 criterial
explained in 7.1 Middleware Assessment Criteria:
Analysis Results
Product Partner Fully Partially Non Empty
Compliant Compliant Compliant
Apache Kafka STS - CAF 86,79 3,77 1,89 7,55
Infinispan (Red Hat) ASTS 62,26 7,55 24,53 5,66
Infinispan (Red Hat) BT 33,96 15,09 45,28 5,66
Redis STS 66,04 11,32 18,87 3,77
Vortex Dds (Adlink) AZD 33,96 22,64 30,19 13,21
Imdg Hazelcast BT 73,58 18,87 5,66 1,89
Jboss Fuse (Red Hat) CAF 90,57 0,00 0,00 9,43
Tibco Activespaces INDRA 64,15 5,66 28,30 1,89
Tibco Rendezvous INDRA 58,49 3,77 37,74 0,00
Table 7.2 – Middlewares analysis result
GA 777465 Page 33 of 197

8 DATA STRUCTURES
The aim of this section is to collect the definition of data structures required for the operation of an
advanced Traffic Management System. This advanced TMS will be a distributed system based on
data formed by a set of business logic using data through Integration Layer according to a defined
Canonical Data Model (CDM). The IL will be in charge of the management of the required rights
to write and/or read data for each application.
The data structures for Integration layer, as defined on this document, only take into account the
data definition as structures for exchange of information between the integrated systems involved
in Traffic Management.
As a first approach to data structure definition, the following areas of information were explored
as sources of data:
• Infrastructure.
• Traffic Management System (TMS):
o Trains.
o Routing.
o Conflicts.
• Temporary Speed Restrictions (TSR).
• Possessions.
• Interlocking (ILX).
• Radio Block Centre (RBC).
• Trackside Automatic Train Operation (ATO).
• Energy Grid.
• Asset Management.
• Fleet & Crew.
• Driver Advisory System (DAS).
• Passenger Information System (PIS).
• Public Weather Information Service.
The main logical entitles managed such as trains, routing and conflicts have been considered as
sources of data within the TMS. Additionally, a common definition of the information related to the
static data of the topological network is intended to be analysed within the infrastructure area.
As indicated before, the purpose of this document is to define the dynamic data required for the
information exchange between the business logic involved in traffic management. Thus, the
purpose of this document is not the static definition of the infrastructure but the first attempt to
describe and standardize the dynamic data as part of a common language required for integration.
Only as a knowledge repository to obtain initial data. Never with the aim to substitute the use of
internal databases, inasmuch as any involved business logic requires to implement its own rules.
The main intention of this approach is to know and to perform the following aspects:
GA 777465 Page 34 of 197

• What kind of data are able to be written into the IL and what is the system (or business logic)
source of the data.
• What kind of information is required to be consumed by other business logic in order to manage
the traffic
• Cover the exchanges of information within the systems involved in the prototypes of X2Rail-2
WP6.
• Carry out the data definition adapted as well for signalling under moving block as under fixed
block signalling.
During the process of data structures definition for an advanced TMS based on the IL it is required
to take into account the following principles with the aim to guarantee an easy and proper system
integration:
• The different functionalities of Traffic Management require different levels of data granularity.
• In order to provide place for new traffic features it is required that the Traffic Management
modules have available the usual managed data, but also additional information as boarding or
prognosis information useful for advanced functionalities.
• The modules in charge of the Traffic Management require information provided by external
systems, but also generate information to be consumed by them. Therefore, both aspects, the
information provided and the information required from other systems are relevant.
• The Integration Layer is the basis for allowing the exchanges of information between the
involved modules or systems.
• The exchanged of information is performed during the operation in real time, by means of
dynamic data. Most of the Traffic Management functions require to answer quickly after any
disturbance in the operation. Because of that, the complexity of the data structures should be
avoided in order to include all the required information, but not additional useless information
for the traffic management.
• The degraded situations during the operation should be taken into account.
With the aim to reflect the process of discovering data carried out along this task the structure of
the document is as follows:
• One chapter for each of the above mentioned areas, as sources of information.
• For each source of information the data have been identified according the following criteria:
o Data: Data that the business logic representing the area provides to the external systems
through the IL.
o Requests: Commands exposed by the business logic owner of the area to the external
systems to be invoked through the IL.
o Alarms: Type of alarms that the business logic owner of the data are able to generate.
o Data Received from External Systems: Data required from other areas that the business
logic owner of the area requires to use in order to provide their functions.
For covering the identification of the data structures, the identified areas have been distributed
among the involved partners according the following table.
GA 777465 Page 35 of 197
Area Responsible Partner

Infrastructure IMs (DB, TRV, NR, SYSTRA)
TMS Trains INDRA
TMS Routing INDRA
TMS Conflicts SIEMENS
Temporary Speed Restrictions (TSR) CAF
Possessions INDRA
Interlocking (ILX) AZD
Radio Block Centre (RBC) CAF, DB
Trackside Automatic Train Operation (ATO) BOMBARDIER
Energy Grid SIEMENS
Fleet & Crew THALES
Asset Management HITACHI RAIL STS
Driver Advisory System (DAS) HITACHI RAIL STS
Passenger Information System (PIS) HACON
Public Weather Information Service HACON
Table 8.1 – Areas Assignment
As first approach of identification of data, it has been agreed to postpone the unification of the
following aspect to later stages of definition of the Canonical Data Model:
• Rules of identification of attributes: The attributes of each source of information are expressed
in the most appropriate format according to the provider.
• Data formats: Several data formats are identified along the different areas.
• Inclusion of detailed units for each numeric attributes: The units can be indicated or left open
until later model specification.
In this sense, it has to be noted that the goal of this task is to identify the concepts and the data
to be exchanged between the several involved actors for supporting advanced functionalities of
traffic management. For each of them the list of attributes and possible admitted values are
provided in order to clarify the content of each identified structure, but without the goal of defining
completely a data model.
Infrastructure
The infrastructure section has been elaborated based on topology and positioning concepts from
RailTopoModel v1.0. The object “Route body” is based on the work of the EULYNX Data
Preparation (DP) cluster which is itself based on RailTopoModel. Both RailTopoModel and
EULYNX DP are initiatives with the participation of several European infrastructure managers.
Data produced by infrastructure should be defined at least with the following data:
• Switch.
• Crossing.
• Track.
• Bridge.
GA 777465 Page 36 of 197

• Tunnel.
• Embankments.
• Line sections.
• Stations.
• Level crossing.
• Depots/yards.
• Access points/nodes.
8.1.1 Topology
Net elements are the basic elements that make up the infrastructure. Net elements can have
relations with other net elements.
8.1.1.1 Positioned relation

Positioned relation
Attribute Attribute description Admitted values
ID Universal identifier UUID of 128-bit code
positioned relation
ID of A UUID of element A UUID of net element
ID of B UUID of element B UUID of net element
Navigability Possibilities of train movements AB, BA, both, none
between A and B
Position on A The relation is using the start/end Start OR end
of Element A
Position on B The relation is using the start/end Start OR end
of Element B
Table 8.2 – Positioned relation
8.1.1.2 Linear location

A linear location is defined based on partial or complete reference object(s) – associated net
elements, e.g. a route is defined based on complete or partial track sections.
Linear location
ID Universal identifier UUID of linear 128-bit code
location
Ordered association of UUID of ordered set of elements UUID of ordered association
net elements which constitute the linear location
Application direction Whether linear element maintains Normal, reverse, both
direction of ordered association
Table 8.3 – Linear location
8.1.1.2.1 Ordered association of net elements
GA 777465 Page 37 of 197

Element constituted by more than one partial or complete constituent net elements in a given
order. If a constituent element is associated with intrinsic coordinates 0 and 1, as beginning and
end, then the whole linear element is part of the ordered association of net elements.
Ordered association of net elements
ID Universal identifier UUID of ordered 128-bit code
association of net elements
Constituent net UUID of linear elements which UUID of net element
elements constitute the ordered association
Intrinsic coordinate Intrinsic coordinate indicating how Number between 0 and 1
beginning much of each constituent element is
relevant to the ordered associated net
element
Intrinsic coordinate Intrinsic coordinate indicating how Number between 0 and 1
end much of each constituent element is (greater than the
relevant to the ordered associated net corresponding intrinsic
element coordinate beginning)
Keeps orientation Whether orientation of constituent Boolean
element is relevant for ordered
association of net elements
Sequence Number which indicates sequence of Integer
constituent element in the ordered
association
Table 8.4 – Ordered association of net elements
8.1.1.3 Spot location

Instance with no dimensions, used for control points or location of signals.
Spot location
ID Universal identifier UUID of ordered 128-bit code
association of spot location
Associated net UUID of linear net element to which the UUID of net element
element spot location is related with
Linear coordinate Intrinsic coordinate of the spot location Tuple (intrinsic
at the associated net element. Optional: coordinate; vertical offset;
lateral and vertical (height) offset. horizontal offset)
Application direction Whether the signal is used in the same Normal, reverse, both
direction of the net element to which it
is associated.
Table 8.5 – Spot location
GA 777465 Page 38 of 197

8.1.2 Positioning
8.1.2.1 Intrinsic coordinate

Location along a chosen linear net element, value between 0 and 1, corresponding to beginning
and end of the element. To the intrinsic coordinate, a horizontal and vertical offset can be added,
forming the linear location.
8.1.3 Line / track section

A line section or track section starts or ends at block section limits, buffer stops and/or track joints.
A line section or track section starts at intrinsic coordinate 0 and ends at 1
Track section
ID Universal identifier UUID of track 128-bit code
section
Geometric X, y, z coordinates
Coordinates in a chosen schematic,
coordinates of
geographic or geodetic reference
start and end
system. Z coordinate is optional.
position
Default travel Boolean
0->1 of travel direction
direction
Track section type Indicates to what type of line it belongs String
(siding, layover, shunting)
Installed signalling Mechanical; colour light
including number of aspects;
Type of signalling installed for this
position light; in cab e.g.
section
ETCS and associated level;
other
Installed train Track circuits; axle counters;
Type of train detection for this section
detection eurobalise; other
Traction system Type of electrification; non-
Traction power installed for this section
electrified
Max gauge Maximum permissible gauge of rolling Positive number
stock for this section
Max axle load Maximum permissible axle load of Positive number (when
rolling stock for this section according available) & line category (A,
to UIC “loading guidelines, volume 1, B1, B2, C2, C3, C4, D2, D3,
3rd edition” D4, E4, E5)
Nominal max Maximum permissible speed for traffic. Mph/kph positive number
speed Different vehicles maybe be required to
follow lower speed
Nominal voltage Couple of positive numbers
Voltage supplied by the catenary
(Voltage and frequency)
Traction mode ID Diesel, electric
Nominal max Positive number
Maximum capacity of power supply
power supply
Max slope Positive or negative number
Gradient of the section
relative to previous track;
GA 777465 Page 39 of 197
slope expressed as a
percentage
Max curve radius Curvature of the section Positive number
ID Identification for section Alphanumeric value
Access Type of restriction and
restrictions (TSR, Changes from designed limits associated reduced value
etc.) within permitted values
Siding possibilities Availability and access to sidings Boolean
Resilience to maximum permissible speeds and/or Conditions and associated
natural hazards axle loads under different conditions ranges of numbers
Table 8.6 – Track section
8.1.4 Route body

Route body
route body
Route entry UUID of route entry object UUID of net element
(normally a signal and more
rarely a buffer stop)
Route exit UUID of route exit object UUID of net element
(normally a signal and more
rarely a buffer stop)
Requires points in List with UUID of points and Set of tuples with UUID of point
position respective position needed for and respective position
this route to be set
Route type Defined type of route in the Listed [Train, Shunting, …]
system.
Routing Mode Routing Mode. Listed [Automatic, Semi-
Automatic, Manual]
Linear location UUID of linear location which UUID of net element
constitutes the route
Table 8.7 – Route body
8.1.4.1 Route constraints

In line with GRASP principles, namely low coupling and protected variations, the route is unaware
of this set of attributes which are delegated to this separate class.
Route constraints
route to which the constraints
apply to
Automatic Interlocking automatically sets Boolean
this route
GA 777465 Page 40 of 197

Electrified Whether route is fully Boolean

electrified
Priority When from entry to exit more Integer
than one route are possible,
then there is a level of priority
for the control system, 1 for
highest.
TSR Temporary speed restriction Positive number
Intermediate point speed Speed reduction no longer Positive number
reduction applies once the train has
cleared the point
ARS Availability of Automated Route Boolean
Setting, a system external to
the interlocking
Delay for lock Time delay for guaranteeing Positive number
route has been cleared by
previous railway vehicle
Reduced braking Braking distance below the Boolean
distance normal values
Max line speed Max line speed within the route Positive number
Table 8.8 – Route constraints
8.1.5 Point
Point includes points and other moveable elements allowing a train to move from one track to
another. For Germany, location of a point is measured with reference to the beginning of the points,
where they are welded to the rest of the track.
Point
ID Universal identifier UUID of point 128-bit code
Point mechanism Indicates the type of mechanism string
used for its operation (manual,
electro-mechanical, etc)
Point type Indicates the type of point - simple points,
- double slip points,
- single slip points,
- moveable switch diamond
crossings,
- moveable crossing noses,
- derailers.
Trailing detection Indicates whether point is Boolean
equipped with trailing detection
Normal Position Position of the point blades for Left, right, straight
most frequent traffic and with the
highest speed
Reversed position Position of the point for the least Left, right, straight
frequently used route, which may
GA 777465 Page 41 of 197

also be the route having the

lowest speed
Length Length of the point panels in Positive number
meters
Geometric coordinates Coordinates in a chosen X, y, z coordinates
schematic, geographic or geodetic
reference system. Z coordinate is
optional.
Linear coordinate Measure from the beginning of the Tuple (Measure; vertical offset;
track. Optional: lateral and vertical horizontal offset)
(height) offset
Heating Presence of heating device for Boolean
snowy conditions
Insulation type Type of insulation needed when String
used in an area with track circuits
Max speed Maximum speed for combinations Tuple (point position, train
of different point positions and type, speed)
train type
Max axle load Maximum tonnage which the point Positive number
is designed to support
Switching time Time necessary to move the Positive number
blades
Positioned Relation List with UUID of positioned Tuple of UUID
relations in which element (point)
is involved in.
Table 8.9 – Point
8.1.6 Signal
Track
ID Universal identifier UUID of signal 128-bit code
Type Defines the type of information the Alphanumeric
signal conveys (advance, main,
shunting, composed…)
Functional type e.g. tunnel signal Alphanumeric
Geometric coordinates Coordinates in a chosen schematic, X, y, z coordinates
geographic or geodetic reference
Associated net UUID of linear net elements to which UUID of net element
element the operational control point is
topologically related
Linear coordinate Intrinsic coordinate along the Tuple (intrinsic
associated net element. Optional: coordinate; vertical offset;
lateral and vertical (height) offset horizontal offset)
Application direction Whether the signal is used in the same Normal, reverse, both
direction of the net element to which it
is associated.
Aspect Aspect being displayed Alphanumeric
GA 777465 Page 42 of 197

Status Contains the operational status of the Alphanumeric

signal (fully operational, failure)
Sighting Distance in metres from which it is Positive number
visible
Relation with other e.g. coupling with other light signal, String
signals lamp proving, back-to-back locking,
non-stop movement
Table 8.10 – Signal
8.1.7 Operational control point

Operational control point
ID Universal identifier UUID of operational 128-bit code
control point (OCP)
Associated net UUID of linear net elements to which UUID of net element
element the operational control point is
topologically related
Linear coordinate Intrinsic coordinate of the spot location Tuple (intrinsic
at the associated net element. Optional: coordinate; vertical offset;
lateral and vertical (height) offset horizontal offset)
Application direction Whether linear element maintains Normal, reverse, both
direction of ordered association (here should normally be
both)
Table 8.11 – Operational control point
8.1.8 Bridge
Bridge
Design life Expected life time at the design phase Positive number in years
Span length Length of the bridge between the two Positive number in
ends meters
Max design traffic load Maximal planned tonnage supported by Positive number in million
the bridge during its lifetime at design gross tons
phase
Max axle load Maximal load for one axle running on Positive number in tons
the bridge
Resilience to natural Maximum permissible speeds and/or Conditions and
hazards: max loading axle loads under different conditions associated ranges of
for lateral wind, snow, numbers
seism, hot
temperature
Associated net UUID of linear net element to which the UUID of net element
element bridge is topologically related
Linear coordinate of Intrinsic coordinate of the bridge start Tuple (intrinsic
start and end position and end on the associated net coordinate; vertical offset;
element’s curvilinear abcissa horizontal offset)
GA 777465 Page 43 of 197

Geometric coordinates Coordinates in a chosen schematic, X, y, z coordinates

of start and end geographic or geodetic reference
position system. Z coordinate is optional.
Table 8.12 – Bridge
8.1.9 Tunnel
Tunnel
Total length Length of the tunnel between the two Positive number in meters
ends
Associated net UUID of linear net element to which UUID of net element
element the tunnel is topologically related
Portal 1 geometric Coordinates in a chosen schematic, X, y, z coordinates
coordinates geographic or geodetic reference
Portal 1 linear Intrinsic coordinate of the tunnel’s Tuple (intrinsic coordinate;
coordinate portal 1 along the associated net vertical offset; horizontal
element. Optional: lateral and offset)
vertical (height) offset
Portal 2 geometric Coordinates in a chosen schematic, X, y, z coordinates
Portal 2 linear Intrinsic coordinate of the tunnel’s Tuple (intrinsic coordinate;
coordinate portal 2 along the associated net vertical offset; horizontal
element. Optional: lateral and offset)
vertical (height) offset
Max loading gauge Max admissible vehicle gauge Listed [GC, GB+,GB, GA,
Universal] According with
UIC Loading gauge values
(EN15273)
Effective height Distance between the rail head and Positive number in meters
the OLE structure
Table 8.13 – Tunnel
8.1.10 Embankment
Embankment
Geometric coordinates Coordinates in a chosen schematic,
of start and end geographic or geodetic reference X, y, z coordinates
position system. Z coordinate is optional.
Associated net UUID of linear net element to which
UUID of net element
element the tunnel is topologically related
Intrinsic coordinate of start and end
Tuple (intrinsic coordinate;
Linear coordinate of of embankment in relation to
vertical offset; horizontal
start and end position associated net element. Optional:
offset)
lateral and vertical (height) offset
GA 777465 Page 44 of 197
maximal planned tonnage supported

Positive number in million
Max design traffic load by the embankments during its
gross tons
lifetime at design phase
maximal load for one axle running on
Max axle load Positive number in tons
the embankment
maximum permissible speeds and/or Conditions and associated
Max wind load
axle loads under different conditions ranges of numbers
Table 8.14 – Embankment
8.1.11 Level crossing

Level crossing
UUID Universal identifier UUID of level
crossing
Geometric Coordinates in a chosen schematic, X, y, z coordinates
Associated net UUID of linear net element to which UUID of net element
element the level crossing is topologically
related
Linear coordinate Intrinsic coordinate. Optional: Tuple (intrinsic coordinate;
lateral and vertical (height) offset vertical offset; horizontal offset)
State Operational status of installation Unknown, open, closed, opening,
closing
Local control Whether it allows local control Boolean
Model Model of the level crossing, Unprotected, protected manned,

describing its functioning automatic
Type Type of automatic level crossing SAL0 (no barriers), SAL2 (two
half barriers), SAL4 (four half
barriers), SAL FC (low cost used
for freight lines and low speeds)
Barrier length Length of the barriers Positive number
Nominal drop time Time necessary to descend and Two positive numbers
and rise time rise the barriers in nominal
conditions
Nominal max Maximum speed which trains may Positive numbers, lower than or
speed per track use for traversing the track at the equal to maximum line speed in
and direction level crossing in different directions the track section
Striking distance Distance of train detector sensor Positive number
from the level crossing to trigger
closure
Minimal warning Time to allow for the response of Positive number
time the equipment
GA 777465 Page 45 of 197

Table 8.15 – Level crossing
8.1.12 Station
Station
ID Universal identifier UUID of station 128-bit code
Superstation ID Refers to the superstation in case this UUID of net element
macroscopic node is only part of what is
commercially refered to as one station
(e.g. "Frankfurt (M) Hbf lower level" as
part of "Frankfurt (M) Hbf)")
UUID of linear locations which
Linear location UUID of net elements
constitute the station
Halt A halt is similar to a normal station but Boolean
without any points
Table 8.16 – Station
8.1.12.1 Stop point

A stop point is a point on a track where trains regularly stop for boarding or other purposes. It is
generally included in a station or in a depot.
Stop point
ID Universal identifier UUID of stop point 128-bit code
Associated net UUID of track section to which the stop UUID of net element
element point is topologically related
Linear coordinate Intrinsic coordinate along the Tuple (intrinsic coordinate;
associated net element. Optional: vertical offset; horizontal
lateral and vertical (height) offset offset)
Application Whether the signal is used in the same Normal, reverse, both
direction direction of the net element to which it
is associated.
Table 8.17 – Stop point
8.1.12.2 Platform
A platform is a section at a track where passengers can board trains. It is not intended as physical
platform: the physical platform can be longer than the usable section or there might not be a
physical platform at all.
Platform
ID Universal identifier UUID of platform 128-bit code
Name Public name of platform (e.g. "9b") Alphanumerical
GA 777465 Page 46 of 197

Length The length of the platform that is usable Positive number

for boarding; note that the usable
length might be shorter than the train
length
Linear location UUID of linear location which constitute UUID of net element
the platform
Max train length The train length that can regularly stop Positive number
at this point
Platform height Platform height above rail, might be Numerical
sectional which would require the Note: might be <0 in extreme
introduction of platform sections as cases where no physical
elements (tbd) platform exists
Accessibility type Describes the way to access the Direct, stairs, escalator, lift,
platform from street level ramp, …
Table 8.18 – Platform
8.1.12.3 Station service

Stations service
Category ID Refers to category, like: Ticket counter, ID
toilets, personal assistance …
Opening times List of time ranges of opening time Standard validity expression
Table 8.19 – Station service
8.1.12.4 Facilities on layover tracks

Facilities on layover tracks
Associated net UUID of track section to which the UUID of net element
element layover track is topologically related
Linear coordinate Intrinsic coordinate along the Tuple (intrinsic coordinate;
associated net element. Optional: vertical offset; horizontal
lateral and vertical (height) offset offset)
Application Whether the signal is used in the same Normal, reverse, both
direction direction of the net element to which it
is associated.
Category ID Categories are for example "dirty water ID
disposal", "fresh water supply", "brake
air"
Mobile flag Whether the facility is stationary or Boolean
mobile, like a fuel truck or a dirty water
truck
Opening hours List of time ranges of opening time for Standard validity expression
facility
Table 8.20 – Facilities on layover tracks
GA 777465 Page 47 of 197

Traffic Management System (TMS): Trains
8.2.1 Data
Data related to trains have been conceptually classified according with the following items.
• Train Identification: It includes the General Data and the additional information regarding the
numbering and the service of the train.
• Train Timetable: Scheduled, target, forecasted and audited timetable data, and planned and
audited boarding and landing information.
• Rolling Stock: Scheduled, target and audited formation data, including details of vehicles and
containers.
• Train Staff: Scheduled, target and audited crew data.
• Train Path: Audited train path based on current location list data, expected detailed train path,
affections of TSRs to the train and Movement Authorities.
• Train Operation: Planned and energy consumption data, incidents and audited operation modes.
8.2.1.1 Data related to Train Identification

As first approach, a Train includes within a single Train identifier the information related not only
to a commercial train mission but also the additional movements of the same such as shunting
movements or movements without passengers/load. It allows also to model in the same Train
several commercial services with different commercial identifiers.
8.2.1.1.1 General Data

The general data of a Train defines univocally a train through a train identifier. It typically includes
the characterization of the train according to a commercial number and the time when the first
commercial departure is scheduled. In any case, the structure allows to use any kind of train
identifier managed by the TMS.
General Data
Train Identifier Internal identification of a train String
with the aim to collect under a
single identifier all the
movements of the train.
Typically it is composed by a
number and the date of the
commercial departure of the
train.
Train Number Main commercial number of the String
train.
Commercial Service Start Departure Datetime of the first Timestamp
Time movement of the Train in
commercial service.
Train Type Type of train attending if it is Listed [Scheduled,
scheduled at long-time plan or Unscheduled]
GA 777465 Page 48 of 197
not created during operation

according with the operational
needs.
Train Category Type of elements carried on the Listed [Passengers, Freight,
train. Mixed]
Train SubCategory Subtype according to the Listed [Fast-Freight, Slow-
elements carried and the type of Freight, Local Passengers,
service. Sub-Urban Passengers, High
Speed Passengers, etc.]
Train Status Commercial status of the train. Listed [Scheduled, Close to
Run, Running, Finished,
Cancelled]
Railway Undertaking Company allowed to interface String
with the Infrastructure Manager
to get allocation of slots.
Train Operating Company Company allowed to carry String
persons or goods in the railway
network.
N x Additional Feature Additional information regarding Array [Complex [Additional
numbering, parking and Feature]]
movements.
Table 8.21 – General Data
8.2.1.1.2 Additional Features

This structure models several additional information to the timetable data which could be of
interest for the traffic management. Thus, specific information for the several numbers or identifiers
that the same train can be assigned during its running are included in this structure for facilitating
the access to these data.
In the same way, the information regarding the time lapses when the train is parked and the
different types of movements according to the service offered can be consulted.
This model also allows to include additional features if it is necessary for specific future
functionalities or systems, each of them with its specific attributes.
All this information is scheduled data, and therefore all the references to locations or timetable
control points are scheduled data.
Additional Feature
Feature Type Type of information provided in Listed [Numbering, Stabled,
the feature of the train. Movement]
Specific Attributes Set of attributes according to the Array [Complex [Specific
according to the Type value of the Type of the Attributes]]
value Additional Feature.
Table 8.22 – Additional Feature
The attributes could be different for each Type of Additional Feature defined:
GA 777465 Page 49 of 197
• Type Numbering: Information of the several numbers or identifiers assigned to the train during
its life cycle.
• Type Stabled: Time lapses when the train is stabled, excluding the stops for boarding and landing
of passengers or goods.
• Type Moving: Time lapses when the train is providing commercial service, moving without
commercial service or shunting.
Specific Attributes for Type: Numbering

Number Commercial number or any String
other identifier of the train during
shunting, parking, etc. assigned
to the train in the control point.
Control Point Reference to a control point String
where the stop of the train is
allowed.
Scheduled Timetable Order of Timetable Control Numeric
Control Point Reference Point in Scheduled Timetable
Table 8.23 – Specific Attributes for Type: Numbering
Specific Attributes for Type: Stabled

Control Point Reference to a control point String
where the stop of the train is
allowed.
Start Time Timestamp when the parking in Timestamp
the Control Point starts.
End Time Timestamp when the parking in Timestamp
the Control Point ends.
Table 8.24 – Specific Attributes for Type: Stabled
Specific Attributes for Type: Moving

Moving Type Type of movement according to Listed [Commercial, Empty,
its commercial or internal Shunting]
characteristic.
Control Point Start Reference to an identified String
location (node) where is allowed
to define a datetime value for a
train movement where the type
of movements starts.
Scheduled Timetable Order of the Timetable Control Numeric
Start where the type of movements
starts.
GA 777465 Page 50 of 197
Control Point End Reference to an identified String

location (node) where is allowed
to define a datetime value for a
train movement where the type
of movements ends.
Scheduled Timetable Order of the Timetable Control Numeric
End where the type of movements
ends.
Table 8.25 – Specific Attributes for Type: Moving
8.2.1.2 Data related to Train Timetable

The aim of this chapter is to collect all the information related to the timetable of a train and its
evolution. According to the life cycle of a train during the operation, the following entities related
to the timetable of each train have been identified:
• Scheduled timetable: Defined timetable for the current day of operation, which is established
before the departure of the train. It is usually provided by an offline system in charge of the long
term operation. It provides the established times of arrival and departure for each control point
defined for a train. This timetable is informed to third party systems such as Passenger
Information Systems in stations.
• Target timetable: During the train running, due to unscheduled events or traffic needs, the
scheduled timetable could be required to be modified. Re-planning actions will be included over
the scheduled timetable by the user of the TMS with the aim to minimize the impact on these
events on the traffic evolution. Thus, the target timetable indicates the intention of running to
be accomplished by the train. This timetable is used within the TMS to minimize the deviation of
the real timetable regarding the scheduled timetable.
• Audited timetable: It indicates the real times when the arrival and departures of a train takes
place.
• Forecasted timetable: According with the status of the traffic and the infrastructure, the
forecasted timetable is the estimation of arrival times for the control points of a train no reached
yet. This timetable is evolving during the running of the train and will be calculated by TMS
business applications.
A timetable for a train running on D-day, will be formed by an ordered set of control points with
information related to the datetime when each event is scheduled/targeted/audited/forecasted and
information related to the event (start, end, stop or pass of a train).
In order to define data related to a train timetable the following data and attributes have been
identified.
The level of detail for the train data related to timetable is based on the required exchange of
information between the TMS and the external systems.
8.2.1.2.1 Timetable Control Point

GA 777465 Page 51 of 197
Established times and their related parameters for a train at each control point of the route.
According with the lifecycle of the train, usually the trains are scheduled in advance and its related
information is published on TMS. Train scheduling establishes the arrival and departure times that
needs to be fulfilled during operation in order to assure an optimal traffic management across the
networks. At this stage, the “Control Point” used to establish the arrival and departure times are
related to a macroscopic level of infrastructure, where the control point represents an entire node
of the network such as a station, a siding, a depot, etc. The list of control points used for this
purpose are defined by each IM as a set of control points where the time has been fixed and other
business services like ticketing or passenger information are aware of the same.
During operation, the arrival/departure times on these “control points” need to be respected and
the purpose of the TMS during operation is to evaluate deviations at this level of information, in
order to detect when to modify the scheduled movements is required.
For other purposes, like routing, it is required to use the microscopic level of infrastructure in order
to know the precise path used by the train. Times on microscopic level are not fixed, and are able
to be modified by the user during operation, in order to better fulfil the required.
Timetable information is defined to be exchanged between the systems in charge to monitor and
control the time and to improve the service quality.
Timetable Control Point
Control Point Reference to an identified
String
location where is allowed to
define a datetime value for a
train movement (stop or pass).
Arrival DateTime DateTime when is planned that Timestamp
the train arrive to the control
point.
Commercial Departure DateTime defined officially for Timestamp
DateTime the departure time of the train
from a control point.
Technical Departure DateTime contemplating the Timestamp
DateTime reserved time for the departure
of a train in case it is required
additional dwell time for
technical purposes (such as
extra time for passenger
exchange in rush hour). This
time is reserved during the train
scheduling but may not be
necessarily respected during
the train operation.
Movement Type Defines if the train stops or Listed [Stop, Pass, Start, End]
passes at the control point.
Arrival Track Identification of the track within String
the node where is defined the
arrival of the train. In case of a
GA 777465 Page 52 of 197

stop movement, is the track

where the train wait for
passenger’s exchange.
Departure Track Identification of the track within String
the node where the train is
before to departure. Usually, it
is the same track defined as
arrival track.
Arrival Circulation Track Identification of the circulation String
track defined to be used by the
train to reach a node (outside
the node).
Departure Circulation Identification of the circulation String
Track track defined to be used by the
train to leave a node (outside
the node)
Stop Type Scheduled kind of stop defined Listed [Commercial Stop,
for a train. Commercial stops Technical Stop]
needs to be respected during
operation but other types may
not be required.
Minimum Commercial Minimum defined stop duration Numeric
Dwell Time of the train for commercial
purposes such as passengers
boarding
Table 8.26 – Timetable Control Point
8.2.1.2.2 Scheduled Timetable

Scheduled timetable for a train is formed by an ordered set of ‘Timetable Control Points’.
Scheduled Timetable
N x Timetable Control Set of ordered Timetable Array [Complex [Timetable
Point Control Point defining the Control Point]]
complete scheduled timetable
for train running on D-day.
Table 8.27 – Scheduled Timetable
8.2.1.2.3 Target Timetable

Target timetable for a train is formed by an ordered set of Timetable Control Points.
Target Timetable
N x Timetable Control Set of ordered Timetable Array [Complex [Timetable
Point Control Point defining the Control Point]]
complete target timetable for
train running on D-day.
GA 777465 Page 53 of 197

Table 8.28 – Target Timetable
8.2.1.2.4 Audited Timetable Control Point

Collection of data related with the real values when the train has arrived and leaved the control
point at the macroscopic level of the infrastructure, where the arrival/departure times are defined.
During operation, the location of the train is permanently updated according with the level of
accuracy provided by the signalling system in use. This level of information is registered with the
train path information.
Each Audited Timetable Control Point refers to a Target Timetable Control Point where and when
the audited information applies.
Audited Timetable Control Point
Control Point Reference to an identified String
Target Timetable Control Order of the referred Timetable Numeric
Point Reference Control Point in Target
Timetable.
Audited Arrival DateTime Date and time when the train Timestamp
has reached the control point.
Audited Departure Date and time when the train Timestamp
DateTime has left the control point.
Audited Movement Type Defines if the train has stopped Listed [Stop, Pass, Start, End]
at the control point or only has
passed.
Audited Arrival Track Identification of the track within String
the node where is performed the
where the train waits for
Audited Departure Track Identification of the track within String
the node where the train
performs its departure. Usually,
it is the same track used as
arrival track.
Audited Arrival Circulation Identification of the circulation String
Track track used by the train to reach
a node (outside the node).
Audited Departure Identification of the circulation String
Circulation Track track used by the train to leave
a node (outside the node)
Audited Stop Type Kind of stop performed by the Listed [Commercial Stop,
train. Technical Stop]
Audit Type Defines when the audited Listed [Manual or Automatic]
values have been received
GA 777465 Page 54 of 197
automatically or set manually by

the TMS user.
Table 8.29 – Audited Timetable Control Point
8.2.1.2.5 Audited Timetable

Registration of data related with the real values produced by the train for the reached control point
of its route.
Target Timetable
N x Audited Timetable Set of ordered Audited Array [Complex [Audited
Control Point Timetable Control Point defining Timetable Control Point]]
the complete audited timetable
for train running on D-day.
Table 8.30 – Audited Timetable
8.2.1.2.6 Forecasted Timetable Control Point

Estimated data related with the calculated values when the train is expected to arrive and leave
the control point according with the current traffic situation at the macroscopic level of the
infrastructure, where the arrival/departure times are defined.
During operation, based on the traffic evolution, the TMS is continuously providing information
related with the expected timetable in order to allow integrated systems to know the deviation on
the control points against the target and/or the scheduled depending on the purpose of the system.
New systems requiring a deeper level of information are able to use the information related to the
train path.
Each Forecasted Timetable Control Point refers to a Target Timetable Control Point where and
when the forecasted information applies.
Forecasted Timetable Control Point
Timetable.
Forecaseted Arrival DateTime when is expected that Timestamp
DateTime the train arrives to the control
point according with the current
traffic situation.
Forecaseted Departure DateTime when is expected that Timestamp
DateTime the train leaves the control point
GA 777465 Page 55 of 197

according with the current traffic

situation.
Forecasted Movement Defines if the train stops or Listed [Stop, Pass, Start, End]
Type passes at the control point.
Forecaseted Arrival Track Identification of the track within String
the node where is defined the
where the train wait for
Forecasted Departure Identification of the track within String
Track the node where the train is
before to departure. Usually, it is
the same track defined as arrival
node track.
Forecasted Arrival Identification of the circulation String
Circulation Track track defined to be used by the
train to reach a node (outside
the node).
Forecasted Departure Identification of the circulation String
Circulation Track track defined to be used by the
train to leave a node (outside the
node)
Forecasted Stop Type Kind of stop expected to be Listed [Commercial Stop,
carried out by the train. Technical Stop]
Table 8.31 – Forecasted Timetable Control Point
8.2.1.2.7 Forecasted Timetable

Estimated data for a train timetable according with the current traffic situation.
Forecasted Timetable
N x Forecasted Timetable Set of ordered Forecasted Array [Complex [Forecasted
Control Point Timetable Control Point defining Timetable Control Point]]
the expected timetable for train
running on D-day.
Table 8.32 – Forecasted Timetable
8.2.1.3 Data related to Rolling Stock

According with the definition of timetable data, based on the train life cycle, same concepts have
been used for the definition of the data related to the rolling stock of each train:
• Scheduled data: Defined rolling stock for the current day of operation established before the
departure of the train. If the specific vehicles have not been informed yet, scheduled data may
use only type of vehicles.
GA 777465 Page 56 of 197
• Target data: During the train running, due to unscheduled events or traffic needs, the scheduled
rolling stock requires to be modified or completed with the identifiers of the specific vehicle.
• Audited data: It indicates the specific rolling stock that has been used. The intention here is to
collect or confirm that the rolling stock used is the informed on the target.
8.2.1.3.1 Scheduled Formation Control Point

This data describes an ordered set of vehicles defined together to carry out the train running
leaving a control point. The formation may be defined according with the type of rolling stock used
by the theoretical formation or with the specific rolling stock when available.
Each Scheduled Formation Control Point refers to a Scheduled Timetable Control Point where the
formation is scheduled.
Scheduled Formation Control Point
Scheduled Timetable Order of the referred Timetable Numeric
Control Point Reference Control Point in Scheduled
Timetable.
Formation Identifier of the formation String
leaving the Control Point.
Weight Total weight of the formation Numeric
during the section.
Length Total length of the formation Numeric
during the section.
Loading Gauge Maximum gauge of the Listed [GC, GB+,GB, GA,
formation during the section in Universal] According with UIC
use. Loading gauge values
(EN15273)
Track Gauge Type of the gauge of the track Listed [UIC gauge, Iberian
used by the formation for the gauge, Metric gauge, Swedish
section delimited by Control gauge]
Point Start and Control Point
End.
Features and Amenities Main features of the formation Array [String]
for the section.
N x Vehicle Ordered set of vehicles to be Array [Complex [Vehicle]]
used during the section.
Table 8.33 – Scheduled Formation Control Point
8.2.1.3.2 Scheduled Formation

This data describes the set of vehicles scheduled for the running of the train along its route. This
formation will be composed by a set of scheduled formation control points defining the formation
leaving each of the scheduled run points.
GA 777465 Page 57 of 197
Scheduled Formation
N x Scheduled Formation Ordered set of data related to Array [Complex [Scheduled
Control Point the formation of a train Formation Control Point]]
scheduled for each section of
the train route where the
formation does not changes.
Table 8.34 – Scheduled Formation
8.2.1.3.3 Target Formation Control Point

This structure includes the information of the goal of the formation for the train leaving a control
point according with the evolution of the traffic and the modifications on the scheduled information
previously announced. In this stage it is more probable to be informed the identifiers of the
vehicles, although this information is included in the structures at scheduled and target levels.
Each Target Formation Control Point refers to a Target Timetable Control Point where and when
the target rolling stock information is defined.
Target Formation Control Point
Timetable.
Formation Identifier of the formation String
leaving the Control Point.
Weight Total weight of the formation Numeric
during the section.
Length Total length of the formation Numeric
during the section.
Loading Gauge Maximum gauge of the Listed [GC, GB+,GB, GA,
use. Loading gauge values
(EN15273)
Track Gauge Type of the gauge of the track Listed [UIC gauge, Iberian
used by the formation for the gauge, metric gauge, Swedish
section delimited by Control gauge…]
Point Start and Control Point
End.
Features and Amenities Main features of the formation Array [String]
for the section.
N x Vehicle Ordered set of vehicles to be Array [Complex [Vehicle]]
used during the section.
Table 8.35 – Scheduled Formation Control Point
GA 777465 Page 58 of 197

8.2.1.3.4 Target Formation

This data describes the set of vehicles assigned for the running of the train along its route. This
formation will be composed by a set of target formation control points of the train route.
Target Formation
N x Target Formation Ordered set of data related to Array [Complex [Formation in
Control Point the formation of a train assigned Section]]
for each section of the train
route where the formation does
not changes.
Table 8.36 – Target Formation
8.2.1.3.5 Audited Formation Control Point

The audited formation control point includes the information of the formation of a train leaving the
control point.
Each Audited Formation Control Point refers to a Target Timetable Control Point where and when
the target rolling stock information is defined. In this way, the target timetable, target rolling stock
and audited rolling stock information are linked for each control point.
Audited Formation Control Point
Timetable
Audited Formation Identifier of the formation String
Audited Weight Total weight of the formation Numeric
during the section.
Audited Length Total length of the formation Numeric
during the section.
Audited Loading Gauge Maximum gauge of the Listed [GC, GB+,GB, GA,
use Loading gauge values
(EN15273)
Audited Track Gauge Type of the gauge of the track Listed [UIC gauge, Iberian
used by the formation for the gauge, metric gauge, Swedish
section gauge…]
Audited Features and Main features of the formation Array [String]
Amenities for the section
N x Vehicle Ordered set of vehicles already Array [Complex [Vehicle]]
used for the section.
GA 777465 Page 59 of 197

Audit Type Type of audit according to the Listed [Manual, Automatic]

system or user providing the
information.
Table 8.37 – Audited Formation Control Point
8.2.1.3.6 Audited Formation

This data describes the set of vehicles already used for the running of the train during its route.
This formation will be composed by a set of audited formation control points.
Audited Formation
N x Audited Formation Ordered set of data related to Array [Complex [Formation in
Control Point the formation used for a train Section]]
during each section of the train
route where the formation has
not been changed.
Table 8.38 – Audited Formation
8.2.1.3.7 Vehicle
Definition of the rolling stock used for a train formation. This data structure may be used to indicate
just the rolling stock type of a theoretical formation or the nominated rolling stock of a real-time
formation when available. The identification of the type of vehicle is used in order to obtain the
characteristics of each type of vehicle such as the physical and dynamic characteristics, the
features, the on-board equipment’s…
Vehicle
Vehicle Identifier Identification of the specific String
vehicle (UIC)
Vehicle Type Identifier of the type of vehicle Listed [Vehicle Types]
Traction If the vehicle is pulling or not Boolean
during the section.
Loaded If the vehicle is loaded or not, in Boolean
case of wagons.
Goods Code Code related to the type of load Listed [Type of goods]
transported by the vehicle, in
case of wagons.
Goods Weight Total weight related to the load Numeric
transported by the vehicle, in
case of wagons.
Seals Number Number of seals closing used to Numeric
close the wagon during the
section.
Dangerous Goods If is included dangerous goods Boolean
in the vehicle, in case of
wagons.
GA 777465 Page 60 of 197

Dangerous Goods Code Code related to the dangerous Listed [Type of dangerous
goods transported by the goods]
wagon.
Passengers Number of passenger on-board Array [Complex [Class,
by category Number of passengers]]
Line Permit Holder Lines allowed for the circulation Array [String]
of the specific vehicle.
Status Alarm Active affected Alarm to Listed [Alarm Status]
Vehicle. It is included only in the
Vehicle in the Audited
Formation in Section.
N x Container Ordered set of containers Array [Complex [Container]]
included over a vehicle, in case
of wagons.
Table 8.39 – Vehicle
8.2.1.3.8 Container
Data related to the load included over the wagons in case of trains related to transport goods.
Container
Container Identifier Identification of the specific String
container (UIC)
Container Type Identifier of the type of Listed [Container Type]
container.
Loaded If the container is loaded or not, Boolean
in case of wagons.
Goods Code Code related to the type of load Listed [Type of goods]
included on the container.
Goods Weight Total weight related to the load Numeric
transported on the container.
Seals Number Number of seals used to close Numeric
the container.
Dangerous Goods If is included or not dangerous Boolean
goods in the container.
Dangerous Goods Code Code related to the dangerous Listed [Type of dangerous
goods included on the goods]
container.
Table 8.40 – Container
8.2.1.4 Data related to Train Staff

According with the definition of timetable data, based on the train life cycle, same concepts have
been used for the definition of the data related to the train staff.
• Scheduled crew: Defined staff or required for the current day of operation and established
before the departure of the train. If the crew identifiers have not been informed yet to the TMS,
scheduled data may use only type of staff.
GA 777465 Page 61 of 197
• Target crew: During the train running, due to unscheduled events or traffic needs, the scheduled
staff may require to be modified or completed with the identifiers of the staff.
• Audited crew: It indicates the specific staff that has been involved. The intention here is to
collect or confirm that the staff really involved is the same as informed on the target staff.
8.2.1.4.1 Scheduled Crew Control Point

This structures includes the scheduled information of the crew leaving the control point. It refers
to a Scheduled Timetable Control Point where and the when the crew data applies.
Scheduled Crew Control Point
Scheduled Timetable Order of the referred Timetable Numeric
Control Point Reference Control Point in Scheduled
Timetable.
Crew Identifier Identifier for the set of the crew String
assigned to the train for the
current section.
N x Crewmember Identification of the members of Array [String]
the crew assigned to the train
for the current section.
Table 8.41 – Scheduled Crew Control Point
8.2.1.4.2 Scheduled Crew

Scheduled data related to the crew assigned to a train along its route. The scheduled crew will be
formed by an ordered set of scheduled crew control points.
Scheduled Crew
N x Scheduled Crew Ordered set of crew scheduled Array [Complex [Crew in
Control Point to carry out each specific Section]]
section of the train route.
Table 8.42 – Scheduled Crew
8.2.1.4.3 Target Crew Control Point

The target crew control point includes the target information of the crew leaving the control point
according the evolution of the target timetable and the crew data modifications during the
operation. It refers to a Target Timetable Control Point where and when the information applies.
Target Crew Control Point
GA 777465 Page 62 of 197


Timetable.
assigned to the train for the
current section.
the crew assigned to the train
for the current section.
Table 8.43 – Target Crew Control Point
8.2.1.4.4 Target Crew

Data related to the crew assigned to a train along its route according with the traffic situation. The
target crew will be formed by an ordered set of target crew control points.
Target Crew
N x Target Crew Control Ordered set of crew assigned to Array [Complex [Crew in
Point carry out each specific section Section]]
of the train route.
Table 8.44 – Target Crew
8.2.1.4.5 Audited Crew Control Point

The audited crew control point includes the data of the crew who has on service when the train
leaves a control point.
It refers to a Target Timetable Control Point for locating the place and time referred by the
information.
Audited Crew Control Point
Timetable
audited for the train in the
section.
the crew audited.
GA 777465 Page 63 of 197


information.
Table 8.45 – Audited Crew Control Point
8.2.1.4.6 Audited Crew

Data related to the crew who has carried out the set of crew section for a train route. The scheduled
crew will be formed by an ordered set of crew allowed for a section of the route.
Audited Crew
N x Audited Crew Control Ordered set of crew who has Array [Complex [Crew in
Point carried out each specific section Section]]
of the train route.
Table 8.46 – Audited Crew
8.2.1.5 Data related to Train Path

The intention here is to register detailed information produced during the movements of the train
along the network with the aim to provide advanced information for business application purposes.
The information is collected during the running of the Train including detailed audited information
of the location of the train, the Temporary Speed Restrictions that the Train crosses and the
Movement Authorities that the Train receives.
8.2.1.5.1 Current Location

The current location includes the information of the location of the train. The provider of this
information can be very variable according to the equipment of the train and the line the train is
running. Because of that, for each current location data the source has to be identified, but the
information provided will differ according to the provider.
In the same way, the location of the front and the rear ends can be provided, although it should
be mandatory to include at least the positioning information through one of the systems (KP –
Line, GNSS Coordinates front end or LRBG location).
Current Location
Location DateTime DateTime the location when the Timestamp
train is located at location data.
Location Source Provider of the location data. Listed [GNSS, RBC,
Occupancies, Mixed]
KP – Line Kilometric Point at Line where Complex [Numeric - String]
the head of a train is located on.
Infrastructure Elements Element or elements of Array [String]
Infrastructure that can be
referred (typically Track
Section) to state location where
GA 777465 Page 64 of 197
the train is located on. Several

occupied elements may be
indicated.
GNSS Coordinates front Global Navigation Satellite Complex [GNSS Coordinates]
end System coordinates where the
front end of train is located at
location DateTime.
GNSS Coordinates rear Global Navigation Satellite Complex [GNSS Coordinates]
end System coordinates where the
rear end train is located at
location DateTime.
LRBG Location Position based on balise (Balise Complex [String, Numeric]
identifier, distance)
Direction Direction the train is moving Listed [Up, Down]
along the line.
Current Speed Current speed of train at Numeric
location datetime.
Table 8.47 – Current Location
8.2.1.5.2 Audited Train Path

The audited Train Path covers all the data of location provided for the Train. If several systems
are providing information, all of them is collected. The audited Train Path is formed by a set of
ordered current location data.
Audited Train Path
N x Current Location Set of ordered Current Array [Complex [Current
Locations describing the path Location]]
followed by the Train.
Table 8.48 – Audited Train Path
8.2.1.5.3 Expected Location

The expected location includes the punctual information of the expected detailed location of the
train.
Expected Location
Expected Location Datetime the location when the Timestamp
DateTime train is expected to be located at
location data.
Infrastructure Elements Element of Infrastructure that Array [String]
can be referred (typically Track
Section) to state location where
the train is located on.
Direction Direction the train is moving Listed [Up, Down]
along.
GA 777465 Page 65 of 197

Expected Speed Current speed of train at Numeric

location datetime.
Table 8.49 – Expected Location
8.2.1.5.4 Expected Train Path

The expected Train Path covers the detailed path at microscopic level to be run by the train. The
expected Train Path is formed by a set of ordered expected location data.
Audited Train Path
N x Expected Location Set of ordered Current Array [Complex [Expected
Locations describing the path Location]]
followed by the Train.
Table 8.50 – Expected Train Path
8.2.1.5.5 Train Related Speed Restriction

The Temporary Speed Restriction of a train includes the information of the TSR that affects the
train during its movement. The purpose of this information is not to collect the data of the TSR on
the line but capture the information of when and where the train is informed of a TSR and when
and where it really affects to the train movement.
Train Related Speed Restriction
Temporary Speed Identifier of a TSR included in String
Restriction the system by the TSR
management system.
Reception Point Location element where the Complex [Location]
train is notified of the TSR.
Reception DateTime DateTime when the train is Timestamp
notified of the TSR.
Maximum Speed Maximum Speed of the TSR. Numeric
Start Point Location element where the Complex [Location]
train entries into the area
defined in the TSR.
Start DateTime DateTime when the TSR starts Timestamp
to affect the running of the train.
End Point Location element where the Complex [Location]
TSR leaves to affect the running
of the train.
End DateTime DateTime when the TSR leaves Timestamp
to affect the running of the train.
Table 8.51 – Train Related Speed Restriction
8.2.1.5.6 Movement Authority
GA 777465 Page 66 of 197

The Movement Authority information of a train collects the data of the authorities of movement
provided to the train. Several systems could provide this information, according to the signalling
and train protection systems. The data covers the maximum information that could be provided,
but according to the different systems, not all of them could be included.
Movement Authority
Movement Authority Identifier of the Movement String
Identifier Authority when it is managed by
other system.
Movement Authority System provider of the Listed [ERTMS1, ERTMS2,
Source Movement Authority to the train. CTC, Signaller, Shunter,
PICOP, Driver]
Reception Point Location element where the Complex [Location]
train is notified of the MA.
Reception DateTime DateTime when the train is Timestamp
notified of the MA.
Start Point Location element where the MA Complex [Location]
starts.
End Point Location element where the MA Complex [Location]
ends.
Authorized Overtake Indication if overtake is Boolean
authorized.
Overtake Signal Identifier of the signal to be String
overtaken.
Section Length Length of the section of the MA. Numeric
Section Time Limit Time limit the MA is valid. Numeric
Table 8.52 – Movement Authority
8.2.1.6 Data related to Train Operation

Within the operation of the train are included the information of the modes of operation the train is
using along the services. Additionally this category includes the boarding passenger information
and the energy consumption data, planned and audited, and the incidents that arise and affect the
train during the operation.
8.2.1.6.1 Planned Boarding

Number of expected passengers boarding and landing the train along its route for each vehicle
forming the train.
Planned Boarding
N x Vehicle Planned Set of scheduled data related to Array [Complex [Vehicle
Boarding Control Point passengers boarding a train Planned Boarding Control
along its route by vehicle. Point]]
Table 8.53 – Planned Boarding
GA 777465 Page 67 of 197

8.2.1.6.2 Vehicle Planned Boarding Control Point

Number of expected passengers boarding and landing the train in a control point (station).This
data may be set according with booking information or estimations. This data may be defined for
the rolling stock type of the theoretical formation or to the specific vehicle assigned to the train if
available. For each vehicle, the number of passengers will be specified according with the
commercial class of the seat (place).
Vehicle Planned Boarding Control Point
location where the boarding and
landing of passenger is allowed.
Vehicle Type Model of rolling stock of the car. Listed [Type of Vehicle]
vehicle (UIC).
Boarding Data related to the scheduled Array [Complex [Class,
number of passengers expected Number of passengers]];
to board the train for each class where Class is the type of
of the vehicle. place of the Vehicle Type.
Landing Data related to the scheduled Array [Complex [Class,
number of passengers expected Number of passengers]];
to leave the train for each class where Class is the type of
of the vehicle. place of the Vehicle Type.
Table 8.54 – Vehicle Planned Boarding Control Point
8.2.1.6.3 Vehicle Audited Boarding Control Point

Number of counted passengers that have taken and leaved the train in a control point
(station).This data may be set according with boarding information if available or with the booking
information if the scheduled boarding information is based on estimations. For each vehicle, the
number of passengers will be specified according with the commercial class of the site (place).
Vehicle Audited Boarding Control Point
location where the boarding and
landing of passengers is
allowed.
Vehicle Planned Boarding Order of the referred Vehicle Numeric
Control Point Reference Planned Boarding Control Point
in Planned Boarding.
vehicle (UIC).
information.
GA 777465 Page 68 of 197
Boarding Data related to the audited Array [Complex [Class,

number of passengers boarding Number of passengers]] where
the train for each class of the Class is the type of place of the
vehicle. Vehicle.
Landing Data related to the audited Array [Complex [Class,
number of passengers landing Number of passengers]] where
the train for each class of the Class is the type of place of the
vehicle. Vehicle.
Table 8.55 – Vehicle Audited Boarding Control Point
8.2.1.6.4 Audited Boarding

Number of counted passengers boarding and landing the train along its route for each vehicle of
the train.
Audited Boarding
N x Vehicle Audited Set of counted data related to Array [Complex [Vehicle
Boarding Control Point passengers boarding a train Audited Boarding Control
along its route by vehicle. Point]]
Table 8.56 – Audited Boarding
8.2.1.6.5 Planned Energy Consumption in Section

The consumption of a train can be planned before the operation in order to quantify the fuel or
electric power required for completing the scheduled movements of the train.
Taking into account that the energy grid may be divided into different areas fed by different electric
stations, the consumption planned could be also provided into sections. In the same way, the
consumption of another power supply can be scheduled and audited into sections.
Planned Energy Consumption in Section
Start Point Reference to a location where Complex [Location]
the section covered by the data
starts.
End Point Reference to a location where Complex [Location]
ends.
Planned Power Supply Power supply planned to be Array [Listed [Diesel Fuel,
used for running between the Direct Current, Hydrogen,
start point and end point. Alternating Current]]
Planned Consumption Volume of fuel or quantity of Array [Numeric (Units
energy planned to be consumed according to the power supply
in the running between the start value)]
point and end point.
Table 8.57 – Planned Energy Consumption in Section
GA 777465 Page 69 of 197

8.2.1.6.6 Planned Energy Consumption

The complete planned Energy Consumption quantifies the total consumption planned for a train,
composed by a set of ordered planned energy consumption in section. To be coherent the sections
have to be consecutive.
Target Energy Consumption
N x Planned Energy Set of ordered Planned Energy Array [Complex [Planned
Consumption in Section Consumption in Section. Energy Consumption in
Section]]
Table 8.58 – Planned Energy Consumption
8.2.1.6.7 Audited Energy Consumption in Section

These data include the audited values of energy consumption, which can be notified according to
sections.
Audited Energy Consumption in Section
starts.
ends.
Target Energy Order of the referred Energy Numeric
Consumption in Section Consumption in Section in
Planned Energy Consumption
Audited Power Supply Power supply used for running Array [Listed [Diesel Fuel,
between the start point and the Direct Current, Alternating
end point. Current]]
Audited Consumption Volume of fuel or quantity of Array [Numeric (Units
energy consumed in the running according to the power supply
between the start point and the value)]
end point.
information.
Table 8.59 – Audited Energy Consumption in Section
8.2.1.6.8 Audited Energy Consumption

The complete audited energy consumption is composed by a set of ordered audited energy
consumption in section.
Audited Energy Consumption
GA 777465 Page 70 of 197

N x Audited Energy Set of ordered Audited Energy Array [Complex [Audited

Consumption in Section Consumption in Section. Energy Consumption in
Section]]
Table 8.60 – Planned Energy Consumption
8.2.1.6.9 Current Operating Mode

The operating mode includes the information regarding the signalling and train protection system
in use. This information is always audited and reflects the location and time when a mode is
activated.
Current Operating Mode
Train Protection Train Protection system in use.
Listed [ATP, ATO…]
Signalling System Signalling system in use.
Listed [On Sight, ASFA, LZB,
ETCS1, ETCS2, EBICAB700,
CBTC…]
Shunting Mode Indication of shunting mode. Boolean
Mode Activation Location Location where the notified Complex [Location]
mode is activated.
Mode Activation DateTime DateTime when the notified Timestamp
mode is activated.
Table 8.61 – Current Operating Mode
8.2.1.6.10 Audited Operating Mode

The complete audited operating mode information is composed by a set of current operation
modes, including therefore every change in any mode in use in the train.
Audited Operating Mode
N x Current Operating Set of ordered Current Array [Complex [Current
Mode Operating Mode. Operating Mode]]
Table 8.62 – Audited Operating Mode
8.2.1.6.11 Incident
This information includes the incidents that affects the train during its running.
Incident
Location Location element where the Complex [Location]
incident occurs.
Incident Type Type of Incident. Listed [Delay, Cancellation,
Reverse, Detention]
KP – Line Section Kilometric Point at Line Section Complex [Numeric, String]
where the incident occurs.
GA 777465 Page 71 of 197

Incident DateTime DateTime where the incident Timestamp

occurs.
Delay Delay of the train caused by the Numeric
incident.
Justification Justification of the incident. String
Circulation Attributable Indication if the circulation of the Boolean
train causes the incident.
Description Description of the incident. String
Table 8.63 – Incident
8.2.1.7 Data related to Restrictions between Trains

A restriction between trains is a dependence data information related to two trains, but that is not
included directly in the information of none of them. Therefore the Trains Restrictions are managed
outside the management of the trains, although each of them refers to two trains.
The approach of the following data has the aim to cover several situations of the traffic
management where the circulation of where a train event is restricted by another event. Such as
the following:
• Traffic situations that require linking the departure or arrival of two trains in a control point for
operational reasons (transferring of rolling stock, crewmembers or passengers).In this way, a
lapse time is defined for allowing the passengers or crewmembers to transfer between both
trains or for allowing the uncoupling and coupling of the affected vehicles. Several times, such as
in case of passenger transfer, the restriction may not be mandatory and a maximum waiting time
can be established in order to no penalise the punctuality of the traffic.
• Traffic situations where the restriction between trains is defined on different control points.
Such as traffic conditions related to assure the required interval/distance/time between trains.
Departure of the train 1 from the control point 1 affect the departure of the train 2 into the
control point 2.
8.2.1.7.1 Trains Restriction

Trains Restriction
Train 1 Identifier of the train setting the String
restriction (first train).
Train 2 Identifier of the train suffering String
the effects of the restriction
(second train).
Train 1 Event Event of the first train setting the Listed [Arrival, Departure,
restriction. Pass]
Train 2 Event Event of the second train Listed [Arrival, Departure,
conditioned by the restriction Pass]
Control Point 1 Reference to an identified Complex [Location]
location of the first train
movement (stop or pass) where
the restriction is defined.
GA 777465 Page 72 of 197
Control Point 2 Reference to an identified Complex [Location]

location of the second train
movement (stop or pass) where
the restriction is defined.
Restriction Type Type of restriction according to Listed [Rolling Stock, Crew,
the affected elements of the Passengers Transfer, Joint,
train. Split]
Maximum Accepted Delay Maximum time allowed to delay Numeric
the event of the train
establishing the restriction
(event 1) where the restriction
needs to be maintained. Other
cases, the restriction may be
necessarily respected.
Maximum Waiting Time Maximum time allowed to delay Numeric
the event of the conditioned
train (event 2) waiting in order to
maintain the restriction. Such as
in a “Passenger Transfer”
restriction. Other cases, the
restriction may be necessarily
respected.
Priority Classification of the restriction List [Low, Medium, High]
regarding the level of priority
Lapse Minimum time between both Numeric
events.
Affected Passengers Number of passengers Numeric
transferring between both trains
in case of boarding restriction.
Affected Crewmembers Identifiers of the Crewmembers Array [String]
transferring between both
trains.
Affected Vehicles Identifiers of the Vehicles Array [String]
transferring between both
trains.
Table 8.64 – Trains Restriction
8.2.2 Requests
8.2.2.1 Create Train

Command to create a new train in the system.
Command Create Train
Parameters Parameter description Admitted values
General Data To complete the main Complex [General Data]
information
Scheduled Timetable Sequence of scheduled Complex [Scheduled
timetable points. Timetable]
GA 777465 Page 73 of 197

Scheduled Formation Sequence of sections with the Complex [Scheduled

scheduled assignment of rolling Formation]
stock.
Scheduled Crew Scheduled crew for the train, if Complex [Scheduled Crew]
this information is available.
Expected Train Path Sequence of expected Complex [Expected Train
locations. Path]
Planned Boarding Sequence of planned boarding Complex [Planned Boarding]
and loading passengers by
vehicles and sections, if this
information is available.
Planned Energy Sequence of sections with Complex [Planned Energy
Consumption Energy Consumption control. Consumption]
Table 8.65 – Create Train
8.2.2.2 Modify Train

Command to modify information of a train.
Command Modify Train
Train Identifier Identifier to associate the String
changes to the train.
General Data To complete the main Complex [General Data]
information
Target Timetable In the modification, is possible Complex [Target Timetable]
replace or complete the data
concerned about the sequence
of planned timetable points.
Target Formation In the modification, is possible Complex [Target Formation]
concerned about the sequence
of sections with the rolling stock
assigned to train.
Target Crew In the modification, is possible Complex [Target Crew]
concerned about crew for the
train, if this information is
available.
Expected Train Path Sequence of expected Complex [Expected Train
locations. Path]
Table 8.66 – Modify Train
8.2.2.3 Cancel Train

Command to cancel a train.
Command Cancel Train
GA 777465 Page 74 of 197


Explanation Cause of the cancelation String
Table 8.67 – Cancel Train
8.2.2.4 Justify Incident

Command to insert information about incident, justification or other data.
Command Justify Incident
Incident Data Data about the incident to justify Complex [Incident]
or complete this information.
Table 8.68 – Justify Incident
8.2.2.5 Audit Manually Train

Command to modify or to set manual audited data, the income parameter depend on type of
information.
Command Audit Manually Train
Audited Timetable To add or modify audited data Complex [Audited Timetable]
concerned about timetable.
Audited Formation To add or modify audited data Complex [Audited Formation]
concerned about rolling.
Audited Crew To add or modify audited data Complex [Audited Crew]
concerned about the crew.
Audited Boarding To add or modify audited data Complex [Audited Boarding]
concerned about the boarding.
Audited Energy To add or modify audited data Complex [Audited Energy
Consumption concerned about the energy Consumption]
consumption.
Audited Operating Mode To add or modify audited data Complex [Audited Operation
concerned about the operating Mode]
mode.
Table 8.69 – Audit Manually Train
8.2.2.6 Set Trains Restriction

Command to set restriction in the system, it is referred to two trains, the income parameter
depends on the type of restriction as crew, formation, boarding, etc.
Command Set Trains Restriction
GA 777465 Page 75 of 197
Trains Restriction Information of restriction to Complex [Trains Restriction]

associate to the affected trains
Table 8.70 – Set Trains Restriction
8.2.3 Alarms
8.2.3.1 Timetable Audited Deviation

In the operation of a train, the system receives Timetable Audited, if this information is deviated
from the target timetable; the system sets an alarm to warning about this.
Alarm Timetable Audited Deviation
Train Identifier Train identifier to associate String
alarm.
Target Timetable Control The system shows the target Complex [Target Timetable
Point information, full or section. Control Point]
Audited Timetable The system shows the received Complex [Audited Timetable
Control Point information, full or section. Control Point]
Table 8.71 – Timetable Audited Deviation
8.2.3.2 Delayed Timetable Target Deviation

The functionality of the system generates forecasted timetables because of analysis of audited
data, if the result is a forecast timetable exceed the planned, the system sets an alarm to warning
about this.
Alarm Delayed Timetable Target Deviation
alarm.
Target Timetable Control The system show the target Complex [Target Timetable
Point timetable, full or section. Control Point]
Forecasted Timetable The system show the Complex [Forecasted
Control Point forecasted timetable, full or Timetable Control Point]
section.
Table 8.72 – Delayed Timetable Target Deviation
8.2.3.3 Formation in Section Audited Deviation

In the operation of train, the system receives Formation in Section Audited, if this information is
deviated from the Formation in Section target; the system sets an alarm to warning about this.
Alarm Formation in Section Audited Deviation
alarm.
GA 777465 Page 76 of 197

Target Formation in The system show the target Complex [Target Formation in
Section information, full or section. Section]
Audited Formation in The system show the received Complex [Audited Formation
Section information, full or section. in Section]
Table 8.73 – Formation in Section Audited Deviation
8.2.3.4 Crew in Section Audited Deviation

In the operation of train, the system receives Crew in Section Audited, if this information is deviated
from the Crew in Section target; the system sets an alarm to warning about this.
Alarm Crew in Section Audited Deviation
alarm.
Target Crew in Section The system shows the target Complex [Target Crew n
information, full or section. Section]
Audited Crew in Section The system shows the received Complex [Audited Crew in
information, full or section. Section]
Table 8.74 – Crew in Section Audited Deviation
8.2.3.5 Boarding Control Point Audited Deviation

In the operation of train, the system receives Boarding Control Point Audited, if this information is
deviated from the Boarding Control Point scheduled; the system sets an alarm to warning about
this.
Alarm Boarding Control Point Audited Deviation
alarm.
Scheduled Boarding The system show the Complex [Scheduled Boarding
Control Point Scheduled information, full or Control Point]
section.
Audited Boarding Control The system show the received Complex [Audited Boarding
Point information, full or section. Control Point]
Table 8.75 – Boarding Control Point Audited Deviation
8.2.3.6 Energy Consumption Audited Deviation

In the operation of a train, the system receives Energy Consumption Audited, if this information is
deviated from the planned Energy Consumption; the system sets an alarm to warning about this.
Alarm Energy Consumption Audited Deviation
alarm.
GA 777465 Page 77 of 197

Planned Energy The system shows the planned Complex [Planned Energy
Consumption in Section information, full or section. Consumption in Section]
Audited Energy The system shows the received Complex [Audited Energy
Consumption in Section information, full or section. Consumption in Section]
Table 8.76 – Energy Consumption Audited Deviation
8.2.3.7 TSR Received

When the system receives a Temporary Speed Restriction and according to the target timetable
of the train, it is detected that the train will be affected, then the system sets an alarm to warning
about this.
Alarm TSR Received
alarm.
TSR Data The system show the received String
TSR information.
Table 8.77 – TSR Received
8.2.3.8 TSR Affecting

When a configured Temporary Speed Restriction affects to a train, the system sets an alarm to
warning about this.
Alarm TSR Affecting
alarm.
TSR Identifier The system show the identifier String
of refer TSR.
Table 8.78 – TSR Affecting
8.2.3.9 New Incident

When the system receives an Incident and it is referred to a train inserted, the system sets an
alarm to warning about this.
Alarm New Incident
alarm.
Trains Affected List of trains affected Array [String]
Incident Data The system show the received Complex [Incident]
information, full or section.
Table 8.79 – New Incident
GA 777465 Page 78 of 197

8.2.4 Data Received from External Systems
8.2.4.1 Data related to Rolling Stock

According with the definition of train data related to rolling stock it will be required to know the
following type of information for each type of vehicle:
• General data:
o Data related to the identification of the type of vehicle
o Type of vehicle: Locomotive, Coach, wagon…
o Type of transport: Goods or passengers
o Type of wagon: Tank wagon, Portable tanks, Wagons and containers for carriage in bulk,
Tank containers…
• Physical characteristics:
o Length, gauge, docking system, static mass, dynamic mass, maximum speed, number of
axles, type of power supply (diesel/electrical), track gauge (Iberian gauge, metric gauge,
Swedish gauge...), auxiliary services of consumption.
• Dynamic characteristics:
o Parking brake, engine performance, maximum tractive effort curve, maximum braking
effort curve, consumption curve, uniform acceleration, uniform deceleration, running
resistance curve (Rolling factor, flange factor, aero dynamical factor), traction efficiency,
braking efficiency.
• Features and Amenities in case of coach for passengers:
o Number of seats by class
o Restaurant service, wifi, wc
o Handicapped-accessible…
• Information related to the on-board equipment’s available on the vehicle.
8.2.4.2 Data related to Train Staff

According with the definition of train data related to staff it will be interesting to collect information
related to the members of the crew when available.
The following information related to each crewmember has been identified:
• Type of crewmember: driver, attendant…
• Identification of the crewmember.
• Company.
• Train diving licences and certificates. Information related with the type of rolling stock and the
lines of the network where the driver is authorized.
GA 777465 Page 79 of 197

Traffic Management System (TMS): Routing
8.3.1 Data
The aim of this chapter is to collect the information related to the routing of a train. It is possible to
find one or more routes in a sequence to describe the path managed by the Traffic Managed
System.
The attribute “Train ID” is optional.
8.3.1.1 Route
Route
Route Entry Element The element to start a route, String
this point sets the entry. Usually
signal.
Route Exit Element The element to end a route, this String
point sets the finish.
Route Setting DateTime The datetime to start the route. Timestamp
Route Release DateTime The datetime to release the Timestamp
route.
Route Formation Timestamp
Route Formation Time
DateTime
Route Type Defined type of route in the Listed [Train, Shunting, …]
system.
Routing Mode Routing Mode. Listed [Automatic, Semi-
Automatic, Manual]
Static Route Identifier Route identifier in interlocking String
infrastructure
Automatic Succession Indication if the automatic Boolean
succession is provided.
TrainID Unique identifier of the train IDtype
Table 8.80 – Route
8.3.1.2 Route-Programme
Route-Programme
N x Route Sequence of routes assigned to Array [Complex [Route]]
the train.
Table 8.81 – Route-Programme
8.3.2 Requests
8.3.2.1 Set Routing Mode in Signal

Command to activate or deactivate the automatic routing in signal.
GA 777465 Page 80 of 197

Command Set Automatic Routing in Signal

Signal Identifier to associate the signal. String
Mode Requested status. Listed [Automatic, Semi-
Automatic, Manual]
Table 8.82 – Set Automatic Routing in Signal
8.3.2.2 Set Routing Mode in Area

Command to activate or deactivate the automatic routing in area.
Command Set Automatic Routing in Area
Area Identifier to associate the area. String
Automatic, Manual]
Table 8.83 – Set Automatic Routing in Area
8.3.2.3 Set Routing Mode for Train

Command to activate or deactivate the automatic routing for a train.
Command Set Automatic Routing for Train
Train Identifier Identifier to associate the train. String
Automatic, Manual]
Table 8.84 – Set Automatic Routing for Train
8.3.2.4 Activate/Deactivate Automatic Succession

Command to activate or deactivate the automatic routing for a train.
Command Set Automatic Succession Routing for Train
Signal Identifier to associate the signal. String
Activate / Deactivate Requested status. Boolean
Table 8.85 – Activate/Deactivate Automatic Succession
8.3.3 Alarms
8.3.3.1 Inaccessible Route

Changes in the routing management or other event trigger the need to change the routing
sequence. The alarm points the inaccessible route.
Alarm Inaccessible Route
GA 777465 Page 81 of 197
Train Identifier Identifier to associate the train.

Route Identifier to associate the route.
Table 8.86 – Inaccessible Route
8.3.3.2 Rejected Route

Changes in the infrastructure trigger the need to change the routing sequence. E.g. it is not
possible to lock a switch or an unexpected track occupation. The interlocking rejects routes
because of this type of events. The alarm points the inaccessible route.
Alarm Rejected Route
Train Identifier Identifier to associate the train.
Route Identifier to associate the route.
Table 8.87 – Rejected Route

According to the definition of routing, to establish and manage routes, it is necessary information
involved in other systems:
• Infrastructure: In the decision of routes there are restrictions depending on the infrastructures
(switch type, platforms, gauges, etc.).
• Operation Plan: The routing needs the set of possible routes in each interlocking.
• Detected Values: The real time management for routing requires the punctual knowledge of
field, in the interlocking devices.
Traffic Management System (TMS): Temporary Speed Restrictions
8.4.1 Data
8.4.1.1 TSR
Temporary Speed Restriction
TSR ID Identification of the Temporary Speed Alphanumeric unique
Restriction identifier
Speed Value of the maximum allowed speed Numeric 0 - 600 km/h (1 km/h
for the TSR resolution)
Start location Kilometric Point of the start of the TSR Numeric (in cm)
Start track id Identifier of the track for the start of the Alphanumeric unique
TSR identifier
End location Kilometric Point of the end of the TSR Numeric (in cm)
End track id Identifier of the track for the end of the Alphanumeric unique
TSR identifier
List of track ID’s List of identifiers of all the tracks List alphanumeric unique
between start and end of the TSR identifiers
GA 777465 Page 82 of 197
Traction type Identifies traction type according to (see 7.5.1.86.1 of SRS 026
national specification NID_TRACTION)
Train category Identifies train category according to (see 7.5.1.84 of SRS 026
national specification NC_TRAIN)
Axle load category Identifies axle load category according (see 7.5.1.62 of SRS 026
to national specification M_AXLELOADCAT)
Cant deficiency Identifies cant deficiency according to (see 7.5.1.82.1 of SRS 026
national specification NC_CDIFF)
Loading gauge Identifies loading gauge according to (see 7.5.1.68 of SRS 026
national specification M_LOADINGGAUGE)
Hour of activation Hour when the TSR is activated Hour
Date of activation Date when the TSR is activated Date
Expected duration To be used for timetable forecasting Hours
Audited duration Time duration of the TSR to be audited Hours
Direction TSR applies to one or both directions Up / Down / both
Airtight TSR applies to train with/without not fitted / fitted / both
airtight system or both
Train length delay TSR is valid until front/rear end of train front / rear
passes the end of the TSR
Revocable Indicates if the TSR is revocable Yes / No
Text message Text message associated with the TSR text
Cause Cause for the TSR text
Text distance Distance in advance of the TSR to text
inform the driver
Responsible Person who activated the TSR text
Table 8.88 – Temporary Speed Restriction data
8.4.2 Requests
8.4.2.1 Establish a TSR

Speed Temporary Speed Numeric 0 - 600 km/h (1 km/h
resolution)
Start location Kilometric Point of the start of the Numeric (in cm)
TSR
Start track id Identifier of the track for the start of Alphanumeric unique identifier
the TSR
End location Kilometric Point of the end of the Numeric (in cm)
TSR
End track id Identifier of the track for the end of Alphanumeric unique identifier
the TSR
List of track ID’s List of identifiers of all the tracks List alphanumeric unique
between start and end of the TSR identifiers
Traction type Identifies traction type according to (see 7.5.1.86.1 of SRS 026
national specification NID_TRACTION)
GA 777465 Page 83 of 197

Train category Identifies train category according (see 7.5.1.84 of SRS 026
to national specification NC_TRAIN)
Axle load category Identifies axle load category (see 7.5.1.62 of SRS 026
according to national specification M_AXLELOADCAT)
Cant deficiency Identifies cant deficiency according (see 7.5.1.82.1 of SRS 026
to national specification NC_CDIFF)
Loading gauge Identifies loading gauge according (see 7.5.1.68 of SRS 026
to national specification M_LOADINGGAUGE)
Hour of activation Hour when the TSR is activated Hour
Date of activation Date when the TSR is activated Date
Direction TSR applies to one or both Up / Down / both
directions
Airtight TSR applies to train with/without not fitted / fitted / both
airtight system or both
Train length delay TSR is valid until front/rear end of front / rear
train passes the end of the TSR
Revocable Indicates if the TSR is revocable Yes / No
Text message Text message associated with the text
TSR
Cause Cause for the TSR text
Responsible Person who stablished the TSR text
Table 8.89 – Stablish a TSR
8.4.2.2 Activate a TSR

TSR ID Identification of an already Alphanumeric unique identifier
established TSR that is going to be
activated
Action Activates a TSR after being Activate
established, so after this action the
TSR is activated
Responsible Person who activated the TSR text
Table 8.90 – Activate a TSR
8.4.2.3 Deactivate a TSR

TSR ID Identification of the Temporary Alphanumeric unique identifier
Speed Restriction
Action Cancels the activation of a TSR No activate
after being established, so after this
action the TSR is removed from the
system
Responsible Person who deactivated the TSR text
GA 777465 Page 84 of 197

Table 8.91 – Deactivate a TSR
8.4.2.4 Remove a TSR

Speed Restriction
Action Prepares the system for the Remove
removal of a TSR
Responsible Person who removed the TSR text
Table 8.92 – Remove a TSR
8.4.2.5 Purge a TSR

Speed Restriction
Action Purges a TSR from the system after Purge
preparing it for the removal, so after
this action the TSR is removed
Responsible Person who purged the TSR text
Table 8.93 – Purge a TSR
8.4.2.6 Cancel the purge of a TSR

Speed Restriction
Action Cancels the purge of a TSR after No purge
preparing it from the removal, so
after this action the TSR continues
activated
Responsible Person who cancelled the TSR text
Table 8.94 – Cancel the purge of a TSR
8.4.3 Alarms
• TSR establishment rejection
• TSR activation rejection
• TSR remove rejection
• TSR purge rejection
• Fail of an equipment related to TSR
GA 777465 Page 85 of 197

Conflicts
8.5.1 Data
The aim of this chapter is to collect the information related to the conflicts which can occur in a
timetable.
The term conflict can be interpreted quite widely.
The objective of this section is to specify one class diagram able to define any type of warning,
error and conflict in a similar way, as a compiler produces its error and warning list:
• Invalid object link – the available reference points to a non-existing or invalid object in the
timetable, e.g. “NextTrip”-connection points to a cancelled trip.
• Invalid object value – an attribute of an object is not sufficient for the operation, e.g. available
TrainProtection-Attribute has value “ETCS-1” on the path including mandatory “ETCS-2” value.
• Limited resource – a set of objects require usage of a resource with limited capacity
concurrently, e.g. two trains plan to reserve the same track at the same time, or the same rolling
stock is allocated to several trips concurrently.
8.5.2 Conflict definition

Conflict Definition
Id Id of the conflict which shall be String
referenced by conflict
resolution.
IssuedTimestamp Time of validity of conflict Timestamp
definition. If one of the objects
defined in this conflict changed
afterwards, the conflict
definition is assumed as invalid.
ConflictType Defines the type of the conflict. Listed [InvalidLink,
InvalidValue,
LimitedResource]
Object Defines the path to the main Object Path according to CDM
object of the conflict: definition.
- Containing invalid data
link or
- Containing invalid data
value or
- Limited resource (e.g.
track)
InvalidAttributeId Defines the attribute id in Integer
Object providing invalid link or
invalid value.
ExpectedAttrValue Hint for the expected value for Any (double, string, int,
the invalid-object-value. enumerator)
GA 777465 Page 86 of 197

ConflictingObjectLinks The limited-resource conflict Object-Attribute Path

occurs if several objects use according to CDM definition
shared object concurrently. with maxOccurs=”unbounded”.
Usage can be identified as The order of conflicting objects
“linking”. In this attribute paths is according to the planned
with conflicting links are stored. sequence of limited-resource-
occupation.
Severity Defines the severity of the Listed [Warning, Error]
conflict. In case of Error the
train operation will be
impossible, in case of warning
probably not optimal.
ExpectedResolutionTime Most of the conflicts can be Timestamp
solved short before operation –
so the operator can structure
his work as required.
InvalidLinkReason There are several reasons for Listed
invalidity of a link – it could be [TemporaryNotAvailable,
- temporary not available NotAvailable,
(e.g. a track due to NotExisting]
maintenance)
- Not available (e.g. due to
cancellation)
- Not existing in IL (e.g.
reference to the not yet
planned or imported trip)
ObjectType The type of the main object as String [Module.ClassName]
defined by CDM. It can be used
to associate conflict resolution
to different systems in a
customer specific installation.
The object type is implicitly
encoded in the Object path.
JustificationRef Reference to Object with String [reference]
justification. It replaces the
common used error-codes.
Table 8.95 – Conflict definition
8.5.3 Conflict resolution

The conflict resolution represents part of the sandbox functionality. See [D8.4 In2Rail] for detailed
description of the Sandbox concept. The ChangeSet object contains an attribute changeReasons
of type sequence<string>, which can contain the set of IDs for conflicts.
GA 777465 Page 87 of 197

8.5.4 Railway specific examples
8.5.4.1 Insufficient length of a platform

Under assumption, that the Platform is specified in as Trip.Task.Platform-attribute, the assigned
platform could have not sufficient length. The conflict definition would look like this:
{
“Id”:”eea-ers”,
“conflictType”:”InvalidValue”,
..”object”:”/3/2[20180302]/2[2003]/5[#8]/2”, //Trip.Task.Platform
“objectType”:“TP.Platform”,
“invalidAttributeId”:5, //Trip.Task.Platform.length
“expectedAttributeValue”:”350”,
“severity”:”error”,
“expectedResolutionTime”:”11:20:00”
}
8.5.4.2 Rear collision/Crossing

The conflict detects a braking of a fast train (1205) by a slow one (2003) on Track t221. Assumption:
the planned trip contains a list of tracks to be used together with movement direction.
Trip
DirectedTrack
trackRef: string
dirUp: boolean
Figure 8.1 – Rear collision / Crossing Conflict sample
In this case the conflict is defined by using the same trackRef by two train at the same time. If the
collision is rear or crossing the client application can deduce from the dirUp-Attribute – if both are
true, it is a rear collision, if they are different, it is a crossing.
{
“Id”:”eea-e2”,
“conflictType”:”LimitedResource”,
..”object”:”/2/2[52]/2[t221]”, //reference to the track
“objectType”: “TP.Track”,
“severity”:”warning”, //the operation can continue if ARS works properly
“conflictingObjectLinks”: [
“/3/2[20180302]/2[2003]/3[#4]”, //Trip.Path.TrackIndex
GA 777465 Page 88 of 197

“/3/2[20180302]/2[1205]/3[#16]” //Trip.Path.TrackIndex
]
}
8.5.4.3 Missing next trip connection

Missing next trip connection, as the next trip is not in the timetable
{
“Id”:”eea-ers”,
“conflictType”:”InvalidLink”,
..”object”:”/3/2[20180302]/2[2003]/5[#8]”,
“invalidAttributeId”:6,
“invalidLinkReason”:”NotExisting”,
“severity”:”warning”,
“objectType”:”TT.ConnectionNextTrip”
}
8.5.4.4 Shared platform

Shared track t221 for trips 2003 and 1205.
{
..”object”:”/2/2[52]/2[t221]”,
“objectType”:”TP.Track”,
“/3/2[20180302]/2[2003]/4[#8]/2”,
“/3/2[20180302]/2[1205]/4[#3]/2”
]
}
8.5.4.5 Unavailable track due to closure

Trip 2003 is using unavailable track closed due to maintenance
{
“conflictType”:”InvalidLink”,
..”object”:“/3/2[20180302]/2[2003]/3[#6]”,
“invalidAttributeId”:2,
“invalidLinkReason”:”TemporaryNotAvailable”,
“objectType”:”TT.Trip”
}
GA 777465 Page 89 of 197

8.5.4.6 Unavailable track due to possession

Trip 2003 is using unavailable track closed due for possession
{
..”object”:”/2/2[52]/2[t221]”,
“objectType”:”TP.Track”,
“/3/2[20180302]/2[2003]/4[#8]/2”, //TTM.DailyTT.Trip.Track
“/5/2[20180302]/2[ps2212]/4[tr221]” //PossessionMgmt.Day.Possession.Track
]
}
8.5.5 Conflict management module

Conflicts show issues in some data set. Assuming each operator can work on a “local copy” of
RTTP the conflicts and conflicts resolutions are specific to his local copy. Therefore, the most
obvious way to integrate conflicts is to assign them to a sandbox and publish on dedicated
sandbox specific topic on the Integration Layer.
SandboxManagement
Sandbox
Conflict ChangeSet
Figure 8.2 – Integration of Conflicts in CDM
If a ChangeSet resolves some conflicts it can reference them by additional aggregation relation.
GA 777465 Page 90 of 197

TrainPositions Sandbox Restrictions

ChangeSets
Conflict detection
module
Sandbox
Conflicts
Figure 8.3 – Possible setup for a conflict detection module with Integration Layer
Possessions
8.6.1 Data
Data related to possession are defined according with the life-cycle of the possession and its
management in relation within the traffic management. In this sense, we have identified the
following entities associated to the possessions as a sub-set of information provided by the system
in charge of maintenance.
In order to improve the scheduling of the amount of works required, the following approach uses
the capacity to define possessions associated to each scope of works to be carried out in a
delimited area with the aim to allow improve the use of the affected infrastructure facilities when
the works are finished regardless several possession belong to a same business reference.
In case a possession is authorized periodically (such as Mondays from 04:00h-06:00h), according
with the scope of the traffic management, into the IL this authorization needs to be modelled as
several possessions with the same business reference but with the authorized start/end datetimes
related to each Monday. In the same way, the amount of works for a single day associated to a
business reference can be scheduled independently and generate several possessions.
This structure is also useful for defining independently several works each of them in a possession
related all them to the same maintenance activity, and therefore all of them with a common
business reference.
GA 777465 Page 91 of 197

In order to provide new business logic to traffic management, the following approach tries to
manage separately the data of the possession related to:
• General Data of the possession: Location, type and nature of works.
• Timetable and its evolution (scheduled, target and audited).
• Data related to the involved resources required for reparation (work team and rolling stock).
• Data related to the elements that needs to be repaired and the nature of the works required.
8.6.1.1 Possession
According with the life-cycle of the railway operations the works related to the possession are
scheduled temporally and several resources (staff or rolling stock) may be required for reparations.
These scheduled works are able to be modified if required by the operator of the traffic control,
establishing a new scheduled of works for the possession. These modification related to the time
where the works needs to be placed are collected as target data.
Scheduled data are based on the authorized time of the possession request, but target data
according with the status of the traffic and the availability of the resources may increase or reduce
the time window.
Despite this scheduling of works, the duration of the works may differ from the scheduled or target,
thus, audited data, register the real time where the works have taken place.
The works related to the possession usually involve in some way the use of other elements or
locations of the infrastructure during the time that the possession is in use. The following approach
defines the location of the possession through the identifiers of the signals protecting the entire
area (borders). As additional information for the TMS, the collection of the specific elements that
needs reparation and their main attributes may include as repairing elements.
Possession
General Data Borders, status and Complex [General Data]
additional information.
Possession Scheduled Working times defined Complex [Scheduled Data]
Timetable Data originally, when the
possession is notified by the
maintenance system
(authorized).
Possession Target Working times to be used in Complex [Target Data]
Timetable Data case that a modification is
required according with the
traffic situation.
Possession Audited Working times when the Complex [Audited Data]
Timetable Data works has been take place.
Repairing Elements Identification of the Array [Complex [Repairing Element]]
elements that need to be
repaired and information of
the status of the reparation.
GA 777465 Page 92 of 197

Involved Rolling Stock Additional information Array [Complex [Rolling Stock

related to the rolling stock Element]]
used during the repairing
works.
Involved Team Additional information Array [Complex [Team Worker]
related to the staff in charge
of the repairing actions and
their equipment.
Table 8.96 – Possession
8.6.1.1.1 General Data

The general data of a possession includes mainly the borders of the area included within the
possession and its status according to the life cycle of the system managing them.
Additionally it includes the source of the possession, the associated TSR and information
regarding its relation with other possessions.
General Data
Source Possession System or person who Listed [Maintenance System,
Data provides the data related to Signalling System, Traffic Operator]
the possession to the TMS.
Business Reference Business reference-key of String
the possession; multiple
possessions may share the
same business reference.
Possession Type Type of the possession, e.g. Listed [Maintenance, Complete
maintenance work, Closure]
complete closure.
Borders List of infrastructure Array [Element Identifier]
elements (signals)
protecting the area of the
possession.
Status Possible values during the Listed [Scheduled, Activated,
life cycle of the possession Working, Stopped, Finished,
Deactivated, Cancelled]
Possession Reason Description of the nature of String
the request requiring
possession.
Possession Approval It indicates that approval is Boolean
provided for a given
possession.
Deactivation Possible According with the nature of Boolean
the scope of work the traffic
operator from the control
centre is able to deactivate
the possession or not.
TSR ID Identifier of a TSR included 40 bytes alphanumeric unique
in the system by the TSR identifier
GA 777465 Page 93 of 197
management system
associated to the
possession (if any).
Table 8.97 – General Data
8.6.1.1.2 Scheduled Data

Data related to the time where the works are scheduled originally and notified to TMS. This data
is defined when the possession is registered according with the information available.
Scheduled Data
Possession Start Time Scheduled date time for the Timestamp
activation of the possession (the
operator from the control centre
establishes the signalling
restricted conditions).
Possession End Time Scheduled date time for the Timestamp
deactivation of the possession
(the operator from the control
centre re-establishes the
signalling normal conditions).
Works Start Time Scheduled date time for the Timestamp
beginning of the works (PICOP
is able to take possession of
involved elements).
Works End Time Scheduled date time for the Timestamp
conclusion of the works.
(PICOP is able to release
possession of involved
elements).
Possession Start Time Margin to advance/delay the Numeric
Margin datetime for the activation of the
possession.
Possession End Time Margin to advance/delay the Numeric
Margin datetime for the possession
deactivation.
Table 8.98 – Scheduled Data
8.6.1.1.3 Target Data

Data related to the updated datetime, when the possession are going to be place with the aim to
adjust if required the scheduled data to the traffic conditions and reduce the impact of the
possession.
Target Data
Possession Start Time Target date time for the Timestamp
activation of the possession.
GA 777465 Page 94 of 197
Possession End Time Target datetime for the Timestamp

deactivation of the possession.
Works Start Time Target datetime for the Timestamp
beginning of the works.
Works End Time Target datetime for the Timestamp
Possession Start Time Margin to advance/delay the Numeric
Margin target datetime for the activation
of the possession.
Possession End Time Margin to advance/delay the Numeric
Margin target datetime for the
possession deactivation.
Table 8.99 – Possession Target Data
8.6.1.1.4 Audited Data

Audited data related to the time where the possession has taken place. This information may be
automatically included according to events produced or registered manually by the traffic operator
from the control centre with coordination of the PICOP
Audited Data
Audited Possession Start Audited datetime for the Timestamp
Time activation of the possession.
Audited Possession End Audited datetime for the Timestamp
Time deactivation of the possession
Audited Works Start Time Audited datetime for the Timestamp
beginning of the works.
Audited Works End Time Audited datetime for the Timestamp
information.
Table 8.100 – Possession Audited Data
8.6.1.1.5 Repairing Elements

Data related to the specific element that are the cause of the possession and need to be repaired
or revised. This element has self-entity in the infrastructure. This information is accessory to the
possession into the TMS, but allow to provide detailed information for monitoring the progress of
the works. Not is mandatory repairing elements to stablish possession.
Repairing Element
Element Identifier Unique identifier of the String
infrastructure element that
requires repairing actions.
GA 777465 Page 95 of 197

Status of repairing work Indication if the work is in Listed [Not Started, Working,
progress or completed. Fixed, Cancelled]
Start Datetime Datetime when the element has Timestamp
been started to be repaired.
End Datetime Datetime when the element has Timestamp
been finished to be repaired.
Manager System System that controls the Listed [Signalling, Energy]
element.
Required Operation Description of the work nature to String
be solved in order to Required
operation about the refer
element
Protection Required Additional information related to Array [Complex [Protection
the safety measures required to Type, Location]]
accomplish the repairing works.
Ways of making sure that a line
is protected. This includes
keeping signals at danger,
placing detonators on the line,
using a track circuit operating
clip and showing a hand danger
signal.
Table 8.101 – Repairing Element
8.6.1.1.6 Rolling Stock Element

Data related to rolling stock required to support the scope of works defined into the possession in
case that it is informed. According with the stage of the operation this information may be provided
with more or less detail.
Rolling Stock Element
Rolling Stock Identifier Unique identifier to refer rolling String
stock in case of nominal data
available.
Rolling Stock Type The rolling stock used in the Listed [Locomotive, Ballast
possession, is of some kind Tamper]
defined.
Table 8.102 – Rolling Stock Element
8.6.1.1.7 Team Worker

Data related to workers involved in the possession. According with the stage of the operation this
information may be provided with more or less detail.
Team Worker
GA 777465 Page 96 of 197

Team Worker Identifier Unique identifier to refer the String

worker. In case of nominal data
available.
Possession Portable Portable device to control the String
Device Identifier infrastructure in the track.
Unique identifier to refer the
device. It is not mandatory that
the worker has one associated.
Team Worker Role The worker has a role Listed [PICOP, Driver,
associated for this possession. Technician]
Team Worker Company Company to which the worker String
belongs.
Professional Qualification Work for which the worker is Listed [Electrician, Welder]
able to do in the infrastructure.
Work Permit Holder Lines or zones allowed for work Array [Lines/Zones]
by the worked.
Table 8.103 – Team worker
8.6.2 Requests
The possessions are managed outside the TMS and its lifecycle is responsibility of the system
managing them. This system could be part of the maintenance system or be an intermediate entity
between the maintenance and the TMS. According to the situation of the works and the decision
of maintenance, the system in charge of managing the possession could receive from external
systems through the IL requests for creating, modifying, auditing or cancelling possessions.
8.6.2.1 Create Possession

Command to request a possession creation.
Command Modify Possession
General Data General Data of the possession. Complex [General Data]
Possession Scheduled Working times defined Complex [Scheduled Data]
Timetable Data originally, when the possession
is notified by the maintenance
system (authorized).
Repairing Elements Identification of the elements Array [Complex [Repairing
that need to be repaired and Element]]
information of the status of the
reparation.
Involved Rolling Stock Target list of rolling stock used Array [Complex [Rolling stock
during the possession. Not Element]]
mandatory.
Involved Team Target list of staff participating Array [Complex [Team
on the possession. Worker]]
Table 8.104 – Create Possession
GA 777465 Page 97 of 197

8.6.2.2 Modify Possession

Command to modify an existing possession created in the system in order to complete resources
involved or target data. The request could include the following data in addition to the mandatory
possession identifier.
Command Modify Possession
Possession Identifier of the possession to be String
modified.
General Data / Status Updated status of the Listed [Scheduled, Activated,
possession. Working, Stopped, Finished,
Deactivated, Cancelled]
General Data / TSR ID Modified TSR associated to the 40 bytes alphanumeric unique
possession. identifier
Possession Target In the modification, it is possible Complex [Timetable Data]
Timetable Data to replace or complete the data
concerned about the timetable
and resources involved into the
works (rolling stock and
workers) defined as scheduled
data.
Repairing Elements Identification of the elements Array [Complex [Repairing
that need to be repaired and Element]]
information of the status of the
reparation.
Involved Rolling Stock Target list of rolling stock used Array [Complex [Rolling stock
during the possession. Not Element]]
mandatory.
Involved Team Target list of staff participating Array [Complex [Team
on the possession. Worker]]
Table 8.105 – Modify Possession
8.6.2.3 Cancel Possession

Command to cancel an existing possession created in the system.
Command Cancel Possession
cancelled.
General Data / Status Request to indicate the status of “Cancelled”
the possession as cancelled
Audited End Time Allow to register the real hour Timestamp
where the works has been
cancelled as Possession End
Time (Possession Audited
Timetable Data / Audited
Possession End Time)
GA 777465 Page 98 of 197

Table 8.106 – Cancel Possession
8.6.2.4 Audit Possession

Command to modify an existing audited data, or to create new, for a possession, with a manual
procedure.
Command Audit Manually Possession
audited.
Possession Audited Allow to register the data Complex [Audited Data]
Timetable Data concerned the real hours where
the works has been take place.
Table 8.107 – Audit Manually
8.6.3 Alarms
8.6.3.1 Possession Cancelled

The system sets an alarm when a possession is cancelled.
Alarm Possession Finish
Possession Identifier associated to
possession.
Table 8.108 – Possession Cancelled
8.6.3.2 Possession Not Started on Time

The system sets an alarm when a possession does not start, when the "Target Possession Start
Time" is exceeded.
Alarm Possession Not Started
Possession Identifier associated to the
possession.
Table 8.109 – Possession Not Started
8.6.3.3 Possession Not Finished on Time

The system sets alarm when a possession does not finish, when the "Target Possession End
Time" is exceeded.
Alarm Possession Not Finished
Possession Identifier associated to the
possession.
GA 777465 Page 99 of 197

Table 8.110 – Possession Not Finished

According to the definition of possession, to establish and manage possessions, it is necessary
information involved in other systems:
• Trains: Possessions affect to one or more trains whose path is overlapping with elements
affected by possession.
• Rolling Stock: Depend on the possession, is required to assign rolling stock.
• Team works: Possessions have a team of workers assigned by role, professional qualification and
permit holder.
• Infrastructure: The possessions are fixed at elements in the infrastructure, and therefore is
required information about it.
Interlocking
8.7.1 Data
8.7.1.1 General Rules

• Every item must be uniquely identifiable
• Some items could be composed from other items
• Items are interrelated
• Items could have primary direction and could be usable in this or in both directions
• Items can get broken
o What could disable them
o What could limit functionality of the parent item
o What need not limit functionality of the parent item but requires handling
• Items could be locked in given state -- either by interlocking, TMS or manually
• Items could be under maintenance/repair
• Items can lost connectivity (either unidirectionally or bidirectionally)
8.7.1.2 Data Types

The following table (10.1) describes data types used further in description of interlocking items.
Data Types
Name Range / Remark
Base Type
IDtype Integer / Current base type can differ in different countries;
alphanumeric the domain should be large enough to be able to
hold all items in the domain;
It is necessary to discuss locality and construction of
the identifiers: at least in some countries they are
unique at station level, in other countries they could
be national-wide unique. Similarly, there can be
GA 777465 Page 100 of 197
differences in construction of the identifiers like

country-(area-) station-item; some identifiers could
have also additional information.
DirectionType enumerated Represent current direction assignment (left,
straight, right)
SignalExtentType flags proposal: bit 0 - traffic signal; bit 1 - shunting signal;
bit 2 - speed; bit 3 - indication; bit 4 - invalidation
DirectionChangeTyp enumerated
(set, asked4change, changing)
e
ExtendedRouteIdTy Integer /
valid route identifier or special value "for no route"
pe alphanumeric
PointType enumerated
Represent configuration of a point:
• simple variation to left
• simple variation to right
• triple switch
• crossing without change of direction
• crossing with double junction
• crossing with single junction
special version
ARSIndicationType enumerated intended to indicate what ARS is willing to do with
the route; it is especially important when routes
could be set both by people and by ARS;
proposed values:
• nothing - not intended to be handled soon

• planned - ARS plans to set up this route
soon
• delayed - ARS plans to set up this route
soon but there are some issues (e.g. the
route is not released yet)
... but it is delayed for safety reasons
• not-allowed - the route should be set up
soon but ARS is not allowed to do so
• waiting - ARS plans to set up the route soon
but some conditions must be fulfilled (e.g.
waiting for other train)
... but it is delayed for traffic reasons
Additional reasonable status values welcome.

ETCSlevelType enumerated ETCS levels according corresponding ERTMS
subset
(according ss026v3.4.0 they are: ETCS_level_0,
ETCS_level_NTC, ETCS_level_1, ETCS_level_2,
ETCS_level_3).
ETCSlevelListType flags for each ETCS level one bit indicating its support
GeoCoordinates composed Base: latitude and longitude in base system of the
country or in which it is measured + id of the
measurement system
ETRS-89 coordinates: latitude and longitude
GA 777465 Page 101 of 197
WGS-84 coordinates: latitude and longitude

LinearCoordinate integer Distance in centimetres form the beginning of the
track
RouteStatusType enumerated proposed values:
mandatory: no-route, route-setting, route-set, route-
releasing;
optional: route-blocked
RouteType enumerated train, shunting; there can be a mapping between
route ID and route type
SensingTypes flags individual bits indicating presence of sensor types:
e.g. hot box, hot tyre, wheel non-roundnes, ...
TrainSignalType enumerated absolute stop, permissive stop, warning, free; off,
nothing
off is intended to indicate that the signal should be
ignored;
nothing is intended as backward information that
no light is on (in some countries it has the meaning
of stop);
for requested values only the first five values
should be allowed
ShuntingSignalType enumerated inhibited, allowed; off, nothing
off is intended to indicate that the signal should be
ignored;
nothing is intended as backward information that
no light is on (in some countries it has the meaning
of stop);
for requested values only the first three values
should be allowed
LcControlType enumerated Independent, commanded
TrainIssueList Record list List of record containing axle nr (integer), side
(enumerated: left,right), and issue (enumerated –
sensed issue, like hot box, hot tyre, …)
IlxControlPlace integer ControlCenterID (special value – e.g. 0 – for local)
IlxControlTypes flags Specifies supported interfaces:
InDevice, LocalPersonal, LocalDriven,
DistantPersonal, DistantDriven
There can be more values specifying also extent of
the available functionality or other features (e.g.
distinguishing safety level of the control).
IlxItfType enumerated InDevice, LocalDedicatedUI, RemoteDedicatedUI,
SafeCommand, FullCommand, OpenUI.
SignalControlType enumerated Describes source of the signal command.
proposal: direct, route, autoblock, trigger
Table 10.111 – Data Types
8.7.1.3 Individual Items – Status
8.7.1.3.1 Track
GA 777465 Page 102 of 197

Track
Attribute Attribute description Admitted values Source
Unique identifier of the
ID IDtype assigned
track/line
DataValid Are the further data valid? Boolean interlocking
Is the given track/line
Occupance Boolean interlocking
occupied?
Trains being currently on
Trains TrainList interlocking
given track/line
Direction Currently assigned direction DirectionType interlocking
DirectionChange Status of direction assignment DirectionChangeType interlocking
could contain identifier of valid
AssignedRoute route or a special value for "no ExtendedRouteIdType interlocking
route set"
Table 10.112 – Track
8.7.1.3.2 Train Route

Train Route
RouteID Unique identifier of the train
IDtype assigned
route
RouteStatus Indicates status of the train
RouteStatusType interlocking
route; could vary for its parts
ARSIndication ARS indications; the data could
be either directly from source or ARS (could be
as a reflection of their ARSIndicationType in TMS or
interlocking image (what could interlocking)
be in some cases the same)
RouteParts full list of tracks/lines RoutePartsType interlocking
ValidRouteParts list of tracks/lines still assigned
to the route (could differ from
the previous one when the train RoutePartsType interlocking
already freed some parts of the
route)
AllowedRouting Allowed Routing Modes (the Set of values interlocking
Modes ones currently available for [Automatic, Semi-
use). Automatic, Manual]
Table 10.113 – Train Route
8.7.1.3.3 Signal
Signal
SignalID Unique identifier of the signal IDtype assigned
GA 777465 Page 103 of 197

SignalExtent what could this signal display? / SignalExtentType interlocking

what kind of signals can this
signal provide?
SignalControl How is the signal controlled SignalControlType interlocking
RequestedTrainSi What should be TrainSignalType interlocking
gnal displayed/indicated/signalled
DisplayedTrainSig What is really TrainSignalType interlocking
nal displayed/indicated/signalled
RequestedShunti What should be ShuntingSignalTyp interlocking
ngSignal displayed/indicated/signalled e
DisplayedShuntin What is really ShuntingSignalTyp interlocking
gSignal displayed/indicated/signalled e
RequestedImmedi what speed should be indicated integer interlocking
ateSpeed [in km/h]
DisplayedImmedi what speed is really indicated integer interlocking
ateSpeed [in km/h]
RequestedNextSp what speed should be indicated integer interlocking
eed for next section [in km/h]
DisplayedNextSp what speed is really indicated integer interlocking
eed for next section [in km/h]
What signals do not work flags interlocking
DetectedIssues
properly
8.7.1.3.4 Switch/Point
Switch/Point
Attribute Attribute description Admitted Source
values
SwitchID Unique identifier of the IDtype assigned
point/switch
GeoPosition geographical position of the GeoCoordinates asset mgmt
point
LinearPosition linear position of the point LinearCoordinate asset mgmt
related to the beginning of
the route
PointVariant determines configuration of PointType asset mgmt
the point
MaxSpeedLeft maximal speed for passing integer asset mgmt
the object when set to left
MaxSpeedStraight maximal speed for passing integer asset mgmt
the object when set to
straight
MaxSpeedRight maximal speed for passing integer asset mgmt
the object when set to right
MaxAxleLoad maximal axle load for float asset mgmt
passing the object
GA 777465 Page 104 of 197

IsSetAndLocked is the point safely set to Boolean interlocking

indicated direction?
IsLocked is the point physically Boolean interlocking
locked (cannot be
changed)?
IsPreset is the point designed to Boolean interlocking
automatically set in given
direction?
Direction What direction is set? DirectionType interlocking
IsMoving is the point just changing Boolean interlocking
direction?
Table 10.115 – Switch/Point
8.7.1.3.5 Train
Train
TrainID Unique identifier of the IDtype assigned
train
TrainNumber IM-related train number Integer interlocking
(the one displayed to
operators)
ShouldBeHeld should the train be Boolean interlocking
stopped and held? reflection of TMS
isARSallowed is automated route setting Boolean interlocking
allowed for this train?
isATOallowed is automated train Boolean interlocking
operation support allowed
for this train?
isATOcapable is the train able to use Boolean interlocking
ATO?
ETCSlevelSupported what levels of ETCS is ETCSlevelListType interlocking
the train capable?
ETCSlevelRunning what level of ETCS is the ETCSlevelType interlocking
train currently using?
Table 10.116 – Train
8.7.1.3.6 Axle Counter

Axle Counter
values
AxleCounterID Unique identifier of the IDtype assigned
axle counter
isActive Is the axle counter Boolean interlocking
active?
GA 777465 Page 105 of 197

isInactive Is the axle counter Boolean interlocking

inactive?
ConsistencyIssueDetected Consistency error Boolean interlocking
detected?
Table 10.117 – Axle Counter
8.7.1.3.7 Track Circuits

Track Circuits
values
TrackCircuitID Unique identifier of the IDtype assigned
track circuit
DataValid Are the further data Boolean interlocking
valid?
Occupied Track circuit is occupied Boolean interlocking
Free Track circuit is free Boolean interlocking
ConsistencyIssueDetected Consistency error Boolean interlocking
detected?
Table 10.118 – Track Circuits
8.7.1.3.8 Level Crossing

Level Crossing
values
LevelCrossingID Unique identifier of the level IDtype assigned
crossing
BarriersAvailable Are the barriers available/installed? Boolean interlocking
ControlPossible Is it possible to control this LC from Boolean asset mgmt
this interlocking?
StatusVisible is it possible to see status of this Boolean asset mgmt
LC from this interlocking?
CrossingBlocked Is the level crossing blocked? Boolean interlocking
LocalOperated Is the level crossing locally Boolean interlocking
operated?
BarriersOpen Are the barriers open? Boolean interlocking
BarriersClosed Are the barriers closed? Boolean interlocking
BarriersMoving Are the barriers moving? Boolean interlocking
BarrierHealth Are all the barriers ok? Boolean interlocking
CurrentControl How is the LC currently controlled LcControlType interlocking
Table 10.119 – Level Crossing
8.7.1.3.9 Train Sensor

Train Sensor
GA 777465 Page 106 of 197


values
TrainSensorID Unique identifier of the train sensor IDtype assigned
GeoPosition geographical position of the train GeoCoordinate asset mgmt
sensor s
LinearPosition linear position of the train sensor LinearCoordinat asset mgmt
related to the beginning of the route e
SupportedSensi supported sensing types Boolean asset mgmt
ng
DataValid Are the further data valid? Boolean sensor
AxleCount Number of detected axles integer sensor
DetectedIssues List of detected issues TrainIssueList sensor
Table 10.10 – Train Sensor
8.7.1.3.10 Fallen Object Detector

Fallen Object Detector
FodID Unique identifier of the fallen IDtype assigned
object detector
GeoPosition geographical position of the GeoCoordinates asset
FOD mgmt
LinearPosition linear position of the FOD LinearCoordinate asset
related to the beginning of the mgmt
route
DataValid Are the further data valid? Boolean sensor
FallenObjectDetected has been fallen object detected? Boolean sensor
DetectedIssues List of detected issues TrainIssueList sensor
Table 10.11 – Fallen Object Detector
8.7.1.3.11 Gauge Changer

Gauge Changer
GaugeChangerID Unique identifier of the gauge IDtype assigned
changer
GeoPosition geographical position of the GC GeoCoordinates asset mgmt
LinearPosition linear position of the GC related to LinearCoordinate asset mgmt
the beginning of the route
PrimaryDirection What is the primary direction Enumerated (g1- asset mgmt
g2, g2-g1)
isPrimaryDirection Is it set for primary direction? Boolean interlocking
isReady Is the device Ready? Boolean interlocking
Table 10.12 – Gauge Changer
8.7.1.3.12 Interlocking
GA 777465 Page 107 of 197

Interlocking
values
InterlockingID Unique identifier of the IDtype assigned
interlocking
AvailableInterfaces What interfaces are available? InterfaceList asset mgmt
ControlPlace From where it is controlled? IlxControlPlace interlocking
ControlMeans How it could be controlled? IlxControlTypes interlocking
ActiveInterfaces What interfaces are used? flags interlocking
Table 10.13 – Interlocking
8.7.1.3.13 Interlocking Interface

Interlocking Interface
values
InterlockingInterfaceID Unique identifier of the interlocking IDtype assigned
interface
InterlockingID Identifier of the interlocking to which IDtype assigned
the interface is connected
InterfaceType What kind of interface it is? IlxItfType assigned
AvailableDirections What directions are supported? integer asset mgmt
Proposal: 01 out, 10 in, 11 bidi.
UsedDirections What directions are in use? Proposal: integer interlocking
00 off, 01 out, 10 in, 11 bidi
Table 10.14 – Interlocking Interface
8.7.2 Requests
The intents for changing behaviour or status of interlocking could be grouped into at least the
following levels:
1. clear changes that do not negatively influence safety situation.
2. changes that need to be done carefully (e.g. they do not mean safety issue but probably can later
cause other issues)
3. changes that weaken safety measures (i.e. they must be done on someone's explicit
responsibility)
8.7.2.1 General Rules

• Every item must be uniquely identifiable.
• Every service/data request sent by TMS to ILX must be uniquely identifiable.
• Some items could be composed from other items.
• Items are interrelated.
• Items can be locked physically or logically; locks can be of various meaning.
GA 777465 Page 108 of 197

• Safety measures could vary; some could be set by national legislative or could be infrastructure-
manager dependent.
• Data sent by TMS to ILX are generally of two possible natures:
1. request - TMS states what it needs and the ILX can reject the request immediately or try
to apply and then report the result. ILX can ask for acknowledgement of the request. The
importance of the acknowledgment and the means used for it could vary. The reporting
can be provided directly (by answering the request) or indirectly (by appropriate
changing of system status).
2. Information (not necessarily supported in all systems).
• Protocol schemata:
1. TMS sends a request, ILX acknowledges it or changes its state (can be recognized from
the state sent regularly form ILX to TMS)
2. TMS sends a request, ILX rejects it (in the case that the operation is not possible or safe
yet) TMS sends a request, ILX sends (optionally) some information and asks for
acknowledgment; TMS can reject it (and then the request is cancelled) or send the
acknowledgment and ILX will try to fulfil it. It is possible that the request could be still
rejected (e.g. something happened in the meantime so the request became more
dangerous than when sent first, something could get broken or locked).
3. The same in point 3 but ILX asks not for acknowledgment but for taking explicit
responsibility for something critical (usually requiring more complex acknowledgment
like special reply from the user).
• Sent data should be small and of some reasonable frequency only -- it should not be possible to
congest ILX with requests.
8.7.2.2 Individual Requests

For any of the request types below some level of acknowledgment shall be set. Its minimal level is usually
determined by national legislative or by rules set by responsible infrastructure manager. In some countries
some requests can be handled without acknowledgment.
8.7.2.3 Train Route
8.7.2.3.1 Set train route Request

Set Train Route Request
values
RouteID Unique identifier of the train route (probably assigne
IDtype
inclusive area id and station id) d
TrainID Unique identifier of the train (train ID or IDtype assigne
(extended) train number) d
TrainLengt Train length (optional value; useful especially
Integer TMS
h when longer than assigned line)
Table 10.15 – Set Train Route Request
GA 777465 Page 109 of 197

8.7.2.3.2 Release Train Route Request

Release Train Route Request
Attribut Attribute description Admitted Source
e values
RouteID Unique identifier of the train route (probably
IDtype assigned
inclusive area id and station id)
TrainID Unique identifier of the train (train ID or IDtype assigned
(extended) train number)
Table 10.16 – Release Train Route Request
8.7.2.4 Train handling
8.7.2.4.1 Track Creation Request

Train Creation Request
values
TrainID Unique identifier of the train IDtype assigne
d
TrackPartID Unique identifier of track part, where IDtype assigne
the train (or at least its leading d
vehicle) is
PositionOnTrackP Placement of the new train on the Integer TMS
art track part; it is necessary if there is
already another train (or more of
them); when creating first train there it
could be optional
Position is counted from left to right:
0 … on the left from existing leftmost
train, 1 … between leftmost and
second leftmost, etc.
TrainLength Train length (optional value; useful
especially when longer than assigned Integer TMS
line)
Table 10.17 – Train Creation Request
8.7.2.4.2 Train Split Request

Train Split Request
values
OriginalTrainID Unique identifier of the train IDtype assigne
d
TrackPartID Unique identifier of track part where the IDtype assigne
train (or at least its leading vehicle) is d
TrainParts List of new trains (their IDs, optionally also
TrainList TMS
directions) ordered from left to right
Table 10.18 – Train Split Request

GA 777465 Page 110 of 197
8.7.2.4.3 Train Coupling Request

Train Coupling Request
values
NewTrainI Unique identifier of the train IDtype assigne
D d
TrackPartI Unique identifier of track part, where the IDtype assigne
D trains are d
TrainParts List of the trains to be coupled (their IDs)
TrainList TMS
ordered from left to right
Table 10.19 – Train Coupling Request
8.7.2.4.4 Train Renumbering Request

Train Renumbering Request
values
OldTrainID Unique identifier of the train IDtype assigne
d
NewPartID Unique identifier of the train IDtype assigne
d
TrackPartI Unique identifier of track part where the train
IDtype TMS
D is
Table 10.20 – Train Renumbering Request
8.7.2.4.5 Train Cancellation Request

Train Cancellation Request
values
TrainID Unique identifier of the train IDtype assigne
d
TrackPartI Unique identifier of track part where the train
IDtype TMS
D is
Table 10.21 – Train Cancellation Request
8.7.2.5 Direct Asset Manipulation

Direct control over individual items (point machines, derailers ...)
General Setting
• full item identification
• current item state
• desired item state
The current state could be in some settings optional -- it is for being sure that the requesting application
is aware of the current state (that the request is not outdated).
GA 777465 Page 111 of 197

Direct Asset Manipulation Template

values
AssetID Unique identifier of the asset to be IDtype assigne
directly manipulated d
OldState Current state of the asset (optional – AssetStateType ILX
important for checking validity of the
request)
RequestedStat Requested state of the asset
AssetStateType TMS
e
Table 10.22 – Direct Asset Manipulation Template
8.7.2.6 Locks and Flags

There could be multiple status indicators influencing behaviour of and allowed activities for
individual interlocking objects. Some of them block their use until remove (locks), some of them
can be overridden (flags).
It appears that there are different locks and flags in different countries.
It can (and should) be therefore discussed whether to have general functions for setting and
releasing locks and flags or to have tailored ones.
8.7.2.6.1 Set Lock

Set Lock Template
values
ItemID Unique identifier of the item to be locked IDtype assigne
d
WhatLock Identifies the lock type LockType TMS
AdditionalInfo Additional information (remark) Text TMS
Table 10.23 – Set Lock Template
8.7.2.6.2 Release Lock

Release Lock Template
values
ItemID Unique identifier of the item to be IDtype assigne
unlocked d
WhatLock Identifies the lock type LockType TMS
Table 10.24 – Release Lock Template
8.7.2.6.3 Set Flag

Set Flag Template
values
GA 777465 Page 112 of 197

ItemID Unique identifier of the item to be flagged IDtype assigne

d
WhatFlag Identifies the flag type FlagType TMS
AdditionalInfo Additional information (remark) Text TMS
Table 10.25 – Set Flag Template
8.7.2.6.4 Release Flag

Release Flag Template
values
ItemID Unique identifier of the item to be IDtype assigne
unflagged d
WhatFlag Identifies the flag type FlagType TMS
Table 10.26 – Release Flag Template
8.7.3 Alarms
Something needs priority handling; this communication is originated by ILX but the response from
TMS is expected.
• Something get broken
o alarm id
o full item identification
o error status
This alarm can require more time to resolve; it is therefore possible that some system could require
multiple acknowledgements: one for accepting the information, one for making the workabouts
and one for fixing the situation. The handling could also depend on the severity of the issue
• Acknowledgement of a request
o request id
o message
o acknowledgment type
• Something timed out
o alarm/request id
o notification message
o acknowledgment type
8.7.3.1 Alarm Responses

• Alarm Acknowledgement
o alarm/request id
• Request Acknowledgement Rejection
o request id
GA 777465 Page 113 of 197

Radio Block Centre (RBC)
8.8.1 Data
8.8.1.1 Position Report

Position Report
Mode Operation mode FS, OS, SR (See SRS
026)
Level ERTMS level 0, STM, 1, 2, 3
Estimated front end Location in the line of the estimated ≥0
front end
Estimated rear end Location in the line of the estimated ≥0
rear end
Most restrictive front end Location of the most restrictive front ≥0
end
Most restrictive rear end Location of the most restrictive rear ≥0
end
Least restrictive front end Location of the least restrictive front ≥0
end
Least restrictive rear end Location of the least restrictive rear ≥0
position end
Train length Length of the train [m] ≥0
Speed Current train speed, [km/h] ≥0
Direction Direction of train movement of the Up/Down/Unknown
train
Integrity confirmed Qualifier that indicates if the train true / false
integrity is confirmed
Length to last confirmation See "LTRAININT" in SRS 026 ≥0
of integrity
Service operational identifier of the operational number of Alphanumeric
number the train
Operational number Train running number Alphanumeric
ETCS identifier Onboard ETCS ID Alphanumeric
Table 8.120 – Position Report
8.8.1.2 Movement Authority

Movement authority
Length of sections See Packet 15 SRS 026, length ≥0
of the sections included in the
MA
Limit of authority Limit of Authority Speed, See ≥0
speed SRS 026
Operational number Train running number Alphanumeric
GA 777465 Page 114 of 197
Table 8.121 – Movement Authority
8.8.1.3 Emergency Stop

Emergency stop
Position of Location in the line of the ≥0
emergency stop emergency stop
Type Indicates whether the emergency true / false
stop is conditional or not
Accepted If the train stop is conditional, true / false
indicates if the train has accepted it
Acknowledgement If the emergency stop is true / false
unconditional, indicates if the train
has acknowledge it
Table 8.122 – Emergency Stop
8.8.1.4 Adhesion factor

Adhesion factor
Position of start of Location in the line of the start of a ≥0
low adhesion area low adhesion area
Length Length of the low adhesion area [m] ≥0
Adhesion factor Percentage of the low adhesion factor 0-1
Table 8.123 – Table title
8.8.2 Requests
8.8.2.1 Emergency Stop

Emergency Stop
Operational Train running number Alphanumeric
number
Position of Location in the line of the emergency ≥0
emergency stop stop
Type Indicates whether the emergency stop true / false
is conditional or not
Table 8.124 – Set an emergency stop
8.8.2.2 Low adhesion area

Low adhesion area
GA 777465 Page 115 of 197

Position of start of Location in the line of the start of a low ≥ 0

low adhesion area adhesion area
Length Length of the low adhesion area [m] ≥0
Adhesion factor Percentage of the low adhesion factor 0-1
Position of start of Location in the line of the start of a low ≥0
low adhesion area adhesion area
Table 8.125 – Set a low adhesion area
8.8.2.3 Set a route

Set a route
Route ID Identifies the route that should be set 40 bytes alphanumeric unique
identifier
Route type In what 'mode' the route should be set Main route, shunting route,
warning route, on-sight/call-on
route, staff responsible route
Commanded state State of the command command is for pre-selection,
command is for route setting,
command is for route setting
overriding restrictions
Overlap Overlap to be set with the route 0x00 to 0xFE
Flank protection With or without flank protection With, without, not specified
Electrified Type of electric feeding at the end of electrified, non-electrified, for
Destination the route electric train, not specified
Command User Who has initiated the command ARS, other, not specified
Table 8.126 – Set a route command
8.8.3 Alarms
At least the following alarms have been detected related to RBC:
• Unconditional Emergency Stop sent
• Conditional emergency Stop Sent
• Unconditional Emergency Stop sent Acknowledged by the train
• Integrity Lost / Recovered

The following data will be required for this system:
• Estimated time of arrival (ETA)
• Activated Temporary Seed Restrictions (location, speed)
• State of catenary
GA 777465 Page 116 of 197

Trackside Automatic Train Operation (ATO)
8.9.1 Data
8.9.1.1 Journey Profile

A Journey Profile defines the operational elements for the ATO-OB to execute the Train Service.
A Journey Profile contains the following information:
1. Status of the Journey Profile;
2. Train route data including a list of:
• Segment Profile identifier to be travelled by the ATO-OB in the order defined by the train
movement.
• Segment Profile version;
• Segment Profile travelling direction which is needed for the onboard to determine if the
corresponding Segment Profile will be travelled in nominal or reverse direction.
3. Operational data including a list of:
• Timing Point identifier (time references of Timing Points in shall be listed in chronological
order.)
• Arrival time and tolerance;
• Timing Point alignment;
• Day light saving hour information;
• Timing Point type (Timing points can be of the type : Stopping point1, Stopping point to be
skipped, Passing Point);
• Additional Timing Point information;
• End of Journey.
• Departure time;
• Train hold information;
• Minimum dwell time;
• Doors management information;
4. Dynamic infrastructure data required to operate (Temporary Constraints) including a list of:
• Temporary Constraint type (ASR, Low Adhesion, ATO Inhibition Zone or DAS Inhibition Zone);
• Temporary Constraint location;
• ASR speed level and a qualifier which indicates if the supervision of the end of the speed
restriction relates to the front or the rear end the train;
• Low adhesion rate (if applicable).
1Stopping point refers to the Stop point described in Chapter 6 – Infrastructure. The naming should be
aligned with ATO WP and Subset-126 / Subset -125.
GA 777465 Page 117 of 197

All location information is referred to a Segment Profile ID and given as a distance from the
beginning of that SP, unless otherwise specified.
The Journey Profile identifies, for each Stopping Point, if the ATO-OB must manage train doors
opening (including the sides for opening the doors) and train doors closing.
The identifier of a Timing Point is composed of a country/region identity number and a TP identity
number within the country/region.
The ASR includes any TSR defined by the ETCS and may include any operational speed
restriction requested by IM or RU.
The Journey Profile, sent from the ATO-TS, identifies Stopping Points for train from the list of
Timing Points included in the Segment Profile and if the train must align to a Stopping Point with
its front, its middle or its rear end.
ATO requires synchronization with UTC time.
Variables have one of the following prefixes:
Prefix Explanation
A_ Acceleration
D_ Distance
G_ Gradient
L_ Length
M_ Miscellaneous
N_ Number
NC_ Class Number
NID_ Identity Number
Q_ Qualifier
T_ Time/date
V_ Speed
X_ Text
Table 8.127 – Prefixes of the Variables
[N_ITER] specifies the number of iterations of a variable or group of variables which follow.
If [N_ITER] is 0 then no variables follow.
GA 777465 Page 118 of 197

Attribute Attribute Description Admitted values

Status of the Journey ATO TMS is continuously Valid: JP containing the data
Profile [Q_JP_Status] broadcasting updated JP requested.
information. Unavailable: JP specifies that the
The Generation of the status of the requested part of the
JP is an ATO-TS internal function. Journey Profile is currently
The ATO-TS must determine the not available yet (but all the
Attribute based on the state of previously sent JPs are still
information available from applicable).
Integration Layer or internally Invalid: JP specifies that the TP
stored data identifier asserted in the
JPReq does not belong to
the preceding JP already
sent to the ATO-OB.
Update: JP specifies that the
Journey Profile has been
updated by the TMS within
the current visibility of the
ATO-OB.
Number of SPs. ATO-TS need to generate this Binary to numeric
[N_ITER_SP] information as an internal function
Identity of the SP’s Data to be available in JP Topic 10 bits
country or region
[NID_C (k)]
SP identity [NID_SP (k)] Data to be available in JP Topic Binary to numeric.
32 bits
Identifier of the Data to be available in JP Topic 1 byte for the major version and
segment profile 1 byte for the minor one.
version [M_SP_Version (k)] Determine compatibility of
versions for the ATO -OB
Qualifier to indicate Data to be available in JP Topic 0 = Reverse
the valid travelling 1 = Nominal
direction of the SP
[M_SP_Version (k)]
Number of iterations ATO-TS need to generate this
of TPs information information as an internal function
[N_ITER (k)]
TP identity. Data to be available in JP Topic Binary to numeric.
[NID_TP (k,l)] 32 bits
Date of the requested Data to be available in JP Topic Value from 0 (01/01/2010) to
arrival time at the TP. 32767 (18/09/2099)
[T_Latest_Arrival_Date (k,l)]
GA 777465 Page 119 of 197


Arrival time at the TP Data to be available in JP Topic Value from 0 (00:00:00) to 86399
in seconds (23:59:59) and 131071 for
[T_Latest_Arrival_Seconds undefined arrival time.
(k,l)]
Acceptable time Data to be available in JP Topic Binary to numeric (in seconds).
allowance to be The value is 0 for Stopping
earlier at the TP. Points.
[T_Arrival_Window (k,l)]
Qualifier defining if Data to be available in JP Topic 0 = Front
the TP location is 1 = Middle
applicable from the 2 = Rear
front, middle or rear of 3 = Spare
the train
[Q_TP_Alignment (k,l)]
TP Definition Data to be available in JP Topic 0 = Stopping point
[Q_Stop_Skip_Pass (k,l)] 1 = Stopping Point to be skipped
2 = Passing Point
Specific Information ATO-TS need to generate this 0 = No specific information,
for the TP. information as an internal function 1 = End of Journey
[Q_TP_Information (k,l)]
Daylight saving hour Data to be available in JP Topic 0 = No saving hour
[Q_Day_Light_Saving (k,l)] 1 = Saving hour
Date of the expected Data to be available in JP Topic Value from 0 (01/01/2010) to
departure time from 32766 (17/09/2099) and 32767
the Stopping Point. for undefined departure time.
[T_Departure_Date (k,l))
Dwell time in seconds Data to be available in JP Topic Value from 0 (00:00:00) to 86399
from scheduled arrival (23:59:59) and 131071 for
time to scheduled undefined departure time.
departure time
[T_Departure_Seconds (k,l)]
Command to hold Data to be available in JP Topic 0 = Do not hold Train
train at stopping point 1 = Hold Train.
[Q_Train_Hold (k,l)]
Minimum dwell time at Data to be available in JP Topic Binary to numeric (in seconds)
given Stopping Point (may be dynamically updated) 10 bits
[T_Minimum_Dwell_Time (k,l)]
Individual Door Data to be available in JP Topic 00 = none
Opening 01 = right
[Q_Opening_Door_Side (k,l)] 10 = left
11 = both
GA 777465 Page 120 of 197


Centralized Door Data to be available in JP Topic 0 = Opening by passengers
Opening 1 = Centralized automatic
[Q_Centralised_Opening (k,l)]
Door Closing Data to be available in JP Topic 0 = ATO-OB not to manage train
[Q_Automatic_Closing (k,l)) doors closing 1=
ATO-OB to manage train doors
closing
Number of iterations ATO-TS need to generate this
of Temporary information as an internal function
Constraints
[N_ITER (k)]
Reason for the Data to be available in JP Topic 0 = ASR
temporary constraint. 1 = Low Adhesion
[Q_TC_Type (k,m)] 2 = ATO Inhibition Zone
3 = DAS Inhibition Zone
Status Change of the Data to be available in JP Topic 0 = Start
temporary constraint 1 = Ends
at a location 2 = Starts/Ends
[Q_TC_Range (k,m)] 3 = Covers Whole SP
Location of the start of Data to be available in JP Topic Binary to numeric (in
the temporary centimeters)
constraint relatively to
the beginning of the
SP.
[D_TC_Start_Location (k,m)]
Location of the end of Data to be available in JP Topic Binary to numeric (in
the temporary centimeters)
constraint relatively to
the beginning of the
SP
[D_TC_End_Location (k,m)]
Speed Limit Qualifier Makes no sense. 0 = End of the train
(Indicate if a speed limit Should be always End of the train 1 = Front of the train
given for a profile
element is to be applied
until the front or the end
of the train has left the
indicated section)
[Q_FRONT (k,m)]
Value of the speed Data to be available in JP Topic [0..120] x 5 km/h [0..600]
level restriction km/h ; [121-126] = Spare
[V_Speed_Level (k,m)]
GA 777465 Page 121 of 197


Value of the braking Data to be available in JP Topic 0 = 100%
capacity remaining in May be dynamic Data coming 1 = 90%
Low adhesion from integration of Weather info 2 = 80%
condition into the JP 3 = 70%
[Q_Low_Adhesion_Rate 4 = 60%
(k,m)]
5 = 50%
6 = 40%
7 = 30%;
Table 8.128 – Journey Profile
8.9.1.2 Segment Profile

A Segment Profile contains static infrastructure data required for Automated Train Operation.
Content of the Segment Profile:
• Segment Profile identifier;
• Segment profile version;
• Segment Profile Status;
• Length of the SP;
• Distance to stop in rear of an EOA;
• Offset to compute the local time from the UTC time;
• Altitude at the beginning of the SP;
• Static Speed Profile;
• Gradient Profile;
• Curve Profile;
• Traction system information;
• Allowed current consumption.
The SP contains:
• For Balises:
o BG identifier;
o Position of the balise in the balise group;
o Balise location.
• For Timing Points:
o TP Identifier;
o TP Location;
o Stopping tolerance;
o Stopping Point Reached distance;
o TP Name.
• Information on:
o Platform areas;
GA 777465 Page 122 of 197
o Tunnels;
o Powerless sections;
o Axle Load Speed Profiles;
o Stopping points in rear of an unprotected level crossing;
o Permitted Braking Distance;
o Switch off Regenerative Brake areas;
o Switch off eddy current brake for service brake areas;
o Switch off eddy current brake for emergency brake areas;
o Switch off Magnetic Shoe Brake areas.
The identifier of a Segment Profile is composed of a country/region identity number and an identity
number within the country/region.
A SP may be used in nominal or reverse direction. The nominal direction of a SP is defined by the
direction from beginning to end. It is an engineering decision.
The Segment Profile definition shall ensure that two consecutive SPs are contiguous, i.e. there is
no location gap nor overlap between them.
All location information shall be given as a distance from the beginning (nominal direction) of the
Segment Profile, unless otherwise specified.
The distance to stop in rear of an EOA shall be given as a distance from the EOA.
Each SP shall have a unique identity number within an ETCS NID_C area.
The Segment Profile shall have a version number to detect if the Infrastructure Manager has
brought some changes i.e. if a Segment Profile stored in the ATO-OB has become obsolete.
For each data type, the list of items shall be included in increasing order of location starting from
the beginning of the Segment Profile.
Number SPs in the packet.
[N_ITER]
Identity of the SP’s country or Data to be available in SP
region Topic
[NID_C (k)]
SP identity Data to be available in SP 32 bits
[NID_SP (k)] Topic
Status of the SP Not necessary to be 0 = Invalid (SP not found in
[Q_SP_Status (k)] available as Data on IL, ATO-TS database.
TMS provides always the 1 = Valid (SP requested)
updated version, whilst the
“elder” versions may be
persistent on IL
GA 777465 Page 123 of 197


SP Version To be analysed with ATO 1 byte for the major version
[M_SP_Version (k)] WP if necessary in SP and 1 byte for the minor one.
Topic
Length of the segment of railway Data to be available in SP Binary to numeric (in
covered by the SP Topic centimeters)
[L_SP (k)] 24 bits
Distance to stop the train before Data which may be Binary to numeric (in
an EoA available in SP Topic To centimeters)
[D_EoA_Offset (k)] be analysed with ATO WP 24 bits
if necessary in SP Topic
Offset to add to the UTC time in To be analysed with ATO Binary to numeric
to calculate the local time WP if necessary in SP Signed value
[Q_UTC_Offset (k)] Topic Resolution: 15min
-48 = UTC - 12:00
0 = UTC ± 0
56 = UTC + 14:00
(-63) - (-49) = Spare
57 - 63 = Spare
Altitude at the beginning of the To be analysed with ATO Binary to numeric (in
SP. Considering ETRS89 as WP if necessary in SP centimetres) starting at -1000
reference Topic or if it can be fixed m Needed to compute
[M_SP_Altitude (k)] value in ATO-TS traction effectiveness of
Diesel Locomotives
Basic Static Speed Profile Data to be available in SP [0 -120] x 5 km/h
speed at the beginning of the Topic <=> [0-600] km/h
Segment Profile [121-126] = Spare
[V_STATIC (k)]
Qualifier to indicate if the Static Data should be generated 0 = Train length delay
Speed Profile is to be applied to from ATO-TS depending 1 = No train length delay
the front of the train (no train on sequence of the SP Q_FRONT is an attribute for the speed
value. It defines what to do at the end of
length delay) or to the end of the and the propriety speed the corresponding section if the next
train (train length delay indication for the segment. speed value is a “step up”.
[Q_FRONT (k)] To be agreed/clarified with
ATO WP
Number of iterations of Specific Data should be generated
Speed Profiles from ATO-TS depending
[N_ITER (k)] on sequence of the
Specific Speed Profiles
GA 777465 Page 124 of 197


Indicates the type of specific Data needs to be available
SSP category on SP
[Q_DIFF (k,l)] 0 Cant Deficiency specific category
In case of “other specific” SSP, it tells 1 Other specific category, replaces
ERTMS/ETCS on-board equipment whether the Cant Deficiency SSP
it replaces or not the Cant Deficiency SSP 2 Other specific category, does not
as selected by on-board when the train replace the Cant Deficiency SSP
belongs to an “other international” train 3 Spare
category to which the “other specific” SSP
applies
“Can’t Deficiency” SSP category Data needs to be available 0 Cant Deficiency 80 mm
1 Cant Deficiency 100 mm
for which a different value for the on SP
static line speed exists 3 Cant Deficiency 150 mm
[NC_CDDIFF (k,l)] 4 Cant Deficiency 165 mm
Used together with V_DIFF to permit certain 5 Cant Deficiency 180 mm
trains to go faster or lower than the 6 Cant Deficiency 210 mm
“international basic static speed” given by 7 Cant Deficiency 225 mm
V_STATIC. 8 Cant Deficiency 245 mm
11 - 15 Spare
“other specific” SSP category for Data needs to be available
which a different value for the on SP
static line speed exists 0 Specific SSP applicable to
[NC_DIFF (k,l)] Freight train braked in “P”
Used together with V_DIFF to permit trains position
belonging to the corresponding “other
1 Specific SSP applicable to
international” train category to go faster or
Freight train braked in “G”
lower than the “international basic static
position
speed” given by V_STATIC.
Value 0 of NC_DIFF corresponds to the LSB
Passenger train
of NC_TRAIN, value 14 of NC_DIFF to MSB
3- Spare
(15-bit variable) of NC_TRAIN.
15
Absolute Positive Speed Data needs to be available [0 -120] x 5 km/h
associated to a train category on SP <=> [0-600] km/h
[V_DIFF (k,l)] [121-126] = Spare
Number of iterations of Static Data should be generated
Speed Profiles from ATO-TS depending
[N_ITER (k)] on sequence of the
Specific Speed Profiles
Location of the Static Speed Data needs to be available Binary to numeric (in
Profile change relatively to the on SP centimetres)
beginning of the SP. 24 bits
[D_Location (k,m)]
GA 777465 Page 125 of 197


Basic Static Speed Profile Data needs to be available 7 Bits
speed on SP Minimum: 0 km/h
[V_STATIC (k,m)] Maximum: 600 km/h
Resolution: 5 km/h
Qualifier to indicate if the Static Data should be generated 0 = Train length delay
Speed Profile is to be applied to from ATO-TS depending 1 = No train length delay
the front of the train (no train on sequence of the SP Q_FRONT is an attribute for the speed
value. It defines what to do at the end of
length delay) or to the end of the and the propriety speed the corresponding section if the next
train (train length delay). indication for the segment. speed value is a “step up”.
Q_FRONT (k,m) To be agreed/clarified with
ATO WP
Number of iterations of Specific Data should be generated
Static Speed Profiles from ATO-TS
[N_ITER (k,m)] To be agreed/clarified with
ATO WP
Specific SSP category Data needs to be available
[Q_DIFF (k,m,n)] on SP
In case of “other specific” SSP, it tells 0 Cant Deficiency specific category
ERTMS/ETCS on-board equipment whether 1 Other specific category, replaces
it replaces or not the Cant Deficiency SSP the Cant Deficiency SSP
as selected by on-board when the train 2 Other specific category, does not
belongs to an “other international” train replace the Cant Deficiency SSP
category to which the “other specific” SSP 3 Spare
applies
the “Cant Deficiency” SSP Data needs to be available 0 Cant Deficiency 80 mm
category for which a different on SP
value for the static line speed 3 Cant Deficiency 150 mm
exists. 4 Cant Deficiency 165 mm
[NC_CDDIFF (k,m,n)] 5 Cant Deficiency 180 mm
In case of “other specific” SSP, it tells 6 Cant Deficiency 210 mm
ERTMS/ETCS on-board equipment whether 7 Cant Deficiency 225 mm
it replaces or not the Cant Deficiency SSP 8 Cant Deficiency 245 mm
as selected by on-board when the train 9 Cant Deficiency 275 mm
belongs to an “other international” train 10 Cant Deficiency 300 mm
category to which the “other specific” SSP 11 - 15 Spare
applies
GA 777465 Page 126 of 197


“other specific” SSP category for Data needs to be available
which a different value for the on SP
static line speed exists. 0 Specific SSP applicable to
[NC_DIFF (k,m,n)] Freight train braked in “P”
Used together with V_DIFF to permit trains position
belonging to the corresponding “other
international” train category to go faster or
lower than the “international basic static
position
speed” given by V_STATIC.
Value 0 of NC_DIFF corresponds to the LSB
Passenger train
of NC_TRAIN, value 14 of NC_DIFF to MSB
3- Spare
(15-bit variable) of NC_TRAIN.
15
Absolute Positive Speed Data may be available on [0 -120] x 5 km/h
associated to a train category SP <=> [0-600] km/h
[V_DIFF (k,m,n)] To be agreed/clarified with [121-126] = Spare
ATO WP
Value of the new gradient at the Data needs to be available Binary to numeric (0-255) with
beginning of the Segment on SP resolution 1‰
Profile
[G_New_Gradient (k)]
Direction of the new gradient Data needs to be available 0 = Downhill
[Q_GDIR (k) on SP 1= Uphill
Number of iterations of gradient Data should be generated
changes from ATO-TS
[N_ITER (k)]
Location of the gradient change Data needs to be available Binary to numeric (in
relatively to the beginning of the on SP centimetres)
SP 24 bits
(D_Location (k,o)]
Value of the new gradient Data needs to be available Binary to numeric (0-255)
[G_New_Gradient (k,o)] on SP with resolution 1‰
Direction of the new gradient Data needs to be available 0 = Downhill,
[Q_GDIR (k,o)] on SP or to be generated 1= Uphill
in ATO-TS. To be
agreed/clarified with ATO
WP
GA 777465 Page 127 of 197


Curve category at the beginning Data needs to be available 0 = R>7000m
of the Segment Profile on SP 1 = 7000m≥R>4500m;
[N_Radius_Category (k)] 2 = 4500m≥R>2800m;
3 = 2800m≥R>2000m;
4 = 2000m≥R>1500m;
5 = 1500m≥R>1250m;
6 = 1250m≥R>1075m;
7 = 1075m≥R>925m;
8 = 925m≥R>825m;
9 = 825m≥R>725m;
10 = 725m≥R>625m;
11 = 625m≥R>525m;
12 = 525m≥R>475m;
13 = 475m≥R>425m;
14 = 425m≥R>375m;
15 = 375m≥R>325m;
16 = 325m≥R>300m;
17 = 300m≥R>275m;
18 = 275m≥R>250m;
19 = 250m≥R>225m;
20 = 225m≥R>200m;
21 = 200m≥R>175m;
22 = 175≥R>150m;
23 = R≤150m;
24-31 = Spare
Side of the curve Data needs to be available 0 = Unknown, 1 = Right, 2 =
[Q_Curve_Side (k)] on SP Left, 3 = Spare
Number of iterations of curve Data should be generated
changes from ATO-TS
[N_ITER (k)]
Location of the curve change Data needs to be available Binary to numeric (in
SP 24 bits
[D_Location (k,p)]
GA 777465 Page 128 of 197


Curve category Data needs to be available 0 = R>7000m
[N_Radius_Category (k,p)] on SP 1 = 7000m≥R>4500m;
2 = 4500m≥R>2800m;
3 = 2800m≥R>2000m;
4 = 2000m≥R>1500m;
5 = 1500m≥R>1250m;
6 = 1250m≥R>1075m;
7 = 1075m≥R>925m;
8 = 925m≥R>825m;
9 = 825m≥R>725m;
10 = 725m≥R>625m;
11 = 625m≥R>525m;
12 = 525m≥R>475m;
13 = 475m≥R>425m;
14 = 425m≥R>375m;
15 = 375m≥R>325m;
16 = 325m≥R>300m;
17 = 300m≥R>275m;
18 = 275m≥R>250m;
19 = 250m≥R>225m;
20 = 225m≥R>200m;
21 = 200m≥R>175m;
22 = 175≥R>150m;
23 = R≤150m;
24-31 = Spare
Side of the curve Data needs to be available 0 = Unknown
[Q_Curve_Side (k,p)] on SP 1 = Right
2 = Left
3 = Spare
Voltage value at the beginning Data needs to be available
of the Segment Profile on SP 0 Line not fitted with any traction
[M_VOLTAGE (k)] system
It indicates the voltage of the traction system 1 AC 25 kV 50 Hz
installed on a specific line or respectively 2 AC 15 kV 16.7 Hz
that can be used by an engine 3 DC 3 kV
The identity of the traction system is given 4 DC 1.5 kV
by M_VOLTAGE and, if M_VOLTAGE ≠ 0, 5 DC 600/750 V
by the country identifier of the traction 6- Spare
system (NID_CTRACTION) 15
Country identifier of the traction Data needs to be available It identifies the information,
system on SP additional to M_VOLTAGE,
[NID_CTRACTION (k)] required to fully define the
traction system.
GA 777465 Page 129 of 197


Number of iterations of voltage Data should be generated
changes from ATO-TS
[N_ITER (k)]
Location of the voltage change Data needs to be available Binary to numeric (in
SP 24 bits
[D_Location (k,q)]
Voltage value Data needs to be available
[M_VOLTAGE (k,q)] on SP 0 Line not fitted with any traction
system
1 AC 25 kV 50 Hz
2 AC 15 kV 16.7 Hz
3 DC 3 kV
4 DC 1.5 kV
5 DC 600/750 V
6- Spare
15
Country identifier of the traction Data needs to be available
system on SP
[NID_CTRACTION (k,q)]
Allowed current consumption at Data needs to be available 10 Bits
the beginning of the Segment on SP Minimum: 0 A
Profile Maximum: 10000 A
[M_CURRENT (k)] Resolution: 10 A
Number of iterations of allowed Data should be generated
current consumption changes from ATO-TS
[N_ITER (k)]
Location of the allowed current Binary to numeric (in Binary to numeric (in
consumption change relatively centimetres) centimetres)
to the beginning of the SP 24 bits
[D_Location (k,r)]
Allowed current consumption 10 Bits
[M_CURRENT (k,r)] Minimum: 0 A
Maximum: 10000 A
Resolution: 10 A
Number of iterations of balise Data should be generated
groups from ATO-TS
[N_ITER (k)]
Identifier of the balise group Data needs to be available 14 Bits
[NID_BG (k,s)] on SP Start: 0
Max: 16382
Number of balises in the balise Data needs to be available 0 1 balise in the group
group on SP …
[N_TOTAL (k,s)] 7 8 balises
GA 777465 Page 130 of 197


Defines the relative position in a Data needs to be available
balise group, as defined in on SP 0 I am the 1st
… …
Section 7.5.1.81.
7 I am the 8th
[N_PIG (k,s,N_TOTAL)]
Location of the balise relatively Data needs to be available Binary to numeric (in
to the beginning of the SP. on SP centimetres)
[D_Location (k,s,N_TOTAL)] 24 bits
Number of iterations of Timing Data should be generated
Points from ATO-TS
[N_ITER (k)]
TP identity Data needs to be available Binary to numeric.
[NID_TP (k,t]) on SP 24 bits
4294967295 for undefined
value.
Location of the Timing Point Data needs to be available Binary to numeric (in
SP 24 bits
[D_Location (k,t)]
Required stopping tolerance to Data needs to be available 0 = 10cm
use when the TP is a Stopping on SP 1 = 20cm
Point 2 = 30cm
[Q_Stop_Location_Tolerance (k,t)] 3 = 40cm
4 =50cm
5 = 1m;
6 = 1,5m
7 = 2m
8 = 2,5m
9 = 3m
10 = 5m
11 = 7,5m
12 = 10m
13 = 15m
14 = 20m
15 = 25m
16 = 30m
17 = 50m
18 = 75m
19 = 100m
20-30 = Spare;
31 = No requirement
GA 777465 Page 131 of 197


Distance from a Stopping Point Data needs to be available Binary to numeric (in
to consider it as reached on SP centimetres)
[D_STP_Reached (k,t)] 24 bits
Length of text string ATO TS to generate bit 8 Bits
[L_TEXT (k,t)] length Min: 0
Max: 255
Name of the TP To be agreed/clarified with
[X_TEXT (k,t,L_TEXT)] ATO WP
Number of iterations of Platform Data should be generated
Areas from ATO-TS
[N_ITER (k)]
Indicator whether the Platform Data needs to be available 0 = Starts,
Area starts, ends, starts and on SP 1 = Ends
ends or covers the whole 2 = StartsEnds
concerning Segment Profile 3 = WholeSP
[Q_Range (k,u)]
Location of the platform start Data needs to be available Binary to numeric (in
SP 24 bits
[D_Start_Location (k,u)]
Location of the platform end Data needs to be available Binary to numeric (in
SP 24 bits
[D_End_Location (k,u)]
Number of iterations of tunnels Data should be generated
[N_ITER (k)] from ATO-TS
Indicator whether the Tunnel Data needs to be available 0 = Starts,
starts, ends, starts and ends or on SP 1 = Ends
covers the whole concerning 2 = StartsEnds
Segment Profile 3 = WholeSP
[Q_Range (k,v)]
Category of the Tunnel Data needs to be available 0 = Spare
[Q_Tunnel_Category (k,v)] on SP 1 = Single track tunnel
The Tunnel described in 2 = Double track tunnel
chapter 6.5 does not 3-7 = Spare.
define “Category” which
need to be aligned.
Location of the tunnel start Data needs to be available Binary to numeric (in
SP 24 bits
[D_Start_Location (k,v)]
GA 777465 Page 132 of 197


Location of the tunnel end Data needs to be available Binary to numeric (in
SP 24 bits
[D_End_Location (k,v)]
Number of iterations of Data should be generated
Powerless Sections from ATO-TS
[N_ITER (k)]
Indicator whether the Powerless Data needs to be available 0 = Starts,
Section starts, ends, starts and on SP 1 = Ends
ends or covers the whole 2 = StartsEnds
[Q_Range (k,w)]
Location of the Powerless Data needs to be available Binary to numeric (in
Section start relatively to the on SP centimetres)
beginning of the SP 24 bits
[D_Start_Location (k,w)]
Location of the Powerless Data needs to be available Binary to numeric (in
Section end relatively to the on SP centimetres)
[D_End_Location (k,w)]
Number of iterations of Axle Data should be generated
Load Speed Profiles from ATO-TS
[N_ITER (k)]
Indicator whether the Axle Load Data needs to be available 0 = Starts,
Speed Profile starts, ends, starts on SP 1 = Ends
and ends or covers the whole 2 = StartsEnds
[Q_Range (k,x)]
GA 777465 Page 133 of 197


Axle load from which the speed Data needs to be available A: ≤ 16 t
HS17: 16 t < M_AXLELOAD ≤ 17 t
restriction is applicable on SP B1 : 17 t < M_AXLELOAD ≤ 18 t
[M_AXLELOADCAT (k,x)] C2 : 18 t < M_AXLELOAD ≤ 20 t
The values allocated correspond to a list of D2 : 20 t < M_AXLELOAD ≤ 22.5 t
increasing axle load categories (i.e. B1 > E4 : 22.5 t < M_AXLELOAD ≤ 40 t
HS17, B2 > B1, D2 > C4, ….etc) and it is M_AXLELOAD above 40 t
used by the on-board equipment to compare
its axle load category with the axle load Minimum Maximum
category sent by trackside. 0 A
1 HS17
2 B1
3 B2
4 C2
5 C3
6 C4
7 D2
8 D3
9 D4
10 D4XL
11 E4
12 E5
13-127 Spare
Speed restriction to be applied if Data needs to be available [0 -120] x 5 km/h
the axle load of the train ≥ on SP <=> [0-600] km/h
M_AXLELOADCAT (k,v) [121-126] = Spare
[V_New_Speed_Level (k,x)]
Qualifier to indicate if the ALSP Data needs to be available 0 = Train length delay
is to be applied to the front of on SP 1 = No train length delay
the train (no train length delay)
or to the end of the train (train
length delay).
[Q_FRONT (k,x)]
Qualifier to indicate if a speed limit given for
a profile element is to be applied until the
front of the train (no train length delay) or the
end of the train (train length delay) has left
the element
Location of the Axle Load Speed Data needs to be available Binary to numeric (in
Profile start relatively to the on SP centimetres)
beginning of the SP
[D_Start_Location (k,x)]
Location of the Axle Load Speed Data needs to be available Binary to numeric (in
Profile end relatively to the on SP centimetres)
[D_End_Location (k,x)]
GA 777465 Page 134 of 197


Number of iterations of stopping Data should be generated
locations for unprotected level from ATO-TS
crossings
[N_ITER (k)]
Location of the stop in rear of an Data needs to be available Binary to numeric (in
unprotected level crossing on SP centimetres)
[D_UnprotectedLx_Stop (k,d)] 24 bits
Number of iterations of Data should be generated
Permitted Braking Distance from ATO-TS
areas
[N_ITER (k)]
Specifies if the Permitted Data needs to be available 0 = Starts,
Braking Distance area starts, on SP 1 = Ends
ends, starts and ends or covers 2 = StartsEnds
the whole concerning Segment 3 = WholeSP
Profile
[Q_Range (k,y)]
Permitted Braking Distance Data needs to be available Binary to numeric (in
value on SP centimetres)
[D_Permitted_Braking_Distance (k,y)] 24 bits
Indicator whether the permitted Data needs to be available 0 = Service Brake
braking distance is to be on SP 1 = Emergency Brake
achieved with the Service Brake
or Emergency Brake
[Q_PBD_SBEB (k,y)]
Indicator if a single gradient Data needs to be available Binary to numeric (0-255)
value applicable for the on SP with resolution 1‰
calculation 8 bits
[G_PBD (k,y)]
Direction of the gradient Data needs to be available 0 = Downhill
[Q_GDIR_PBD (k,y)} on SP 1= Uphill
Location of the Permitted Data needs to be available Binary to numeric (in
Braking Distance area start on SP centimetres)
relatively to the beginning of the 24 bits
SP
[D_Start_Location (k,y)]
Location of the Permitted Data needs to be available Binary to numeric (in
Braking Distance area end on SP centimetres)
SP
[D_End_Location (k,y)]
GA 777465 Page 135 of 197


Number of iterations of Switch Data should be generated
off Regenerative Brake areas from ATO-TS
[N_ITER (k)]
Indicator whether the Switch off Data needs to be available 0 = Starts,
Regenerative Brake area starts, on SP 1 = Ends
ends, starts and ends or covers 2 = StartsEnds
the whole concerning Segment 3 = WholeSP
Profile
[Q_Range (k,z)]
Location of the Switch off Data needs to be available Binary to numeric (in
Regenerative Brake area start on SP centimetres)
SP
[D_Start_Location (k,z)]
Regenerative Brake area end on SP centimetres)
SP
[D_End_Location (k,z)]
off eddy current brake for from ATO-TS
service brake areas
[N_ITER (k)]
eddy current brake for service on SP 1 = Ends
brake area starts, ends, starts 2 = StartsEnds
and ends or covers the whole 3 = WholeSP
concerning Segment Profile
[Q_Range (k,a)]
Location of the Switch off eddy Data needs to be available Binary to numeric (in
current brake for service brake on SP centimetres)
area start relatively to the 24 bits
beginning of the SP
[D_Start_Location (k,a)]
current brake for service brake on SP centimetres)
area end relatively to the 24 bits
beginning of the SP
[D_End_Location (k,a)]
off eddy current brake for from ATO-TS
emergency brake areas
[N_ITER (k)]
GA 777465 Page 136 of 197


eddy current brake for on SP 1 = Ends
emergency brake area starts, 2 = StartsEnds
ends, starts and ends or covers 3 = WholeSP
the whole concerning Segment
Profile
[Q_Range (k,b)]
current brake for emergency on SP centimetres)
brake area start relatively to the 24 bits
beginning of the SP
[D_Start_Location (k,b)]
current brake for emergency on SP centimetres)
brake area end relatively to the 24 bits
beginning of the SP
[D_End_Location (k,b)]
off Magnetic Shoe Brake areas from ATO-TS
[N_ITER (k)]
Magnetic Shoe Brake area on SP 1 = Ends
starts, ends, starts and ends or 2 = StartsEnds
covers the whole concerning 3 = WholeSP
Segment Profile
[Q_Range (k,c)]
Magnetic Shoe Brake area start on SP centimetres)
SP
[D_Start_Location (k,c)]
Magnetic Shoe Brake area end on SP centimetres)
SP
[D_End_Location (k,c)]
Table 8.129 – Segment Profile
8.9.1.3 ATO Status Report (STR)

Status Report Packet sent by the ATO-OB to the ATO-TS contain valuable information to increase
the precision of the Traffic Forecast.
ATO-TS shall translate the STR into CDM Format and broadcast the data via Integration Layer.
GA 777465 Page 137 of 197
STR content:
• Current ATO state in use
• Indicators for:
o Next Stopping Point Skip
o Low adhesion reported by the driver
o Slip/Slide indication detected by external system,
o Operational conditions fulfilment,
o Train is moving,
o Train is unable to stop at the next Stopping Point.
• Current Speed of the train when the STR is sent.
• Driver identifier number
• Identifiers of the SP and Position of the estimated front end of the train at the moment the STR
is sent, relatively from the beginning of the given SP.
• Identifiers of the previous TP's and indication whether the train
o has stopped
o has departed from
o has passed
o has stopped accurately or not at the stopping point
• Identifiers of the next TP's and indication on
o Arrival date
o Time to arrival (in sec)

The current ATO State in use Status data from ATO-OB 4 bits
[M_ATO_State] to be broadcasted via IL 0 = Unknown
1 = CO (Configuration)
2 = NA (Not Available)
3 = AV (Available)
4 = RE (Ready)
5 = EG (Engaged)
6 = DE (disengaged)
7 = FA (Failure)
[8-15] = Spare
GA 777465 Page 138 of 197


Bitset with the indicators Status data from ATO-OB 16 bits
state to be broadcasted via IL bit0 = Data inconsistency
[Q_STR_Indicators] bit1 = Next Stopping Point Skip
bit2 = Low adhesion reported by
the driver
bit3 = Slip/Slide indication
detected by external
system
bit4 = Operational conditions
fulfilment, bit5 = Train is
moving
bit6 = Unable to stop at the next
Stopping Point
[bit7-bit15] = Spare Values.
Current Speed of the train Status data from ATO-OB 10 bits
when the STR is sent to be broadcasted via IL Binary to numeric.
[V_TRAIN_ATO] Resolution: 1 km/h
Driver identifier number as Status data from ATO-OB 128 bits
defined in SUBSET-027 v300 to be broadcasted via IL 16 characters (ISO 8859-1)
§4.2.3.7.
[Driver_ID]
Identity of the SP's country or Status data from ATO-OB 10 bits
region to be broadcasted via IL See [Ref 1], Section 7.5.1.86.
[NID_C]
Not relevant if
D_Sending_Position =
Undefined location
SP identity Status data from ATO-OB 32 bits
[NID_SP] to be broadcasted via IL Binary to numeric.
Not relevant if
D_Sending_Position =
Undefined location
Position of the estimated Status data from ATO-OB 24 bits
front end of the train when to be broadcasted via IL Binary to numeric (in
the STR is sent (relatively centimetres).
from the beginning of the 16777215 = Undefined location
given SP)
[D_Sending_Position]
Identity of the previous TP's Relevant Status data from 10 bits
country or region ATO-OB in connection See [Ref 1], Section 7.5.1.86.
[NID_C] with
Not relevant if NID_TP is
[Q_Pass_Stop_Depart] to
undefined
be broadcasted via IL
GA 777465 Page 139 of 197

Previous TP identity Relevant Status data from 32 bits
[NID_TP] ATO-OB in connection Binary to numeric
with 4294967295 for undefined value.
[Q_Pass_Stop_Depart] to
be broadcasted via IL
Qualifier to indicate if train Status data from ATO-OB2 bits
has stopped at the TP, has 0 = Train passed the TP
relevant with “Previous TP
departed from the TP or has 1= Train stopped at the TP
identity” to be broadcasted
passed the TP. via IL 2 =Train departed from the TP
[Q_Pass_Stop_Depart] 3 = Undefined
Qualifier specifing if the train Relevant data for TMS- 2 bit
has stopped accurately or not ATO
at the Operational Stopping
Point.
[Q_Accurate_Stopping]
Number of iterations of TPs Not relevant for broadcast 5 bits
information via IL
[N_ITER]
Identifier of the next TP's Not relevant 10 bits
country or region See [Ref 1], Section 7.5.1.86.
[NID_C (k)]
Not relevant if NID_TP is
undefined
Next TP identity Relevant data for TMS 32 bits
[NID_TP (k)] Binary to numeric
4294967295 for undefined value.
Date to arrive at the TP Relevant data for TMS 15 bits
[T_Arrival_Date (k)] Value from 0 (01/01/2010) to
32767 (18/09/2099)
32767 = undefined
Estimated time in seconds to Relevant data for TMS 17 bits
arrive at the TP Value from 0 (00:00:00) to 86399
[T_Arrival_Seconds (k] (23:59:59)
131071 = undefined
Table 8.130 – ATO Status Report
Energy Grid
The state of the energy grid influences operations in TMS in several ways:
• Outages of power supply limit usage of electric locomotives in restricted areas,
• Rerouting of trains must consider current and future state of the energy grid,
GA 777465 Page 140 of 197

• Limitations of available power supply (e.g. due to maintenance of power substation) limit
acceleration ability of the trains, especially for concurrently accelerating trains,
• Power consumption peaks on “old” energy supply systems could activate protection relays and
disturb train operations considerably.
The high-level structure of the involved objects is shown in Figure 8.4.
Infrastructure
*
*
Power substation PowerArea
(dynamic) *
FeedingSection
NetElement
Figure 8.4 – Basis class diagram for static configuration of energy grid in TMS
8.10.1 Data
Feeding section “static” data
ID Identifies the power section. 40 bytes alphanumeric
unique identifier
netElements A sequence of NetElements covered by Sequence of references to
the PowerSection. NetElements.
startPos Start position on the first NetElement Length in cm from the
covered by the power section. beginning of the first
NetElement.
startDirUp True, if the direction on the NetElement True, False
at the beginning covered by the Power
Section is in the same direction as
NetElement.
GA 777465 Page 141 of 197

endPos End position on the last NetElement Length in cm from the

covered by the power section. beginning of the last
NetElement.
endDirUp True, if the direction on the NetElement True, False
at the end covered by the Power
Section is in the same direction as
NetElement.
nominalVoltage Defines the default voltage on the Integer in [Volts]
PowerSection.
nominalFrequency Defines the energy frequency. Integer in 0.1 [Hz]. Value 0

means DC.
maxCurrent Defines maximum current provided on Integer in [Ampers].
the PowerSection.
nominalMaxSpeed Maximum speed of the train supported Integer in [km/h], 0 means
by the power supply. no limitations.
Table 8.131 – Feeding section “static data”
In addition to the seldom changing configuration of the FeedingSections their dynamic state shall
be published on the Integration Layer. The values can be published on different topics (e.g. voltage
separated from power consumption).
FeedingSection “online” data
ID Identifies the power section. 40 bytes alphanumeric
unique identifier
voltageDrop Deviation of the current voltage Integer in [0.1 Volts], max
from the default value. 10kV
actualCurrent Current power consumption on the Integer in [Amper]
PowerSection.
catenaryTempReserve Remaining temperature capacity of Promille (Tmax – T)/Tmax
? the catenary until it gets too hot and
must be switched off.
On If false-the FeedingSection is not boolean
connected to power supply.
Table 8.132 – Feeding section “online data”
GA 777465 Page 142 of 197

Substation 1 Substation N
PowerSupplyConfigurationLogic
FeedingSection
TMS-Logic
Train 1 Train 2 Train M
Driver Logic ATO Logic Driver Logic
Figure 8.5 – Power distribution logic in power supply chain
There are several active logics inside of the system (s. Figure 8.5):
• Power supply configuration logic dynamically reconfigures the power supply from the
substations to single Feeding Sections in dependence of many parameters (maintenance actions
in substations, penalties for power peaks, limits in equipment etc.).
• TMS logic assigns trains to FeedingSections by modification of the timetable.
• Automatic Train Operation (ATO) unit on board decides, when to apply which acceleration rates.
• Train driver defines acceleration rates.
In over dimensioned situations the PowerSupplyConfigurationLogic can pretend an ideal power

supply: the trains would receive as much energy as they require for the operation.
With approach to the limits of the electrical equipment the trains will receive less energy resulting
in reduced acceleration rates, which would influence the train operations. Modern trains have built-
in current limitations based on available voltage – they use the power supply line as a
“communication” mean between each other. In case of active power limits the voltage goes down,
and the trains automatically reduce their power consumption. The trains located closer to the
GA 777465 Page 143 of 197
“active” power station consume more power. In total the trains in conflict would increase their run
time by several seconds. If this “inherent” conflict resolution is not acceptable, the TMS could use
its degrees of freedom to rearrange the power consumption between trains according to some
other algorithm.
This topic is currently a subject of research. Hence the data structures on IL are not clear yet and
will be defined in the future projects.
Fleet & Crew
8.11.1 Data
This section contains the data published to the Integration layer from the Crew and Rolling Stock
management systems.
This is split into 5 sections:
1. Common Data Structures
2. Crew related Data
3. Passenger allocation and consist Data
4. Freight allocation and consist Data
5. Vehicle Characteristics
In the following sections, some of the attributes within a data structure are themselves formed of
data structures defined within the chapter. To indicate this, the data structure forming the attribute
will be surrounded by curly braces ‘{}’ within the Admitted Values column. E.g. {Vehicle}.
At the beginning of sections 8.11.1.2, 8.11.1.3 and 8.11.1.4 is a diagram to show the hierarchy of
the data structures.
8.11.1.1 Common Data structures

Below are data structures that are re-used in multiple sections:
8.11.1.1.1 Location
This data structure holds the information needed to identify locations.
Location
CountryCodeISO Country Code (eg: GB) Country Codes
LocationPrimaryCode UIC Location Code UIC Location Code
PrimaryLocationName Location Name Alphanumeric
LocationSubsidiaryIdentific Enables use of Local Country {LocationSubsidiaryIdentificat
ation Location ion}
Table 8-133 – Location
8.11.1.1.2 LocationSubsidiaryIdentification
GA 777465 Page 144 of 197
This is required for Railways where a local system for identifying locations is also required.
LocationSubsidiaryIdentification
LocationSubsidiaryCode Local Country Location ID Alphanumeric
LocationSubsidiaryTypeC Local Country Location ID Type Defined by country
ode
AllocationCompany UIC Company Code for IM UIC Company Code
(Infrastructure Maintainer)
Table 8-134 – LocationSubsidiaryIdentification
8.11.1.1.3 OperationalTrainNumberIdentifier
This is the Operational Train Number for the running train service.
OperationalTrainNumberIdentifier
OperationalTrainNumber Operational Train Number Alphanumeric
Table 8-135 – OperationalTrainNumberIdentifier
8.11.1.1.4 TransportOperationalIdentifiers
It’s crucial that the Train service related to the shift leg and consist allocations is uniquely
identifiable. This data in this structure ensures that is possible. In some cases the operational train
number is not enough to achieve this.
TransportOperationalIdentifiers
ObjectType Planned Path (PA) in Schedule Train ‘PA’
ID Type
Company UIC Company Code for IM UIC Company Code
(Infrastructure Maintainer)
SecondaryTrainIdentifier Secondary attribute for uniquely Alphanumeric
identifying a train. May be country
specific.
TimetableYear Current System Year Numeric (Year)
StartDate Planned Departure Date of train Date (YYYY-MM-DD)
(YYYY-MM-DD)
Table 8-136 – 1.1.1.4 TransportOperationalIdentifiers
8.11.1.2 Data related to Crew

This data structure is a based on a ‘shift centric’ view of crew data. This means the crew shift is
the top of the hierarchy; this shift is assigned to a crew resource and built of a set of crew
allocations (e.g. Crew Shift Legs).
GA 777465 Page 145 of 197
Figure 8.6 – Overview Hierarchy of following Crew Shift data structures
8.11.1.2.1 CrewShiftAllocation
The ‘CrewShiftAllocation’, defines the overall shift for a crew member. This can be used to identify
the deployment plan for a crew member, showing their assignment to schedules. This includes
the identification of the Shift, the start and end times of the shift and the planned and allocated
resource for the shift
The ‘CrewShiftLeg’, is the repeatable structure that holds the data for each leg (activity) of the
shift.
CrewShiftAllocation
CrewShiftAllocationType Defines if this is a Simulated plan or live 0 = Simulated (What
plan that has been implemented by the If) / 1 = Live
crew rostering system. (Implemented in the
Crew Rostering
System)
CrewShiftName Shift Description / Crew Diagram Name Alphanumeric
used by RU (Operator)
CrewShiftDateTimeOn Date & Time of shift START (UTC + Datetime
Offset)
CrewShiftDateTimeOff Date & Time of shift END (UTC + Datetime
Offset)
CrewShiftID Unique ID for Crew Shift - Guaranteed Alphanumeric
Uniqueness and non- traceability to the
person, compliant with the General
Data Protection Regulations
CrewShiftRoleRequired Agreed Terms for Crew eg: Driver, Alphanumeric e.g.
Guard etc. Driver, Guard
CrewShiftAllocationLastUpda Last Date Time at which Shift Allocation Datetime
teDateTime was last updated (UTC + Offset)
GA 777465 Page 146 of 197

CrewShiftAllocation
CrewShiftAllocationStatus Status of the allocation e.g. planned, Alphanumeric
assigned, in progress, complete
CrewShiftAllocatedResource Currently Allocated Resource {CrewShiftResource}
CrewShiftPlanedResource Originally Planned Resource {CrewShiftResource}
CrewShiftLeg Each activity of the crew member N x {CrewShiftLeg}
Table 8-137 – CrewShiftAllocation
8.11.1.2.2 CrewShiftResource
This holds the id of the Crew Resource. This is used to identify the crew member related to the
shift.
CrewShiftResource
CrewShiftAllocatedReso Anonymised and GDPR Compliant Alphanumeric
urceID Resource ID allocated - issued by the
Crew Rostering System to consuming
systems to prove allocation is ‘Real’
ResourceEmployerComp UIC Company Code for Resource Numeric
anyCode Employer
CrewShiftDetails Further details about the Crew member if [CrewShiftDetails]
required
Table 8-138 – CrewShiftResource
8.11.1.2.3 CrewShiftDetails
This holds the details of the Crew Resource. This is used to for further information about the crew
member related to the shift.
CrewShiftResource
CrewName Name of Crew Member String
ContactNumber Phone number to contact Crew Numeric
CrewRole Role of the Crew member String
CrewWorkStartTime DateTime that the resource begins work DateTime
CrewWorkEndTime DataTime that the resource ends work DateTime
CrewStatus List of the ‘’Attendance’’ status of duties: String
Spare, attendance, absence, etc.
Table 8-139 – CrewShiftDetails
8.11.1.2.4 CrewShiftLeg
GA 777465 Page 147 of 197

Each activity of the crew member is a ‘leg’ of the overall shift. Each leg includes the identification
of the train service the activity is related to and the start and destination location and time of the
activity.
CrewShiftLeg
ShiftLegIsOperational True = Operational (e.g. True/False
Driving, Conducting etc)
False = Non Operational (e.g.
Travelling as Passenger
ShiftLegType Details of the shift leg type. {ShiftLegType}
ShiftLegTrainIdentifiers Identification of the Train {ShiftLegTrainIdentifier}
Service to which the Shift Leg
is allocated.
ShiftLegOriginLocation Location for SHIFT LEG {Location}
ORIGIN
ShiftLegOriginDateTime Date & Time of SHIFT LEG Datetime
ORIGIN (UTC + Offset)
ShiftLegDestinationLocation Location for SHIFT LEG END / {Location}
FINISH
ShiftLegDestinationDateTime Date & Time of SHIFT LEG Datetime
END / FINISH (UTC + Offset)
ShiftLegAtRisk True = Activity will be True/False
undertaken
False = Risk that the Allocation
may Change
ShiftLegAtRiskDescription Description of Risk Alphanumeric
ShiftLegLastUpdateDateTime Last Time Publishing System Datetime
updated the Shift Leg
Table 8-140 CrewShiftLeg
8.11.1.2.5 ShiftLegType
The ‘ShiftLegType’ contains the information of the type of activity involved in this shift leg. E.g.
Train Run, Shunting.
ShiftLegType
ShiftLegTypeCode Eg: 01 = Train Run, 05 = Shunting, 99 = Numeric (0-99)
Other, etc..
ShiftLegTypeCode Human Friendly Description of Shift Leg Alphanumeric
Type Code
Table 8-141 – ShiftLegType
GA 777465 Page 148 of 197

8.11.1.2.6 ShiftLegTrainIdentifiers
This includes the details of the train service the shift leg relates to.
ShiftLegTrainIdentifiers
TrainOperationalIde In Mainland Europe, the below identifies {TransportOperationalIdentif
ntification the train service uniquely iers}
SecondaryTrainIdent Secondary attribute for uniquely Alphanumeric
ifier identifying a train. May be country
specific.
ReferenceOTN Originally Planned Operational Train {OperationalTrainNumberId
Number / TrainID entifier}
This caters for Change of Operational
Train Number / Train ID
ResponsibleRU UIC Company Code for RU (Train UIC Company Code
Operator) Responsible for that part of the
shift leg – may be different to the Crew
Member Employer – this allows for multi-
responsibilities
Table 8-142 – ShiftLegTrainIdentifiers
8.11.1.3 Data related to Passenger Consist and Allocation

This section holds the data structures for the passenger consist information and its allocation to
train services. This is a train service centric view, where each train service includes the vehicles
used along its journey. This can be used to identify the Rolling Stock deployment plan of a vehicle
or resource group.
Figure 8.7 – Overview Hierarchy of following Passenger consist data structures
8.11.1.3.1 PassengerConsistAllocation
This is the identifier of the train service that will be allocated passenger consists that form the
physical journey of the service. Reference OTN is included incase the operational Train Number
changes along the journey.
GA 777465 Page 149 of 197

PassengerConsistAllocation
TrainOperationalIdentifi Identifies the Scheduled Train Path ID in {TransportOperationalId
cation which the Physical Vehicles Run entifiers}
OperationalTrainNumb Current Train ID {OperationalTrainNumb

erIdentifier erIdentifier}
ReferenceOTN Originally Planned Train ID (if “Current” {OperationalTrainNumb
Train ID is Different) erIdentifier}
Allocation Repeating Group – Identifies the {PassengerConsist}
Allocation of Resource Groups (ie: Units or
Sets) To “Journey Legs” within the Path (A
“Journey Leg” is a portion of the Journey
along the Scheduled Train Path)
Table 8-143 – PassengerConsistAllocation
8.11.1.3.2 PassengerConsist
This includes the Resource Groups (formations of vehicles) that form the train service between
two locations. If there is a join or split there may be multiple allocations for the overlapping parts
of a train journey.
PassengerConsist
AllocationSequenceNu Sequential Position of an Allocation within Numeric
mber the Scheduled Train Journey “1” is the first
allocation (It may be the only allocation)
TrainOriginDateTime Origin Departure Date and Time of Train Datetime
(UTC Without Offset)
TrainOriginLocation Origin Location of Train. {Location}
ResourceGroupPosition Numeric position of resource group within Numeric
the train formation. The lead unit should
be ‘1’.
DiagramDate Start date of diagram. Date
DiagramNo Diagram ID alphanumeric
TrainDestLocation Destination location of train. {Location}
TrainDestDateTime Destination Arrival Date and Time of Train Datetime
(UTC Without Offset)
AllocationOriginLocatio Location at Which The allocation Starts Location
n
AllocationOriginDateTi Date and Time When the Allocation Datetime
me Begins (UTC Without Offset)
GA 777465 Page 150 of 197

AllocationOriginDistanc Allocation Origin at Distance from Origin of UnitOfMeasurement:

e Train Alphanumeric
Value: Numeric
AllocationDestinationLo Location at Which The allocation Starts {Location}
cation
AllocationDestinationDa Date and Time When the Allocation Ends Datetime
teTime (UTC Without Offset)
AllocationDestination Allocation Origin at Distance from Origin of UnitOfMeasurement:
Train Alphanumeric
Value: Numeric
Reversed Identifies if formation is in reverse Y/N
Resource Group Details of the Resource Group in this N x {Resource Group}
allocation.
Table 8-144 – PassengerConsist
8.11.1.3.3 ResourceGroup
Resource groups are a collection of vehicles. This allows groups of vehicles that will stay formed
to be tracked as a group rather than individuals.
ResourceGroup
ResourceGroupID ID of Locomotive, Unit or Set forming the Alphanumeric
Train
TypeOfResource Type of resource (i.e. U = unit, S = set, L = Single Character
loco set).
FleetID Rolling Stock Fleet Identifier – this is Alphanumeric
unique to the model / range / class of
vehicle. An example of this would be:
060/156 to mean vehicle number 60 of the
type Class 156. It is the Fleet ID used in
the country’s rolling stock register
ResourceGroupStatus Status of Resource Group – “N” = Normal Alphanumeric
EndOfDayDistance The expected Distance Travelled at the UnitOfMeasurement:
end of the current day Alphanumeric
Value: Numeric
PreAssignment Expresses desire to stop a resource and a {PreAssignment}

particular location and time, e.g. for
maintenance.
NextAvailableLocation Conditional Field - Location from Where {Location}
Vehicle is available from – this is only
GA 777465 Page 151 of 197

populated if VehicleStatus (In ‘Vehicle)

Below is NOT “N” - Fields populated by
way of example only
NextAvailableDateTime Conditional Field - Location from Where Datetime
Vehicle is available from – this is only
populated if VehicleStatus (In ‘Vehicle)
Below is NOT “N” - Field populated by way
of example only
Restriction Restrictions Applied to this Resource {Restriction}
Group
Vehicle The vehicles forming the resource group N x {Vehicle}
Table 8-145 – ResourceGroup
8.11.1.3.4 PreAssignment
A pre-assignment is used when a resource group must arrive at a particular location by a particular
time, i.e. for maintenance work. This information can be used when creating the rolling stock plan.
PreAssignment
PreAssignmentRequire Location Where the Resource Group must {Location}
dLocation Stop
PreAssignmentDueDat Date and Time When Resource Group Datetime
eTimeDateTime must Stop at Location
PreAssignmentReason Free Format Text with reason for Pre- Alphanumeric
Assignment
PreAssignmentDateTim Date and Time when Pre-Assignment was Datetime
e applied
Table 8-146 – PreAssignment
8.11.1.3.5 Restriction
Any restrictions on the resource group.
Restriction
Restriction Code Code to describe restriction Restriction Codes
Date Date the Restriction was applied Date
RestrictionComments Free format text comments Alphanumeric
Distance Distance from origin at which the UnitOfMeasurement:
restriction was applied Alphanumeric
Value: Numeric
Hours Hours from Origin at which the restriction Numeric
was applied
GA 777465 Page 152 of 197
Table 8-147 – Restriction
8.11.1.3.6 Vehicle
This structure defines an individual vehicle that forms a resource group. This includes all details
of the individual vehicles, such as maximum speed and weight.
Vehicle
VehicleID Vehicle Number Numeric
TypeOfVehicle C = Coach / L = Locomotive Alphanumeric
SpecificType Design Code for Vehicle Alphanumeric
TractionType Electric Diesel Code
PowerSupply Source of Power e.g. Overhead Line Code
LoadingGauge Loading Gauge of Vehicle Numeric
TrackGauge Track Gauge of Vehicle Numeric
ResourcePosition Conditional Field - Position of Resource in Numeric
Resource Group – Not present for
Vehicles not in a Resource Group
PlannedResourceGrou Optional Field – Publishes a whole {ResourceGroup}
p Resource Group if the Originally Planned
Resource Group is different from the
Actual Resource Group Above (ie: This
Resource Group)
Control List of Control Systems and description List[Code:
e.g. LZB, ERTMS L1 Alphanumeric]
List[Description:
Alphanumeric]
Length Length of vehicle: UnitOfMeasure:
Alphanumeric
Value: Numeric
Weight Weight in Metric Tonnes Numeric

RUBranding Livery of vehicle Alphanumeric
Décor Décor of vehicle Alphanumeric
SpecialCharacteristics Codes for characteristics Codes
ElectricTrainHeating Electric Train Heating Value Numeric
NumberOfSeats1stClas Number of 1st Class seats Numeric
s
NumberOfSeatsStanda Number of Standard Class seats Numeric
rdClass
NumberOfSeatsUnclas Number of seats Numeric
sified
GA 777465 Page 153 of 197

NumberOfSeatsPriority Number of priority seats on-board (e.g. for Numeric

elderly/people with limited-movement.
RestaurantFlag Flag to show if vehicle contains restaurant 1 character
WifiFlag Flag for Wifi available 1 character
NumberOfToilets Number of toilets on board. Numeric
Handicapped- Flag for if Handicapped-accessible 1 character
accessibleFlag
AuxiliaryServiceEnergy The consumption of auxiliary services UnitOfMeasure:
Consumption available in vehicle. Alphanumeric
Value: Numeric
VehicleStatus If the vehicle is in a Resource Group, this Alphanumeric
will be the same or ‘better’ than the value
for the whole of the resource group
NextAvailableLocation Location Vehicle is Available from, only if {Location}
VehicleStatus is not ‘N’
NextAvailableDateTime Conditional Field - Location from Where Datetime
Vehicle is available from
Coach Letter Coach letter from A-Z or Blank A-Z or Blank
FuelCapacity Fuel Capacity of Vehicle Numeric
NumberOfCabs Number of Cabs on Vehicle Numeric
Cab1TrainCommunicati List of Train communication Systems and List[Type:
on contact details (radio type etc) e.g. GSMR Alphanumeric ]
List[Contact: Number]
on contact details (radio type etc) e.g. Alphanumeric]
GSMR,CSR radio List[Contact: Number]
on contact details (radio type etc) e.g. GSMR Alphanumeric]
GPSFlag Flag to indicate GPS is available 1 character
DateEnteredService Date Vehicle Entered Service Date
VehicleRegistration Details of Vehicle Registration {VehivleRegistration}
CellphoneNumber Mobile Number for GSM Cab Radio Numeric
MaintanencePlanningS System used for Maintenance Planning Alphanumeric
ystem
ModificationIndicators Value indicating Modification Status Alphanumeric
VehicleName Name of Vehicle Alphanumeric
TrainBrakeType Type of Brake Used – “A” = Air Brake Code (e.g. “A” = Air
Brake)
MaximumSpeed Maximum Speed in defined unit UnitOfMeasure:Alphanu
meric
GA 777465 Page 154 of 197

Speed: Numeric
OperatorCode Company code for Vehicle Operator UIC Company Code
OwnerCode Company Code for Vehicle Owner UIC Company Code
HirerCode Company Code of Operator Hiring the UIC Company Code
Vehicle – may be different to the Vehicle
Operator
SubHirerCode If there is a sub-hire – the company sub- UIC Company Code
hiring is here
Defect Defects as recorded {Defect}
Table 8-148 – Vehicle
8.11.1.3.7 VehicleRegistration
Data containing the registration details of each vehicle.
VehicleRegistration
VehicleRegistrationSyst System that holds Vehicle Registration Alphanumeric
em Details
RegistrationDetails Registration Details Alphanumeric
DateRegistered Date vehicle was registered Date
DateRegistrationExpire Date the vehicle regeistration expires Date
s
Table 8-149 – VehicleRegistration
8.11.1.3.8 Defects
Each individual vehicle can have related defect information.
Defects
MaintenanceUID UID for Defects Record Alphanumeric
DefectCode Code to identify Defect Alphanumeric
MaintenanceDefectLoc Location of defect as stored in defect Alphanumeric
ation system
DefectDescription Defect Description Alphanumeric
DefectStatus Status of Defect Alphanumeric
MaintenanceRepairLoc Location of where the repair will take place Alphanumeric
ation as stored in defect system
RepairDescription Repair Description Alphanumeric
Table 8-150 – Defects
GA 777465 Page 155 of 197

8.11.1.4 Data related to Freight Consist Allocation

This section contains the data structures for Freight Consist and allocation. This is a train service
centric view. Each service is assigned a Freight Consists. This Freight Consist is made up from
Locomotives, Wagons and Wagon Containers. This can be used to identify the Rolling Stock
deployment plan of a vehicle.
Figure 8.8 – Overview Hierarchy of following freight consist data structures
8.11.1.4.1 FreightTrainConsistAllocation
This describes the train service details that will be allocated a freight consist.
FreightTrainConsistAllocation
TrainOperationalIdentifi Identifies the Scheduled Train Path ID in {TransportOperationalId
cation which the Physical Vehicles Run entifiers}
OperationalTrainNumb Current Train ID {OperationalTrainNumb
erIdentifier erIdentifier}
ReferenceOTN Originally Planned Train ID (if “Current” {OperationalTrainNumb
Train ID is Different) erIdentifier}
FreightTrainConsist Repeating Group – Identifies the {FreightConsist}
Allocation of Resource Groups (ie: Units or
Sets) To “Journey Legs” within the Path (A
“Journey Leg” is a portion of the Journey
along the Scheduled Train Path)
Table 8-151 – FreightTrainConsistAllocation
8.11.1.4.2 FreightConsist
This is the top level structure for the freight consist that forms the total train journey. It includes
the start and destination location and time for this train journey leg and some high level
information.
GA 777465 Page 156 of 197

FreightConsist
TrainConsistDateTime Time the consists data has been added Datetime
TrainOriginLocation Origin location of train {Location}
TrainDestinationLocatio Destination location of train {Location}
n
TrainLength Overall length of the train UnitOfMeasurement:
Alphanumeric
Value: Numeric
TrainLatestLocation Latest location of the train {Location}
TrainBrakeType Code for Train Brake Type Code e.g. A = Air Brake
PartialConsistFlag Identify consist with no locomotive or no 1 character
coaches/wagons
ExceptionalLoad Flag to indication special movement ExceptionalLoadFlag:
conditions are required. True/False
ExceptionalLoadDescri
ption: Alphanumeric
TrainLocomotives One or more locomotives for the train in N x {Locomotive}
the consist.
TrainWagons One or more Wagons for in the consist. N x {Wagon}
Table 8-152 – FreightConsist
8.11.1.4.3 Locomotive
This describes the Locomotive that is part of the Freight Train Consist.Including details such as
Maximum Speed and Weight.
Locomotive
LocomotiveNumber Identity number of vehicle Numeric
LocomotiveSpecialChar Special characteristics of the locomotive 2 1 character codes
acteristics
LocomotiveTrainPositio Sequence number of locomotive in train Numeric
n consist.
RouteAvailability Code used to match trains to routes they Numeric
can physically travel on
LocomotiveLength Length of the locomotive UnitOfMeasure:
Alphanumeric
Value: Numeric
MaximumSpeed Maximum Speed of Locomotive UnitOfMeasure:Alphanu
meric
Speed: Numeric
GA 777465 Page 157 of 197

Control List of Control Systems and description List[Code:

e.g. LZB, ERTMS L1 Alphanumeric]
List[Description:
Alphanumeric]
Weight Weight in metric tonnes Numeric
TractionType Electric Diesel Code
PowerSupply Source of Power e.g. Overhead Line Code
LoadingGauge Loading Gauge of Vehicle Numeric
TrackGauge Track Gauge of Vehicle Numeric
AttachLocation Location where locomotive is attached to {Location}
the train
DetachLocation Location where the locomotive is detached {Location}
from the train
Power Power of the Locomotive 1-9999
TrainCommunication List of Train communication Systems and List[Type:
contact details (radio type etc) e.g. GSMR Alphanumeric]
GPSFlag Flag to indicate GPS is available 1 character
RestrictedMaximumSpe Restricted maximum speed of the UnitOfMeasure:Alphanu
ed Locomotive meric
Speed: Numeric
LocomotiveBrakeForce Brake force of Locomotive 0-99
Table 8-153 – Locomotive
8.11.1.4.4 Wagon
This is used to describe that wagons that form the Freight Train.
Wagon
WagonTrainPosition Identifies position of wagon within train Numeric
formation. Sequential numbers. Front of
train is 1.
WagonNumber Unique identifier for Wagon 12 character EVN
RouteAvailability Code used to match trains to routes they Numeric
can physically travel on
WagonLoadingGauge Loading Gauge of Vehicle Numeric
WagonTrackGauge Track Gauge of Vehicle Numeric
WagonLength Length of the Wagon UnitOfMeasure:
Alphanumeric
Value: Numeric
GA 777465 Page 158 of 197

WagonMaximumSpeed Maximum speed of wagon UnitOfMeasure:Alphanu

meric
Speed: Numeric
GrossWeight Total Weight of goods in wagon or Numeric
transportation unit. (Booked weight of
goods included packing) in Kilograms.
WagonTareWeight Tare weight of wagon when empty in Numeric
Kilograms.
WagonNetWeight Net weight of load carried by wagon in Numeric
Kilograms.
WagonLoadStatus Code to indicate load statue Alphanumeric Code
e.g. E = Empty
WagonType Code to define Wagon Type Alphanumeric
UltimateDestination Final Location of the Wagon {Location}
CommodityCode Code indicating type of material the wagon Alphanumeric
is carrying
OriginLocation Wagon’s originating location {Location}
CrippleCode Code to indicate a problem with the wagon Alphanumeric
if one exists.
Customer Details of the Customer {Customer}
AttachLocation Location where the vehicle is attached {Location}
DetachLocation Location where the vehicle is detached {Location}
WagonCommunication Wagon communication method and Type: Alphanumeric
contact details (radio type etc) Contact: Numeric
WagonBrakeForce Brake force of Wagon 0-99
WagonDangerousGood Details of dangerous goods carried by {DangerGoods}
s wagon
SpecialHandlingCode If wagon has special handling Code
requirements.
SpecialCharacteristics Special characteristics Code Code
WagonContainers N x {Containers}
Table 8-154 – Wagon
8.11.1.4.5 Customer
The customers can be Identified using a customer code, along with their address and contact
details.
Customer
CustomerCodeISO Identifies Country or State by code Alphanumeric
PrimaryCode Primary customer code Code
GA 777465 Page 159 of 197

AdditionalCode Secondary customer code Code

Type Type of customer (Consignor, or Alphanumeric
Consignee)
CustomerCode Customer Code Customer Code
Name Customer Name Alphanumeric
AdditionalInformation Additional Information Alphanumeric
VAT Value Added Tax Numeric
POBox P.O. Box P.O. Box
StreetNumber Street Number Numeric
Street Street Alphanumeric
Country Country Alphanumeric
ZipCode Zip Code Alphanumeric
City City / Town Alphanumeric
Signature Signature Alphanumeric
Contacts Contact information Contact information
ContractualCarrierCode Contractual Carrier Code Alphanumeric
Table 8-155 – Customer
8.11.1.4.6 DangerousGoods
Dangerous goods information can be applied to both the Wagons and the Containers.
DangerousGoods
DangerousGoodsClass Class of dangerous goods Alphanumeric
DangerousGoodsExplo Code to identify if explosive Alphanumeric
siveCode
DangerousGoodsEmer Code related to type of dangerous goods Alphanumeric
gencyCode
ExplosivesEmergencyC Code related to type of explosives Alphanumeric
ode
Table 8-156 – DangerousGoods
8.11.1.4.7 Containers
Information related to the containers including dimensions and position on the wagon.
Containers
ContainerNumber Container number Numeric
ContainerID Container international ID (ISO 6346) Alphanumeric Code
Table 8-157 – Containers
GA 777465 Page 160 of 197

8.11.1.5 VehicleCharacteristics
Vehicle characteristics used to more accurately simulate train performance and can be used for
details that may not be required in higher level structures for scheduling.
VehicleCharacteristics
VehicleUniqueID Rolling Stock Register Unique ID for Alphanumeric
Vehicle
VehicleType Locomotive / Multiple Unit / Carriage / Alphanumeric
Wagon
VehicleFamily Text Describing the Class / Type etc… Alphanumeric
MaximumVelocity Maximum Speed for the Vehicle Numeric
Length Length over the Couplers for the Vehicle UnitOfMeasurement:
Alphanumeric
Value: Numeric
UnladenMass Weight with fuel (if used) but not UnitOfMeasurement:
passengers or freight payload Alphanumeric
Value: Numeric
UnsprungMass The mass of a wheel, or wheelset, UnitOfMeasurement:

and other associated Alphanumeric
components which are not dynamically
isolated from the track by Value: Numeric
Vehicle suspension arrangements.
ClingingFriction Defaults to 1 if not known. This is a Numeric
multiplier applied to the static friction to
indicate the force required to overcome
static inertia.
Rolling Resistance A This is used to plot the Rolling Resistance Numeric
Curve from 0 kph to the vehicle’s
maximum velocity
Rolling Resistance B This is used to plot the Rolling Resistance Numeric
maximum velocity
Rolling Resistance C This is used to plot the Rolling Resistance Numeric
maximum velocity
TractiveEffortCurve Table of values used to plot the general Table [From(km/h),
Speed / Force Curve Force(KN),To(km/h),For
ce(KN),]
GA 777465 Page 161 of 197

BrakingCategory Braking category Table [Braking

Category,DecelartionRa
te]
BrakeForce Generic Braking Force as a percentage of Numeric
‘g’ – applied from vehicle’s maximum
speed to zero kph
BrakingCurve Table of the braking force by speed Table [From(km/h),
Force(KN),To(km/h),For
ce(KN),]
DockingSystem Alphanumeric
NumberOfAxles Number of Axles Numeric
EnginePerformance Alphanumeric
Value assigned to the mechanical
performance of the engine of this
locomotive.
ConsumptionCurve In case of diesel and mixed engine Table[Power(kW), Fuel
locomotives, the fuel consumption will be Consumption(kg/h)]
characterized by the fuel consumption
curve. The curve must have at least three
pairs of values. The power will be
expressed in kW and fuel consumption in
kg / h
Uniform Acceleration Acceleration capacity of the vehicle. UnitOfMeasurement:
Alphanumeric
Value: Numeric
Uniform Deceleration Deceleration capacity of the vehicle UnitOfMeasurement:
Alphanumeric
Value: Numeric
Table 8-158 - VehicleCharacteristics
8.11.2 Requests
It is not foreseen that any direct commands on the stock and crew management system will need
to be run from other systems.

The role of the Rolling Stock and Crew management systems is to plan the use of resources to
actualise train journeys. The data required for the timetable and the latest forecasted plan of the
train journeys.
GA 777465 Page 162 of 197

• Train Timetables:
o Scheduled.
o Target.
o Forecasted.
o Audited.
• Rolling Stock Library.
Asset Management
8.12.1 Data
The aim of this chapter is to collect the information exchanged between a TMS and an Asset
Management System. The source of these information is the document [In2Rail D8.4] “Interface
Control Document for Integration Layer Interfaces, external/Web interfaces and Dynamic Demand
Service”. The following figure (courtesy of BT) depicts the relation between the TMS and the
advanced Asset Management System, and outlines the data flow between them.
GA 777465 Page 163 of 197

Figure 8.9 – Relation between TMS and Asset Management System

The above figure refers to WP9, Intelligent Mobility Management (I2M) – ‘Nowcasting’ and
Forecasting, which is one of the sub-project of In2Rail.
From the In2Rail site: “WP9 focuses on the design and development of an advanced asset
information system with the ability to ‘nowcast’ and forecast network asset status with the
associated probabilities”.
The advanced asset information system could be used in real time by the TMS in order to
immediately have a measure of the impact of an asset failure to the railway traffic / operations.
Alternatively, it could be used in an offline, simulated fashion by the maintenance department in
order to prioritize maintenance interventions based on the real impact of a sudden asset failure to
the railway traffic / operations.
The final goal is not to replace the TMS-Decision-support-function but to improve it by including
another decision support system which can provide useful and actionable information for the TMS.
WP9 lays the foundation of the main building blocks for the next generation Railway Asset
Management framework, further developed in IN2SMART, one of Shift2Rail project.
8.12.1.1 Point Machine

Point Machine
Decision Support New operational parameters Tbd – placeholder for
information for TMS suggested by the AMS outcomes of IN2SMART
Max. Speed Normal Maximum allowed speed to pass Binary to numeric (in km/h or
the object, as evaluated by the mi/h)
Asset Management System.
(Note: has a similar “plate” static
data, dependant on type of Point
Machine) – for normal position
Max. Speed Reverse Maximum allowed speed to pass Binary to numeric (in km/h or
the object, as evaluated by the mi/h)
Asset Management System.
Machine) – for reverse position
Max Axle Load Maximum allowed axle load to Binary to numeric (in N or kp)
pass the object, as evaluated by
the Asset Management System.
Machine)
Availability prognosis Indication on availability fore- 0..100 (or 0..1.0)
cast for the Object
Maintenance Object is under maintenance 0 => In maintenance
1 => In operation
Table 8.159 – Point Machine

GA 777465
8.12.1.2 Signal
Signal
cast for the Object
1 => In operation
8.12.1.3 Track Circuit

Track Circuit
cast for the Object
1 => In operation
Table 8.161 – Track Circuit
8.12.1.4 Axle Counter

Track Circuit
cast for the Object
1 => In operation
Table 8.162 – Axle Counter
8.12.1.5 Bridge
Level Crossing
cast for the Object
1 => In operation
Table 8.163 – Bridge
GA 777465
8.12.1.6 Tunnel
Level Crossing
cast for the Object
1 => In operation
Table 8.164 – Tunnel
8.12.1.7 Embankment
Level Crossing
cast for the Object
1 => In operation
Table 8.165 – Embankment
8.12.1.8 Line section

Level Crossing
cast for the Object
1 => In operation
Table 8.166 – Line Section
8.12.1.9 Level Crossing

Level Crossing
cast for the Object
1 => In operation
Table 8.167 – Line Section
GA 777465
Driver Advisory System (DAS)
8.13.1 Data
8.13.1.1 Status Report

Status Report data transmitted by the Driver Advisory System to the TMS are modelled on the
corresponding definition found in UNISIG SUBSET-126. The inspiring UML class diagram can be
found in SUBSET-126, Figure 6 Status Report Packet composition. The following table shall be
consistent and shall reflect upcoming changes in SUBSET-126. Additional data not found in
SUBSET-126 is marked by the annotation (*)2.
SR – Status Report
Train_Identifier (*) Is the running number of the String
train.
Consists of up to 8 digits which
are entered left adjusted into
the data field, the leftmost digit
is the digit to be entered first. In
case it is shorter than 8 digits,
the remaining space is to be
filled with special character “F”.
ETCS_Number (*) The ETCS identity number. Binary to numeric
The ETCS identity number is
uniquely defined for
ERTMS/ETCS purposes.
DAS_Identifier (*) Unique id and reference Binary to numeric
head/tail.
Part of DAS status information
DAS_Current_Status_ Current Status Operation 0 => no operation,
_Operation (*) 1 => in operation
DAS_Type (*) DAS Type: if DAS is connected 0 => connected,
or not to train 1 => non connected
Indicators_State Bitset with the indicators state. bit0 => Data inconsistency,
bit1 => Next Stopping Point
Skip, bit2 => Low adhesion
reported by the driver,
bit3 => Slip/Slide indication
detected by external system,
bit4 => Operational conditions
fulfilment,
bit5 => Train is moving,
bit6 => Unable to stop at the
next Stopping Point
2 (*) Not found in UNISIG SUBSET-126 specification.
GA 777465
Current_Speed (*) Current Speed of the train Binary to numeric.

when the Report is sent. One unit = 1km/h.
Driver_ID Driver identifier number as List of 0 to 1 element of
defined in SUBSET-027 String
SP_C_Identifier Identifier of the SP's country or Binary to numeric
region.
Code used to identify the
country or region in which the
balise group, the RBC or the
RIU is situated. These need
not necessarily follow
administrative or political
boundaries.
SP_Identifier SP identifier. Binary to numeric
Train_Position Position of the estimated front Binary to numeric (in
end of the train at the moment centimetres).
the Report is sent (relatively (224-1) = undefined location
from the beginning of the
given SP).
TP_Country_Identifier Identifier of the previous TP's Binary to numeric
country or region.
boundaries.
Previous_TP_Identifier Previous TP identifier Binary to numeric.
(232-1) = undefined value.
Pass_Stop_Depart Indicates if train has stopped at 0 => Train passes the TP,
the TP, has departed from the 1=> Train stops at the TP,
TP or has passed the TP. 2 => Train departs
from the TP,
3 => Undefined
Accurate_Stopping Specifies if the train has 0 => Undershoot,
stopped accurately or not at 1 => Accurate,
the Operational Stopping Point. 2 => Overshoot
Timing_Point_Estimation See table “SR Timing Point Indexed List of
Estimation” below Timing Point Estimation
Table 8.168 – SR Timing Point Estimation
SR – Status Report – Timing Point Estimation

Next_TP_C_Identifier Identifier of the next TP's Binary to numeric
country or region. Not relevant if
NID_TP is undefined.
Not relevant if
Next_TP_Identifier is undefined.
GA 777465

RIU is situated. These need not
necessarily follow
boundaries.
Next_TP_Identifier Next TP identifier. The NID_TP Binary to numeric
is unique within a NID_C. (132-1) = undefined value
Arrival_Date If Range = Ends or StartsEnds Value from 0 (01/01/2010) to
Location of the Switch off 32767 (18/09/2099)
Magnetic Shoe Brake area end
relatively to the beginning of the
SP.
Arrival_Seconds Estimated time in seconds to Value from 0 (00:00:00) to
arrive at the TP. 86399
(23:59:59)
Table 8.169 – SR Timing Point Estimation
8.13.1.2 Train Data
Data transmitted from the DAS system to the TMS. These data have no counterparts in
UNISIG SUBSET-126 specification. Additional data not found in SUBSET-126 is marked by
the annotation (*).
TD – Train Data
Train_Identifier (*) It is the running number of the String
train.
Consists on up to 8 digits which
are entered left adjusted into
the data field, the leftmost digit
is the digit to be entered first. In
case it is shorter than 8 digits,
the remaining space is to be
filled with special character “F”.
Train Category (*) Identifies the train category.
Category is related train
characteristics that identifies
different performances on same
tracks -
Train_Consist (*) Binary to numeric
(232-1) = undefined value
Vehicle (*) See table “TD Vehicledata” Indexed List of
below Vehicle Data
Locomotive / Wagon (*) See table “TD Locomotive / Indexed List of
Wagon data” below Locomotive / Wagon Data
Table 8.170 – TD Train Data
GA 777465
TD – Train Data –Locomotive / Wagon Data

Position (*) Loco / Wagon position Binary to numeric.
in train composition
Status (*) Qualifier, indicates if 0 => active traction,
Wagon / Loco is active 1 => towed
traction or towed
Category (*) Wagon category 0 => Locomotive
1 => Passenger Wagon,
2 => Freight Wagon,
3 => tbd
Power_Unit_Type (*) Indicates if Locomotive 0 => diesel,
has diesel, electric or 1 => electric
hybrid traction 2 => hybrid
Model (*) Wagon model String
Load_Weight (*) Weight of the hauled Binary to numeric, in kg
goods
Load_Type (*) Wagon type, if it is 1 => Passenger,
container, car, etc 2 => Container,
3 => Other, tbd
Loco / Wagon_Real_Mass (*) Loco / Wagon mass Binary to numeric, in kg
Loco / Wagon_Brake_Mass (*) Loco / Wagon brake Binary to numeric, in kg
mass
Loco / Wagon_Virtual_Mass (*) Loco / Wagon virtual Binary to numeric, in kg
mass
Loco / Wagon_Length (*) Loco / Wagon length Binary to numeric, in cm
Braking_Type (*) Type of braking system Binary to numeric.
Range tbd
Num_Axles (*) Number of axles Binary to numeric.
Range tbd
Axle_Load_Category (*) Axle load category, refer Binary to numeric.
to CR INF TSI Range tbd
Power_Consumption_Auxiliary_System Total Power Binary to numeric.
(*) Consumption Range tbd
Table 8.171 – TD Locomotive / Wagon Data
TD – Train Data – Vehicle Data

Model (*) Vehicle model String
Vehicle_Real_Mass (*) Vehicle real mass Binary to numeric, in
kg
Vehicle_Lenght (*) Train length Binary to numeric.
Range tbd
Voltage (*) Voltage Binary to numeric, in
N
Traction_Max_Power (*) Traction maximum power Binary to numeric.
Range tbd
Traction_efficiencies (*) Traction efficiencies Binary to numeric.
Range tbd
GA 777465
Max_speed (*) Maximum speed Binary to numeric.

Range tbd
Max_effort (*) Traction maximum effort Binary to numeric.
Range tbd
Effort_Speed_Characteristic (*) Traction effort-speed Binary to numeric.
characteristics Range tbd
Max_Acceleration (*) Maximum acceleration Binary to numeric.
Range tbd
Braking_Type (*) Braking Type: electrical, Binary to numeric.
mechanichal, regenerative, Range tbd
etc
Max_Braking_Force (*) Braking maximum force Binary to numeric, in
N
Service_Braking_Force (*) Service braking force Binary to numeric, in
N
Braking_performances (*) Braking performances 0..100 =>
performance
Max_Effort (*) Braking maximum effort Binary to numeric.
Range tbd
Effort_Speed_Characteristics (*) Braking effort-speed Binary to numeric.
characteristics Range tbd
Lower_Threshold (*) Lower speed threshold for Binary to numeric.
electrical braking Range tbd
Max_deceleration (*) Maximum deceleration Binary to numeric.
Range tbd
Lower_Threshold (*) Lower speed threshold for Binary to numeric.
electrical braking Range tbd
Max_deceleration (*) Maximum deceleration Binary to numeric.
Range tbd
Davis_Resistence_Prameter_A (*) It takes into account mass adimensional real
and mechanical resistance value from 0 to 1
Davis_Resistence_Prameter_B (*) It takes into account mass adimensional real
and mechanical resistance value from 0 to 1
Davis_Resistence_Prameter_C_in_op It takes into account adimensional real
en_air (*) aerodynamic resistance value from 0 to 1
Davis_Resistence_Prameter_C_in_tu It takes into account adimensional real
nnel (*) aerodynamic resistance value from 0 to 1
Braking_Time (*) It takes into account the Binary to numeric (in
time of braking sec)
Unbraking_Time (*) It takes into account the Binary to numeric (in
unbracing time sec)
Table 8.172 – TD Vehicle Data
GA 777465
8.13.2.1 Journey profile

Journey profiles data transmitted by the TMS to the Driver Advisory System are a subset of the
corresponding definition found in UNISIG SUBSET-126. The original UML class diagram can be
found in SUBSET-126, Figure 7 Journey Profile Packet Composition.
JP – Journey profile
JP_Status Status of the Journey Profile: 0 => Invalid,
1 => Valid,
2 => Unavailable,
3 => Update,
4 => End of Journey
Segment_Profile_List See table “JP Segment Profile Indexed List of
List” below Segment Profile List
Table 8.173 – Journey Profile (JP)
JP – Journey profile – Segment Profile List

NID_C Identifier of the SP's country or Code used to identify the
region country or region in which the
necessarily follow
boundaries.
NID_SP SP Identifier Binary to numeric.
SP_Version Identifier of the segment profile 1 byte for the major version and
version. 1 byte for the minor one.
SP_Dir Valid travelling direction of the 0 => Reverse,
SP. 1 => Nominal
Timing_Point_Constraints See table “JP Timing Point Indexed List of
Constraints” below Timing Point Constraints
Temporary_Constraints See table “JP Temporary Indexed List of
Constraints” below Temporary Constraints
Table 8.174 – JP Segment Profile List
JP – Journey profile – Timing Point Constraints

NID_TP Identifier Unique timing point identifier Binary to numeric.
(232-1) => undefined
Latest_Arrival_Date Date of the requested arrival Value from 0 (01/01/2010) to
time at the TP 32767 (18/09/2099)
Latest_Arrival_Seconds Seconds of the requested Value from 0 (00:00:00) to
arrival time al the TP 86399 (23:59:59) and 131071
for undefined arrival time.
GA 777465
Arrival_Window Acceptable time allowance to Binary to numeric (in seconds).

be earlier at the TP The value is 0 for Stopping
Points.
Train_Alignment This qualifier defines if the TP 0 => Front,
location is applicable from the 1 => Middle,
front, middle or rear of the train. 2 => Rear,
3 => Spare
Stop_Skip_Pass Specifies if the Timing Point is a 0 => Stopping point,
Passing Point, an operational 1 => Stopping Point to be
Stopping Point or a skipped skipped,
Stopping Point. 2 => Passing Point,
3 => Spare
TP_Specific_Info Specifies some information 0 => No specific information,
specific for the TP. 1 => End of Journey,
[2-3] => Spare
Day_Light_Saving Flag. Day light saving hour is 0 = No saving hour, 1 = Saving
applicable to calculate the local hour
time
StPt_Information See table “JP Stopping Point List of 0 to 1 elements of
Information” below Stopping Point Information
Table 8.175 – JP Timing Point Constraints
JP – Journey profile – Timing Point Constraints – Stopping Point Information

Departure_Date Date of the expected departure Value from 0 (01/01/2010) to
time from the Stopping Point. 32766 (17/09/2099)
32767 => undefined departure
time.
Departure_Seconds Seconds of the expected Value from 0 (00:00:00) to
departure time from the 86399 (23:59:59)
Stopping Point. 131071 => for undefined
departure time.
Train_Hold The variable defines if the train 0 => Do not hold Train,
is requested to be held at the 1 => Hold Train
Stopping Point or not.
Minimum_Dwell_Time Minimum dwell time at given Binary to numeric (in seconds)
Stopping Point (in seconds).
Table 8.176 – JP Timing Point Constraints – Stopping Points Information
JP – Journey profile – Temporary Constrains

TC_Type Reason for the temporary
0 = ASR, 1 = Low Adhesion, 2 =
constraint
ATO Inhibition Zone, 3 = DAS
Inhibition Zone, 3 = Spare
TC_Range Specifies if the temporary 0 = Starts, 1 = Ends, 2 =
onstraint starts, ends, starts and StartsEnds, 3 = WholeSP
GA 777465
ends or covers the whole

concerning Segment Profile.
TC_Start_Location Start location of the temporary List of 0 to 1 elements of
constraint relatively to the Binary to numeric (in
beginning of the SP. centimetres)
TC_End_Location End location of the temporary List of 0 to 1 elements of
constraint relatively to the Binary to numeric (in
beginning of the SP. centimetres)
Additional_Speed_ Indicates if a speed limit given List of 0 to 1 elements of
_Restriction_Front for a profile element is to be 0 = Train length delay on validity
applied until the front of the train end point of profile element
(no train length delay) or the 1 = No train length delay on
end of the train (train length validity end point of profile
delay) has left the element element
Additional_Speed_ Value of the speed level List of 0 to 1 elements of
_Restriction_Speed_ restriction. 0..120 => Speed_level. One unit
_Level = 5km/h
Low_Adhesion_Rate Value of the braking capacity List of 0 to 1 elements of
remaining. 0 => 100%,
1 => 90%,
2 => 80%,
3 => 70%,
4 => 60%,
5 => 50%,
6 => 40%,
7 => 30%
Table 8.177 – JP Temporary Constrains
8.13.2.2 Segment Profile

Segment profiles data transmitted by the TMS to the Driver Advisory System are a subset of the
corresponding definition found in UNISIG SUBSET-126. The original UML class diagram can be
found in SUBSET-126, Figure 8 “Segment Profile Packet Composition (1/2)” and Figure 9
“Segment Profile Packet Composition” (2/2)”
SP – Segment Profile – –
Segment_Profile See table “SP Segment Profile Indexed List of
Details” below Segment Profile Details
Table 8.178 – SP – Segment Profile
SP – Segment Profile – Segment Profile Details –

ID_C Identity number of Code used to identify the
country/region (Code used to country or region in which the
identify the country or region balise group, the RBC or the
in which the balise group, the RIU is situated. These need not
RBC or the RIU is situated.) necessarily follow
GA 777465
boundaries.
ID_SP SP Identifier Binary to numeric.
SP_Status Status of the SP: 0 => Invalid,
"Valid": SP requested. 1 => Valid
"Invalid": SP not found in
database.
SP_Version Identifier of the SP version 1 byte for the major version and
1 byte for the minor one.
SP_Length Length of the segment of Binary to numeric (in
railway covered by the SP. centimetres)
EoA_Offset Distance to stop the train Binary to numeric (in
before an EoA. centimetres)
UTC_Offset Offset to add to the UTC time Binary to numeric.
in order to calculate the local 0..39 => UTC offsets
time.
SP_Altitude Altitude at the beginning of Binary to numeric (in
the SP. (ETRS 89 Reference) centimetres) starting at -1000m
SSP_Start_ Static Speed Profile Start - 0..120 =>
_Static_speed Basic Static Speed Profile SSPS_STATIC_speed.
Speed at the beginning of the One unit = 5 km/h
SP
SSP_Start_Front Static Speed Profile Start - 0 => Train length delay,
Indicates if the Static Speed 1 => No train length delay
Profile is to be applied to the
front of the train (no train
length
delay) or to the end of the
train (train length delay).
SSP_Start_Specific_ See table “Specific Speed Indexed List of
_Speed_Profile Profile” below Specific Speed Profile
SSP_Start_Static_Speed_ See table “SP Static Speed Indexed List of
_Profile_Change Profile Change” below Static Speed Profile Change
Gradient_Start_ Value of the new gradient at Binary to numeric (0-255) with
_New_Gradient the beginning of the Segment resolution 1‰
Profile
Gradient_Start_ Direction of the new gradient 0 => Downhill,
_New_Gradient_Direction 1 => Uphill
Gradients_Change See table “SP Gradients Indexed List of
Change” below Gradient Changes
Curve_Start_ Curve category at the 0 => R>7000m,
_Radius_Category beginning of the Segment 1 => 7000m≥R>4500m,
Profile 2 => 4500m≥R>2800m,
3 = 2800m≥R>2000m,
4 => 2000m≥R>1500m,
5 => 1500m≥R>1250m,
6 => 1250m≥R>1075m,
7 => 1075m≥R>925m,
8 => 925m≥R>825m,
GA 777465
9 => 825m≥R>725m,
10 => 725m≥R>625m,
11 => 625m≥R>525m,
12 => 525m≥R>475m,
13 => 475m≥R>425m,
14 => 425m≥R>375m,
15 => 375m≥R>325m,
16 => 325m≥R>300m,
17 => 300m≥R>275m,
18 => 275m≥R>250m,
19 => 250m≥R>225m,
20 => 225m≥R>200m,
21 => 200m≥R>175m,
22 => 175≥R>150m,
23 => R≤150m;
Curve_Start_ Side of the curve 0 => Left,
_Curve_Side 1 => Right
Curves_Changes See table “SP Curves Indexed List of
Change” below Curves Change
Power_Voltage_Start_ Voltage value at the 0 Line not fitted with any
_Voltage beginning of Segment Profile traction system
1 AC 25 kV 50 Hz
2 AC 15 kV 16.7 Hz
3 DC 3 kV
4 DC 1.5 kV
5 DC 600/750 V
Power_Voltage_Start_ Country identifier of the Binary to numeric
_C_Traction traction system.
boundaries.
Power_Voltages_Changes See table “SP Power Indexed List of
Volatage Changes” below Power Voltages Changes
Current_Limitation_Start Allowed current consumption 0..1000 => allowed current
at consumption to be used by the
the beginning of the Segment train. One unit = 10 A
Profile.
Current_Limitation_ See table “SP Current Indexed List of
_Changes Limitation Changes” below Current Limitation Changes
Balise_Group See table “SP Balises” below Indexed List of
Indexed List of
Balises
Platform_Areas See table “SP Platform Area” Indexed List of
below Platform Area
GA 777465
Tunnels See table “SP Tunnel” below Indexed List of

Tunnel
Powerless_Section See table “SP Powerless Indexed List of
Section” below Powerless Section
Axel_Load_Speed_Profile See table “SP Axel Load Indexed List of
Speed Profile” Axel Load Speed Profile
Unprotected_Level_ Location of the stop in rear of Indexed List of
_Crossing Stop an unprotected level crossing. Binary to numeric (in
centimeters)
Permitted_Breaking_ See table “SP Permitted Indexed List of
_Distance Braking Distance” below Permitted Braking
Distance
Switch_off_Regenerative_ See table “SP Switch off Indexed List of
_Breaking regenerative breaking” below Switch off regenerative
breaking
Switch_off_Eddy_ See table “SP Switch off Indexed List of
_Current_Brake Eddy Switch off Eddy
Current Brake” below Current Brake
Switch_off_Current_ See table “SP Switch off Indexed List of
_Emergency_Brake Current Emergency Brake” Switch off Current
below Emergency Brake
Switch_off_Magnetic_ See table “SP Switch off Indexed List of
_Shoe_Brake Magnetic Shoe Brake” below Switch off Magnetic
Shoe Brake
Table 8.179 – SP Segment Profile Details
SP – Segment Profile – Static Speed Profile Start - Specific Speed Profile –

Category Indicates the type of specific Binary to numeric
Static Speed Profile category.
Indicates the type of specific
SSP category
In case of “other specific” SSP,
it tells ERTMS/ETCS on-board
equipment whether it replaces
or not the Cant Deficiency SSP
as selected by on-board , when
the train belongs to an “other
international” train category to
which the “other specific” SSP
applies
Cant_Deficiency It is the “Cant Deficiency” SSP List of 0 to 1 elements of

category for which a different Binary to decimal,
value for the static line speed 0 => Specific SSP applicable to
exists Cant Deficiency 80 mm
1 => Specific SSP applicable to
Cant Deficiency 100 mm
GA 777465

10 => Specific SSP applicable
to Cant Deficiency 300 mm
Other_Specific “Other specific” SSP category List of 0 to 1 elements of
for which a different value for Binary to decimal,
the static line speed exists. 0 => Specific SSP applicable to
Freight train braked in “P”
position
position
Passenger train
Absolute_Speed Absolute Positive Speed 0..120 => Absolute speed. One
associated to a train category. unit = 5km/h
Table 8.180 – SP Specific Speed Profile
SP – Segment Profile – Static Speed Profile Start – Static Speed Profile Change
Location Location of the Static Speed Binary to numeric (in
Profile change relatively to the centimetres)
beginning of the SP.
Static_Speed Basic Static Speed Profile 0..120 => Static speed. One unit
Speed when it changes = 5km/h
Front Indicate if the Static Speed 0 =>Train length delay,
Profile is to be applied to the 1 => No train length delay
front of the train (no train length
delay) or to the end of the train
(train length delay).
Specific_Static_Speed_ See table “SP Specific Static Indexed List of
_Profile_Change Speed Profile Change” below Specific Static Speed Profile
Change
Table 8.181 – SP Static Speed Profile Change
GA 777465
SP – Segment Profile – Static Speed Profile Start – Static Speed Profile Change –
Specific Static Speed Profile Change
Category Indicates the type of specific Binary to numeric
Static Speed Profile category.
Indicates the type of specific
SSP category
In case of “other specific” SSP,
it tells ERTMS/ETCS on-board
equipment whether it replaces
or not the Cant Deficiency SSP
as selected by on-board , when
the train belongs to an “other
international” train category to
which the “other specific” SSP
applies
Cant_Deficiency “Cant Deficiency” SSP category List of 0 to 1 elements of
for which a different value for Binary to decimal,
the static line speed exists 0 => Specific SSP applicable to
8 =>Specific SSP applicable to
Other_Specific List of 0 to 1 elements of
Binary to decimal,
Freight train braked in “P”
position
position
Passenger train
GA 777465
Absolute_Speed 0..120 => Absolute speed. One

unit = 5km/h
Table 8.182 – SP Specific Static Speed Profile Change
SP – Segment Profile – Gradient Start – Gradient Changes

Location Location of the gradient change Binary to numeric (in
relatively to the beginning of the centimetres)
SP.
New_Gradient Value of the new gradient Binary to numeric (0-255) with
when it changes resolution 1‰
Direction Direction of the new gradient 0 => Downhill,
1=> Uphill
Table 8.183 – SP Gradient Changes
SP – Segment Profile – Curve Start – Curves Changes

Location Location of the curve change Binary to numeric (in
SP.
Radius_Category Curve category when it 0 => R>7000m;
changes 1 => 7000m≥R>4500m;
2 => 4500m≥R>2800m;
3 => 2800m≥R>2000m;
4 => 2000m≥R>1500m;
5 => 1500m≥R>1250m;
6 => 1250m≥R>1075m;
7 => 1075m≥R>925m;
8 => 925m≥R>825m;
9 => 825m≥R>725m;
10 => 725m≥R>625m;
11 => 625m≥R>525m;
12 => 525m≥R>475m;
13 => 475m≥R>425m;
14 => 425m≥R>375m;
15 => 375m≥R>325m;
16 => 325m≥R>300m;
17 => 300m≥R>275m;
18 => 275m≥R>250m;
19 => 250m≥R>225m;
20 => 225m≥R>200m;
21 => 200m≥R>175m;
22 => 175≥R>150m;
23 => R≤150m;
Curve_Side Side of the curve 0 = Left, 1 = Right
GA 777465
Table 8.184 – SP Curves Changes
SP – Segment Profile – Power Voltage Start – Power Voltage Change

Location Location of the voltage change Binary to numeric (in
SP.
Voltage Voltage value when it changes 0 => Line not fitted with any
traction system
1 => AC 25 kV 50 Hz
2 => AC 15 kV 16.7 Hz
3 => DC 3 kV
4 => DC 1.5 kV
5 => DC 600/750 V
C_Traction Country identifier of the traction Binary to numeric
system.
necessarily follow
boundaries.
Table 8.185 – SP Power Voltage Change
SP – Segment Profile – Current Limitation Start – Power Voltage Current Limitation

Change
Location Location of the Allowed Current Binary to numeric (in
Consumption relative to the centimetres)
Current Allowed Current Consumption 0..1000 => allowed current
at the beginning of SP and consumption to be used by the
when it changes train. One unit = 10 A
Table 8.186 – SP Power Voltage Change
SP – Segment Profile – Balise Group – Balises

Balise_Group Identifier of the balise group Binary to numeric
Identity number of a balise
group or loop within the country
or region.
Each group includes 1 to 8
balises
Position_In_Group Defines the relative position in a 0 => First
balise group …
7 => Eight
GA 777465
Location Location of the balise relatively Binary to numeric (in

to the beginning of the SP. centimetres)
Table 8.187 – SP Baslises
SP – Segment Profile – Timing Points

TP_Identifier TP identifier. The NID_TP is Binary to numeric.
unique within a NID_C. (132-1) for undefined value.
Location Location of the Timing Point Binary to numeric (in
relatively to the beginning of centimetres)
the
SP.
Stop_Location_Tolerance Required stopping tolerance to 0 => 10cm,
use when the TP is a Stopping 1 => 20cm,
Point.. 2 => 30cm,
3 => 40cm,
4 => 50cm,
5 => 1m,
6 => 1,5m,
7 => 2m,
8 => 2,5m,
9 => 3m,
10 => 5m,
11 => 7,5m,
12 => 10m,
13 => 15m,
14 => 20m,
15 => 25m,
16 => 30m,
17 => 50m,
18 => 75m,
19 => 100m,
31 => No requirement
Distance_SP Distance from a Stopping Point Bynary to numeric
to consider it as reached
TP_Name Name of the TP Indexed List of
Text strings are used to Strings
transmit plain text messages.
Each element of a text string
contains a single character
encoded as ISO 8859-1, also
known as Latin Alphabet #1.
Table 8.188 – SP Timing Points
SP – Segment Profile – Platform Area

Range Specifies if the Platform Area 0 => Starts,
starts, ends, starts and ends or 1 => Ends,
GA 777465
covers the whole concerning 2 => StartsEnds,

Segment Profile. 3 => WholeSP
Start_Location [If Q_Range = Starts or List of 0 to 1 elements of
StartsEnds] Binary to numeric (in
Location of the platform start centimetres)
SP.
End_Location [If Q_Range = Ends or List of 0 to 1 elements of
StartsEnds] Binary to numeric (in
Location of the platform end centimetres)
SP.
Table 8.189 – SP Platform Area
SP – Segment Profile – Tunnel

Range Specifies if the Tunnel starts, 0 => Starts,
ends, starts and ends or covers 1 => Ends,
the whole concerning SP 2 => StartsEnds,
3 => WholeSP
Tunnel_Category Category of the Tunnel. 1 => Single track tunnel,
2 => Double track tunnel
Start_Location If Range = Starts or StartsEnds List of 0 to 1 element of
Location of the tunnel start Binary to numeric (in
SP.
End_Location If Range = Ends or StartsEnds List of 0 to 1 element of
Location of the tunnel end Binary to numeric (in
SP.
Table 8.190 – SP Tunnel
SP – Segment Profile – Powerless Section

Range Specifies if the Powerless 0 => Starts,
Section starts, ends, starts and 1 => Ends,
ends or covers the whole 2 => StartsEnds,
concerning Segment Profile. 3 => WholeSP
Location of the Powerless Binary to numeric (in
Section start relatively to the centimetres)
Location of the Powerless Binary to numeric (in
Section end relatively to the centimetres)
Table 8.191 – SP Powerless Section
GA 777465
SP – Segment Profile – Axel Load

Range Specifies if the Axle Load 0 => Starts,
Speed Profile starts, ends, 1 => Ends,
starts and ends or covers the 2 => StartsEnds,
whole concerning SP 3 => WholeSP
AL_Category Axle load from which the speed
restriction is applicable.
The values allocated below
correspond to a list of
increasing axle load categories
(i.e. B1 > HS17, B2 > B1, D2 >
C4, ….etc) and it is used by the
on-board equipment to compare
its axle load category with the
axle load category sent by
trackside.
For the underlying meaning of
the axle load categories listed
below (with the exception of
HS17) refer to CR INF TSI.
The category HS17 (axle load
<= 17t) corresponds to a static
load per axle only, as specified
in HS RST TSI clause 4.2.3.2.
The introduction of this artefact
is necessary to ensure
backward compatibility, without
any negative performance
impact, in case ASPs are used
on lines operated with system
version X = 1. 0 = A,
1 = HS17, 2 = B1, 3 = B2, 4 =
C2, 5 = C3, 6 = C4, 7 = D2, 8 =
D3,
9 = D4, 10 = D4XL, 11 = E4, 12
= E5, 13 - 127 = Spare
New_Speed_Level Speed restriction to be applied 0..120 => New Speed Level.
if the axle load of the train ≥ One unit = 5km/h
AL_Category
Front Indicate if the ALSP is to be 0 => Train length delay,
applied to the front of the train 1 => No train length delay
(no train length delay) or to the
end of the train (train length
delay)
Location of the Axle Load Binary to numeric (in
Speed Profile start relatively to centimetres)
the beginning of the SP.
GA 777465
Location of the Axle Load Binary to numeric (in

Speed Profile end relatively to centimetres)
the beginning of the SP.
Table 8.192 – SP Axel Load Speed Profile
SP – Segment Profile – Permitted Breaking Distance

Range Specifies if the Permitted 0 => Starts,
Braking Distance area starts, 1 => Ends,
ends, starts and ends or covers 2 => StartsEnds,
the whole concerning Segment 3 => WholeSP
Profile.
Permitted_Braking_ Permitted Braking Distance Binary to numeric (in
_Distance value. centimetres)
Location of the Permitted Binary to numeric (in
Braking Distance area start centimetres)
SP.
Location of the Permitted Binary to numeric (in
Braking Distance area end centimetres)
SP.
Table 8.193 – SP Permitted Breaking Distance
SP – Segment Profile – Switch off Regenerative Brake

Range Specifies if the Switch off 0 => Starts,
Regenerative Brake area starts, 1 => Ends,
ends, starts 2 => StartsEnds,
and ends or covers the whole 3 => WholeSP
Location of the Switch off Binary to numeric (in
Regenerative Brake area start centimetres)
SP.
Regenerative Brake area end centimetres)
SP.
Table 8.194 – SP Switch off Regenerative Brake
SP – Segment Profile – Switch off Eddy Current Brake

GA 777465

Eddy Current Brake area starts, 1 => Ends,
ends, starts 2 => StartsEnds,
and ends or covers the whole 3 => WholeSP
Location of the Switch off eddy Binary to numeric (in
current brake for service brake centimetres)
area start relatively to the
Eddy Current Brake area end centimetres)
SP.
Table 8.195 – SP Switch off Eddy Current Brake
SP – Segment Profile – Switch off Eddy Current Emergency Brake

Eddy Current Brake for 1 => Ends,
emergency brake area starts, 2 => StartsEnds,
ends, starts and ends or covers 3 => WholeSP
the whole concerning Segment
Profile.
current brake for emergency centimetres)
brake area start relatively to the
current brake for emergency centimetres)
brake area end relatively to the
Table 8.196 – SP Switch off Eddy Current Emergency Brake
SP – Segment Profile – Switch off Magnetic Shoe Brake

Magnetic Shoe Brake brake 1 => Ends,
area starts, ends, starts and 2 => StartsEnds,
ends or covers the whole 3 => WholeSP
Magnetic Shoe Brake area start centimetres)
GA 777465
SP.
Magnetic Shoe Brake area end centimetres)
SP.
Table 8.197 – SP Switch off Magnetic Shoe Brake
Passenger Information Systems (PIS)
8.14.1 Data
8.14.1.1 Passenger related information

Passenger related information
Train ID Operational train number String
Running Datetime Running day and starting time of the Datetime
train
Unit ID Rolling Stock Unit ID String (UIC-ident Number)
Booked Number of booked passengers Integer >=0
passengers 1st within this rolling stock unit (1st
Class class)
Booked Number of booked passengers Integer >=0
passengers 2nd within this rolling stock unit (2nd
Class class)
Passengers Number of passengers within this Integer >=0
rolling stock unit
Passengers per Number of passengers within this n x Integer > =0
destination rolling stock unit per booked
destination station
Table 8.198 – Passenger related information
For the starting location the arrival time is given by the time of making the train available on the
platform track, i.e. the track occupancy begins.
For the destination location the departure time is given by the time the train is moved away from
the platform track, i.e. the track occupancy ends.
8.14.2 Alarms
At least the following alarms have been detected related to PIS:
• Disruption of communication towards PIS

GA 777465
• Published Timetable from timetable master system

• Online Production Plan from TMS
• Generic train dependencies (including transfer connection dependencies) from TMS
• Generic disruption information (possessions, TSR, incidents) from TMS
8.14.3.1 Timetable Train Header

Timetable Train Header
Train run ID ID of the train run (reference to train String
ID in train table)
Train departure Date/Time of the train departure Datetime
datetime from origin
Table 8.199 – Timetable Train Header
8.14.3.2 Timetable Train Details

Timetable Train Details
Record ID Internal Record ID Id
ID in train table)
Train location ID Location whithin the train’s journey Location ID
leg
Arrival datetime Time of arrival at the location Datetime
Departure datetime Time of departure from the location Datetime
Location track ID Track ID on which the train is Track ID
expected at the location
Arrival/departure Platform on which the train is Platform number
platform expected
Train consist data Coach information including, coach Coach ID and sequence ID,
ID and sequence ID, and occupancy occupancy (percentage or ratio)
referring to the direction of travel
Table 8.200 – Timetable Train Details
8.14.3.3 Train Connection Status

Train Connection Status
Train run ID 1 ID of the first train run (reference to String
train ID in train table)
Train departure Date/Time of the departure of the Datetime
datetime 1 first train
Train run ID 2 ID of the second train run (reference String
to train ID in train table)
Train departure Date/Time of the departure of the Datetime
datetime 2 second train
Connection type Type of the train connection (split, String
etc)
GA 777465
Connection status Status of the train connection Integer

Arrival connection Location ID of the arriving train Id
location connection
Departing Location ID of the departing train Id
connection location connection
Arrival connection Track ID of the connecting service Track ID
Connection type Type of the train connection, e.g. String
transfer connections, and
operational dependencies such as
splitting, coupling, etc.
Alternative Alternative location of the train Track Id
Connection connection
Location
Max waiting time Maximum waiting time for second Time
train
Min handling time Minimum handling time for first train Time
Table 8.201 – Train Connection Status
8.14.3.4 Disruption Information

Disruption information
Id Identification of the disruption Id
Disruption begin Begin date and time of the disruption Datetime
datetime
Disruption end Expected end date and time of the Datetime
datetime disruption (optional)
Disruption type Type of the disruption String
Disruption Description of the disruption String
description
Creation Time when the disruption record Datetime
timestamp was created
Related train run ID ID of the train run to which the String
disruption info is related (optional)
Related train Date/Time of the departure of the Datetime
departure datetime train being related to the disruption
(optional)
Related train First train location ID at/from which Id (of train details table)
location begin on the disruption is relevant
(optional)
Related train First train location ID at/up to which Id (of train details table)
location end the disruption is relevant (optional)
Related Replacement services for disrupted String
replacement services (connections), remark: free
services text entry with potential future key
value pair structure
Table 8.202 – Train Disruption Information
GA 777465
8.14.3.5 Train Running Forecast

Train Running Forecast
ID in train table)
Train departure Date/Time of the train departure Datetime
datetime
Train location ID Location within the train’s journey Location ID
leg
Forecasted arrival Time of arrival at the location Time
time
Forecasted Time of departure at the location Time
Departure time
Table 8.203 – Train Running Forecast
Public Weather Information Services
8.15.1 Data
8.15.1.1 Weather information

Weather information
Id Identity of the record
Timestamp Time of observation Local/Central
Geo-reference Latitude, Longitude 2x String
Max wind speed Decimal (m/s)
Meridional wind Wind speed in north-south direction
Decimal (m/s)
speed
Zonal wind speed Wind speed in west-east direction Decimal (m/s)
Relative humidity (ratio between the
actual amount of water vapour
Relative humidity present to the capacity that the air
Decimal (percent)
(2m above ground) has at a particular moment)
measured 2m above ground in
percent
Surface specific Relative humidity measured on
n x Decimal (percent) (for each
humidity (e.g., specific material surfaces in percent
type of surface)
steel)
Temperature of the air in degree
Air temperature Decimal (degree centigrade)
centigrade
Ground Temperature on the ground in
Decimal (degree centigrade)
temperature degree centigrade
Relative volumetric water content of
Soil moisture Decimal (percent)
soil
Snow depth Depth of snow Decimal (m)
Snow density Density of snow Decimal (g/cm³)
Solar irradiation Solar irradiation Decimal (W/m²)
GA 777465
Table 8.204 – Weather information
8.15.2 Alarms
At least the following alarms have been detected related to public weather services:
• Disruption of communication (information retrieval from weather services).

• Spatial baseline data (areas, railway lines and nodes, track sections and switches) with geo-
references.
GA 777465
9 REFERENCES
[ERTMS SRS 026] ERTMS/ETCS Class 1 System Requirement Specification –
SUBSET 026 Version 3.6.0, July 2017 ERA
[In2Rail D7.5-1] In2Rail Project, Grant Agreement H2020-MG-2014-635900 –

D7.5 Evaluation of the Proof of concept: Appendix 1:
Requirement List – 30/09/2016, http://www.In2Rail.eu/
[In2Rail D8.1] In2Rail Project, Grant Agreement H2020-MG-2014-635900 –

D8.1 Requirements for the Integration Layer – 21/09/2016,
http://www.In2Rail.eu/

D8.2 Requirements for Interfaces – 31/07/2017,

D8.3 Description of Integration Layer and Constituents –
17/04/2018, http://www.In2Rail.eu/

D8.4 Interface Control Document for Integration Layer
Interfaces, external/Web interfaces and Dynamic Demand
Service – 16/04/2018, http://www.In2Rail.eu/

D9.1 Asset status representation – 28/06/2017,
GA 777465
Appendix A: Comparison of Middleware Products
Table 9.1 – Comparison of Middleware Products (Requirements for Integration Layer)
GA 777465 Page 194 of 197

Table 9.2 – Comparison of Middleware Products (Requirements for Interfaces)
GA 777465 Page 195 of 197

Table 9.3 – Comparison of Middleware Products (Economical Criteria)
GA 777465 Page 196 of 197

Appendix B: Ownership of results

The table lists the ownership of results for this deliverable.
Ownership of results
Company Percentage Short Description of share of Concrete Result
delivered input (where applicable)
IND 9,09 Coordinating document, contributions,
discussions, reviews
STS 9,09 Contributions, discussions, reviews
AZD 9,09 Contributions, discussions, reviews
BTSE 9,09 Contributions, discussions, reviews
CAF 9,09 Contributions, discussions, reviews
DB 9,09 Contributions, discussions, reviews
HC 9,09 Contributions, discussions, reviews
NR 9,09 Contributions, discussions, reviews
SIE 9,09 Contributions, discussions, reviews
THA 9,09 Contributions, discussions, reviews
TRV 9,09 Contributions, discussions, reviews
Table 9.4: Ownership of results

X2R2-WP6-D-BTS-051-01 - System Requirements Specification (SRS) For Integration Layer

Uploaded by

Document Information

Original Description:

Original Title

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

X2R2-WP6-D-BTS-051-01 - System Requirements Specification (SRS) For Integration Layer

Uploaded by

Copyright:

Available Formats

X2Rail-2

Project Title: Enhancing railway signalling systems based on train

Due date of deliverable Month 30

Deliverable template version: 05 (13/02/18)

Author(s) INDRA Sistemas S.A. (INDRA)

GA 777465 Page 3 of 197

2 TABLE OF CONTENTS ...................................................................................................................................... 4

3 ABBREVIATIONS AND ACRONYMS ................................................................................................................. 7

5 OBJECTIVE / AIM .......................................................................................................................................... 10

6 REQUIREMENTS FOR THE INTEGRATION LAYER ........................................................................................... 12

FUNCTIONAL PURPOSE OF THE INTEGRATION LAYER ............................................................................................... 12

7 MIDDLEWARE STATE OF THE ART EVALUATION ........................................................................................... 18

MIDDLEWARE ASSESSMENT CRITERIA .................................................................................................................. 18

8 DATA STRUCTURES ...................................................................................................................................... 34

GA 777465 Page 4 of 197

GA 777465 Page 5 of 197

APPENDIX A: COMPARISON OF MIDDLEWARE PRODUCTS ........................................................................................... 194

GA 777465 Page 6 of 197

3 ABBREVIATIONS AND ACRONYMS

Abbreviation / Acronyms Description

GA 777465 Page 7 of 197

GA 777465 Page 8 of 197

GA 777465 Page 9 of 197

GA 777465 Page 10 of 197

8 Data Structures Identification and detail of the information required to

Table 5.1: Document Structure

6 REQUIREMENTS FOR THE INTEGRATION LAYER

Functional Purpose of the Integration Layer

In this document both aspects of the Integration Layer are covered:

GA 777465 Page 12 of 197

GA 777465 Page 13 of 197

6.2.3 Quality of Service (QoS)

GA 777465 Page 14 of 197

6.3.1 Security & Accounting

6.3.1.2 Permissions (authorization)

6.3.1.3 Message Security, Confidentiality and Integrity

GA 777465 Page 15 of 197

6.3.1.4 System Protection

6.3.2 Data Access Patterns

6.3.3.1 Messaging Channel Patterns

GA 777465 Page 16 of 197

6.3.3.2 Message Construction Patterns

6.3.3.3 Message Payload Format

6.3.3.4 Message Model Versioning

GA 777465 Page 17 of 197

7 MIDDLEWARE STATE OF THE ART EVALUATION

Middleware Assessment Criteria

GA 777465 Page 18 of 197

− Support the request-reply exchange pattern.

GA 777465 Page 19 of 197

− It should be possible for modules to be notified of apparition and suppression of given

Middleware Products Selection

7.3.1 Comparison of Middleware Products

7.3.2 Weaknesses and Strengths of analysed Middleware Products

7.3.2.1 Apache Kafka

GA 777465 Page 21 of 197

In the context of messaging, although it is designed as a publish-subscribe system, it can be configured to

7.3.2.2 Infinispan (Red Hat Data Grid)

In the context of messaging, it allows exchange in different ways as point-to-point, publication-

GA 777465 Page 23 of 197

In the context of messaging, it allows exchange in different ways as point-to-point, publication-

GA 777465 Page 24 of 197