Analysis of ATO System Operation Scenarios Based on UPPAAL and the Operational Design Domain

Abstract

With the gradual maturity of the automatic train operation (ATO) system in subways, its application scope has also expanded to the high-speed railway field. Considering that the ATO system is still in the early stages of operation, it will take time to fully mature, and definite specifications of the requirements for system operation have not yet been formed. This paper presents the operational design domain (ODD) of the high-speed railway ATO system and proposes a scenario analysis method based on the operational design domain to obtain the input conditions of the system requirements. The article models and verifies the scenario of the linkage control of the door and platform door based on the UPPAAL tools and extracts the input and expected output of the system requirements of the vehicle ATO system. Combined with the input conditions of the system requirements, the system requirements of the vehicle ATO in this scenario are finally obtained, which provides a reference for future functional specification generation and test case generation.

1. Introduction

At the end of 2019, the Beijing-Zhangjiakou Railway equipped with Chinese self-developed high-speed rail automatic driving system opened, marking the arrival of the era of intelligent high-speed rail. As the demand for intelligent automation in high-speed railways continues to increase, ATO systems will play an increasingly important role in train operation control. ATO system research is becoming more and more important due to the significance of high-speed railways, and related system tests are urgently needed.

The current research on the realization of the ATO function mainly focuses on the ATO control algorithm. Liu et al. [1] designed an energy-saving algorithm for the ATO system based on the tabu search algorithm. Wang et al. [2] proposed a fast optimization method that considers both braking accuracy and driving comfort during the operation of the ATO system. Yang et al. [3] designed a hybrid model prediction framework based on model predictive control, which achieved precise control under strict constraints. Kong et al. [4] proposed a non-singular fast terminal sliding mode control strategy based on self-organizing radial basis function neural network approximation to achieve safe and reliable train operation. Cao et al. [5] discussed the application of fuzzy predictive control to the ATO system and compared it with the traditional control technology. In the current ATO system research, the research on the ATO control algorithm is to find the optimal train control scheme and the key elements that affect train operation. In addition to the detailed and in-depth design of the system itself, a mature system needs to have detailed tests on the operation of the system to ensure the safety of the system.

Scenario-based analysis is an important method in ATO system research. Yan et al. [6] used STPA to conduct human error and management-related security risk analysis of the operating scenarios for the ATO system. Zhang et al. [7] took a typical temporary speed-limit server switching scheme as an example, constructed its symbolic verification program model, and generated related test cases through mutation testing. One of the key points of system testing is to systematically find all possible situations for train operation and design test cases for these situations. In order to fully obtain these scenarios, it is necessary to combine the research of the control strategy of the high-speed railway ATO system to explore the environment that the system needs to deal with and the design indicators of the system. That means that before designing system test cases, various requirements of the system, such as functional requirements, non-functional requirements, and system requirements, need to be extracted.

Some scholars have carried out relevant research on the extraction of system requirements. John et al. [8] described and analyzed the requirement development process in a scenario-based design through case studies. They used classroom scenarios to evaluate and design the requirements. Bindschadler et al. [9] described a requirement development method that is flexible enough to serve various environments and constraints through NASA’s project management process. Daniel et al. [10] proposed a method to describe requirements formally by replacing natural language with state transition diagrams. A control experiment was carried out using this method to verify its role in disambiguation. Yang et al. [11] proposed a method to extract software requirements from existing knowledge sources through natural language processing and evaluated the extracted early requirements in terms of seismology, building products, and computational fluid dynamics. Michel et al. [12] proposed a SysML-based requirements engineering method based on model-driven requirements and use case diagrams. Modeling user requirements graphically and clearly maps the relationship between requirements and use case diagrams and achieves system decomposition in early system development activities. Reggio [13] introduced the extraction method of IoT system requirements, using UML and extended domain models to generate functional requirement specifications.

Currently, most research on ATO is focused on how to realize the automatic driving function of the ATO system. The test of the ATO system mainly revolves around the construction of test cases, but before generating executable test cases, ATO needs to be more specific to determine the system operation boundary and form the research of the system requirements. With the continuous improvement of the high-speed railway ATO system, related testing work has become more and more important; however, there are still relatively few studies in the field of ATO system testing, and mature system requirements and functional requirements have not yet been formed. The research of this paper is to construct the operational design domain of the high-speed railway ATO system by referring to the operational design domain in the field of autonomous vehicles, thereby proposing a method of extracting system requirements from the specific operation scenarios of the high-speed railway ATO system. The extracted system requirements will prepare the generation of high-speed railway ATO system test cases and system functional specifications. The research structure of this paper is shown in Figure 1.

