Intelligent operation and maintenance management method for battery changing cabinet based on Internet of Things

Abstract

The invention discloses an intelligent operation and maintenance management method for a power conversion cabinet based on the Internet of Things, and relates to the technical field of the Internet of Things and a distributed system.The method comprises the steps that in the peak period such as the morning peak of a commercial district, multiple riders initiate power conversion requests at the same time, a system receives the requests through an Internet of Things gateway and generates a global unique identifier; each request is traceable and is prevented from being repeated; the requests are submitted to a consensus group formed by an edge node and a battery changing cabinet controller, and global monotonic serial numbers are distributed based on a sequence consistency protocol, so that ordered processing of the requests is realized, and distribution conflicts under network delay are avoided; the atomic occupancy mechanism is combined with token lease, battery resources are exclusively locked on the target battery replacement cabinet, and operation is completed only when a physical confirmation event such as a cabinet door state signal or battery handshake is matched with a token number, so that false occupancy and a deadlock state are prevented.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of Internet of Things and distributed systems, and in particular to an intelligent operation and maintenance management method for a battery swap cabinet based on Internet of Things. BACKGROUND

[0002] With the application of electric vehicle battery swap services in high-density urban scenarios, battery swap cabinets are mostly interconnected with user terminals and cloud platforms through Internet of Things to realize battery state monitoring and remote operation and maintenance. After a user initiates a battery swap request on a mobile terminal, the system allocates and issues an instruction based on inventory and state information. Existing systems mostly use first-come, first-served, distributed locks, and timeout release to handle concurrent access.

[0003] However, under high concurrency conditions such as rush hours, concurrent conflicts and state inconsistencies are likely to occur due to network delays, message disordering, and retry mechanisms. For example, the same battery is repeatedly allocated, the lock is occupied but not timely aligned with the physical operation of the cabinet, resulting in a successful display on the user terminal but the cabinet failing to complete the pick-up and placement, thereby affecting service continuity and user experience. Even if general means such as request ordering, idempotent control, and timeout rollback are used, response delays, uneven resource allocation, and untimely recovery may still occur in multi-point access scenarios across cabinets or regions, making it difficult to balance consistency, timeliness, and fairness. SUMMARY

[0004] In view of the above existing problems, the present application is proposed.

[0005] The present application provides an intelligent operation and maintenance management method for a battery swap cabinet based on Internet of Things to solve the problem of resource competition and deadlock in existing battery swap cabinet systems under multi-user concurrent battery swap, leading to battery allocation conflicts, service interruptions, and low operation and maintenance efficiency.

[0006] To solve the above technical problems, the present application provides the following technical solutions:

[0007] The present application provides an intelligent operation and maintenance management method for a battery swap cabinet based on Internet of Things, which includes:

[0008] Step S1: The gateway receives a battery swap request from a user terminal and generates a globally unique identifier for each request.

[0009] Step S2: The request is submitted to a consensus group composed of edge nodes and / or battery swap cabinet controllers, and a globally monotonic sequence number is assigned to the request based on a sequential consistency protocol.

[0010] Step S3: According to the sequence number, an atomic occupation of the target battery on the target battery swap cabinet is performed, and an open cabinet / pick-up and placement instruction is allocated and issued, and a lease with a token number is issued.

[0011] Step S4, listen to the physical confirmation event from the cabinet and match with the token number;

[0012] Step S5, release the occupation and roll back the resource to available when no valid confirmation is obtained within the lease period or preset timeout;

[0013] Step S6, retry or reassign the unfinished request according to the scheduling strategy.

[0014] As a preferred scheme of the intelligent operation and maintenance management method of the battery swap cabinet based on the Internet of Things, the idempotent and deduplication processing is performed on the request access side, including: replay / concurrent submission is detected based on the globally unique identifier and the recent submission cache, and repeated requests only return existing allocation results.

[0015] As a preferred scheme of the intelligent operation and maintenance management method of the battery swap cabinet based on the Internet of Things, the consensus group is a consensus log generated by the leader type consensus protocol, and the log entry contains the request identifier, the serial number, the target cabinet / battery identifier and the token number, and only after the majority of nodes are submitted, it can be effective externally.

[0016] As a preferred scheme of the intelligent operation and maintenance management method of the battery swap cabinet based on the Internet of Things, the atomic occupation adopts a lease and token anti-concurrent mechanism: the current token number is written in the resource metadata, and the cabinet side only accepts the execution / confirmation message carrying the matching token number.

[0017] As a preferred scheme of the intelligent operation and maintenance management method of the battery swap cabinet based on the Internet of Things, the physical confirmation event includes at least one of the following or a combination thereof:

[0018] Cabinet door state closed signal, tray weight change signal, battery BMS handshake completion signal, lock tongue in place signal.

[0019] As a preferred scheme of the intelligent operation and maintenance management method of the battery swap cabinet based on the Internet of Things, the timeout threshold is adaptively set: according to the network round-trip delay measurement value and the cabinet queue length in the recent period, the threshold is dynamically adjusted, and the maximum / minimum boundary is limited; when link degradation is detected, the threshold is increased, and when the queue is congested, the threshold is decreased;

