A method, system, device, and medium for dynamic management of object controllers.

Abstract

This invention discloses a method, system, device, and medium for dynamic management of object controllers. The method is used in a train control system for vehicle-to-vehicle communication. The train control system includes a trackside resource controller, which is pre-configured with a set of controllable object controllers and a set of communicable object controllers. The method includes: acquiring the status identifiers of adjacent trackside resource controllers; and dynamically adjusting message processing strategies based on the status identifiers: if the status identifier indicates that an adjacent trackside resource controller is available, the current trackside resource controller only processes messages from the set of controllable object controllers; if the status identifier indicates that an adjacent trackside resource controller is unavailable, the current trackside resource controller processes messages from all object controllers in the set of communicable object controllers. Compared with existing technologies, this invention achieves flexible configuration of trackside resource controllers and seamless resource takeover in case of failure by pre-configuring the object controller set and using a dynamic negotiation and takeover mechanism based on status identifiers.

Description

Technical Field

[0001] This invention relates to the field of rail transit signal control technology, and in particular to a method, system, device and medium for dynamic management of object controllers on the trackside resource controller side of vehicle-to-vehicle communication. Background Technology

[0002] Vehicle-to-vehicle communication, as a new generation of train control system, mainly includes the onboard controller (CC), the wayside train controller (WTC), and the wayside resource controller (WRC). The onboard controller (CC) or the wayside train controller (WTC) calculates the train's running trajectory, while the wayside resource controller (WRC) completes the allocation and monitoring of resources.

[0003] In existing vehicle-to-vehicle communication systems, the trackside resource controller (WRC) obtains the status of trackside equipment such as switches, signals, and CPB (Containment Push Button) through the object controller (OC). Generally, the WRC and OC are connected by hard wires. However, in certain specific situations, hard wires cannot be laid out, and when adjacent WRCs are not working, trains may be unable to reach the boundary or obtain trackside equipment resources at the boundary.

[0004] A search revealed that Chinese Patent Publication No. CN111776013A discloses a train autonomous control system and method based on vehicle-to-vehicle communication. This system centrally manages resource allocation and simplifies system interfaces by setting up a single trackside resource manager (WRC). The WRC is used as a backup for a faulty train to take over its resource requests and information interactions, thereby reducing data transmission links and improving system efficiency. However, this solution only describes the architecture of a single WRC and does not address the resource collaborative management problem of boundary areas when multiple WRCs coexist. It does not solve the problem of how adjacent WRCs can dynamically take over the boundary trackside equipment resources under their jurisdiction when a WRC fails.

[0005] Therefore, how to achieve flexible communication configuration between the trackside resource controller and the object controller, and seamlessly take over trackside equipment resources when the adjacent trackside resource controller fails, is a technical problem that needs to be solved. Summary of the Invention

[0006] The purpose of this invention is to overcome the defects of the prior art and provide a dynamic management method, system, device and medium for object controllers.

[0007] The objective of this invention can be achieved through the following technical solutions: According to a first aspect of the present invention, a dynamic management method for object controllers is provided. This method is used in a train control system with vehicle-to-vehicle communication. The train control system includes a trackside resource controller, which is pre-configured with a set of controllable object controllers and a set of communicable object controllers. The set of communicable object controllers includes the set of controllable object controllers. The method includes: Obtain the status identifier of the adjacent trackside resource controller, the status identifier being used to indicate whether the corresponding trackside resource controller is in an available working state; The current trackside resource controller dynamically adjusts its message processing strategy for each object controller it communicates with based on the status flags. If the status indicator indicates that the adjacent trackside resource controller is available, the current trackside resource controller only processes messages from the set of controllable object controllers; If the status flag indicates that the adjacent trackside resource controller is unavailable, the current trackside resource controller processes messages from all object controllers in the set of communicable object controllers.

[0008] As a preferred technical solution, the controllable object controller is an object controller whose physical location of the equipment belongs to the current trackside resource controller. The communicable object controller is all the object controllers that need to communicate with the current trackside resource controller. Furthermore, the number of object controllers in the set of communicable object controllers is greater than or equal to the number of object controllers in the set of controllable object controllers.

