Disaster recovery switching method and device of vehicle management system and storage medium

Abstract

The invention discloses a disaster recovery switching method and device for a vehicle management system and a storage medium, and relates to the technical field of digital information transmission, and the disaster recovery switching method for the vehicle management system comprises the steps: responding to a region fault alarm triggered for a fault region, executing a main and standby database switching action based on the databases of the fault area and the to-be-transferred area; in response to operation and maintenance input for the fault area, updating a target protocol address and a target area address, corresponding to a to-be-transferred area, of each vehicle type on the basis of the to-be-transferred area indicated by the operation and maintenance input; and controlling the cluster management platform of the fault area to disconnect the service connection with each vehicle type based on the fault protocol address. The technical effect of improving the fault service recovery efficiency of the server area can be achieved.

Description

Technical Field

[0001] This application relates to the field of digital information transmission technology, and in particular to a disaster recovery switching method, device and storage medium for a vehicle management system. Background Technology

[0002] Currently, connected vehicle services are deployed through local data centers to process status data and remote control commands uploaded from vehicles. However, in the event of a regional fault, the defect can be directly transmitted to the vehicles, causing all vehicles in the area to lose network access and rendering functions such as navigation and collision warnings ineffective.

[0003] To address this, the relevant technologies employ a dual-active / disaster recovery deployment within the same city, relying on redundant resources within the region to ensure the continuity of communication between vehicles and the network. While the dual-active deployment within the same city has backup resources and can cope with single data center failures, in the event of a city-wide disaster, the RTO (Recovery Time Objective) and RPO (Recovery Point Objective) of business data become excessively long, leading to prolonged service interruptions. Summary of the Invention

[0004] The main purpose of this application is to provide a disaster recovery switching method, device and storage medium for a vehicle management system, which aims to solve the technical problem of long business service recovery time when city-level server failures occur.

[0005] To achieve the above objectives, this application provides a disaster recovery switchover method for a vehicle management system, applied to the server side. The disaster recovery switchover method for the vehicle management system includes: In response to a regional fault alarm triggered for a faulty area, a primary / standby database switchover is performed based on the databases of the faulty area and the area to be switched to. In response to the maintenance input for the fault area, update the target protocol address and target area address of each vehicle model corresponding to the area to be transferred; The cluster management platform controlling the fault area disconnects the service connection between the vehicle model and the fault protocol address.

[0006] In one embodiment, after the step of the cluster management platform controlling the fault area disconnecting the service connection with each vehicle model based on the fault protocol address, the following steps are included: In response to an address retrieval request initiated by the vehicle through a preset interface, the target protocol address is returned to the vehicle.

[0007] In one embodiment, after the step of returning the target protocol address to the vehicle in response to an address acquisition request initiated by the vehicle through a preset interface, the method includes: If the vehicle establishes a connection with the cluster management platform of the region to be transferred to through the target protocol address, it is determined whether the region in the cache is consistent with the region to be transferred to. If the region in the cache is inconsistent with the region to be transferred to, then the region identifier of the vehicle is updated based on the region to be transferred to.

[0008] In one embodiment, after the step of updating the area identifier of the vehicle, the following steps are included: In response to a first area identifier sent by a terminal communicating with the vehicle, if the first area identifier does not match the area identifier, the target area address of the vehicle is returned to the terminal.

[0009] In one embodiment, after the step of the cluster management platform controlling the fault area disconnecting the service connection with each vehicle model based on the fault protocol address, the following steps are included: In response to a rollback command triggered for the faulty area, the cluster management platform of the faulty area is controlled to restore the service connection with each vehicle model based on the fault protocol address, and to update the corresponding switched fault protocol address and faulty area address for each vehicle model, so as to execute the rollback command.

[0010] To achieve the above objectives, this application provides a disaster recovery switchover method for a vehicle management system, applied to vehicles. The disaster recovery switchover method for the vehicle management system includes: In response to the startup command, retrieve the server protocol address from the local cache; In response to a network connection error, the target protocol address is obtained from the server through a preset interface; The connection process is executed through the target protocol address, and the target protocol address is stored in the local cache.

[0011] In one embodiment, the network connectivity anomaly includes at least one of the following: The timestamp in the local cache has timed out; The server protocol address connection failed.

[0012] To achieve the above objectives, this application provides a disaster recovery switching method for a vehicle management system, applied to a terminal communicating with a vehicle. The disaster recovery switching method for the vehicle management system includes: In response to the operation command triggered by the terminal, the first area identifier of the vehicle paired with the terminal is obtained from the local cache, and the first area identifier is sent to the server so that the server can verify the first area address and the area address. If the target area address and area identifier returned by the server are received, the operation command is issued to the vehicle based on the target area address; Update the first region identifier in the local cache according to the region identifier.

[0013] In one embodiment, after the step of sending the first region identifier to the server, the following steps are included: If the server returns information indicating a match for the first region identifier, the operation command is sent to the vehicle based on the region address obtained from the local cache.

[0014] In addition, to achieve the above objectives, this application also provides a disaster recovery switching device for a vehicle management system, the vehicle management system disaster recovery switching device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the vehicle management system disaster recovery switching method as described above.

[0015] In addition, to achieve the above objectives, this application also provides a storage medium, which is a computer-readable storage medium, on which a computer program implementing a disaster recovery switching method for a vehicle management system is stored. The computer program implementing the disaster recovery switching method for a vehicle management system is executed by a processor to implement the steps of the disaster recovery switching method for a vehicle management system as described above.

[0016] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the disaster recovery switchover method for a vehicle management system as described above.

[0017] Furthermore, to achieve the above objectives, this application also provides a disaster recovery switching device for a vehicle management system, comprising: The database switching unit is configured to perform a primary / standby database switching action based on the database of the faulty area and the area to be switched to in response to a regional fault alarm triggered for the faulty area. The strategy coordination unit is configured to update the target protocol address and target area address of each vehicle model corresponding to the area to be transferred to in response to the operation and maintenance input for the fault area; and control the cluster management platform of the fault area to disconnect the service connection between each vehicle model and the fault protocol address.

[0018] Furthermore, to achieve the above objectives, this application also provides a disaster recovery switching device for a vehicle management system, comprising: The first protocol acquisition unit is configured to retrieve the server protocol address from the local cache in response to a startup command; Anomaly detection unit, configured to detect network connection anomalies; The first connection unit is configured to obtain the target protocol address from the server through a preset interface; The first protocol acquisition unit is configured to store the target protocol address into the local cache; The first connection unit is configured to execute a connection process via the target protocol address.

[0019] Furthermore, to achieve the above objectives, this application also provides a disaster recovery switching device for a vehicle management system, comprising: The second protocol acquisition unit is configured to acquire the first area identifier of the vehicle paired with the terminal from a local cache in response to an operation command triggered by the terminal. The second connection unit is configured to send the first region identifier to the server so that the server can verify the first region address and the region address; if it receives the target region address and region identifier returned by the server, it issues the operation command to the vehicle based on the target region address. The second protocol acquisition unit is further configured to update the first region identifier in the local cache according to the region identifier.

[0020] This application provides a disaster recovery switchover method for a vehicle management system. On the server side, in response to a regional fault alarm triggered for a faulty area, the present invention first performs a primary / backup switchover based on the databases of the faulty area and the area to be transferred. Then, in response to the maintenance input for the faulty area, it updates the target protocol address and target area address according to the vehicle model and controls the cluster management platform to disconnect the faulty connection of the vehicles in the faulty area. This can overcome the limitations of traditional disaster recovery switchover's "one-size-fits-all" approach, which leads to the pressure collapse of the target area and easy data loss. By leveraging the server's global control and canary scheduling capabilities for multi-regional resources, it provides a refined execution path for disaster recovery switchover that adapts to vehicle models in batches. This avoids the target area from crashing due to sudden traffic overload and ensures the integrity and consistency of business data through seamless primary / backup database switchover. At the same time, by linking and synchronizing the addresses and area identifiers of the server, vehicles, and terminals, the business interruption cycle of fault switchover is shortened. This achieves stable, controllable, and efficient collaboration of disaster recovery switchover under the server-side multi-active architecture, enhancing the system's business continuity and data security in extreme scenarios such as city-level disasters.

[0021] On the vehicle side, this embodiment of the invention prioritizes obtaining the server protocol address from the local cache in response to the startup command. If the cache times out or the connection fails, the target protocol address is obtained from the server through a preset high-availability interface, stored in the cache, and the connection process is executed. This overcomes the limitations of traditional single-connection methods for vehicles, which are susceptible to regional faults and have poor connection stability. By leveraging the dual mechanism of "local cache reuse and server interface fallback," a stable and adaptive connection address acquisition path is provided for the vehicle. This reduces the network and computing power consumption of the vehicle in frequently requesting the server, speeds up the startup connection response, and adapts the latest target protocol address to the server's disaster recovery switching strategy, avoiding vehicle offline due to regional faults. At the same time, the cache update mechanism ensures that the vehicle is connected to the "home" or "optimal" data center for a long time, thereby achieving continuous online and stable connection of the vehicle in a multi-region active-active architecture, improving the reliability of core functions such as remote vehicle control and status query, and enhancing the user's driving experience.

