Implementing the TSI EU into the System of Developing the Annual
Train Timetable of the Infrastructure Manager
KAREL GREINER
Department of Informatics and Mathematics in Transport,
Faculty of Transport Engineering,
University of Pardubice,
Studentská 95, 532 10, Pardubice,
CZECH REPUBLIC
Abstract: – The paper describes a new method of developing the annual train timetable in the information
system of the infrastructure manager in the Czech Republic. The system is accessible to the information
systems of railway undertakings through a data interface that allows receiving and providing messages
compliant with the TAF / TAP TSI specifications of the European Union. In order to develop a timetable,
processes are designed for processing a new request, modifying and cancelling a request by the railway
undertaking, deleting a route by the infrastructure manager, and processing data that is not needed at the time of
path construction.
Key-Words: - Timetable, train, path, information system, KANGO, TSI
Received: July 14, 2022. Revised: March 10, 2023. Accepted: March 21, 2023. Published: May 3, 2023.
1 Introduction
In the past, the annual train timetable in the Czech
Republic was developed at the level of the national
railway undertaking České dráhy, which acted as
both railway undertaking and infrastructure
manager.
In 2006, the development of the new KANGO
system was initiated for the company České dráhy,
which at that time also served as the infrastructure
manager. During the development of this system,
the role of the infrastructure manager was taken
over by the state organisation Správa železnic. The
KANGO system was divided into two systems, but
the module for entering railway undertakings'
requirements for train paths remained common for
both organisations. Routine operation of these
systems commenced at the end of 2010.
The other railway undertakings passed their
orders outside the system to the infrastructure
manager's staff who entered them into the KANGO
system.
To make the KANGO system accessible to the
information systems of different railway
undertakings and to meet the interoperability
conditions of the European Union, it was necessary
to develop the infrastructure manager's data
interface and redesign the train path requirements
module.
2 Original System
The concept of the annual train timetable
compilation in the Czech Republic was based on
two information systems, KANGO and KASO, [1].
The structure of these systems is shown in Figure 1.
The KANGO system was primarily designed for
infrastructure managers, while the KASO system
was used exclusively by the national railway
undertaking České dráhy.
KANGO-Kmen
KANGO-GVD KANGO-Vlak
PCS
KASO
modules
Fig. 1: Earlier architecture of information systems
for the development of the annual train timetable
The development of the timetable starts with the
preparation of master data (railway network,
traction vehicles, etc.) in the KANGO-Kmen
module. The basic train data are acquired by the
railway undertaking or on its behalf by an employee
of the infrastructure manager in the KANGO-Vlak
module, [2]. The train construction is performed by
WSEAS TRANSACTIONS on SYSTEMS
DOI: 10.37394/23202.2023.22.41
Karel Greiner
E-ISSN: 2224-2678
372
Volume 22, 2023
the infrastructure manager in the KANGO-GVD
module, which determines the time positions of
trains, the station and line tracks travelled, and other
data. In the KASO modules, the traction vehicle and
carriage group circulations are also developed, and
locomotive and train crew rotations are drafted.
The KANGO modules work on a common
central database that contains a database of master
data, trains, and users. KASO modules read master
data and train data from the KANGO database via
KANGO-Vlak. They use their central database for
circulations and rotations data. The mutual
exchange of train data with the European PCS
system, [3], is handled by KANGO-Vlak.
The train data requested by the railway
undertaking and the actual data maintained by the
infrastructure manager are recorded in a pair of
trains: required and actual. The required train is
entered by the railway undertaking in the KANGO-
Vlak module as a train requirement for the
infrastructure manager. The actual train is created
by copying the required train and modified by the
infrastructure manager in KANGO-GVD (hereafter
referred to as the constructor). The constructor can
enter time, station, and line track data in the path of
the actual train within the KANGO-GVD
construction area (approximately the territory of the
Czech Republic).
The data relating to the part of the path that does
not belong to the KANGO-GVD construction area
is filled into the required train by the KANGO-Vlak
user directly or imported from the PCS.
During the process of developing the timetable,
the requested train passes through the phases
Transferred Requirement, Requirement Creation,
Ready for Construction, Construction, Constructed,
Requirement Change, Ready for Construction –
Change, Agreed by Railway Undertaking, and the
corresponding actual train through the phases
Construction, Constructed, Agreed by Railway
Undertaking. The train phases are described in more
detail in [2].
The train object contains the following data
groups:
Train header – path-independent data, e.g.
train number and name.
Train path – a sequence of transport points
and their associated data, e.g. time data,
train running calendar, and activities.
Objects in the train path that have a defined
section and validity calendar, e.g. railway
undertakings, traction vehicles, and train
parameters.
The sequence of path transport points is
hereinafter referred to as a route.
The architecture of the KANGO system did not
allow attaching information systems of other
railway undertakings. The railway undertaking
České dráhy did not have its database of trains and
master data, in which it could maintain both data
necessary for infrastructure managers and specific
data for its use.
3 New System
It was for these reasons that in 2013 a development
was initiated to split the KANGO and KASO
systems into two separate systems.
To ensure the liberalisation of the European rail
market and the interoperability of infrastructure
managers and railway undertakings, the European
Union has issued technical specifications for the
interoperability of telematic applications:
in freight transport (TAF TSI), [4], [5],
in passenger transport (TAP TSI), [6], [7].
These regulations had to be respected when
developing the new system. Therefore, a data
interface has been developed that allows
communication between the information system of
the railway undertaking and that of the
infrastructure manager using standardised TSI
messages in XML format. The basic TSI messages
that KANGO works with are as follows:
Path Request – a request for a path sent by
the railway undertaking to the infrastructure
manager.
Path Details – a constructed path sent
(provided) by the infrastructure manager to
the railway undertaking. In the KANGO
system and other information systems in the
Czech Republic, the term data timetable
(hereinafter referred to as DTT) has been
introduced for the constructed path.
The structure of the transformed KANGO and
KASO systems is shown in Figure 2. The structure
of the KASO system is shown in a simplified form
as it is not the focus of this paper.
WSEAS TRANSACTIONS on SYSTEMS
DOI: 10.37394/23202.2023.22.41
Karel Greiner
E-ISSN: 2224-2678
373
Volume 22, 2023
KANGO-Kmen Other KASO
modules
KANGO-GVD KANGO-Tras
PCS
KASO-Vlak
Information
system of other
railway
undertaking
KANGO-JRD
 