2. Operational Design Domain of the High-Speed Railway ATO System

2.1. Introduction to the Operational Design Domain

SAE (Society of Automotive Engineers) defines the ODD as “The specific conditions under which a given driving automation system or feature thereof is designed to function, including, but not limited to, driving modes”. The operational design domain is a set of normal working conditions defined at the design level of the train automatic driving system. Further, the ODD represents the conditions that support the normal operation of the automatic driving system and the constraints that determine the normal operation of the system. In general, the ODD is useful for the following tasks [14].

• Design process: Defining the ODD helps identify what scenarios the automated driving system must handle. System-wide and system requirements can then be defined alongside the ODD.
• Testing and verification: The ODD can be sampled to generate test cases with varying levels of detail for unit testing or integration testing via simulation.
• Online monitoring: The ODD can be instantiated as a runtime object to be measured and validated during operation. This is also known as functional boundary monitoring [15].

Thorn E. et al. [16] gave a classification framework for ODD construction. This ODD classification adopts the form of a hierarchical structure of categories and subcategories. Each category has a definition and a level where it is appropriate. This classification is descriptive, not normative, because it is foreseeable that these elements can be organized into several different groups. The taxonomy provides a structured method to organize and identify various ODDs for automated driving system functions. The Figure 2 shows the ODD classification framework with top-level categories and direct sub-categories constructed in the text.

After referring to the contents of the vehicle and system design in the literature [17,18,19,20,21,22], combined with the concept of the operational design domain of auto-driving technology in the literature [16], this paper extracts the operational design domain of the high-speed railway ATO system.

2.2. System Operation Characteristics

• The terrain of China is complicated, and ramps, bends, and tunnels were built according to the terrain during the construction of the running track. For high-speed railways, generally, the maximum gradient is not allowed to be greater than 20‰, and the difficult areas are no greater than 30‰. Steel track-carrying trains are used to run mainly ballastless tracks, and the standard gauge is usually 1435 mm.
• Through the construction of various facilities, many stations have been established along the railway for passengers to get on and off. Some stations are equipped with platform screen doors. At the same time, turnouts are set to guide trains into different platform lanes.
• The operation of the system has its normal temperature, humidity, wind speed, and other environmental requirements. In extreme weather such as strong winds, severe rain, and snow, the operation of the system will be restricted.
• System operation has a boundary: the maximum speed is limited to 350 km/h; the speed in the ceiling speed zone is no less than 80 km/h; and the track the train enters at the station is restricted by the operation plan. The system’s information interaction has a maximum response time. The response time is regarded as a communication timeout. The constraints in operation are also the basis for judging the normal operation of the system.
• The high-speed railway ATO system is based on the CTCS-2/CTCS-3 level train control system. The train is equipped with an ATO unit to realize automatic driving control, and a dedicated precision positioning transponder is installed on the ground to achieve special positioning. The ground equipment communicates via GPRS (General Packet Radio Service) to realize platform door control, data transmission between stations, and train operation adjustment plan (referred to as the operation plan) processing.

2.3. Structure and Interface of the High-Speed Railway ATO System

The high-speed rail ATO system is based on the CTCS-2/CTCS-3 level train control system, with ATO equipment, GPRS radio, and other related equipment added to the train; the ground equipment is in the temporary speed restriction server (TSRS), centralized traffic control (CTC), train control center (TCC), and other equipment. The function is added to the upper part; the precise positioning transponder is added to the station stock road. The high-speed rail ATO system mainly includes five items: automatic departure from the station, automatic operation of the section, automatic stop at the station, automatic door opening, and linkage control of the door and platform door. The high-speed rail ATO system train equipment includes the newly added ATO and train, the ATO and automatic train protection system (ATP) interface, the ATP and train interface, the ground equipment added to TCC and platform door system interface, the modified TSRS and TCC, the TSRS and CTC interface, the ATO train equipment, and the ground TSRS equipment with the newly added GSM-R/GPRS interface. The high-speed rail ATO system interface diagram is shown in Figure 3. The classification of the existing operational design domains according to requirement specifications and overall technical specifications is an important part of constructing operational design domains. Accurate classification is related to the organization of the operational design domain and the completeness of the final result, so it is the basis for in-depth research.

2.4. Operational Design Domain of ATO System Members

