1 Introduction

Recently, Automatic Train Operations (ATO) are gaining consideration in the railway industry thanks to the possibility of realizing efficient and safe management of railway traffic. This research effort is making it possible to extend the use of ATO, already consolidated in closed railway systems (e.g., urban metros), also to infrastructures not intrinsically predisposed to high grades automation due to heterogeneous traffic and multi-operator involvement, such as the railway mainlines (Yin, et al. 2017).

ATO is a control system, both on-board and trackside, capable of autonomously managing the movement of the train, respecting the journey constraints and maximizing the efficiency of the driving procedures. The ATO is characterized by the related grade of automation (GoA). The standard IEC 62290–1 defines 5 GoAs for ATO, from 0, i.e., absence of automation, to 4, i.e., fully unmanned train control (Martinez and Martin 2020).

Nowadays, all automatic train operations run under the supervision of Automatic Train Protection (ATP) systems. The European standard ATP system on high-speed and high-capacity railway lines is the European Rail Traffic Management System / European Train Control System (ERTMS/ETCS). In its current form, ETCS supervises the speed profile and position limits, as well as the interlocking of trains on ERTMS-monitored line segments, with the ultimate goal of achieving a fluid corridor between different national train systems (Yin, et al. 2017). The joint operation of ATO and the ETCS defines the so-called ATO over ETCS framework.

However, current ETCS requirements do not support a high degree of automation for ATO. In fact, to date, integrations between ATO and ETCS are limited to the GoA 1 and GoA 2 prototypes (Yin, et al. 2017; Eschbach 2021). Furthermore, the current ETCS standard [i.e., SUBSET-026 (2016)], still considers the presence of the on-board human driver as mandatory during automatic train operations. The presence is necessary because most of the safety interventions provided by ETCS involve sending alerts to the driver through an on-board subsystem used for control and supervision. At present, ETCS intervenes autonomously in the three cases described by SUBSET-041 (2012): (i) when an emergency braking message provided by a Balise (on-track transponder) is detected; (ii) when an emergency message is received via GSM-R communication (trackside link); and (iii) when the train crosses sections of the line labeled End of Authority/Limit of Authority.

Recently, the European project X2Rail4 is pushing for the development of an ATO over ETCS framework implementing GoA 3 and GoA 4 operations (XXXX). To this aim, it is necessary to update the ETCS specifications, by introducing a novel safety submodule in the ATO over ETCS GoA 4 equipment that supervises some vital and safety–critical functions not covered by the current ERTMS/ETCS infrastructure. For instance, some useful operations, not covered by ETCS, include the movements of an unmanned railway vehicle during maintenance or diagnostics missions, shunting or in-depot operations and the remote recovery of trains forced to a standstill position on the line due to signalling system malfunctions. In addition, since a low percentage of routes are equipped with ERTMS/ETCS (e.g., only 3400 km out of 16,800 in Italy), an ATP system capable of supervising the ATO is also needed on the national signalling system.

To take a step toward the fully automated unattended train operation, we propose a pioneering implementation of a compact ATP submodule, called Vital Control Module (VCM). This module serves as an on-board vital control core, carrying out the following functions:

  • Assessing the overall on-board ATO equipment operativity in real-time;

  • Providing safety supervision during remote operations of train recovery and diagnostic missions;

  • Ensuring safety supervision of automatic train operations on infrastructures without ERTMS/ETCS system;

  • Extending the scenarios for automatic emergency braking due to the absence of on-board staff;

  • Operating without interfering with pre-existing ETCS and on-board equipment.

The VCM has been designed and developed as hardware/software architecture, to be integrated into an unmanned railway vehicle within the ATO over ETCS GoA4 framework.

The VCM has been designed to fulfill railway-related and safety–critical standards, both for the hardware and software aspects. Concerning the hardware side, the reference standards in the railway field are EN50155 (2022) and EN50124 (2020a; 2020b) for rolling stock equipment. While for software certifications, the standard is EN50128 (2020) for railway control and protection applications.

The VCM hardware has been implemented as a dedicated PCB, while the VCM software has been designed and implemented using a dedicated, reliable, and safe hard real-time operating system (RTOS). The VCM application logic has been conceptualized, developed, and verified as a Finite State Machine (FSM) using the Simulink/Stateflow tool and a model-based approach. Subsequently, the application logic has been exported for implementation on the target system (i.e., Ultrazed EG System on Module by Avnet). The target implementation was carried out by exporting the FSM as scheduled RTOS tasks.

This paper focuses on the characterization of the VCM application logic by analyzing the Worst-Case Execution Time (WCET) and Worst-Case Response Time (WCRT) of involved tasks. The analysis is carried out on timed execution traces acquired via a commercial tracing tool. Moreover, a testbed for the hardware-in-the-loop (HIL) has been also implemented to reproduce some real-life scenarios to evaluate the VCM intervention timing.