[0009] As a preferred technical solution, the status identifier has two status values: a first status value, which indicates that the trackside resource controller to which it belongs is in an available state; The second status value is used to indicate that the trackside resource controller to which it belongs is in an unavailable or faulty state.

[0010] As a preferred technical solution, the method further includes an initialization phase: After the trackside resource controller is powered on, it attempts to establish communication with the adjacent trackside resource controller. If a response is received from the adjacent trackside resource controller within the preset time, the communication initialization is considered to have been completed normally. If no response is received, check whether the status of the controllable object controller of the current trackside resource controller is normal, and check whether the status flag of the adjacent trackside resource controller has been received. Initialization is completed only when the status of the controllable object controller is normal and the preset status flag conditions are met.

[0011] As a preferred technical solution, the preset status identification conditions include: If the number of communicable object controllers of the current trackside resource controller is equal to the number of controllable object controllers, then the initialization is completed directly; If the number of communicable object controllers of the current trackside resource controller is greater than the number of controllable object controllers, it is necessary to confirm that the status flags of all adjacent trackside resource controllers have been received and that they all indicate the second status value, and then complete the initialization.

[0012] As a preferred technical solution, the communication between trackside resource controllers or between trackside resource controllers and object controllers is triggered communication, and the triggering conditions include: The train runs to the jurisdictional boundary area of ​​two trackside resource controllers, and the status identifier of the adjacent trackside resource controller is the first status value; After powering on, the trackside resource controller actively sends status requests to adjacent trackside resource controllers.

[0013] As a preferred technical solution, when the current trackside resource controller processes messages from all object controllers in its set of communicable object controllers, it only sends control commands or status reply messages to the object controllers in its set of controllable object controllers.

[0014] As a preferred technical solution, the non-controllable object controller in the set of communicable object controllers is configured to: send only the status identifier of its associated trackside resource controller to the associated trackside resource controller, or send the status identifier and the status information of the trackside equipment it manages.

[0015] As a preferred technical solution, the method further includes: Configure a multi-connection field for each object controller to define the maximum number of trackside resource controllers that the object controller is allowed to establish communication with.

[0016] According to a second aspect of the present invention, a system for implementing the object controller dynamic management method is provided, the system comprising: This includes the trackside resource controller and the object controller; The object controller is connected to the trackside equipment and is used to manage the status of the trackside equipment; The trackside resource controller is communicatively connected to the object controller, and has pre-stored configuration information for a set of controllable object controllers and a set of communicable object controllers. It can also obtain the status identifiers of adjacent trackside resource controllers and switch their response modes to messages from different object controllers based on these status identifiers.

[0017] According to a third aspect of the present invention, an electronic device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the program to implement the method described thereon.

[0018] According to a fourth aspect of the present invention, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the method described thereon.

[0019] Compared with the prior art, the present invention has the following advantages: 1. This invention breaks through the limitations of traditional hard-wired connections by pre-configuring a set of controllable object controllers and a set of communicable object controllers, and dynamically adjusting message processing strategies based on the status identifiers of adjacent trackside resource controllers. It realizes flexible communication configuration between trackside resource controllers and object controllers, and can seamlessly take over boundary trackside equipment resources when adjacent trackside resource controllers fail.

[0020] 2. This invention adopts a state-based triggering communication strategy, in which controllers communicate only when necessary, avoiding continuous message interaction, effectively reducing system communication load, and improving overall operating efficiency.

[0021] 3. This invention clarifies the security boundaries of resource management. Even in takeover mode, WRC only controls devices within its own controllable OC set, and only monitors the status of the takeover boundary OC. This mechanism prevents control conflicts and ensures the operational safety of the system.

[0022] 4. This invention sets up a rigorous initialization verification process and quantity constraint rules, combined with the unique design of status identifiers, to ensure the integrity of the status during the system startup phase and the logical consistency during operation, effectively avoiding system failures caused by abnormal configurations or missing statuses. Attached Figure Description

[0023] Figure 1 This is a flowchart of the method of the present invention; Figure 2 This is a system architecture diagram of the present invention; Detailed Implementation

