An intelligent scheduling method for battery replacement of an electric two-wheeled vehicle

CN122539954APending Publication Date: 2026-08-11WARBURG PINCUS (SHENZHEN) TECHNOLOGY CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2026-06-24
Publication Date
2026-08-11

AI Technical Summary

Technical Problem

[0004]然而,这种最优匹配算法天然趋向于将用户集中引导至评分最高的少数热门换电柜,容易造成局部过载而其他柜机闲置的负载不均问题

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122539954A_ABST
    Figure CN122539954A_ABST
Patent Text Reader

Abstract

This invention provides an intelligent scheduling method for battery swapping in electric two-wheeled vehicles, belonging to the field of data processing technology. The method is applied to a scheduling center and includes: the scheduling center receiving a battery swapping request sent by the electric two-wheeled vehicle at its corresponding physical location; in response to the battery swapping request, the scheduling center determining a battery swapping resource set, and based on a hash function, pseudo-randomly selecting multiple candidate battery compartments from the battery swapping resource set for the electric two-wheeled vehicle; the battery swapping resource set including available battery compartments within the physical area where the physical location is located; and the scheduling center indicating the physical locations of the multiple candidate battery compartments to the electric two-wheeled vehicle.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to an intelligent scheduling method for battery swapping in electric two-wheeled vehicles. Background Technology

[0002] With the rapid growth in the number of electric two-wheeled vehicles, battery swapping has become an important energy replenishment method for urban travel due to its convenience. Battery swapping networks typically consist of a large number of distributed swapping stations, each containing multiple battery compartments. When a user's battery is low, they need to go to a nearby swapping station to replace it.

[0003] Existing battery swapping scheduling methods generally employ a centralized architecture: when a user initiates a battery swapping request via a mobile terminal, the cloud-based scheduling center obtains the user's location information and combines it with real-time status data of all batteries in the current battery swapping cabinets (including battery level, health status, temperature, etc.) to perform calculations using a preset matching algorithm. This algorithm typically compares the user's request with the battery status one by one, selecting the battery compartment with the best comprehensive score in dimensions such as distance, battery level, and health status from globally available resources, and returning the location information of the designated battery compartment to the user, who then proceeds to the corresponding battery swapping cabinet to complete the swap.

[0004] However, this optimal matching algorithm naturally tends to concentrate users in a few popular battery swapping stations with the highest ratings, which can easily cause uneven load distribution, with some stations being overloaded while others remain idle. Summary of the Invention

[0005] To address the aforementioned technical problems, the present invention provides the following solution: Firstly, a method for intelligent scheduling of battery swapping for electric two-wheeled vehicles is provided. This method is applied to a scheduling center and includes: the scheduling center receiving a battery swapping request sent by the electric two-wheeled vehicle at a corresponding physical location; in response to the battery swapping request, the scheduling center determining a set of battery swapping resources and, based on a hash function, pseudo-randomly selecting multiple candidate battery compartments from the set of battery swapping resources for the electric two-wheeled vehicle, the set of battery swapping resources including available battery compartments within the physical area where the physical location is located; and the scheduling center indicating the physical locations of the multiple candidate battery compartments to the electric two-wheeled vehicle.

[0006] Therefore, upon receiving a battery swap request, the dispatch center first determines a battery swap resource set containing all available battery compartments within the physical location area. Then, based on a hash function, it pseudo-randomly selects multiple candidate battery compartments from this resource set for the electric two-wheeler, rather than calculating a unique optimal solution through global state comparison. The hash function has low computational complexity, eliminating the need for one-by-one comparison of real-time battery states. This simplifies the scheduling decision from complex matching operations to efficient mapping operations, significantly reducing server computational load and easily supporting massive concurrent requests during peak periods. Simultaneously, the uniform distribution characteristic of the hash function allows different users to be pseudo-randomly guided to different battery compartments within the resource set, naturally achieving load balancing and effectively avoiding the problems of overloading popular compartments and leaving less popular ones idle. Furthermore, the redundant design of multiple candidate battery compartments provides users with on-site options. If the preferred battery compartment becomes unavailable due to physical uncertainties (such as physical damage or charging abnormalities), users can still switch to alternative battery compartments, avoiding process interruptions caused by re-initiating requests due to failure to specify a single target, thus improving the success rate of a single battery swap and the user experience.

[0007] Optionally, multiple candidate battery compartments are pseudo-randomly selected from the battery swapping resource set based on a hash function, including: the dispatch center generates a temporary and one-time-use battery swapping session identifier for the battery swapping request; the dispatch center determines multiple candidate battery compartments pseudo-randomly for the electric two-wheeler based on the hash function, the battery swapping session identifier, and the number of battery compartments in the battery swapping resource set.

[0008] Therefore, by generating a temporary, one-time-use battery swap session identifier for each battery swap request, the scheduling center can select candidate battery compartments without storing users' historical session states. This identifier is only valid for the current request; even if the same user repeatedly initiates battery swap requests at the same location, a different session identifier will be generated each time, resulting in different lists of candidate battery compartments. This mechanism effectively prevents malicious users from pre-emptively occupying specific battery compartment resources by replaying old requests, enhancing system security and fairness. Simultaneously, the one-time-use characteristic simplifies server-side state management; the scheduling center does not need to maintain complex user session contexts, reducing system implementation complexity.

[0009] Optionally, the battery swapping session identifier satisfies the following relationship: SID=H(UserID||Timestamp||RequestedPower||LocationFuzzyCode||RandomSalt); where, SID is the battery swapping session identifier, H() is the anti-collision hash function, || is concatenation, UserID is the user identifier corresponding to the electric two-wheeler, Timestamp is the time when the electric two-wheeler sent the battery swapping request, RequestedPower is the battery swapping power demand level indicated by the battery swapping request or the estimated required range, LocationFuzzyCode is the location fuzzy code corresponding to the physical location, and RandomSalt is a temporary and one-time random parameter generated by the scheduling center for the battery swapping request.

[0010] Therefore, the generation of the battery swapping session identifier integrates multiple dimensions of information, including user identifier, timestamp, battery swapping demand, location fuzzy encoding, and random parameters. The introduction of the timestamp ensures that requests at different times generate different identifiers, fundamentally eliminating the possibility of replay attacks. The introduction of battery swapping demand implicitly diverts users with different range requirements into different candidate sets. The use of location fuzzy encoding preserves regional correlation while avoiding the exposure of the user's precise location, protecting location privacy. The addition of random parameters further increases the unpredictability of the identifier, preventing attackers from speculating or colliding with other users' session identifiers by constructing specific inputs. The fusion of multiple factors gives the session identifier inherent uniqueness, timeliness, and unpredictability, further enhancing the randomness of subsequent hashing.