[0020] The dynamic calculation method of the timeout threshold is:

[0021] 1) Set the observation window and the update period to collect round-trip delay samples, cabinet queue length and failure rate to form a stable statistical basis;

[0022] 2) Calculate the quantile delay, queue proportion and period failure rate in each update period as adaptive input;

[0023] 3) In the first update period, For each update cycle, the timeout threshold is calculated using the following formula, and interval pruning is performed:

[0024] ,

[0025] in, Indicates the first The timeout threshold for the period, in milliseconds. The index representing the discrete update cycle is a non-negative integer. This represents the threshold value for the previous period, in milliseconds (ms). This represents the exponential smoothing coefficient, which is a dimensionless constant. Indicates the first Periodic RTT Quantiles, in milliseconds (ms). Indicates quantile level. This represents the link degradation amplification factor, which is a dimensionless constant. Indicates the first Cyclic link degradation indicators This represents the failure rate amplification factor, which is a dimensionless constant. Indicates the first Periodic request failure rate This represents the congestion reduction coefficient, which is a dimensionless constant. Indicates the first Queue length on the side of the periodic cabinet, in units of pieces. This represents the upper bound of the queue capacity, in units of pieces. and These represent the lower and upper bounds of the threshold, respectively, in milliseconds (ms). Indicates will Cut off to closed interval Operators;

[0026] Calculate the relative increase:

[0027] ,

[0028] in, This represents the positive increase in relative quantile delay. This represents the same quantile value of the previous period's RTT, in milliseconds (ms).

[0029] 4) The update cycle and observation window meet the requirements. ;

[0030] 5) When or When the threshold increases, it is adjusted upwards to accommodate link degradation and failure risks. When the threshold is increased, it is lowered;

[0031] 6) When a sample is missing, the threshold of the previous cycle is retained and does not fall below the lower bound. Multiple consecutive timeouts trigger a one-time backoff, raising the threshold of the next cycle but not exceeding the upper bound. After returning to normal, return to step 3). Gradual changes and limits on the scope of changes are adopted.

[0032] As a preferred embodiment of the IoT-based intelligent operation and maintenance management method for battery swapping cabinets described in this invention, the method of triggering reallocation after releasing the occupied cabinet includes: selecting the next target cabinet within the candidate cabinet set based on distance / inventory / load, and setting a backoff time window for the same request.

[0033] As a preferred embodiment of the IoT-based intelligent operation and maintenance management method for battery swapping cabinets described in this invention, the scheduling strategy adopts priority weights, the weights being calculated based on at least one or more of the following: user historical request frequency, current waiting time, and service level, and used to determine the order when priority conflicts occur when the sequence number is the same.

[0034] The calculation rules for the priority weights are defined as follows:

[0035] During the update cycle The system collects the frequency of near-window requests from the user to which the request belongs, the current waiting time of the request, and the service level, forming the input for subsequent normalization.

[0036] Recursive and saturation normalization are constructed for historical request frequencies:

[0037] ,

[0038] in, Indicates the discrete update cycle number. Indicates the first The weighted request frequency per period, in times per second. This indicates the weighted request frequency of the previous period, in times per second. Indicates the recursive weight. Indicates the first The number of requests made by this user within the period, in units of times. Indicates the update cycle, in seconds. Represents the frequency factor. This represents the saturation scaling coefficient, which is a dimensionless constant.

[0039] Proportionally crop the current waiting time:

[0040] ,

[0041] in, Indicates the waiting factor. This indicates the duration the request has been waiting, in seconds. Indicates the reference duration. Indicates will Truncation to closed interval Operators;

[0042] Map service levels to range quantities As a service factor;

[0043] In the In each update cycle, the priority score for concurrent decision-making is calculated using the following formula, and boundary pruning and shuffling are performed:

[0044] ,

[0045] in, Indicates the first The priority score of the cycle, , , Let represent the linear weights of the three types of factors, which are all dimensionless constants. This represents the power of the frequency factor, used to compress or amplify the impact on high-frequency users; it is a dimensionless constant. Represents the frequency factor. Indicates the waiting factor. Indicates service factor, This represents the dispersion amplitude, which is a dimensionless constant. Indicates a globally unique request identifier The calculated deterministic pseudo-random number, This indicates the globally unique identifier generated by the request.

[0046] As a preferred embodiment of the IoT-based intelligent operation and maintenance management method for battery swapping cabinets described in this invention, the following features are provided: edge-cloud collaborative fault tolerance: when most nodes in the consensus group are unavailable, the system switches to a local degradation queue to maintain basic battery swapping capability. After the connection is restored, the local commit records are reconciled with the consensus logs and conflicts are resolved.

[0047] As a preferred embodiment of the IoT-based intelligent operation and maintenance management method for battery swapping cabinets described in this invention, the request and confirmation messages are verified against replay using timestamps and signatures, the signature key is securely stored by the gateway and the cabinet controller, and expired messages are discarded without affecting the resource status.

