Rail transit vehicle-mounted task verification method

By verifying the legitimacy of tasks issued by the ATS through the onboard controller (CC), and taking into account its own status and environmental factors, the problem of insufficient verification of tasks issued by the ATS by the CC is solved, thereby improving driving safety and operational efficiency.

CN118205594BActive Publication Date: 2026-11-06卡斯柯信号(成都)有限公司
View PDF 3 Cites 0 Cited by

Patent Information

Application Number
CN202311469080.0
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2023-11-07
Publication Date
2026-11-06
Estimated Expiration
2043-11-07

AI Technical Summary

Technical Problem

In the existing technology, the onboard controller (CC) lacks effective verification of the tasks issued by the Automatic Train Control System (ATS), which leads to potential safety hazards and does not optimize user experience and operational efficiency.

Method used

The vehicle controller (CC) combines its own status, historical information and other environmental factors to verify the legitimacy of the received driving tasks, including verifying configuration requests, driving task requests, driving tasks and available driving tasks. It only executes the task after the verification is successful and reports the reason for the verification failure to the ATS.

Benefits of technology

To ensure driving safety, optimize user experience and operational efficiency, and reduce safety risks in driving tasks by providing a complete verification process and task switching solution.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN118205594B_ABST
    Figure CN118205594B_ABST
Patent Text Reader

Abstract

This invention discloses a method for verifying onboard tasks in rail transit, relating to the field of rail transit technology. The method includes: when a vehicle receives a driving task from the ATS (Automatic Train Service), its CC (Controlled Carrier) performs a legality verification of the received driving task based on its own status, historical information, and other environmental factors. This includes sequentially verifying the configuration request, the driving task request, the driving task itself, and the available driving task. If the verification passes, the vehicle drives according to the driving task; if the verification fails, the driving task is ignored, and the reason for the task verification failure is sent to the ATS. This invention does not completely trust the driving task issued by the ATS, but rather focuses on the CC's ability to verify the legality of the received driving task based on its own status, historical information, and other environmental factors. It provides a complete verification process that runs through the entire process from the ATS issuing the configuration request to its conversion into the actual driving task executed by the train.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of rail transit technology, and more specifically to a rail transit onboard task verification method, which can be used in the TACS train control system for the verification, updating, and authorization management of onboard tasks issued by the Automatic Train Supervision (ATS) system by the onboard controller (CC). Background Technology

[0002] CC is a subsystem of the Automatic Train Control (ATC) system. CC works in conjunction with other subsystems such as the Wayside Resource Controller (WRC), Wayside Train Controller (WTC), and ATS to enable train operation based on tasks issued by the ATS.

[0003] Existing technical solutions primarily focus on generating operational plans based on user needs. Once the operational plan is issued to the train, the train operates according to the plan, meaning the CC assumes the tasks issued by the ATS are valid. However, train operation is influenced by various factors. To ensure safe and efficient system operation, the train needs to verify the tasks issued by the ATS in conjunction with the current status, historical information, and other environmental factors. Only after successful verification can the train operate according to the task. Current research has focused relatively little on the CC's verification of tasks issued by the ATS. In the prior art, patent CN110857110B discloses a train dispatching method, dispatching device, dispatching system, terminal equipment, and train. After receiving a passenger's request including a first identifier of the passenger's current station and a second identifier of the destination station, the train matches a train to be dispatched from multiple trains and sends the first and second identifiers to the dispatched train. This causes the dispatched train to travel to the passenger's current station based on the first identifier, and simultaneously to travel towards the destination station based on the second identifier. In this patent, the train operation is driven by the passenger. After the passenger requests the current and destination station locations, the train operation task is issued to the train, which then travels to the passenger's current location according to the task and then proceeds to the destination station. The train does not verify the legality or security of the received task, which poses certain risks.

[0004] Search results for relevant papers show that current research mainly focuses on how to generate operation plans, with little mention of how the CC verifies the operation plan after it is issued to the train scheduler. For example, the paper "Research on Intelligent Adjustment Method of Intercity Railway Train Schedule Considering Balance" mentions an algorithm for intelligent adjustment and optimization of train schedules based on factors such as passenger flow, station operations, and train operation safety. This algorithm also requires trains to strictly follow the operation plan and does not address the area of ​​CC verification of train operation tasks. Summary of the Invention

