Multi-terminal cooperative control method, device and equipment for charging and battery swapping service

Abstract

The present application relates to the technical field of charging and battery swapping equipment control, solves the problem that the prior art cannot realize cooperative battery swapping control among the user end, the cabinet end and the platform background under different network connection states, and provides a multi-end cooperative control method, device and equipment for charging and battery swapping services, the method comprising: in response to a battery swapping request, obtaining the connection state between the cabinet end and the platform background; if the connection state is normal connection, determining target battery swapping execution information according to the battery swapping request and cabinet state information; if the connection state is interrupted connection, sending offline authentication information and a battery swapping instruction to the cabinet end; locally verifying the offline authentication information, and after verification, determining target battery swapping execution information according to the battery swapping instruction and offline decision data; and performing a battery swapping operation according to the target battery swapping execution information to obtain a battery swapping execution result. The present application improves the service availability and operation reliability of the charging and battery swapping system in a complex network environment.

Description

Technical Field

[0001] This invention relates to the field of charging and swapping equipment control technology, and in particular to a multi-terminal collaborative control method, device and equipment for charging and swapping services. Background Technology

[0002] With the rapid development of the new energy industry, two-wheeled vehicles such as electric bicycles and electric motorcycles are increasingly used in urban delivery and personal commuting. To shorten battery recharging time, battery swapping stations are gradually becoming important energy supply equipment for two-wheeled vehicles. Existing charging and swapping systems typically include a user terminal, a platform backend, and a swapping station. Users initiate swapping requests through the user terminal, the platform backend processes the swapping business based on user information, battery information, and station status, and the swapping station performs operations such as opening the compartment, battery detection, and battery retrieval and placement based on the corresponding swapping execution information. Therefore, a single battery swapping operation usually requires collaborative communication and control between the user terminal, the platform backend, and the swapping station.

[0003] In existing technologies, when the terminal and the platform backend maintain normal communication, the platform backend typically handles battery swapping eligibility verification, target battery matching, and bay allocation before controlling the terminal to execute the corresponding battery swapping operation. However, when the network connection between the terminal and the platform backend fails, the original battery swapping control link, which relies on the real-time participation of the platform backend, is easily interrupted. Although existing solutions have proposed processing methods such as local terminal interaction, offline battery swapping codes, short-range communication, and dynamic passwords for different offline scenarios, online and offline battery swapping usually employ independent processing mechanisms. The functions and decision-making relationships undertaken by the user end, terminal, and platform backend under different network conditions lack a unified collaborative control method, making it difficult to maintain the continuous execution of battery swapping services when network conditions change. Existing technologies also suffer from insufficient multi-terminal status synchronization and terminal offline processing capabilities.

[0004] For example, Chinese patent CN111105565A discloses an offline battery swapping method and system for a battery swapping cabinet. When the cabinet is offline, the user enters their account information via the cabinet's touchscreen, and the cabinet reads the battery number, selects the corresponding fully charged battery, and completes the local battery swapping via a verification code. This offline swapping primarily relies on local interaction between the user and the cabinet. Chinese patent CN113382396A discloses an offline battery swapping method, system, and device. When the mobile terminal experiences communication failure, the battery swapping cabinet continues to communicate with the battery swapping platform, verifying user and battery information and determining the swapping command through the platform. Its battery swapping control still depends on real-time communication between the cabinet and the platform backend. Existing Chinese patent CN114630307A discloses a battery swapping method and system with both the battery swapping cabinet and server offline. When both the battery swapping cabinet and server are offline, the client sends an authentication request generated based on local battery swapping parameters to the battery swapping cabinet via Bluetooth, enabling the client to directly complete the battery swap with the cabinet. However, the platform backend does not participate in real-time battery swapping control during this offline process. Existing Chinese patent CN114067497A achieves offline battery swapping through dynamic passwords and battery identification codes. Although the above solutions can adapt to specific network anomaly scenarios, they have not yet formed a control mechanism that can switch and coordinate the battery swapping decision-making and execution relationships between the user end, the battery swapping cabinet end, and the platform backend based on the connection status between the cabinet end and the platform backend.

[0005] Therefore, how to achieve coordinated battery swapping control between the user end, the cabinet end, and the platform backend under different network connection states is a technical problem that urgently needs to be solved. Summary of the Invention

[0006] In view of this, embodiments of the present invention provide a multi-terminal collaborative control method, apparatus and equipment for charging and battery swapping services, in order to solve the problem that the prior art cannot achieve collaborative battery swapping control between the user terminal, the cabinet terminal and the platform backend under different network connection states.

[0007] In a first aspect, embodiments of the present invention provide a multi-terminal collaborative control method for charging and battery swapping services, applied to a multi-terminal collaborative control system for charging and battery swapping services. The system includes a user terminal, a cabinet terminal, and a platform backend. The user terminal is communicatively connected to both the cabinet terminal and the platform backend. The cabinet terminal is communicatively connected to the platform backend. The method includes: In response to the battery swapping request initiated by the user terminal for the cabinet terminal, the connection status between the cabinet terminal and the platform backend is obtained; If the connection status is normal, then the target battery swap execution information is determined based on the battery swap request and the cabinet status information corresponding to the cabinet terminal. If the connection status is interrupted, the offline authentication information provided by the platform backend and the battery swapping instruction corresponding to the battery swapping request will be sent to the cabinet terminal through the user terminal; The offline authentication information is locally verified by the cabinet terminal, and after the verification is successful, the target battery swap execution information is determined based on the battery swap instruction and the offline decision data pre-stored in the cabinet terminal. Based on the target battery swapping execution information, the cabinet terminal is controlled to perform a battery swapping operation, and the battery swapping execution result is obtained.

[0008] Preferably, the step of obtaining the connection status between the cabinet terminal and the platform backend in response to the battery swapping request initiated by the user terminal for the cabinet terminal includes: The platform backend receives the battery swapping request sent by the user terminal and extracts the user identity token from the access request corresponding to the battery swapping request. Based on the user identity token, determine the target role of the user corresponding to the user terminal; Based on the battery swapping request, determine the corresponding target resources and target operations; The target resource and the target operation are matched with the permission matrix corresponding to the target role to obtain the permission matching result; When the permission matching result is a successful match, the user data and cabinet data corresponding to the battery swapping request are verified for access permissions according to the data permission range corresponding to the target role, and the data permission verification result is obtained. When the data permission verification result is successful, the battery swapping request is accepted, and the connection status between the cabinet terminal and the platform backend is obtained.

[0009] Preferably, the step of locally verifying the offline authentication information through the cabinet terminal, and determining the target battery swap execution information based on the battery swap instruction and the offline decision data pre-stored on the cabinet terminal after successful verification, includes: Based on the offline authentication information, obtain the user token corresponding to the battery swapping request; The user token is matched with the list of authorized user tokens in the offline decision data, and it is determined whether the user token is within the validity period. Based on the matching result and the validity period determination result, the local authentication result is determined. When the local authentication result is successful, the target battery model corresponding to the battery swapping request is determined according to the battery swapping instruction. The target battery model is matched with the battery model whitelist in the offline decision data to obtain the model matching result; When the model matching result is a successful match, the second candidate fully charged battery compartment and the second candidate empty battery compartment are determined according to the target battery model and the battery compartment mapping table in the offline decision data. The target fully charged battery compartment and the target empty battery compartment are determined from the second candidate fully charged battery compartment and the second candidate empty battery compartment, respectively, and the target battery swapping execution information is determined based on the target fully charged battery compartment and the target empty battery compartment.

[0010] Preferably, the step of matching the user token with the list of authorized user tokens in the offline decision data and determining whether the user token is within its validity period, and determining the local authentication result based on the matching result and the validity period determination result, includes: Extract the credential payload and signature information corresponding to the user token from the offline authentication information; The signature information is verified using the verification public key pre-stored at the terminal of the machine to obtain the signature verification result. When the signature verification result is successful, the credential user identifier and credential validity period are determined based on the credential payload; The user identifier of the credential is compared with the user identifier corresponding to the battery swapping instruction to obtain a user identifier consistency result; The user token is matched with the list of authorized user tokens to obtain the token matching result; The local authentication result is determined based on the signature verification result, the user identifier consistency result, the token matching result, and the credential validity period.

[0011] Preferably, when the model matching result is a successful match, determining the second candidate fully charged storage compartment and the second candidate empty storage compartment based on the target battery model and the storage compartment battery mapping table in the offline decision data includes: Based on the battery mapping table for each compartment, determine the battery storage information corresponding to each compartment in the cabinet terminal; Based on the battery storage information corresponding to each of the aforementioned compartments, determine the first set of compartments with stored batteries and the second set of compartments without stored batteries; Based on the battery information corresponding to each compartment in the first compartment set, the compartments whose battery models match the target battery model and whose corresponding batteries meet the full charge condition are selected from the first compartment set to obtain the second candidate fully charged compartments; The storage spaces in the second storage space set that meet the battery return conditions are determined as the second candidate empty battery storage spaces.

[0012] Preferably, the step of controlling the cabinet terminal to perform a battery swapping operation based on the target battery swapping execution information, and obtaining the battery swapping execution result, includes: According to the target battery swap execution information, the cabinet terminal is controlled to perform a battery swap operation according to a preset battery swap process. The preset battery swap process includes a battery swap instruction reception and confirmation stage, an empty battery compartment opening stage, a battery return confirmation stage, a fully charged compartment opening stage, a battery removal confirmation stage, and a battery swap completion confirmation stage. Based on the preset battery swapping process and the current execution status of the cabinet terminal during the battery swapping operation, the current battery swapping stage is obtained; Based on the current battery swapping stage, the corresponding target detection object, target detection parameters, and stage completion conditions are determined from the preset stage anomaly detection strategy library; Based on the target detection parameters, the target object is detected to obtain the detection result for the current stage; When the current stage detection result does not meet the stage completion condition, the abnormal event corresponding to the current stage detection result is handled to obtain the abnormal handling result. Based on the anomaly handling result, when it is determined that the current stage detection result after anomaly handling meets the stage completion condition, the cabinet terminal is controlled to enter the next battery swapping stage in the preset battery swapping process, and the next battery swapping stage is returned as the new current battery swapping stage to the step of determining the corresponding target stage anomaly detection strategy from the preset stage anomaly detection strategy library based on the current battery swapping stage, until all battery swapping stages in the preset battery swapping process are completed, and the battery swapping execution result is obtained.

[0013] Preferably, the step of detecting the target object according to the target detection parameters to obtain the detection result at the current stage includes: Based on the phase execution action corresponding to the current battery swapping phase, a target anomaly detection chain is obtained. The target anomaly detection chain includes multiple step-by-step detection links arranged in the order of execution of the phase execution actions. Each step-by-step detection link corresponds to at least one target detection object and at least one target detection parameter. According to the arrangement order of each step of the target anomaly detection chain and the target detection parameters, the corresponding target detection object is detected step by step, and the detection completion status of the current step by step detection link is used as the starting condition for the next step by step detection link. When the detection result of the current step by step detection link meets the corresponding link completion condition, the next step by step detection link is started. When the detection result of any of the step-by-step detection steps does not meet the corresponding step completion condition, the current stage detection result is determined to be that the stage completion condition is not met, and the execution of subsequent step-by-step detection steps is stopped. When the detection results of each of the step-by-step detection stages meet the corresponding stage completion conditions, the detection result of the current stage is determined to meet the stage completion conditions.

[0014] Preferably, when the current stage detection result does not meet the stage completion condition, the abnormal event corresponding to the current stage detection result is subjected to abnormal handling, and the abnormal handling result includes: Extract detection anomalies that do not meet the stage completion conditions from the current stage detection results, and associate each detection anomaly with the stage execution action corresponding to the current battery swapping stage to form at least one candidate anomaly event; Based on the current battery swapping stage, a target abnormal event relationship chain corresponding to the current battery swapping stage is determined from a preset abnormal event relationship chain. The target abnormal event relationship chain is used to characterize the sequential occurrence relationship and abnormal impact relationship between different abnormal events in the current battery swapping stage. Each candidate abnormal event is matched with an abnormal event in the target abnormal event relationship chain to determine the abnormal occurrence position of each candidate abnormal event in the target abnormal event relationship chain, and the association relationship between each candidate abnormal event is determined based on the abnormal occurrence position. For candidate abnormal events with a relationship, reverse tracing is performed according to the abnormal influence direction in the relationship chain of the target abnormal event. The upstream abnormal event that causes other candidate abnormal events and is not caused by other candidate abnormal events is identified as the target abnormal event, and the other candidate abnormal events caused by the target abnormal event are identified as the accompanying abnormal events. Based on the abnormal event type corresponding to the target abnormal event and the phase completion conditions of the current battery swapping phase, the target abnormal handling action is determined from the preset abnormal handling strategy, and the battery swapping cabinet is controlled to execute the target abnormal handling action to obtain the abnormal handling result.

