Unmanned torpedo car control program online updating method and system

Abstract

The invention provides an unmanned torpedo vehicle control program online updating method and system, and the method comprises the steps: 1, deploying a first vehicle control program instance and a second vehicle control program instance, and carrying out the parallel operation of a first vehicle control program instance and a second vehicle control program instance, and forming a dual-control architecture DDC; 2, storing the vehicle control state information in a unified manner through an intermediate database; 3, initiating a permission switching request based on the vehicle number granularity, and migrating the control permission of the target vehicle from the current master control instance to another vehicle control program instance; 4, in the permission switching process, the new master control instance recovers the scheduling context by reading the intermediate database, and the uncompleted instruction continues to be executed. By means of a double-version vehicle control structure, database state keeping, manual permission switching and the like, the updating process of a vehicle control program is completed on the premise of not interrupting operation, the transportation task continuity and program maintainability are guaranteed, and the method is suitable for an industrial automatic control system with the high stability requirement.

Description

Technical Field

[0001] This invention relates to the field of molten iron transportation technology in the steel manufacturing industry, specifically to an online update method and system for the control program of an unmanned mixed-rail vehicle. Background Technology

[0002] SCADA (Supervisory Control and Data Acquisition) system is a computer-based distributed control system (DCS) and power automation monitoring system. It has a wide range of applications, including data acquisition and monitoring control, and process control in industries such as power, metallurgy, petroleum, chemical, gas, and railway.

[0003] It is understood that some steel companies employ a centralized vehicle control architecture in molten iron transportation, coordinating the operation of multiple molten iron ladle cars through a unified control program. When updating the control program, this approach typically requires pausing all scheduling tasks and manually replacing the program. This method may have the following limitations in actual operation: if the update fails, all molten iron ladle cars will be unable to receive scheduling instructions, potentially interfering with the normal tapping rhythm of the blast furnace if this occurs during critical periods. Furthermore, if the control program fails to update successfully, it may force the blast furnace to reduce production or temporarily shut down to ensure safety. Simultaneously, because all vehicles must stop and perform the program replacement during the update process, the scheduling status is difficult to maintain continuity, especially in scenarios with multiple cars operating in parallel, potentially disrupting the scheduling rhythm of molten iron ladle cars and increasing the difficulty of manually restoring the consistency and stability of the system. In contrast, if individual vehicles can be flexibly switched to the new program version without interrupting the overall system operation, the stability of the update process and the flexibility of the scheduling system will be significantly improved.

[0004] Patent document (application number: CN202210705417.2) discloses a vehicle-to-ground information interaction method and system for an unmanned intelligent mixed-train vehicle in a steel plant area. This includes interacting with the vehicle's onboard PLC, route module, and vehicle-to-ground module to obtain communication information. Based on this communication information, the unmanned intelligent mixed-train vehicle in the steel plant area performs wireless communication status judgment, vehicle movement condition judgment, arrival status judgment, driving control, cover opening / closing control, automatic charging control, and intelligent mixed-train vehicle power consumption statistics, and performs emergency braking when necessary. However, this patent adopts a single-control program operation architecture, mainly completing the vehicle control logic through real-time interaction between the onboard PLC and the ground module. It does not involve the lifecycle management of the vehicle control program, and its control logic is performed on a system-wide basis, lacking the ability to select program versions and roll back status at the vehicle level.

[0005] Patent application CN116382725A discloses a method and system for updating and monitoring the status of an unmanned logistics vehicle system, including: a manager uploading the vehicle-side system software to be updated to a server; the server sending a receipt to the manager after receiving the software and determining whether to perform a first update operation; the server detecting the vehicle software version flag within the area and receiving the user's receipt information, determining whether to perform a second update operation, and obtaining the vehicle status receipt signal. However, this patent cannot completely solve the existing technical problems, nor can it meet the needs of this invention. Summary of the Invention

[0006] To address the shortcomings of existing technologies, the purpose of this invention is to provide a method and system for online updating of the control program for unmanned hybrid rail vehicles.