[0005] To overcome the shortcomings of the existing technology, this invention discloses a method for verifying onboard tasks in rail transit. The purpose of this invention is to solve the problems existing in the verification of tasks issued by the control center (CC) to the automatic train control system (ATS) in the prior art. To ensure train operation safety, the CC should verify the legality of received train operation tasks by considering its own status, historical information, and other environmental factors. Only if the verification passes can the task be considered valid, and train operation proceed according to the task. If the verification fails, the task is ignored, and the reason for the task verification failure is replied to the ATS for confirmation by the dispatcher. Furthermore, to optimize user experience and improve operational efficiency, when the CC receives a new task while executing the current train operation task, it should update the currently executing task after successful verification.

[0006] To achieve the above objectives, the technical solution adopted by the present invention is as follows: A method for verifying onboard tasks in rail transit includes: when a vehicle receives a driving task issued by an Automatic Train Control System (ATS), its Control Center (CC) performs a legality verification of the received driving task by combining its own status, historical information, and other environmental factors. This includes sequentially verifying the configuration request, the driving task request, the driving task itself, and the available driving task. If the verification is successful, the vehicle drives according to the driving task; if the verification fails, the driving task is ignored, and the reason for the task verification failure is sent to the ATS. The ATS is an Automatic Train Monitoring System, and the CC is an onboard controller.

[0007] In this invention, when a vehicle receives a driving task from the ATS, the CC should perform a legality verification of the received driving task based on its own status, historical information, and other environmental factors. This includes multiple verification processes such as verifying the configuration request, verifying the driving task request, verifying the driving task, verifying "available driving tasks," and updating the driving task. A verification process and switching scheme are provided for each step of the verification, as follows: 1. Verify the configuration request (Setting request) Preferably, in the verification configuration request, the number of task requests in the configuration request issued by the verification ATS is not less than 1 and not more than 2.

[0008] In this invention, the train operation task request is included in the configuration request issued by the ATS. Therefore, the information in the configuration request must be verified first. In the configuration request, the ATS issues the train operation task request and the number of task requests. Only when the number of task requests is not less than 1 and not greater than 2 can the CC proceed with the subsequent processing of the train operation task request in this configuration request.

[0009] II. Verify the driving task request Preferably, the verification driving task request includes the calculation of elements such as destination parking area / path start area, destination parking point / departure parking point, driving task path, and departure area. If any element in the destination parking area / route start area or destination parking point / departure parking point fails to be calculated, the driving task verification request will fail. Otherwise, by combining the above elements with the departure time and stop information in the task request, train operation task 1 and train operation task 2 can be formed.

[0010] Preferably, in calculating the elements of destination parking area / route start area, destination parking point / departure parking point, and departure area, the method is to search for corresponding route resource information in the route resources based on the values ​​of relevant fields in the driving task request.

[0011] Preferably, in the calculation of the driving task path element, a driving task path from the starting area to the destination parking area is searched in the route map based on the path starting area and the destination parking area, combined with the turnout position information in the driving task request.

[0012] III. Verification of Driving Tasks Preferably, the verification of the train operation task includes: verifying the CC's own status, verifying that this train operation task is not a cancellation command issued by the ATS, verifying the continuity of the train operation task with historical tasks, verifying whether the current position of the train is compatible with the train operation task, verifying the continuity of train operation task 1 and train operation task 2, and verifying the validity of the train operation task path.

[0013] Preferably, the verification method for CC's own status is as follows: CC is able to calculate the train's location information on the route map, and according to the location information, CC does not appear in the unauthorized area.

[0014] Preferably, the verification method for confirming that the driving task is not a cancellation command issued by the ATS is as follows: the departure area ID and destination parking area ID of driving task 1 and driving task 2 are not both 0.

[0015] Preferably, the method for verifying the continuity between the driving task and the historical task is as follows: if there is a driving task being executed, the departure area of ​​the current driving task should be consistent with the destination parking area of ​​the driving task being executed; otherwise, if there is a driving task that has been completed, the departure area of ​​the current driving task should be consistent with the destination parking area of ​​the completed driving task; otherwise, the departure area of ​​the current driving task should be empty.

[0016] Preferably, the verification method for whether the current position of the train is compatible with the train operation task is as follows: if the starting area of ​​the path is located within the ATS jurisdiction boundary, the current position of the train should intersect with the ATS jurisdiction area; if the starting area of ​​the path is not within the ATS jurisdiction boundary, the current position of the train should intersect with the train operation task path.