The operational design domain of the high-speed railway ATO system can be defined as the set of conditions that satisfy the normal operation of the high-speed railway ATO system. Regarding the operational design domain of auto-driving trains, combined with the operational characteristics of the Chinese high-speed railway ATO system, this article divides the operational design domain of high-speed railway ATO into the following six dimensions: railway infrastructure (RI), related system members (RSMs), information transmission (IT), operation area (OA), operating environment (OE), and operational constraints (OCs). This structure is shown in Figure 4.

$$\mathrm{ODD}=\left\{\left.\mathrm{IT},\mathrm{OA},\mathrm{OC},\mathrm{OE},\mathrm{RI},\mathrm{RSM}\right\}\right.$$

(1)

2.4.1. Railway Infrastructure

Railway infrastructure represents a collection of physical infrastructure conditions required for system operation, including the following five aspects: operating lines, operating tracks, electrical facilities, trackside facilities, and station facilities. Among them, the running line is subdivided from two angles of the plane and longitudinal section, including various line requirements such as radius of the plane curve, line spacing, maximum slope, minimum ramp length, etc.; The running track includes the type of track structure and the rail surface adhesion conditions that support the normal operation of the train; Electrical facilities provide power and energy for trains, including power supply voltage and phase-separation area settings. The phase-separation area settings are an important factor affecting train operation. Trackside facilities are trackside signaling equipment, including balise, track circuits, and switches. Station facilities refer to the newly added platform doors for the operation of the high-speed railway ATO system. Infrastructure is an indispensable physical basic condition for the operation of the high-speed railway ATO system. This structure is shown in Figure 5.

2.4.2. Related System Members

Related system members represent other members of the system on which the operation of the high-speed railway ATO system depends, including trains, ground equipment, and onboard equipment. The train is the control object of the system. The train bridge, train control system, train door system, and dynamic system are all necessary parts of the train. For the ground equipment, there is direct information communication between the TSRS and ATO, which are responsible for the train registration, operation plan, platform door commands and status, and forwarding of the train status. The CTC and radio block center (RBC) do not have a direct interface with ATO, and only the CTC is considered in the operational design, that is the operation plan formulation function of the CTC and the function of the driving permit-issuing of the RBC. For the onboard equipment, the onboard ATP and ATO have a direct interface. The balise transmission module (BTM) equipment is related to the reception of the transponder information, and the track circuit reader (TCR) equipment affects the control commands of the ATP. This structure is shown in Figure 6.

2.4.3. Information Transmission

Information transmission represents the relationship between the information interface in the operation of the system and the information transmitted on the channel, including train-ground communication, train inside communication, and the ground inside communication. Referring to the ATO system interface diagram in the previous section, the train-to-ground communication includes the communication channels among the RBC, ATP, TSRS, and ATO. The train inside communication includes the interface between ATO and the train, the interface between ATP and the train, the interface between ATP and ATO, and the interface among the BTM, TCR, and ATP. The ground inside communication only refers to the information channel related to ATO, the communication interface between the CTC and TSRS, the adjacent TSRS, and the TSRS and TCC. Data in the information transmitted have been described in the foregoing passages and will not be repeated here. This structure is shown in Figure 7.

2.4.4. Operating Area

The operating area refers to the division of the system operation in space, including intra-station area and between-station area. There are many ways to divide the operating space. Here, the area within the station and the area between the stations are divided according to the impact on the operation of the ATO system: in addition to the traditional sideline and the mainline, the station has added switch sections that require a speed limit. The between-station area is divided into phase areas and non-phase areas according to the layout of the electrical facilities. This structure is shown in Figure 8.

2.4.5. Operational Constraints

The operational constraints refer to the set of constraints that define the normal operation of the system, including time constraints, control constraints, and distance constraints. Time constraints include communication time and the normal delay of system control; control constraints include hard ATP control commands and flexible operation plan constraints; distance constraints represent distance conditions that define whether the system is operating normally or not, including but not limited to precise stopping criteria and safe stopping distance. This structure is shown in Figure 9.

2.4.6. Operating Environment

The operating environment refers to the natural environmental constraints of the system operation, including weather, temperature, and humidity, that is wind, rain, snow, and the accompanying natural environment such as temperature, humidity, and wind speed. This structure is shown in Figure 10.

3. Timed Automata and the UPPAAL Tool

3.1. Introduction to Timed Automata