[0015] Secondly, embodiments of the present invention provide a multi-terminal collaborative control device for charging and battery swapping services, applied to a multi-terminal collaborative control system for charging and battery swapping services. The system includes a user terminal, a cabinet terminal, and a platform backend. The user terminal is communicatively connected to both the cabinet terminal and the platform backend. The cabinet terminal is communicatively connected to the platform backend. The device includes: The connection status acquisition module is used to acquire the connection status between the cabinet terminal and the platform backend in response to the battery swapping request initiated by the user terminal for the cabinet terminal. A normal connection battery swapping processing module is used to determine the target battery swapping execution information based on the battery swapping request and the cabinet status information corresponding to the cabinet terminal if the connection status is normal. The connection interruption battery swapping processing module is used to send the offline authentication information provided by the platform backend and the battery swapping instruction corresponding to the battery swapping request to the cabinet terminal through the user terminal if the connection status is a connection interruption. The offline processing module is used to perform local verification of the offline authentication information through the cabinet terminal, and after the verification is successful, determine the target battery swap execution information based on the battery swap instruction and the offline decision data pre-stored in the cabinet terminal; The battery swapping execution module is used to control the cabinet terminal to perform a battery swapping operation based on the target battery swapping execution information, and obtain the battery swapping execution result.

[0016] Thirdly, embodiments of the present invention provide an electronic device, including: at least one processor, at least one memory, and computer program instructions stored in the memory, which, when executed by the processor, implement the method of the first aspect described above.

[0017] In summary, the beneficial effects of the present invention are as follows: The multi-terminal collaborative control method, device, and equipment for charging and swapping services provided in this invention establish a multi-terminal communication relationship between the user terminal, the cabinet terminal, and the platform backend. The connection status between the cabinet terminal and the platform backend serves as the basis for switching the swapping control path, enabling the system to adopt appropriate swapping decision-making methods for different network states. When the connection between the cabinet terminal and the platform backend is normal, the platform backend determines the target swapping execution information by combining the swapping request initiated by the user terminal and the corresponding cabinet status information. This allows for unified swapping decisions using user, equipment, and storage space information held by the platform backend. When the connection between the cabinet terminal and the platform backend is interrupted, the user terminal forwards the offline authentication information and swapping instructions provided by the platform backend to the cabinet terminal, leveraging the user terminal's ability to communicate with both the platform backend and the cabinet terminal. This allows the cabinet terminal to verify the legitimacy of the swapping request locally even when it cannot access the platform backend in real time, and autonomously determine the target swapping execution information based on pre-stored offline decision data, thus continuing the swapping operation. Therefore, this solution does not simply terminate the battery swapping service when the network is interrupted, nor does it allow the charging station to operate independently without platform authorization. Instead, it adaptively switches between "platform backend decision-making" and "charging station local decision-making" based on the network connection status. At the same time, it utilizes the user terminal to handle information transmission in offline scenarios, so that both online and offline battery swapping paths are ultimately unified and reduced to the battery swapping execution control of the charging station. This improves the coordination capabilities of the user terminal, charging station, and platform backend under network status changes, reduces the impact of communication interruptions between the charging station and the platform backend on the continuity of the battery swapping service, and takes into account the authorization reliability and the autonomous execution capability of the charging station during offline battery swapping, thereby improving the service availability and operational reliability of the charging and swapping system in complex network environments. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the embodiments of the present invention will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort, and these are all within the protection scope of the present invention.

[0019] Figure 1 This is a schematic diagram of the structure of the multi-terminal collaborative control system for charging and swapping services in Embodiment 1 of the present invention; Figure 2 This is a schematic diagram of the overall process of the multi-terminal collaborative control method for charging and swapping services in Embodiment 1 of the present invention; Figure 3 This is a flowchart illustrating the exception event-driven engine processing logic in Embodiment 1 of the present invention; Figure 4 This is a schematic diagram of the structure of the multi-terminal collaborative control device for charging and swapping services in Embodiment 2 of the present invention; Figure 5 This is a schematic diagram of the electronic device in Embodiment 3 of the present invention. Detailed Implementation

[0020] The features and exemplary embodiments of various aspects of the present invention will now be described in detail. To make the objectives, technical solutions, and advantages of the present invention clearer, the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only configured to explain the present invention and are not configured to limit the present invention. For those skilled in the art, the present invention can be practiced without some of these specific details. The following description of the embodiments is merely intended to provide a better understanding of the present invention by illustrating examples of the invention.

[0021] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes said element.

[0022] It should be noted that all actions involving the acquisition of signals, information, or data in this invention are carried out in compliance with the relevant data protection laws and regulations of the locality and with authorization from the owner of the relevant device.

[0023] Example 1 Please see Figure 1 This invention provides a multi-terminal collaborative control method for charging and battery swapping services, which is applied to a multi-terminal collaborative control system for charging and battery swapping services. The system includes a user terminal, a cabinet terminal, and a platform backend. The user terminal is communicatively connected to the cabinet terminal and the platform backend, respectively, and the cabinet terminal is communicatively connected to the platform backend.

[0024] Specifically, the multi-terminal collaborative control system for charging and battery swapping services is a cloud-and-field collaborative architecture consisting of a user terminal responsible for user interaction and information relay, a platform backend responsible for business decision-making and data management, and a cabinet terminal responsible for on-site battery swapping execution. The user terminal is deployed on the user's mobile terminal, using an application or mini-program as the interaction entry point to complete tasks such as cabinet location, scanning for battery swapping, applying for battery swapping, checking order status, and sending and receiving information during the battery swapping process. The platform backend is deployed on a cloud server, centrally maintaining user information, order information, cabinet and battery asset information, and undertaking business control tasks such as user qualification verification, bay allocation, battery swapping instruction generation, status management, and anomaly handling. The cabinet terminal is deployed in the local control hardware of the battery swapping cabinet, directly controlling the electromagnetic lock and detecting on-site information such as bay door status, battery presence status, battery charge, and battery identification through a bay door control module and a battery detection module. This forms a three-terminal structure where user interaction, backend decision-making, and on-site execution are separated yet collaborative.

[0025] In terms of communication, the user terminal and the platform backend can communicate bidirectionally via HTTPS interface for battery swapping applications, cabinet status reporting, battery swapping instructions, order status, and other business data, and can receive status updates via WebSocket and other methods. The user terminal and the cabinet terminal establish a short-range communication connection via Bluetooth Low Energy (BLE), and complete the writing of control instructions and the feedback of cabinet status, door changes, and battery swapping completion information based on the instruction and response feature values ​​in the GATT service. This allows the user terminal to not only interact directly with the cabinet terminal, but also to act as an information relay node between the platform backend and the cabinet terminal when needed. The cabinet terminal and the platform backend can communicate via MQTT or HTTP long connections for the transmission of device heartbeat, compartment status, battery status, alarm information, and control instructions, enabling the platform backend to monitor the online status and on-site operation of the cabinet terminal.

[0026] By setting up the above three communication links, when the communication between the cabinet terminal and the platform backend is normal, the platform backend can directly participate in the unified decision-making and control of the battery swapping business. When the remote link between the cabinet terminal and the platform backend is interrupted, the communication paths between the user terminal and the platform backend, as well as between the user terminal and the cabinet terminal, are still maintained. This provides a communication foundation for the user terminal to forward offline authentication information and battery swapping instructions, and for the cabinet terminal to execute local battery swapping decisions. Therefore, it can avoid the entire battery swapping business from relying on a single communication link, improve the flexibility of multi-terminal collaborative control under different network conditions, and enhance the continuous execution capability of the battery swapping business.

[0027] Please see Figure 2 The method includes: In response to the battery swapping request initiated by the user terminal for the cabinet terminal, the connection status between the cabinet terminal and the platform backend is obtained; Specifically, when a user initiates a battery swap service, the user first needs to determine the specific cabinet corresponding to the swap. For example, the user can identify the target cabinet by scanning the QR code on the cabinet or manually entering the cabinet number, and then generate a swap request containing the cabinet number, user ID, current battery model, and target battery model. After accepting the swap request, the system does not immediately proceed to cabinet allocation. Instead, it first determines whether the target cabinet and the platform backend have normal data communication capabilities. The cabinet and the platform backend can maintain a long MQTT or HTTP connection and periodically transmit device heartbeats. The heartbeats can carry information such as the cabinet number, firmware version, network status, and timestamp. If the platform backend continuously receives heartbeats, the connection is considered normal. If no heartbeat is received for a preset number of consecutive times, or if the cabinet does not receive a response from the platform backend for a preset number of consecutive times, the connection is considered interrupted. For example, in practical applications, the cabinet can send an MQTT heartbeat every 30 seconds. If no response is received for three consecutive times, it can be determined that the cabinet can no longer communicate normally with the platform backend. By prioritizing the confirmation of the connection status after a battery swap request is generated, the system can clarify the currently available communication conditions before making a formal battery swap decision. This provides a reliable basis for the subsequent selection of whether to make an online decision on the platform backend or an offline decision on the cabinet end, and avoids the battery swap process from being stalled for a long time due to waiting for the cloud to return the result when the network is interrupted.

[0028] If the connection status is normal, then the target battery swap execution information is determined based on the battery swap request and the cabinet status information corresponding to the cabinet terminal. Specifically, once it's confirmed that normal communication is possible between the terminal and the platform backend, the user service information maintained by the platform backend and the real-time status of the terminal can be fully utilized to complete the battery swapping decision. Terminal status information includes not only whether the terminal is online, but also on-site data such as the door open / closed status of each compartment, the presence of batteries inside, and the corresponding battery's SOC. The terminal can first scan each compartment, then send the scan results to the user terminal via Bluetooth. The user terminal then uploads the data to the platform backend via HTTPS, ensuring that the compartment status in the backend database is as consistent as possible with the actual on-site status. Based on this, the platform backend verifies the user's real-name authentication status, whether the service plan is valid, and the remaining number of swaps or available time based on the user ID in the battery swapping request. Simultaneously, it searches for a fully charged battery available for swapping within the current terminal based on the target battery model. For example, when a user currently uses a 60V battery and requests a replacement with a fully charged battery of the same model, the platform's backend can filter the storage locations from the storage location information to find locations that store 60V batteries and whose charge meets the battery swap requirements. Simultaneously, it can find an empty storage location that is not currently storing a battery and can be used by the user to return the old battery. Then, it can determine the target fully charged storage location and the target empty storage location. These two storage location numbers, along with the battery model related to this swap, constitute the target battery swap execution information required by the locker. This process incorporates the user's battery swap eligibility, battery model requirements, and the actual storage location status at the locker location into the decision-making process, reducing the likelihood of incorrectly issuing a battery swap task even when the user is eligible but the locker has no matching battery, or when the backend records an empty storage location that is actually occupied.

[0029] If the connection status is interrupted, the offline authentication information provided by the platform backend and the battery swapping instruction corresponding to the battery swapping request will be sent to the cabinet terminal through the user terminal; Specifically, when the communication link between the cabinet terminal and the platform backend is interrupted, the platform backend can no longer directly send battery swapping control information to the cabinet terminal through the original cabinet network. Therefore, an alternative transmission path is formed by utilizing the user terminal, which can still connect to the platform backend and the cabinet terminal respectively. Offline authentication information is used to prove that the current user or the current battery swapping service has been authorized by the platform. Specifically, a JWT offline authentication certificate pre-issued by the platform backend can be used. This certificate can store the user's unique identifier, user role, issuance time, expiration time, etc., and is digitally signed by the platform backend using a cloud private key. The battery swapping instruction can carry the user identifier, order information, and battery model or warehouse-related business information corresponding to this battery swap. In actual execution, the user terminal can first obtain the above certificate and battery swapping information from the platform backend through a cellular network or other available network, then enable Bluetooth scanning, locate the target cabinet terminal through the service UUID and cabinet terminal number, establish a BLE / GATT connection with the cabinet terminal, and write the offline authentication certificate and battery swapping instruction to the cabinet terminal through the instruction feature value opened by the cabinet terminal. For example, if the 4G module of the battery swapping cabinet at a user's site loses network access, but the user's mobile phone can still access the platform's backend, the user's mobile phone essentially forms a short-range relay link between the platform and the cabinet, enabling the authorization information provided by the platform to reach the field equipment despite the cabinet's own network failure. Here, the user's terminal mainly plays the role of information pass-through and does not decide which specific battery compartment to open on the user's mobile phone. This maintains the control relationship of the platform backend as the source of authorization while solving the problem of control information failing to reach the field equipment after the cabinet's remote communication is interrupted.