[0048] The beneficial effects of this invention are as follows: The concurrent scheduling method for battery swapping cabinets based on the Internet of Things effectively solves the resource contention and deadlock problems when multiple users are concurrent through distributed consensus and serialization processing.

[0049] During peak hours, such as the morning rush hour in commercial areas, multiple riders simultaneously initiate battery swapping requests. The system utilizes an IoT gateway to receive these requests and generate globally unique identifiers, ensuring each request is traceable and preventing duplicate requests. By submitting requests to a consensus group composed of edge nodes and the battery swapping cabinet controller, and allocating globally monotonic sequence numbers based on a sequential consistency protocol, ordered processing of requests is achieved, avoiding allocation conflicts under network latency. An atomic occupancy mechanism combined with token leases exclusively locks battery resources on the target battery swapping cabinet. Operation is only completed when a physical confirmation event (such as a cabinet door status signal or battery handshake completion) matches the token number, thus preventing false occupancy and deadlock. A dynamic timeout adjustment mechanism adaptively sets thresholds based on network latency and queue length. Timeouts are extended to reduce false positives when the link deteriorates, and shortened to accelerate resource release when the queue is congested, improving resource utilization and response speed. Furthermore, a priority scheduling strategy calculates weights based on users' historical frequency, waiting time, and service level, achieving fair sorting in case of sequence number conflicts, reducing user waiting time and complaints. This invention also features edge-cloud collaborative fault tolerance capabilities, switching to a local degradation queue when the consensus group becomes unavailable to maintain basic service continuity, and ensuring message security through anti-replay verification.

[0050] This invention enhances the concurrent processing capability of the battery swapping cabinet system, reduces the risk of operation and maintenance interruption, improves user experience and system reliability, and is suitable for high-load, on-demand delivery scenarios. Attached Figure Description

[0051] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly described below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation on the scope of this application.

[0052] Figure 1 This is a flowchart illustrating the IoT-based intelligent operation and maintenance management method for battery swapping cabinets in this embodiment. Detailed Implementation

[0053] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0054] All terms used in this application (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein should be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0055] For example, the terms “first” and “second” used in this application are only used to distinguish and describe similar objects, to differentiate the first object from another object, and are not used to describe a specific order or sequence, nor should they be interpreted as indicating or implying relative importance.

[0056] This application proposes an intelligent operation and maintenance management method for battery swapping cabinets based on the Internet of Things, combining... Figure 1 As shown, the method, applied to a system including user terminals, IoT gateways, battery swapping cabinet controllers, and edge / cloud nodes, includes:

[0057] Step S1: The gateway receives the battery swapping request from the user terminal and generates a globally unique identifier for each request.

[0058] Step S2: Submit the request to the consensus group consisting of edge nodes and / or battery swapping cabinet controllers, and assign a global monotonic sequence number to the request based on the sequential consistency protocol;

[0059] Step S3: Perform atomic occupancy on the target battery in the target battery swapping cabinet according to the serial number, allocate and issue cabinet opening / removal instructions, and issue a lease with a token number at the same time.

[0060] Step S4: Listen for physical confirmation events from the cabinet and match them with the token number;

[0061] Step S5: If no valid confirmation is received within the lease period or the preset timeout, release the occupied resource and roll it back to availability;

[0062] Step S6: Retry or reallocate incomplete requests according to the scheduling policy;

[0063] In this embodiment, the globally unique identifier can be understood as an identifier string composed of a time entropy source and a high-quality random source, along with information about the source node. It is obtained by generating the identifier on the gateway side and performing a window-to-window verification before submission. The consensus group is a set of edge nodes and / or battery swapping cabinet controllers that participate in voting and submission. The sequential consistency protocol generates strictly monotonic global sequence numbers, which are implemented in engineering by a single-leader serial proposal. Atomic occupancy is a single, unallocable occupancy write to the target battery. The token number is a monotonic sequence generated synchronously with the occupancy. The physical confirmation event is a completion signal from the cabinet's sensing and execution components. The scheduling strategy is a rule for sorting conflicts and retries given that the sequence number is already determined. Specifically, the default lease validity period is 5 seconds, which can be configured from 2 to 30 seconds depending on the site link conditions; the preset timeout lower bound is recommended to be no less than 60% of the steady-state round-trip latency, and the upper bound should not exceed twice the historical peak value; the default retry backoff range is 100 milliseconds to 800 milliseconds, which increases exponentially with the number of failures and is capped at the upper limit; the default retry limit for a single request is 3 times, which can be adjusted from 1 to 5 times according to the failure rate, and automatically degrades based on the near-window success rate. For example, before most nodes complete their submissions, they do not announce successful allocation to the outside world, but only return the intermediate state in the queue, thereby avoiding phantom locking. Optionally, within a single cabinet's exclusive partition, if the consensus group size is one, it can degenerate into local sequentialization by the leader but still retain token and lease verification to ensure consistency with the input and output of the full solution. Furthermore, when insufficient resources, network, or computing power is detected, the minimum executable approach is maintained: only new request registrations are accepted, no occupation instructions are issued, occupied resources are retained until the lease expires or manual intervention occurs, and processing resumes in the original order after the default threshold is restored.