[0017] Preferably, the method for verifying the continuity between driving task 1 and driving task 2 is as follows: if driving task 2 exists, the departure area of ​​driving task 2 must be consistent with the destination parking area of ​​driving task 1.

[0018] Preferably, the method for verifying the validity of the driving task path is: CC can search for the path from the starting area to the parking area in the route map.

[0019] Preferably, the driving task 1 is: If the train is in a state of ignoring train operation tasks, the available train operation task 1 is empty; If the train is not in a state of ignoring train operation tasks and all of the above verification rules are met, train operation task 1 is converted into a usable train operation task 1. If the train is not in a state of ignoring train operation tasks and at least one of the above verification rules is not met, then the available train operation task 1 will maintain its existing state and will not be updated.

[0020] Preferably, the driving task 2: If the train is in a state of ignoring train operation tasks, the available train operation task 2 is empty; If the train is not in the state of ignoring train operation tasks and train operation task 1 is verified, then it is only necessary to check the validity of the verification of the train operation task path of train operation task 2. If the conditions are met, train operation task 2 is directly converted into usable train operation task 2. At this time, there is no need to perform the above rules for subsequent verification of train operation task 2. If the train is not in a state of ignoring train operation tasks and train operation task 1 passes the verification but the validity verification of the train operation task path of train operation task 2 fails, then the available train operation task 2 is empty. If the train is not in a state of ignoring train operation tasks and the verification of train operation task 1 fails, then all the above rules need to be verified for train operation task 2. If all the above conditions are met, then train operation task 2 is converted into a usable train operation task 2. If the train is not in a state of ignoring train operation tasks and the verification of train operation task 1 fails, then the above rules are applied to the verification of train operation task 2. If at least one condition is not met, then the existing state of the available train operation task 2 is maintained.

[0021] After completing the above verification, usable train task 1 and usable train task 2 can be generated, and the reason for the failure of the train task verification will be sent back to ATS for the dispatcher to confirm.

[0022] IV. Verify available driving tasks Preferably, the available driving task verification methods include: If there is an available driving task 1 and a completed driving task, and the departure area of ​​the available driving task 1 is the same as the destination parking area of ​​the completed driving task, then the available driving task 1 can be converted into a task to be executed, and the available driving task 2 can be converted into a task to be executed. Otherwise, if there is an available driving task 1 but the completed driving task does not exist, and the departure area ID of the available driving task 1 is 0, then the available driving task 1 can be converted into a task to be executed, and the available driving task 2 can be converted into a task to be executed. Otherwise, if there is an available driving task 2 and a completed driving task, and the departure area of ​​the available driving task 2 is the same as the destination parking area of ​​the completed driving task, then the available driving task 2 can be converted into a task to be executed. At this time, the task to be executed is empty. Otherwise, if there is an available driving task 2 but the completed driving task does not exist, and the departure area ID of the available driving task 2 is 0, then the available driving task 2 can be converted into a task to be executed. At this time, the task to be executed is empty. In other cases, both "Preparing to execute the task" and "Preparing to execute the next task" are empty.

[0023] V. Driving Task Update Preferably, it also includes driving task updates, wherein the driving task updates include: The task to be executed is the task currently being executed; the task to be executed next is the next task to be executed; completed tasks are initialized to empty. When the train arrives at the destination parking area of ​​the task being performed and stops precisely, or when the train passes through a stop and both the current task and the next task's stop function are for passenger transfer, then the train operation task needs to be updated and switched to the next task: update the completed task to the task to be prepared for execution, update the current task to the task to be prepared for the next task, and update the next task to empty.

[0024] The beneficial effects of this invention are: The rail transit onboard task verification method provided by this invention does not completely trust the train operation tasks issued by the ATS. Instead, it focuses on the fact that the CC should combine its own status, historical information and other environmental factors to verify the legality of the received train operation tasks. It also provides a complete verification process that runs through the entire process from the ATS issuing the configuration request to converting it into the actual train operation task executed by the train.

[0025] To ensure train operation safety, this invention requires that when a train receives a train operation task from the ATS, the CC (Train Control Center) should verify the legality of the received task based on its own status, historical information, and other environmental factors. Only if the verification passes can the task be considered valid, and the train can proceed according to the task. If the verification fails, the task is ignored, and the reason for the task verification failure is reported back to the ATS for confirmation by the dispatcher. Based on the above principles, this patent proposes a verification method and task switching scheme for train operation tasks. Between the ATS issuing a configuration request and the actual train operation task being executed, this patent proposes multiple intermediate states, including "train operation task request," "train operation task," "available train operation task," "preparing to execute task," and "preparing to execute the next task." For each intermediate state, a verification process and switching scheme are provided, taking into account both train operation safety and operational efficiency. Attached Figure Description