[0030] The offline authentication information is locally verified by the cabinet terminal, and after the verification is successful, the target battery swap execution information is determined based on the battery swap instruction and the offline decision data pre-stored in the cabinet terminal. Specifically, after receiving the offline authentication information forwarded by the user, the terminal needs to verify the legitimacy of the information without real-time intervention from the platform backend before allowing the use of locally cached data for battery swapping decisions. Local verification can begin by using the verification public key pre-stored on the terminal to verify the digital signature in the offline authentication credential, confirming that the credential was indeed issued by the platform backend holding the corresponding private key and has not been tampered with during transmission. Subsequently, the expiration time in the credential can be checked, and the user's unique identifier in the credential payload can be compared with the user identifier independently carried in the battery swapping instruction. Only when the signature is correct, the credential is not expired, and the two user identifiers match is the offline battery swap considered to be trusted and authorized. After completing this layer of security verification, the terminal further calls the offline decision cache ODC. The ODC is data synchronized from the platform backend and saved locally during normal network connectivity of the terminal, and may include a list of authorized user tokens, a battery model whitelist, a battery mapping table for battery bays, and time synchronization deviation values. The terminal can first confirm whether the current user's token is still in the valid token list, then determine whether the target battery model requested by the user is a model that allows battery swapping. Subsequently, it queries the battery mapping table for each bay to check the current battery's serial number (SN), charge level, and status, selecting a fully charged or empty bay that meets the requirements. For example, if the terminal's cache shows that bay 1 is empty, bay 3 has a 60V battery with a SOC meeting the full charge condition, and the other bays are charging or faulty, bay 1 can be considered as a candidate bay for returning the old battery, and bay 3 as a candidate bay for swapping out the new battery. This forms the target battery swapping execution information for the current offline state. In this way, even without real-time communication with the platform, the terminal does not unconditionally accept user commands. Instead, it first establishes a trusted boundary using the platform's pre-authorization information, and then combines locally cached authorization, battery, and bay data to complete the autonomous battery swapping judgment, thus balancing offline service availability and battery swapping security.

[0031] Based on the target battery swapping execution information, the cabinet terminal is controlled to perform a battery swapping operation, and the battery swapping execution result is obtained.

[0032] Specifically, after identifying the target empty and fully charged battery compartments, the terminal can translate the aforementioned decision into actual control of the on-site hardware. Typically, the electromagnetic lock on the empty battery compartment is released first, opening the compartment door to allow the user to place the currently used low-power battery inside. The terminal detects the door's closure via a magnetic sensor and uses the battery detection module inside the compartment to confirm the presence of a battery. It can also read the returned battery's serial number (SN), voltage, temperature, and state of charge (SOC) data via NFC or a dedicated communication interface to confirm the old battery has been returned. Once the old battery return conditions are met, the fully charged battery compartment is opened. After the user removes the new battery, the terminal continues to monitor the compartment's status, detecting changes from battery presence to absence and the door closing again, and reads the corresponding battery identifier for subsequent pairing verification. Taking a normal battery swap as an example, after the user places the old battery into empty compartment #2 and closes the door, the machine detects that compartment #2 is closed and the battery is present, and then opens the pre-assigned fully charged compartment #6. After the user takes the fully charged battery from compartment #6 and closes the machine door, the machine confirms that the old battery has been returned, the new battery has been removed, and all relevant compartment doors are closed, thus determining the battery swap as complete. The final battery swap execution result can include information such as the order number, new battery ID, new battery SOC, and completion time, and is further synchronized to the platform backend through the user's terminal for subsequent processing such as order completion, battery asset relationship updates, and package deductions. By adopting an execution method that provides actual feedback confirmation of compartment door status and battery presence status, the completion of the battery swap is no longer determined solely by whether the opening command was successfully sent, but by the actual status of the old battery being returned and the new battery being removed on-site, which helps improve the consistency between the battery swap execution result and the on-site status of the machine.

[0033] Preferably, the step of obtaining the connection status between the cabinet terminal and the platform backend in response to the battery swapping request initiated by the user terminal for the cabinet terminal includes: The platform backend receives the battery swapping request sent by the user terminal and extracts the user identity token from the access request corresponding to the battery swapping request. Based on the user identity token, determine the target role of the user corresponding to the user terminal; Based on the battery swapping request, determine the corresponding target resources and target operations; The target resource and the target operation are matched with the permission matrix corresponding to the target role to obtain the permission matching result; When the permission matching result is a successful match, the user data and cabinet data corresponding to the battery swapping request are verified for access permissions according to the data permission range corresponding to the target role, and the data permission verification result is obtained. When the data permission verification result is successful, the battery swapping request is accepted, and the connection status between the cabinet terminal and the platform backend is obtained.

[0034] Specifically, the platform backend first receives the battery swap request submitted by the user and extracts the user identity token from the access request carrying the battery swap request. The user identity token is used to identify the identity of the current access subject and its corresponding permission relationship. The platform backend can intercept the access request through RBAC middleware and query the role to which the user belongs based on the user identity token, thereby determining the target role corresponding to the current battery swap request. The target role can be one of the pre-configured roles such as ordinary user, maintenance personnel, agent or operator, platform administrator, etc. Different roles correspond to different functional access scopes and data access scopes. After identifying the target role, the platform backend further analyzes the business object and request behavior targeted by the battery swapping request to determine the target resources and target operations corresponding to this access. The target resources may include battery swapping business operations, user data, cabinet equipment data, or order data, while the target operations are used to represent read, write, or execute operations performed on the corresponding resources. The platform backend then calls the permission matrix pre-established for the target role and matches the target resources and target operations corresponding to this battery swapping request with the allowed items in the permission matrix. For example, a regular user can initiate a QR code battery swapping operation related to their own account, but cannot perform remote control of the cabinet. While maintenance personnel can view the status of the cabinet and perform remote opening, restart, and other equipment control operations in their area of ​​responsibility, they cannot access user privacy data or perform financial settlements. If both the target resource and the target operation fall within the permission scope allowed by the target role, a successful permission matching result is obtained. Based on this, the platform backend continues to verify the user data and cabinet data involved in this battery swap request according to the data permission scope corresponding to the target role. For example, ordinary users can only access their own user information and order data, agents or operators can only access data within their agency area or corresponding tenant scope, and maintenance personnel can only access device, alarm, and work order data within their assigned area. This prevents access subjects with only certain functional permissions from unauthorized access to data in other areas, other tenants, or other users. Only when both functional permission matching and data permission verification pass, does the platform backend formally accept the battery swap request and continue to monitor the current connection status between the cabinet and the platform backend. For example, it uses cabinet heartbeats, MQTT long connection status, or the most recent communication response to determine whether the cabinet is currently in a normal or interrupted connection state, thus entering the subsequent online or offline battery swap control process. This setup enables multi-layered verification of identity, role, operation permissions, and data scope to be completed simultaneously before the battery swapping process formally enters the decision-making stage. This ensures that subsequent processing of cabinet status, bay information, and battery swapping control information is based on legitimate access. Furthermore, it links permission verification with subsequent connection status judgments, preventing unauthorized users or unauthorized entities from directly triggering cabinet battery swapping control. This improves access security and business control reliability during multi-terminal collaborative battery swapping.

[0035] Preferably, if the connection status is normal, then determining the target battery swap execution information based on the battery swap request and the cabinet status information corresponding to the cabinet terminal includes: Based on the user information corresponding to the battery swapping request, the battery swapping eligibility of the user corresponding to the user terminal is verified to obtain the battery swapping eligibility verification result. When the battery swap eligibility verification result is passed, the first candidate fully charged bay that matches the target battery model is determined based on the target battery model corresponding to the battery swap request and the cabinet status information. Based on the cabinet status information, a first candidate empty battery compartment is determined for accommodating batteries to be returned; The target fully charged battery compartment and the target empty battery compartment are determined from the first candidate fully charged battery compartment and the first candidate empty battery compartment, respectively, to obtain the target battery swapping execution information.

[0036] Specifically, with normal communication maintained between the terminal and the platform backend, the platform backend can make an online decision on the required battery swap slots based on the user's submitted battery swap request and the terminal's current real-time status. Battery swap eligibility indicates whether the current user meets the conditions to continue the current battery swap service. The platform backend can query the user's real-name authentication status, whether the current data plan is valid, and whether the remaining swap attempts or duration meet the requirements of this battery swap based on the user ID carried or associated in the swap request. The platform backend then integrates these verification results to form the battery swap eligibility verification result. For example, if a user has completed real-name authentication but their battery swap plan has expired or they have insufficient remaining swap attempts, the battery swap eligibility verification will fail, and a battery swap slot will not be allocated to them. The normal battery swap process described in the document also involves verifying the real-name authentication status, data plan validity, and remaining swap attempts or duration after receiving the swap request, and only proceeding with slot allocation after the verification is successful. When the battery swap eligibility requirements are met, the platform's backend further filters fully charged battery compartments available for user retrieval based on the target battery model and cabinet status information in the swap request. Cabinet status information is generated by scanning each compartment, reflecting at least the compartment door status, battery presence status, and battery SOC (State of Charge). The platform backend combines the battery model and current status of each compartment to select compartments with batteries that match the user's needs and are currently available for swapping, forming the first-line candidate fully charged compartments. For example, when a user requests a 60V battery, compartments storing 72V batteries, as well as those still charging, faulty, or otherwise unavailable, are excluded, leaving only compartments storing 60V batteries that meet the full charge requirement as candidates. Simultaneously, the platform backend also determines which compartments currently do not store batteries and are ready to receive the user's old battery based on the same cabinet status information, forming the first-line candidate empty battery compartments. These compartments are primarily used to receive batteries currently in use and awaiting return, therefore, they must be at least currently empty and not in an unavailable state. The terminal unit can detect the door status, battery status, and SOC of each battery compartment, and synchronize the real-time compartment status to the platform backend, providing on-site basis for the above selection. After obtaining two types of candidate compartments, the target fully charged compartment and target empty compartment for this battery swap are selected from the first candidate fully charged compartment and the first candidate empty compartment, respectively. The selected compartment information is organized into target battery swap execution information for the terminal unit to perform actions such as opening the compartment, returning the old battery, and removing the new battery. For example, after the platform backend selects two 60V fully charged compartments, No. 3 and No. 6, and two empty compartments, No. 1 and No. 4, it can determine compartment No. 6 as the target fully charged compartment and compartment No. 1 as the target empty compartment based on the current availability, and associate the two compartment numbers with the corresponding battery swap services.By first determining user eligibility and then selecting target batteries and return bays based on the status of the on-site cabinets, invalid execution information can be avoided when users do not have the conditions for battery swapping or when there are no compatible batteries or available bays on-site. This ensures that battery swapping decisions in online mode are consistent with user needs and the actual resources of the cabinets, and also provides clear and directly implementable control basis for subsequent cabinet execution to specific bays.

[0037] Preferably, the step of locally verifying the offline authentication information through the cabinet terminal, and determining the target battery swap execution information based on the battery swap instruction and the offline decision data pre-stored on the cabinet terminal after successful verification, includes: Based on the offline authentication information, obtain the user token corresponding to the battery swapping request; The user token is matched with the list of authorized user tokens in the offline decision data, and it is determined whether the user token is within the validity period. Based on the matching result and the validity period determination result, the local authentication result is determined. When the local authentication result is successful, the target battery model corresponding to the battery swapping request is determined according to the battery swapping instruction. The target battery model is matched with the battery model whitelist in the offline decision data to obtain the model matching result; When the model matching result is a successful match, the second candidate fully charged battery compartment and the second candidate empty battery compartment are determined according to the target battery model and the battery compartment mapping table in the offline decision data. The target fully charged battery compartment and the target empty battery compartment are determined from the second candidate fully charged battery compartment and the second candidate empty battery compartment, respectively, and the target battery swapping execution information is determined based on the target fully charged battery compartment and the target empty battery compartment.