[0064] In one embodiment, the request access side performs idempotency and deduplication processing, including: detecting replay / concurrent submissions based on a globally unique identifier and the most recently submitted cache; duplicate requests only return existing allocation results. In this embodiment, the most recently submitted cache is a set of near-window request digests stored on the gateway side, which means, in engineering terms, a memory that identifies replay or concurrent submissions within a limited time. The cache is obtained by combining the request identifier, source, and timestamp into a digest and storing it in a circular storage. Specifically, the default cache retention time is 60 seconds, which can be adjusted from 10 seconds to 300 seconds according to link and business peaks. The cache capacity is at least twenty times the peak request volume per second to cover retries and jitter. The adjacent judgment window is at least twice the steady-state round-trip latency. For example, if the same identifier is hit and an already allocated result exists within the window, the previous allocation information is returned directly; if only a record exists in the queue, the queue number is reused without re-queuing. Optionally, the digest calculation can use a stable hash or a message authentication hash, both of which are equivalent in input and output to ensure that the collision rate is controlled. When the cache is corrupted or its capacity is exhausted, switch to a dual-key determination based on timestamp and source and shorten the window to half of the default size to reduce the risk of false positives and missed judgments.

[0065] In one embodiment, the consensus group generates a consensus log for the leader-type consensus protocol. The log entries include a request identifier, sequence number, target cabinet / battery identifier, and token number, and are only effective after a majority of nodes have committed.

[0066] In this embodiment, a majority of nodes refers to more than half of the consensus group size, obtained by calculating the threshold from the member view at runtime. The consensus log is a persistent sequential record containing the necessary metadata and proposal sequence number of the request, and is stored on local reliable storage with verification. Specifically, the default leader heartbeat period is 150 milliseconds, adjustable from 50 to 500 milliseconds; the default proposal submission timeout is five to ten times the heartbeat period; the minimum duration for member health assessment is recommended to be no less than three heartbeat cycles. For example, the leader replicates to followers in parallel before committing, commits immediately upon reaching the threshold and broadcasts the commit index, otherwise remains suspended. Optionally, the leader rotation strategy can adopt a fixed priority or a dynamic priority based on health scores, neither of which changes the semantics of log linearization. When a majority of commits cannot be satisfied, external activation is suspended, and only local temporary records are saved; after the connection is restored, reconciliation is performed according to the log index, and uncommitted temporary allocations are discarded.

[0067] In one embodiment, atomic occupancy employs a lease and token anti-concurrency mechanism: the current token number is written into the resource metadata, and the cabinet only accepts execution / confirmation messages carrying matching token numbers. In this embodiment, resource metadata refers to the occupancy status and token field bound to the battery slot; the token number is a monotonically increasing one-time sequence value, obtained by generating it from the current submission sequence number or its security mapping and writing it along with the occupancy. Specifically, the write operation uses in-situ overwrite with post-write read verification, and the default verification timeout does not exceed 200 milliseconds; the minimum duration of token validity is not less than the lease validity period; concurrently arriving execution messages only retain those with matching tokens, while the rest are directly discarded and conflict counts are recorded. For example, if the cabinet receives a confirmation message for an older token, it is considered expired and status advancement is rejected. Optionally, resource metadata persistence can adopt a log-first or shadow structure, both of which maintain consistency in interface and semantics. When read / write operations in the metadata area fail, read-only degradation is entered, new occupancy writes are rejected, and recovery is achieved after health monitoring passes, during which time the already occupied resources remain unchanged.

[0068] In one embodiment, the physical confirmation event includes at least one or a combination of the following:

[0069] The system includes a cabinet door closure signal, a tray weight change signal, a battery BMS handshake completion signal, and a latch position signal. In this embodiment, the engineering meaning of a physical confirmation event is a set of state changes from the cabinet door, tray, latch, and battery management unit. This is obtained by the cabinet controller polling at a fixed period or reporting via interruption. Specifically, the minimum duration for signal dejittering is 50 milliseconds by default, adjustable between 10 and 200 milliseconds; the weight change threshold is at least 5% of the battery's net weight, combined with zero-point drift compensation; the shortest session time for handshake completion is at least twice the steady-state round-trip time; multiple signals are merged using an admission rule where any necessary signal is true and there are no mutually exclusive alarms. For example, if the cabinet door is closed and the latch is in place but the weight change does not meet the threshold, it can remain pending confirmation and be sampled again. Optionally, if a single sensor is missing, success can be determined by the combined confidence of the remaining signals reaching the site's set threshold, and the output remains consistent. A soft alarm is set when a sensor malfunctions or has abnormal readings, entering the manual inspection queue, and the lease validity period is extended to the default upper limit to avoid accidental rollback.

[0070] In one embodiment, the timeout threshold is adaptively set: dynamically adjusted based on recent network round-trip delay measurements and cabinet queue length, with maximum / minimum boundaries defined; the threshold is increased when link degradation is detected, and decreased when queue congestion occurs to accelerate release;

[0071] The dynamic calculation method for the timeout threshold is as follows:

[0072] 1) Set up observation windows and update cycles to collect round-trip delay samples, cabinet queue lengths and failure rates to form a stable statistical basis;

[0073] 2) Calculate quantile delay, queue percentage, and cycle failure rate within each update cycle as adaptive input;

[0074] 3) in the For each update cycle, the timeout threshold is calculated using the following formula, and interval pruning is performed:

[0075] ,

[0076] in, Indicates the first The timeout threshold for the period, in milliseconds. The index representing the discrete update cycle is a non-negative integer. This represents the threshold value for the previous period, in milliseconds (ms). This represents the exponential smoothing coefficient, which is a dimensionless constant. Indicates the first Periodic RTT Quantiles, in milliseconds (ms). Indicates quantile level. This represents the link degradation amplification factor, which is a dimensionless constant. Indicates the first Cyclic link degradation indicators This represents the failure rate amplification factor, which is a dimensionless constant. Indicates the first Periodic request failure rate This represents the congestion reduction coefficient, which is a dimensionless constant. Indicates the first Queue length on the side of the periodic cabinet, in units of pieces. This represents the upper bound of the queue capacity, in units of pieces. and These represent the lower and upper bounds of the threshold, respectively, in milliseconds (ms). Indicates will Cut off to closed interval Operators;

[0077] To quantify link degradation, the relative increase is calculated:

[0078] ,

[0079] in, This represents the positive increase in relative quantile delay. This represents the same quantile value of the previous period's RTT, in milliseconds (ms).

[0080] In the formula, , , , , , Steady-state RTT quantiles can be taken times, Historical peak values ​​can be obtained. times;

[0081] 4) Assume that the update cycle and observation window satisfy... Common configuration is When business fluctuations intensify, select a smaller [size / size]. ;

[0082] 5) When or When the threshold increases, it is adjusted upwards to accommodate link degradation and failure risks. When the threshold increases, it is lowered to facilitate the release of occupied space;

[0083] 6) When a sample is missing, the threshold of the previous cycle is retained and does not fall below the lower bound. Multiple consecutive timeouts trigger a one-time backoff, raising the threshold of the next cycle but not exceeding the upper bound. After returning to normal, return to step 3). By employing gradual changes and limiting the magnitude of changes, the threshold fluctuations between adjacent cycles are reduced;

[0084] Specifically, quantile RTT is used as a robust representative, and exponential smoothing is used to construct a historical memory, avoiding overreaction of the threshold to short-term spikes. The threshold is composed of three types of adaptive terms with clear directions: link degradation gain and failure rate gain jointly raise the threshold to reduce unnecessary retries caused by misjudgments; queue congestion term reduces the threshold proportionally to promote rapid release of occupancy and achieve a balance between throughput and latency; upper and lower bound pruning forms hard boundaries to limit the spillover of abnormal scenarios; quantile level, smoothing coefficient, and congestion coefficient provide portable parameter tuning hooks, which can be reused under different sites and different link conditions; the relationship between the update cycle and the observation window is statistically stable. A trade-off is made between qualitative analysis and response speed; faster convergence is achieved by shortening the update cycle when business disturbances increase. Rollback and missing sampling strategies cover actual operating scenarios where data is unavailable and continuously abnormal, and combined with limit sway and gradual updates, threshold oscillations caused by configuration changes are reduced. It facilitates integration at gateways or edge nodes and works in conjunction with consensus scheduling and atomic occupancy mechanisms. In this embodiment, round-trip latency samples are the communication time periodically measured between the gateway and the cabinet, obtained by probing during idle or low-frequency instrumentation and estimating based on business message timestamps. The queue length is the number of instructions to be executed on the cabinet side. The failure rate is the percentage of failures within the observation window. Specifically, the observation window defaults to covering no less than five update cycles and no more than ten update cycles; the update cycle defaults to one second and can be adjusted according to business fluctuations within the range of 200 milliseconds to five seconds; the default ratio of upper and lower bound pruning references steady-state latency and historical peak values; the coefficients for exponential smoothing and congestion reduction are obtained based on site trial operation and a single adjustment limit is set. For example, when link jitter worsens and failure rates increase, the threshold is raised in the next cycle to reduce false positives and retries; when the queue proportion increases, the threshold is lowered accordingly to promote occupancy release. Optionally, latency samples can be obtained through active probing or passive observation, and the quantile values ​​generated by either method can be selected as representative values. When observations are missing, the threshold from the previous cycle is retained and not lower than the lower bound; when consecutive timeouts reach the site threshold, a one-time backoff is triggered, and after recovery, the system returns to regular updates.