[0024] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0025] Example 1: like Figure 1 As shown, this invention provides a method for dynamic management of object controllers on the trackside resource controller side of vehicle-to-vehicle communication, specifically including: Step S1: Preprocessing Configuration Stage Before the system runs, the logical configuration of each trackside resource controller and its communication range object controller needs to be performed, such as... Figure 1 The system connection diagram shown includes multiple trackside resource controllers (WRCs) (e.g., WRC1, WRC2, WRC3) and multiple object controllers (OCs) (e.g., OC1, OC2, OC3, OC4). Each WRC is configured with two logical sets: Controllable Object Controller Set: Contains all trackside devices (OCs) within its jurisdiction. For example, the controllable OC set of WRC2 is {OC2}. The set of communicable object controllers contains all OCs that need to interact with the WRC in terms of status. This set necessarily includes the aforementioned set of controllable OCs, and may also include OCs that are physically located in adjacent WRCs but are within the jurisdiction boundary and need to be monitored. For example, the set of communicable OCs for WRC2 is {OC1, OC2, OC3}. The configuration must meet a basic rule: the number of OCs in the communicable OC set must be greater than or equal to the number of OCs in the controllable OC set; otherwise, the system will throw an exception during the configuration phase. For an OC, its communication mode needs to be configured. This is defined by a boolean field `multi_con`: if `multi_con = true`, it means that the OC allows communication with multiple (≥1) WRCs, typically used for OCs managing boundary shared devices; if `multi_con = false`, it means that the OC only allows communication with one WRC, typically used for devices entirely within a single WRC. Boundary CPB devices are typically configured with `multi_con = true`.

[0026] Each WRC and a specific boundary OC can generate a state identifier, which has two distinct state values: The first status value is false: This indicates that the WRC to which the WRC belongs is in an available working state and can perform resource management and coordination normally. The second status value, true, indicates that the associated WRC is in an unavailable or faulty state.

[0027] Step S2: Initialization Phase After the WRC is powered on, it enters the initialization phase, which aims to determine its own working mode and set the correct status flag. Its default status flag is the second status value.

[0028] WRC first checks whether the status of all devices in its controllable OC set is reported normally; The WRC attempts to establish communication with all neighboring WRCs and request their status: If a response is received from an adjacent WRC within the preset time, it indicates that the adjacent WRC is in normal working condition. At this time, as long as all controllable OC states of this WRC are normal, this WRC can directly complete the initialization and enter the normal working phase. If no response is received from any adjacent WRC, proceed to the initialization judgment logic based on the status flag: First, check whether all controllable open states in this WRC are normal; Then, a judgment is made based on the pre-configured set relationships: If the number of communicable OCs in this WRC is equal to the number of controllable OCs, it means that this WRC does not need to rely on neighboring boundary devices. Under the premise that the controllable OCs are in normal status, initialization can be completed directly. If the number of communicable OCs in this WRC is greater than the number of controllable OCs, it indicates the existence of a boundary device. It is necessary to monitor the CPB status of all adjacent WRCs through the boundary OCs. Only when this WRC confirms that the CPB status of all adjacent WRCs is the second state value (true), and combined with the normal status of its own controllable OCs, can this WRC safely complete the initialization and prepare to take over the boundary resources.

[0029] Step S3: Normal working phase Once the initialization is complete, the WRC enters the normal operation phase, and its behavior logic is dynamically determined by the CPB state of itself and adjacent WRCs.

[0030] Normal operating mode: When a WRC communicates normally with its neighboring WRCs, it sets its own CPB to the first state value (false), declaring itself available. In this mode, it only processes messages from its controllable OC set, ignoring messages from other OCs in the communicable OC set, as these devices should be managed by their neighboring WRC with a CPB of false. Communication between WRCs uses a trigger-based mechanism, with the main triggering conditions including: 1) a train reaches the jurisdictional boundary between two WRCs, and the CPB of the adjacent WRC is false; 2) when the WRC is powered on and initialized. This greatly reduces the system communication load.