The paper is organized as follows: Sect. 2 provides an overview of the overall framework of ATO over ETCS GoA4. Sect. 2.4 outlines the here proposed architecture, deepening the used RTOS and the application logic. Sect. 4 presents WCET and WCRT analysis for the schedulability verification, discussing the experimental results. Sect. 5 concludes the paper by proposing future perspectives and achievements.

2 System overview

2.1 The VCM-empowered ATO over ETCS framework

Figure 1 schematizes the ATO over ETCS GoA 4 framework (gray/blue boxes) with the integration of the VCM architecture (red block). The current ATO over ETCS GoA 4 on-board equipment only includes the four grey/blue main blocks shown in Fig. 1: (i) the ATO computation core (ATO-OB); (ii) the ETCS system (ETCS-OB), (iii) the Supervision and Control System (SCS-OB) and (iv) the Train Interface. The Train Interface includes the ETCS control, the Emergency Brake (EB) and the traction/brake control systems.

Fig. 1
figure 1

General overview of the ATO over ETCS GoA 4 proposal with integration of the VCM architecture

Full size image

The main block of the ATO over ETCS framework (on-board side) is the ATO-OB. ATO-OB controls and drives the train, elaborating the speed profiles and braking curves, according to the train mission. For this purpose, it is provided with direct access to the traction and service brake control system. ATO-OB exploits the SCS-OB to receive possible alarms and manage the speed profile. It also interfaces the ETCS-OB that communicating with its counterpart on the trackside (ETCS-TS in Fig. 1) ensures the safety supervision of the train operations considering the overall infrastructure.

In this context, ATO-OB has its trackside counterpart, the ATO-TS, which communicates with the infrastructure and the ETCS-TS for traffic management and authorization for remote driving operations. The above-described architecture schematizes the current ATO over ETCS framework (Deutsch 2022).

To achieve a high automation degree (GoA4) of the framework, the ATP capabilities of ETCS must be improved. In this respect, Fig. 1 illustrates our new design that includes the here-proposed module, i.e., the VCM architecture block in Fig. 1. The VCM architecture improves the on-board equipment features, directly interfacing the EB and the ETCS control subsystems, and the ATO-OB.

The interface with the EB control system permits the VCM architecture to drive the solenoid valves connected to the pneumatic plates. The EB issuing consists of a power cutoff of the solenoid valves that causes a sudden depressurization of the pipes and, thus, the pneumatic plates closing. This process leads to the total locking of the traction and the immediate deceleration of the train.

The ETCS Control system consists of a driving interface for a radio relay that is used to turn ON/OFF the ETCS-OB system. VCM architecture can turn ON the ETCS-OB entrusting it with train supervision (i.e., insertion procedure). VCM architecture can also turn OFF the ETCS-OB while maintaining the safety control of the operations (i.e., isolation procedure).

The communication channel between ATO-OB and the VCM must ensure:

  • Constant monitoring of the operational status and vitality of the ATO systems (i.e., ATO-OB and ATO-TS);

  • A VCM intervention in safety-threatening situations when ETCS-OB is unable to supervise operations (ETCS isolated or faulty);

  • A bridge for communication with the trackside counterpart of ATO-OB, i.e., ATO-TS, to:

    • Verify the presence, in supervision, of a remote operator;

    • Provide the operator with the ability to formalize VCM-managed requests (i.e., emergency braking and ETCS isolation/insertion requests).

The VCM to ATO-OB connection is independent of the ETCS, then even in the presence of un-supervising ETCS (e.g., isolated or faulty), communication between the rail vehicle and the remote operator (ATO-TS) remains available via ATO-OB, ensuring safety train operations.

The VCM architecture block can be further divided into subsystems, as per the simplified architecture in Fig. 2. According to Fig. 2, the core of the VCM architecture consists of a pair of VCM boards, the VCM1 and VCM2. The boards are organized in a 2-out-of-2 (2oo2) architecture based on a voting approach and communicate between them through the Inter Processor Communication (IPC) protocol (Markovits and Rácz 2021; Fara, et al. 2021).

Fig. 2
figure 2

Simplified architecture of VCM block

Full size image

The VCM hardware is the PCB proposed in our previous work (Mezzina et al. 2022) and that is shown in the green box at the bottom of Fig. 2. Briefly, the VCM board consists of 10-layer PCB carrier cards holding a central computing core based on the Ultrazed EG- SoM by Avnet. The VCM hardware includes several communication buses typical of the railway context (e.g., digital I/O, CAN, Ethernet, SPI, and so on), to favor the module inclusion in already existing on-board equipment.

The VCM boards interface the odometry system (ATO-ODO in Fig. 2), the Balise Transmission Module (BTM in Fig. 2), the DataLog board, and the watchdog one (WD in Fig. 2).

The ATO-ODO board periodically sends data from tachometric sensors to VCM. Starting from these data, VCM can estimate the train speed and position via a dedicated algorithm.

The BTM board is equipped with an antenna that is used to read the telegram from the Balises distributed on the tracks. Next, the BTM transfers the telegram to the VCM. The latter takes care of decoding the telegram and encapsulating it for secure retransmission to ATO-OB.