[0011] Optionally, the battery swapping session identifier satisfies the following relationship: SID=H(UserID||Timestamp||PreviousSID||RandomSalt); where, SID is the battery swapping session identifier, H() is the collision-resistant hash function, || is concatenation, UserID is the user identifier corresponding to the electric two-wheeler, Timestamp is the time when the electric two-wheeler sent the battery swapping request, PreviousSID is the battery swapping session identifier used by the user corresponding to the electric two-wheeler in the past when the battery swapping was successful. When the user is swapping for the first time, PreviousSID is a preset initial value, and RandomSalt is a temporary and one-time random parameter generated by the scheduling center for the battery swapping request.

[0012] Therefore, by introducing the session identifier used in a previous successful battery swap as one of the input parameters for generating the current session identifier, a chain-like relationship is formed between different battery swap sessions of the same user. This chain structure provides the system with a lightweight behavior auditing capability. If abnormal battery swapping behavior occurs (such as the session identifier being intercepted and replayed), the system can detect it by verifying the continuity of the session chain. Simultaneously, using preset initial values ​​for first-time battery swapping users ensures the universality of the solution. This design provides additional guarantees for the traceability of user battery swapping behavior and system security without increasing the overhead of centralized database queries.

[0013] Optionally, the dispatch center determines multiple candidate battery compartments for the electric two-wheeler in a pseudo-random manner based on the hash function, the battery swapping session identifier, and the number of battery compartments in the battery swapping resource center. This includes: the dispatch center determines multiple candidate battery compartments for the electric two-wheeler in a pseudo-random manner based on the hash function, the aggregation level, the battery swapping session identifier, and the number of battery compartments in the battery swapping resource center. The aggregation level is used to indicate whether at least two candidate battery compartments are aggregated into one candidate battery compartment block.

[0014] Therefore, by introducing the aggregation level parameter, the candidate battery compartment selection mechanism can flexibly adapt to different vehicle configurations and battery states. The aggregation level indicates whether at least two candidate battery compartments should be aggregated into one candidate battery compartment block. When the aggregation level is 1, each candidate corresponds to a single battery compartment, which is suitable for ordinary single-battery vehicles. When the aggregation level is greater than 1, multiple physical battery compartments are bound into one candidate battery compartment block (or logical candidate block), which is suitable for vehicles that support dual-battery or multi-battery parallel operation, or scenarios where a single battery has low health and requires combined power supply. This mechanism unifies the scheduling requirements of different hardware configurations under the same framework, eliminating the need to deploy independent scheduling logic for different types of vehicles and improving the flexibility of the battery swapping solution.

[0015] Optionally, the battery swapping session identifier, aggregation level, number of centralized battery swapping resource compartments, and multiple candidate battery compartments satisfy the following relationship: index_i=Hash(SID||i)modN'; where, Hash() is a hash function, SID is the battery swapping session identifier, || represents a connection, L is the aggregation level, L is an integer greater than or equal to 1, and N is an integer multiple of L; when L equals 1, N'=N, N is the number of battery compartments in the battery swapping resource set, and index_i indicates the i-th candidate battery compartment selected in the battery swapping resource set, i is an integer from 1 to M, and M is an integer greater than 1 and less than N'; when L is greater than 1, N'=N / L, and index_i indicates the i-th candidate battery compartment block selected in the battery swapping resource set.

[0016] Therefore, the above scheme is a specific implementation of aggregation level. It involves dividing the total number N of battery compartments in the battery swapping resource pool by the aggregation level L to obtain the adjusted resource pool size N', and then performing a hash modulo operation. When the aggregation level is greater than 1, the hash operation directly maps to logical blocks, with each logical block corresponding to L physically adjacent battery compartments. This method moves the grouping operation before the hash mapping, simplifying the calculation process. A single hash operation locates a complete candidate block without additional post-processing steps. It is suitable for scenarios where the battery swapping cabinets have already pre-grouped or arranged adjacently according to aggregation requirements during deployment.

[0017] Optionally, the battery swapping session identifier, aggregation level, number of centralized battery swapping resource compartments, and multiple candidate battery compartments satisfy the following relationship: base_index_i=Hash(SID||i)modN; Where Hash() is the hash function, SID is the battery swapping session identifier, || represents a connection, N is the number of battery compartments in the battery swapping resource set, i is an integer from 1 to M, M is the preset number of candidates and is greater than 1 and less than N; L is the aggregation level. When L equals 1, the i-th candidate battery compartment is the battery compartment with index base_index_i in the battery swapping resource set; when L is greater than 1, the i-th candidate battery compartment block consists of L consecutive battery compartments with indices from block_start_i to block_start_i+L-1 in the battery swapping resource set. Among them, block_start_i=base_index_i-(base_index_imodL).

[0018] Therefore, the above scheme is another specific implementation of the aggregation level. It always performs hash mapping on a physical battery compartment basis to obtain the base index, and then calculates the starting index of the logical block based on the aggregation level L using modulo subtraction, thus determining L consecutive battery compartments as a candidate block. This method postpones the grouping operation after the hash mapping, without changing the modulus of the hash operation. The resource pool always operates at the physical compartment level, making it more flexible. When the physical layout of the battery swapping cabinet needs to be dynamically adjusted to change the binding strategy, there is no need to rebuild the index system of the logical resource pool; only the aggregation calculation logic in post-processing needs to be adjusted, reducing the system's dependence on hardware deployment.

[0019] Optionally, the dispatch center determines the battery swapping resource set, including: the dispatch center determines an area at a preset distance from the physical location as a physical area; the dispatch center determines that all available battery compartments located within the physical area constitute the battery swapping resource set.

[0020] Therefore, by defining a physical area within a preset distance centered on the user's physical location and incorporating all available battery compartments within that area into the battery swapping resource set, the geographical range of candidate battery compartments is precisely matched to the user's actual reachability. The preset distance setting can be dynamically adjusted based on factors such as urban traffic conditions and the density of battery swapping station distribution. While ensuring that users can conveniently reach candidate battery compartments, the size of the resource set is controlled to avoid increasing the user's travel costs due to an overly large resource set leading to excessively dispersed candidate battery compartments. This achieves a balance between scheduling flexibility and user experience.

[0021] Optionally, the dispatch center instructs the electric two-wheeler on the physical locations of multiple candidate battery compartments, including: the dispatch center sending a battery swapping response to the electric two-wheeler, the battery swapping response including identifiers of multiple candidate battery compartments and information indicating the physical locations of the multiple candidate battery compartments.