[0022] In the terminal, when responding to an operation command, this embodiment of the invention first retrieves the vehicle's first region identifier from the local cache and sends the first region identifier to the server for verification. If the server returns the target region address and region identifier, it indicates that the locally cached data is outdated. The local cache is then updated based on the target region address and region identifier returned by the server, and the operation command is issued to the vehicle based on the target region address. If the server returns matching information for the first region identifier, it indicates that the locally cached data is correct, and the operation command is issued to the vehicle based on the locally cached region address. This method not only ensures the correctness of the terminal's region address and that the terminal and vehicle are connected to the same region, but also reduces the signaling overhead between the terminal and the server. Furthermore, it overcomes the limitations of traditional terminals blindly issuing commands, which can easily lead to command failures and data inconsistencies due to vehicle cross-regional switching. By leveraging a two-way verification mechanism of "local cache verification and server-side real-time query," it provides precise regional positioning support for terminal command routing. This reduces the overhead of invalid command transmission and processing, speeds up command issuance response, and avoids command anomalies or data conflicts caused by regional mismatches, ensuring the accuracy of command execution. At the same time, it adapts to dynamic vehicle switching scenarios through adaptive regional identifier updates, enabling collaborative linkage between the terminal and the vehicle without manual configuration by the user. This allows for precise command issuance and efficient interaction of the terminal under a human-vehicle-cloud multi-active architecture, enhancing the smoothness of remote operation functions and the robustness of system operation. Attached Figure Description

[0023] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0024] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0025] Figure 1 This is a flowchart illustrating an embodiment of the disaster recovery switchover method for the vehicle management system of this application. Figure 2 This is a flowchart illustrating Embodiment Six of the Disaster Recovery Switching Method for the Vehicle Management System of this Application; Figure 3 This is a flowchart illustrating Embodiment 7 of the disaster recovery switchover method for the vehicle management system of this application. Figure 4 This is a schematic diagram of the architecture of a vehicle management system provided in Embodiment 8 of the disaster recovery switchover method for the vehicle management system of this application; Figure 5 This is a schematic diagram of data flow during disaster recovery switching in a vehicle management system, provided in Embodiment 8 of the disaster recovery switching method for the vehicle management system of this application. Figure 6 This is a schematic diagram of the fault switching process in Embodiment 8 of the disaster recovery switching method for the vehicle management system of this application; Figure 7 This is a schematic diagram of the system framework involved in the disaster recovery switching equipment of the vehicle management system of this application.

[0026] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0027] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0028] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0029] Currently, the relevant technologies adopt a dual-active / disaster recovery deployment within the same city, relying on redundant resources within the region to ensure the communication continuity between vehicles and the network. While the dual-active deployment within the same city has backup resources and can cope with single data center failures, in the event of a city-wide disaster, the RTO (Recovery Time Objective) and RPO (Recovery Point Objective) of business data become too long, leading to prolonged service interruptions.

[0030] The main solution of this application is as follows: in response to a regional fault alarm triggered for a faulty area, a primary / backup database switchover is performed based on the databases of the faulty area and the area to be transferred; in response to maintenance input for the faulty area, the target protocol address and target area address of each vehicle model corresponding to the area to be transferred are updated based on the area to be transferred indicated by the maintenance input; and the cluster management platform of the faulty area is controlled to disconnect the service connection between the faulty area and each vehicle model based on the faulty protocol address.

[0031] This application, by responding to regional fault alarms, first performs a primary / backup switchover based on the databases of the faulty region and the region to be transferred. Then, it responds to maintenance inputs to update the target protocol address and target region address by vehicle type, and controls the cluster management platform to disconnect the faulty connection of vehicles in the faulty region. This overcomes the limitations of traditional disaster recovery switchover's "one-size-fits-all" approach, which can lead to target region pressure collapse and data loss. By leveraging the server's global control and canary scheduling capabilities for multi-regional resources, it provides a refined execution path for disaster recovery switchover that adapts to vehicle types in batches. This avoids target region downtime due to sudden traffic overload, ensures the integrity and consistency of business data through seamless primary / backup database switchover, and shortens the business interruption cycle of fault switchover by linking and synchronizing the server with vehicle and terminal addresses and region identifiers. In this way, it achieves stable, controllable, and efficient collaboration of disaster recovery switchover under a server-side multi-active architecture, enhancing the system's business continuity and data security in extreme scenarios such as city-level disasters.

[0032] It should be noted that the executing entity in this embodiment can be a vehicle management system, or a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or a disaster recovery switching device for a vehicle management system capable of the above functions. This embodiment does not specifically limit this. The following uses a vehicle management system as the executing entity as an example to describe this embodiment and the following embodiments.

[0033] It should be noted that the vehicle management system in this embodiment includes a server, vehicles, and terminals.

[0034] Based on this, Embodiment 1 of this application proposes a disaster recovery switchover method for a vehicle management system. For its application on the server side, please refer to [reference needed]. Figure 1 The disaster recovery switchover method for the vehicle management system includes steps S10 to S30: Step S10: In response to a regional fault alarm triggered for the faulty area, perform a primary / backup database switchover based on the databases of the faulty area and the area to be switched to.

[0035] In this embodiment, a regional fault alarm refers to an alarm notification automatically triggered and sent by the system when it detects an anomaly in a data center, network, or core service in a certain region, rendering it unable to provide normal service. A faulty region refers to the region currently experiencing service anomalies and unable to continue carrying services. That is, the faulty region is the region indicated by the regional fault alarm, and the regional fault alarm is an alarm generated specifically for the faulty region. The region to be transferred to refers to a pre-configured backup region with service carrying capacity, used to receive switched-in service traffic when the faulty region fails. The primary / backup database switching operation refers to the process of transferring read / write permissions for service data from the primary database in the faulty region to the backup database in the region to be transferred to, while ensuring the data integrity and availability of the backup database after it is upgraded to the primary database.

[0036] As an optional implementation, the system incorporates a built-in fault detection module to monitor the operational status of databases in each region in real time, including database connection stability, data synchronization latency, and hardware resource load. When a faulty database in a region meets preset alarm conditions, such as three consecutive connection timeouts or a data synchronization latency exceeding 5 minutes, a region fault alarm is automatically triggered. Subsequently, the system determines the optimal region to be transferred to based on preset region priority configurations. First, write protection is implemented on the primary database of the faulty region to prevent data write conflicts. Then, the backup database of the region to be transferred to is upgraded to the primary database, the database routing configuration is updated, and the primary / backup switch is completed.

[0037] As an alternative implementation, operations and maintenance personnel can monitor the operational status of each region in real time through a monitoring platform. When an anomaly is detected in a faulty region, they can manually initiate a region fault alarm and specify the region to be transferred to. After receiving the alarm command, the system pushes a switchover confirmation request to the operations and maintenance personnel. After the personnel confirm the switchover through the approval process, the primary and backup databases are switched over. During the switchover process, the system first verifies the data consistency between the backup database in the region to be transferred and the primary database in the faulty region. If the data differences are within the allowable range, write protection and backup database upgrade operations are then performed, and a switchover log is generated for subsequent traceability.

[0038] Step S20: In response to the maintenance input for the faulty area, update the target protocol address and target area address of each vehicle model corresponding to the area to be transferred.

[0039] In this embodiment, "operational input" refers to the operation instructions entered by operations personnel through the policy management platform to specify the switching rules, including but not limited to any one or any combination of information such as the target area identifier, vehicle model range, and address configuration parameters. The target protocol address refers to the protocol address used by the vehicle in the target area to establish a communication connection with the server; in this embodiment, it is specifically the MQTT protocol address. The target area address is the address used by the terminal connected to the vehicle to connect with the server.

[0040] It should be noted that the operational input can occur either before or after the primary / standby database switchover. That is, the region to be switched over can be a pre-configured region; if a region fault alarm is triggered, the pre-configured region to be switched over will be used to perform the primary / standby database switchover. Alternatively, if a region fault alarm is triggered and pushed to the operational personnel, the personnel will configure the region to be switched over, as well as the target protocol address and target region address for each vehicle model, as operational input. In response to the operational input for the faulty region, the server will parse the address to be switched over, as well as the target protocol address and target region address for each vehicle model, and execute subsequent steps.

[0041] As an optional implementation, the policy management platform provides a batch configuration function. Maintenance personnel can select all vehicle models corresponding to the faulty area in the background, enter the target protocol address and target area address of the area to be transferred, and click confirm. The system automatically synchronizes the configuration information to the policy collaboration service. After receiving the information, the policy collaboration service updates the vehicle model-address association mapping table to ensure that subsequent address query requests from vehicles and terminals can obtain the latest configuration.

[0042] As an alternative implementation, the system supports configuring switching rules based on vehicle model priority. Maintenance personnel can set the switching priority of core vehicle models to be higher than that of ordinary vehicle models when inputting maintenance information. Upon receiving the input, the system first updates the target protocol address and target region address corresponding to the core vehicle model. After the core vehicle model completes the switch and operates stably for a preset time, such as 30 minutes, it automatically updates the address configuration of ordinary vehicle models, achieving batch updates.

[0043] Step S30: Control the cluster management platform of the fault area to disconnect the service connection with each vehicle model based on the fault protocol address.