The datalog board has the purpose of saving navigation data, operating as a black box. VCM exploits this link for saving all generated notifications.

Finally, the WD system is used to supervise the functional integrity status of VCM. If VCM fails to respond within a preset interval, the WD intervenes by turning off the power supplies. This procedure results in emergency braking as explained above.

2.2 VCM general specifications

As stated above, VCM interfaces on-board equipment to monitor their working and intervenes in safety-threatening situations to ensure a proper ATP in a context of the ATO GoA 4. The following numbered list summarizes some of the general specifications of the VCM, focusing, for the sake of clarity, on those that are most significant and impact safety and the functional validation phase:

  1. S 1.

    VCM queries, with a fixed period, ATO-OB by sending a request message. Query message consists of six sections: {ATO Vitality, Operator Vigilance, EB Release Confirmation, ETCS Insertion Confirmation, ETCS Isolation Confirmation, EB Rearm Confirmation}.

    1. S1.1.

      ATO Vitality allows the system to cyclically check the computing and communication capabilities of the ATO subsystems.

    2. S1.2.

      Operator Vigilance permits the assessment of the remote operator vigilance (i.e., the active presence of the operator in the trackside control room).

    3. S.1.3.

      EB Release Confirmation gives the possibility of remotely activating the emergency braking system (i.e., ATO-TS via ATO-OB).

    4. S1.4.

      ETCS Insertion/Isolation Confirmation allows the remote operator (i.e., ATO-TS via ATO-OB) to exploit VCM for powering off/on the ETCS according to the specific mission.

    5. S1.5.

      EB Rearm Confirmation queries the remote operator (i.e., ATO-TS via ATO-OB) about the possibility of enabling procedures for safe recovery operations.

  2. S 2.

    The VCM to ATO-OB message structure is fixed and consists of two fields per section: (i) sequence number, (ii) request flag. Whenever the request flag changes from 0 to 1, the sequence number associated with it increments. Request flags are set by different pre-conditions managed by the VCM application logic (see Sec. 3.2).

  3. S 3.

    The ATO-OB system responds to the VCM queries by processing the requests, incrementing the sequence number associated with the request, and providing a response to each enabled section.

  4. S 4.

    ATO-OB must transmit with each response to VCM its operational status. VCM must supervise the ATO-OB operational status. If the status is FAIL, VCM must intervene in issuing the EB.

  5. S 5.

    VCM analyzes the response received from ATO-OB to assess its validity. A message is defined valid if the sequence numbers involved in the verification have been correctly incremented by ATO-OB.

  6. S 6.

    VCM receives data from tachometer sensors on the ATO-ODO board. VCM processes the acquisitions by extracting the speed and position of the railway vehicle.

    1. S 6.1.

      VCM must supervise the train speed with un-supervising ETCS-OB (isolated or faulty). If the train speed overcomes a pre-set limit (i.e., 30 km/h in this application), VCM must intervene in issuing the EB.

    2. S 6.2.

      VCM can detect a failure of odometer sensors on ATO-ODO. In this case, the VCM system will label ATO-ODO as not efficient. Otherwise, ATO-ODO is defined as efficient

  7. S 7.

    VCM controls a radio relay that is used to turn ON (insert) or OFF (isolate) the power supply of the ETCS-OB subsystem.

  8. S 8.

    VCM controls the solenoid valves used to activate emergency braking by acting on the pneumatic plates. The control of the VCM can be also used to pressurize the pipes to rearm the EB system. The rearming procedure is used to make traction available after emergency braking.

  9. S 9.

    VCM issues the EB (i.e., emergency braking) according to the pre-conditions and conditions summarized in Table 1.

  10. S 10.

    VCM set the System Decay flag according to scenarios summarized in Table 1. The system decay condition leads to the inability to recover the train safely. Therefore, the train remains in a safe state (stopped train) until the on-board subsystems are restarted.

Table 1 VCM Intervention scenarios
Full size table

In this context, MW consists of applications embedding device drivers, which are encapsulated by using a message-oriented approach. The application logic do not directly call device driver functions and have no access to the hardware. Instead, a static configuration file is used to define channels between railway logic and specific applications, each of which can only access the memory addresses where a single device is mapped. Interfacing with the hardware is therefore implemented with a message-passing model, and defects in a device driver are confined to the single application that is designated to use it.

In the 2oo2 architecture described in Sect. 2.1, MW also provides configurable communication channels, which implement replica synchronization, communication and voting over SPI. As shown in Fig. 3, MW applications (i.e., device drivers) are statically distributed (at the time of configuration) on the four available cores of the hardware target (CPU 0…3 in Fig. 3).

Fig. 3
figure 3

Inner Architecture of the VCM software stack with focus on application logic tasks

Full size image