[0022] This indicates that the battery swapping response sent by the dispatch center to the electric two-wheeler includes the identifiers of multiple candidate battery compartments and their physical locations. This allows users to know the distribution of all candidate options in advance and plan their route accordingly. Users do not have to visit the candidate compartments in strict order according to the candidate list; instead, they can flexibly choose the first candidate battery compartment to try based on their current location and preferences, reducing unnecessary back-and-forth travel.

[0023] Optionally, after the dispatch center sends a battery swapping response to the electric two-wheeler, the method further includes: the dispatch center receiving a battery swapping success message from the electric two-wheeler, the battery swapping success message indicating to the user the target battery compartment selected from multiple candidate battery compartments.

[0024] Therefore, after sending a battery swap response, the dispatch center receives a successful battery swap notification from the electric two-wheeler. This notification clearly indicates to the user the target battery compartment selected from multiple candidate battery compartments. This feedback mechanism enables the dispatch center to perceive the actual usage status of each candidate battery compartment in real time, update the battery compartment occupancy status promptly, and prevent the same battery compartment from being repeatedly allocated by subsequent requests.

[0025] In a second aspect, a computer-readable storage medium is provided, comprising: a computer program or instructions; when the computer program or instructions are executed on a computer, the computer causes the computer to perform the method described in the first aspect. Attached Figure Description

[0026] Figure 1 This is a schematic diagram of the architecture of a battery swapping system provided in an embodiment of the present invention; Figure 2 This is a flowchart illustrating an intelligent scheduling method for battery swapping of electric two-wheeled vehicles provided in an embodiment of the present invention. Figure 3This is another flowchart illustrating the intelligent scheduling method for battery swapping of electric two-wheeled vehicles provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0027] The technical solution of the present invention will now be described with reference to the accompanying drawings.

[0028] In this embodiment of the invention, descriptions such as "when," "under the circumstances," "if," and "if" all refer to the device making corresponding processing under certain objective circumstances, and are not limited to a specific time. They do not require the device to make a judgment action during implementation, nor do they imply any other limitations.

[0029] To facilitate understanding of the embodiments of the present invention, firstly, using Figure 1 The battery swapping system shown in the image is an example. Figure 1 As shown, the battery swapping system includes a dispatch center and distributed battery compartments.

[0030] The dispatch center is the core decision-making node of the battery swapping network, responsible for executing the intelligent scheduling method for battery swapping of electric two-wheeled vehicles provided in the embodiments of this application. Physically, the dispatch center can be a standalone physical server, a server cluster composed of multiple servers using load balancing technology, or a virtual server instance (i.e., a cloud server) deployed on a cloud computing platform. The dispatch center internally deploys a battery swapping scheduling service program, which can run on operating systems such as Linux and Windows, and interacts with the cabinet control terminals of each battery swapping station and the user's mobile terminal through communication methods such as Application Programming Interface (API) or message queues. From a functional perspective, the dispatch center primarily handles the following processing logic: It receives battery swapping requests initiated by the onboard communication module of the electric two-wheeled vehicle or its user's mobile terminal via cellular mobile communication networks (such as 4G or 5G) or wireless local area networks (WLANs). These requests carry the physical location information of the electric two-wheeled vehicle. In response to the battery swapping request, the dispatch center, based on a preset geofencing strategy, determines a physical area within a preset distance centered on the physical location and includes all serviceable battery compartments within this physical area into the battery swapping resource set corresponding to this request. Furthermore, the dispatch center generates a temporary, one-time-use battery swapping session ID (SID) for this request and uses a preset hash function. The system uses a pseudo-random mapping operation to select multiple candidate battery compartments from the battery swapping resource set, based on the battery swapping session identifier and the total number of available battery compartments. Then, the dispatch center sends a battery swapping response containing the identifiers of these candidate battery compartments and the physical location information of their respective battery swapping cabinets to the electric two-wheeled vehicle or its user terminal, allowing the user to proceed to the site for further local confirmation and battery swapping operations. Simultaneously, the dispatch center maintains a real-time status database of all battery compartments in the entire battery swapping network. This database records parameters such as the occupancy status of each battery compartment, the remaining charge (SOC) of the batteries within the compartment, the state of health (SOH), battery temperature, and the number of cycles. This status data is reported in real-time by each battery swapping cabinet, providing the dispatch center with the foundational data for determining battery compartment availability and executing scheduling decisions.

[0031] The battery compartment is the smallest physical unit for storing, charging, and managing batteries in a battery swapping network, and it is distributed across battery swapping cabinets in different geographical locations. Each battery compartment is assigned a globally unique and unchangeable physical identifier to facilitate precise addressing throughout the battery swapping network. Structurally, each battery compartment contains a battery housing slot, electrical connectors, charging control circuitry, locking mechanisms, a status monitoring module, and a compartment control communication module. The battery compartment is used to accommodate removable, standardized rechargeable battery packs. The electrical connector automatically interfaces with the power and signal contacts after the battery pack is inserted, enabling power transmission and data communication. The charging control circuit manages constant current or constant voltage charging of the batteries in the compartment according to the charging strategy issued by the dispatch center or cabinet control terminal. The locking mechanism automatically locks the compartment door after the battery pack is inserted, and can be unlocked by the user through scanning a code or Near Field Communication (NFC). The status monitoring module integrates voltage, current, and temperature sensors, enabling real-time collection of parameters such as battery voltage, charging / discharging current, cell temperature, and battery health. This status information is periodically or triggered by events and reported to the dispatch center via wired or wireless means through the compartment control communication module. The compartment control communication module also receives control commands from the dispatch center or cabinet control terminal, such as compartment opening commands, charging start / stop commands, and indicator light control commands. Based on the status information reported by each battery compartment, the dispatch center determines in real time whether each battery compartment is in an available state. That is, when there are no batteries in the battery compartment, or the batteries in the compartment are fully charged and have not been reserved, or the remaining power and health of the batteries in the compartment meet the preset threshold, the battery compartment is marked as serviceable and is identified as a set of battery swapping resources that can be scheduled for subsequent battery swapping requests.

[0032] This application provides an intelligent scheduling method for battery swapping in electric two-wheeled vehicles. This method is applied to a scheduling center and uses a hash function to generate multiple candidate battery compartments for users in a pseudo-random manner. This transforms the traditional centralized optimal matching scheduling mode into a decentralized candidate set scheduling mode, thereby reducing computational overhead while achieving natural load balancing.