[0085] In one embodiment, triggering reallocation after releasing the occupancy includes: selecting the next target cabinet within the candidate cabinet set based on distance / inventory / load, and setting a backoff time window for the same request to avoid jitter. In this embodiment, the candidate cabinet set is a subset of cabinets that meet the constraints of inventory, online status, and geographic location, obtained by filtering based on real-time status and policies at the edge or cloud side; distance is the estimated travel distance from the user terminal to the cabinet; load is a combined metric of the cabinet's current execution queue and available power. Specifically, the default range of the backoff time window is between 100 milliseconds and 1 second, doubling with the number of failures and capped at the site limit; the default refresh cycle of the candidate set is two seconds, which can be adjusted within 500 milliseconds to 10 seconds; when reselecting a target cabinet, a short-term prohibition time is set for the previous target to avoid oscillation. For example, if the last two retries both failed due to cabinet congestion, a neighboring cabinet with a lower load can be prioritized. Optionally, distance estimation can be performed via mobile network location or terminal positioning, and the weights of the outputs of the two methods in the sorting can be configured. When the candidate set is empty, keep the request in the queue and extend the backoff time to the upper limit, while reporting to operations and maintenance to replenish inventory or restore offline cabinets.

[0086] In one embodiment, the scheduling strategy employs priority weights, which are calculated based on at least one or more of the user's historical request frequency, current waiting time, and service level, and are used to determine the order when priority conflicts occur when sequence numbers are the same.

[0087] The rules for calculating priority weights are defined as follows:

[0088] During the update cycle The system collects the frequency of near-window requests from the user to which the request belongs, the current waiting time of the request, and the service level, forming the input for subsequent normalization.

[0089] Recursive and saturation normalization are constructed for historical request frequencies:

[0090] ,

[0091] in, Indicates the discrete update cycle number. Indicates the first The weighted request frequency per period, in times per second. This indicates the weighted request frequency of the previous period, in times per second. Indicates the recursive weight. Indicates the first The number of requests made by this user within the period, in units of times. Indicates the update cycle, in seconds. Represents the frequency factor. This represents the saturation scaling coefficient, which is a dimensionless constant.

[0092] Proportionally crop the current waiting time:

[0093] ,

[0094] in, Indicates the waiting factor. This indicates the duration the request has been waiting, in seconds. This indicates the reference duration, which can be taken as the nearest window quantile, in seconds. Indicates will Truncation to closed interval Operators;

[0095] Map service levels to range quantities (e.g., SL1 / SL2 / SL3→) ), as a service factor;

[0096] In the In each update cycle, the priority score for concurrent decision-making is calculated using the following formula, and boundary pruning and shuffling are performed:

[0097] ,

[0098] in, Indicates the first The priority score of the cycle, , , Let represent the linear weights of the three types of factors, which are all dimensionless constants. This represents the power of the frequency factor, used to compress or amplify the impact on high-frequency users; it is a dimensionless constant. Represents the frequency factor. Indicates the waiting factor. Indicates service factor, This represents the dispersion amplitude, which is a dimensionless constant. Indicates a globally unique request identifier The calculated deterministic pseudo-random number, This indicates a globally unique identifier generated by the request;

[0099] Optional normalization condition is The surplus is used for When input samples are missing, the previous score remains unchanged; when the concurrent conflict rate increases near the window, the score is increased proportionally. and reduce This reduces concurrent operations caused by high-frequency clustering.

[0100] Originating from operation and maintenance strategy configuration, The quantile level is derived from historical statistics. Derived from frequency smoothing and saturation strategies; parameters are periodically applied. Update and write to the snapshot, limiting the magnitude of each change to a preset ratio to reduce fluctuations;

[0101] Larger With higher This will move long-queue requests to the front, reduce the tail of the queue, and increase... Prioritize coming out of the closet for higher-level services and set up [certain features]. It can suppress the occupancy tendency of a very small number of ultra-high frequency users and introduce It can reliably break up requests with the same consensus sequence number, reducing the probability of preemption and collision in scenarios where consensus sequence numbers are the same.

[0102] Specifically, the rule uses three factors to construct a configurable priority score. The frequency factor, after recursion and saturation processing, takes into account both historical activity and convergence speed. The waiting factor is a proportional measure of the current queuing time, which can elevate the position of long-waiting requests, thereby suppressing tail latency expansion. The service factor provides differentiated weights based on the level. When combining, a linear-power hybrid structure is given, and a deterministic shuffling term with controllable amplitude is added to form a stable fine-grained ranking when the scores are similar, reducing collisions under concurrent contention. In this embodiment, the historical request frequency is the arrival intensity of users within the update cycle, obtained by recursively counting and smoothing arrival events on the gateway side; the waiting time is the duration from enqueuing to the current moment; the service level is a level mapping predefined by the operation and maintenance strategy; and the deterministic shuffling term is a stable pseudo-random quantity derived from the request identifier. Specifically, the weights for frequency recursion are chosen between zero and one to balance convergence and memory; the waiting reference duration can be estimated from the near-window quantile; the linear weights and power exponents are fixed after the site trial run and gradually adjusted with a limited amplitude; the initial value of the scrambling amplitude is small, and it is increased proportionally when the conflict rate rises. For example, when the scores of two requests are close, introducing a scrambling term can stably change the order of requests, reducing the risk of duplicate allocation caused by concurrent requests with the same score. Optionally, the service level mapping can adopt three or more levels, all monotonically mapped within the range of zero to one and without changing the sorting interface. When any input sample is missing, the previous score remains unchanged and the change amplitude in a single cycle is limited; when the near-window conflict rate rises significantly, the weight of the waiting factor is temporarily increased to shorten the tail latency.