[0038] Specifically, when the connection between the terminal and the platform backend is interrupted, and the user has already sent the offline authentication information and battery swapping instruction to the terminal, the terminal first parses the user token associated with the current battery swapping request from the received offline authentication information. The user token is used to identify whether the current user is a pre-authorized battery swapping user by the platform backend in the offline state. During normal network operation, the terminal periodically updates its local offline decision cache (ODC) or every time it successfully communicates with the platform backend. This cache stores a list of currently authorized user tokens and records the validity period of each token. Therefore, after obtaining the current user token, the terminal can locally traverse or query the list of authorized user tokens, matching the current user token with each token in the list. At the same time, it determines whether the token is still valid at the current battery swapping time based on its expiration time. Only when the current token can be found in the list of authorized user tokens and has not expired is a local authentication result of successful authentication formed. If there is no corresponding token or the token has expired, subsequent battery allocation will not continue, thereby preventing the use of unauthorized or expired user credentials to initiate battery swapping during the terminal's network outage. The list of authorized user tokens in ODC is data that is synchronized to the cabinet by the platform backend and persistently stored during normal network connection of the cabinet, so that the above authentication process does not rely on the platform backend to return verification results in real time.

[0039] After local authentication is successful, the terminal further parses the battery swap instruction forwarded by the user to determine the target battery model required for this battery swap request. The target battery model is used to limit the specification of the new battery that the user wants to obtain, which can correspond to different battery specifications such as 60V and 72V supported by the system. The terminal then calls the battery model whitelist in the ODC and matches the target battery model with the battery models in the whitelist that are allowed to be swapped in the current system. In addition to recording the battery models that can be used, the whitelist can also associate the corresponding model with the legal battery SN prefix rules, thereby determining whether the target battery requested is a battery type that the terminal can legally provide. For example, if a user requests a 72V battery, but the current cabinet's cached battery model whitelist only allows 60V batteries, the result of a model mismatch will be obtained directly, and the opening of the compartment will not proceed. If the target battery model is on the whitelist, the cabinet will continue to call the locally stored compartment battery mapping table. This battery mapping table reflects the correspondence between each compartment and its batteries, and may include information such as the serial number (SN), charge level, and current status of the batteries stored in each compartment. Based on this, the cabinet will traverse all current compartments, selecting from those already storing batteries a second candidate fully charged compartment if the battery model matches the target battery model, the SOC is at full charge, and the current status allows for battery replacement. Simultaneously, it will select from those compartments that have never stored batteries and are not currently in a faulty, locked, or other unavailable state to receive the user's returned battery, forming a second candidate empty battery compartment. The customer's solution explicitly adopts a method of selecting available compartments based on the local compartment mapping table, and stipulates that the compartment selection logic in offline mode is consistent with the online mode. For example, if the cabinet's cache shows that compartment 2 is empty and available, compartment 4 contains the same model as the target battery but is still charging, and compartment 6 contains the same model and is fully charged, then compartment 6 can be added as the second candidate fully charged compartment, and compartment 2 as the second candidate empty battery compartment. When multiple candidate compartments meet the conditions, the cabinet can select one target fully charged compartment and one target empty battery compartment for this battery swap, and organize the two target compartments and their corresponding battery swap service information into target battery swap execution information, which is then used by the subsequent compartment door control module to sequentially return the old battery and remove the new battery. By progressively narrowing the executable range according to user authorization verification, battery model validity verification, and local compartment resource filtering, the cabinet can complete a relatively complete local battery swap decision based on pre-synchronized data from the platform, even when completely disconnected from real-time communication with the platform backend, rather than acting directly based solely on the user's compartment opening request. This improves the reliability of matching between user authorization, battery model, and actual available compartments during offline battery swapping and ensures that the battery swapping service continues to execute even in the event of a network interruption.

[0040] Preferably, the step of matching the user token with the list of authorized user tokens in the offline decision data and determining whether the user token is within its validity period, and determining the local authentication result based on the matching result and the validity period determination result, includes: Extract the credential payload and signature information corresponding to the user token from the offline authentication information; The signature information is verified using the verification public key pre-stored at the terminal of the machine to obtain the signature verification result. When the signature verification result is successful, the credential user identifier and credential validity period are determined based on the credential payload; The user identifier of the credential is compared with the user identifier corresponding to the battery swapping instruction to obtain a user identifier consistency result; The user token is matched with the list of authorized user tokens to obtain the token matching result; The local authentication result is determined based on the signature verification result, the user identifier consistency result, the token matching result, and the credential validity period.

[0041] Specifically, after receiving offline authentication information forwarded by the user in an offline state, the terminal can first parse it according to the data structure of the offline authentication credential. The offline authentication credential can adopt a JSON Web Token structure, which consists of three parts: header, credential payload, and signature. The credential payload is used to carry data related to user authorization, such as issuer identifier, user unique identifier, user role, issuance time, and expiration time. The signature information is used to prove that the credential was indeed issued by the platform backend and has not been tampered with during transmission. The user token can be understood as a credential identifier or the credential itself corresponding to the current user's authorized identity. After parsing the offline authentication information, the terminal can obtain the credential payload and signature information associated with the user token. Subsequently, the terminal uses the locally pre-stored verification public key to perform digital signature verification on the signature information. In this solution, the platform backend stores the private key used for issuing credentials, while the terminal only stores the public key corresponding to that private key. Therefore, even if the terminal cannot communicate with the platform backend in real time, it can still use the verification public key to verify the source and integrity of the received credentials. Specifically, according to the ES256 signature rule, the data corresponding to the credential header and credential payload can be re-digested, and then the verification public key can be used to verify the received signature value. When the verification results match, it indicates that the credential was issued by the platform backend holding the corresponding private key, and its payload content has not been illegally modified after issuance. Otherwise, the authentication can be directly judged as a failure, and the battery swapping process can be refused. The platform backend uses ECDSA in conjunction with NIST P-256 elliptic curve and SHA-256 to generate credential signatures. The private key is only stored in the cloud, while the terminal stores the public key for local signature verification. This allows the terminal to still have the ability to independently verify the authenticity of platform authorization information even in the event of a network outage.

[0042] After signature verification is successful, the terminal parses the user's unique identifier and expiration timestamp from the credential payload to obtain the credential user identifier and credential validity period. The credential user identifier indicates the actual authorized user, while the validity period limits the time range within which the offline credential can be used. Simultaneously, the battery swapping instruction can also carry a separate plaintext user identifier. The terminal compares the credential user identifier parsed from the credential payload with the user identifier in the battery swapping instruction character by character. Only when they match completely is the result of a matching user identifier. For example, if the user identifier in a JWT credential corresponds to user A, but the plaintext battery swapping instruction carries user B, even if the JWT itself is correctly signed, user B cannot be allowed to use user A's valid credential to perform a battery swap. This reduces the risk of intercepted valid credentials being misused across accounts. Based on this, the terminal further queries and matches the current user token with the list of authorized user tokens in the offline decision data. This list of authorized user tokens is local authorization data that is synchronized to the ODC by the platform backend and persistently stored during normal network connectivity of the terminal. It records user tokens that are still allowed to perform offline battery swapping by the platform and their validity period. If the current user token can be found in the list of authorized items, the token matching result is obtained. Otherwise, it means that even if the credential signature is correct, the user is not a valid authorized user cached locally by the terminal. Finally, the terminal combines the signature verification result, user identifier consistency result, token matching result, and whether the current credential is still within its validity period to form a local authentication result. Usually, only when the signature verification is successful, the credential user and the battery swapping instruction user are consistent, the user token is in the list of authorized user tokens, and the credential has not expired, is the local authentication considered successful and allowed to proceed to the subsequent battery model verification and bay selection process. If any condition is not met, the offline battery swapping can be terminated. Through this layer-by-layer verification method, the terminal does not simply rely on the existence of a single token to allow offline access. Instead, it simultaneously verifies the source of the credential, the integrity of the credential, the user correspondence, the local authorization status, and the authorization validity. This ensures that offline battery swapping can maintain a security control that is basically consistent with the platform's authorization boundary even when it is disconnected from the platform's real-time communication.

[0043] Preferably, when the model matching result is a successful match, determining the second candidate fully charged storage compartment and the second candidate empty storage compartment based on the target battery model and the storage compartment battery mapping table in the offline decision data includes: Based on the battery mapping table for each compartment, determine the battery storage information corresponding to each compartment in the cabinet terminal; Based on the battery storage information corresponding to each of the aforementioned compartments, determine the first set of compartments with stored batteries and the second set of compartments without stored batteries; Based on the battery information corresponding to each compartment in the first compartment set, the second candidate fully charged compartment is obtained by filtering the compartments whose battery models match the target battery model and whose corresponding batteries meet the full charge condition. The storage spaces in the second storage space set that meet the battery return conditions are determined as the second candidate empty battery storage spaces.

[0044] Specifically, after the target battery model has passed local whitelist verification, the terminal can further access the battery mapping table in the offline decision cache to locally filter the battery slots that are actually available for battery swapping within the terminal. The battery mapping table records the correspondence between each slot and its corresponding battery. It can include information such as the slot number, whether a battery is present in the slot, the battery's serial number (SN), charge level, and current status. Therefore, the terminal can restore the current battery storage status of each slot based on this mapping relationship without accessing the platform's real-time backend database.

[0045] In practice, the terminal can first traverse the battery mapping table of each compartment and divide the compartments into two categories according to the battery presence status: for compartments that have been detected or recorded as having batteries, they are assigned to the first compartment set; for compartments that do not currently have batteries, they are assigned to the second compartment set. In this way, the candidate range for providing fully charged batteries and the candidate range for receiving old batteries from users are distinguished from the physical occupancy status. Subsequently, for each compartment in the first set of compartments, the terminal continues to read information such as the corresponding battery model, charge level, and status. On the one hand, it matches the battery model with the target battery model corresponding to this battery swap request; on the other hand, it determines whether the battery has reached the preset full charge conditions. For example, it can determine this based on the battery's SOC and whether it is currently in a normal and usable state. Only compartments with the same model and meeting the full charge conditions are retained as second candidate full charge compartments. For example, if a user requests a 60V battery, and a compartment has a battery, but the corresponding battery is 72V, or although it is 60V, it is still charging and the SOC has not yet reached the requirement for swapping, then it should not be included in the second candidate full charge compartment. Only compartments containing 60V batteries with the required charge level and status can be considered as candidates for subsequent target full charge compartments. For the second set of compartments, it further determines whether these empty compartments meet the battery return conditions. The battery return conditions can at least include that the compartment is not currently occupied by a fault, locked, or other services, and has the conditions to receive the battery to be returned. Thus, empty compartments that can actually receive old batteries are determined as second candidate empty battery compartments. The customer's solution clearly stipulates that the cabinet selects available slots based on the slot mapping table cached by ODC in offline mode, and its selection logic is consistent with that in online mode. Therefore, the above filtering is actually a local reproduction of the platform's slot allocation logic in the online state on the cabinet.

[0046] For example, if the current cabinet has 6 bays, bays 1 and 2 are empty, bay 3 contains a battery of the same model as the target but not fully charged, bay 4 contains other models of batteries, bay 5 contains the target model battery that is fully charged, and bay 6 is faulty, then a first set of bays containing bays 3, 4, and 5 and a second set of bays containing bays 1 and 2 can be formed. Then, only bay 5 is retained from the first set as the second candidate fully charged bay, and bays that do not meet the return conditions are filtered out from the second set to obtain the second candidate empty bay. By first dividing the set according to whether batteries are stored, and then filtering according to battery model, full charge condition, and return condition, the cabinet can still make orderly and interpretable local bay decisions based on the current cached bay resource status even when offline. This reduces erroneous bay openings caused by model mismatch, insufficient power, or bay unavailability, and also provides a reliable basis for subsequently determining the actual target fully charged bay and the target empty bay from the candidate bays.