[0033] Figure 2 The illustration shows a flowchart of an intelligent scheduling method for battery swapping of electric two-wheeled vehicles provided in an embodiment of this application. The method includes steps S201 to S203, and optionally, step S204.

[0034] S201, the dispatch center receives a battery swapping request sent by an electric two-wheeler at the corresponding physical location.

[0035] Electric two-wheeled vehicles refer to two-wheeled vehicles that use replaceable rechargeable battery packs as their sole or partial power source, including but not limited to electric bicycles, electric motorcycles, and electric mopeds. Users of electric two-wheeled vehicles can initiate battery swapping requests in two ways: one is through a battery swapping application (APP) installed on their mobile terminal (such as a smartphone), and the other is through the vehicle's built-in onboard communication module. A battery swapping request is a message sent by the user to the dispatch center through either of the above methods, requesting the allocation of a swappable battery. This message is transmitted to the dispatch center via communication links such as cellular mobile communication networks (e.g., 4G, 5G) or wireless local area networks (WLANs).

[0036] The battery swap request carries information including user identifier, vehicle identifier, physical location, and power demand information. The user identifier is a unique identification code used to identify a registered user in the battery swap system. It can be a numerical number, string, or a combination thereof assigned by the system during user registration, such as "UID_2024_001587". The vehicle identifier is a unique identification code used to identify a registered electric two-wheeler in the battery swap system. It can be a Vehicle Identification Number (VIN) or a unique number assigned to the vehicle by the system, such as "VIN_LS2BGAJN3M0001234". Through the vehicle identifier, the dispatch center can obtain configuration information such as the vehicle's battery compatibility model and whether it supports multi-battery parallel power supply, providing a basis for subsequent aggregation level selection. The physical location refers to the actual geographical location of the electric two-wheeler when sending the battery swap request. The physical location can be obtained through satellite positioning technologies such as the Global Positioning System (GPS) and the BeiDou Navigation Satellite System (BDS), or through cellular base station positioning or wireless local area network positioning. It can be represented as a set of latitude and longitude coordinates, such as "30°35'N, 104°04'E". Battery demand information is used to characterize the user's expectations for the battery's charge or driving range after the battery replacement. In one implementation, the battery demand information can be an estimated required driving range, referring to the distance the user expects the vehicle to travel after the battery replacement, expressed in kilometers, such as "50 kilometers". In another implementation, the power demand information can be the requested power demand level, which refers to dividing the user's expectation of the remaining battery power into one of several levels according to preset rules. For example, the remaining battery power (State of Charge, SOC) demand can be divided into three levels: low, medium, and high. "Low" corresponds to an SOC of not less than 50%, "medium" corresponds to an SOC of not less than 70%, and "high" corresponds to an SOC of not less than 90%. Users can select the level that matches their needs when initiating a battery swap request.

[0037] Accordingly, the dispatch center receives the battery swapping request through its network communication interface, parses the aforementioned information items from the message body, and puts the parsed request data into the request processing queue, waiting to execute the subsequent dispatch processing procedures.

[0038] S202, in response to the battery swapping request, the dispatch center determines the battery swapping resource set and, based on a hash function, pseudo-randomly selects multiple candidate battery compartments from the battery swapping resource set for the electric two-wheeler. The battery swapping resource set includes available battery compartments within the physical area where the physical location is located.

[0039] In this context, the battery swapping resource set refers to a logical set of available battery compartments delineated by the dispatch center from the entire battery swapping network for this particular battery swapping request. A hash function is a cryptographic function that maps an input message of arbitrary length to a fixed-length output digest. It possesses determinism (identical inputs will always produce the same output), collision resistance (it is computationally infeasible to find two different inputs that produce the same output), and uniform distribution (the output follows a uniform distribution within the value space). In this application, the hash function is used to map the battery swapping session identifier to the index value of the battery compartment. Candidate battery compartments refer to multiple battery compartments that the dispatch center pseudo-randomly selects from the battery swapping resource set using a hash function and recommends to the user for priority testing. Pseudo-randomness means that although the selection process is calculated by a deterministic hash function, due to the uniform distribution of the hash function output and the unpredictability of the input seed, the output result statistically exhibits an unpredictable random distribution.

[0040] This step is the core step in the embodiments of this application. Instead of performing traditional global state matching calculations, the scheduling center generates a candidate battery compartment list through hash mapping. See also... Figure 3 Specifically, it includes the following sub-steps.

[0041] S202a, the dispatch center determines the battery swapping resource set.

[0042] First, the dispatch center determines the area within a preset distance from the physical location of the battery swapping request, based on a pre-defined geofencing strategy. This preset distance is a pre-configured distance threshold used to delineate the geographical scope of the dispatch. It can be dynamically adjusted according to the deployment density of battery swapping stations in the city; for example, it can be set to 2 kilometers in the core urban area and 5 kilometers in the suburbs. Then, the dispatch center queries its maintained real-time status database to determine all available battery compartments within this physical area as a logical set. This set is the battery swapping resource set for this request.

[0043] The availability status refers to the battery compartment meeting preset serviceability conditions, specifically including: the battery compartment contains a battery, the remaining charge (SOC) of the battery is not lower than a preset threshold (e.g., SOC ≥ 80%), the battery health (SOH) is not lower than a preset threshold (e.g., SOH ≥ 70%), the battery compartment is not currently reserved by other users, and the hardware of the battery compartment is fault-free. The dispatch center maintains the availability flag of each battery compartment in real time based on the battery compartment status information periodically reported or triggered by events from each battery swapping station.

[0044] Assume there are N available battery compartments in this battery swapping resource set, and each battery compartment has a unique index number in the resource set. These N battery compartments can be represented as a set R={C_0,C_1,...,C_{N-1}}, where C_j represents the identifier of the battery compartment with index j.

[0045] S202b, the dispatch center generates a temporary and one-time-use battery swap session identifier for the battery swap request.

[0046] In this embodiment, the scheduling center does not directly schedule based on the user identifier. Instead, it generates a temporary and one-time-use battery swap session identifier (SessionID, SID) for each battery swap request. Temporary means that the battery swap session identifier is only valid within the processing period of this battery swap request and automatically expires after the battery swap is completed or after a preset validity period. One-time-use means that the same battery swap session identifier will not be reused for scheduling another battery swap request; even if the same user initiates two consecutive battery swap requests, the generated battery swap session identifiers will be different.

