DIGITAL TRACK MAP FOR THE VEXA EXPERT SYSTEM

. This paper aims to summarize possible solutions of a Digital Track Map proposal, designed to become a data source for the VEXA decision-making system. The VEXA project is carried out in cooperation of the Department of Applied Mathematics at the Czech Technical University in Prague – Faculty of Transportation Sciences and the AŽD Praha s. r. o. company. The Digital Track Map is an indispensable data source describing the railway line intended for the VEXA supervised trains operation and its surroundings. Being created in the ArcGIS Pro software environment, the digital map allows individual objects to be visualized and handled as standard GIS features and described by related data stored in a geodatabase. Depending on the object class, the object location can be expressed in different ways. Not only physical location (directly expressible using GIS features) but also functional location (as the objects relate to a particular track) must be considered.


Introduction
The effort to reduce the influence of the critical human factor in the railway sector leads to the development of numerous process information systems. Such systems include, for example, automatic train control systems, automatic train operation systems, various forms of railway traffic management systems and decision-making systems. Whereas many of these systems require accurate infrastructure data, the need for thorough description of the railway infrastructure is growing. This is not different in the case of the expert system that is being developed within VEXA.
The VEXA research project is carried out in cooperation of the Department of Applied Mathematics at the Czech Technical University in Prague -Faculty of Transportation Sciences and the AŽD Praha s.r.o. control and signalling systems supplier. The VEXA expert system itself consists of several interconnected modules providing various functionalities leading to perform the tasks of an autonomous railway vehicle.
Based on the evaluation of defined inputs, it aims to substitute decision-making processes of a train driver. These inputs can be outputs from detectors (e. g. obstacle, fire) and status reporting systems (as regards the individual modules) and track condition monitoring. With the use of a knowledge base and decision rules (railway operation rules, decision algorithms taking into account the driver's behaviour), VEXA is supposed to evaluate the conditions for running a railway vehicle in order to grant a permit to start moving or to issue a request to stop the train. With the use of the VEXA system, it is expected to reach the grade automation of the level GoA3 or GoA4 (i. e. driverless or unattended train operation) [1,2].
In order to provide the VEXA system with infor-mation concerning the environment in which the train is running, the Digital Track Map is being developed. The map is supposed to describe the railway line intended for the VEXA supervised trains operation as well as its surroundings. The Digital Track Map data represent one of the important inputs for the VEXA system decision making processes. Among others, the data will be compared with detected scene in order to recognise unwanted objects.

Logical Architecture of the VEXA System
The onboard VEXA unit is supposed to consist of four following modules: The Perception Input Module is responsible for aggregating inputs from train detectors of different types. As the set of sensors may differ for individual implementations of an autonomous train, the module is being designed to be configurable.
The Map Matching Module is in charge of managing information about the known surroundings of the autonomous train. Based on the unit location information, it provides a comparison of the data obtained from the Perception Input Module with the Digital Track Map data.
The Incident Analysis Module is designed to process the data related to the objects evaluated by the Map Matching Module as potentially unwanted and additional information from detectors. The data are  analysed using a set of deterministic rules forming a nested multi-criteria expert system. On the basis of classification, it decides on the choice of reaction that is necessary to prevent or mitigate the impact of a potential incident.
Finally, the Incident Solver Module is responsible for performing the correct reaction to possible incidents that the Incident Analysis Module was unable to eliminate. The module includes relevant rules that define how to react to a given type of accident.
As regards the VEXA system surroundings, the Perception Subsystem includes various detectors providing data to the Perception Input Module. Among others, it is the Object Detector and the Detectors of Train Control Management System. The interface of other modules to various railway systems is provided by the VEXA -Train Systems Communication Hub and VEXA -Trackside Communication Hub. The Map Matching Module is also supposed to receive data from Global Navigation Satellite System and to communicates with the Digital Track Map.
The logical architecture of the VEXA system is shown in the Figure 1. At the same time, the expected data flows are shown there [1].

Recognition of Potentially Dangerous Objects
As already outlined, the purpose of the Digital Track Map is to provide the VEXA system with the data describing the infrastructure used to operate the autonomous vehicle and its intermediate surroundings.
Even though the Digital Track Map is not a part of VEXA itself, it is being developed in close collaboration with the system in order to provide it with required inputs. Whereas one of the VEXA system goals is to detect unwanted objects around the railway line and especially on the running track, the map serves as a basis for comparison against the scene recognised on the ba-sis of inputs captured by the means of onboard devices. While these inputs are supposed to be processed by the Perception Input Module of the VEXA system, the Map Matching Module is responsible to compare the map with the recognised scene.
For this reason, the map is supposed to include the location of expected objects around the railway line which are to be evaluated as harmless when being compared to the scene. The Map Matching Module evaluates whether detected objects need to be classified as potentially dangerous. This case occurs if there is no corresponding data object included in the Digital Track Map while a real object is detected by train sensors in a specific location.
The information about the potentially dangerous object is to be provided the Incident Analysis Module to decide on and carry out an appropriate reaction which affects the behaviour of the train. In the event of an irregularity being detected that cannot be solved by the Incident Analysis Module and an accident threatens to occur, the Incident Solver Module must also receive the appropriate data to take action [1].

Requirements Arising from Vehicle Localization Aspects
Considering the aspect of topological decomposition, the Digital Track Map consists of two subsystems: Digital Map Trackside and Digital Map Onboard. The Digital Map Onboard subsystem comprise the data tiles being loaded from the Digital Map Trackside part depending on the specific train path. It works in close collaboration with the Map Matching Module, responsible for further data processing. Selection of individual data tiles to be loaded is based on the knowledge of the vehicle location [1]. The vehicle location information is also necessary to be known in order to determine the distance and direction in which the individual objects recorded in the Digital Track Map are expected to be located relative to the vehicle. In order to calculate the values of these quantities, it is necessary to express the object location and the location of the vehicle in a common coordinate system. Whereas linear coordinate systems are not suitable for this purpose (as they must always be assigned to a specific line or track) and there is a need to keep constant lengths, angles, and areas for measurement, it is necessary to express location through one of projected coordinate systems. It may require the recalculation of coordinates, in some cases. A projected coordinate system is defined on a flat, two-dimensional surface and is always based on a geographic coordinate system that is based on a sphere or spheroid. In a projected coordinate system, locations are identified by x and y coordinates. In addition, the z coordinate determining the elevation value can be expressed using a vertical coordinate system [3,4].
As regard the railway vehicle, the location information is supposed to be provided by the GNSS technology. It can be also determined using an odometry system of the vehicle, e. g. using collaboration with some of automatic train control or automatic train operation systems. The odometry information is especially important in such cases for which the location determined on the basis of GNSS is not sufficiently accurate, in particular with regard to ensuring safetyrelevant functions.
The location of a train cannot be determined by the means of the GNSS technology in cases such as when the train is in a tunnel. GNSS is also not able to reliably distinguish on which track in the station or on the multi-track line the vehicle is moving. This can only be determined in combination with route setting information provided by the railway traffic management system.
For these reasons, a spatial description of the track guidance is also required to be included in the Digital Track Map. This makes it possible to convert the odometric information related to the appropriate route into x, y and z coordinates. The same applies to descriptive data directly associated to individual points or segments defined within the network expressed at the level of individual tracks.

VEXA and ATO Possible Cooperation
In the foreseeable future, VEXA should be able to receive data from the AVV system, which is the instance of ATO used in the Czech Republic. The AVV automatic train operation system was developed during the 1990s and put into revenue operation in 2000. It is a representative of the GoA2 grade of automation system, which means the semi-automated train operation. The train is driven automatically, but the driver is still in the cab, e. g. to control the absence of obstacles in the track [2,5,6]. AVV provides automatic driving for acceleration, cruise control and braking, comparing the actual speed with that requested by the driver and applying traction or braking to control the speed. In some cases, AVV is able to work in close cooperation with the ETCS automatic train control system. In such cases, these systems complement each other. AVV can also use the same train parameters as ETCS when calculating braking curves [6].
Based on the principle of interconnection between the ATO and the ATC system, standardised European solution called ATO over ETCS (AoE) is being developed. This narrow harmonised cooperation brings also new concept of infrastructure data processing. Instead of using fixed track map stored in AVV, AoE uses more flexible concept. The description of the railway network corresponds to the decomposition into so-called segment profiles to which the relevant data relate. Each running track is usually covered with several such segment profiles. The onboard ATO part receives these data dynamically from the ATO trackside subsystem. Because the VEXA system has the possibility to get some infrastructure data directly from ATO, it is not needed to include them to the Digital Track Map. The segment profiles, however, do not contain relevant spatial information which is necessary due to the need of recalculation of coordinates for the purposes of the Digital Track Map and the Map Matching Module functionalities.
In order to localize the relevant data in geographic space, it is necessary to link individual segment profiles with appropriate geographically located elements. Such a connection will make it possible to express the location of a point defined by the segment profile identifier and the depth of the segment profile penetration (absolute position from its beginning) also through geographical coordinates. This is essential both in terms of the ATO infrastructure data localization and for the purpose of expressing the railway vehicle geographical location based on the odometry information [6].

RailTopoModel and GIS Principles Application
Spatial expression of a railway transport route, which is the basis for localization of many infrastructure data description components, can take several different forms. The UIC RailTopoModel initiative aims to unify the various approaches to modeling railway infrastructure under one generic model allowing various user extensions managed in a common way.
Since the RailTopoModel has become the IRS 30100 solution in 2016, its application in various projects is gradually expanding. Among others, the railML® 3 XML-based railway data format implements the concepts of the RailTopoModel for data exchange purposes [7].
Taking into account the RailTopoModel principles, the Multipurpose Railway Infrastructure Model is being developed at the Railway Laboratory workplace at the Czech Technical University in Prague  -Faculty of Transportation Sciences. Among several other projects, the Digital Track Map represents a field for implementation and further development of this model. The Multipurpose Railway Infrastructure Model allows the user to view the recorded data in the context of individual objects or object classes, at the same time, however, it retains the form of a relational database, which allows it to be integrated into the geodatabase working under the GIS software used [8].
As the platform for creating the Digital Track Map, the ArcGIS Pro software has been chosen. The software allows to open and edit various data formats from which the most convenient for storing data for the Digital Track Map purposes is the file geodatabase format. It offers a comprehensive data repository integrating feature data sets, standalone tables and some other types of data sources. Thanks to that, individual data records are not necessarily bound to specific GIS features but they can simply be joined with them [4].
Considering the principles of the RailTopoModel recommendation, the topology of the Digital Track Map network is designed using net elements and net relations. Due to the nature of the task solved, the only possible approach is to use the micro level of detail with linear elements representing individual tracks interconnected by net relations at nodes representing switches. Each linear element must be terminated in such a node and connected to the following linear elements with the use of a net relation [9, 10].
The Digital Track Map, as it is created in the Arc-GIS Pro software, allows individual objects to be visualized and handled as standard GIS features, i. e. points, lines and areas. Therefore, the RailTopoModel linear element class can be considered as a specialization of the line feature class, in the GIS context. Individual linear elements can therefore be represented and data-described as line features of the linear element feature class.
These line features are fundamentally linestrings (sometimes also called polylines), i. e. sequences of points localized using geographical coordinates which can also have their altitude and stationing defined. In the case they represent linear elements, these points can be obtained through geodetic survey (as shown in the Figure 2) or by sampling the analytical description of the track guidance (which is shown in the Figure 3).
When a geodatabase is taken into account, there is also the possibility to use the analytic description directly to define the line features (or parts thereof). ArcGIS Pro offers the creation of arc and spiral segments in this way, even by entering their design parameters. It is necessary to consider whether such an option would be beneficial in the creation of the Digital Track Map [4].
The net elements defined in this manner are supposed to become the basis for the location of various types of objects and properties of the railway infrastructure. Among others, the aforementioned ATO segments are assumed to be mapped to them in order to provide relevant data related to respective track sections.
According to the RailTopoModel terminology, railway infrastructure objects and properties which can be localized are collectively called net entities. After all, objects that are not directly related to the transport route can be considered as net entities, as well. This Net entities can be localized basically in two different ways. Taking into account the class names defined in the Multipurpose Railway Infrastructure Model, it is possible to distinguish between physical and functional location. The physical location essentially corresponds to the localization with the use of the standard GIS features and expresses the real location of physical objects in geographical space. Such a location is therefore independent of the railway infrastructure and is not associated with any net elements. On the other hand, the functional location expresses the projection of the relevant object into associated point or segment defined within an (in our case linear) element or several (often consecutive) linear elements. This projection is typically perpendicular but in justified cases may be defined in another way to suit the functional nature of the localized object in relation to the railway transport route.
Depending on the method of functional location, we can further distinguish between spot, linear and area location. This division is based directly on the definition of the RaiTopoModel classes designed to describe the location aspects [9, 10].
As regards the Digital Track Map, taking into account available data sources, the spot location is to be used for locating such entities as signals and balises, while the linear location is supposed to be used by horizontal curves, vertical curves, segment profiles, platform edges, level crossings and possibly other types of net entities. The area location could be used, for example, to locate turnouts, if it is decided that it is beneficial for the VEXA project to record data about them. The main significance of the physical location from the point of view of the Digital Track Map project is seen for the purposes of the railway surroundings objects which have no relation to a particular track. Exclusively this type of location is supposed to be used, in such cases [1,11].

Conclusions
This article outlined possible approaches to creating the Digital Track Map for the VEXA project and introduced the basic issues which must be taken into account when defining the map feature classes. After the design of its structure is completed, the Digital Track Map is supposed to be first used on the VEXA system trial implementation on the Čížkovice -Obrnice railway line, also known as Švestková dráha. The first testing is planned for the line section between the Libčeves railway station and the Židovice railway stop. The prospective intention is to extend the technology to a wider range of railway vehicles and parts of the railway network.