The here proposed application logic has been organized into three different FSMs, which have been exported as dedicated tasks named A, B, and C. These tasks execute on a single core (i.e., CPU 3 in Fig. 3) with different periods and priorities. The tasks are organized into dedicated applications, ensuring that they do not utilize shared resources. Instead, they employ non-blocking Inter-Process Communications (IPCs) to exchange information. This approach is necessary to prevent blocking situations associated with managing multiple accesses to shared memory, thereby ensuring the functional continuity of the application logic.

Application logic tasks have been designed to handle queues of empty messages, intervening safely only if the functionality of the overall system is undermined.

In terms of the role of each individual application logic task, Task A is designed to dynamically query other on-board subsystems (e.g., ATO-OB, WD). At the predefined communication time, Task A assesses the status of the FSMs composing the application logic by analyzing the dedicated status flags. Based on these parameters, the message to be sent will include (or not) certain requests to the connected on-board devices.

Task B checks ATO-OB responses, on-board equipment working and elaborates the speed and position estimations from odometer sensor data; Task C manages procedures to control ETCS-OB and EB systems.

2.3 The real-time operating system

The EN-50128 European standard for railway applications (CENELEC 2020) specifies procedures and technical requirements for the design and development of software and electronic systems used in railways. These critical applications have specific requirements, such as fine timing management mechanisms and fault isolation properties (Donnarumma et al. 2019). Those features can be addressed by employing, and properly designing, a RTOS kernel. Specifically, timing constraints respect must be strictly supported by the system (CENELEC 2020), thus, the RTOS kernel must provide specific mechanisms for handling tasks with explicit timing constraints. Additionally, in safety–critical applications, proper interaction between software and hardware is essential for the correct functioning of the system. In this respect, a correct and robust management of the faults can be realized by providing a proper level of isolation among kernel components. A good partitioning procedure can ensure that a failure in a component does not propagate to others.

Given the importance of EN-50128 safety requirements in the railway domain, careful consideration must be given to selecting a suitable RTOS. The RTOS used for VCM is based on architectural design principles outlined in Donnarumma et al. (2019) and has been specifically designed to adhere to the EN-50128 European standard for railway applications (CENELEC 2020).

Specifically, the RTOS is based on a micro-kernel architecture with fixed priority (Lehoczky 1990) partitioned scheduling, i.e., each task is statically associated to a processor core at configuration time. Temporal isolation is guaranteed using the sporadic-server algorithm (Sprunt et al. 1989), and deadlock avoidance is obtained using the stack resource policy (Baker 1990), i.e., delaying the execution of the task until all the needed resources to be accessed are available. Spatial isolation and fault containment are guaranteed using a micro-kernel architecture, memory virtualization and a programming model based on the concept of applications and tasks.

Concerning the programming model, tasks scheduled by the RTOS are organized into specific applications, by using a static configuration file. Tasks belonging to the same application can cooperate using shared-memory, while tasks from different applications are restricted from accessing each other's memory and instead rely on the kernel's message-passing interface. This approach ensures that faults occurring in a task can only affect other tasks within the same application, thereby containing the impact of the fault.

This programming model is guaranteed by memory virtualization. It is implemented using Memory Management Unit (MMU) hardware and is guaranteed even when using drivers that make use of Direct Memory Access (DMA) hardware by leveraging the Input–Output Memory Management Unit (IOMMU) provided by modern architectures.

2.4 The application logic

The here-presented application logic has been designed through a model-based approach. Specifically, the application logic tasks are designed to operate as FSMs and implemented via MATLAB® 2022b/Simulink Stateflow toolkit (2022).

The VCM model was initially created as a single block integrating the functions identified by the preliminary technical specifications. Subsequently, the overall model has been divided into three smaller blocks to minimize the finite state machines computational load reducing the VCM intervention time in hazardous situation. In addition, the coding standards for railway applications also played a key role in this reduction because it sets limitations in terms of lines of code, input and cyclomatic complexity. The resulting model consisted of three tasks, i.e., A, B and C.

The model has been assessed via the Simulink Model Advisor toolkit to be fully compliant with MISRA C: 2012 (2012) and EN50128 (2020) standards.

Then, the C scripts implementing the three tasks have been extracted via the Embedded Coder application (2022) provided by Simulink. These scripts have been validated for MISRA C: 2012 and EN50128 compliance via Simulink Code Advisor.

The three C-language tasks, that were extracted and validated, have been integrated into the hard RTOS introduced in Sect. 3.1 as three separate applications. The applications, along with the characteristics of the three tasks, were defined during the static pre-configuration of the RTOS using a dedicated XML file.

Specifically, the pre-configuration file involves the definition of the core responsible for task execution, tasks’ priority and the timing parameters defined in Table 5, permission level (used to distinguish an application-type task from a driver-type task) and communication queues to the MW.

Task A is responsible, inter alia, for the composition and the periodic sending of a request message to ATO-OB (see Sect. 2.2). The message includes the six request sections described at S 1.1–S 1.6 of Sect. 2.2, the estimated speed and position of the train, the header of the detected BTM telegram. The message also includes a set of notifications to aware ATO-OB of different events and scenarios.