[0047] In one possible implementation, the battery swapping session identifier satisfies the following relationship: SID=H(UserID||Timestamp||RequestedPower||LocationFuzzyCode||RandomSalt); Wherein, H() is a collision-resistant hash function, such as a truncated version of the Secure Hash Algorithm (SHA) SHA-256 or SHA-3. || represents a concatenation operation, that is, concatenating the binary or string representations of each parameter in sequence to form a continuous input. UserID is the user identifier corresponding to the electric two-wheeler, with the same meaning as described in step S201. Timestamp is the time when the electric two-wheeler sent the battery swap request, which can be accurate to milliseconds, for example, using the Unix timestamp format, such as "1716537600000" representing a millisecond-level time at a certain moment on May 24, 2024. RequestedPower is the battery swap power demand level indicated by the battery swap request or the estimated required range, with the same meaning as described in step S201. LocationFuzzyCode is the fuzzy location code corresponding to the physical location. It refers to converting the precise physical location coordinates into a low-precision regional code through a preset mapping algorithm. For example, the latitude and longitude coordinates are mapped to a geographic grid with a side length of 500 meters, and the grid number "Zone_07" is taken as the fuzzy location code, thereby protecting the user's precise location privacy while preserving regional correlation. RandomSalt is a temporary and one-time random parameter generated by the dispatch center for this battery swap request. It can be a high-entropy random number (such as a 128-bit random bit string) or a pseudo-random sequence generated by a pseudo-random number generator (PRNG).

[0048] In another possible implementation, the battery swapping session identifier satisfies the following relationship: SID=H(UserID||Timestamp||PreviousSID||RandomSalt); Here, PreviousSID is the battery swap session identifier used by the user of the electric two-wheeler during a previous successful battery swap. When the user is swapping batteries for the first time, PreviousSID is a preset initial value. This preset initial value refers to a fixed string or constant value pre-set for each user during the initialization phase or user registration, such as a 32-bit string of all zeros, or a special constant "INITIAL_SESSION_000000" agreed upon by the system. This chained structure links multiple battery swap sessions of the user, providing the system with lightweight behavior auditing capabilities. If the session identifier of a battery swap is illegally intercepted and a replay is attempted, the replay request can be effectively identified and rejected because PreviousSID cannot match the historical value recorded on the chain by the system.

[0049] In S202c, the dispatch center determines multiple candidate battery compartments for electric two-wheeled vehicles by pseudo-randomly selecting them based on the hash function, the battery swapping session identifier, and the number of battery compartments in the battery swapping resource center.

[0050] The dispatch center uses the battery swapping session identifier (SID) as the input seed and performs mapping calculations in the battery swapping resource set through a hash function to pseudo-randomly select M candidate battery compartments. M is a preset number of candidates, an integer greater than 1 and much less than N; for example, M can be 3 or 5. The specific value of M can be configured according to the deployment density of the battery swapping cabinets and the user's expectation of the number of candidates. The larger M is, the more candidates the user has, but the probability of cross-cabinet movement also increases.

[0051] Furthermore, the dispatch center can introduce an aggregation level parameter. The aggregation level, denoted by L, indicates how many physical battery compartments are aggregated into a single logical candidate battery compartment block when generating candidate battery compartments. When a user's electric two-wheeler only supports a single battery, the aggregation level L is typically 1. When the user's electric two-wheeler supports multiple batteries connected in parallel (e.g., dual-battery models), or when the health of a single battery is low and requires combining multiple batteries to meet range requirements, the aggregation level L can be an integer greater than 1. A candidate battery compartment block is a logical dispatch unit consisting of L physically contiguous battery compartments belonging to the same battery swapping cabinet, as indicated by the aggregation level L. When a user selects this candidate battery compartment block, all L batteries within that block will be retrieved at once.

[0052] In one specific implementation, the battery swapping session identifier, aggregation level, number of centralized battery swapping resource compartments, and multiple candidate battery compartments satisfy the following relationship: index_i = Hash(SID||i) mod N'; Wherein, Hash() is the hash function used, with the same meaning as described in step S202; SID is the battery swapping session identifier; || represents a connection; i is an integer from 1 to M, representing the loop counter when generating the i-th candidate; N' is the modulus used in the hash operation, i.e., the resource pool size parameter.

[0053] Specifically, L represents the aggregation level, and L is an integer greater than or equal to 1. N represents the total number of battery compartments in the battery swapping resource set, and N is an integer multiple of L to ensure that the resource pool can be evenly divided into an integer number of candidate battery compartment blocks. When L equals 1, N' = N, that is, the modulus of the hash operation is the total number of battery compartments in the battery swapping resource set. In this case, index_i indicates the index of the i-th selected candidate battery compartment in the battery swapping resource set, and each candidate corresponds to an independent physical battery compartment. When L is greater than 1, N' = N / L, that is, the modulus of the hash operation is the number of logical battery compartment blocks in the battery swapping resource set. In this case, index_i indicates the index of the i-th selected candidate battery compartment block in the battery swapping resource set, and each candidate battery compartment block contains L physically contiguous battery compartments belonging to the same battery swapping cabinet. i is an integer from 1 to M, where M is an integer greater than 1 and less than N'. Here, M is less than N' to ensure that there are enough candidates for the hash operation to generate without duplication. The index of the candidate battery compartment is the position number of the battery compartment or battery compartment block pointed to by the above index_i in the resource set R.

[0054] In another specific implementation, the battery swapping session identifier, aggregation level, number of centralized battery swapping resource compartments, and multiple candidate battery compartments satisfy the following relationship: base_index_i=Hash(SID||i)modN; Where Hash() is the hash function used; SID is the battery swapping session identifier; || represents a connection; N is the total number of battery compartments in the battery swapping resource center; i is an integer from 1 to M, where M is the preset number of candidates and is greater than 1 and less than N; L is the aggregation level.

[0055] When the aggregation level L equals 1, the i-th candidate battery compartment is the battery compartment with index base_index_i in the battery swapping resource set. base_index_i is the base index of the physical battery compartment directly mapped by the hash operation.

[0056] When the aggregation level L is greater than 1, the i-th candidate battery block consists of L consecutive battery blocks with indices from block_start_i to block_start_i+L-1 in the battery swapping resource set. Here, block_start_i is the starting physical index of the candidate battery block, satisfying the following relationship: block_start_i = base_index_i - (base_index_i mod L), where mod represents the modulo operation, i.e., finding the remainder when base_index_i is divided by L. The mathematical meaning of this formula is: first, base_index_i is reduced downwards to the nearest integer multiple of L, thus determining the starting physical index of the candidate battery block. For example, when L=2, and base_index_i is calculated to be 15, since 15 mod 2 = 1, then block_start_i = 15 - 1 = 14, and this candidate battery block consists of two consecutive battery blocks with indices 14 and 15. This approach eliminates the need to re-divide the physical resource pool into logical blocks before hash mapping. Instead, after hash mapping to the physical warehouse index, the index is reduced to the starting position of its candidate battery warehouse block using modulo subtraction, thus achieving post-processing of logical grouping.