Timed automata (TA) is an abstract model designed to capture the time behavior of real-time systems [23]. It is essentially a finite state machine with extended real-valued clock variables. When the system starts, these clocks increase monotonically at the same rate and measure the elapsed time to control the triggering of events. A timed automata is a tuple $(Q,q,E,X,I,T,Y)$ where:

• Q means a limited set of positions; $q\in Q$ is the initial position.
• E means a limited set of observable behaviors.
• X represents a limited set of clock variables.
• I means the mapping from position to position invariant.
• T means a finite set of integer variables.
• Y means a set of transitions.

The scenario of the linkage control of the door and platform door mainly involves the four modules of onboard ATP, TSRS, train, and onboard ATO. Therefore, the modeling object selects these four modules, and we denote them as $T{A}_{ATO}$, $T{A}_{ATP}$, $T{A}_{Train}$, and $T{A}_{TSRS}$.

3.2. Introduction to the Verification Tool UPPAAL

UPPAAL is a modeling and verification tool specifically for real-time systems. With TA as the modeling language, it provides an efficient, easy-to-use, and portable system. UPPAAL uses a graphical user interface. UPPAAL is mainly composed of the editor, simulator, and validator. The editor can describe the system behavior as a TA network with clock and data variables. The simulator can be used to check the information interaction between the models after the model design is completed, thereby helping the model to correct errors. The verifier can study the state space of the system according to the symbol state represented by the constraint, so as to realize the verification of immutability and reachability. The UPPAAL verification model is based on the BNF (Backus Normal Form) grammar [24], and the meaning of each expression is shown in

Table 1. The grammatical meaning of BNF .

Statement	Meaning
$E\left[\right]P$	There is an execution path; all states satisfy P
$E<>P$	There is an execution path such that a certain state satisfies P
$A\left[\right]P$	For all execution paths, all states satisfy P
$A<>P$	For all execution paths, there are states satisfying P
$P\to Q$	If P is satisfied, then Q must be satisfied

.

4. Case Study

4.1. Scenario Description and Analysis

After ATP confirms that the train is stopped, it sends the onboard ATO permission to open the door. According to the pre-selected door control mode, if it is in AO/MC (automatic opening and manual closing doors) mode, the onboard ATO will operate the door. If it is in MO/MC (manual opening and manual closing doors) mode, the driver will open the door manually. After the onboard ATO sends the door open command or receives the state of the door button pressed, it needs to send the door open command of the platform door. The platform door open command is sent by ATO to the TSRS in the ground equipment that governs the train. Based on the train’s marshalling information and the corresponding ground platform door settings, the TSRS confirms that the corresponding train is properly stopped and then sends a door opening command to the corresponding train control center. After the platform door system opens the platform door, the TSRS informs ATO of the platform door status, and the train ATO displays on the DMI (Driver Machine Interface) whether the platform door linkage is successful. If the status of the platform door is not received for a certain period of time, it will be regarded as a failure. Using the operational design domain of the high-speed railway ATO system as a tool, the scenario was re-deconstructed, and the

Table 2. ODD members of the linkage control scenario.

ODD Type	ODD Class	ODD Members	Details
RSM	Ground equipment	TSRS	Forwarding platform door control and status information
		TCC	Control platform door
	Onboard equipment	ATP	Outputting door opening permission and processing DMI display information
	Running train	Train doors	Controlled object
		Train dynamic system	stopping
		Train control system	AM(Automatic Driving Mode)
IT	Train inside	ATP-ATO	Open train doors permission and information for display
		ATO-train	Door open command, the state of the door button, door control mode
	Ground inside	CTC-TSRS	Operation plan
		TSRS-TCC	Platform door control command and platform door state
	Train ground	TSRS-ATO	Platform door control command, platform door state, and operation plan
OA	Intra-station	Sideline platform
RI	Station facilities	Platform door	Controlled object
OC	Control constraint	Operation plan	Having passenger service
	Position constraint	Precise stopping criterion	Less than 0.5 m
	Time constraint	Communication time	Maximum communication time between the TSRS and ATO is less than 6 s

was designed to reflect the mapping of the linkage control scenario of train doors and platform doors in the operational design domain.

4.2. Scenario Model Construction

The following interaction process as shown in Figure 11 can be extracted from the description of the scenario.

The TA models can be built after finishing the interaction process analysis of the scenario. Figure 12, Figure 13, Figure 14 and Figure 15 show the models of ATP, train, ATO, and TSRS respectively. The variables in the model are shown in

Table 3. Variables in the TA model.