[0026] Figure 1 This is a schematic diagram of the present invention. Detailed Implementation

[0027] The following will provide a clear and complete description of the concept, specific structure, and technical effects of the present invention in conjunction with the embodiments and accompanying drawings, so as to fully understand the purpose, features, and effects of the present invention.

[0028] A method for verifying onboard tasks in rail transit, such as Figure 1 As shown, the process includes: when a vehicle receives a driving task from the ATS, its CC (Controlled Controller) performs a legality check on the received driving task by combining its own status, historical information, and other environmental factors. This includes sequentially verifying the configuration request, the driving task request, the driving task itself, and the available driving tasks. If the verification is successful, the vehicle drives according to the driving task; if the verification fails, the driving task is ignored, and the reason for the task verification failure is sent to the ATS. Here, the ATS is the Automatic Train Monitoring System, and the CC is the onboard controller.

[0029] In this invention, when a vehicle receives a driving task from the ATS, the CC should perform a legality verification of the received driving task based on its own status, historical information, and other environmental factors. This includes multiple verification processes such as verifying the configuration request, verifying the driving task request, verifying the driving task, verifying "available driving tasks," and updating the driving task. A verification process and switching scheme are provided for each step of the verification, as follows: 1. Verify the configuration request (Setting request) The train operation task request is included in the configuration request issued by the ATS, so the information in the configuration request must be verified first. In the configuration request, the ATS will issue the train operation task request and the number of task requests. The CC can only process the train operation task request in this configuration request if the number of task requests is not less than 1 and not more than 2.

[0030] 2. Verify the driving task request For each driving task request in the configuration request, calculate the following elements based on the route data: a) Destination parking area / route start area: Based on the destination parking area ID / route start area ID in the driving task request, find the corresponding destination parking area / route start area in the route resources; b) Destination stop / departure stop: Based on route resources, find the destination stop / departure stop that is suitable for the current vehicle model in the destination stop area / route start area; c) Driving task path: Based on the starting area and destination parking area, and combined with the switch location information (location or range) in the driving task request, a driving task path from the starting area to the destination parking area is searched in the route map. d) Departure Area: Based on the departure area ID in the driving task request, find the corresponding departure area in the route resources.

[0031] If any element in a / b cannot be calculated, it indicates that there is a conflict between the task issued by ATS and the line data, and the train operation task request can be considered invalid; otherwise, by combining the above elements and information such as departure time and station functions (passenger transfer, turnaround operation, etc.) in the operation task request, train operation task 1 and train operation task 2 are formed.

[0032] 3. Verify driving tasks For the driving task 1 and driving task 2 generated in step 2, they are verified separately by combining historical information, and finally "available driving task 1" and "available driving task 2" are formed.

[0033] The verification rules are defined as follows: a) At this time, CC can calculate the train's location information on the route map, and according to the location information, CC does not appear in the unauthorized area.

[0034] Note: WRC calculates the CC's authorized region based on the resource information allocated to the CC, but this part is beyond the scope of this article.

[0035] b) This driving task is not a driving task cancellation command issued by ATS, that is, the departure area ID and destination parking area ID of driving task 1 and driving task 2 are not both 0.

[0036] c) Verify the continuity between the current train operation task and historical tasks. Specifically: if a "currently executing train operation task" exists, the departure area of ​​the current task should match the destination stopping area of ​​that task; otherwise, if a "completed train operation task" exists, the departure area of ​​the current task should match the destination stopping area of ​​the completed task; otherwise, the departure area of ​​the current task should be empty. For example, if the train is currently executing a task from station A to station B, the departure area of ​​a newly received train operation task must be station B; if the train has completed a task from station A to station B, the departure area of ​​a newly received task must be station B; if the train is in a newly awakened state, with neither currently executing nor completed tasks, only the destination stopping area needs to be specified, and the departure area in the task issued by the ATS should be empty.