As specified by the general requirement S 2 (Sect. 2.2), the request section structure consists of two fields: (i) the sequence number and (ii) the request flag.

To trigger the transmission of a specific request field, the related flag should be set (by other tasks) within the Task A deadline. Each request flag set will cause the relative sequence number to increase. The specific requests that compose the message are triggered for transmission by considering the timelines/conditions summarized in Table 2.

Table 2 VCM message to ATO-OB trigger conditions for sending requests
Full size table

The design of Task A and its real-time parameters were mainly based on technical specifications related to the interconnections between the VCM and the ATO-OB module. It is important to note that the ATO-OB module is a hardware/software architecture developed by third parties, and as a result, detailed information about its application logic is not available. The most significant specification that influenced the task's design was the communication protocol between the modules, which defined the precise time interval for message exchange between the VCM and ATO-OB.

According to this technical specification, the exact time span that must elapse between two consecutive VCM-to/from-ATO-OB messages is 40 ms (+ 4 ms of transmission delay tolerance). If no message is received or sent within this specified limit, the communication channel is marked as non-functional, triggering an emergency situation. The design constraint is reported in Table 2 under the ATO Vitality section.

The communication between VCM and ATO-OB is based on Ethernet through the encapsulation of the Lightweight TCP/IP stack by the MW.

Task B manages the interface with several on board subsystems, inter alia, the ATO-OB, the odometry board (i.e., ATO-ODO), the EB and the ETCS control systems.

In this respect, Task B receives messages from ATO-OB via Ethernet and monitors the EB and ETCS systems, by checking their power signals via dedicated digital inputs. The digital inputs from the EB system return the availability of the braking system by reading the status of the solenoid valves, while the digital signals from the ETCS system come from the radio relay used to isolate/insert the ETCS system.

In Table 3 summarizes the most representative functions of Task B, including the involved external subsystem, a brief description and the trigger requirements of the functions.

Table 3 Task B main functions compendium
Full size table

Based on the data extracted from the computational functions in Table 3, Task B is responsible for generating an emergency braking flag that will be sent by the non-blocking IPC mechanism to Task C.

Emergency braking flag is set by Task B according to the following conditions:

  1. 1.

    Emergency braking requested by the remote operator via ATO-OB. It represents Scenario A in Table 1.

  2. 2.

    ATO-OB operating status: FAIL (from function ATO-OB operating status check). It represents Scenario B in Table 1.

  3. 3.

    ATO-OB response sections NOT valid (from function ATO-OB response validity check). They represent Scenarios C-E in Table 1.

  4. 4.

    ATO-OB response section concerning ATO-OB vitality and Operator Vigilance not confirmed within preset timeouts (from function ATO-OB response timeout check).

  5. 5.

    ETCS-OB isolated AND ATO-ODO not efficient (from function ATO-ODO efficiency detection). It represents Scenario M in Table 1.

  6. 6.

    ETCS-OB isolated (from function Radio Relay monitoring) AND train speed > 30 km/h (from function Speed and position estimation). It represents Scenario L.

Task B also sets the System Decay flag in cases 2, 3, and 4 of the above-reported list.

Finally, Task B shares with Tasks C, via non-blocking IPCs, the: (i) emergency braking flag (ii) standstill position flag; (iii) ATO-ODO efficiency status; (iv) System Decay flag; (v) EB system status and (vi) ETCS system status.

Task C is in charge of performing the control routines of ETCS-OB (i.e., isolation and insertion procedures) and EB system (i.e., emergency braking and EB rearming).

In Table 4 summarizes the most representative functions of Task C, with a supporting brief description of them and trigger requirements.

Table 4 Task C main functions compendium
Full size table

2.5 Tasks parameters

The tasks composing the applications logic have been realized to be periodic on a single core with specific deadlines (Di) and periods of scheduling (Ti).

The three tasks are released simultaneously at the end of the initialization phase and therefore with the same phase (φ). The phase parameter is added to a fixed configuration time offset, which includes the time required by the RTOS (and the MW) to initialize and test all peripheral devices. For simplicity, we will consider φ as t = 0 in the following.

The scheduling periods and deadlines were firstly derived from the technical requirements of the proposed systems and, specifically, from the ATO—VCM communication protocol specifications (as summarized in Sect. 2.2).

The starting design constraint concerned the data exchange between ATO OB and VCM. As mentioned earlier, the interval between consecutive VCM to/from ATO-OB messages is set to 40 ms (+ 4 ms to account for transmission delay). This time interval serves several purposes: (i) ensuring the proper receipt of VCM's request message, (ii) verifying the message to ensure expected ATO-OB processing, (iii) composing the response message, and (iv) transmitting it back to VCM.

Based on the above conditions and in accordance with the trigger rules for requests sending (as outlined in Table 2), this constraint determines the period of Task A. Setting a period of 40 ms for Task A allows for convenient generation of all requests as multiples of the task period, while maintaining a hard deadline of 2 ms.