[0007] The online update method for the control program of an unmanned hybrid rail vehicle provided by the present invention includes: Step 1: Deploy and run the first and second vehicle control program instances in parallel to form a dual-control architecture (DDC); Step 2: Store vehicle control status information in a unified manner through an intermediate database, including scheduling plan, task progress, alarm status, real-time vehicle operating status, route calculation results, and control permission mapping; Step 3: Initiate a permission switching request based on the vehicle number granularity to migrate the control permission of the target vehicle from the current master control instance to another vehicle control program instance; Step 4: During the permission switch, the new master instance restores the scheduling context by reading the intermediate database and continues to execute unfinished instructions.

[0008] Preferably, both the first vehicle control program instance and the second vehicle control program instance independently execute the following services: Driving information calculation service: executed periodically, including: reading configuration information from the intermediate database and initializing parameters, synchronously obtaining real-time vehicle information from the intermediate database and SCADA system, verifying the validity of vehicle status, and performing route calculation and writing the results to the intermediate database; Driving information delivery service: executed periodically, including: reading configuration information from the intermediate database and initializing parameters, synchronously obtaining real-time vehicle information from the intermediate database and SCADA system, skipping instructions for emergency stop vehicles, preprocessing vehicle information to be delivered, and issuing vehicle delivery instructions to the vehicle control terminal.

[0009] Preferably, the dual-control architecture adopts process-level isolation, with the two instances sharing the same intermediate database and SCADA data source. The active master instance has database read and write permissions, while the inactive standby instance only has database read-only permissions. The master instance is responsible for writing the calculation results and status into the database, while the standby instance maintains runtime context synchronization by periodically reading the database and SCADA data.

[0010] Preferably, the permission switching is performed on a vehicle-by-vehicle basis, specifically including: initiating a switching request and specifying the target vehicle number; the master instance checks whether the vehicle has an instruction in execution; if there is no instruction in execution, the control permission field of the vehicle is updated to the backup instance master in the database, and a switching log is recorded; the backup instance takes over the vehicle control after periodically reading and detecting permission changes; if the target vehicle has an instruction in execution, the permission switching is delayed until the instruction is completed.

[0011] Preferably, the method further includes a fault rollback mechanism: when a calculation error, abnormal command issuance, or abnormal resource usage occurs in the new vehicle control program instance, a rollback command is triggered to switch the target vehicle control permission field from the new instance back to the old instance, and the old instance restores vehicle control by reading the database; All driving commands and their execution status are persistently stored in an intermediate database, and permission switching only modifies the control permission field.

[0012] The online update system for the control program of the unmanned hybrid rail vehicle provided by the present invention includes: Module M1: Deploys and runs the first and second vehicle control program instances in parallel, forming a dual-control architecture (DDC). Module M2: Stores vehicle control status information in a unified manner through an intermediate database, including scheduling plans, task progress, alarm status, real-time vehicle operating status, route calculation results, and control permission mapping; Module M3: Initiates a permission switching request based on the vehicle number granularity, migrating the control permission of the target vehicle from the current master control instance to another vehicle control program instance; Module M4: During the permission switch, the new master instance restores the scheduling context by reading the intermediate database and continues to execute unfinished instructions.

[0013] Preferably, both the first vehicle control program instance and the second vehicle control program instance independently execute the following services: Driving information calculation service: executed periodically, including: reading configuration information from the intermediate database and initializing parameters, synchronously obtaining real-time vehicle information from the intermediate database and SCADA system, verifying the validity of vehicle status, and performing route calculation and writing the results to the intermediate database; Driving information delivery service: executed periodically, including: reading configuration information from the intermediate database and initializing parameters, synchronously obtaining real-time vehicle information from the intermediate database and SCADA system, skipping instructions for emergency stop vehicles, preprocessing vehicle information to be delivered, and issuing vehicle delivery instructions to the vehicle control terminal.

[0014] Preferably, the dual-control architecture adopts process-level isolation, with the two instances sharing the same intermediate database and SCADA data source. The active master instance has database read and write permissions, while the inactive standby instance only has database read-only permissions. The master instance is responsible for writing the calculation results and status into the database, while the standby instance maintains runtime context synchronization by periodically reading the database and SCADA data.

[0015] Preferably, the permission switching is performed on a vehicle-by-vehicle basis, specifically including: initiating a switching request and specifying the target vehicle number; the master instance checks whether the vehicle has an instruction in execution; if there is no instruction in execution, the control permission field of the vehicle is updated to the backup instance master in the database, and a switching log is recorded; the backup instance takes over the vehicle control after periodically reading and detecting permission changes; if the target vehicle has an instruction in execution, the permission switching is delayed until the instruction is completed.