Variable Name	Type	Meaning
$platform\_cmd$	boolean	The signal for open the platform doors permission.
$PS$	integer	The signal for handling passenger transport service (1: handle; 0: does not handle).
$stop$	integer	The signal for the train stops accurately (1: accurately; 0: inaccurately).
$double\_perm$	integer	The signal for open both side train doors permission (1: both side; 0: one side).
$send\_message$	integer	The signal for send display information (1: opening linkage results; 2: closing linkage results).
$door\_mode$	integer	The signal for train doors control mode (1: MO/MC; 2: AO/MC).
$door\_state$	integer	The signal for train doors status (1: opened; 2: closed).
$end$	integer	The signal for interactive termination (0: does not end; 1: end).
$T\_trans$	clock	The clock for train door control time.
$T\_control$	clock	The clock for platform message transmission time.
$T\_delate$	clock	The clock for communication delay.

.

4.3. Verification of the Scenario

After completing the construction of the model, the model needs to be verified to confirm whether the model is consistent with the scenario design. If the verification fails, the model should be positioned and analyzed according to the prompt results, and the model should be continuously corrected and modified to finally realize the model, and the consistency of the description ensures the credibility of subsequent demand extraction. In accordance with the previous description of the model verification technology, this article uses the UPPAAL tools to carry out model verification from two perspectives of dynamic execution verification and property verification.

4.3.1. Performing Verification Dynamically

In the scenario of the linkage control of the train door and platform door, the information interaction relationship among ATO, ATP, the train, and the TSRS is shown in Figure 16.

Taking the UML sequence diagram as a reference, the migration is performed step by step in the UPPAAL simulator to observe the execution path of the model and analyze the interactive behavior of the model. If a migration cannot be executed, an error message will appear in the simulator to assist in the modification of the model. Then, the verification process of the model interaction process is given in Figure 17.

4.3.2. Property Verification

Property verification is done to check whether the built model meets the logic function characteristics and timing function characteristics required in the specification through the reachability of the model. The functional attributes are summarized and extracted and converted into corresponding BNF sentences for verification in the UPPAAL validator. The

Table 4. TA model validation results.

Properties	BNF Statement	Result	Calculating Time
Can restart platform door linkage	E[]($ATO.showcloselink\_failed$ implies $ATO.send\_Platform\_door\_open\_cmd$)	pass	2.8 ms
Automatic door opening	E<>($ATO.idle$ implies $ATO.ATO\_control\_door$)	pass	1.5 ms
Send platform door control command	E<>($ATO.idle$ implies $TSRS.rec\_platform\_door\_cmd$)	pass	1.6 ms
Send linkage results	E<>($ATO.idle$ implies $ATP.rec\_ATO\_show\_msg$)	pass	1.9 ms
Information interaction time is less than 6 s	A[]($ATO.send\_Platform\_door\_open\_cmd$ implies $T\_delate$<=6) and ($ATO.rec\_Platform\_door\_open\_state$ implies $T\_delate$<=6) and ($ATO.send\_close\_door\_cmd$ implies $T\_delate$<=6) and ($ATO.rec\_Platform\_door\_close\_state$ imply $T\_delate$<=6)	pass	3.8 ms
Total time			11.6 ms

gives the function points of the verification and verification statements and results.

4.4. Demand Extraction

Using the verified scenario model as the demand model, combined with the odd mapping of the scenario, we extract the design input and expected output in the scenario as

Table 5. System requirement parameters in the scenarios.

Conditions	Input	Output
1. AM mode	1. Operation plan	1. Doors open command
2. Passenger service	2. Open train doors permission	2. Platform door control command
3. Sideline platform	3. The state of the door button	3. Information for display
4. Stop	4. Doors control mode
	5. Platform door state

.

The following system requirements can be extracted:

• In the door control mode AO/MO, the onboard ATO can automatically open the door according to the plan when the sideline platform has the condition of stopping.
• In the AM mode, the onboard ATO can send correct platform door control commands to the TSRS based on the planning and marshalling information and the status of the door buttons.

5. Conclusions and Future Work

This paper constructs the operational design domain of the high-speed railway ATO system with reference to the framework of the operational design domain of autopilot and analyzes the linkage control scenarios of train doors and platform doors. The article uses TA grammar and UPPAAL tools to build a model of the scenario and verify it and finally extracts the system requirements of the onboard ATO in the scenario. The extracted system requirements will provide support for future test case design. The next research will focus on further improving the extraction results of the system requirements. Further study will be done of the effective method for generating test cases based on system requirements to meet the requirements of laboratory system testing.