[0044] In this embodiment, the cluster management platform refers to the core platform used to manage the MQTT communication clusters in various regions, responsible for maintaining the long-term connection status between vehicles and the server, and controlling connection disconnection and reconstruction. The fault protocol address refers to the protocol address used by the vehicle when establishing a connection with the faulty region before the fault occurred; that is, the communication address before the fault switchover. The service connection refers to the long-term connection established between the vehicle and the cluster management platform based on the MQTT protocol, used for transmitting vehicle data and commands.

[0045] As an optional implementation, after completing the address update, the system automatically sends a connection disconnection command to the cluster management platform in the fault area. The command includes the vehicle identification numbers of each vehicle model that need to be disconnected. Upon receiving the command, the cluster management platform iterates through all vehicle connections currently associated with that vehicle model and sends a disconnection notification to each one. Once the vehicle confirms receipt, the long connection is terminated, ensuring the orderly disconnection.

[0046] As an alternative implementation, upon receiving a disconnect command, the cluster management platform does not immediately disconnect all connections. Instead, it terminates service connections for each vehicle model based on the fault protocol address in batches according to a preset disconnection rate, such as disconnecting 10% of connections per minute. Simultaneously, it monitors the connection load of the area to be transferred in real time. If the number of connections in the area to be transferred approaches its capacity limit, it automatically adjusts the disconnection rate to reduce the access pressure on the area to be transferred.

[0047] For example, suppose region X is the faulty region and region Y is the region to be transferred, involving vehicle models A and B. The system detects a hardware fault in the database of region X and automatically triggers a region fault alarm. In response to this alarm, the system determines that region Y is the region to be transferred to. First, it implements write protection on the primary database of region X, verifies the data consistency between the backup database of region Y and the primary database of region X, and after confirming that the data differences are within the allowable range, it upgrades the backup database of region Y to the primary database, completing the primary / backup switch. Subsequently, maintenance personnel initiate maintenance input through the policy management platform, selecting vehicle models A and B, entering the MQTT target protocol address and target region address of region Y, and setting the update priority of core vehicle model A to be higher than that of vehicle model B. The system updates the address configuration of vehicle model A first, and then updates the address configuration of vehicle model B 30 minutes later. After the address update is completed, the system sends a disconnect command to the cluster management platform of region X. The cluster management platform disconnects the service connections of vehicle models A and B based on the faulty protocol address of region X in batches at a rate of 10% disconnection per minute, while simultaneously monitoring the connection load of region Y in real time to ensure stable access pressure.

[0048] This embodiment ensures data security by first performing a primary / backup database switchover, then updating the target address according to vehicle model to clarify the connection direction, and finally disconnecting faulty connections in batches to reduce the switchover pressure. It overcomes the limitations of traditional disaster recovery switchovers, such as data loss and target area overload. Leveraging the server's global scheduling and fine-grained control capabilities, it provides a safe, orderly, and controllable execution path for server-side disaster recovery switchover. It ensures the integrity of business data through primary / backup database switchover, avoids sudden traffic surges through vehicle model address updates and batch connection disconnections, and smoothly migrates business from the faulty area to the receiving area. This enhances the server system's rapid response capability to regional faults, strengthens business continuity, and improves system stability.

[0049] Based on any of the above embodiments, in Embodiment 2 of this application, after step S30, the following is included: Step S40: In response to the address acquisition request initiated by the vehicle through a preset interface, the target protocol address is returned to the vehicle.

[0050] In this embodiment, the address retrieval request refers to the request instruction actively sent by the vehicle to a preset interface after a connection failure based on the fault protocol address. This request is used to obtain a valid communication address and includes core data such as vehicle identifier and model information, so that the server can accurately match the corresponding configuration. The preset interface refers to a highly available HTTPS interface deployed in various regions, used by the vehicle to query the server for the latest target protocol address when the connection fails or the cache expires.

[0051] As an optional implementation, the default interface uses Alibaba Cloud GTM to perform traffic round-robin scheduling via an independent domain name, distributing vehicle address retrieval requests to the NLB in each region, and then the NLB forwards them to the policy coordination service. After receiving the request, the policy coordination service queries the updated address mapping table based on the vehicle model information in the request, quickly extracts the corresponding target protocol address, and returns it to the vehicle in a preset data format to ensure response efficiency.

[0052] As an alternative implementation, the default interface has a built-in request verification mechanism. After receiving a request to obtain the vehicle's address, it first verifies the validity of the vehicle identifier and whether the request frequency meets the limits. If the verification passes, the policy coordination service queries the target protocol address corresponding to the vehicle and returns it; if the verification fails, it returns a request failure message and records the exception log, while simultaneously pushing alarm information to the operations and maintenance personnel to prevent malicious requests from consuming resources.

[0053] For example, continuing the previous scenario, after the cluster management platform in region X disconnects the fault protocol address service connection for vehicle models A and B in batches, a vehicle of model A fails to reconnect via the fault protocol address three times and automatically initiates an address retrieval request to a preset interface. This request is scheduled by Alibaba Cloud GTM to the NLB in region Y, and then forwarded to the policy coordination service. After verifying the validity of the vehicle identifier, the policy coordination service queries the target protocol address in region Y corresponding to vehicle model A and returns it to the vehicle. Subsequent address retrieval requests initiated by other vehicles of model A and model B after reconnection failures all follow the same process to obtain the target protocol address.

[0054] This embodiment ensures that vehicles can quickly obtain the target protocol address after a connection failure by using highly available scheduling and precise address matching of preset interfaces. This connects the database switching and address update steps described earlier, forming a complete fault switching link. It leverages Alibaba Cloud GTM and NLB to ensure interface stability and avoid interruptions in the address query process. Furthermore, it improves the accuracy of address returns through request verification and precise mapping, allowing vehicles to quickly access the destination area, shortening service interruption time, and further enhancing the efficiency and reliability of disaster recovery switching.

[0055] Based on any of the above embodiments, in Embodiment 3 of this application, after step S40, the following is included: Step S50: If the vehicle establishes a connection with the cluster management platform of the area to be transferred through the target protocol address, determine whether the area in the cache is consistent with the area to be transferred.

[0056] Step S60: If the region in the cache is inconsistent with the region to be transferred to, then update the region identifier of the vehicle based on the region to be transferred to.

[0057] In this embodiment, the current region refers to the region to which the vehicle is to be transferred after successfully establishing a connection through the target protocol address. The region in the cache refers to the region that the vehicle was connected to before the failover occurred, stored in the server's cache. This region can be a failed region or another region. The region identifier is information used to uniquely identify the region to which the vehicle belongs. It is associated with the target region address and is the core basis for the server and terminal to identify the region affiliation of the vehicle.

[0058] As an optional implementation, after a vehicle establishes a connection with the cluster management platform via the target protocol address, the cluster management platform automatically identifies the region it belongs to. Simultaneously, it extracts the vehicle's connection region before the fault switch from the system's stored vehicle fault connection logs as a cached region. The cluster management platform compares the current region with the cached region; if they do not match, it immediately sends a region identifier update request to the policy coordination service. Upon receiving the request, the policy coordination service modifies the region identifier field corresponding to the vehicle and synchronizes it to the main data center to ensure data consistency across the entire system.

[0059] As an alternative implementation, after a vehicle establishes a connection, the cluster management platform pushes a verification request containing the vehicle identifier and the current connected node information to the policy coordination service. The policy coordination service determines the current region (the region to be transferred to) based on the connected node information, and then queries the region information stored in the main data center (the cached region) using the vehicle identifier to complete the comparison. If the comparison results are inconsistent, the policy coordination service directly updates the vehicle's region identifier in the main data center and returns a successful update receipt to the cluster management platform. The cluster management platform records the update log for subsequent verification.

[0060] For example, continuing the previous scenario, after a vehicle of model A obtains the target protocol address of region Y, it successfully establishes a long connection with the cluster management platform of region Y. The cluster management platform of region Y identifies its own region as the current region, i.e., region Y, and extracts region X, which the vehicle previously connected to, from the vehicle's fault connection log as the fault region. Upon comparison, the current region and the fault region are inconsistent, and the cluster management platform sends an update request to the policy coordination service. After receiving the request, the policy coordination service updates the vehicle's region identifier to the identifier corresponding to region Y and synchronizes it to the main data center of region Y, ensuring that each service node on the server side can obtain the latest region affiliation information of the vehicle. Subsequently, other vehicles that have disconnected from the faulty connection, after connecting to the cluster management platform of region Y, all complete the comparison of the current region and the fault region and the update of the region identifier according to the above process.

[0061] Furthermore, if the region to be transferred to is consistent with the region in the cache, a preset request interaction task is executed to control the cluster management platform and the vehicle to perform data interaction.

[0062] This embodiment establishes a closed-loop management system for fault switching by comparing and updating the region after vehicle connection, connecting the address acquisition and connection establishment steps mentioned earlier. This ensures the server can grasp the latest region affiliation of vehicles in real time, providing accurate data support for terminal queries. Furthermore, the unified synchronization of region identifiers guarantees data consistency across the entire system, avoiding command routing errors caused by outdated region information. Simultaneously, region verification and updates can be completed automatically without manual intervention, improving the automation and accuracy of disaster recovery switching and further enhancing the collaborative stability of the server's multi-active architecture.