[0016] Preferably, the method further includes a fault rollback mechanism: when a calculation error, abnormal command issuance, or abnormal resource usage occurs in the new vehicle control program instance, a rollback command is triggered to switch the target vehicle control permission field from the new instance back to the old instance, and the old instance restores vehicle control by reading the database; All driving commands and their execution status are persistently stored in an intermediate database, and permission switching only modifies the control permission field.

[0017] Compared with the prior art, the present invention has the following beneficial effects: (1) The present invention aims to propose an online update method for the control program of a hybrid railway car without interruption of operation, so as to ensure that the program can achieve a smooth transition through the switching of master control authority during the update process. The update process is controllable and rollback is possible, which meets the requirements of high availability and high stability of unmanned driving. (2) This invention effectively solves the problems of interruption, failure and state loss caused by updating the vehicle control program in the unmanned driving mission of the mixed-rail vehicle. Through the permission switching and state saving mechanism, the vehicle control program can be hot-updated without interruption. It has the promotion value of being widely applicable to high availability scenarios, and is especially suitable for industrial production occasions with strong continuity such as steel smelting and rail transportation. Attached Figure Description

[0018] Other features, objects, and advantages of the present invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 The DICDP swimlane diagram illustrates the operation flow of a single-node vehicle control program. Figure 2 The DDC swimlane diagram illustrates the operational logic of the vehicle control program under the dual-control structure. Figure 3 This is a diagram of the DDC Virtual Input module, showing the access control and version configuration interfaces.

[0019] The diagram shows: DDC is a dual-control architecture, Database is a database, SCADA Tag is a monitoring point tag, DIC is a driving information calculation service, DID is a driving information distribution service, RDM is a real-time data manager, SE is a sampling unit, DICDP is a single-node vehicle control program, Config File is a configuration file, Database Table is a data table, DDC Virtual Input is a DDC virtual input, and DDC Virtual Output is a DDC virtual output. Detailed Implementation

[0020] The present invention will now be described in detail with reference to specific embodiments. These embodiments will help those skilled in the art to further understand the present invention, but do not limit the invention in any way. It should be noted that those skilled in the art can make several changes and improvements without departing from the concept of the present invention. These all fall within the protection scope of the present invention.

[0021] Example 1 This invention provides a method for online updating of the control program of an unmanned hybrid rail vehicle, including: 1. Dual-Version Vehicle Control Program Architecture: Two parallel vehicle control program instances are deployed in the vehicle control system, executing the "Driving Information Calculation Service" and the "Driving Information Dispatch Service" respectively, collectively referred to as the "Driving Information Calculation and Dispatch Pattern (DICDP)," as shown in the attached diagram. Figure 1 As shown. Two DICDP instances form a dual-control architecture, "Dual DICDP Cluster (DDC)," which supports switching between primary and backup control logic without interrupting operation. See the appendix for details of the vehicle control process. Figure 2 Regarding the specific implementation process of the "driving information calculation service": To ensure that the calculation results of driving information are consistent with the real-time status of the system, this service is executed periodically, and the process is as follows: a. Initialization: Read configuration information from the intermediate database to complete the initialization of service parameters and runtime environment; b. Data acquisition: Real-time information of each vehicle is obtained synchronously from the intermediate database and the SCADA system; c. Status check: Check the acquired vehicle operating status to confirm that the key information is valid and meets the calculation conditions; d. Route calculation and output: Under the premise that the status check passes, the route information is calculated and the calculation result is written to the intermediate database for subsequent modules to call; The route information calculation process is as follows: under the condition of satisfying the status check, a structured route instruction is generated and persistently stored based on real-time vehicle data and preset rules.

[0022] Regarding the specific implementation process of the "Driving Information Distribution Service": To ensure the security and continuity of the distributed instructions, this service is executed periodically, and the process is as follows: a. Initialization: Read configuration information from the intermediate database to complete the initialization of service parameters and runtime environment; b. Data acquisition: Real-time information of each vehicle is obtained synchronously from the intermediate database and the SCADA system; c. Emergency Stop Handling: Appropriate handling shall be carried out for vehicles in an emergency stop state, and no departure command shall be generated or issued in this cycle; d. Driving information preprocessing: Preprocessing the driving information to be issued; e. Command issuance: The pre-processed driving information is sent to the control terminal of the corresponding vehicle for execution.