[0047] Preferably, the step of controlling the cabinet terminal to perform a battery swapping operation based on the target battery swapping execution information, and obtaining the battery swapping execution result, includes: According to the target battery swap execution information, the cabinet terminal is controlled to perform a battery swap operation according to a preset battery swap process. The preset battery swap process includes a battery swap instruction reception and confirmation stage, an empty battery compartment opening stage, a battery return confirmation stage, a fully charged compartment opening stage, a battery removal confirmation stage, and a battery swap completion confirmation stage. Based on the preset battery swapping process and the current execution status of the cabinet terminal during the battery swapping operation, the current battery swapping stage is obtained; Based on the current battery swapping stage, the corresponding target detection object, target detection parameters, and stage completion conditions are determined from the preset stage anomaly detection strategy library; Based on the target detection parameters, the target object is detected to obtain the detection result for the current stage; When the current stage detection result does not meet the stage completion condition, the abnormal event corresponding to the current stage detection result is handled to obtain the abnormal handling result. Based on the anomaly handling result, when it is determined that the current stage detection result after anomaly handling meets the stage completion condition, the cabinet terminal is controlled to enter the next battery swapping stage in the preset battery swapping process, and the next battery swapping stage is returned as the new current battery swapping stage to the step of determining the corresponding target stage anomaly detection strategy from the preset stage anomaly detection strategy library based on the current battery swapping stage, until all battery swapping stages in the preset battery swapping process are completed, and the battery swapping execution result is obtained.

[0048] Specifically, firstly, the cabinet terminal is controlled to perform the battery swapping operation according to the preset battery swapping process based on the target battery swapping execution information. This involves converting the aforementioned determined target fully charged bays, target empty bays, and other battery swapping execution information into actual control actions on the cabinet terminal, so that a battery swapping operation proceeds step by step in a fixed phase sequence, rather than the cabinet terminal directly and continuously executing all actions. Specifically, the terminal first enters the battery swap instruction reception and confirmation stage, receiving and confirming the battery swap instruction sent by the user. After confirming the validity of the battery swap task, it enters the empty battery compartment opening stage, controlling the corresponding empty battery compartment door to open and waiting for the user to return the old battery. After detecting that the user has completed the battery return, it enters the battery return confirmation stage, confirming the compartment door's closed status, the battery's presence status, and the battery information inside the compartment. For example, if the compartment door changes from open to closed and a battery is detected inside, the battery's serial number can be read for verification via NFC or a dedicated communication interface. After confirming the old battery return is valid, it enters the full charge compartment opening stage, controlling the target full charge compartment door to open and waiting for the user to remove the full charge battery. Then, it enters the battery removal confirmation stage, confirming that the user has removed the target battery through changes in the compartment door status and battery removal events. Finally, it enters the battery swap completion confirmation stage, confirming that the battery swap operation is complete when the old battery has been returned, the new battery has been removed, and the corresponding compartment doors are closed, and generating the corresponding battery swap execution result. The actual process also records status information such as the new battery ID, SOC, and completion time after the battery swap is completed. Therefore, through this phased execution method, each control action at the cabinet terminal can correspond to a clear business stage and confirmation node, thereby avoiding the premature execution of subsequent actions before the previous action is completed.

[0049] The current battery swapping stage is determined by the preset battery swapping process and the current execution status of the terminal during the swapping operation. This allows the terminal to determine in real time which stage the battery swapping operation has reached. The current execution status here is not simply the device's operating status, but rather a comprehensive reflection of the completion status of the swapping action, including door status, battery presence status, battery information, and command execution status generated by the terminal during actual execution. For example, after opening the empty battery compartment, the terminal can determine whether it is still in the empty battery compartment opening stage based on whether the corresponding compartment door is open. When it detects that the user has placed the old battery into the compartment and closed the door, it determines whether it can enter the battery return confirmation stage based on the battery presence status inside the compartment and the read battery serial number. During the removal of a fully charged battery, it can determine whether it has moved from the fully charged compartment opening stage to the battery removal confirmation stage based on the fully charged compartment door status and the battery removal event. Thus, the terminal effectively establishes a stage-based state progression relationship corresponding to the preset battery swapping process. Upon completion of the key execution actions specified in each stage, the current execution status is updated to the state corresponding to the next stage, ensuring that subsequent detection and control are based on an accurate understanding of the current stage.

[0050] Based on the current battery swapping stage, the corresponding target detection objects, target detection parameters, and stage completion conditions are determined from the pre-set stage anomaly detection strategy library. This involves setting detection rules tailored to the actual execution characteristics of different battery swapping stages. The stage anomaly detection strategy library can pre-establish corresponding detection strategies for each of the six stages mentioned above. The target detection object is used to limit the cabinet components or business status that need to be monitored in the current stage. For example, in the empty battery compartment opening stage, the focus is on the opening status of the target compartment door and whether the opening action has been performed; in the battery return confirmation stage, the focus is on the closed status of the compartment door, the battery presence status, and the identity information of the returned battery; and in the battery removal confirmation stage, the focus is on the fully charged compartment door status and the battery removal status. The target detection parameters are used to limit the data actually collected and judged by the cabinet terminal, such as the compartment door open / closed status, battery presence / absence status, battery serial number (SN), and state of charge (SOC). The stage completion conditions are used to clarify under what circumstances the current stage is allowed to end. For example, in determining battery return, the system reads the battery serial number (SN) and performs a verification after detecting that the door status has changed from open to closed and that a battery is present in the compartment, to confirm that the user has completed battery return. Battery swapping completion requires that the old battery has been returned, the new battery has been removed, and the corresponding compartment doors are closed. By selecting the appropriate detection strategy according to the current stage, the same set of cabinet detection resources can undertake different judgment tasks at different stages, avoiding irrelevant detection results caused by performing uniform detection without distinguishing between battery swapping stages.

[0051] The detection results for the current stage are obtained by detecting the target object according to the target detection parameters. This translates the detection requirements determined in the current stage into actual status collection and judgment at the terminal. In practice, the terminal can read the corresponding door status, battery presence status, battery identification, and operating parameters according to the target detection parameters, and compare the collected results with the corresponding stage completion conditions. For example, after the empty battery compartment is opened, the terminal starts a timer and continuously detects whether the user has closed the compartment door, whether an old battery has been placed in the compartment, and whether the NFC tag of the battery in the compartment can be verified. When the user returns the battery and closes the compartment door, the terminal detects the change in door status, confirms the presence of a battery in the compartment, and then reads the battery serial number to perform verification, thus forming the detection result for the current stage. During the removal of a fully charged battery, the terminal can detect changes in the compartment door status and the battery removal event, and form a battery removal confirmation result after the corresponding conditions are met. Therefore, the detection result of the current stage can not only indicate whether the stage is completed, but also specifically reflect the detection items that have not met the completion conditions, providing direct evidence for subsequent abnormal event location and abnormal handling.

[0052] When the current stage's detection results do not meet the stage completion conditions, anomaly handling is performed on the corresponding abnormal events to obtain an anomaly handling result. This involves taking targeted recovery measures based on the specific incomplete state when the battery swapping process fails to proceed normally, rather than directly terminating the entire battery swapping task. For example, after the empty battery compartment is opened, if the user does not place the old battery or close the compartment door within the specified time, the terminal can determine that the battery return has timed out based on a preset waiting time and perform actions such as closing the compartment door and sending a battery return timeout or failure notification to the user. If NFC verification failure of the battery in the compartment is detected, the battery return can be determined as abnormal, and the normal process can be refused to continue. If the battery swapping command itself has a signature verification failure, the terminal can refuse to execute the command and return the corresponding error information. After the anomaly handling is completed, the terminal re-acquires the relevant detection status, such as re-checking the compartment door status, battery presence status, and battery identity information, to form the current stage detection result after anomaly handling. In this way, the result of the abnormality handling is not simply a record of the abnormality, but is used to determine whether the handling action taken has actually eliminated the abnormal state that caused the current stage to be unable to be completed, thereby providing a basis for judgment on whether the battery swapping process can continue.

[0053] Based on the anomaly handling results, the system determines whether the current stage's detection results meet the stage completion conditions. If they do, the system controls the terminal to enter the next battery swapping stage in the preset battery swapping process, and uses this next stage as the new current stage. The system then re-selects the corresponding detection object, detection parameters, and completion conditions from the stage anomaly detection strategy library until all six stages are completed. In other words, each battery swapping stage forms a closed loop of detection, judgment, anomaly handling, and reconfirmation. The stage can only proceed further once the critical state of the current stage truly meets the completion conditions. For example, even if the user closes the door after the empty battery compartment is opened, if the battery's status is unconfirmed or the battery's serial number (SN) verification fails, the system cannot directly enter the fully charged compartment opening stage. Only after the old battery has been confirmed as validly returned can the system continue to the next stage. Similarly, after a fully charged battery is removed, the system can only enter the battery swapping completion confirmation stage and ultimately generate a battery swapping completion result after confirming that the new battery has been removed and the relevant compartment door is closed. After the battery swap is completed, the cabinet will record the new battery ID, SOC, and completion time, and update the local state machine to COMPLETED. Then, the final state will be synchronized to the platform backend for order settlement. Therefore, the above-mentioned stage cycle ultimately forms a complete closed loop from receiving the battery swap instruction, returning the old battery, taking out the new battery, to confirming the completion of the battery swap. This allows the cabinet to first complete the abnormal recovery and reconfirmation in the event of a stage abnormality, and then decide whether to continue the subsequent battery swap action, thereby improving the continuity and reliability of the battery swap process.

[0054] Preferably, the step of detecting the target object according to the target detection parameters to obtain the detection result at the current stage includes: Based on the phase execution action corresponding to the current battery swapping phase, a target anomaly detection chain is obtained. The target anomaly detection chain includes multiple step-by-step detection links arranged in the order of execution of the phase execution actions. Each step-by-step detection link corresponds to at least one target detection object and at least one target detection parameter. According to the arrangement order of each step of the target anomaly detection chain and the target detection parameters, the corresponding target detection object is detected step by step, and the detection completion status of the current step by step detection link is used as the starting condition for the next step by step detection link. When the detection result of the current step by step detection link meets the corresponding link completion condition, the next step by step detection link is started. When the detection result of any of the step-by-step detection steps does not meet the corresponding step completion condition, the current stage detection result is determined to be that the stage completion condition is not met, and the execution of subsequent step-by-step detection steps is stopped. When the detection results of each of the step-by-step detection stages meet the corresponding stage completion conditions, the detection result of the current stage is determined to meet the stage completion conditions.

[0055] Specifically, the cabinet terminal does not independently judge all the detection objects at the same time during a battery swapping phase. Instead, it combines the phase execution actions that actually need to be performed in the current phase to establish a target anomaly detection chain corresponding to the sequence of actions in that phase. It determines whether the next detection step should be started based on whether the previous detection step is completed, so that the detection process and the battery swapping operation itself form a hierarchical correspondence.

[0056] The phased execution actions refer to the actual equipment actions that the cabinet needs to complete and the operations that the user needs to cooperate in during the current battery swapping phase. For example, in the empty battery compartment opening phase, the cabinet needs to first control the target empty battery compartment to unlock and open the compartment door. In the battery return confirmation phase, it needs to sequentially confirm whether the user has put the old battery into the compartment, whether the compartment door has been closed again, and whether the battery in the compartment is a legally returned battery. In the fully charged compartment opening and battery removal confirmation phase, it needs to first complete the opening action of the target fully charged compartment, and then confirm whether the user has removed the fully charged battery. Therefore, based on the sequential dependencies between these phased execution actions, the anomaly detection required in the current phase can be divided into multiple hierarchical detection links, and the corresponding target anomaly detection can be determined from the pre-established phased anomaly detection strategy. The chain involves each step of the detection process being associated with at least one target object to be confirmed and target detection parameters used to obtain the status of that target object. For example, for a storage door, the door status can be used as the target object, and the door status sensor can be used to obtain the open or closed status. For whether a battery has entered the storage compartment, the battery presence status can be used as the target object, and the battery detection module in the storage compartment can be used for detection. For whether the battery has been returned correctly, the battery serial number can be read, and the reading result can be used as the basis for battery identification. At the same time, a timer can be used to obtain whether the user operation has exceeded the preset waiting time. This ensures that each detection step has a clear data source and judgment basis, rather than making a vague judgment based on a single comprehensive abnormal result. After determining the target anomaly detection chain, the terminal executes the detection sequentially according to the order of each step. The completion status of the previous step serves as the starting condition for the next step. In other words, the next detection step is only initiated after the corresponding equipment status of the previous step has met the requirements. For example, during the opening of the empty battery compartment, the terminal first checks whether the target compartment door has changed from a closed state to an open state. Only after confirming that the opening action has been completed will the user battery return detection be initiated. After detecting that there is already a battery in the compartment, the terminal door closure status detection is then performed, and the battery serial number (SN) inside the compartment is read for identity verification after the door is closed. Therefore, the different detection steps are not independent of each other, but rather the detection completion status is passed step by step according to the actual execution order of the battery swapping action. This method also allows the terminal to clearly know which specific action step the anomaly occurred in during the detection process.