[0063] Based on any of the above embodiments, in Embodiment 4 of this application, after the step of updating the area identifier of the vehicle, the following steps are included: Step S71: In response to the address acquisition request initiated by the terminal, the area identifier is returned to the terminal to prompt the terminal to determine the first area address of the vehicle.

[0064] Alternatively, in step S72, in response to a first area identifier sent by a terminal communicating with the vehicle, if the first area identifier does not match the area identifier, the target area address of the vehicle is returned to the terminal.

[0065] In this embodiment, the terminal refers to the intelligent device used by the user to interact with the vehicle, specifically a mobile phone, tablet, or other device equipped with an APP. The address acquisition request is a request initiated by the terminal to the server before issuing an operation command, used to query the vehicle's current area information, including core data such as the terminal identifier and the paired vehicle identifier. The first area address refers to the service connection address of the area the vehicle currently belongs to, i.e., the area to be transferred to, determined by the terminal based on the received area identifier, and is used to establish a precise command transmission link between the terminal and the vehicle.

[0066] As an optional implementation, after the terminal initiates an address acquisition request, the request is forwarded to the policy coordination service via the business gateway. Based on the vehicle identifier in the request, the policy coordination service queries the updated vehicle region identifier in the main data center and directly returns the region identifier to the terminal without additional verification. Upon receiving the region identifier, the terminal automatically matches the corresponding first region address using the built-in region identifier-region address mapping relationship.

[0067] For example, continuing the previous scenario, after a vehicle of model A completes its area identifier update, a user initiates a remote lock command via the terminal app. Before issuing the command, the terminal automatically sends an address retrieval request to the server, carrying both the terminal identifier and the vehicle identifier. Upon receiving the request, the policy coordination service verifies the valid pairing between the terminal and the vehicle, finds that the vehicle's area identifier corresponds to area Y, binds this identifier to the first area address of area Y, and returns it to the terminal. Upon receiving this, the terminal directly extracts the first area address and issues the remote lock command to the vehicle based on this address, ensuring the command is accurately routed to the service node in area Y.

[0068] For step S72, this implementation method involves performing the region identifier verification on the server side.

[0069] In this embodiment, the terminal sends a first region identifier to the server to verify whether its cached first region identifier is the latest identifier. Upon receiving the first region identifier, the server compares it with the region identifier cached by the vehicle on the server. If they do not match, the server obtains the target region address associated with the region identifier and returns the vehicle's target region address to the terminal. If they match, the server generates matching information for the first region identifier and returns this information to the terminal to indicate that the region address in the terminal's cache is the latest address.

[0070] For example, continuing the previous scenario, after a vehicle of model A completes its region identifier update, the user initiates a remote lock command via the terminal app. Before issuing the command, the terminal retrieves the first region identifier of the paired vehicle from its local cache and sends it to the server. After receiving the first region identifier, the policy coordination service verifies that it is inconsistent with the updated region identifier. If this is inconsistent, it indicates that the region address cached by the terminal has expired, and the service returns the target region address of region Y to the terminal. Upon receiving this, the terminal directly extracts the target region address and issues the remote lock command to the vehicle based on it, ensuring that the command is accurately routed to the service node in region Y.

[0071] This embodiment returns the latest vehicle region identifier to the terminal, connecting with the vehicle region identifier update step described earlier, providing accurate region positioning support for terminal command issuance. It ensures request security through pairing relationship verification and improves terminal processing efficiency by providing a direct address binding return method, ensuring the terminal can quickly determine the first region address. Simultaneously, it synchronizes region information between the server and the terminal, preventing command issuance errors due to outdated region information, further improving end-to-end collaboration in disaster recovery switching, and enhancing the reliability of remote operation functions and user experience.

[0072] Based on any of the above embodiments, in Embodiment 5 of this application, after step S30, the following is included: Step S70: In response to the rollback command triggered for the faulty area, control the cluster management platform of the faulty area to restore the service connection with each vehicle model based on the fault protocol address, and update the corresponding switched fault protocol address and faulty area address for each vehicle model to execute the rollback command.

[0073] In this embodiment, the rollback command is a control command used to trigger the return of services from the pending transfer area to the original faulty area after the faulty area has restored normal service capabilities. It can be initiated manually by maintenance personnel or automatically by the system. The fault protocol address refers to the protocol address when the vehicle connects to the faulty area. The faulty area address is the area address when the terminal connects to the faulty area. The rollback operation refers to the complete process of restoring service connections, address configurations, and area affiliation to their state before the fault occurred, ensuring stable service operation upon returning to the original area.

[0074] As an optional implementation, after the faulty area is restored, maintenance personnel confirm through the monitoring platform that the area's service status and database operation meet the rollback conditions, and then manually initiate a rollback command on the policy management platform. Upon receiving the command, the system first controls the cluster management platform of the area to be transferred to stop receiving new connection requests for that vehicle model, then controls the cluster management platform of the faulty area to restore service connections with each vehicle model based on the fault protocol address, and controls the server to restore service connections with terminals based on the faulty area address. Simultaneously, the policy coordination service updates the address configuration of each vehicle model, recording the switched fault protocol address and faulty area address in the fault configuration table.

[0075] As an alternative implementation, the system incorporates a rollback trigger mechanism to monitor the service recovery status of the faulty area in real time. Once the database synchronization in the faulty area is complete, resource load is below a preset threshold, and the system has been running stably for a preset time (e.g., 1 hour), a rollback assessment report is automatically generated and pushed to maintenance personnel. After confirmation by the maintenance personnel, the system automatically triggers a rollback command, executing the rollback operation in batches according to vehicle model priority. First, the service connection between the core vehicle model and the faulty area based on the fault protocol address is restored, and the address configuration is updated. After the core vehicle model is running stably, the connection and configuration update for ordinary vehicle models are then restored, avoiding traffic surges during the rollback process.

[0076] For example, continuing the previous scenario, after the fault in area X is resolved, the database resumes normal operation, and the resource load remains stable within a reasonable range for one hour. The system automatically generates a rollback assessment report and pushes it to the operations and maintenance personnel. After confirmation, the personnel trigger the rollback command. The system first controls the cluster management platform in area Y to stop receiving new connection requests from vehicle models A and B, and then controls the cluster management platform in area X to restore service connections with each vehicle model based on the fault protocol address. During the rollback process, the connection restoration and configuration update for the core vehicle model A are completed first. After observing for 30 minutes without any abnormalities, the rollback operation for the ordinary vehicle model B is then executed.

[0077] This embodiment triggers service regression through a rollback command, connecting with the fault switching process described earlier to form a complete closed loop of fault switching, service operation, fault recovery, and rollback regression. It adapts to different operational needs through manual or automatic triggering mechanisms, and rollbacks in batches according to vehicle model priority to avoid traffic surges, ensuring the original faulty area smoothly receives the regressed services. Simultaneously, the target protocol address and target area address are retained for subsequent traceability, restoring the original configuration to ensure the stability of the service after regression, further improving the disaster recovery capabilities of the server-side multi-site active-active architecture, and enhancing the system's flexibility and reliability in responding to faults.

[0078] Based on any of the above embodiments, applied to vehicles, in Embodiment Six of this application, the disaster recovery switchover method for the vehicle management system includes: Step A10: In response to the startup command, obtain the server protocol address from the local cache.

[0079] In this embodiment, the start command refers to the control command triggered when the vehicle is ignited or the communication module is restarted, used to initiate the communication connection process between the vehicle and the server. The server protocol address refers to the standardized address used when the vehicle and the server establish communication; in this embodiment, it is specifically the MQTT protocol address, used to ensure the stability of data transmission between the vehicle and the server.

[0080] It should be noted that the server can be in the cloud, or it can be another type of server or physical server. In this implementation, both the policy coordination service and the cluster management platform are considered servers. The server is used for data interaction between the relay terminal and the vehicle.

[0081] For example, in a case where a terminal issues a command to a vehicle, the terminal establishes communication with the server based on the target area address and sends the operation command to the policy coordination service of the area to be transferred to. After receiving the operation command, the policy coordination service distributes the operation command through the cluster management platform of the area to be transferred to, that is, issues the operation command to the vehicle.

[0082] As an optional implementation, after the vehicle is ignited and powered on, the communication module automatically triggers a start command without requiring any additional user intervention. Upon receiving the command, the vehicle's control unit directly accesses the specified storage path in its local cache to retrieve the pre-stored server protocol address. The entire process requires no interaction with the server, thus shortening the address acquisition time.

[0083] As an alternative implementation, after the vehicle responds to the start command, it first performs an integrity check on the local cache to check for the existence of storage entries related to the server protocol address and whether the entries are corrupted. If the check passes, the address is retrieved from the cache; if the check fails, the cache is directly determined to be invalid, triggering the subsequent address retrieval process.

[0084] Step A20: In response to a network connection error, obtain the target protocol address from the server through a preset interface.

[0085] In this embodiment, network connection anomalies include at least one of the following: the local cache timestamp times out; the server protocol address connection fails.

[0086] In this embodiment, timestamp timeout refers to the storage time of the server protocol address in the local cache exceeding a preset validity period, typically 30 days. Connection failure refers to the vehicle attempting to establish a connection with the server using the server protocol address obtained from the local cache, and failing to reconnect consecutively a preset number of times, typically 3 times. This embodiment does not specifically limit the values ​​of the validity period and the preset number of attempts; these can be adaptively set by maintenance personnel.