[0023] 2. Vehicle Control Status Maintenance Mechanism: All vehicle control status information (such as scheduling plans, task progress, alarm status, etc.) is maintained uniformly by an intermediate database. When switching vehicle control programs, the new vehicle control program restores the scheduling context by reading the database content, thus achieving task status continuity. The DICDP dual instance, consisting of the "Driving Information Calculation Service" and the "Driving Information Distribution Service," adopts process-level isolation at the operating system level, and they do not share memory space. The two instances share the same intermediate database and SCADA data source, where the active (primary) instance has read and write permissions, while the inactive (backup) instance only has read-only permissions, thus forming a "single write, multiple read" isolation strategy. Cross-process coupling is avoided by separating the "data plane (database / SCADA) - control plane (control permission fields)." The key data requiring real-time mirroring between the two instances includes: the real-time operating status of each vehicle (location, speed, etc.), scheduling plans and task progress, route calculation results and proposed vehicle dispatch information, alarm / event status, and control permission mapping between vehicles and instances. Synchronization is achieved by both instances periodically reading data from the database and SCADA system, determining increments based on timestamp / version fields. The primary instance is responsible for writing results and status, while the standby instance follows in read-only mode to maintain a consistent operating context with the primary instance. Primary / standby failover is performed on a vehicle-by-vehicle basis: After a manual failover request is initiated and a vehicle is specified, the primary instance first determines the current command execution status of the vehicle. If completed, it immediately updates the vehicle's control permissions in the database to "standby instance primary control" and records the failover log. Once the standby instance detects a permission change through periodic reads, it takes over the vehicle, begins calculating and / or distributing driving information, and the failover is complete. If there are ongoing commands, it waits for the command to complete before updating permissions and taking over. In the case where the specified vehicle has no ongoing commands, the time from permission update to new primary takeover is approximately 500ms to 1 second. To ensure that no instructions are lost during the handover process, this system persistently stores all driving instructions and their statuses in the database. The handover only modifies the control permission fields without changing the contents of the instruction table. After the new master takes over, it directly continues the unfinished instructions and related statuses from the database. Moreover, the "master write, backup read" permission model naturally avoids concurrent writes and race conditions, eliminating the risk of instruction loss and duplicate issuance from a mechanism perspective. At the same time, the handover does not affect the operation of other vehicles.

[0024] 3. Online Program Update Access Control: The system supports access control based on vehicle ID, allowing individual vehicles to be switched to the updated vehicle control program. All switching information, current vehicle control version status, etc., are recorded and managed through the "DDC VirtualInput" module. See the appendix for the specific structure. Figure 3In the "Dual DICDP Cluster (DDC)" architecture, the current master control program version information used by each vehicle is centrally managed and updated through a database. The system maintains a record of control permissions and version status for each vehicle in the database, serving as the basis for determining the ownership of its master control instance. When a manual permission switching command is initiated, the master instance first queries the database to check the current execution status of the target vehicle, ensuring it is in a "no commands being executed" state before proceeding. Then, it updates the vehicle's control permission field in the database, pointing it to the new vehicle control program version, completing the transfer of control. The entire version switching process strictly relies on the updating of the database permission field and the program's own permission judgment logic, with clear pre-judgment of status, ensuring that the switching only occurs within a safe window, thus preventing accidental operations. Furthermore, since vehicle control commands and task status are persistently stored in the database, the switching process does not involve state copying or migration, avoiding the uncertainty of data synchronization and enhancing the controllability and rollback capability of the operation. The current system supports fine-grained control at the vehicle level, allowing independent switching of the vehicle control program version for any single vehicle.