[0103] In one embodiment, edge-cloud collaborative fault tolerance works as follows: when a majority of nodes in the consensus group are unavailable, the system switches to a local degradation queue to maintain basic outbound capabilities. Once the connection is restored, the local commit records are reconciled with the consensus log, and conflicts are resolved. In this embodiment, the local degradation queue is a minimal commit queue that maintains outbound capabilities when a majority of nodes are unavailable. It is obtained by persistently storing the commits locally on the edge or cabinet controller, temporarily storing the occupancy and tokens in the order of arrival. Specifically, the determination to enter degradation mode is based on consecutive failures of health probes within a minimum duration. During degradation, concurrency and the number of concurrent requests per user are limited to suppress conflicts. After the connection is restored, reconciliation is based on the commit index, retaining the earliest record for concurrent occupancy of the same resource and rolling back subsequent records. For example, if the same battery is temporarily occupied by multiple local records, the first record is retained in chronological order, triggering the reallocation of subsequent requests. Optionally, during degradation, a restricted mode of outbound only or inbound only can be enabled, neither of which changes the reconciliation and rollback interface. If local persistence fails, immediately stop accepting new requests, retain occupied resources until the lease expires or manual intervention is required, and perform compensatory reconciliation after recovery.

[0104] In one embodiment, request and confirmation messages employ timestamp and signature anti-replay verification. The signature key is securely stored by the gateway and cabinet controller. Expired messages are discarded without affecting resource status. In this embodiment, the timestamp is monotonic time information carried in the request and confirmation messages, obtained by reading from a trusted time source and performing deviation correction at the edge or cabinet side. The signature is an authentication value calculated based on a symmetric or asymmetric key, which is stored in the secure area of ​​the gateway and cabinet controller. Specifically, the allowed deviation for time synchronization is no more than one second by default, and can be configured within the range of 200 milliseconds to 5 seconds according to site conditions. The message validity period is no less than three times the steady-state round-trip time by default. Key rotation is performed once every 30 to 90 days by default and supports dual-active transition. Signatures are discarded upon failure or expiration and the state machine is not advanced. For example, slight deviations triggered by short-term time drift are still acceptable and the timestamp can be corrected, but the allowed deviation limit must not be exceeded. Optionally, the signature algorithm can be selected from multiple equal-strength implementations, with consistent interfaces. Key management can interface with a hardware security environment or a software key library, with consistent output. When the time source is unavailable, maintain the most recent trusted time snapshot and enter conservative mode, shorten message validity period and increase logging level until the time source is restored.

[0105] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

[0106] Furthermore, those skilled in the art will understand that although some embodiments herein include certain features included in other embodiments but not others, combinations of features from different embodiments are meant to be within the scope of this application and form different embodiments. For example, all the embodiments above can be used in any combination. The information disclosed in this background section is intended only to enhance the understanding of the general background of this application and should not be construed as an admission or in any way implying that such information constitutes prior art known to those skilled in the art.

Claims

1. A smart operation and maintenance management method for battery swapping cabinets based on the Internet of Things (IoT), applied to a system including user terminals, IoT gateways, battery swapping cabinet controllers, and edge / cloud nodes, characterized in that, The method includes: Step S1: The gateway receives the battery swapping request from the user terminal and generates a globally unique identifier for each request. Step S2: Submit the request to a consensus group consisting of edge nodes and / or battery swapping cabinet controllers, and assign a global monotonic sequence number to the request based on the sequential consistency protocol; Step S3: Based on the serial number, perform atomic occupancy on the target battery in the target battery swapping cabinet, allocate and issue cabinet opening / removal instructions, and issue a lease with a token number at the same time; Step S4: Listen for physical confirmation events from the cabinet and match them with the token number; Step S5: If no valid confirmation is received within the lease period or the preset timeout, release the occupied resource and roll it back to availability; Step S6: Retry or reallocate incomplete requests according to the scheduling policy.

2. The intelligent operation and maintenance management method for battery swapping cabinets based on the Internet of Things as described in claim 1, characterized in that, The access side is requested to perform idempotency and deduplication processing, including: detecting replay / concurrent submissions based on globally unique identifiers and the most recently submitted cache, and returning only the existing allocation result for duplicate requests.

3. The intelligent operation and maintenance management method for battery swapping cabinets based on the Internet of Things as described in claim 1, characterized in that, The consensus group generates a consensus log for the leader-type consensus protocol. The log entries include the request identifier, sequence number, target cabinet / battery identifier, and token number, and only become effective externally after a majority of nodes have committed.

4. The intelligent operation and maintenance management method for battery swapping cabinets based on the Internet of Things as described in claim 1, characterized in that, Atomic occupancy employs a lease and token anti-concurrency mechanism: the current token number is written into the resource metadata, and the cabinet side only accepts execution / confirmation messages carrying the matching token number.

5. The intelligent operation and maintenance management method for battery swapping cabinets based on the Internet of Things as described in claim 1, characterized in that, The physical confirmation event includes at least one or a combination of the following: Cabinet door status closed signal, tray weight change signal, battery BMS handshake completed signal, and latch in position signal.