Fig. 2: Current architecture of information systems
for the development of the annual train timetable
The KANGO-Vlak module was divided into two
modules:
KANGO-Tras – manages route requests
from railway undertakings and DTTs
created by the infrastructure manager.
KASO-Vlak – used to develop the railway
undertaking's timetable.
The communication interface of the KANGO
system for the information systems of railway
undertakings is the KANGO-JRD module, which
receives TSI messages from individual railway
undertakings via web services and provides
messages to railway undertakings based on their
query. KANGO-Tras queries the KANGO-JRD
module at regular time intervals for new messages,
which it then processes. The messages intended for
railway undertakings are generated by KANGO-
Tras and sent to KANGO-JRD, which after
validation stores them in a message table from
which they are provided to the individual systems of
the railway undertakings. Interstate path data is
exchanged between KANGO-Tras and the PCS.
The KANGO-Kmen and KANGO-GVD
modules play the same role as in the original
KANGO architecture.
The Path Request and Path Details messages are
almost identical in structure, containing mainly the
following information:
Message header – contains message type,
status, and identifier, information about the
sender and recipient of the message, and
date and time of message creation. The
message status can take the values Creation,
Modification, and Deletion.
Information type – indicates the status of
the request or DTT.
Identifiers related to the request or DTT.
The sequence of path transport points and
the data relating to them. Only significant
transport points can be included in the
request, the complete route is given in the
DTT, i.e. there must be a transport section
between two transport points in the railway
network database.
In a path request and DTT, unlike a train object,
a calendar (running days bitmap) can only be
specified at a single, reference transport point.
According to the TSI, this can be any transport point
in the path. In KANGO, only the starting point can
be a reference point. In the other transport points of
the path, only the information about the number of
days of calendar offset with respect to the reference
transport point is given. Train data (length, weight,
traction vehicles, etc.) can change at each transport
point, but cannot be defined with a custom calendar.
Exceptions are passenger timetable notes and
integrated passenger transport systems, which have
a defined section and validity calendar and are part
of the structured national message parameters. The
transport point data also includes the train number,
which is not mandatory in the request. The train
number can only change from even to the nearest
odd number in the path and vice versa. In this case,
the train number is given as a slash number, e.g.
170/1.
The following transport identifiers appear in TSI
messages:
Path Request ID (PRID) – created by the
railway undertaking, it identifies the path
request. The identifier is also included in the
DTT to determine the link between the path
request and the DTT.
Train ID (TRID) – created by the railway
undertaking, it identifies the business case
(from the perspective of the infrastructure
manager). Multiple path requests can have
the same TRID – the relationship between
TRID and PRID is 1:N. As a rule, these are
path requests related to the same train. A
TRID cannot be given in two path requests
with overlapping calendars. The TRID is
contained in the path request and is repeated
in the DTT.
Path ID (PAID) – created by the
infrastructure manager, it identifies the
DTT. According to the TSI, more than one
DTT can be provided for one path request –
the relationship between PRID and PAID
can be 1:N. In KANGO, only a 1:1
relationship is handled.
WSEAS TRANSACTIONS on SYSTEMS
DOI: 10.37394/23202.2023.22.41
Karel Greiner
E-ISSN: 2224-2678
374
Volume 22, 2023
The KANGO-Tras module works with 4 types of
trains:
Request – originates from the Path Request
message. The user can only view it.
DTT – is created from the request.
Required train – is created by KANGO-Tras
from one or more DTTs. The user can only
view it.
Actual train – is created by KANGO-GVD
from the required train. It is edited by the
user in KANGO-GVD.
The required and actual trains correspond to the
same named train types in the original KANGO
architecture.
There are two types of DTTs:
DTT with a request – is created from a
request sent via the KANGO data interface.
There is only one request for each of these
DTTs.
DTT without a request – is created by the
KANGO-Tras user without sending a
request via the KANGO data interface. A
special type of DTT without a request is a
catalogue DTT, whose requesting railway
undertaking is a railway undertaking with
the Catalogue flag. It is used for sample
DTTs offered to railway undertakings and
auxiliary DTTs created during the timetable
creation process described below.
The relationship between the required train and
the DTT is 1:N. The required train data is the union
of the attached DTT data. The DTT route is a subset
of the route of the required train. The time position
of the DTT is the same as the required train. DTT
calendars in the same section must not overlap. At
least one DTT must be attached in each section of
the required train.
An example of the relationships between these
train types is shown in Figure 3.
Request
TR 10, PR 1
Route: A B
Calendar: 1-4
DTT
PA 1
Route: A B
Calendar: 1-4
Required train
Route: A C
Calendar:
A B: 1-5
B C: 6-7
Actual train
Route: A C
Calendar:
A B: 1-5
B C: 6-7
DTT
PA 3
Route: A C
Calendar: 6-7
Request
TR 10, PR 3
Route: A C
Calendar: 6-7
Request
TR 10, PR 2
Route: A B
Calendar: 5
DTT
PA 2
Route: A B
Calendar: 5
Fig. 3: Example of relationships between train types
4 Procedure for Developing the
Annual Timetable
When a new timetable is being developed, it is
based on the previous timetable. The database
contains only DTTs without request that is in the
Transferred DTT phase.
For each message sent by the railway
undertaking, KANGO-Tras sends one of the
following messages:
Receipt Confirmation – the message from
the railway undertaking has been
successfully processed.
Error – the message from the railway
undertaking was erroneous. The message
contains the text of the error.
KANGO-Tras does not respond to any Receipt
Confirmation or Error messages sent by the railway
undertaking. These messages are not required from
the railway undertaking.
If no status is specified for the TSI messages
described below, the message has the Creation
status.
4.1 New Path Request
The processing of a new path request sent by the
railway undertaking via the KANGO data interface
is carried out as follows (see Figure 4):
1. The railway undertaking sends a Path Request
message (Harmonisation – Completed
information type) containing a new path request.
2. If the message contains errors, KANGO-Tras
does not create the request and sends an Error
message to the railway undertaking.
WSEAS TRANSACTIONS on SYSTEMS
DOI: 10.37394/23202.2023.22.41
Karel Greiner
E-ISSN: 2224-2678
375
Volume 22, 2023
Fig. 4: Processing a new path request
3. If the message is error-free, KANGO-Tras
creates a request from this message in the New
Request – Accepted phase. It fills in the missing
transport points in the requested route using the
shortest path method of Dijkstra's algorithm,
[8]. If the request does not contain a train
number, the request is assigned the smallest
available train number from the user-defined
interval. It also creates a DTT from the request
in the DTT Creation phase.
4. After creating the DTT, the program tries to
automatically attach the DTT to the required
train. One of the following trains will be used:
A new required train, if there required train
with the same number, does not exist.
The required train with the same route in the
section of the DTT route, the same train
number, and the requesting railway
undertaking, if it is linked to another non-
catalogue DTT in this section and the train
calendar does not overlap with the DTT
calendar in this section.
The required train with the same route in the
section of the DTT route and the same train
number, if it is linked to the catalogue DTT
of this section.
The required train with the same train
number and the requesting railway
undertaking, whose route can be extended
by a section of the DTT route.
In the DTT section in which the required train is
attached to the catalogue DTT, the catalogue
DTT is replaced by the attached DTT. If the
DTT is to be attached to an existing train that is
in the Ready for Construction or Ready for
Construction – Change phase, the request, and
the DTT shall not be created, and the message is
only processed when the train reaches the next
phase – construction.
5. If the DTT does not automatically attach to the
required train, it must be attached by the
KANGO-Tras user. The user can choose one of
the following commands:
Create – A new required train is created
with data taken from the DTT.
Use – the user selects an existing required
train.
6. When the DTT is attached to the required train,
either automatically or manually, the new
required train enters the Requirement Creation
phase, the existing required train remains in the
Requirement Creation phase or, if it has already
been previously passed to construction in
KANGO-GVD, it is transferred to the
Requirement Change phase.
7. DTTs in the DTT Creation phase can be
modified by the KANGO-Tras user according to
his/her rights. If the DTT is attached to the
required train after editing the DTT the data
corresponding to the required train is
automatically updated.
8. If the DTT is attached to the required train and
contains the requested data, the user can pass it
to the construction in KANGO-GVD by
transferring it to the DTT Construction phase. If
the DTT has been automatically attached to the
requested train (on receipt of the Path Request
message), it is automatically transferred to this
phase. Most of the data in the DTT cannot be
modified in this phase. If neither DTT attached
to the required train is in the DTT Creation or
DTT Change phase (see below), the required
train is transferred out of the phase:
Requirement Creation to the Ready for
Construction phase – if it has not already
been submitted for construction,
WSEAS TRANSACTIONS on SYSTEMS
DOI: 10.37394/23202.2023.22.41
Karel Greiner
E-ISSN: 2224-2678
376
Volume 22, 2023
Requirement Change to the Ready for
Construction – Change phase – if it has
already been submitted for construction.
9. KANGO-GVD automatically creates a new
actual train for the required train in the Ready
for Construction phase, copying all data from
the required train into it. If the required train is
in the Ready for Construction – Change phase,
it imports the data that cannot be edited in
KANGO-GVD from the required train into the
existing actual train. It then takes the required
and the actual train to the Construction phase.
10. After the construction of the actual train is
completed in KANGO-GVD, the actual train is
transferred from the Construction phase to the
Constructed phase.
11. KANGO-Tras detects train phase changes at
regular time intervals. Once the actual train has
reached the Constructed phase, KANGO-Tras
imports the data that can be edited in KANGO-
GVD from the actual train to the corresponding
required train and its associated DTTs. It
transfers the required train to the Constructed
phase and the DTT from the DTT Construction
phase to the Draft DTT – Constructed phase.
Most of the data in the DTT cannot be modified
in this phase. If the KANGO-GVD user later
transfers the actual train back to the
Construction phase, KANGO-Tras
automatically transfers the required train back to
the Construction phase and the attached DTTs
back to the DTT Construction phase.
12. The KANGO-Tras user can transfer the DTT
from the DTT Construction or Draft DTT –
Constructed phase back to the DTT Creation
phase to modify it. The related required train is
transferred from the Construction or
Constructed phase to the Requirement Change
phase or remains in the Requirement Creation
phase. Step 8 follows to transfer the DTT back
to construction.
13. The infrastructure manager provides the railway
undertaking with the DTT draft by moving the
DTT from the Draft DTT – Constructed phase
to the Draft DTT – Published phase. The
transfer of a DTT to this phase can only be done
by a KANGO-Tras user with the Important
Phases right. The railway undertaking is sent a
Path Details message (Draft Offer information
type). At this stage, most of the data cannot be
edited in DTT and the response of the railway
undertaking is awaited. The KANGO-GVD user
can still transfer the related train to the
Construction phase in this phase, but the DTT
phase does not change. Once the related train is
back in the Constructed phase, the DTT is
updated without changing the phase, and the
Path Details message (Draft Offer information
type) is sent again to the railway undertaking.
The possibility to provide a new draft DTT
without the railway undertaking's response is
not in accordance with the TSI but was
requested by the users.
14. The railway undertaking may send one of the
following messages in response to the draft
DTT:
Path Confirmed (Observation – Complete
information type) – the railway undertaking
accepts the draft DTT, the message does not
contain a text of comments.
Path Details Refused (Observation –
Complete information type) – the railway
undertaking rejects/refuses or has
commented on the draft DTT, the message
contains the text of the comments.
15. In the case of Path Confirmed message
processing, KANGO-Tras sets the information
in the DTT about the approval of the draft DTT
and transfers it to the Final DTT – Constructed
phase. This is followed by Steps 21 or 22.
16. In the case of Path Details Refused message
processing, KANGO-Tras sets the information
in the DTT about the disapproval of the draft
DTT with the text of the comment and transfers
it to the DTT Change phase. It transfers the
related required train to the Requirement
Change phase. If the required train is in the
Ready for Construction – Change phase, the
message is only processed when the train
reaches the next phase – construction.
17. The DTT in the DTT Change phase can be
modified by the KANGO-Tras user according to
his/her rights. If the DTT is attached to the
required train, after it is modified the data of the
attached required train is updated automatically.
18. In exceptional cases, the KANGO-Tras user can
transfer the DTT from the Draft DTT –
Published phase to the next phase (DTT
Change, Final DTT – Constructed, DTT Pre-
booked) by him/herself without any response
from the railway undertaking. This operation
can only be performed by a user with the
Important Phases right. If later a Path
Confirmed or Path Details Refused message is
received, the DTT sets the information about the
acceptance or refusal of the draft DTT with any
comment text, but the DTT phase does not
change.
19. If the DTT in the DTT Change phase is attached
to the required train and contains the requested
WSEAS TRANSACTIONS on SYSTEMS
DOI: 10.37394/23202.2023.22.41
Karel Greiner
E-ISSN: 2224-2678
377
Volume 22, 2023
data, the user can pass it to the construction by
transferring it to the DTT Construction –
Change phase. In this phase, most of the data in
the DTT cannot be modified. If neither the DTT
attached to the required train is in the DTT
Creation or DTT Change phase, the required
train is transferred to the Ready for Construction
or Ready for Construction – Change phase and
then to the Construction and Constructed phase
as described in Steps 9 and 10.
20. Once the actual train reaches the Constructed
phase, KANGO-Tras automatically imports the
data that can be edited in KANGO-GVD from
the actual train to the corresponding required
train and attached DTTs. It transfers the
required train to the Constructed phase and the
DTTs from the DTT Construction – Change
phase to the Final DTT – Constructed phase.
Most of the data in the DTT cannot be modified
in this phase. If the KANGO-GVD user later
transfers the actual train back to the
Construction phase, KANGO-Tras
automatically transfers the required train back to
the Construction phase and the DTT back to the
DTT Construction – Change phase.
21. The KANGO-Tras user can transfer the DTT
from the DTT Construction – Change or Final
DTT – Constructed phase back to the DTT
Change phase to modify it. The related required
train is transferred from the Construction or
Constructed phase to the Requirement Change
phase or remains in the Requirement Change
phase. Step 19 follows to transfer the DTT back
to construction.
22. The infrastructure manager provides the railway
undertaking with the Final DTT by transferring
the DTT from the Final DTT – Constructed
phase to the Final DTT – Published phase. The
transfer of the DTT to this phase can only be
done by a KANGO-Tras user with the
Important Phases right. The railway
undertaking is sent a Path Details message
(Final Offer information type). In this phase,
most of the data in the DTT cannot be edited
and awaits the railway undertaking's response.
The KANGO-GVD user can also transfer the
related train to the Construction phase in this
phase, but the DTT phase is not changed. When
the related train is transferred back to the
Constructed phase, the DTT is updated without
changing the phase and the Path Details
message (Final Offer information type) is sent
again to the railway undertaking. The possibility
to provide a new final DTT without the railway
undertaking's response is not in accordance with
the TSI but was requested by the users.
23. The railway undertaking may send one of the
following messages in response to the final
DTT:
Path Confirmed (Final Offer – Accepted
information type) – the railway undertaking
accepts the final DTT, the message does not
include a text of comments.
Path Details Refused (information type not
specified in the message) – the railway
undertaking does not accept the final DTT,
the message contains the text of the
comment.
24. If the Path Confirmed message is processed,
KANGO-Tras sets the information in the DTT
about the approval of the final DTT and
transfers the DTT to the DTT Pre-booked phase.
25. If the Path Details Refused message is
processed, KANGO-Tras sets the information
about the rejection of the final DTT in the DTT
with the comment text and performs the DTT
deletion operation (see below).
26. In exceptional cases, the KANGO-Tras user can
transfer the DTT from the Final DTT –
Published phase to the next phase (DTT Pre-
booked) by him/herself without any response
from the railway undertaking. This operation
can only be performed by a user with the
Important Phases right. If later a Path
Confirmed or Path Details Refused message is
received, the DTT sets the final DTT acceptance
or rejection information with any comment text,
but the DTT phase is not changed.
27. Once the DTT reaches the DTT Pre-booked
phase, the railway undertaking is sent a Path
Details message (Final Offer – Accepted
information type). In this phase, most of the
data in the DTT cannot be modified. The
KANGO-GVD user can also transfer the related
Path to the Construction phase in this phase, but
the DTT phase does not change. Once the
related train is back in the Constructed phase,
the DTT is updated without changing the phase,
and the Path Details message (Final Offer –
Accepted information type) is sent again to the
railway undertaking.
28. In exceptional cases, the KANGO-Tras user can
transfer the DTT from the DTT Pre-booked
phase back to the Final DTT – Published phase
to allow the railway undertaking to modify or
cancel the request. The Path Details message
(Final Offer information type) is sent again to
the railway undertaking and the information
about the acceptance or refusal of the final DTT
WSEAS TRANSACTIONS on SYSTEMS
DOI: 10.37394/23202.2023.22.41
Karel Greiner
E-ISSN: 2224-2678
378
Volume 22, 2023
is deleted in the DTT. This operation can only
be performed by a user with the Important
Phases right.
29. On the date of allocation of the railway
capacity, the KANGO-Tras user transfers the
DTT from the DTT Pre-booked phase to the
DTT Booked phase. The DTT can be transferred
to this phase if the related required train is in the
Constructed phase and the other DTTs attached
to this train are also in the DTT Pre-booked
phase. The related required and actual train is
transferred to the Booked phase. Only a user
with the Important Phases right can transfer the
DTT to this phase. A Path Details message is
sent to the railway undertaking (Booked
information type). Most of the data of the DTT
cannot be edited in the DTT Booked phase. The
actual train in the Booked phase cannot be
edited in KANGO-GVD.
The DTT Pre-booked phase is not mentioned in
the TSI. It has been introduced to allow modifying
the train in KANGO-GVD even in this phase, to
update the DTT with railway undertaking data not
needed at the time of construction in KANGO-
GVD, or possibly to return the DTT to the previous
phase to allow the railway undertaking to modify
the request.
If the infrastructure manager processes a request
that the railway undertaking has not sent via the
KANGO data interface, it creates the DTT without
request in the DTT Creation phase or transfers it
from the Transferred DTT phase. The procedure is
then the same as for a DTT with a request, except
that no messages are sent to the railway
undertaking. The railway undertaking's response to
the draft and final DTT is entered into the DTT by
the KANGO-Tras user.
4.2 Modifying the Path Request
When modifying a path request sent by a railway
undertaking via the KANGO data interface is as
follows (see Figure 5):
Path Request
(S: M, TI: HC)
New Request 
Accepted
DTT Creation to
Final DTT 
Published
DTT Creation Requirement
Creation/Change
Request
Change -
Accepted
Construction/
Constructed
Fig. 5: Path request modification process
1. The railway undertaking may make a
modification to its request if the DTT is in the
DTT Creation to the Final DTT – Published
phase. The railway undertaking sends a Path
Request message (Modification status,
Harmonisation – Completed information type).
2. If the message contains errors or the request
cannot be modified (the DTT is in an
unauthorized phase), KANGO-Tras does not
process the modification of the request and
sends an Error message to the railway
undertaking.
3. If the message is error-free and the request can
be modified, KANGO-Tras creates a request
from the message that overwrites the original
request. The request enters the Request Change
– Accepted phase. The DTT attached to this
request enters the DTT Creation phase. If the
DTT is attached to the required train, this train
is transferred to the Requirement Change phase
or remains in the Requirement Creation phase.
All data from the request, including the route, is
transferred to the DTT. Next, the data of the
required train is updated according to the DTT.
However, if a change to the required train would
cause modification of another non-catalogue
DTT attached to this train, the DTT shall be
detached from the train. If the related required
train is in the Ready for Construction or Ready
for Construction – Change phase, the message
is only processed when the train reaches the
next phase – construction.
4. The procedure is then the same as for a DTT
created from a new path request, except that the
DTT is automatically transferred from the DTT
Creation phase to the DTT Construction phase
if all the following conditions are met:
The DTT was not originally in the DTT
Creation phase.
The DTT is attached to the required train.
There is no other DTT with request and the
same train number as the modified DTT that
is not attached to the required train and is in
a different phase than the DTT Deleted or
DTT Cancelled.
If, after the DTT has been detached from the
train, there is a section of the train that is not
attached to any DTT, the detached DTT shall be
replaced by the catalogue DTT in that section. The
new catalogue DTT will enter the DTT Creation
phase.
4.3 Cancelling the Path Request
The procedure for cancelling a request by the
railway undertaking via the KANGO data interface
is as follows (see Figure 6):
WSEAS TRANSACTIONS on SYSTEMS
DOI: 10.37394/23202.2023.22.41
Karel Greiner
E-ISSN: 2224-2678
379
Volume 22, 2023
Fig. 6: Path request cancellation process
1. The railway undertaking may cancel the request
if the DTT is in the DTT Creation to Final DTT
– Published phase. The railway undertaking
sends a Path Request message (Deletion status,
Harmonisation – Completed information type).
2. If the message contains errors or the request
cannot be cancelled (the DTT is in an
unauthorised phase), KANGO-Tras does not
process the cancellation and sends an Error
message to the railway undertaking.
3. If the message is error-free and the request can
be cancelled, KANGO-Tras transfers the
request to the Request Cancelled phase. The
DTT attached to this request is transferred to the
DTT Cancelled phase and detached from the
required train. If the related required train is in
the Ready for Construction or Ready for
Construction – Change phase, the message is
only processed when the train reaches the next
phase – construction.
If, after the DTT has been detached from the
train, there is a section of the train that is not bound
to any DTT, the detached DTT is replaced by a
catalogue DTT in this section. The new catalogue
DTT enters the DTT Creation phase.
A DTT in the DTT Cancelled phase can only be
deleted by a user of the administrator type. In this
case, the DTT is irreversibly deleted from the
database together with the request.
4.4 Deleting the DTT
The infrastructure manager may later discover that
the DTT cannot be allocated after receiving a new
path request or modifying it and deleting the DTT.
The procedure for deleting a DTT is as follows (see
Figure 7):
Path Details
(TI: NAA)
New Request/
Request
Change 
Accepted
DTT Creation to
Final DTT 
Published
DTT Deleted
Request
Deleted
Construction/
Constructed/
Requirement
Creation/Change
Fig. 7: DTT deletion process
1. The KANGO-Tras user can delete the DTT if it
is in the DTT Creation to Final DTT –
Published phase. After entering the text of the
reason for deletion, the DTT is transferred to the
DTT Deleted phase and detached from the
required train. The corresponding request is
transferred to the Request Deleted phase.
2. The railway undertaking is sent a Path Details
message (No Alternative Available information
type) containing the reason for the deletion.
If, after the DTT has been detached from the
train, there is an internal section in the train that is
not attached to any DTT, the detached DTT is
replaced by the catalogue DTT in this section. The
new catalogue DTT will enter the DTT Creation
phase. If there is no start or end section of the train
attached to the DTT, the train shall be shortened by
this section.
4.5 Non-construction Data
Data that is not needed at the time of construction in
KANGO-GVD is sent by the railway undertaking
via the KANGO data interface in Path Request
and/or Object Info messages. These are passenger
timetable notes, integrated passenger transport
systems, lines, etc.
The infrastructure manager sends this data in the
Path Details message. In those messages, this data
is contained in structured national parameters.
The Object Info message can be used by the
railway undertaking to update the data in the DTT,
which can be in the DTT Creation to DTT Pre-
booked phase. After receiving the message,
KANGO-Tras modifies these data in the DTT and
the related train.
5 Conclusion
Since the end of 2010, the annual timetable in the
Czech Republic has been developed using the
KANGO system on the side of Správa železnic, an
infrastructure manager, and KASO on the side of
České dráhy, a railway undertaking, which had a
common KANGO-Vlak module for ordering train
paths. The architecture of the KANGO system did
not allow attaching the information systems of other
railway undertakings, which had to request train
paths through the infrastructure manager's staff.
Moreover, the railway undertaking České dráhy did
not have its database of trains and master data in
which it could maintain its specific data for its own
use.
WSEAS TRANSACTIONS on SYSTEMS
DOI: 10.37394/23202.2023.22.41
Karel Greiner
E-ISSN: 2224-2678
380
Volume 22, 2023
Therefore, in 2013, the development was started
to separate the KANGO and KASO systems and to
create a web services-based data interface for the
railway operator, with which the information
systems of railway undertakings can communicate
using XML messages. These messages correspond
to the TAF/TAP TSI of the European Union with
minor national differences. The railway
undertaking's information system sends messages
and queries the messages provided by the
infrastructure manager. The basic messages are the
Path Request sent by the railway undertaking and
the Path Details (constructed path – DTT) sent by
the infrastructure manager.
A new KANGO-Tras module was developed to
replace the KANGO-Vlak module. KANGO-Tras
handles the processing of messages from railway
undertakings, the creation of messages for railway
undertakings, and the management of path requests,
DTTs, and required trains that arise from one or
more DTTs by merging their data. The required
trains are the basis for the construction of the actual
trains in KANGO-GVD, from which time data and
other data entered by the constructors into the DTT
are fed back.
For the development of the annual timetable,
processes were designed for processing a new path
request, modifying and cancelling the path request
by the railway undertaking, deleting the DTT by the
infrastructure manager, and processing non-
construction data that are not needed at the time of
construction in KANGO-GVD.
The new KANGO system was deployed into
routine operation at the beginning of 2020 and the
2019/2020 timetable was successfully developed in
it. The KASO systems of the railway undertakings
České dráhy and ARRIVA and information systems
of other railway undertakings communicate via the
KANGO data interface.
The Czech Republic is currently the only
European country in which an information system
for developing train timetables that meets the TSI
EU specifications is in routine operation. In other
European countries, the implementation of the TSI
is in the development phase.
References:
[1] H. Bachratý, K. Šotek, "The concept aimed to
railway timetable design innovation",
Koncepce směřující k inovaci tvorby jízdního
řádu v železniční dopravě (in Czech). In Proc.
INFOTRANS 2009, Pardubice: University of
Pardubice, 2009, pp. 117–126. ISBN 978-80-
7395-171-9.
[2] K. Greiner, J. Volek, Information system of
railway undertakings' train track requirements.
In Proc. International Conference on Applied
Computer Science, Malta: WSEAS Press, 2010,
pp. 254–258. ISSN 1792-4863, ISBN 978-960-
474-225-7.
[3] Path Coordination System – RNE [online],
2023 [cit. 2023-03-22]. Available from:
<http://pcs.rne.eu/>.
[4] Commission Regulation (EC) No 1305/2014 on
the technical specification for interoperability
relating to the telematics applications for
freight subsystem of the rail system in the
European Union and repealing the Regulation
(EC) No 62/2006. In Official Journal of the
European Union, 2014, L356, pp. 438–488.
[5] Commission Implementing Regulation (EU)
No 2021/541 amending Regulation (EU) No
1305/2014 as regard the simplification and
improvement of data calculation and exchange
and the update of the Change Control
Management process. In Official Journal of the
European Union, 2021, L108, pp. 19–56.
[6] Commission Regulation (EU) No 454/2011 on
the technical specification for interoperability
relating to the subsystem 'telematics
applications for passenger services' of the trans-
European rail system. In Official Journal of the
European Union, 2011, L123, pp. 11–67.
[7] Commission Implementing Regulation (EU)
No 2019/775 amending Regulation (EU) No
454/2011 as regards Change Control
Management. In Official Journal of the
European Union, 2019, L139, pp. 103–107.
[8] E. W. Dijkstra, "A note on two problems in
connection with graphs". Numerische
Mathematik, no. 1, 1959, pp. 269–271.
WSEAS TRANSACTIONS on SYSTEMS
DOI: 10.37394/23202.2023.22.41
Karel Greiner
E-ISSN: 2224-2678
381
Volume 22, 2023
Contribution of Individual Authors to the
Creation of a Scientific Article (Ghostwriting
Policy)
The author proposed the presented processes of
developing train timetable and also verified their
functionality by programming the KANGO-Tras
module.
Sources of Funding for Research Presented in a
Scientific Article or Scientific Article Itself
No funding was received for conducting this study.
Conflict of Interest
The author has no conflict of interest to declare.
Creative Commons Attribution License 4.0
(Attribution 4.0 International, CC BY 4.0)
This article is published under the terms of the
Creative Commons Attribution License 4.0
https://creativecommons.org/licenses/by/4.0/deed.en
_US
WSEAS TRANSACTIONS on SYSTEMS
DOI: 10.37394/23202.2023.22.41
Karel Greiner
E-ISSN: 2224-2678
382
Volume 22, 2023