[0025] 4. Vehicle Control Program Hot Update Process: Different vehicle control program versions coexist within the system, with manual initiation of permission switching operations. Currently, permission switching in the system is initiated manually, primarily based on the following two considerations: Firstly, in the initial deployment phase of a new vehicle control program version, its stability is still under observation, and compared to older versions that have been validated over a long period, there may be potential uncertainties. In this context, if large-scale permission switching is performed through automated mechanisms, it may spread to multiple vehicles before the problem is fully exposed, amplifying the scope of risk impact. Secondly, the current architecture emphasizes "safety and controllability, vehicle-by-vehicle switching." Manual initiation allows technicians to flexibly decide whether to switch and the timing of the switch based on on-site operating conditions, individual vehicle status, and version testing results. In practical applications, permission switching has been abstracted through a database interface, providing a good foundation for automated expansion. In the future, provided the new version is running stably and the risk model is controllable, a semi-automated or condition-triggered switching scheme can be introduced in conjunction with a rule engine or scheduling strategy to achieve intelligent assisted decision-making under manual confirmation, thereby ensuring both security and scheduling efficiency. The system completes the program switching vehicle-by-vehicle according to the configuration, without requiring a unified shutdown. The system features a fault rollback mechanism that allows manual switching back to the old program version to ensure operational safety. This mechanism safeguards system security and stability when the new version of the vehicle control program malfunctions or deviates from expected operating conditions. The conditions for triggering a rollback primarily include unexpected calculation errors, abnormal command issuance, response timeouts, abnormal resource usage, or discrepancies between scheduling execution results and predetermined logic during program execution. Once manually confirmed as a program version-related issue, a rollback operation can be immediately performed on the designated vehicle. The rollback process involves manually switching control of the target vehicle from the current new program instance back to the old program instance via the permission switching interface. Once the old program instance detects the restored permissions, it resumes control of the vehicle's scheduling and command issuance processes. Since commands and status information are stored uniformly in the database, the rollback process does not involve state migration; it only changes control permission fields, ensuring that faulty vehicles can quickly return to the control of a verified and stable program version, thereby reducing the risk of anomaly propagation and improving system fault tolerance. Currently, this mechanism is manually triggered; however, an automatic rollback strategy can be explored in conjunction with the anomaly detection module in the future.

[0026] Based on actual test data, the traditional shutdown update method, from initiating a vehicle stop command, waiting for all vehicles to enter a stationary state, executing program replacement, to the system resuming normal scheduling operation, takes an average of about 1 hour. During this period, the system cannot issue any scheduling commands, completely interrupting the production process. In contrast, the solution described in this invention achieves online program updates through vehicle-by-vehicle permission switching without interrupting system operation, completely eliminating the 1-hour downtime window and significantly improving scheduling continuity and the stability of blast furnace tapping rhythm. Regarding the impact of update failure, if the traditional solution fails to replace the program, all vehicles will stop receiving scheduling commands, affecting all vehicles in the system. However, in the implementation scenario of this invention, which includes 50 mixed-iron vehicles, update failure only affects the single vehicle that has been switched, while the operation of other vehicles is unaffected, reducing the impact by about 50 times. Furthermore, due to the buffer adjustment mechanism between vehicle scheduling, the actual impact is further reduced. Regarding the time consumed by switching or rolling back operations, if the target vehicle is not currently executing commands, the time required for permission switching is approximately 500 milliseconds to 1 second, and the system can complete takeover within milliseconds. The resource overhead of running a dual-controller program instance is relatively controllable. Taking the current deployment version as an example, it occupies an additional 22MB of memory, and the CPU utilization rate is kept below 1%. The overall system resource consumption is kept within an acceptable range.

[0027] Specifically, this invention provides an online update method for the vehicle control program of an unmanned hybrid rail vehicle, comprising: vehicle control program A and vehicle control program B are deployed on the same device or redundant platform; during the update process, the vehicle master control authority is transferred by manually switching permissions; the vehicle control status is stored in an external database, and after the update, it is read by the new program to continue executing the original task. The vehicle control status includes the scheduling plan, the vehicle's current location, task execution flags, alarm status, etc. The permission switching process includes version verification, status synchronization confirmation, manual command execution, and switch feedback confirmation. The system runs continuously during the update process, the vehicle task is not interrupted, and it has log recording capabilities to support fault tracing. The system has a manual rollback function in abnormal situations to ensure that the original vehicle control program can be switched back and the status restored if the update fails.

[0028] Example 2 The present invention also provides an online update system for the control program of an unmanned hybrid train. The online update system for the control program of an unmanned hybrid train can be implemented by executing the process steps of the online update method for the control program of an unmanned hybrid train. That is, those skilled in the art can understand the online update method for the control program of an unmanned hybrid train as a preferred embodiment of the online update system for the control program of an unmanned hybrid train.