6. The intelligent operation and maintenance management method for battery swapping cabinets based on the Internet of Things as described in claim 1, characterized in that, Timeout threshold adaptive setting: dynamically adjusted based on recent network round-trip delay measurements and cabinet queue length, with maximum / minimum boundaries set; the threshold is increased when link degradation is detected and decreased when queue congestion occurs; The dynamic calculation method for the timeout threshold is as follows: 1) Set up observation windows and update cycles to collect round-trip delay samples, cabinet queue lengths and failure rates to form a stable statistical basis; 2) Calculate the quantile delay, queue percentage, and cycle failure rate within each update cycle as adaptive inputs; 3) in the For each update cycle, the timeout threshold is calculated using the following formula, and interval pruning is performed: ， in, Indicates the first The timeout threshold for the period, in milliseconds. The index representing the discrete update cycle is a non-negative integer. This represents the threshold value for the previous period, in milliseconds (ms). This represents the exponential smoothing coefficient, which is a dimensionless constant. Indicates the first Periodic RTT Quantiles, in milliseconds (ms). Indicates quantile level. This represents the link degradation amplification factor, which is a dimensionless constant. Indicates the first Cyclic link degradation indicators This represents the failure rate amplification factor, which is a dimensionless constant. Indicates the first Periodic request failure rate This represents the congestion reduction coefficient, which is a dimensionless constant. Indicates the first Queue length on the side of the cycle cabinet, in units of pieces. This represents the upper bound of the queue capacity, in units of pieces. and These represent the lower and upper bounds of the threshold, respectively, in milliseconds (ms). Indicates will Cut off to closed interval Operators; Calculate the relative increase: ， in, This represents the positive increase in relative quantile delay. This represents the same quantile value of the previous period's RTT, in milliseconds (ms). 4) The update cycle and observation window meet the requirements. ; 5) When or When the threshold increases, it is adjusted upwards to accommodate link degradation and failure risks. When the threshold is increased, it is lowered; 6) When a sample is missing, the threshold of the previous cycle is retained and does not fall below the lower bound. Multiple consecutive timeouts trigger a one-time backoff, raising the threshold of the next cycle but not exceeding the upper bound. After returning to normal, return to step 3). Gradual changes and limits on the scope of changes are adopted.

7. The intelligent operation and maintenance management method for battery swapping cabinets based on the Internet of Things as described in claim 1, characterized in that, Release the occupancy and trigger reallocation, including: selecting the next target cabinet in the candidate cabinet set based on distance / inventory / load, and setting a backoff time window for the same request.

8. The intelligent operation and maintenance management method for battery swapping cabinets based on the Internet of Things as described in claim 1, characterized in that, The scheduling strategy employs priority weights, which are calculated based on at least one or more of the user's historical request frequency, current waiting time, and service level, and are used to determine the order when priority conflicts occur when sequence numbers are the same. The calculation rules for the priority weights are defined as follows: During the update cycle The system collects the frequency of near-window requests from the user to which the request belongs, the current waiting time of the request, and the service level, forming the input for subsequent normalization. Construction of recursion and saturation normalization for historical request frequencies: ， in, Indicates the discrete update cycle number. Indicates the first The weighted request frequency per period, in times per second. This indicates the weighted request frequency of the previous period, in times per second. Indicates the recursive weight. Indicates the first The number of requests made by this user within the period, in units of times. Indicates the update cycle, in seconds. Represents the frequency factor. This represents the saturation scaling coefficient, which is a dimensionless constant. The current waiting time is proportionally cropped: ， in, Indicates the waiting factor. This indicates the duration the request has been waiting, in seconds. Indicates the reference duration. Indicates will Truncation to closed interval Operators; Map service levels to range quantities As a service factor; In the In each update cycle, the priority score for concurrent decision-making is calculated using the following formula, and boundary pruning and shuffling are performed: ， in, Indicates the first The priority score of the cycle, , , Let represent the linear weights of the three types of factors, which are all dimensionless constants. This represents the power of the frequency factor, used to compress or amplify the impact on high-frequency users; it is a dimensionless constant. Represents the frequency factor. Indicates the waiting factor. Indicates service factor, This represents the dispersion amplitude, which is a dimensionless constant. Indicates a globally unique request identifier The calculated deterministic pseudo-random number, This indicates the globally unique identifier generated by the request.

9. The intelligent operation and maintenance management method for battery swapping cabinets based on the Internet of Things as described in claim 1, characterized in that, Edge-cloud collaborative fault tolerance: When a majority of nodes in the consensus group are unavailable, switch to the local degradation queue to maintain basic outbound capabilities. After the connection is restored, reconcile the local commit records with the consensus log and resolve conflicts.

10. The intelligent operation and maintenance management method for battery swapping cabinets based on the Internet of Things as described in claim 1, characterized in that, Request and confirmation messages are verified against replay using timestamps and signatures. The signature key is securely stored by the gateway and cabinet controller. Expired messages are discarded without affecting resource status.

Images