[0087] As an optional implementation, after retrieving the locally cached server protocol address, the vehicle automatically verifies its timestamp. If the timestamp indicates that it has expired, the address is abandoned, and a request to obtain the target protocol address is initiated to the server through a preset interface. If the timestamp has not expired, an attempt is made to establish a connection using the address. If three consecutive connection attempts fail, the interface request process is triggered again.

[0088] As an alternative implementation, the vehicle first attempts to establish a connection using the locally cached server protocol address. If the initial connection is successful, normal communication proceeds. If the initial connection fails, it automatically retryes twice. After three failed attempts, the locally cached timestamp is then verified. Regardless of whether the timestamp has expired, the target protocol address is requested from the server through a preset interface to ensure that the latest valid address is obtained.

[0089] Step A30: Execute the connection process using the target protocol address and store the target protocol address in the local cache.

[0090] In this embodiment, the connection process refers to the complete process by which the vehicle establishes an MQTT long connection with the cluster management platform of the area to be transferred to, based on the target protocol address. This includes steps such as sending a connection request, identity verification, and link establishment. Storing in the local cache means replacing the old address in the local cache with the obtained target protocol address and updating the timestamp to ensure that it can be reused directly upon the next startup.

[0091] As an optional implementation, after obtaining the target protocol address, the vehicle immediately sends a connection request to the cluster management platform corresponding to that address. After the cluster management platform completes identity verification and returns a successful connection response, the vehicle confirms that the connection process is complete, then writes the target protocol address to its local cache, overwriting the original old address and updating the timestamp to the current time.

[0092] As an alternative implementation, after obtaining the target protocol address, the vehicle first verifies the address format to ensure it conforms to the MQTT protocol address specification before initiating a connection request. During the connection process, link stability is monitored in real time. If the connection is successful and runs stably for 5 minutes, the target protocol address is stored in the local cache. If an abnormal interruption occurs during the connection process, the address acquisition request is re-initiated to avoid caching invalid addresses.

[0093] For example, when a user starts a vehicle of model A, the vehicle responds to the start command and retrieves the server protocol address for region X from its local cache. Verification reveals that the timestamp of this address has expired (stored for 35 days), so the vehicle abandons using this address and initiates a request to the server through a preset interface. Through Alibaba Cloud GTM scheduling, the request is forwarded to the policy coordination service in region Y, which returns the target protocol address for region Y. The vehicle then receives the address, verifies its format, sends a connection request to the cluster management platform in region Y, completes identity verification, and establishes a stable connection for 5 minutes. Afterward, the vehicle stores the target protocol address in its local cache, updates the timestamp to the current time, and all subsequent communication is based on this address.

[0094] This embodiment overcomes the connection latency or interruption issues caused by traditional vehicles relying solely on the server to obtain addresses through a dual mechanism of prioritizing local caching and using interface fallback. It leverages local caching to reuse valid addresses, reducing network interaction overhead and accelerating connection startup. Furthermore, timeout checks and reconnection failure triggering mechanisms ensure timely acquisition of the latest target protocol address during failover scenarios. Simultaneously, updating the cache after a successful connection facilitates subsequent startups, enabling adaptive connectivity in a multi-active architecture. This ensures the continuity of core functions such as remote vehicle control and status queries, improving user experience and system stability.

[0095] Based on any of the above embodiments, in Embodiment Seven of this application, the disaster recovery switching method for a vehicle management system applied to a terminal includes: Step B10: In response to the operation command triggered by the terminal, the first area identifier of the vehicle paired with the terminal is obtained from the local cache, and the first area identifier is sent to the server so that the server can verify the first area address and the area address.

[0096] In this embodiment, the operation command refers to the command initiated by the user through the terminal APP to control the vehicle or query the vehicle status, such as remotely locking the car, starting the air conditioner, or querying the vehicle location. The first area identifier refers to the area identifier cached locally on the terminal and recorded by the terminal and the paired vehicle during the last interaction, which is used by the terminal to initially determine the area affiliation of the vehicle.

[0097] As an optional implementation, after the user clicks the corresponding function button on the terminal APP to trigger the operation command, the terminal does not need to wait and automatically accesses the locally cached vehicle-related data storage directory to directly extract the first area identifier of the paired vehicle and quickly complete the initial data acquisition.

[0098] As another optional implementation, after the terminal responds to the operation command, it first checks whether the first area identifier storage record of the paired vehicle exists in the local cache. If it exists and the record is complete, the identifier is extracted; if it does not exist or the record is corrupted, the first area identifier is directly determined to be empty, and subsequent processing is carried out according to the identifier mismatch logic.

[0099] Step B20: Request the region identifier of the vehicle and the target region address of the terminal and the server from the server.

[0100] Step B30: If the first area identifier matches the area identifier, then the operation command is issued to the vehicle based on the target area address.

[0101] In this embodiment, the region identifier refers to the latest identifier of the region to which the vehicle currently belongs, stored on the server, and is consistent with the region identifier updated on the vehicle and synchronized on the server. The target region address refers to the communication address of the service node corresponding to the region identifier on the server, used to establish a precise command transmission link between the terminal and the server. Matching means that the character content and format of the first region identifier and the region identifier are exactly the same, indicating that the vehicle region information cached on the terminal is consistent with the latest record on the server, and the vehicle has not switched regions.

[0102] As an optional implementation, after extracting the first region identifier, the terminal automatically assembles a request data packet containing the terminal identifier and the paired vehicle identifier, and initiates a request to the server through a preset communication channel, explicitly requesting the vehicle's region identifier and the corresponding target region address. The request process requires no user intervention. After receiving the region identifier and target region address returned by the server, the terminal automatically compares the identifiers. If a match is found, the terminal immediately sends an operation command to the corresponding service node on the server via the target region address. The service node then forwards the command to the vehicle, shortening the command transmission path.

[0103] As an alternative implementation, when the terminal initiates a request, it additionally carries a first region identifier as auxiliary information. After receiving the request, the server can first use the auxiliary information to initially locate the query range, speeding up the query and return speed of the region identifier and the target region address, and improving response efficiency. After the terminal confirms that the identifiers match, it first sends a link test request to the server through the target region address to verify whether the communication channel is smooth. If the test result shows that the channel is normal, the operation command is then issued; if the channel is abnormal, a prompt message is pushed to the user and the target region address is re-requested.

[0104] For example, continuing the previous scenario, a user wants to remotely start a paired vehicle (model A) via a terminal app. After triggering the operation command, the terminal retrieves the vehicle's first region identifier (region X identifier) ​​from its local cache. It then sends a request to the server, carrying the terminal identifier, vehicle identifier, and auxiliary information including the first region identifier. The server finds that the vehicle has completed a region switch, and its current region identifier is region Y. It also returns the target region address for region Y. The terminal compares the identifiers and finds a mismatch between the first region identifier (X) and the region identifier (Y). Subsequent steps are handled according to the identifier inconsistency logic (this corresponds to subsequent steps; this step focuses on the matching scenario). If the vehicle has not undergone a region switch, and the region identifier remains region X, the terminal confirms a match and, using the returned target region address X, sends a remote start command to the vehicle. The command is accurately forwarded to the vehicle via the server's service node, and the vehicle successfully responds.

[0105] Optionally, the identifier comparison can also be performed on the server side. In one variant, in response to an operation command triggered by the terminal, the terminal retrieves the first region identifier of the vehicle it is paired with from its local cache. The terminal generates a request based on the first region identifier and sends it to the server. The server compares the vehicle's region identifier with the first region identifier in the latest data and returns the comparison result and the server's target region address to the terminal. The terminal determines whether the first region identifier matches the first region identifier based on the comparison result. If the comparison result shows a match, the terminal issues the operation command to the vehicle based on the target region address. If the comparison result shows a mismatch, the terminal updates the local cache based on the first region identifier.

[0106] That is, after step B10, there are steps B40 and B50.

[0107] Step B40: If the target area address and area identifier returned by the server are received, the operation command is sent to the vehicle based on the target area address.

[0108] Step B50: Update the first region identifier in the local cache according to the region identifier.

[0109] In this embodiment, the terminal sends a first region identifier to the server to verify whether its cached first region identifier is the latest identifier. Upon receiving the first region identifier, the server compares it with the region identifier cached by the vehicle on the server. If they do not match, the server obtains the target region address associated with the region identifier and returns the vehicle's target region address to the terminal. Upon receiving the target region address and region identifier, the terminal knows that its locally cached region address has expired and issues the operation command to the vehicle based on the target region address; it also updates the locally cached first region identifier according to the region identifier. Furthermore, the locally cached region address can also be updated to the target region address. If they match, matching information for the first region identifier is generated and returned to the terminal to indicate that the region address in the terminal's cache is the latest address. That is, if the terminal receives matching information for the first region identifier returned by the server, it issues the operation command to the vehicle based on the region address obtained from the local cache.