[0029] The system includes: Module M1: deploying and running a first vehicle control program instance and a second vehicle control program instance in parallel, forming a dual-control architecture (DDC); Module M2: uniformly storing vehicle control status information through an intermediate database, including scheduling plans, task progress, alarm status, real-time vehicle operating status, route calculation results, and control permission mapping; Module M3: initiating a permission switching request based on the vehicle number granularity, migrating the control permission of the target vehicle from the current master control instance to another vehicle control program instance; Module M4: during the permission switching process, the new master control instance restores the scheduling context by reading the intermediate database and continues to execute unfinished instructions.

[0030] The first vehicle control program instance and the second vehicle control program instance each independently execute the following services: Driving information calculation service: executed periodically, including: reading configuration information from the intermediate database and initializing parameters, synchronously obtaining real-time vehicle information from the intermediate database and SCADA system, verifying the validity of vehicle status, and performing route calculation and writing the results to the intermediate database; Driving information delivery service: executed periodically, including: reading configuration information from the intermediate database and initializing parameters, synchronously obtaining real-time vehicle information from the intermediate database and SCADA system, skipping instructions for emergency stop vehicles, preprocessing vehicle information to be delivered, and issuing vehicle delivery instructions to the vehicle control terminal.

[0031] The dual-control architecture adopts process-level isolation, with the two instances sharing the same intermediate database and SCADA data source. The active primary control instance has read and write permissions to the database, while the inactive standby instance only has read-only permissions. The primary instance is responsible for writing the calculation results and status to the database, while the standby instance maintains runtime context synchronization by periodically reading the database and SCADA data.

[0032] The permission switching is performed on a vehicle-by-vehicle basis, specifically including: initiating a switching request and specifying the target vehicle number; the master instance checks whether there is an instruction being executed for the vehicle; if there is no instruction being executed, the control permission field of the vehicle is updated to the master of the backup instance in the database, and a switching log is recorded; the backup instance takes over the control of the vehicle after periodically reading and detecting permission changes; if there is an instruction being executed for the target vehicle, the permission switching is delayed until the instruction is completed.

[0033] The method also includes a fault rollback mechanism: when a new vehicle control program instance has a calculation error, abnormal command issuance, or abnormal resource usage, a rollback command is triggered to switch the target vehicle control permission field from the new instance back to the old instance, and the old instance restores vehicle control by reading the database. All driving commands and their execution status are persistently stored in an intermediate database, and permission switching only modifies the control permission field.

[0034] Those skilled in the art will understand that, in addition to implementing the system, apparatus, and their modules provided by this invention in purely computer-readable program code, the same program can be implemented in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers by logically programming the method steps. Therefore, the system, apparatus, and their modules provided by this invention can be considered a hardware component, and the modules included therein for implementing various programs can also be considered structures within the hardware component; alternatively, modules for implementing various functions can be considered both software programs implementing the method and structures within the hardware component.

[0035] Specific embodiments of the present invention have been described above. It should be understood that the present invention is not limited to the specific embodiments described above, and those skilled in the art can make various changes or modifications within the scope of the claims, which do not affect the essence of the present invention. Unless otherwise specified, the embodiments and features described in this application can be arbitrarily combined with each other.

Claims

1. An unmanned iron mixer vehicle control program online updating method, characterized in that, Comprising: Step 1: Deploy and run the first and second train control program instances in parallel to form a double control architecture DDC; Step 2: Store train control state information including dispatch plan, task progress, alarm state, vehicle real-time running state, route calculation result and control authority mapping in the intermediate database uniformly; Step 3: Initiate authority switching request based on vehicle number granularity, migrate the control authority of the target vehicle from the current master instance to another train control program instance; Step 4: During the authority switching process, the new master instance recovers the dispatch context by reading the intermediate database and continues to execute the unfinished instructions.

2. The method according to claim 1, wherein, The first and second train control program instances both independently execute the following services: Train information calculation service: executed periodically, including reading configuration information from the intermediate database and initializing parameters, synchronously obtaining vehicle real-time information from the intermediate database and the SCADA system, verifying vehicle state validity, and performing route calculation and writing the result to the intermediate database; Train information issuing service: executed periodically, including reading configuration information from the intermediate database and initializing parameters, synchronously obtaining vehicle real-time information from the intermediate database and the SCADA system, skipping instruction issuing for emergency stop vehicles, preprocessing proposed train information, and issuing train instructions to the vehicle control end.