[0057] For example, a waiting time is set for the battery return process after opening the empty battery compartment. The system checks the user's actions upon closing the compartment door, inserting the old battery, and confirming the status after closing the door. An exception is triggered only if the corresponding operation is not completed within the specified time, or if the NFC tag read after the door is closed fails verification. Therefore, opening the compartment can be a pre-detection step, battery insertion confirmation a subsequent step, and door closure and battery identity verification a further step. If any step fails to meet its completion condition, the terminal can determine that the current stage is incomplete and immediately stop subsequent step-by-step checks. For example, if the terminal has issued an empty compartment opening command but the door is not detected to be open within the specified time, there is no need to continue checking whether the user has inserted a battery, because the user has not yet obtained the conditions to perform subsequent operations. Similarly, if the door has been confirmed to be open, but no battery is detected in the compartment within the specified time, the battery return process is directly determined to be abnormal, and there is no need to continue performing battery serial number verification. Furthermore, if the battery is detected to have entered the compartment but the door is not properly closed, the current stage cannot be considered complete, and subsequent checks are also stopped. By constraining subsequent detections with preconditions, this approach avoids situations where the object being detected is in a state where it is not ready for detection due to the incompleteness of the preceding action, thereby reducing invalid detections and misjudgments caused by unpreparedness. When the detection result of any step-by-step detection step does not meet the corresponding step completion condition, the cabinet will take that abnormal step as the direct basis for the incompleteness of the current stage and stop executing subsequent steps, thus determining that the detection result of the current stage does not meet the stage completion condition. Conversely, if all step-by-step detection steps corresponding to the current stage are completed sequentially according to the target abnormal detection chain, such as the target compartment door being opened as required, the old battery being placed in the target compartment, the compartment door being closed again, and the battery SN verification being passed, or if the old battery has been returned, the new battery has been removed, and the corresponding compartment doors have been closed in the battery swapping completion stage, then it means that the current stage has reached the predetermined state from the precondition to the postcondition. Only then will the detection result of the current stage be determined as meeting the stage completion condition, and the cabinet will be allowed to continue to the next battery swapping stage.

[0058] Therefore, the above-mentioned step-by-step detection actually forms a conditional chain that proceeds synchronously with the battery swapping operation: the detection conditions for the next action are only met after the completion of the previous action; if an abnormality occurs in a certain link, the abnormality is stopped at that link and the abnormality position is retained; only after all links are completed are the conditions for the current stage to proceed to the next stage released. This not only allows for detailed judgment of the battery swapping process using existing cabinet data such as the status of the compartment door, the battery presence status, the battery SN and SOC read by NFC, and the operation waiting time, but also allows for further identification of stage abnormalities that were originally difficult to locate directly at specific action links. This provides a clear detection basis for subsequent identification of abnormal events based on incomplete detection items, and for distinguishing between the source abnormal events that cause other abnormalities and the accompanying abnormal events they generate. This improves the accuracy of the battery swapping cabinet in identifying changes in the state of the battery swapping process and the targeted nature of abnormality handling.

[0059] Preferably, when the current stage detection result does not meet the stage completion condition, the abnormal event corresponding to the current stage detection result is subjected to abnormal handling, and the abnormal handling result includes: Extract detection anomalies that do not meet the stage completion conditions from the current stage detection results, and associate each detection anomaly with the stage execution action corresponding to the current battery swapping stage to form at least one candidate anomaly event; Based on the current battery swapping stage, a target abnormal event relationship chain corresponding to the current battery swapping stage is determined from a preset abnormal event relationship chain. The target abnormal event relationship chain is used to characterize the sequential occurrence relationship and abnormal impact relationship between different abnormal events in the current battery swapping stage. Each candidate abnormal event is matched with an abnormal event in the target abnormal event relationship chain to determine the abnormal occurrence position of each candidate abnormal event in the target abnormal event relationship chain, and the association relationship between each candidate abnormal event is determined based on the abnormal occurrence position. For candidate abnormal events with a relationship, reverse tracing is performed according to the abnormal influence direction in the relationship chain of the target abnormal event. The upstream abnormal event that causes other candidate abnormal events and is not caused by other candidate abnormal events is identified as the target abnormal event, and the other candidate abnormal events caused by the target abnormal event are identified as the accompanying abnormal events. Based on the abnormal event type corresponding to the target abnormal event and the phase completion conditions of the current battery swapping phase, the target abnormal handling action is determined from the preset abnormal handling strategy, and the battery swapping cabinet is controlled to execute the target abnormal handling action to obtain the abnormal handling result.

[0060] Specifically, when the current battery swapping phase fails to be completed as scheduled, the multiple detected anomalies are not treated as independent faults. Instead, the actual uncompleted actions are first determined based on the detection results. Then, the sequence and influence relationships between the actions in this phase are considered to trace the source anomaly that truly caused the phase to fail. Finally, the corresponding handling actions are selected only for the source anomaly, thereby avoiding repeated handling when the same cause leads to multiple subsequent anomalies.

[0061] The terminal first identifies detection anomalies that fail to meet the corresponding completion requirements from the current stage's detection results. For example, during the battery return process, operations such as waiting for the user to insert an old battery after the empty battery compartment is opened, detecting the compartment door closing again, and reading the battery serial number (SN) inside the compartment have been set. The terminal can use the compartment door status, battery presence status, and battery identification information to determine whether the return process is complete. Therefore, if it detects that no battery has entered the compartment within the specified time, the compartment door is not closed properly, or the read battery SN is inconsistent with the user's bound battery, these unmet detection items can be extracted. Then, the detection anomalies are mapped to the actual actions performed in the current stage. For example, the compartment door not being opened is mapped to the empty battery compartment opening action, the failure to detect the battery entering the compartment within the specified time is mapped to the battery return action, and the battery identification verification failure after the compartment door is closed is mapped to the battery return confirmation action. This forms candidate anomalies with clear action sources, rather than directly using the abnormal state generated by the sensor as the final fault conclusion. It also uses an abnormal event-driven engine and a timeout timer to automatically detect situations such as cabinet doors not being opened and batteries not being returned. For example, if the cabinet door is not opened, the T1 timer can determine whether the cabinet responds within a specified time after the opening command is issued. For battery return, the T2 timer can constrain the waiting time for the user to close the cabinet door, insert the old battery, and close the door again. Therefore, these existing detection results can be directly used as the basis for the formation of candidate abnormal events.

[0062] After receiving candidate abnormal events, the terminal further selects a relationship chain corresponding to the current battery swapping stage from a pre-established abnormal event relationship chain. This relationship chain does not simply record which abnormalities exist, but describes the possible causal transmission relationships between abnormalities according to the actual operation sequence of the current stage. For example, during the process of opening the empty battery compartment and returning the battery, the following relationships may be formed: opening action not completed, compartment door not opened, user cannot insert old battery, no battery detected in the compartment, and subsequent return confirmation cannot be completed. Under this relationship, the earlier opening abnormality belongs to the earlier state, and the subsequent battery not returned and return confirmation abnormalities may be the result of the previous abnormality not being resolved. Therefore, it is necessary to first establish a matching relationship between candidate abnormal events and the corresponding abnormal positions in the relationship chain, determine which link of the entire abnormal chain each candidate abnormality belongs to, and obtain the upstream and downstream relationships between candidate abnormal events accordingly. For example, if the cabinet has issued an opening command but no feedback is received within the specified time (T1), an opening anomaly can be initially identified. Since the door is not open, the user cannot proceed with the subsequent battery return operation, potentially leading to other anomalies such as battery not being returned or the door not meeting the next stage's requirements. While these subsequent anomalies are indeed detected, it doesn't necessarily mean that multiple fault handling steps need to be performed separately. The cabinet automatically retryes after the door opening timeout, up to a maximum of three times. Since battery return has its own independent waiting time, the existing sequence of these actions can be used to further pinpoint the anomaly.

[0063] After determining the location of candidate anomalies, for candidate anomalies with upstream and downstream relationships, the cabinet end traces backward along the direction of the anomaly's impact. That is, it searches upstream from the currently detected subsequent anomalies to find the upstream anomaly that can explain the anomaly, and determines whether the upstream anomaly itself can be explained by other candidate anomalies. When a candidate anomaly can be the cause of other candidate anomalies, and there is no other candidate anomaly in the relationship chain that is upstream of it and can further explain the candidate anomaly, it can be identified as the target anomaly event, which is the anomaly source that truly needs to be prioritized in the current stage. Subsequent anomalies caused by the target anomaly, such as abnormal door status and incomplete battery return, are identified as accompanying anomaly events. For example, if the empty battery compartment opening command is not executed normally, resulting in the compartment door not opening, and the user being unable to insert the old battery, ultimately causing a battery not returned anomaly, then by tracing back, the incomplete opening action can be taken as the target anomaly event, while the compartment door not opening and the battery not being returned are associated anomalies. The key to this approach is to distinguish between the fundamental problem that actually occurs in the equipment and the manifestation of that problem at each stage in the battery swapping process, so as to avoid the cabinet terminal continuously executing multiple conflicting or repetitive recovery actions for the same fault cause.

[0064] Finally, after identifying the target anomaly, the terminal selects a target anomaly handling action from the pre-configured anomaly handling strategy based on the anomaly type and the unmet completion conditions of the current battery swapping phase. This action can resolve the source anomaly and restore the current phase to the completion conditions. For example, if the opening action is incomplete, the opening command can be retried according to the existing anomaly handling mechanism. After reaching the specified number of retries, the anomaly status will be entered. If the battery ID does not match, the door will not be closed, but the battery will be refused and the user will be prompted to retrieve the mismatched battery and replace it with the correct one.

[0065] After executing the target anomaly handling action, the cabinet re-acquires the relevant detection status of the current stage and compares the processed status with the original stage completion conditions to obtain the anomaly handling result. If the source anomaly has been resolved and subsequent related states can continue to advance, the current stage is allowed to re-enter the subsequent detection or battery swapping process, instead of separately handling the accompanying anomalies caused by the source anomaly. Through the above processing, the battery swapping cabinet can further transform the anomaly detection results into an anomaly event chain with sequential relationships and directions of influence, and locate the truly source anomaly that needs to be handled from multiple apparent anomalies. This transforms anomaly handling from responding to each detection result item by item to targeted recovery of the cause of the anomaly, thereby reducing duplicate and erroneous processing, and providing a clear basis for whether the subsequent battery swapping stage can continue.

[0066] Preferably, the step of determining a target anomaly handling action from a preset anomaly handling strategy based on the anomaly type corresponding to the target anomaly and the phase completion conditions of the current battery swapping phase, and controlling the battery swapping cabinet to execute the target anomaly handling action to obtain the anomaly handling result includes: Based on the type of the target abnormal event, determine the abnormal handling object and the abnormal handling target state corresponding to the target abnormal event; Based on the anomaly handling object, the anomaly handling target state, and the phase completion conditions of the current battery swapping phase, at least two candidate anomaly handling actions are determined from the preset anomaly handling strategies, and the expected recovery state corresponding to each candidate anomaly handling action is determined. The expected recovery state corresponding to each of the candidate anomaly handling actions is matched with the stage completion condition to determine the stage recovery result corresponding to each of the candidate anomaly handling actions, and the candidate anomaly handling action whose stage recovery result satisfies the stage completion condition is selected from the candidate anomaly handling actions as the target anomaly handling action. Control the battery swapping cabinet to execute the target anomaly handling action, and obtain the current state of the anomaly handling object corresponding to the target anomaly event after the execution is completed; The current state of the exception handling object is matched with the exception handling target state to obtain the exception handling verification result, and the exception handling result is determined based on the exception handling verification result.