[0110] For example, continuing the previous scenario, User A triggers a remote query command to check the vehicle's remaining range via a terminal app. The terminal retrieves the vehicle's first region identifier, i.e., region X, from its local cache, packages it together with the terminal identifier and vehicle identifier, encrypts it, and sends it to the server. Upon receiving the server, it compares the first region identifier sent by the terminal with the latest region identifier of the vehicle stored in its own database, i.e., region Y. Finding a discrepancy, the server retrieves the target region address corresponding to region Y and returns it along with the region Y identifier to the terminal. After receiving the target region address and region Y identifier, the terminal sends a link connectivity test to the service node in region Y. Once the channel is confirmed to be open, the terminal issues a remote query command to check the remaining range based on the target region address. The command is forwarded to the vehicle via the service node. After the vehicle returns the remaining range data, the terminal replaces the original first region identifier of region X in its local cache with the region Y identifier, updates the timestamp, backs up the old identifier, and displays the vehicle's current remaining range information to User A. If User A subsequently initiates another command, the terminal will directly retrieve the region Y identifier from its cache and send it to the server. After the server compares the identifier and confirms a match, the terminal quickly issues the command based on the region Y address.

[0111] This embodiment overcomes the routing errors caused by blindly issuing commands from the terminal by employing a dual verification logic of local cache retrieval on the terminal and real-time querying on the server. It leverages local caching to quickly obtain preliminary regional information, reducing the overhead of invalid requests, while simultaneously requesting the latest identifier and connection address from the server to ensure the accuracy of command issuance. The design of directly issuing commands when identifiers match shortens command transmission latency, ensuring the immediacy of remote operations. It also strengthens the coordination of regional information between the terminal, server, and vehicle, maintaining data consistency and improving user experience and system reliability.

[0112] Based on any of the above embodiments, in Embodiment 8 of this application, after step B20, the following is included: Step B60: If the first region identifier does not match the region identifier, then update the local cache according to the region identifier.

[0113] In this embodiment, updating the local cache means replacing the old first region identifier stored in the terminal's local cache with the region identifier obtained from the server, and synchronously updating the timestamp of the cache record to ensure that the terminal can directly obtain the latest vehicle region identifier when the operation command is triggered next time.

[0114] As an optional implementation, after the terminal confirms that the identifiers do not match, it automatically replaces the first region identifier in the local cache with the region identifier without user confirmation, and at the same time updates the cache timestamp to the current time, overwriting the original record. The whole process is completed silently in the background without interfering with user operations.

[0115] As an alternative implementation, before updating the local cache, the terminal first backs up the old first region identifier to the local temporary storage directory, then replaces the original cache record with the region identifier and updates the timestamp. The backup is retained for 7 days. If an identifier anomaly occurs subsequently, fault information can be traced through the backup, facilitating troubleshooting.

[0116] Step B50: Issue the operation command to the vehicle based on the target area address.

[0117] In this embodiment, issuing an operation command refers to the process by which the terminal accurately transmits the user-triggered control or query command to the service node in the corresponding area of ​​the server through the obtained target area address, and then the service node forwards it to the target vehicle, ensuring the accuracy and timeliness of command transmission.

[0118] As an optional implementation, after the terminal completes the local cache update, it immediately establishes a temporary communication link through the target area address, encrypts and packages the operation command according to the preset data format, and sends it. After the sending is completed, there is no need to wait for confirmation, and the user is directly shown a "command has been issued" prompt, which improves the efficiency of operation feedback.

[0119] As an alternative implementation, after establishing a communication link, the terminal first sends a pre-verification request to the corresponding service node on the server side. Only after confirming that the service node can normally receive and forward the instruction does the terminal issue the operation instruction. Upon receiving a "Instruction delivered to vehicle" confirmation from the service node, the terminal displays an operation result prompt to the user, ensuring effective instruction transmission.

[0120] For example, continuing the previous scenario, a user triggers a remote vehicle lock command via a terminal app. The terminal obtains the first region identifier (region X), requests it from the server, and receives the region identifier (region Y) and the connection address of region Y. A comparison reveals an inconsistency. The terminal automatically replaces the locally cached region X identifier with the region Y identifier, updates the timestamp to the current time, and backs up the old identifier to a temporary directory. Subsequently, the terminal initiates a pre-verification request to the server node using the connection address of region Y. After confirming the connection is successful, it issues the remote vehicle lock command. The server node receives the command and accurately forwards it to the vehicle that has switched to region Y. The vehicle performs the locking operation and returns a confirmation receipt. The terminal then displays a "Lock successful" message to the user.

[0121] This embodiment connects the previously described region identifier query process with cache updates and precise command issuance when identifiers are inconsistent, forming a complete collaborative logic on the terminal side. It ensures that subsequent operations do not require repeated queries by updating the local cache in real time, improving interaction efficiency. Furthermore, it avoids failures caused by sending commands to the wrong region through precise routing of the target region address. Simultaneously, optional backup mechanisms and pre-verification processes further guarantee the reliability and traceability of operations, perfecting the closed loop of region information synchronization between the terminal, server, and vehicle, improving the success rate of remote operations and user experience, and enhancing the system's adaptability in a multi-active architecture.

[0122] Based on any of the above embodiments, Embodiment Nine of this application proposes a disaster recovery switchover method for a vehicle management system, which is applied to a vehicle management system. Specifically, refer to... Figure 4 , Figure 4 The system architecture of the vehicle management system is shown.

[0123] The vehicle management system comprises vehicles, servers, and terminals. The server architecture is hierarchical, with one server deployed in each region, including vehicle control services, policy coordination services, a policy management platform, a business database, and an MQTT Cluster Manager. The policy management platform, a B2B operations platform, provides a configuration interface for operations personnel to add, delete, modify, and query policies, including APP policies, T-Box policies, canary deployment policies, and heartbeat policies. The policy coordination service, a B2C server, provides a policy query interface for APPs and T-Boxes to make policy changes. The MQTT Cluster Manager is the MQTT cluster management platform. After operations personnel modify the tbox_address of a corresponding vehicle model or bicycle, they push the change to the MQTT Cluster Manager. Upon receiving this information, the MQTT Cluster Manager proactively disconnects the long-lived connection between that vehicle model or bicycle and the MQTT server. Subsequently, when the vehicle reconnects to another region, the MQTT Cluster Managers in that region will also detect this and initiate a notification, informing the policy coordination service of the region code the vehicle is currently connected to, which then updates the tbox_region. The APP, or terminal, interacts with the policy-based collaborative service through regional addresses, while the vehicle, or T-BOX, interacts with the policy-based collaborative service through protocol addresses.

[0124] Based on the vehicle management system, disaster recovery and failover methods include: In response to a regional fault alarm, the server performs a primary / backup database switchover based on the databases of the faulty region and the region to be transferred. In response to maintenance input, it updates the target protocol address and target region address for each vehicle model corresponding to the region to be transferred. It also controls the cluster management platform of the faulty region to disconnect the service connection between the faulty region and each vehicle model based on the faulty protocol address. In response to a start command, the vehicle retrieves the server protocol address from its local cache. If the timestamp in the local cache times out, or the server protocol address connection fails, it retrieves the target protocol address from the server through a preset interface. It then executes the connection process with the cluster management platform using the target protocol address and stores the target protocol address in its local cache. In response to an address retrieval request initiated by the vehicle through a preset interface, the server returns the target protocol address to the vehicle. If the vehicle establishes a connection with the cluster management platform using the target protocol address, it determines the vehicle's current region and the faulty region. If the current region and the faulty region are inconsistent, the vehicle's region identifier is updated. In response to an operation command triggered by the terminal, the terminal retrieves the first region identifier of the vehicle paired with the terminal from its local cache; it requests the region identifier of the vehicle and the target region address of the terminal and the server from the server; if the first region identifier matches the region identifier, the terminal issues the operation command to the vehicle based on the target region address. In response to the address retrieval request initiated by the terminal, the server returns the region identifier to the terminal to prompt the terminal to determine the first region address of the vehicle. If the terminal determines that the first region identifier does not match the region identifier, it updates its local cache based on the region identifier; and issues the operation command to the vehicle based on the target region address.

[0125] For example, refer to Figure 5 and Figure 6After the vehicle (T-Box) is powered on, it first obtains the server's MQTT protocol address from the local cache for connection. If the cache (TTL is 30 days) expires or reconnection fails three times, it proactively obtains the vehicle's latest MQTT protocol address through an additional HTTPS high-availability interface, stores it in the cache, and re-establishes the connection, thus resolving the intelligent routing issue. The additional HTTPS interface is deployed in each region, using a separate domain name and Alibaba Cloud GTM to perform traffic round-robin scheduling to the NLB in each region, thereby achieving high availability for this interface. The app pre-caches the region code of the current vehicle locally. Before issuing commands, it proactively obtains the latest region code and the region's connection address from the server. If the regions match, the command is issued directly; otherwise, the local cache is updated, and the command is issued using the latest connection address, thus resolving the status discovery issue. When the app, server, and vehicle (T-Box) are all in the same region for an extended period, the data consistency issue can be resolved. The server configures the MQTT protocol address for each vehicle model or individual vehicle to connect to its corresponding region. If region A fails, the server gradually changes the region address of each vehicle model to the address corresponding to another region. After the vehicle retryes three times and fails, it will re-acquire the address of the other region until the vehicle re-establishes a connection with the other region. Then, the server-stored region code is updated via MQTT notification. In this way, each vehicle model in region A can be gradually rolled out to other regions, thus resolving the failover issue.