[0037] d) Verify whether the train's current location is compatible with the train operation task. That is, if the starting area of ​​the route is located within the ATS jurisdiction boundary, the train's current location should intersect with the ATS jurisdiction area. For example, if the train enters the jurisdiction from outside the ATS jurisdiction boundary, and the departure area of ​​the task issued by the ATS is located within this jurisdiction boundary, the task can only be considered valid after the train enters the ATS jurisdiction boundary. If the starting area of ​​the route is not within the ATS jurisdiction boundary, the train's current location should intersect with the train operation task route. For example, if the train operation task requires the train to depart from station A to station B, the train operation task can only be considered valid if the train is located in the area between station A and station B (including the area where station A and station B are located).

[0038] e) Verify the continuity between driving task 1 and driving task 2: If driving task 2 exists, the departure area of ​​driving task 2 must be consistent with the destination parking area of ​​driving task 1.

[0039] f) Verify the validity of the driving task path, that is, CC can search for the path from the starting area to the parking area in the route map.

[0040] For driving task 1: If the train is in a "ignore train operation task" state (such as the current train encroaching on an unauthorized area), the available train operation task 1 is empty; If the train is not in the "ignore train operation task" state and all the above verification rules are met, train operation task 1 is converted into "available train operation task 1"; If the train is not in the "ignore train operation task" state and at least one of the above verification rules is not met, then "available train operation task 1" will remain in its existing state and will not be updated.

[0041] For driving task 2: If the train is in a state of "ignoring train operation tasks" (such as the current train encroaching on an unauthorized area), the available train operation task 2 is empty; If the train is not in the "ignore train operation task" state and train operation task 1 has passed verification, then it is only necessary to check that rule f of train operation task 2 has passed verification (i.e., the train operation task path of train operation task 2 is valid). If the conditions are met, train operation task 2 is directly converted into "usable train operation task 2", and there is no need to perform the above-mentioned subsequent verification of the rules for train operation task 2. For example, if the train is located at station A, train operation task 1 is from station A to station B, and train operation task 2 is from station B to station C, if train operation task 1 has passed verification, then for train operation task 2, rules a / b / e have also passed verification. It is only necessary to ensure that rule f has passed verification, even if rules c / d are not verified at this time. Even if the verification fails, it can still be considered that Train Operation Task 2 is valid (since Train Operation Task 2 is a follow-up task to Train Operation Task 1, when verifying Train Operation Task 2, rules c / d are likely to be unsatisfactory. Therefore, the above verification should be performed after Train Operation Task 1 is completed and Train Operation Task 2 is the task that the train is about to perform; for example, for rule c, there is no task being performed at this time, the destination stopping area of ​​the completed task is station A, and the departure area of ​​Train Operation Task 2 is station B, which are not consistent, so rule c verification fails; similarly, for rule d, the train is located at station A at this time, but is not within the train operation path area from station B to station C, so the verification also fails).

[0042] If the train is not in the "ignore train operation task" state and train operation task 1 is verified successfully while rule f of train operation task 2 is not verified successfully (i.e., the train operation task path of train operation task 2 is invalid), then "available train operation task 2" is empty.

[0043] If the train is not in the "ignore train operation task" state and the verification of train operation task 1 fails, then all the above rules need to be verified for train operation task 2. If all the above conditions are met, then train operation task 2 is converted into "available train operation task 2". If the train is not in the "ignore train operation task" state and the verification of train operation task 1 fails, then the above rules are applied to the verification of train operation task 2. If at least one condition is not met, then the "available train operation task 2" remains in its existing state.

[0044] After completing the above verification, "Available Train Task 1" and "Available Train Task 2" can be generated, and the reason for the failure of the train task verification can be replied to ATS for dispatchers to confirm.

[0045] 4. Verify "Available Driving Tasks" If there is an available train operation task 1 and a "completed train operation task", and the departure area of ​​the available train operation task 1 is the same as the destination stopping area of ​​the "completed train operation task", then the available train operation task 1 can be converted into a "task to be executed", and the available train operation task 2 can be converted into a "task to be executed". For example, if the train has just completed the task from station A to station B and is currently at station B, the available train operation task 1 is from station B to station C, and the available train operation task 2 is from station C to station D. Then the train is ready to execute the task from station B to station C, and the next task to be executed is from station C to station D.