[0067] Specifically, firstly, the terminal determines the specific exception handling object and the target state to which the object should be restored, based on the exception event type of the target exception event. The exception handling object can correspond to the specific equipment component or execution state where the exception occurred. For example, if an opening exception occurs during the empty battery compartment opening phase, the door control state of the target empty battery compartment can be considered the exception handling object, and the door being in the open state can be determined as the target exception handling state. After determining the handling object and target state, the terminal further considers the completion conditions of the current battery swapping phase and selects multiple candidate exception handling actions from pre-configured exception handling strategies to resolve the exception. It then determines the expected recovery state that may be achieved after executing each candidate action. These candidate actions are not simply a list of different control commands, but are selected based on the current state of the exception object and the state that needs to be achieved in the subsequent phase. For example, if the door is not open, different handling methods can be selected based on the actual cause of the exception, such as resending the opening control command or re-initializing the opening mechanism. The possible state that the door may reach after execution is then determined, thus establishing a correspondence between different handling actions and recovery states. Subsequently, the terminal unit matches the expected recovery state corresponding to each candidate anomaly handling action with the current stage's completion conditions. It determines whether an action, while changing the current state of the anomaly object, truly restores the current battery swapping stage to a state where it can continue. For example, if the current stage requires the empty battery compartment to be opened before the battery return operation can begin, the expected state of the candidate action must not only restore the compartment door from an unopened state to an open state but also meet the stage completion condition's requirement for compartment opening completion. Only candidate actions that meet this condition are identified as the target anomaly handling action. In this way, the selection criterion for anomaly handling actions shifts from simply restoring equipment malfunctions to whether the current battery swapping stage can be restored, ensuring the handling action corresponds to the entire battery swapping process. After determining the target anomaly handling action, the terminal unit controls the corresponding equipment to actually execute the action, such as re-driving the target compartment door to perform the opening operation. After the action is executed, it does not directly rely on the issuance of control commands or the return of success from the execution program to determine anomaly elimination. Instead, it re-acquires the current state of the anomaly object to obtain the actual status information fed back by the equipment. For compartment door-related anomalies, the feedback from the compartment door status sensor can be reread to confirm whether the compartment door has truly changed from a closed or unresponsive state to an open state. For battery return-related anomalies, the battery's presence status in the compartment and information such as the battery's serial number read via NFC or the battery communication interface can be combined to reconfirm whether the battery was returned correctly.Finally, the cabinet terminal matches the current state of the exception handling object after execution with the previously determined exception handling target state to obtain the exception handling verification result. If the actual state has reached the target state, it means that the exception handling has been verified at the device state level, and the corresponding exception handling result can be determined as successful. If the actual state has not yet reached the target state, it means that although the exception handling action was executed, the target exception has not been effectively resolved. In this case, the exception handling result should reflect that the handling was not successful, and subsequent exception handling mechanisms can continue to handle it or end the current stage. For example, if the cabinet door is not open and no feedback is received within the specified waiting time, it can be automatically retried, up to 3 times. The battery return process has user operation waiting time and door status confirmation time set separately.

[0068] Preferably, selecting the candidate anomaly handling action whose corresponding stage recovery result satisfies the stage completion condition from the candidate anomaly handling actions as the target anomaly handling action includes: For each of the candidate exception handling actions, determine the exception state that can be eliminated after executing the candidate exception handling action, and determine the exception elimination range corresponding to the candidate exception handling action based on the correlation between the exception state and the target exception event. The state of the stage that has not yet been completed after the target abnormal event in the current battery swapping stage is obtained, and the state change relationship between each stage state after the candidate abnormality handling action is determined according to the expected recovery state corresponding to the candidate abnormality handling action. If the candidate exception handling action can eliminate the exception state corresponding to the target exception event, and no new stage state conflicting with the stage completion condition is generated after the candidate exception handling action is executed, then the candidate exception handling action is determined as a valid exception handling action. Compare the exception elimination ranges corresponding to each of the effective exception handling actions, and determine the effective exception handling action that can eliminate the target exception event and has the smallest corresponding exception elimination range as the target exception handling action.

[0069] Specifically, after identifying multiple candidate anomaly handling actions, the terminal first analyzes the anomaly states that each candidate action can actually change or eliminate. It then determines the corresponding anomaly elimination range by combining the correlation between these anomaly states and the target anomaly event. This means determining which anomaly a candidate action can directly handle and, more importantly, which related anomalies it can further resolve along the current anomaly event's correlation. For example, in a scenario where the cabinet door is not properly opened, the target anomaly event might manifest as the door not being opened. Related anomaly states could include the unlocked state not being released and the door opening state not being confirmed. If a candidate action can restore the locked state and further enable the door to enter the open state, its anomaly elimination range can cover multiple anomaly states related to the target anomaly. Based on this, the terminal further acquires the unfinished stage states after the target anomaly event occurs in the current battery swapping phase. It then analyzes how these stage states will change after executing the action, based on the expected recovery state corresponding to each candidate action. This means determining whether the subsequent states can continue according to the battery swapping process after the action restores the current anomaly, and whether it will invalidate previously confirmed states. For example, during the empty battery compartment opening phase, opening the compartment door is a prerequisite for subsequent battery return detection. If a candidate action can restore the compartment door to open, then the subsequent steps can proceed to battery insertion, compartment door closing, and battery serial number detection. Conversely, if an action can change the compartment door control state, but its expected recovery result still cannot meet the current stage completion conditions, or if its execution causes the already confirmed stage state to revert to an incomplete state, then the action cannot be considered to effectively restore the current battery swapping process.

[0070] Subsequently, the cabinet terminal uses whether the target anomaly can be eliminated and whether it will introduce new stage state conflicts as the criteria for judging the validity of candidate actions. Only candidate actions that can eliminate the abnormal state corresponding to the target anomaly and will not cause the state after execution to conflict with the current stage completion conditions are determined as valid anomaly handling actions. This can avoid using an action as an executable recovery plan simply because it can change the state of a local device.

[0071] Finally, when multiple effective anomaly handling actions can resolve the target anomaly, the anomaly elimination range corresponding to each action is further compared, and the action that can eliminate the target anomaly with the smallest anomaly elimination range is selected as the target anomaly handling action. The core principle is to prioritize the handling method that performs local recovery for the current target anomaly, rather than changing too many related states simultaneously to handle one anomaly, thereby reducing the impact on other completed states and subsequent states of the current battery swapping process. For example, for the cabinet door not opening anomaly, if resending the opening control of the current compartment can restore the target compartment door to open and meet the stage completion conditions, there is no need to use the handling method that may simultaneously adjust other compartments or change more business states; only when local handling cannot restore the stage is it necessary to use the candidate action with a larger anomaly elimination range. For example, after issuing the compartment opening command in the platform backend, wait for feedback from the cabinet terminal. If no normal feedback is received after 5 seconds, a retry is triggered, with a maximum of 3 retries; if it still fails, the order is marked as an anomaly, the faulty compartment is frozen, and an operation and maintenance work order is generated.

[0072] Please see Figure 3 , Figure 3This demonstrates the overall logic of the EEDE (Exception Event Driven Engine) for detecting, judging, and recovering from different abnormal events during the battery swapping process. EEDE can be understood as an exception handling module built on an event triggering and timeout mechanism. It sets corresponding detection conditions and handling paths for different exception types, such as locker door not opened, battery not returned, network abnormality, order interruption, signature verification failure, battery mismatch, or malfunction. For the locker door not opened exception, after the platform backend or locker terminal executes the locker opening control, a T1 timer is started, for example, set to 5 seconds. If the corresponding locker door is not actually opened within T1 time, an automatic retry is triggered, and a backup locker space can be reallocated and the locker opening command reissued. If multiple retries still fail, the order is marked as abnormal, the faulty locker space is frozen, and a maintenance work order is dispatched. For the battery not returned exception, after opening the empty battery locker space, a T2 related timer is started. Different waiting times can be set according to the business mode, such as 60 seconds in standard mode and 30 seconds in customized mode. After the old battery is inserted, the system continues to check the door closing status for 5 seconds for a single battery swap or 3 seconds for consecutive battery swaps. If no battery is detected or the door is closed within the timeout period, the door is automatically closed, the order status is updated, and a timeout notification is sent to the user. If a new battery has been removed but the old battery has not been returned, the system can also record the user's outstanding battery status. In case of network anomalies, the system can start a T3 timer after a status change event is sent, for example, set to 10 seconds. If no confirmation is received within the timeout period, a tiered recovery process is performed based on the location of the anomaly. The terminal can activate ODC to enter local offline decision-making mode. The platform backend marks orders as pending synchronization and completes asynchronous reconciliation and status updates by uploading local persistent logs after network recovery. For order interruptions, a T4 timer (e.g., set to 3 minutes) is activated when the Bluetooth connection between the user and the terminal is lost, no heartbeat is received from the user for an extended period, or the user leaves. If communication is not restored and battery swapping is not completed within this time, the terminal automatically closes the opened bay doors, releases bay resources, and caches the abnormal status. Subsequently, the platform backend changes the corresponding order to an interruption exception. Furthermore, for signature verification failures, the terminal performs ES256 signature verification using its local public key before executing the battery swapping command. If verification fails, execution is refused, and the platform is allowed to regenerate the command. Multiple consecutive failures can mark the terminal as a high-risk device and stop new order allocation. For battery mismatches or battery malfunctions, information such as battery ID, voltage, and temperature is read via NFC or the battery communication interface for judgment. If the battery ID does not match, acceptance is refused. If parameters such as temperature exceed safety thresholds, the battery can be accepted, but the corresponding bay is marked as faulty and maintenance is triggered. Therefore, Figure 3The EEDE shown does not uniformly terminate battery swapping after an anomaly occurs. Instead, it performs retry, resource recovery, switching to offline mode, status compensation, risk isolation, or maintenance handling according to the different stages, durations, and severity of the anomaly. This improves the automatic recovery capability and business continuity of the battery swapping process in the event of equipment failure, abnormal user operation, and network fluctuations.

[0073] Example 2 Please see Figure 4 This invention provides a multi-terminal collaborative control device for charging and battery swapping services, applied to a multi-terminal collaborative control system for charging and battery swapping services. The system includes a user terminal, a cabinet terminal, and a platform backend. The user terminal is communicatively connected to both the cabinet terminal and the platform backend, and the cabinet terminal is communicatively connected to the platform backend. The device includes: The connection status acquisition module is used to acquire the connection status between the cabinet terminal and the platform backend in response to the battery swapping request initiated by the user terminal for the cabinet terminal. A normal connection battery swapping processing module is used to determine the target battery swapping execution information based on the battery swapping request and the cabinet status information corresponding to the cabinet terminal if the connection status is normal. The connection interruption battery swapping processing module is used to send the offline authentication information provided by the platform backend and the battery swapping instruction corresponding to the battery swapping request to the cabinet terminal through the user terminal if the connection status is a connection interruption. The offline processing module is used to perform local verification of the offline authentication information through the cabinet terminal, and after the verification is successful, determine the target battery swap execution information based on the battery swap instruction and the offline decision data pre-stored in the cabinet terminal; The battery swapping execution module is used to control the cabinet terminal to perform a battery swapping operation based on the target battery swapping execution information, and obtain the battery swapping execution result.

[0074] It should be noted that each module and unit in the multi-terminal collaborative control device for charging and swapping services in this embodiment corresponds one-to-one with each step in the multi-terminal collaborative control method for charging and swapping services in the aforementioned embodiment. Therefore, the specific implementation of this embodiment can refer to the implementation of the multi-terminal collaborative control method for charging and swapping services in the aforementioned embodiment, and will not be repeated here.

[0075] Example 3 In addition, combined Figure 1 The multi-terminal collaborative control method for charging and swapping services described in this embodiment of the invention can be implemented by an electronic device. Figure 5 A schematic diagram of the hardware structure of an electronic device provided in an embodiment of the present invention is shown.

[0076] Electronic devices may include processors and memory storing computer program instructions.

[0077] Specifically, the processor may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement embodiments of the present invention.

[0078] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0079] Computer-readable media include both permanent and non-permanent, removable and non-removable media, which can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient media, such as modulated communication signals and carrier waves.

[0080] The processor reads and executes computer program instructions stored in the memory to implement any of the multi-terminal collaborative control methods for charging and swapping services in the above embodiments.

[0081] In one example, the electronic device may also include a communication interface and a bus. For example, Figure 5 As shown, the processor 401, memory 402, and communication interface 403 are connected through bus 410 and complete communication with each other.

[0082] The communication interface is mainly used to enable communication between various modules, devices, units and / or equipment in the embodiments of the present invention.

[0083] A bus, including hardware, software, or both, couples components of an electronic device together. For example, and not limitingly, a bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, a bus may include one or more buses. While specific buses are described and illustrated in embodiments of the invention, the invention contemplates any suitable bus or interconnect.