[0126] Referring to Table 1, which shows an example of configuring the address for a vehicle model.

[0127] Table 1, Example of Vehicle Configuration Information

[0128] Reference Figure 5 The strategy management platform, belonging to the B2B operations side, provides a configuration interface for operations personnel to perform CRUD operations on strategies, including APP strategies, T-Box strategies, canary deployment strategies, and heartbeat strategies. The strategy collaboration service, belonging to the B2C server side, provides a strategy query interface for APP and T-Box to make strategy changes. The MQTT Cluster Manager is the MQTT cluster management platform. After operations personnel modify the tbox_address of a corresponding vehicle model or bicycle, they push the change to the MQTT Cluster Manager. Upon receiving this information, the MQTT Cluster Manager proactively disconnects the long-lived connection between that vehicle model or bicycle and the MQTT server. Subsequently, when the vehicle reconnects to another region, the MQTT Cluster Manager in that region will also detect this and initiate a notification, informing the strategy collaboration service of the region code the vehicle is currently connected to, and the strategy collaboration service will then change the tbox_region.

[0129] Access Layer Design: After the vehicle (T-Box) powers on, it first obtains the server's MQTT protocol address from the local cache for connection. If the cache (TTL is 30 days) expires or reconnection fails three times, it proactively obtains the latest MQTT protocol address (tbox_address) for the vehicle through the policy query interface of the policy coordination service, stores it in the vehicle's local cache, and re-establishes the connection. The policy query interface of the policy coordination service is deployed in each region. Through an independent domain name (tsp-strategy.xxx.com), Alibaba Cloud GTM performs traffic round-robin scheduling to the NLB in each region, and then the NLB performs load balancing to realize the policy update of the T-Box. Before issuing commands, the APP proactively obtains the latest region code and region connection address from the server through strategy.xxx.com. If the regions are consistent, the command is issued directly; otherwise, the local cache is updated, and the command is issued using the latest connection address.

[0130] Application layer design: All services are tagged upon registration with the Nacos registry to ensure local data center priority during microservice inter-service calls. After service registration with the Nacos registry, bidirectional synchronization of service lists is required to ensure consistency between the two centers. If a service in one center fails, it can be rerouted to the same service in another center via the service list.

[0131] Data Layer Design: Under normal circumstances, regardless of whether it's the primary or secondary data center, application data is written exclusively to the primary data center's database. Here, we'll use Region A as the primary data center, with its database as the master database and the secondary data center's database as the backup database. Data in the master database needs to be synchronized to the backup database in real time. In the event of a database failure, write protection needs to be implemented on the master database, and the backup database needs to be promoted to master.

[0132] Reference Figure 6As an example of the overall failover process, M001: A regional failure begins. Due to force majeure or human factors, the entire region of Region A experiences a failure. M002: The failover process is initiated. After evaluation, the operations and maintenance personnel initiate the failover approval process until all relevant leaders agree. M003: After completing the database master-slave switch, the operations and maintenance personnel modify the policy and begin the database master-slave switch operation. First, write protection is disabled for the master database, and then the standby database is promoted to master. M004: The region is automatically changed. Then, the operations and maintenance personnel log in to the policy management platform and sequentially change the app_address of vehicle model A and vehicle model B to App2.xxx.com, and the tbox_address to Ecu2.xxx.com. After the operations and maintenance personnel modify the connection addresses of the APP and T-Box, the policy coordination service pushes a message to the MQTT Cluster Manager, forcibly disconnecting the vehicle model from the MQTT server. After three failed reconnections, the vehicles involved in this model proactively obtain the latest address through the policy query interface of the policy coordination service, store it in the vehicle's local cache, and re-establish the connection. After the MQTT Cluster Manager detects the connection, it queries the cache to determine if the vehicle's region has changed. If so, it sends a notification to the policy coordination service to change the app_region and tbox_region, such as changing from Hangzhou to Shanghai. M005: The APP issues commands. Before issuing commands, the APP includes the previous app_region query in the header to check if the region has changed. If the server determines that the region has changed, it returns the latest app_address. The APP then issues vehicle control commands based on the latest address. M006: Fault recovery policy rollback. After region A recovers, at a suitable time, such as during a low-traffic period in the early morning, the database master-slave configuration and related policies are rolled back according to the above steps.

[0133] The implementation process of this embodiment will be described below using a specific scenario. The vehicle management system deploys two off-site data centers, X and Y. Area X is the area that carries out daily business operations, and area Y is the backup area to be transferred. The vehicle models involved include core model A and ordinary model B. User A's vehicle is model A, and the terminal is a mobile phone with a server-side APP. Due to a sudden natural disaster, the data center in area X is paralyzed, and the server-side fault detection module automatically triggers an area fault alarm. After the server responds to the alarm, it first implements write protection on the primary database in region X, verifies the data consistency between the backup database and the primary database in region Y, and upgrades the backup database in region Y to the primary database, completing the primary-backup switch. Subsequently, the operations and maintenance personnel initiate operations and maintenance input through the policy management platform, select vehicle model A and vehicle model B, enter the MQTT target protocol address and target region address in region Y, and set the priority of vehicle model A to be higher than that of vehicle model B. The system updates the address configuration of vehicle model A first, and automatically updates the address configuration of vehicle model B after 30 minutes. Finally, the server sends a disconnect command to the cluster management platform in region X. The platform disconnects the service connections of vehicle model A and vehicle model B based on the faulty protocol address in region X in batches at a rate of 10% per minute, while monitoring the connection load in region Y to ensure load stability.

[0134] User A starts the vehicle. After the vehicle responds to the start command, it retrieves the MQTT protocol address for region X from its local cache. Verification reveals that the address's timestamp has been stored for 32 days (exceeding the 30-day timeout period). The vehicle abandons using this address and initiates an address retrieval request to the server via a pre-defined HTTPS interface. This request is scheduled by Alibaba Cloud GTM to the NLB in region Y, and then forwarded to the Policy Collaboration Service. The Policy Collaboration Service queries the target protocol address for vehicle model A in region Y and returns it to the vehicle. After receiving the address, the vehicle verifies that the format conforms to the MQTT protocol specification, sends a connection request to the cluster management platform in region Y, completes identity verification, and establishes a stable connection for 5 minutes. Then, the vehicle stores the target protocol address in its local cache and updates the timestamp to the current time.

[0135] After the cluster management platform in region Y detects a vehicle's connection, it determines the vehicle's current region as region Y and extracts the faulty region from the fault connection log as region X. Upon comparison and finding a discrepancy, the cluster management platform sends a region identifier update request to the policy coordination service. Upon receiving this request, the policy coordination service updates the vehicle's region identifier to the identifier corresponding to region Y and synchronizes it to the main data center in region Y, ensuring that all service nodes on the server side can obtain the latest region information.

[0136] User A wants to remotely turn on the vehicle's air conditioning via a terminal app. After triggering the operation command, the terminal executes step B10, retrieving the vehicle's first region identifier (X region identifier) ​​from its local cache. It then sends a request to the server, carrying the terminal identifier, vehicle identifier, and auxiliary information including the first region identifier. The server finds the vehicle's region identifier to be Y region identifier and returns the target region address for Y region. The terminal compares the two and finds a discrepancy between the first region identifier and the region identifier. It automatically replaces the locally cached X region identifier with the Y region identifier, updates the timestamp, and backs up the old identifier to a temporary directory. The terminal then sends a pre-verification request to the server node via the connection address for Y region. After confirming the connection is successful, it issues the remote air conditioning turn-on command. The server node receives the command and accurately forwards it to the vehicle. The vehicle performs the air conditioning start operation and returns a confirmation receipt. The terminal displays a "Air conditioning is on" message to User A.

[0137] Throughout the disaster recovery switchover process, the business was smoothly migrated from region X to region Y, vehicles remained online, terminal commands were executed accurately, and there was no data loss or service interruption. This fully demonstrated the advantages of the "human-vehicle-cloud collaboration" multi-active architecture and ensured the business continuity and stability of the server system in the face of regional failures.

[0138] This application provides a disaster recovery switching device for a vehicle management system. The disaster recovery switching device for a vehicle management system includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the disaster recovery switching method for the vehicle management system in the above embodiment 1.

[0139] The following is for reference. Figure 7 The diagram illustrates a structural schematic of a disaster recovery switching device suitable for implementing the vehicle management system embodiments of this application. The disaster recovery switching device for the vehicle management system in these embodiments may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital radio receivers, personal digital assistants (PDAs), tablets, and in-vehicle terminals, as well as fixed terminals such as digital TVs and desktop computers. Figure 7 The disaster recovery switchover device for the vehicle management system shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0140] like Figure 7As shown, the disaster recovery switching device of the vehicle management system may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The random access memory 1004 also stores various programs and data required for the operation of the disaster recovery switching device of the vehicle management system. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the vehicle management system's disaster recovery switchover device to communicate wirelessly or wiredly with other devices to exchange data. Although a vehicle management system's disaster recovery switchover device with various systems is shown in the figure, it should be understood that implementing or having all the systems shown is not required. More or fewer systems can be implemented alternatively.