[0031] Step S4: Fault Detection and Takeover Mode Each WRC continuously monitors the CPB of its neighboring WRCs. Once it detects that the CPB of a neighboring WRC has changed to the second state value (true), it determines that the neighbor is unavailable. At this point, the current WRC will immediately begin receiving and processing messages from all OCs in its set of communicable OCs, thereby taking over the boundary equipment under the jurisdiction of the faulty neighbor and ensuring uninterrupted train operation. It is important to note that in takeover mode, although the current WRC processes messages from all OCs, for reasons of clear control and safety, it only sends control commands or status replies to OCs in its own set of controllable OCs. For the boundary OCs that originally belonged to the faulty neighbor, the current WRC only performs status monitoring and necessary data forwarding, without actively sending control commands to prevent command conflicts when the neighbor recovers.

[0032] When a faulty WRC is repaired and re-initialized by power-on, it will proactively request its status from its neighbors. Upon receiving the request, the healthy neighboring WRC will reply with its own status based on the request content. Once communication is restored, the CPB status of both parties will be readjusted according to the communication status, and the system will automatically return to the normal responsibility division mode.

[0033] The method of the present invention pre-configures a set of controllable and communicable object controllers for the controller and obtains the status identifiers of adjacent controllers in real time. When an adjacent controller is available, the controller only processes messages within its controllable set, while when an adjacent controller is unavailable, it takes over and processes messages from its entire communicable set, thereby realizing dynamic and fault-tolerant resource management.

[0034] Example 2: like Figure 2 As shown, the present invention provides a system for implementing the above method, which mainly includes two types of devices: a trackside resource controller and an object controller. Object Controller: Directly connected to trackside equipment such as switches, signals, and point-of-use (CPB) buttons, responsible for collecting equipment status, receiving control commands, and driving equipment actions. Each OC has a unique identifier and can be configured in single-connection (multi_con=false) or multi-connection (multi_con=true) mode.

[0035] Trackside Resource Controller (WRC): This is the core management unit of the system. Each WRC pre-stores information on a set of controllable OCs and a set of communicable OCs. A WRC establishes communication connections with one or more OCs and can interact with adjacent WRCs, including button status information. The control logic running within a WRC is configured to execute all the method steps of Embodiment 1, specifically including: The aforementioned safety initialization procedure is executed upon power-up; During runtime, the message processing strategy is dynamically switched based on the CPB status obtained from the adjacent WRC. Based on its own working status and communication with neighbors, it sets and broadcasts its own CPB status through the associated OC. When a neighbor failure is detected, monitoring of the boundary OC is automatically taken over.

[0036] The trackside resource controller of this invention dynamically switches its response mode to messages from different object controllers based on pre-configured set information and status identifiers obtained from adjacent controllers; the object controller is responsible for connecting and managing trackside equipment, and the two work together to achieve flexible resource allocation and seamless fault takeover without the need for fixed hardwire connections.

[0037] Example 3: The electronic device of this invention includes a central processing unit (CPU), which can perform various appropriate actions and processes according to computer program instructions stored in read-only memory (ROM) or loaded from a storage unit into random access memory (RAM). The RAM may also store various programs and data required for device operation. The CPU, ROM, and RAM are interconnected via a bus. Input / output (I / O) interfaces are also connected to the bus.

[0038] Multiple components in the device are connected to the I / O interface, including: input units such as keyboards and mice; output units such as various types of displays and speakers; storage units such as disks and optical discs; and communication units such as network interface cards (NICs), modems, and wireless transceivers. The communication unit allows the device to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0039] The processing unit executes the various methods and processes described above, such as methods S1 to S4. For example, in some embodiments, methods S1 to S4 may be implemented as computer software programs tangibly contained in a machine-readable medium, such as a storage unit. In some embodiments, part or all of the computer program may be loaded and / or installed on the device via ROM and / or a communication unit. When the computer program is loaded into RAM and executed by the CPU, one or more steps of methods S1 to S4 described above may be performed. Alternatively, in other embodiments, the CPU may be configured to execute methods S1 to S4 by any other suitable means (e.g., by means of firmware).

[0040] The functions described above in this document can be performed, at least in part, by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: Field Programmable Gate Arrays (FPGAs), Application-Specific Integrated Circuits (ASICs), Application Standard Products (ASSPs), System-on-Chip (SoCs), Complex Programmable Logic Devices (CPLDs), and so on.