[0046] Otherwise, if there is an available driving task 1 but there is no "completed driving task", and the departure area ID of the available driving task 1 is 0, then the available driving task 1 can be converted into "prepared to execute task", and the available driving task 2 can be converted into "prepared to execute next task". Otherwise, if there is an available train operation task 2 and a "completed train operation task", and the departure area of ​​the available train operation task 2 is the same as the destination stopping area of ​​the "completed train operation task", then the available train operation task 2 can be converted into a "task to be executed", and at this time, "prepared to execute the next task" is empty. Using the above scenario as an example, the train continues its journey and arrives at station C. At this point, the completed task is the journey from station B to station C. The available train operation task 2 meets the above conditions, so it is prepared to execute the journey from station C to station D, and the next task to be executed is empty.

[0047] Otherwise, if there is an available train operation task 2 but the "completed train operation task" does not exist, and the departure area ID of the available train operation task 2 is 0, then the available train operation task 2 can be converted into a "task to be executed". At this time, "prepared to execute the next task" is empty. For example, if the train is in a newly awakened state and the verification of train operation task 1 issued by ATS fails, the available train operation task 1 remains in its original state (i.e., empty), and the departure area ID of the available train operation task 2 is 0, then the task to be executed is the available train operation task 2.

[0048] In other cases, both "Preparing to execute the task" and "Preparing to execute the next task" are empty.

[0049] 5. Driving mission update Generally, "Task to be executed" is the same as "Task currently being executed", "Task to be executed next" is the same as "Next task to be executed", and "Completed tasks" is initialized to empty.

[0050] When the train arrives at the destination parking area for the current task and stops precisely, or when the train passes through a stop and both the current task and the next task's stop function are for passenger transfer, the train operation task needs to be updated to switch to the next task: update the completed task to "Preparing to execute task", update "current task" to "Preparing to execute the next task", and update the next task to empty.

[0051] The above process completes the conversion from ATS issuing a configuration request to "Task in Progress," and verifies the driving task issued by ATS during this process. After generating "Task in Progress," it can be handed over to other subsystems of the CC system, such as ATP / ATO, thereby achieving the goal of controlling the vehicle to drive according to the plan.

[0052] The embodiments of the present invention have been described in detail above, but the present invention is not limited to the described embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of the present invention, and these equivalents or substitutions are all included within the scope defined by the claims of the present invention.

Claims

1. A method for verifying onboard tasks in rail transit, characterized in that, include: When a vehicle receives a driving task from the ATS, its CC (Controlled Controller) performs a legality check on the received driving task by combining its own status, historical information, and other environmental factors. This includes sequentially verifying the configuration request, the driving task request, the driving task itself, and the available driving task. If the verification is successful, the vehicle will drive according to the driving task. If the verification fails, the driving task will be ignored, and the reason for the task verification failure will be sent to the ATS. Here, the ATS is the Automatic Train Monitoring System, and the CC is the onboard controller. In the verification configuration request, the number of task requests in the configuration request issued by the verification ATS is not less than 1 and not more than 2. The verification driving task request includes the calculation of elements such as destination parking area / path start area, destination parking point / departure parking point, driving task path, and departure area. If any element in the destination parking area / route start area or destination parking point / departure parking point fails to be calculated, the driving task verification request will fail. Otherwise, by combining the above elements and the departure time and stop information in the task request, train operation task 1 and train operation task 2 can be formed. The verification of the train operation task includes: verifying the CC's own status, verifying that this train operation task is not a cancellation command issued by the ATS, verifying the continuity of the train operation task with historical tasks, verifying whether the current position of the train is compatible with the train operation task, verifying the continuity of train operation task 1 and train operation task 2, and verifying the validity of the train operation task path. The available vehicle task verification methods include: If there is an available driving task 1 and a completed driving task, and the departure area of ​​the available driving task 1 is the same as the destination parking area of ​​the completed driving task, then the available driving task 1 can be converted into a task to be executed, and the available driving task 2 can be converted into a task to be executed. Otherwise, if there is an available driving task 1 but the completed driving task does not exist, and the departure area ID of the available driving task 1 is 0, then the available driving task 1 can be converted into a task to be prepared for execution, and the available driving task 2 can be converted into a task to be prepared for execution of the next task. Otherwise, if there is an available driving task 2 and a completed driving task, and the departure area of ​​the available driving task 2 is the same as the destination parking area of ​​the completed driving task, then the available driving task 2 can be converted into a task to be executed. At this time, the task to be executed is empty. Otherwise, if there is an available driving task 2 but the completed driving task does not exist, and the departure area ID of the available driving task 2 is 0, then the available driving task 2 can be converted into a task to be executed. At this time, the task to be executed is empty. In other cases, both "Preparing to execute the task" and "Preparing to execute the next task" are empty.