[0141] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0142] The vehicle management system disaster recovery switching device provided in this application, employing the vehicle management system disaster recovery switching method in the above embodiments, can solve the technical problem of long service recovery time when city-level server failures occur. Compared with the prior art, the beneficial effects of the vehicle management system disaster recovery switching device provided in this application are the same as those of the vehicle management system disaster recovery switching device provided in the above embodiments, and other technical features in this vehicle management system disaster recovery switching device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0143] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0144] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0145] This application also provides a disaster recovery switching device for a vehicle management system, the disaster recovery switching device for the vehicle management system comprising: The database switching unit is configured to perform a primary / standby database switching action based on the database of the faulty area and the area to be switched to in response to a regional fault alarm triggered for the faulty area. The strategy coordination unit is configured to update the target protocol address and target area address of each vehicle model corresponding to the area to be transferred to in response to the operation and maintenance input for the fault area; and control the cluster management platform of the fault area to disconnect the service connection between each vehicle model and the fault protocol address.

[0146] Optionally, the strategy coordination unit is further configured to return the target protocol address to the vehicle in response to an address acquisition request initiated by the vehicle through a preset interface.

[0147] Optionally, the policy coordination unit is further configured to, if the vehicle establishes a connection with the cluster management platform of the region to be transferred through the target protocol address, determine whether the region in the cache is consistent with the region to be transferred; if the region in the cache is inconsistent with the region to be transferred, update the region identifier of the vehicle based on the region to be transferred.

[0148] Optionally, the policy coordination unit is further configured to respond to a first area identifier sent by a terminal communicating with the vehicle, and if the first area identifier is inconsistent with the area identifier, return the target area address of the vehicle to the terminal.

[0149] Optionally, the strategy coordination unit is further configured to, in response to a rollback command triggered for the faulty area, control the cluster management platform of the faulty area to restore the service connection with each vehicle model based on the fault protocol address, and update the corresponding switched fault protocol address and faulty area address for each vehicle model, so as to execute the rollback command.

[0150] Optionally, this embodiment also provides a disaster recovery switching device for a vehicle management system. In some implementations, the disaster recovery switching device for the vehicle management system can be a vehicle, including: The first protocol acquisition unit is configured to acquire the server protocol address from the local cache in response to the startup command; the anomaly detection unit is configured to detect network connection anomalies; the first connection unit is configured to acquire the target protocol address from the server through a preset interface; the first protocol acquisition unit is configured to store the target protocol address in the local cache; and the first connection unit is configured to execute a connection process through the target protocol address.

[0151] Furthermore, the anomaly detection unit is configured to detect network connection anomalies, which include at least one of the following: the local cache timestamp timeout; the server protocol address connection failure.

[0152] Optionally, this embodiment also provides a disaster recovery switching device for a vehicle management system. In some implementations, the disaster recovery switching device for the vehicle management system can be a vehicle communication terminal, including: The second protocol acquisition unit is configured to acquire the first area identifier of the vehicle paired with the terminal from a local cache in response to an operation command triggered by the terminal. The second connection unit is configured to send the first region identifier to the server so that the server can verify the first region address and the region address; if it receives the target region address and region identifier returned by the server, it issues the operation command to the vehicle based on the target region address. The second protocol acquisition unit is further configured to update the first region identifier in the local cache according to the region identifier.

[0153] Furthermore, the second connection unit is also configured to, upon receiving information from the server indicating a match for the first region identifier, issue the operation instruction to the vehicle based on the region address obtained from the local cache.

[0154] The vehicle management system disaster recovery switching device provided in this application, employing the vehicle management system disaster recovery switching method in the above embodiments, can solve the technical problem of long service recovery time when city-level servers fail. Compared with the prior art, the beneficial effects of the vehicle management system disaster recovery switching device provided in this application are the same as those of the vehicle management system disaster recovery switching method provided in the above embodiments, and other technical features in the vehicle management system disaster recovery switching device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0155] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the disaster recovery switching method of the vehicle management system in the above embodiments.

[0156] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, radio frequency (RF), or any suitable combination thereof.

[0157] The aforementioned computer-readable storage medium may be included in the disaster recovery switching device of the vehicle management system; or it may exist independently and not be installed in the disaster recovery switching device of the vehicle management system.

[0158] The aforementioned computer-readable storage medium carries one or more programs. When the aforementioned one or more programs are executed by the disaster recovery switching device of the vehicle management system, the disaster recovery switching device of the vehicle management system: in response to a regional fault alarm, performs a primary / backup database switching action based on the databases of the faulty region and the region to be transferred; in response to maintenance input, updates the target protocol address and target region address of the region to be transferred for each vehicle model; and controls the cluster management platform of the faulty region to disconnect the service connection between the faulty region and each vehicle model based on the faulty protocol address.

[0159] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0160] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0161] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0162] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the disaster recovery switching method of the vehicle management system described above. This addresses the technical problem of long service recovery times during city-level server failures. Compared to existing technologies, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the disaster recovery switching method of the vehicle management system provided in the above embodiments, and will not be elaborated upon here.

[0163] This application provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the disaster recovery switchover method for a vehicle management system as described above.

[0164] The computer program product provided in this application can solve the technical problem of long service recovery time when city-level servers fail. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as the beneficial effects of the disaster recovery switching method for the vehicle management system provided in the above embodiments, and will not be repeated here.

[0165] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent scope of this application.

Claims

1. A method for failover switching of a vehicle management system, characterized in that, The disaster recovery switching method of the vehicle management system comprises: In response to a region fault alarm triggered for a fault region, performing a master-slave database switching action based on the fault region and a database of a region to be switched into; In response to an operation input for the fault region, updating a target protocol address and a target region address of each vehicle model corresponding to the region to be switched into; Controlling a cluster management platform of the fault region to disconnect service connection with each vehicle model based on a fault protocol address.

2. The failover switching method of a vehicle management system according to claim 1, characterized by, After the step of controlling the cluster management platform of the fault region to disconnect service connection with each vehicle model based on the fault protocol address, the method comprises: In response to an address acquisition request initiated by a vehicle through a preset interface, returning the target protocol address to the vehicle.

3. The failover switching method of a vehicle management system according to claim 2, wherein After the step of in response to an address acquisition request initiated by a vehicle through a preset interface, returning the target protocol address to the vehicle, the method comprises: If the vehicle establishes connection with the cluster management platform of the region to be switched into through the target protocol address, determining whether the region in the cache is consistent with the region to be switched into; If the region in the cache is not consistent with the region to be switched into, updating the region identifier of the vehicle based on the region to be switched into.

4. The failover switching method of a vehicle management system according to claim 3, characterized by, After the step of updating the region identifier of the vehicle, the method comprises: In response to a first region identifier sent by a terminal in communication with the vehicle, if the first region identifier is not consistent with the region identifier, returning a target region address of the vehicle to the terminal.

5. The failover switching method of a vehicle management system according to claim 1, wherein After the step of controlling the cluster management platform of the fault region to disconnect service connection with each vehicle model based on the fault protocol address, the method comprises: In response to a rollback instruction triggered for the fault region, controlling the cluster management platform of the fault region to restore service connection with each vehicle model based on the fault protocol address, and updating a fault protocol address and a fault region address corresponding to each vehicle model after switching, so as to execute the rollback instruction.

6. A failover switching method of a vehicle management system, characterized by, The disaster recovery switching method of the vehicle management system comprises: In response to a start instruction, acquiring a service end protocol address from a local cache; In response to a network connection exception being met, acquiring a target protocol address from a service end through a preset interface; Performing a connection process through the target protocol address, and storing the target protocol address in the local cache.

7. The failover switching method of a vehicle management system according to claim 6, wherein The network connection exception comprises at least one of the following: A time stamp of the local cache is overdue; The service end protocol address connection fails.

8. A method of failover for a vehicle management system, the method comprising: The disaster recovery switching method of the vehicle management system applied to a terminal in communication with a vehicle comprises: In response to an operation instruction triggered by the terminal, acquiring a first region identifier of a vehicle paired with the terminal from a local cache, and sending the first region identifier to a service end, so that the service end verifies the first region identifier and a region identifier; If a target region address and a region identifier returned by the service end are received, issuing the operation instruction to the vehicle based on the target region address; Updating the first region identifier in the local cache according to the region identifier.

9. The failover switching method of a vehicle management system according to claim 8, wherein After the step of sending the first region identifier to the service end, the method comprises: If the matching consistent information for the first area identifier returned by the server is received, the operation instruction is issued to the vehicle based on the area address obtained from the local cache.

10. A failover switching device of a vehicle management system, characterized by, The disaster recovery switching device of the vehicle management system comprises a memory, a processor, and a computer program stored in the memory and executable on the processor, and the computer program is configured to implement the steps of the disaster recovery switching method of the vehicle management system according to any one of claims 1 to 5 or 6-7 or 8-9.

11. A storage medium, characterized by The storage medium is a computer readable storage medium, and the computer readable storage medium stores a computer program, and the computer program is executed by the processor to implement the steps of the disaster recovery switching method of the vehicle management system according to any one of claims 1 to 5 or 6-7 or 8-9.

12. A computer program product, characterised in that, The computer program product comprises a computer program, and the computer program is executed by the processor to implement the steps of the disaster recovery switching method of the vehicle management system according to any one of claims 1 to 5 or 6-7 or 8-9.

Images