To configure Task B, the relevant functions summarized in Table 3 were considered. Task B is responsible for various tasks, including controlling the safety operations of the VCM, processing odometry data from ATO-ODO, supervising the on-board equipment, and verifying the responses received from the ATO-OB. Upon receiving the ATO-OB message, the FSM realizing the Task B requires 16 task execution cycles (worst case scenario—longest functional path) to complete all the verification states. Additionally, an extra execution cycle is needed to prepare the FSM, upon which Task B relies, for receiving and processing new messages from the ATO-OB.

To avoid functional interference between Task B and Task A (e.g., new message from the ATO-OB to be analyzed before completion of the evaluation of the previous one) and considering the technical requirements of the ATO-OB system, the period of Task B was defined at a ratio of 1:20 to the period of Task A. Furthermore, Task B may receive delayed ATO-OB messages. To ensure that Task B functionality check can be completed within the required 17 execution cycles and to prevent interruptions from Task A, Task B has been assigned a higher priority than Task A.

Task C is responsible for activating the emergency brake system (EB) control and ETCS-OB isolation and insertion procedures. Task C also deals with handling the activation of specific requests from Task A. Since the commands to be transmitted to the solenoid valves come from Task B checks, as well as the re-reading of ETCS-OB and EB systems status following the command, Task C was designed to operate “sequentially” to Task B.

This sequencing condition is necessary because Task C relies on the output of Task B in a non-blocking mode. Task C needs to be able to act independently and promptly when emergency braking is required. Task C closely follows Task B to ensure timely action in case Task B activates the braking flag during its checks.

Moreover, for the proper verification of command actuation (radio relay and solenoid valves status re-reading), the period and the deadline of Task C must be the same as that of Task B, i.e., 2 ms. Since the activation of some requests by Task A depends on the handling of Task C, to minimize the generation time of specific requests, Task C must have a higher priority than Task A, but lower than Task B.

In Table 5 summarizes the main timing parameters of the three tasks, configured via the dedicated tool of the RTOS: the relative hard deadlines (Di) equal to the period Ti, and the task priorities (Pi).

Table 5 Application Logic Tasks Parameters
Full size table

The WCET and the WCRT analyses reported in Sect. 4.1 and 4.2, respectively, show that the selected value for the deadline (i.e., 2 ms) is largely sufficient to execute the described tasks. Nevertheless, since the specifications of the vital control module are constantly evolving, it was preferred to keep the timing more relaxed to allocate new task functionality, without prejudicing the specifications concerning the communication intervals.

3 Experimental results

3.1 Worst-case execution time extraction

In safety–critical real-time applications, the deadlines are imposed by the knowledge of the application domain of the system. These constraints typically concern the communication times between platforms, or the physical phenomena with which the system must interact (e.g., EB braking times for check).

Sect. 3.3 analyzed the functional deadline extraction for the specific real-time application. This section analyzes the longest observed execution time of each task composing the application logic of VCM, to permit the verification of schedulability of the proposed application logic. For the sake of simplicity, in the following we will refer to the longest observed execution time as a safe approximation of the WCET.

In this context, it should be specified that WCET estimation is hard to be evaluated because it requires a detailed knowledge of the paths that could be taken in the code, especially when complex conditions are used and bounds on loop execution counts are not known (Gustafsson and Ermedahl 2007).

To obtain sufficiently accurate estimates of the tasks’ WCETs, an analysis was performed based on 36 scenarios described in the system specifications. These scenarios were designed and identified during the definition phase of the validation plan for the VCM system, aiming to cover all the functional paths outlined by the application logic. The scenarios, identified as part of requirements-based testing, allowed for verifying 100% functional coverage of the system, as confirmed by tests conducted using the dedicated toolkit Simulink Coverage (Coverage and for MATLAB® 2022b, Simulink. 2022b).

In general, these scenarios are representative of the paths that are executed both in the normal system operation and in presence of safety-threatening situations triggering the VCM intervention (see Sect. 3.2).

The WCET has been determined by analyzing timed execution traces of the tasks. These traces were collected using the commercial tracing tool Lauterbach PowerTrace, which was connected to the Trace Port Interface Unit via the Mictor 38 connector on the VCM board. The test patterns, extracted by the Simulink Test Harness (Mezzina et al. 2022), were injected into the system to capture the execution behavior.

Figure 4 shows a histogram representation of the gathered tasks execution times in terms of occurrence distribution. From the histograms it is possible to infer that Task A assumes a WCET of 20 μs in 5 cases out of 58,212 executions. Task B presents 2 executions out of 1.164.240 in which the WCET stands at 24 μs. Task C has 2/1.164.240 executions that return a WCET of 31 μs.

Fig. 4
figure 4

Worst Case Execution Time Extraction. Histogram representation of WCET occurrence distribution for Task A, B and C. Y-axes of histograms are in log scale to emphasize the low number of WCET

Full size image

