Abstract
To increase operational efficiency, resilience and capacity of the railway system, the development of modern railway traffic management system (TMS) has attracted more and more attention in recent years. To support the development and implementation of the next generation of TMS and related applications, advanced data collection, transmission and processing approaches, digitalised databases, and virtual validation platforms, etc., are required. In the context of the TMS development (addressed by Technology Demonstrator 2.9 of Shift2Rail Innovation Programme 2), this support is to be provided by a scalable, interoperable and standardised communication platform for internal and external communication between different subsystems, applications and clients. This paper outlines the approach of the ongoing OPTIMA project aimed to develop a communication platform demonstrator for railway TMS based on a novel Integration Layer (IL) and its various interfaces to entities including integration layer services, TMS service, rail business service, external services and operator workstations. Further detailed discussion in this paper relates to the approach to validating the communication platform demonstrator as a functional entity, and as a virtual testing environment to validate railway traffic management and other applications. The validation approach for the applications tested on the communication platform demonstrator is also presented. The results of future implementation of this validation approach will be used to assess the functionality of the communications platform demonstrator developed, and the initial TMS applications tested on it, and form an important step towards developing and implementing IL based communications platforms for future TMSs.
Introduction
The Traffic Management System (TMS) is a key component in railway transport for providing control across the network, automatically setting routes for trains, monitoring train movements, detecting and resolving potential conflicts, etc. for daily railway operation. All major railway infrastructure managers across European countries are moving towards using automatic TMS for the purpose of energy management, maintenance management, advanced signalling, etc., and the TM-related applications that are used in the operator’s workstation which assist the dispatchers to make relevant decisions. Improving the TMS has the potential to improve the capacity, sustainability, resilience, safety and security of the railway system. One of the possible ways to achieve this is to digitalise the railway systems and increase the range of data sources and quantity of data available to the TMS applications through a standardised and sustainable communication platform for real-time communication across the network, including additional interfaces for more traffic management (TM) applications and sufficient bandwidth for data exchange. This would enable the development of autonomous TM applications capable of optimised decision making based on a large range of disparate data sources, which offer a significantly higher quantity and range of data than a human operator could consider. Recent traffic management applications with different objectives or priorities have been reviewed by Corman et al. 1 , 2 TM problems are usually formulated by different mathematical models and solved with various advanced algorithms. Past research includes various TMS for freight rail, 3 passenger rail,4–6 urban rail transit system 7 , 8 whose objectives are mainly improving the efficiency of multiple aspects of railway operations directly associated with the TMS, and intelligent maintenance system covering the maintenance of railway track, 9 railway asset, 10 entire railway infrastructure, 11 etc., which also minimise the cost of operating the railway and ensure stable daily services.
However, most of the TM applications mentioned above were developed at simulation level and very few of them were implemented in practice. One reason for this is that railway infrastructure managers are wary of the risks of implementing systems whose impacts on traffic are uncertain. Another reason is the variable national rules and TM systems across the EU regions that were progressively developed by different infrastructure managers in different countries, which might require separate development and verification for each implementation. The development of a common standardised communication interface for TMS across the EU, and a standard testing and verification process would enable interoperable TM applications to be developed and tested, to ensure their effectiveness and improve the efficiency of implementation. 12 Furthermore, railway TMSs in different countries/regions are not usually fully interconnected to enable them to exploit the potential opportunities to maximise operational efficiency. For example, the diversity and incompatibility of railway signalling systems across EU countries posed a significant challenge to competitiveness of international railway operations until the European Railway Traffic Management System (ERTMS) was developed and has started to be implemented. It provides a standardised interface framework, including data format, communication protocols, etc., which enables uninterrupted movement of intercountry trains across the whole EU network. However, although standardisation for train operation was partially achieved by the introduction of ERTMS, other TMS related functions such as energy management, maintenance management, passenger information exchange, etc., which form a huge amount of daily data exchange related to TMS, and other relevant data services are still not interconnected.
The development, implementation, and standardisation of railway TM applications across EU area was first addressed by European FP7 funded project ON-TIME 13 in 2011. The project contributed to the application framework for real-time algorithms for conflict detection and resolution, 14 , 15 automatic route setting 16 and a driver advisory system, 17 and embedded the developed TM applications into the control of railway traffic through web-based Service-Oriented Architecture (SOA) which enables the TM applications communicate with each other in a standardised data format (i.e., railML 18 ). The key research outputs of ON-TIME project were a novel XML formalisation to present real-time traffic status of railway network, real-time traffic plan and train path envelope 19 for their on-service railway traffic monitoring and control system. Following this, the key research on railway traffic management systems were mainly covered by Innovation Programme 2 (IP2) of Shift2Rail Joint Undertaking which focuses on control, command and communication systems for EU railway system. X2Rail-1 project 20 and its complementary projects were launched in 2015 to extend existing communication system to enable next generation of rail automation systems, 21 which includes Automatic Train Operation (ATO) with Grade of Automation (GoA) level 2 to level 4 and minor specifications for the Moving Block approach to train separation. The X2Rail-2 project 22 investigated future signalling and automation systems for European railways with four key technologies including fail-safe train positioning (based on satellite technology), 23 improving on-board train integrity, 24 formal methods and standardisation for smart signalling systems 25 and new subsystems for railway TMS. The X2Rail-2 project also produced System Requirement Specifications (SRS) for the integration layer, 26 application framework, 27 standardised operators workstation 28 and Web-Interfaces 29 of the next generation TMS, which form part of the establishing requirements of the OPTIMA (cOmmunication Platform for TraffIc ManAgement demonstrator) project. With the best of authors’ knowledge, the development and implementation of advanced TMS applications on an actual national railway network is still at the case studies and simulation, or on pilot test stages, and has only achieved full implementation on isolated sections of railway network; and there are no known solutions that enable multiple TM applications to interact in the management of a large-scale railway network, which makes the OPTIMA project a pioneer in research on railway TM.
The OPTIMA project aims to support the development and validation of innovative TMS modules within its complementary projects X2RAIL-4 and FINE2. The demonstrator developed by OPTIMA will provide a communication platform for next-generation railway TMS and TMS supporting applications, which will enable multiple desired features to be implemented though standardised data communication between TMS and several internal and external services, interoperability between different service providers, new interfaces for additional rail business and information service and the provision of a virtual testing environment. Within the specific scope of the project, the virtual testing environment of the communications platform demonstrator will be used to support the validation of technologies developed by its complementary projects within Shift2Rail Joint Undertaking, and potentially be further used as a part of the Shift2Rail Innovation Program 2 Technical Demonstrator 2.9 “Traffic Management System” demonstrator, and as a reference and validation environment for developers of various technologies for TMS implementation. This paper presents: The concept of OPTIMA project: a communication platform for next generation of railway TMS, which enables the implementation of different TM modules. The structure and functionalities of the OPTIMA communication platform and its key components including Integration Layer (IL), Application Framework (AF), Databases (DBs), Common Data Model (CDM), Operator Workstations (OW), External services and Railway Business Services. The validation process for OPTIMA communication platform demonstrator, from design and setup to execution and evaluation of the validation tests. The approach to validate the novel TM modules within virtual environment provided by the OPTIMA communication platform.
The validation approaches referred to in points 3 and 4 above will be implemented in future work within the OPTIMA project.
Concept and structure of OPTIMA communication platform
The objective of the OPTIMA project is to develop a new communication platform for railway services, which harmonises traffic management, traffic control, asset management, maintenance operations, energy (grid) control systems, signalling field infrastructure and vehicles for signalling purpose (ETCS). The communication platform will also provide an interface (Web Interfaces) for external clients’ information such as Weather Information, Passenger Information, and Freight logistics Information. The aim is to support the development and testing (and potentially future implementation) of novel advanced TMS solutions and associated applications, which will enable the realisation of optimised automated decision making in railway traffic management systems. The OPTIMA communication platform will perform as a middleware which ‘glues’ all the functional blocks together to provide seamless and standardised communication. An overview of OPTIMA communication platform is shown in Figure 1. The key components within the OPTIMA communication platform demonstrator include databases for the persistence layer (containing the data used), a CDM used by all components and the standardised Operator Workstations to be installed in Control Centres. The features of each of the key components are described below:
Structure and key components for OPTIMA communication platform.
This paper focuses on the development of the testing and validation strategy of the OPTIMA communication platform itself, and TM related applications within the virtual environment created by the communication platform.
Approach to validation of the communication platform and novel TM modules
Within the scope of the OPTIMA project, the testing and validation process aims to validate the whole OPTIMA communication platform demonstrator, considering the requirements established from the functional requirements, pre-existing standards, interoperability requirements, as well as conventions for the TMS modules, external services and DBs and any additional requirements deemed as necessary.
Following the development of the OPTIMA communication platform demonstrator, it will be necessary to validate the basic functionality of the IL as a middleware to connect all the TM related entities together and enable seamless data exchange and the platform as a whole, as well as validate the platform against the requirements defined for it. One of the key functions for the platform to be validated is its operation as a virtual testing environment for the testing and validation of the novel TM modules from other Shift2Rail projects, which will themselves be validated through testing in the virtual environment provided by OPTIMA communication platform demonstrator.
The general process to be adopted as the OPTIMA approach for validating the OPTIMA communications platform demonstrator and the TM applications to be tested within it is as follows:
Phase 1. Requirement analysis: requirements of OPTIMA communication platform are analysed to determine the key functionalities, the evaluation parameters and, the key performance indicators (KPIs) to be assessed and satisfied, respectively. The considered requirements include general requirements for OPTIMA communication platform along with specific requirements for its key components and for interconnections and interactions with external systems. The requirements for the OPTIMA communication platform demonstrator were generated based on outputs of previous complementary Shift2Rail projects (X2RAIL-4 and IN2RAIL, which specify general requirements for IL-based TMS communications platforms, in line with the Shift2Rail development strategy), Technical Specifications of Interoperability (TSI) on operation and TMS, technical specification for ETCS baselines, and public railway standards on TMS and communication. More details are discussed in ‘Requirement analysis’ section.
Phase 2. Validation planning: is the phase in which the testing activities to be executed are identified, along with their detailed scopes, objectives, and expected results. The prioritisation of these testing activities should be carefully considered to ensure that the test results contain the necessary data to evaluate the system against the performance and validation criteria. The prioritisation should also ensure that all the features and functionalities of the system required in operation are fully tested, and that any faults, errors or non-compliance with the requirements are identified. For OPTIMA project, a general sequence of validation will start from the communication platform demonstrator, and then validate the novel TM modules output by other Shift2Rail projects, which will also validate the platforms functionality as a test environment for TM modules.
Phase 3. Validation setup: create, provide and configure all essential data, interfaces, connections, power-supply, software, hardware, etc. to support the test to be executed. Details of this step are discussed in ‘Validation setup’ section.
Phase 4. Test scenario generation: the test scenarios shall be generated with respect to the requirements, KPIs, considered conditions, expected results of each scenario, and finally result in workflows of the scenarios and associated test codes. Details of this step are discussed in ‘Test scenario generation’ section.
Phase 5. Test execution: execute the tests with respect to the planning document. Test logs are to be saved for every testing scenario, recording the KPI-related measurements and the parameters of the scenario.
Phase 6. Test output evaluation: based on results of each test, the system is evaluated against the KPIs and requirements. If the requirements for the system or component/module under test are not satisfied, revisions to the items under test, further iterations of testing and analysis might be required. Details for Phase 5 and 6 are shown in ‘Test execution and evaluation of results’ section.
Phase 7. Validation closure: completion of all the tests and a full validation report.
Requirement analysis
The validation consists of two parts, i.e., the validation of communication platform demonstrator, and novel TM modules. The considered requirements mainly include the requirements for IL and the requirements for TM modules. In this section, examples of the requirements are presented and the KPIs are generated based on these requirements.
Requirements for IL
The key functionality of the IL is to provide continuous data exchange, so the main requirements for the communication functions of the IL are listed below (based on the general requirements for an IL for this purpose, as defined in the X2Rail-2 project 26 ).
Req. 1 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 the publish-subscribe pattern.
Req. 2 The IL communications infrastructure shall be kept under configuration control. Specific to IL implementation, the IL-API (Application Programming Interfaces) manages access control to the topics by configuration. (Configuration control)
Req. 3 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. (Message queuing)
Req. 4 The IL shall be available 24hours a day, 7 days a week (24*7).
Req. 5 It shall be possible for the order of message delivery by the IL to be configured as either based on order the message is received (e.g., normal First-in-First-Out (FIFO) queue), or the priority assigned to the topic of the message.
Req. 6 IL should make possible that delivery order can depend on a scheduler algorithm. Example: FIFO, Last-in-Last-out (LIFO), Round Robin.
Requirements for interfaces
To enable uniform data exchange between all the components and the IL, all the interfaces shall be developed with respect to the designed CDM (structures, attributes, unions, etc.). 31 Typical requirements for the interfaces and KPIs are shown below:
Req. 7 The serialisation method of low-level APIs should allow the representation of at least the following basic data types: Variable length string, 8 bits signed integer, 32 bits signed integer, 128 UUID, Boolean, Simple (32 bits) and double (64 bits) precision floating point (IEEE 754). The following basic types, unsigned integer 8 bits, 32 bits and 64 bits can be used in the CDM to indicate that the negative values are not authorised, but the most significant bit (MSB) can never be set.
Req. 8 The communication platform should allow applications and modules to create and delete individual Key/Value Pair in the data grid. Type (class in CDM) must be specified when a Key/Value Pair is created.
Req. 9 For each of the following language, C, C++, Java, C#, if a module of AF or IL is using the CDM-Mapping-API, then the implementation must be generated (using a code generator) from the XML file defining the CDM.
Req. 10 For each of the following languages, C, C++, Java, C#, the representation of structures, enumeration, attributes of structures and their presence, sequences, unions, basics data types and reference to other Key/Value Pairs should be the same (but it can be different for two different languages) for all implementation of the communication platform.
Requirements for TM modules
Since more than one TM modules are to be tested, the requirements for TM modules may be different due to their diverse objectives. As a result, the KPIs for TM modules should be specifically designed with respect to their own requirements and objectives, in this section, only the general requirements for the TM modules are discussed.
In general, a TM module used to make the platform functional for testing of the platform, or a TM module under test, shall be embedded into the AF within the OPTIMA communication platform, however, it might also be hosted externally and interfaced with the platform. The real-time status of railway traffic will be monitored by the TM module, via data transferred through the IL, at the required frequency and analysed with its own processing algorithms. If any hazard, conflict, disturbance, disruption, etc. is detected by the TM module within its traffic management area, the TM module should provide its solution to the considered problem within a specified time period. The scope of a TM module is mainly classified with respect to a specific time scale (i.e. a time period in the future)
32
as follows: Time scale 1, for the rail operations up to 45 mins in the future, where the objective is usually to minimising delays of trains. Time scale 2, for the rail operations between 10-15 min and 2-3 hours in the future, where the objective is usually to minimise passenger waiting times at stations. Time scale 3, for the rail operations covering at least 2 hours in the future, the objective of which is usually the recovery of the planned railway service as much as possible.
Validation setup
The main purpose of validation setup is to ensure all the essential preconditions for every test scenario are ready. For the validation of the communication platform demonstrator and the novel TM modules, the validation setup should ensure. All the components within the communication platform. The interfaces between the IL and other components are available and configured. All the physical connections between IL and other components, as well as their connections to power supply are ready.
For the second stage of the validation process, the validation of novel TM modules, the preconditions are the same as the first stage. Moreover, in the second stage the communication platform shall provide a virtual environment for the tested TM modules; as a result, the communication platform should provide essential information regarding the railway” network including railway infrastructure, rolling stock, scheduling, etc. which is saved in DBs. However, not all these data are available and digitalised, there are mainly two challenges: (1) some data are documented by infrastructure managers with paper files, PDF documents and screenshot, they are not able to transfer into digital version automatically; (2) some data are not available and require substitution with representative mock data. For the available data, they are transcribed manually and saved into DBs. For the data which is not available, data representative of the missing data is generated for the purpose of the validation testing. The infrastructure data for validation includes energy components, station and track components, route components, operational control point, signal position, signalling and control components and their ETCS levels, vehicle type, train timetables, etc. That the representative or mock data used as a substitute for missing data might not be absolutely accurate compared to the section of infrastructure considered for the test scenarios is not a significant issue in the context of the OPTIMA, as the performance of the systems will be assessed based on the response to the data present in the DB. Provided the data is representative enough of the test scenario that there is no conflicts with other data sources, that is sufficient. The entire process for infrastructure digitalisation is shown in Figure 2.
Flow chart for railway infrastructure digitization.
Furthermore, the test scenario will be implemented by inputting the scenarios parameters, live, pre-recorded as-live and mock data from the test route represented in the testing environment, and other sources, which representing normal operations and specific test cases (i.e., artificial hazard, conflict, disturbance, disruption, etc. in railway operation) for the communication platform demonstrator and TM module under test to respond to. The solution generated by target TM module will be transmitted to operator’s workstation for the authorisation of human dispatchers, and the process and outputs will be recorded in a log file for analysis. This sort of setup is for tests with the full platform including a TM module, the setup for other tests might be simpler, for example testing of IL communication might focus only on the communication process where the content of the data is not significant, only the handling of it.
Test scenario generation
A test scenario describes the detailed parameters, inputs and steps for a validation test, for which a requirement or requirements against one or more KPIs are defined. For some of the test scenarios for validation of the communication platform demonstrator, there are already sophisticated approaches for the design of the test scenarios. The approach to the design of tests relating to MTBF for the communication process of the IL is presented further, as an example.
Typical testing approach for the Mean Time Between Failure (MTBF) is Quantitative Accelerated Life Test (QALT). The QALT is a process which tests a product by subjecting it to a specific condition in excess of its normal service parameters in an effort to uncover faults and potential modes of failure in a short amount of time.
33
In the context of OPTIMA communication platform, the availability is expected to be 24*7 which means the communication platform shall always be available to support data exchange, though it could have connection or delivery failures in practice. However, the IL should at least be able to stay within defined performance limits until the next regular maintenance, and the time period for regular maintenance is
The calculation of time between failure on normal condition and QALT.
If a neighbouring detected uptime and downtime for the communication platform are
Regarding to the validation of TM modules which are usually software-based applications, the testing on TM modules, as well as their novel functionalities, is performed using the Software-in-the-Loop (SIL) approach. A closed loop for TM modules testing can be organised with the IL and all the surrounded entities. In general, the railway status data is collected by the railway business services and published into the IL, and the data will be collected by the AF (with TM module) and operator’s workstation, and all the required data of railway infrastructure, rolling stock, timetable, etc. are loaded from DBs by the target TM module for it to process and make a decision (traffic management solution). The parameters and data (such as train movements and timetables) are embedded in the railway business services entity or external services entity to generate and feed the designed scenario to the virtual environment. The setting of the scenario parameters should reflect the specific scenario in practice, there are two ways to model the scenarios: (1) using historical data; i.e., logfile are saved daily and include incidents such as train delay, signal loss, connection break, etc. which can be used in each test scenario to mock practical disturbances in railway operation (2) generating artificial scenarios by appreciate distribution; i.e., artificial data can be used when historical data is not enough, or simulating some extreme cases which rarely happen in practice.
Test execution and evaluation of results
All the test scenarios will be executed according to the sequence specified in the planning stage. For the validation of the IL, all the data exchange in the interfaces and the data flow within the IL will be monitored and saved as a logfile. For the validation of TM modules, the test subject TM module will detect the status of the relevant aspects of the scenario, then, for example, when it detects a deviation from the timetable, or the mechanical failure of a train, it generates a solution and transmit it to operator’s workstation. In practice, the solution should be authorised by operator staff to be implemented, however, the virtual testing environment does not feedback to the real network it represents and receives data from, therefore the solution will not be implemented. The data flow within the interfaces, and generated solution will be saved in logfiles, which will be used for evaluation. If the requirements for the system or component/module under test are not satisfied, revisions to the items under test, and further iterations of testing and analysis might be required.
Conclusions
A communication platform for the next generation railway TMS that is developed by the Shift2Rail OPTIMA project is presented and discussed in this paper. The development of the communication platform enables a standardised data exchange between TMS and several services supporting TMS applications and new interfaces for additional rail business and information services. The development of OPTIMA communication platform enables standardisation and scalability of existing railway TMS and provides standardised interfaces for external railway services. The communication platform also provides a virtual environment to validate novel TM applications developed by other Shift2Rail projects.
The systematic approach for the validation of TMS through the communication platform is also discussed in this paper, including the validation of the communication platform and the novel TM modules input from other Shift2Rail projects. The whole validation process is organised as several steps, i.e., requirements analysis, validation planning and setup, test scenario generation, execution and evaluation. Detailed validation tests will be executed in future work, and OPTIMA communication platform will be delivered as part of a technical demonstrator for future railway TMS.
Footnotes
Declaration of Conflicting Interests
The author(s) declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.
Funding
The author(s) disclosed receipt of the following financial support for the research, authorship, and/or publication of this article: This research received funding from the Shift2Rail Joint Undertaking within the European Union’s Horizon 2020 research and innovation programme, under Grant Agreement No 881777.