[0057] S203, the dispatch center instructs the electric two-wheeler on the physical locations of multiple candidate battery compartments.

[0058] After generating a list of candidate battery compartments, the dispatch center sends a battery swapping response to the electric two-wheeler or its user terminal. The battery swapping response is the reply message returned by the dispatch center to the electric two-wheeler after selecting the candidate battery compartments.

[0059] The battery swapping response includes identifiers for the multiple candidate battery compartments and information indicating their physical locations. The identifier for a candidate battery compartment is a unique code used to identify a compartment within the battery swapping network; for example, "Cabinet-A-015" indicates battery compartment number 15 in swapping cabinet A. The information regarding the physical location of the candidate battery compartment refers to data describing the geographical location and addressing information of the swapping cabinet where the candidate battery compartment is located, including but not limited to: the swapping cabinet name (e.g., "Swapping Cabinet No. 01 on XX Road"), the swapping cabinet address (e.g., "No. XX, XX Road, XX District, XX City"), and the geographical coordinates (latitude and longitude) of the swapping cabinet. The battery swapping response can also include a suggested attempt order. This suggested order refers to the order in which the dispatch center recommends access based on the generation order of candidate battery compartments (i.e., i from 1 to M) or the distance between each candidate battery compartment and the user's current location. For example, "Candidate 1: Cabinet A-15 (300 meters away), Candidate 2: Cabinet C-08 (450 meters away), Candidate 3: Cabinet B-12 (600 meters away)." After receiving this information, the user can intuitively see all the candidate options on the battery swapping application interface on their mobile terminal and flexibly choose which battery swapping cabinet to go to for battery swapping based on their current location and preferences, without having to strictly follow the suggested order.

[0060] Optionally, after step S203, the method may further include step S204.

[0061] S204, the dispatch center receives a battery swap success message from the electric two-wheeler, which instructs the user to select the target battery compartment from multiple candidate battery compartments.

[0062] The "successful battery swap" message refers to the confirmation message sent by the electric two-wheeler or its user terminal to the dispatch center after the user completes the battery swap, informing the dispatch center that the swap has been successfully completed. The "target battery compartment" refers to the battery compartment that the user ultimately selects from the candidate battery compartment list and actually retrieves the battery from.

[0063] When a user arrives at the battery swapping station, inspects the batteries in the candidate battery compartment for appearance and charge level, and confirms their selection, the electric two-wheeler or its mobile terminal reports a successful battery swap to the dispatch center. This successful swap message includes the identifier of the target battery compartment ultimately selected by the user. Based on this, the dispatch center marks the target battery compartment as occupied and releases other unselected candidate battery compartments from the current swap request, making them available for subsequent user swap requests. Simultaneously, this selection record can be persistently stored for subsequent user behavior analysis and battery swapping network operation optimization.

[0064] To better illustrate the advantages of using hash functions in the embodiments of this application, the following comparison of the scheme of this application with the traditional centralized matching scheme is conducted through a specific scenario.

[0065] Scenario: During the evening rush hour, a core business district in a city experiences 1000 concurrent battery swapping requests within 10 minutes. Ten battery swapping stations are deployed within a 5-kilometer radius of the business district, each containing 12 battery compartments, for a total of N=120 available battery compartments. Assume each battery swapping request generates M=3 candidate battery compartments.

[0066] The processing steps of traditional centralized matching schemes: For each battery swapping request, the dispatch center needs to perform the following operations: The system reads the real-time status (battery level, health status, temperature, distance from the user, etc.) of all 120 battery compartments from the database. For each battery compartment, a comprehensive scoring function is calculated based on multi-dimensional indicators, for example: Score = w1 × distance score + w2 × battery level score + w3 × health status score + w4 × temperature score, where w1, w2, w3, and w4 are the weight coefficients of each dimension, and each score is a normalized value. The 120 scores are sorted, and the battery compartment with the highest score is selected as the optimal solution, or the top few are recommended solutions. The results are then returned to the user.

[0067] Assuming each reading of a battery compartment status and scoring calculation takes approximately 0.5 milliseconds, the processing time for a single request is approximately 120 × 0.5 = 60 milliseconds. The total computation time for 1000 concurrent requests is approximately 60,000 milliseconds. If the scheduling center uses single-threaded serial processing, queuing latency will increase significantly, causing users to wait several seconds or even tens of seconds after initiating a request before receiving a response. Even with multi-threaded parallel processing, the consumption of server central processing unit (CPU) and memory resources is still considerable. Furthermore, because the optimal matching algorithm naturally tends to guide users to a few popular battery swapping stations that are close by and have good battery quality, the first 100 requests may all be assigned to a few popular stations, causing the batteries in these stations to be quickly reserved, while other stations remain unused. Subsequent users, even if matched with these popular stations, may face the problem of batteries already being occupied, requiring them to re-initiate requests, further increasing system load and creating a vicious cycle.

[0068] The processing procedure for this application: For each battery swap request, the dispatch center performs the following operations: generates a battery swap session identifier (SID) (one hash operation, approximately 0.01 milliseconds); performs M hash modulo operations (each approximately 0.01 milliseconds, totaling approximately 0.03 milliseconds with M=3); queries the basic availability status of the M battery compartments corresponding to the index (approximately 0.1 milliseconds in total); and returns the candidate list to the user.

[0069] The total processing time for a single request is approximately 0.14 milliseconds, only about 1 / 400th of that of traditional solutions. The total computation time for 1000 concurrent requests is approximately 140 milliseconds, which the scheduling center can easily handle, with users experiencing virtually no latency. This leap in computational efficiency is due to the constant time complexity of hash operations, O(1), which is independent of the size N of the battery swapping resource set, while the complexity of traditional matching solutions is at least O(N) or even O(N·logN).

[0070] Load balancing performance comparison: Mathematically, the output of a hash function follows a uniform distribution within the modulo N value space. This means that when 1000 users independently obtain 3 candidate battery compartments through the hash function, the expected number of times each battery compartment is selected into the candidate list is exactly the same, 1000×3 / 120=25 times. From a probabilistic perspective, among the 120 battery compartments, the proportion of those selected 20 to 30 times (i.e., within the expected value ±20%) will exceed 95%, and the extreme case of some battery compartments being selected in large numbers while others are completely ignored is extremely rare.