Since we do not have access to the kernel source and, thus, we are unable to make assumptions on the execution paths of other tasks or interrupt routines executing on the same core, we extracted the worst-case execution time between two subsequent application logic tasks across 2.328.480 executions by comparing the delays between the end of a task and the beginning of the next-to-be-executed already released task. This time span will be defined \({\Delta }_{Ker\&MW}\) in the following. A single execution of \({\Delta }_{Ker\&MW}\) out of 2.328.480 returned a WCET of 36 μs, while, on average, \({\Delta }_{Ker\&MW}\) execution required 11.24 μs ± 3.31 μs (with a minimum of 8 μs). It should be specified that \({\Delta }_{Ker\&MW}\) includes operating system context switching, MW tasks execution time, among others related to IPC message passing, with a higher priority than Task A and C.

Table 6 summarizes the WCET for the three tasks involved in the application logic and the \({\Delta }_{Ker\&MW}\).

Table 6 WCET, WCRT and timing parameters of Application Logic Tasks
Full size table

3.2 Schedulability verification

Starting from the WCETs extracted for Task A, B, C and the \({\Delta }_{Ker\&MW}\) as described in Sect. 4.2, it is possible to estimate the WCRT for all tasks.

Considering that all the tasks are released at the beginning of the period (with the same phase as indicated in Table 5) and taking into account that Task A is scheduled with a period that is a multiple of Tasks B and C, we will evaluate the Worst Case Response Time (WCRT) as the time interval from the task's release to its completion.

Figure 5 illustrates the WCRT based on the collected experimental data. Figure 5 shows that at every k*Task A period (k*40 ms with k = 1, 2, …), the three tasks realizing the application logic are released simultaneously with the same phase. Following their assigned priorities, the tasks are executed in the order of B, C and A, with a time gap of \({\Delta }_{Ker\&MW}\) between each task. After a time interval equal to the period of Task B (i.e., 2 ms), only Task B and C are executed. This pattern repeats 20 times before Task A is scheduled again.

Fig. 5
figure 5

Demonstrative representation of WCRT considering the experimentally extracted WCETs

Full size image

Table 6 reports the WCET and the WCRT per each analyzed task, considering that there is no pre-emption among tasks. Table 6 also reports the lateness parameter defined as the difference between the finishing time (the time at which the task finishes its execution) and the task deadline.

It is important to note that, while all computations needed for the functionality of the proposed system are executed in Tasks A, B, and C, there is still the need for an additional communication task that receives data to be processed and sends results to a host PC.

In the practice, however, the effects of this task on the analysis are negligible as: (i) it is scheduled on a separate CPU core, (ii) does not share critical sections with the computation tasks (A, B, and C), and (iii) the only communication with the computation tasks happen via non-blocking IPCs. In fact, if for some reason no data is available on one iteration, the additional task will simply be skipped, and an error counter will be updated to keep track of a possible anomalous working condition.

4 Use case

4.1 HIL testbed

To test VCM in the real-life scenarios introduced in Table 1, the VCM board has been included in a dedicated testbed for HIL. The here-proposed HIL testbed includes different modules that emulate the behavior of the ATO-OB (and ATO-TS), ATO-ODO, and Train Interface (ETCS, EB relays). Figure 6a shows a snapshot of the experimental testbench.

Fig. 6
figure 6

HIL Testbed for VCM a Testbench implementation; b Architecture representation

Full size image

According to Fig. 6, the VCM is connected to a backplane via SPI, CAN, digital I/O (DI/O) and Gigabit Ethernet. The backplane is used to distribute signals to the target emulators. Specifically, the Gigabit Ethernet realizes the connection between VCM and a Host PC emulating the ATO subsystem (ATO-OB and ATO-TS). SPI and CAN interfaces are connected to a MiniZed by Avnet. The MiniZed is used to emulate the BTM, and the odometer board (ATO-ODO) functions, i.e., sending Balise Telegram and tachometer sensors data, respectively to VCM. The VCM interfaces, through DI/O an ESP-based board (the red one), which embeds two relays. These relays are used to emulate the reaction time of EB (solenoid valves) and ETCS (radio relay) systems.

This EB/ETCS board is connected to the MiniZed to manage the consequences of braking operations that lead to a reduction of specific parameters generated by the dedicated odometer function (tachometric sensors data evolving to follow the braking curve).

To properly reproduce the 36 scenarios for the functional coverage, and specifically, the most representative scenarios selected in Table 1 for the VCM intervention timing assessment, the test defined via Test Harness in MATLAB® 2022b/Simulink are handled by a Python script on the host PC. The Host PC acts as ATO-OB by communicating with VCM and synchronizes (via USB connection) the operations of the MiniZed.

The testbench includes the connection between VCM and the commercial tracing tool Lauterbach PowerTrace through the Trace Port Interface. Similar to the WCET assessment, the extraction of VCM intervention timing also utilizes traced data. However, in this case, a runtime assessment of specific flags is performed in response to test patterns injected by the Hardware-in-the-Loop (HIL) testbench.