[0041] The program code used to implement the methods of the present invention can be written in any combination of one or more programming languages. This program code can be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing device, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code can be executed entirely on the machine, partially on the machine, as a standalone software package partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0042] In the context of this invention, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media can include, but are not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0043] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A dynamic management method for an object controller, the method being used in a train control system for vehicle-to-vehicle communication, the train control system including a trackside resource controller, characterized in that, The trackside resource controller is pre-configured with a set of controllable object controllers and a set of communicable object controllers, wherein the set of communicable object controllers includes the set of controllable object controllers. The method includes: Obtain the status identifier of the adjacent trackside resource controller, the status identifier being used to indicate whether the corresponding trackside resource controller is in an available working state; The current trackside resource controller dynamically adjusts its message processing strategy for each object controller it communicates with based on the status flags. If the status indicator indicates that the adjacent trackside resource controller is available, the current trackside resource controller only processes messages from the set of controllable object controllers; If the status indicator indicates that the adjacent trackside resource controller is unavailable, the current trackside resource controller processes messages from all object controllers in the set of communicable object controllers. Among them, the controllable object controller is the object controller whose physical location of the equipment belongs to the current trackside resource controller; The communicable object controller is all the object controllers that need to communicate with the current trackside resource controller. Furthermore, the number of object controllers in the set of communicable object controllers is greater than or equal to the number of object controllers in the set of controllable object controllers; The status identifier has two status values: a first status value, which indicates that the trackside resource controller to which it belongs is in an available state; The second status value is used to indicate that the trackside resource controller to which it belongs is in an unavailable or faulty state; The method also includes an initialization phase: After the trackside resource controller is powered on, it attempts to establish communication with the adjacent trackside resource controller. If a response is received from the adjacent trackside resource controller within the preset time, the communication initialization is considered to have been completed normally. If no response is received, check whether the status of the controllable object controller of the current trackside resource controller is normal, and check whether the status flag of the adjacent trackside resource controller has been received. Initialization is completed only when the status of the controllable object controller is normal and the preset status flag conditions are met. The preset status indicator conditions include: If the number of communicable object controllers of the current trackside resource controller is equal to the number of controllable object controllers, then the initialization is completed directly; If the number of communicable object controllers of the current trackside resource controller is greater than the number of controllable object controllers, it is necessary to confirm that the status flags of all adjacent trackside resource controllers have been received and that they all indicate the second status value, and then complete the initialization. The communication between trackside resource controllers or between a trackside resource controller and an object controller is triggered communication, and the triggering conditions include: The train runs to the jurisdictional boundary area of ​​two trackside resource controllers, and the status identifier of the adjacent trackside resource controller is the first status value; After powering on, the trackside resource controller actively sends status requests to adjacent trackside resource controllers.

2. The object controller dynamic management method according to claim 1, characterized in that, When the current trackside resource controller processes messages from all object controllers in its set of communicable object controllers, it only sends control commands or status response messages to the object controllers in its set of controllable object controllers.

3. The object controller dynamic management method according to claim 1, characterized in that, The non-controllable object controller in the set of communicable object controllers is configured to send only the status identifier of its associated trackside resource controller to the associated trackside resource controller, or send the status identifier and the status information of the trackside equipment it manages.

4. The object controller dynamic management method according to claim 1, characterized in that, The method further includes: Configure a multi-connection field for each object controller to define the maximum number of trackside resource controllers that the object controller is allowed to establish communication with.

5. A system for implementing the object controller dynamic management method according to any one of claims 1-4, characterized in that, This includes the trackside resource controller and the object controller; The object controller is connected to the trackside equipment and is used to manage the status of the trackside equipment; The trackside resource controller is communicatively connected to the object controller, and has pre-stored configuration information for a set of controllable object controllers and a set of communicable object controllers. It can also obtain the status identifiers of adjacent trackside resource controllers and switch their response modes to messages from different object controllers based on these status identifiers.

6. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the program, it implements the method as described in any one of claims 1 to 4.

7. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1 to 4.

Images