3. The method according to claim 1, wherein, The double control architecture adopts process-level isolation, and the two instances share the same intermediate database and SCADA data source, wherein: the active master instance has database read-write authority, the inactive standby instance only has database read-only authority, the master instance is responsible for writing calculation results and states to the database, and the standby instance maintains running context synchronization by periodically reading the database and SCADA data.

4. The method according to claim 1, wherein, The authority switching is executed on a vehicle-by-vehicle basis, specifically including: initiating a switching request and specifying a target vehicle number, the master instance checks whether there are instructions being executed for the vehicle, if there are no instructions being executed, the vehicle control authority field is updated to the standby instance master in the database, and the switching log is recorded, the standby instance takes over the vehicle control right by periodically reading after detecting the authority change, if the target vehicle has instructions being executed, the authority switching is delayed until the instructions are completed.

5. The method according to claim 1, wherein, The method further includes a fault rollback mechanism: when the new train control program instance has calculation errors, instruction issuing abnormalities or resource occupation abnormalities, trigger the rollback instruction to switch the target vehicle control authority field from the new instance back to the old instance, and the old instance recovers the vehicle control right by reading the database; All train instructions and their execution states are persistently stored in the intermediate database, and the authority switching only modifies the control authority field.

6. An unmanned iron mixer vehicle control program online updating system, characterized in that, Comprising: Module M1: Deploy and run the first and second train control program instances in parallel to form a double control architecture DDC; Module M2: Store train control state information including dispatch plan, task progress, alarm state, vehicle real-time running state, route calculation result and control authority mapping in the intermediate database uniformly; Module M3: Initiate authority switching request based on vehicle number granularity, migrate the control authority of the target vehicle from the current master instance to another train control program instance; Module M4: In the process of authority switching, the new master instance restores the dispatching context by reading the intermediate database and continues to execute the unfinished instructions.

7. The unmanned iron mixer vehicle control program online updating system according to claim 6, characterized in that, The first and second vehicle control program instances both independently execute the following services: Train operation information calculation service: executed periodically, including reading configuration information from the intermediate database and initializing parameters, synchronously obtaining real-time vehicle information from the intermediate database and the SCADA system, verifying the validity of the vehicle state, performing route calculation and writing the results to the intermediate database; Train operation information issuing service: executed periodically, including reading configuration information from the intermediate database and initializing parameters, synchronously obtaining real-time vehicle information from the intermediate database and the SCADA system, skipping the instruction for emergency stop vehicles, preprocessing the train operation information to be issued, and issuing the train operation instruction to the vehicle control terminal.

8. The online updating system for the unmanned mixed iron car control program according to claim 6, characterized in that, The dual-control architecture adopts process-level isolation, and the two instances share the same intermediate database and SCADA data source, where the active master instance has read and write permissions for the database, and the inactive standby instance only has read-only permissions for the database. The master instance is responsible for writing the calculation results and state to the database, and the standby instance keeps the running context synchronized by periodically reading the database and SCADA data.

9. The online updating system for the unmanned mixed iron car control program according to claim 6, characterized in that, The authority switching is performed on a per-vehicle basis, specifically including initiating a switching request and specifying the target vehicle number, the master instance checking whether there are instructions in execution for the vehicle, if there are no instructions in execution, updating the vehicle control authority field in the database to the standby instance master control, and recording the switching log, the standby instance taking over the vehicle control right by periodically reading after detecting the authority change, if there are instructions in execution for the target vehicle, delaying the authority switching until the instructions are completed.

10. The online updating system for the unmanned mixed iron car control program according to claim 6, characterized in that, The method further includes a fault rollback mechanism: when the new vehicle control program instance has calculation errors, instruction issuing abnormalities, or resource occupation abnormalities, a rollback instruction is triggered to switch the target vehicle control authority field back to the old instance, and the old instance restores the vehicle control right by reading the database; All train operation instructions and their execution status are persistently stored in the intermediate database, and the authority switching only modifies the control authority field.

Images