[0084] In summary, the multi-terminal collaborative control method, device, and equipment for charging and swapping services provided in this embodiment of the invention establishes multi-terminal communication relationships between the user terminal, the cabinet terminal, and the platform backend, and uses the connection status between the cabinet terminal and the platform backend as the basis for switching the swapping control path. This enables the system to adopt appropriate swapping decision-making methods for different network states: When the connection between the cabinet terminal and the platform backend is normal, the platform backend determines the target swapping execution information by combining the swapping request initiated by the user terminal and the cabinet status information corresponding to the cabinet terminal, thereby enabling unified swapping decisions using information such as users, equipment, and storage locations held by the platform backend; When the connection between the cabinet terminal and the platform backend is interrupted, the user terminal forwards the offline authentication information and swapping instructions provided by the platform backend to the cabinet terminal, taking advantage of the fact that the user terminal can communicate with both the platform backend and the cabinet terminal. This allows the cabinet terminal to still verify the legitimacy of the swapping request locally even when it cannot access the platform backend in real time, and autonomously determine the target swapping execution information by combining pre-stored offline decision data, thereby continuing to execute the swapping operation. Therefore, this solution does not simply terminate the battery swapping service when the network is interrupted, nor does it allow the charging station to operate independently without platform authorization. Instead, it adaptively switches between decision-making in the platform backend and local decision-making in the charging station based on the network connection status. At the same time, it utilizes the user terminal to handle information transmission in offline scenarios, so that both online and offline battery swapping paths are ultimately unified and reduced to the battery swapping execution control of the charging station. This improves the coordination capabilities of the user terminal, charging station, and platform backend under network status changes, reduces the impact of communication interruptions between the charging station and the platform backend on the continuity of the battery swapping service, and takes into account the authorization reliability and autonomous execution capability of the charging station during offline battery swapping, thereby improving the service availability and operational reliability of the charging and swapping system in complex network environments.

[0085] It should be clarified that the present invention is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of the present invention is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of the present invention.

[0086] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0087] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0088] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0089] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0090] It should also be noted that the exemplary embodiments mentioned in this invention describe methods or systems based on a series of steps or apparatus. However, this invention is not limited to the order of the steps described above; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0091] The above description is merely a specific embodiment of the present invention. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the protection scope of the present invention.

Claims

1. A multi-terminal collaborative control method for charging and battery swapping services, characterized in that, A multi-terminal collaborative control system for charging and swapping services, the system comprising a user terminal, a cabinet terminal, and a platform backend, wherein the user terminal is communicatively connected to both the cabinet terminal and the platform backend, and the cabinet terminal is communicatively connected to the platform backend; the method includes: In response to the battery swapping request initiated by the user terminal for the cabinet terminal, the connection status between the cabinet terminal and the platform backend is obtained; If the connection status is normal, then the target battery swap execution information is determined based on the battery swap request and the cabinet status information corresponding to the cabinet terminal. If the connection status is interrupted, the offline authentication information provided by the platform backend and the battery swapping instruction corresponding to the battery swapping request will be sent to the cabinet terminal through the user terminal; The offline authentication information is locally verified by the cabinet terminal, and after the verification is successful, the target battery swap execution information is determined based on the battery swap instruction and the offline decision data pre-stored in the cabinet terminal. Based on the target battery swapping execution information, the cabinet terminal is controlled to perform a battery swapping operation, and the battery swapping execution result is obtained.

2. The multi-terminal collaborative control method for charging and swapping services according to claim 1, characterized in that, The step of responding to the battery swapping request initiated by the user terminal for the cabinet terminal, and obtaining the connection status between the cabinet terminal and the platform backend, includes: The platform backend receives the battery swapping request sent by the user terminal and extracts the user identity token from the access request corresponding to the battery swapping request. Based on the user identity token, determine the target role of the user corresponding to the user terminal; Based on the battery swapping request, determine the corresponding target resources and target operations; The target resource and the target operation are matched with the permission matrix corresponding to the target role to obtain the permission matching result; When the permission matching result is a successful match, the user data and cabinet data corresponding to the battery swapping request are verified for access permissions according to the data permission scope corresponding to the target role, and the data permission verification result is obtained. When the data permission verification result is successful, the battery swapping request is accepted, and the connection status between the cabinet terminal and the platform backend is obtained.

3. The multi-terminal collaborative control method for charging and swapping services according to claim 1, characterized in that, The step of locally verifying the offline authentication information through the cabinet terminal, and determining the target battery swap execution information based on the battery swap instruction and the offline decision data pre-stored on the cabinet terminal after successful verification, includes: Based on the offline authentication information, obtain the user token corresponding to the battery swapping request; The user token is matched with the list of authorized user tokens in the offline decision data, and it is determined whether the user token is within the validity period. Based on the matching result and the validity period determination result, the local authentication result is determined. When the local authentication result is successful, the target battery model corresponding to the battery swapping request is determined according to the battery swapping instruction. The target battery model is matched with the battery model whitelist in the offline decision data to obtain the model matching result; When the model matching result is a successful match, the second candidate fully charged battery compartment and the second candidate empty battery compartment are determined according to the target battery model and the battery compartment mapping table in the offline decision data. The target fully charged battery compartment and the target empty battery compartment are determined from the second candidate fully charged battery compartment and the second candidate empty battery compartment, respectively, and the target battery swapping execution information is determined based on the target fully charged battery compartment and the target empty battery compartment.

4. The multi-terminal collaborative control method for charging and swapping services according to claim 3, characterized in that, The step of matching the user token with the list of authorized user tokens in the offline decision data and determining whether the user token is within its validity period, and determining the local authentication result based on the matching result and the validity period determination result, includes: Extract the credential payload and signature information corresponding to the user token from the offline authentication information; The signature information is verified using the verification public key pre-stored at the terminal of the machine to obtain the signature verification result. When the signature verification result is successful, the credential user identifier and credential validity period are determined based on the credential payload; The user identifier of the credential is compared with the user identifier corresponding to the battery swapping instruction to obtain a user identifier consistency result; The user token is matched with the list of authorized user tokens to obtain the token matching result; The local authentication result is determined based on the signature verification result, the user identifier consistency result, the token matching result, and the credential validity period.

5. The multi-terminal collaborative control method for charging and swapping services according to claim 3, characterized in that, When the model matching result is a successful match, determining the second candidate fully charged storage compartment and the second candidate empty storage compartment based on the target battery model and the storage compartment battery mapping table in the offline decision data includes: Based on the battery mapping table for each compartment, determine the battery storage information corresponding to each compartment in the cabinet terminal; Based on the battery storage information corresponding to each of the aforementioned compartments, determine the first set of compartments with stored batteries and the second set of compartments without stored batteries; Based on the battery information corresponding to each compartment in the first compartment set, the compartments whose battery models match the target battery model and whose corresponding batteries meet the full charge condition are selected from the first compartment set to obtain the second candidate fully charged compartments; The storage spaces in the second storage space set that meet the battery return conditions are determined as the second candidate empty battery storage spaces.

6. The multi-terminal collaborative control method for charging and swapping services according to any one of claims 1-5, characterized in that, The step of controlling the cabinet terminal to perform a battery swapping operation based on the target battery swapping execution information, and obtaining the battery swapping execution result, includes: According to the target battery swap execution information, the cabinet terminal is controlled to perform a battery swap operation according to a preset battery swap process. The preset battery swap process includes a battery swap instruction reception and confirmation stage, an empty battery compartment opening stage, a battery return confirmation stage, a fully charged compartment opening stage, a battery removal confirmation stage, and a battery swap completion confirmation stage. Based on the preset battery swapping process and the current execution status of the cabinet terminal during the battery swapping operation, the current battery swapping stage is obtained; Based on the current battery swapping stage, the corresponding target detection object, target detection parameters, and stage completion conditions are determined from the preset stage anomaly detection strategy library; Based on the target detection parameters, the target object is detected to obtain the detection result for the current stage; When the current stage detection result does not meet the stage completion condition, the abnormal event corresponding to the current stage detection result is handled to obtain the abnormal handling result. Based on the anomaly handling result, when it is determined that the current stage detection result after anomaly handling meets the stage completion condition, the cabinet terminal is controlled to enter the next battery swapping stage in the preset battery swapping process, and the next battery swapping stage is returned as the new current battery swapping stage to the step of determining the corresponding target stage anomaly detection strategy from the preset stage anomaly detection strategy library based on the current battery swapping stage, until all battery swapping stages in the preset battery swapping process are completed, and the battery swapping execution result is obtained.

7. The multi-terminal collaborative control method for charging and swapping services according to claim 6, characterized in that, The step of detecting the target object according to the target detection parameters to obtain the detection result at the current stage includes: Based on the phase execution action corresponding to the current battery swapping phase, a target anomaly detection chain is obtained. The target anomaly detection chain includes multiple step-by-step detection links arranged in the order of execution of the phase execution actions. Each step-by-step detection link corresponds to at least one target detection object and at least one target detection parameter. According to the arrangement order of each step of the target anomaly detection chain and the target detection parameters, the corresponding target detection object is detected step by step, and the detection completion status of the current step by step detection link is used as the starting condition for the next step by step detection link. When the detection result of the current step by step detection link meets the corresponding link completion condition, the next step by step detection link is started. When the detection result of any of the step-by-step detection steps does not meet the corresponding step completion condition, the current stage detection result is determined to be that the stage completion condition is not met, and the execution of subsequent step-by-step detection steps is stopped. When the detection results of each of the step-by-step detection stages meet the corresponding stage completion conditions, the detection result of the current stage is determined to meet the stage completion conditions.

8. The multi-terminal collaborative control method for charging and swapping services according to claim 7, characterized in that, When the current stage detection result does not meet the stage completion condition, the abnormal event corresponding to the current stage detection result is handled abnormally, and the abnormal handling result includes: Extract detection anomalies that do not meet the stage completion conditions from the current stage detection results, and associate each detection anomaly with the stage execution action corresponding to the current battery swapping stage to form at least one candidate anomaly event; Based on the current battery swapping stage, a target abnormal event relationship chain corresponding to the current battery swapping stage is determined from a preset abnormal event relationship chain. The target abnormal event relationship chain is used to characterize the sequential occurrence relationship and abnormal impact relationship between different abnormal events in the current battery swapping stage. Each candidate abnormal event is matched with an abnormal event in the target abnormal event relationship chain to determine the abnormal occurrence position of each candidate abnormal event in the target abnormal event relationship chain, and the association relationship between each candidate abnormal event is determined based on the abnormal occurrence position. For candidate abnormal events with a relationship, reverse tracing is performed according to the abnormal influence direction in the relationship chain of the target abnormal event. The upstream abnormal event that causes other candidate abnormal events and is not caused by other candidate abnormal events is identified as the target abnormal event, and the other candidate abnormal events caused by the target abnormal event are identified as the accompanying abnormal events. Based on the abnormal event type corresponding to the target abnormal event and the phase completion conditions of the current battery swapping phase, the target abnormal handling action is determined from the preset abnormal handling strategy, and the battery swapping cabinet is controlled to execute the target abnormal handling action to obtain the abnormal handling result.

9. A multi-terminal collaborative control device for charging and battery swapping services, characterized in that, A multi-terminal collaborative control system for charging and swapping services, the system including a user terminal, a cabinet terminal, and a platform backend, wherein the user terminal is communicatively connected to both the cabinet terminal and the platform backend, and the cabinet terminal is communicatively connected to the platform backend; the device includes: The connection status acquisition module is used to acquire the connection status between the cabinet terminal and the platform backend in response to the battery swapping request initiated by the user terminal for the cabinet terminal. A normal connection battery swapping processing module is used to determine the target battery swapping execution information based on the battery swapping request and the cabinet status information corresponding to the cabinet terminal if the connection status is normal. The connection interruption battery swapping processing module is used to send the offline authentication information provided by the platform backend and the battery swapping instruction corresponding to the battery swapping request to the cabinet terminal through the user terminal if the connection status is a connection interruption. The offline processing module is used to perform local verification of the offline authentication information through the cabinet terminal, and after the verification is successful, determine the target battery swap execution information based on the battery swap instruction and the offline decision data pre-stored in the cabinet terminal; The battery swapping execution module is used to control the cabinet terminal to perform a battery swapping operation based on the target battery swapping execution information, and obtain the battery swapping execution result.

10. An electronic device, characterized in that, include: At least one processor, at least one memory, and computer program instructions stored in the memory, which, when executed by the processor, implement the method as described in any one of claims 1-8.

Images