[0071] Specifically, Monte Carlo simulations demonstrate that in 1000 independent requests, using a traditional centralized matching scheme, if the distance weight is large, the two battery swapping stations (a total of 24 battery compartments) closest to the center of the business district may handle over 60% of the candidate hits, while the battery swapping stations at the edge have extremely low candidate hit rates, resulting in severely uneven resource utilization. However, using the proposed solution, the candidate hit distribution across all battery swapping stations is even, with each station handling approximately 1000 × 3 / 10 = 300 candidate hits, and the deviation between stations not exceeding 15%. This inherent load balancing characteristic allows users to be naturally guided to different battery swapping stations, effectively avoiding local overload and uneven global resource utilization, and eliminating the need to deploy additional load prediction and balancing scheduling modules.

[0072] Comparison of single battery swap success rates: In the traditional solution, if the only optimal battery compartment returned by the dispatch center cannot be used due to uncertainties in the physical world (such as damage to the battery appearance, abnormal charging interface, user dissatisfaction with the battery appearance, or other subjective or objective factors), the user needs to cancel the order and re-initiate the request. The entire process is interrupted and time is increased, which seriously affects the user experience.

[0073] In this application, the user has M candidate battery compartments as options. Assuming the probability of a single battery compartment being rejected by the user is p = 10% (this probability covers user dissatisfaction due to various reasons such as cosmetic damage, perceived insufficient battery power, or loose interfaces), the probability that the user still cannot find a satisfactory battery after checking k candidate battery compartments consecutively is p^k. When M = 3, the probability of all three candidates being rejected is only 0.1³ = 0.1%, or one in a thousand. This means that 99.9% of users can find a satisfactory battery and complete the battery swap on the first attempt in the candidate list, without needing to re-initiate a request, greatly improving the success rate of a single battery swap. This mechanism, which provides redundancy through multiple candidates, is not available in traditional single-optimal-solution scheduling modes.

[0074] Privacy Protection Comparison: In traditional solutions, the user's precise location coordinates are used to calculate the distance to each battery swapping station for optimal matching, requiring the dispatch center to know the user's exact physical location. However, in this application's solution, the introduced LocationFuzzyCode converts precise coordinates into low-precision regional codes before participating in the generation of the battery swapping session identifier. The dispatch center only needs to know the approximate area where the user is located to delineate the battery swapping resource set, eliminating the need to continuously track the user's precise movement trajectory. This effectively protects the user's location privacy while meeting dispatching requirements.

[0075] In summary, upon receiving a battery swap request, the dispatch center first determines a battery swap resource set containing all available battery compartments within the physical location area. Then, based on a hash function, it pseudo-randomly selects multiple candidate battery compartments from this resource set for the electric two-wheeler, rather than calculating a unique optimal solution through global state comparison. The hash function has low computational complexity, eliminating the need for one-by-one comparison of real-time battery states. This simplifies the scheduling decision from complex matching operations to efficient mapping operations, significantly reducing server computational load and easily supporting massive concurrent requests during peak periods. Simultaneously, the uniform distribution characteristic of the hash function allows different users to be pseudo-randomly guided to different battery compartments within the resource set, naturally achieving load balancing and effectively avoiding the problems of overloading popular compartments and leaving less popular ones idle. Furthermore, the redundant design of multiple candidate battery compartments provides users with on-site options. If the preferred battery compartment becomes unavailable due to physical uncertainties (such as physical damage or charging abnormalities), users can still switch to alternative battery compartments, avoiding process interruptions caused by re-initiating requests due to failure to specify a single target. This improves the success rate of a single battery swap and enhances the user experience.

[0076] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Exemplarily, the electronic device may be a terminal, or a chip (system) or other component or assembly that can be disposed in the terminal. Figure 4As shown, the electronic device 400 may include a processor 401. Optionally, the electronic device 400 may also include a memory 402 and / or a transceiver 403. The processor 401 is coupled to the memory 402 and the transceiver 403, for example, via a communication bus.

[0077] The following is combined Figure 4 A detailed description of each component of the electronic device 400 is provided below: The processor 401 is the control center of the electronic device 400. It can be a single processor or a collective term for multiple processing elements. For example, the processor 401 can be one or more central processing units (CPUs), application-specific integrated circuits (ASICs), or one or more integrated circuits configured to implement embodiments of the present invention, such as one or more digital signal processors (DSPs), or one or more field-programmable gate arrays (FPGAs).

[0078] Optionally, the processor 401 can perform various functions of the electronic device 400 by running or executing software programs stored in the memory 402 and calling data stored in the memory 402, such as performing the aforementioned functions. Figure 2 The method shown is a multi-source data fusion intelligent data processing method for enterprise headquarters management.

[0079] In a specific implementation, as one example, processor 401 may include one or more CPUs, for example... Figure 4 CPU0 and CPU1 are shown in the diagram.

[0080] In a specific implementation, as one example, the electronic device 400 may also include multiple processors. Each of these processors may be a single-core processor (single-CPU) or a multi-core processor (multi-CPU). Here, a processor may refer to one or more devices, circuits, and / or processing cores used to process data (e.g., computer program instructions).

[0081] The memory 402 is used to store the software program that executes the solution of the present invention, and is controlled by the processor 401 to execute it. The specific implementation method can be referred to the above method embodiment, and will not be repeated here.

[0082] Optionally, the memory 402 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or electrically erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto. The memory 402 may be integrated with the processor 401 or exist independently, and may be accessed through the interface circuit of the electronic device 400. Figure 4 (Not shown in the image) is coupled to processor 401, but this embodiment of the invention does not specifically limit this.

[0083] Transceiver 403 is used for communication with other electronic devices. For example, if electronic device 400 is a terminal, transceiver 403 can be used to communicate with a network device or with another terminal device. As another example, if electronic device 400 is a network device, transceiver 403 can be used to communicate with a terminal or with another network device.

[0084] Alternatively, transceiver 403 may include a receiver and a transmitter. Figure 4 (Not shown separately). The receiver is used to implement the receiving function, and the transmitter is used to implement the transmitting function.

[0085] Alternatively, the transceiver 403 can be integrated with the processor 401, or it can exist independently and be connected via the interface circuit of the electronic device 400. Figure 4 (Not shown in the image) is coupled to processor 401, and this embodiment of the invention does not specifically limit this.

[0086] Understandable, Figure 4 The structure of the electronic device 400 shown does not constitute a limitation on the electronic device. Actual electronic devices may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0087] Furthermore, the technical effects of the electronic device 400 can be referred to the technical effects of the methods described in the above method embodiments, and will not be repeated here.