2. The vehicle-mounted mission verification method as described in claim 1, characterized in that, The calculation of the destination parking area / route start area, destination parking point / departure parking point, and departure area elements is performed by searching for corresponding route resource information in the route resources based on the values ​​of the relevant fields in the driving task request. In the calculation of the driving task path elements, based on the path starting area and the destination parking area, and combined with the turnout location information in the driving task request, a driving task path from the path starting area to the destination parking area is searched in the route map.

3. The vehicle-mounted mission verification method as described in claim 1, characterized in that, The verification method for CC's own state is as follows: CC is able to calculate the train's location information on the route map at this time, and according to the location information, CC does not appear in the unauthorized area; The verification method for confirming that this driving task is not a cancellation command issued by ATS is as follows: the departure area ID and destination parking area ID of driving task 1 and driving task 2 are not both 0. The method for verifying the continuity between driving tasks and historical tasks is as follows: if there is a driving task being executed, the departure area of ​​the current driving task should be consistent with the destination parking area of ​​the driving task being executed. Otherwise, if a driving task has been completed, the departure area of ​​the current driving task should be the same as the destination parking area of ​​the completed driving task; otherwise, the departure area of ​​the current driving task should be empty. The verification method for whether the current position of the train is compatible with the train operation task is as follows: if the starting area of ​​the path is located within the ATS jurisdiction boundary, the current position of the train should intersect with the ATS jurisdiction area; if the starting area of ​​the path is not within the ATS jurisdiction boundary, the current position of the train should intersect with the train operation task path. The method for verifying the continuity between driving task 1 and driving task 2 is as follows: if driving task 2 exists, the departure area of ​​driving task 2 must be consistent with the destination parking area of ​​driving task 1. The method for validating the driving route is as follows: CC can search for the route from the starting area to the parking area on the route map.

4. The vehicle-mounted mission verification method as described in claim 3, characterized in that, Driving task 1: If the train is in a state of ignoring train operation tasks, the available train operation task 1 is empty; If the train is not in a state of ignoring train operation tasks and all of the above verification rules are met, train operation task 1 is converted into a usable train operation task 1. If the train is not in a state of ignoring train operation tasks and at least one of the above verification rules is not met, then the available train operation task 1 will maintain its existing state and will not be updated.

5. The vehicle-mounted mission verification method as described in claim 4, characterized in that, Driving task 2: If the train is in a state of ignoring train operation tasks, the available train operation task 2 is empty; If the train is not in the state of ignoring train operation tasks and train operation task 1 is verified, then it is only necessary to check the validity of the verification of the train operation task path of train operation task 2. If the conditions are met, train operation task 2 is directly converted into usable train operation task 2. At this time, there is no need to perform the above rules for subsequent verification of train operation task 2. If the train is not in a state of ignoring train operation tasks and train operation task 1 passes the verification but the validity verification of the train operation task path of train operation task 2 fails, then the available train operation task 2 is empty. If the train is not in a state of ignoring train operation tasks and the verification of train operation task 1 fails, then all the above rules need to be verified for train operation task 2. If all the above conditions are met, then train operation task 2 is converted into a usable train operation task 2. If the train is not in a state of ignoring train operation tasks and the verification of train operation task 1 fails, then the above rules are applied to the verification of train operation task 2. If at least one condition is not met, then the existing state of the available train operation task 2 is maintained.

6. The vehicle-mounted mission verification method as described in claim 1, characterized in that, It also includes driving task updates, which include: The task to be executed is the task currently being executed; the task to be executed next is the next task to be executed; completed tasks are initialized to empty. When the train arrives at the destination parking area of ​​the task being performed and stops precisely, or when the train passes through a stop and both the current task and the next task's stop function are for passenger transfers, then the train operation task needs to be updated and switched to the next task: update the completed task to the task to be prepared for execution, update the current task to the task to be prepared for the next task, and update the next task to empty.

Citation Information

Patent Citations

  • Train dispatching methods, dispatching devices, dispatching systems, terminal equipment, and trains

    CN110857110B

  • Public-transport line vehicle-driving plan generation method and device

    CN108734353A

  • Rail transit signal and vehicle professional interface linkage verification method and device

    CN113212500A