4.2 VCM intervention timing

To provide a complete overview of the vital control capabilities provided by the VCM architecture, a timing assessment of the scenarios presented in Sect. 2.2 will be analyzed in this paragraph.

Before proceeding, it should be noted that according to the SUBSET—041 by UNISIG (2012), which defines the ERTMS/ETCS performance requirements for interoperability, the ETCS system is required to intervene by issuing the emergency brake within a time limit of 1 s (most stringent requirement) or higher, when specific hazardous situations are detected. This stringent requirement for the ETCS system (i.e., intervention time of 1 s) constitutes the upper limit for the VCM intervention timing requirements.

In addition, the intervention time should also include the time required to depressurize the pipe and initiate braking action. In this respect, a standard pneumatic plates system for emergency braking depressurizes the pipe at a maximum of 450 ms.

Consequently, the VCM application logic has 550 ms (at maximum) to command and verify the braking. The proposed architecture must intervene in a period shorter than this limit to be compliant with the specifications provided by the related subset.

Figure 7 shows the architecture intervention times in the analyzed scenarios, highlighting three kinds of mitigation actions: EB intervention (blue bars), System Decay with the train already in a standstill position that does not require an EB intervention (orange bars), and EB intervention with System Decay status (green bars).

Fig. 7
figure 7

VCM Intervention Timing versus hazardous scenarios

Full size image

Results show that the longest intervention time of the VCM belongs to Scenario E and consists of 12 ms (worst case). Scenario E considers the detection of a NOT VALID answer, concerning the vigilance of the remotely connected operator. Another scenario that requires a long intervention time (i.e., 10 ms) is the EB activation, due to the explicit request of the remote operator (i.e., Scenario A). The scenarios with the fastest EB intervention time (i.e., 2 ms) are the detection of the failure mode of ATO (Scenario B) and the expiration of the ATO vitality and operator vigilance timeouts (Scenario N). Concerning the System Decay notification (with no EB activation), the fastest reactions (i.e., 2 ms) are provided by the failure in the application of the EB rearm signal (Scenario G) or the ETCS Isolation/Insertion commands (Scenario F).

The timing of Scenarios L and M (red star) depends on the speed and position estimation elaborated by VCM by the periodic reception of tachometric data coming from ATO-ODO. The inter-transmission interval for odometer data is 80 ms.

Considering the analysis above and results in Fig. 7, we can infer that, in the worst case, the proposed architecture can issue an emergency braking in 536 ms. This intervention time is derived by the cumulative sum of 450 ms to depressurize the pipe, 80 ms of inter-transmission interval for odometer sensors data and the 6 ms required by VCM to analyze and elaborate data from ATO- ODO (Scenarios L and M in Fig. 7).

In the worst analyzed case, the intervention time is still below the expected specification [i.e., 1 s as per SUBSET-041(2012)] of ~ 464 ms.

5 Conclusions

New research trends in the railway field are pushing toward control of the train infrastructure increasingly automated. Current solutions exploit supervision control systems based on existing automatic train protection modules, such as the ERTMS/ETCS. However, to create ATO frameworks able to work with GoA3/4, additional train protection functionalities should be provided. To bridge this gap, a pioneer VCM architecture capable of expanding the automatic train protection capabilities of ETCS in a highly automated context has been proposed.

The proposed VCM consists of a hardware/software architecture that includes a PCB on which runs a reliable and safe hard RTOS, integrating an application logic for the vital control operations. The application logic layer, developed as a model with Simulink/Stateflow tool and implemented as a C-script on the Xilinx Ultrascale + core, has been tested through different dedicated testbeds.

In this paper, we have presented the first study to characterize the system WCET and WCRT. The characterization has been carried out by analyzing timed execution traces provided by the Lauterbach PowerTrace tool included in the HIL testbench.

Experimental results have shown that the WCETs reached by the tasks on the various analyzed scenarios, lead to a WCRT 13.6 times smaller than the deadline (i.e., 2 ms). In the context of constantly evolving specifications for AoE GoA4, this earliness (~ − 1.8 ms of lateness) would allow the inclusion of new vital controls, broadening the VCM perspectives of use.

Finally, a HIL testbed to evaluate the VCM intervention timing in response to real-life scenarios has been realized. Considering the worst analyzed scenario, experimental results showed that the proposed architecture can issue the emergency brakes in 536 ms solving hazardous situations, resulting to be 1.87 times faster than the current ATP system, i.e. ETCS.

In light of the above-reported experimental results, the use of the pioneering VCM module has multiple advantages. A breakthrough point is the possibility of using the VCM as an ATP system on track sections not served by the ERTMS/ETCS infrastructure. Another important advantage lies in the possible use of this system for the remote recovery of trains stopped on tracks due to ETCS system failures. Moreover, the proposed compact solution strongly reduces the impact on the pre-existing cabin equipment permitting a rapid integration of the VCM.