[0088] It should be understood that the processor in the embodiments of the present invention can be a central processing unit (CPU), or it can be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0089] It should also be understood that the memory in the embodiments of the present invention can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of random access memory (RAM) are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate synchronous DRAM (DDR SDRAM), enhanced synchronous DRAM (ESDRAM), synchronous linked DRAM (SLDRAM), and direct rambus RAM (DR RAM).

[0090] The above embodiments can be implemented, in whole or in part, by software, hardware (such as circuits), firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of the present invention are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. A semiconductor medium can be a solid-state drive.

[0091] It should be understood that the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. A and B can be singular or plural. Additionally, the character " / " in this article generally indicates an "or" relationship between the preceding and following related objects, but it can also represent an "and / or" relationship. Please refer to the context for a more accurate understanding.

[0092] In this invention, "at least one" means one or more, and "more than one" means two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of a single item or a plurality of items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be a single item or multiple items.

[0093] It should be understood that, in various embodiments of the present invention, the order of the above-mentioned process numbers does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0094] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0095] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0096] In the embodiments provided by this invention, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0097] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0098] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0099] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0100] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for intelligent scheduling of battery swapping for electric two-wheeled vehicles, characterized in that, The method is applied to a scheduling center, and the method includes: The dispatch center receives battery swapping requests sent by electric two-wheeled vehicles at their corresponding physical locations; In response to the battery swapping request, the scheduling center determines a battery swapping resource set and, based on a hash function, pseudo-randomly selects multiple candidate battery compartments from the battery swapping resource set for the electric two-wheeled vehicle. The battery swapping resource set includes available battery compartments within the physical area where the physical location is located. The dispatch center indicates the physical location of the multiple candidate battery compartments to the electric two-wheeler.

2. The method according to claim 1, characterized in that, The step of pseudo-randomly selecting multiple candidate battery compartments for the electric two-wheeler from the battery swapping resource set based on a hash function includes: The dispatch center generates a temporary, one-time-use battery swap session identifier for the battery swap request; The scheduling center determines, based on a hash function, the battery swapping session identifier, and the number of battery compartments in the battery swapping resource center, to pseudo-randomly select one of the multiple candidate battery compartments for the electric two-wheeled vehicle.

3. The method according to claim 2, characterized in that, The battery swapping session identifier satisfies the following relationship: SID=H(UserID||Timestamp||RequestedPower||LocationFuzzyCode||RandomSalt); where, SID is the battery swapping session identifier, H() is the anti-collision hash function, || is concatenation, UserID is the user identifier corresponding to the electric two-wheeler, Timestamp is the time when the electric two-wheeler sent the battery swapping request, RequestedPower is the battery swapping power demand level indicated by the battery swapping request or the estimated required range, LocationFuzzyCode is the location fuzzy code corresponding to the physical location, and RandomSalt is a temporary and one-time random parameter generated by the scheduling center for the battery swapping request.

4. The method according to claim 2, characterized in that, The battery swapping session identifier satisfies the following relationship: SID=H(UserID||Timestamp||PreviousSID||RandomSalt); where, SID is the battery swapping session identifier, H() is the anti-collision hash function, || is concatenation, UserID is the user identifier corresponding to the electric two-wheeler, Timestamp is the time when the electric two-wheeler sent the battery swapping request, PreviousSID is the battery swapping session identifier used by the user corresponding to the electric two-wheeler in a previous successful battery swap. When the user is swapping batteries for the first time, PreviousSID is a preset initial value, and RandomSalt is a temporary and one-time random parameter generated by the scheduling center for the battery swapping request.

5. The method according to any one of claims 2-4, characterized in that, The scheduling center determines, based on a hash function, the battery swapping session identifier, and the number of battery compartments in the battery swapping resource center, to pseudo-randomly select from a plurality of candidate battery compartments for the electric two-wheeled vehicle, including: The scheduling center determines the selection of multiple candidate battery compartments for the electric two-wheeled vehicle in a pseudo-random manner based on the hash function, aggregation level, battery swapping session identifier, and the number of battery compartments in the battery swapping resource center. The aggregation level is used to indicate whether at least two candidate battery compartments are aggregated into one candidate battery compartment block.

6. The method according to claim 5, characterized in that, The battery swapping session identifier, the aggregation level, the number of centralized battery swapping resource compartments, and the multiple candidate battery compartments satisfy the following relationship: index_i=Hash(SID||i)modN'; where, Hash() is the hash function, SID is the battery swapping session identifier, || represents a connection, L is the aggregation level, L is an integer greater than or equal to 1, and N is an integer multiple of L; when L equals 1, N'=N, N is the number of battery compartments in the battery swapping resource set, and index_i indicates the i-th candidate battery compartment selected in the battery swapping resource set, i is an integer from 1 to M, and M is an integer greater than 1 and less than N'; when L is greater than 1, N'=N / L, and index_i indicates the i-th candidate battery compartment block selected in the battery swapping resource set.

7. The method according to claim 5, characterized in that, The battery swapping session identifier, the aggregation level, the number of centralized battery swapping resource compartments, and the multiple candidate battery compartments satisfy the following relationship: base_index_i=Hash(SID||i)modN; Where Hash() is the hash function, SID is the battery swapping session identifier, || represents a connection, N is the number of battery compartments in the battery swapping resource set, i is an integer from 1 to M, M is a preset number of candidates that is greater than 1 and less than N; L is the aggregation level. When L equals 1, the i-th candidate battery compartment is the battery compartment with index base_index_i in the battery swapping resource set; when L is greater than 1, the i-th candidate battery compartment block consists of L consecutive battery compartments with indices from block_start_i to block_start_i+L-1 in the battery swapping resource set. Among them, block_start_i=base_index_i-(base_index_imodL).

8. The method according to claim 1, characterized in that, The dispatch center determines the battery swapping resource set, including: The dispatch center determines the area at a preset distance from the physical location as the physical area; The dispatch center determines that all available battery compartments located within the physical area constitute the battery swapping resource set.

9. The method according to claim 1, characterized in that, The dispatch center instructs the electric two-wheeler on the physical locations of the multiple candidate battery compartments, including: The dispatch center sends a battery swapping response to the electric two-wheeler. The battery swapping response includes the identifiers of the multiple candidate battery compartments and information indicating the physical location of the multiple candidate battery compartments.

10. The method according to claim 9, characterized in that, After the dispatch center sends a battery swapping response to the electric two-wheeler, the method further includes: The dispatch center receives a battery swap success message from the electric two-wheeler, which instructs the user to select a target battery compartment from the plurality of candidate battery compartments.