Intelligent multi-terminal cooperative management method and system

Abstract

The application discloses a kind of intelligent multi-terminal cooperative management method and system.Mother lock is adjusted according to the data scale to be read and the scanning duty cycle that increases with the scale increases, scans the state broadcast periodically sent by each child lock without carrying log content, and the data scale to be read is determined based on the number of child locks identified to new log mark and / or the number of new logs;When identifying the new log mark in the state broadcast, which represents that the child lock has unread new logs, the check code carried by the broadcast is checked, and the corresponding child lock is determined as the child lock to be read after the check is passed;Connection is established with the child lock to be read, and the incremental log is determined according to the read record representing that the log has been successfully read, only the incremental log is read, and the connection is disconnected after reading is completed;The incremental log is summarized and uploaded to the cloud platform for storage.The application can effectively reduce the hardware cost and operating power consumption of multi-lock cooperation, improve the log recovery efficiency and security, and effectively support large-scale multi-lock networking application scenarios.

Description

Technical Field

[0001] This application relates to the field of Internet of Things (IoT) technology, and in particular to an intelligent multi-terminal collaborative management method and system. Background Technology

[0002] In the field of IoT-based fleet transportation management, to achieve monitoring and traceability management of the opening and closing of multiple doors and other transportation units in a truck's cargo compartment, existing technologies typically employ a multi-lock collaborative monitoring system, deploying multiple electronic locks at various monitoring nodes. These electronic locks generally integrate hardware such as lock body control circuits, wireless communication modules (Bluetooth or cellular networks), satellite positioning modules, batteries, and sensors. They are then used in conjunction with mobile apps, backend management systems, or RFID cards to achieve functions such as unlocking authorization, device identification, status uploading, and remote management. In multi-lock collaborative scenarios, a central lock typically establishes Bluetooth connections with each subordinate lock. By maintaining a long-term connection or establishing connections periodically to query each lock, the system obtains the lock's opening and closing status, battery level, anomaly information, and operation logs. The log data is then uploaded to a cloud platform for aggregation and storage. To meet the monitoring needs of environmentally sensitive scenarios such as cold chain transportation, existing solutions typically integrate environmental sensors such as temperature and humidity into each lock. The lock collects environmental information and reports it along with the lock's status.

[0003] However, the aforementioned existing technologies still have the following shortcomings in practical applications: First, when multiple electronic locks of the same model are deployed collaboratively, each lock needs to be equipped with complete wide-area communication modules, positioning modules, and environmental sensors, resulting in high overall hardware costs and power consumption. Second, the central lock and each subordinate lock need to maintain a long-term Bluetooth connection or frequently establish connections one by one for querying, which continues to occupy link resources even under normal circumstances where no events occur, increasing system power consumption and limiting the number of subordinate locks that a single central lock can manage. Third, the tag or event information carried in the broadcast channel lacks anti-forgery and anti-replay protection. Attackers can forge tag broadcasts to induce the central node to repeatedly establish invalid connections or replay historical legitimate broadcasts to disrupt the scheduling order. The multi-round handshake overhead of mature security protocols is unbearable for button battery-powered locks. Fourth, the local real-time clock of low-cost locks accumulates drift after long-term operation, the reliability of log timestamps is insufficient, the log cache during network outages and disconnections lacks hierarchical protection, and it is difficult to provide evidence in subsequent disputes over goods damage. Summary of the Invention

[0004] This application provides an intelligent multi-terminal collaborative management method and system, aiming to solve the technical problems of high overall hardware cost, high power consumption, easy forgery and replay of broadcast tags, and insufficient reliability of log timestamps in existing multi-lock collaborative methods.

[0005] To solve the above-mentioned technical problems, the first technical solution adopted in this application is: to provide an intelligent multi-terminal collaborative management method. This intelligent multi-terminal collaborative management method is applied to a master lock in an intelligent multi-terminal collaborative management system. The intelligent multi-terminal collaborative management system also includes multiple sub-locks and a cloud platform. The master lock is communicatively connected to each sub-lock and the cloud platform. The method includes: scanning the status broadcasts periodically sent by each sub-lock according to a scanning duty cycle. The scanning duty cycle is adjusted according to the size of the data to be read and increases with the increase of the size of the data to be read. The size of the data to be read is determined based on the number of sub-locks with newly identified log markers and / or the number of newly added logs. The status broadcast does not carry the content of the logs stored locally by the sub-locks. When a newly identified log marker is detected from the status broadcast, the checksum carried in the status broadcast is verified. If the verification passes, the checksum is checked. The sublock that sends the status broadcast is identified as the sublock to be read; a new log marker is added to indicate that there is a new log on the sublock's local machine, and the new log is the log that has not been read by the parent lock; a connection is established with the sublock to be read, and the incremental log is determined from the new log based on the read records. Only the incremental log is read, and after successful reading, a read confirmation is returned to the sublock to be read. After the reading is completed, the connection with the sublock to be read is disconnected; the read records are used to indicate the logs that have been successfully read by the parent lock; the read incremental logs are summarized and uploaded to the cloud platform, where they are stored. The cloud platform forwards the entry confirmation returned after successful storage to the corresponding sublock, so that the corresponding sublock can mark the corresponding log as synchronized after receiving the entry confirmation.

[0006] To address the aforementioned technical problems, the second technical solution adopted in this application is: providing another intelligent multi-terminal collaborative management method. This intelligent multi-terminal collaborative management method is applied to a sub-lock in an intelligent multi-terminal collaborative management system. The intelligent multi-terminal collaborative management system also includes a master lock and a cloud platform, with the master lock communicating with both the sub-lock and the cloud platform. The method includes: recording its own generated logs and saving them locally; periodically sending status broadcasts, the status broadcasts not carrying log content; when an event trigger condition is met, setting a new log marker in the status broadcast, the new log marker including a priority flag; the new log marker indicating that there are new logs on the sub-lock that have not been read by the master lock; responding to the connection initiated by the master lock after recognizing the new log marker, providing the master lock with the unread logs for the master lock to read, disconnecting after reading, and summarizing and uploading the read logs to the cloud platform; receiving a read confirmation returned by the master lock after successful reading, and an entry confirmation forwarded by the master lock from the cloud platform after successful saving; and marking the corresponding log as synchronized upon receiving the entry confirmation.

[0007] To address the aforementioned technical problems, the third technical solution adopted in this application is: providing an intelligent multi-terminal collaborative management system. This intelligent multi-terminal collaborative management system includes a master lock, multiple child locks, and a cloud platform; the master lock is communicatively connected to each child lock and the cloud platform; the child locks are used to record their own generated logs and save them locally, periodically send status broadcasts without log content, and when event triggering conditions are met, set a new log marker with a priority flag in the status broadcast. The new log marker indicates that there are new logs on the child lock's local machine that have not been read by the master lock, responds to connections initiated by the master lock by providing unread logs, and marks the corresponding logs as synchronized after receiving read confirmation and database entry confirmation; the master lock is used to scan the status broadcasts of each child lock according to a scan duty cycle that adjusts with the size of the data to be read and increases with the increase of the size of the data to be read, and when a new log marker is identified from the status broadcast, it sends a new log marker to the status broadcast. The checksum is verified. If the verification passes, the sublock that sent the status broadcast is identified as the sublock to be read. Connections are established with the sublocks to be read in descending order of reading priority indicated by the priority flag. Incremental logs are determined from the new logs based on the already read records, and only incremental logs are read. After successful reading, a read confirmation is returned to the corresponding sublock. After reading is completed, the connection is closed, and the read incremental logs are summarized and uploaded to the cloud platform. The database entry confirmation returned by the cloud platform after successful saving is forwarded to the corresponding sublock. The scale of the data to be read is determined based on the number of sublocks that have identified the new log flag and / or the number of new logs. The already read records are used to represent the logs that have been successfully read by the master lock. The cloud platform is used to save the incremental logs uploaded by the master lock and forwards the database entry confirmation to the sublocks through the master lock.

[0008] This application has the following beneficial technical effects compared to the prior art: (1) Significantly reduced power consumption: Under normal circumstances, the sub-lock only periodically sends status broadcasts without log content, thus decoupling the "declaration of the existence of data to be read" and the "log data itself". No connection is maintained when there are no new logs. The mother lock establishes a connection only after recognizing the new log marker and verifying it, and disconnects the connection after reading is completed. The connection only exists during log transmission. Under normal circumstances, the sub-lock does not need to maintain the link or respond to queries for log transmission, and the mother lock does not need to continuously occupy link resources. The connection time and the amount of connection data are compressed synchronously from the three stages of declaration, discovery and transfer, and the power consumption of the sub-lock and the mother lock is reduced synchronously.

[0009] (2) Significantly reduced hardware costs: The logs of each sub-lock are aggregated by the mother lock and uploaded to the cloud platform. The mother lock is used as a single point of exit to the cloud. Sub-locks do not need to be configured with wide area communication modules. The wide area communication capabilities of the mother lock are reused by all sub-locks, and the overall hardware cost of the system is reduced.

[0010] (3) Adaptive matching of scanning intensity and system load: The scanning duty cycle is adjusted according to the size of the data to be read and increases with the increase of the size of the data to be read. The size of the data to be read is determined based on the number of sub-locks that have identified new log markers and / or the number of new logs. When there is no data to be read, the mother lock runs with a low duty cycle and low power consumption. When the amount of data to be read increases, the event detection capability is automatically enhanced. The scanning intensity of the mother lock is dynamically matched with the system load, taking into account both the timeliness of event detection and the scanning power consumption.

[0011] (4) Log recycling is efficient and non-duplication: The master lock determines the incremental log from the new log based on the read records and only reads the incremental log. Logs that have been successfully read are no longer transmitted repeatedly. The connection time and data volume of each connection are compressed to a level that is strictly commensurate with the new part. The connection is disconnected after reading is completed. The duration of a single connection is extremely short. Link resources are reused in an orderly manner among multiple sub-locks. The number of sub-locks that the master lock can manage is no longer limited by the number of long connection concurrency.

[0012] (5) Invalid connections are suppressed: Before establishing a connection, the master lock first verifies the check code carried by the status broadcast. Only when the verification passes will the sub-lock that sent the status broadcast be identified as the sub-lock to be read and the connection be established. The status broadcast that fails the verification will not trigger the connection, thus avoiding invalid connections from occupying link resources and consuming sub-lock power. Attached Figure Description

[0013] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort, wherein: Figure 1 This is a flowchart illustrating an embodiment of the intelligent multi-terminal collaborative management method for master locks provided in this application; Figure 2 This is a flowchart illustrating an embodiment of the intelligent multi-terminal collaborative management method for sub-locks provided in this application; Figure 3 This is a schematic diagram of the structure of an embodiment of the intelligent multi-terminal collaborative management system provided in this application; Figure 4 yes Figure 3 A schematic diagram of the structure of a specific implementation of the intelligent multi-terminal collaborative management system 300 of the embodiment. Detailed Implementation

[0014] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0015] The terms "first," "second," and "third" used in the embodiments of this application are for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. "A plurality of" means at least two. The terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion.

[0016] In this application, the term "multi-terminal" in the intelligent multi-terminal collaborative management system refers to all participating terminals, including the master lock, child locks, and cloud platform, as well as other terminals such as user terminals, environmental sensor nodes, and RFID cards that serve as collaborative nodes. The following implementation uses a three-tiered relay architecture consisting of a master lock, multiple child locks, and a cloud platform as an example for illustration. This is only to demonstrate the core principles of the technical solution and does not constitute a sole limitation on the system architecture. In specific implementations, other functional nodes can be added or the hierarchical relationships can be adjusted. Furthermore, this solution is compatible with other scenarios that share the same technical issues or similar application requirements, such as scenarios with multiple master locks, a single child lock, or the deployment of other terminal devices. All of these scenarios can be considered application scenarios for this solution and fall within the scope of protection of this application.

[0017] For ease of reading, the specific implementation methods are presented in three parts: the first part is the method implementation examples applied to the master lock (Examples 1 to 8, where Example 1 is the basic example and Examples 2 to 8 are further examples based on it); the second part is the method implementation examples applied to the slave lock (Examples 9 to 14, where Example 9 is the basic example and Examples 10 to 14 are further examples based on it); the third part is the system implementation examples (Examples 15 to 19); and finally, there is a description of support for other protection topics. Common concepts repeatedly referenced in each embodiment (status broadcast, new log, global sequence number, priority flag bit, rolling count value, broadcast timestamp, checksum, etc.) are defined at their first appearance and are used thereafter.

[0018] The following embodiments use IoT fleet cold chain transportation management as an application scenario: a six-door refrigerated van is used as a transportation unit. The master lock (denoted as M0) is deployed at the central management node of the van, and six sub-locks (denoted as S1 to S6) are deployed at the six doors respectively. The cloud platform is deployed in the transportation management room. The sub-locks are powered by button batteries and integrate a short-range wireless communication module, a radio frequency identification module, a lock body control circuit, a local real-time clock, and a local storage with a capacity of 4096 logs. The status broadcast period is 1 second. The master lock integrates a low-power Bluetooth module, a 4G cellular communication module, and a satellite positioning module and is powered by a rechargeable lithium battery. The master lock and each sub-lock are connected via Bluetooth, and the master lock and the cloud platform are connected via a cellular network, forming a three-level hierarchical relay architecture of "sub-lock → master lock → cloud platform". The values ​​(duty cycle, backoff delay, sequence number interval, disconnection threshold, expected deviation range, etc.) appearing in each embodiment are calculated according to formulas (1) to (12) and are consistent.

[0019] (I) Implementation Examples of Methods Applied to Mother Locks Example 1: Overall Log Recycling Process This embodiment provides an intelligent multi-terminal collaborative management method for a master lock. This method is applied to a master lock in an intelligent multi-terminal collaborative management system, which also includes multiple sub-locks and a cloud platform. The master lock communicates with each sub-lock and the cloud platform. Before executing this method, the master lock has already bound itself to each sub-lock via an RFID card and established a management record for each bound sub-lock (see Embodiment 15 for details on the binding process and the establishment of the management record). The management record is maintained in conjunction with the online status of the sub-locks—each time a sub-lock is scanned, the most recent scan time and all status fields are refreshed. For sub-locks determined to be offline, all pointers and counts are retained to ensure seamless reconnection after re-entry into the network. The management record is periodically mirrored to the master lock's non-volatile memory for power-off recovery. See also... Figure 1 The method includes steps 101 to 104.

[0020] Step 101: Scan the status broadcasts periodically sent by each sublock according to the scan duty cycle. The scan duty cycle is adjusted according to the size of the data to be read and increases as the size of the data to be read increases. The size of the data to be read is determined based on the number of sublocks with newly identified log tags and / or the number of newly added logs. The status broadcast does not carry the contents of the logs stored locally by the sublocks.

[0021] Normal operation refers to the daily operating state where no connection has been established between the slave lock and the master lock. Status broadcasting is a short-frame broadcast signal sent by the slave lock to surrounding wireless channels at fixed intervals under normal operation; it carries only status information and no log content. In this state, the slave lock only periodically sends status broadcasts (the broadcast period in this embodiment is...). =1 second) without transmitting log content with the master lock, thus decoupling the "declaration of the existence of data to be read" from the "log data itself". The master lock adopts a random scanning method: the start time and duration of the scanning window are arranged in a pseudo-random sequence, so that there is no fixed phase relationship between the scanning time and the sub-lock broadcast period, avoiding systematic missed scans.

[0022] The scan duty cycle (i.e., the proportion of time used for scanning per unit time) is the core control parameter for master lock scan scheduling. It refers to the proportion of time that the master lock allocates to the scanning wireless channel per unit time. Its value can be dynamically adjusted in real time based on the number of newly identified child locks with new log tags, achieving adaptive matching between scan intensity and the scale of data to be processed. It maintains low power consumption when there is no data to be read, and automatically improves event detection capability when the amount of data to be read increases. Specific adjustment methods include, but are not limited to, linear adjustment, step adjustment, and saturation adjustment. Firstly, linear adjustment: the scan duty cycle adjusts according to the number of sub-locks to be read. It increases linearly in fixed steps and is truncated at the upper limit, i.e. ,in The step factor (e.g., 5%) – for each additional sublock to be read, the duty cycle increases by 5%, for example... =0% =20% at 2 o'clock =4 hours 30% =10 hits the 60% limit; linear adjustment is the simplest and most intuitive to implement, suitable for scenarios with a small number of reads and a desire to quickly maximize scan intensity. However, its drawback is that when the number of reads is large, the duty cycle quickly reaches its limit and lacks a smooth transition.

[0023] Secondly, tiered adjustment: Divide the number of sub-locks to be read into several levels, and the mother lock determines the duty cycle by looking up a table - for example, 0 locks correspond to 10%, 1 to 2 locks correspond to 25%, 3 to 4 locks correspond to 35%, and 5 locks and above correspond to 50%. Tiered adjustment only involves looking up and comparing tables, which minimizes the amount of calculation and makes it easy to manually set levels according to the operation strategy. It is suitable for operation scenarios with clear level boundaries. The disadvantage is that the scanning intensity changes abruptly at the level transition.

[0024] Third, saturation adjustment: Equation (1) Where n is the number of sublocks to be read; For scanning duty cycle; As the lower limit of silence, this embodiment takes =10%, ensuring basic discovery capabilities are maintained even when there is no data to be read; As the upper limit of the duty cycle, this embodiment takes =60%, constrained by the power consumption budget of the main lock; The half-saturation constant is taken in this embodiment. =4. The physical meaning of equation (1) is: the scan duty cycle increases monotonically with the number of sublocks to be read and is related to the number of sublocks to be read. The upper limit of saturation is reached, and the increase is rapid in the low quantity region. When the value is 1, the value rises to between the lower limit and the median of the interval. In the high-quantity region, the growth slows down and gradually approaches the upper limit. The more child locks to be read, the faster the mother lock needs to discover and connect them. However, the increase in scan intensity naturally slows down and caps as the number of child locks increases, preventing uncontrolled power consumption due to an unbounded increase in duty cycle. For example: =0 =10%, the equivalent detection period is approximately the ratio of the broadcast period to the duty cycle (1 second / 10%=10 seconds), meaning that on average, each sublock can be scanned once every 10 seconds; =2 ≈26.7%; =4 =35%; when the number of reads continues to increase. Approaching saturation at 60%, the equivalent detection cycle is shortened to approximately 2 seconds. When the sublock S3 experiences a violent tampering alarm, the next scan cycle... =1, =20%, the mother lock can detect the high priority broadcast of S3 within a few seconds.

[0025] The above three adjustment methods are all deterministic mappings based on the current number of data to be read. The only difference is the functional relationship (linear, lookup table, or saturation curve) between the number and the duty cycle. The master lock can be selected according to the power consumption budget and operation strategy or switched through the parameter set, which is simple to implement and the behavior is predictable. Every time the master lock scans a frame of status broadcast, it updates the online status, lock status, power, exception code, priority flag value and the most recent scan time of the corresponding sub-lock in the local sub-lock status table, and includes the sub-locks that have been identified with new log flags into the set to be read. The number of sub-locks to be read (as in equation (1)) used to determine the scale of data to be read in this application is the number of sub-locks in the set to be read, and the statistical caliber of the newly identified log flags is adopted. Sub-locks that fail the verification do not initiate a connection in step 102, and enter the connection scheduling only after their subsequent broadcast verification passes.

[0026] In this step, as a lower-level measure of the scale of data to be read, in addition to identifying the number of sublocks marked with newly added logs, the total number of newly added logs or a combination of the total number of logs and the number of sublocks (such as a weighted sum) can also be used. Taking the total number of unread logs as a measure and taking a half-saturation constant of 256 logs as an example: when there are no logs to be read, the duty cycle is maintained at the silent lower limit of 10%; after a certain scan, sublocks S3 and S5 have accumulated 32 and 96 logs respectively, totaling 128 logs, then the duty cycle rises to 10% + 50% × 128 / (128 + 256) ≈ 26.7%; when the total backlog is 512 logs, the duty cycle rises to about 43.3%. Using the number of sublocks as a measure highlights "how many sublocks are waiting", while using the number of unread logs as a measure highlights "how much data has not been moved". The combined measure takes into account both, and both are specific implementation methods that increase as the scale of data to be read increases.

[0027] Among them, the number of unread log entries is known by the master lock before establishing a connection: although the status broadcast does not carry log content, the sub-lock further carries the unread log entry count indication information in the status broadcast. The master lock can know the number of new logs that have not been read locally by each sub-lock without establishing a connection. One implementation is to set an unread count field in the broadcast frame (e.g., 16 bits, directly representing the number of log entries that have not been read locally by the master lock. Its presence and width are declared with the parameter set version number. The master lock parses the field according to the bit width corresponding to the version number. At this time, the broadcast frame load is extended accordingly but still far below the single frame load limit); another implementation is to use the quantity level information implicit in the priority flag bit - the priority value is determined by the quantity increment participating in the fusion (the fusion mechanism is detailed in equation (9) of embodiment 9). The master lock back-calculates the level of the unread log entry count according to the event-priority benchmark table and the current value, and estimates the number of new logs with level granularity; yet another implementation is for the master lock to estimate the number of new logs according to the historical log generation rate of the sub-lock and the time since the last successful reading. Therefore, the master lock can count and identify the number of child locks with newly added log markers and the number of newly added logs simply by scanning the various status broadcasts. Then, it can determine the size of the data to be read based on the number of child locks, the number of newly added logs, or a combination of the two, so that the scan duty cycle increases as the size of the data to be read increases.

[0028] Step 102: When a new log tag is identified from the status broadcast, the checksum carried in the status broadcast is verified. If the verification passes, the sublock that sent the status broadcast is identified as the sublock to be read.

[0029] The newly added log marker is a marker field set by the sub-lock in the status broadcast. It is used to indicate that a new log exists locally on the sub-lock. Once set, it is continuously broadcast with each status broadcast frame until the corresponding log is successfully read and confirmed for storage before being reset. The newly added log is the log stored locally by the sub-lock that has not been read by the parent lock (for the marker setting mechanism, see step 203 of Example 9). After the parent lock parses the broadcast frame and identifies the newly added log marker, it does not immediately initiate a connection. Instead, it first verifies the checksum carried in the broadcast frame. If the verification passes, the sub-lock that sent the broadcast is identified as the sub-lock to be read. The sub-lock to be read refers to the sub-lock that has a new log locally and has been identified by the parent lock as the target for connection reading. Its range is dynamically updated as the parent lock scans and identifies it. If the verification fails, the frame is discarded and no connection is initiated. The checksum is calculated and generated by the sub-lock based on a verification algorithm pre-agreed with the parent lock. The verification code is a message authentication code generated by the sublock based on the key parameters, including the sublock identifier and time-varying parameters (the generation method is detailed in Example 10). Its calculation input includes the identifier of the sublock that sent the broadcast, the priority flag value carried by the broadcast, the rolling count value that increases with each broadcast, and the broadcast timestamp that changes with time (the complete parameter set is shown in Equation (10) of Example 10). Therefore, the verification codes of each broadcast frame are different from each other. Forged frames and replay frames are intercepted in the verification process, and attackers cannot induce the mother lock to establish an invalid connection (the complete expansion of the triple criteria is shown in Example 2).

[0030] Step 103: Establish a connection with the sublock to be read, determine the incremental log from the new log based on the read records, read only the incremental log, return a read confirmation to the sublock to be read after successful reading, and disconnect the connection with the sublock to be read after reading is completed.

[0031] In this embodiment, read records are implemented using read sequence number pointers. Read records are information maintained by the master lock or child lock side to distinguish between logs that have been successfully read and those that have not. Incremental logs are the set of logs with global sequence numbers greater than the read sequence number pointer. The read sequence number pointer is the maximum global sequence number (initially 0 after binding) maintained by the master lock for each bound child lock, representing a log that has been successfully read. The global sequence number is assigned by the child locks in ascending order of log entries (see step 201 in embodiment 9). Each log entry can be uniquely identified throughout the system using a tuple of "child lock identifier + global sequence number". After establishing a connection with the child lock to be read, the master lock queries the child lock for its current maximum global sequence number. The reading range is determined as follows: Reading range Number of records read Equation (2) Where Lmax is the current maximum global sequence number of the sublock; This is the pointer to the read sequence number of the sublock. The physical meaning of equation (2) is: the global sequence number is less than or equal to... All logs have been successfully read and do not need to be transmitted again; only those falling within ( , The incremental logs within the specified interval constitute the current read set, and the connection time and the amount of connection data are compressed to a level strictly commensurate with the "new" portion. For example, after the mother lock and child lock S5 establish a connection, the query retrieves... =152, the sequence number pointer has been read from S5 maintained by the mother lock. =120, so this time only 32 log entries with global sequence numbers 121 to 152 will be read. After reading, Updated to 152, single connection duration is less than two seconds; if the reading process is interrupted at sequence number 140 due to signal interference, the master lock will only... The logs are updated to the maximum sequence number 140 that has been fully received. Logs starting from 141 are reserved for the next connection to continue reading from 141. No data is lost during interruption and no data is duplicated during recovery. The master lock sets an upper limit on the reading time of a single connection (10 seconds in this embodiment). If the timeout is exceeded, the connection is disconnected and retried according to the backoff strategy in embodiment 3, to prevent a single sub-lock with a large amount of logs from monopolizing the connection channel for a long time.

[0032] In this step, the read records can take other lower-level forms besides the read sequence number pointer. Firstly, read timestamps: The master lock records the log timestamp corresponding to the most recent read completion of each child lock. During the next connection, logs with timestamps later than this read timestamp are read. Considering the drift of the child lock's local real-time clock, the timestamp format needs to back the read boundary by a margin of the expected deviation range and supplemented with global sequence numbers for deduplication. For example, if the master lock records the read timestamp of child lock S5 as 10:32:15, and the current expected deviation range of this child lock is 10 seconds, then the next connection will read logs with timestamps later than 10:32:05, and duplicates will be removed by global sequence numbers to ensure that no logs within the drift window are missed. Secondly, read sequence number set: The master lock records the set of global sequence numbers that have been successfully read (such as a bitmap). Logs not in this set are read, which is suitable for scenarios with sequence number gaps (some logs have failed to be read). Third, the child lock deletion method: After receiving read confirmation from the mother lock, the child lock deletes the read log, making the existing local log the increment. The mother lock does not need to maintain records, but the child lock loses its local archive. All of the above methods distinguish between read and unread records based on the read records on either the mother lock or the child lock side. Among these, the read sequence number pointer implementation is the simplest, has the lowest overhead, and is unaffected by clock drift, making it the preferred method adopted in this embodiment. After reading is completed, the mother lock immediately disconnects, achieving immediate disconnection after reading—the connection only exists during log transmission, and the child lock then returns to its normal state of only broadcasting status.

[0033] Step 104: Summarize the read incremental logs and upload them to the cloud platform for storage. The cloud platform will then forward the entry confirmation returned by the cloud platform after successful storage to the corresponding sub-lock, so that the sub-lock can mark the corresponding logs as synchronized after receiving the entry confirmation.

[0034] The master lock aggregates the incremental logs read from each child lock, along with its own generated logs (including security event logs from Example 2 and offline event logs from Example 4), and uploads them to the cloud platform via wide area communication. During the aggregation and upload, the master lock uses the "child lock identifier + global sequence number" tuple as the key to remove duplicates, uploading only logs that have not yet been uploaded. The master lock maintains an uploaded sequence number level for each child lock, advancing the level upon successful upload. If cache loss occurs due to a master lock restart, the level is restored based on the highest sequence number of each child lock returned by the cloud platform after restart. If the network between the master lock and the cloud platform is unavailable (e.g., entering a cellular signal dead zone during transport), the master lock saves the read incremental logs and its own generated logs to a local cache, and continues uploading in global sequence number order after network recovery; failed uploads are continuously retransmitted until successful. The local cache uses a circular buffer organization: the write pointer advances with log reading, and the upload pointer advances with successful upload. The segment in between is the "read but not uploaded" segment. After the network is restored, the upload pointer continues in the order of the upload pointer. The circular buffer capacity is determined by the sum of the expected longest network outage duration and the log rate of all sub-locks (in this embodiment, it is estimated to be about 600 logs based on a 48-hour network outage and a total of 12 logs / hour for six sub-locks, with a capacity of 1024 logs configured and a margin reserved). After the cloud platform successfully saves the data, it sends an entry confirmation to the master lock. The master lock forwards the data through the next connection with the sub-lock, triggering the sub-lock to mark the corresponding log as synchronized (for details of the sub-lock's behavior, see step 205 in embodiment 9).

[0035] The log recycling process constructed in steps 101 to 104 of the above embodiment 1 enables the master lock to scan with a low duty cycle under normal event-free conditions. After identifying the marker and verifying it, it establishes a connection as needed, reads only the increment by pointer, disconnects immediately after reading, and transmits the read and storage confirmation back level by level. It summarizes, deduplicates, and uploads to the cloud. The connection time and connection data volume are compressed simultaneously in the three stages of announcement, discovery, and transfer, which significantly reduces the power consumption of the sub-locks and master locks. At the same time, it greatly improves the log recycling efficiency in multi-sub-lock scenarios. It effectively solves the technical problems of long connection occupying resources and frequent triggering of invalid connections in the existing technology. It is conducive to improving the sub-lock management capacity that the system can bear and meeting the operation requirements of large-scale multi-terminal collaborative networking scenarios.

[0036] Example 2: Triple Replay Protection Verification This embodiment further elaborates on the verification process of the checksum in step 102, based on embodiment 1. The status broadcast also carries a rolling count value and a broadcast timestamp: the rolling count value is maintained by the sublock, monotonically increasing with each status broadcast and naturally wrapping around after reaching the upper limit; the broadcast timestamp is the time information read from the local real-time clock and written into the broadcast frame when the sublock sends the status broadcast. The verification includes three sub-steps; all three must pass for the verification to be considered successful.

[0037] Step 1021 (Recalculation Consistency): Recalculate the checksum. If the recalculated checksum matches the checksum carried in the status broadcast, authentication is considered successful. The master lock uses the shared key parameters of the corresponding child lock stored locally to recalculate the checksum for the child lock identifier, priority flag value, rolling count value, broadcast timestamp, and parameter set version number within the frame using the same verification algorithm pre-agreed with the child lock, and compares it with the checksum carried within the frame. This sub-step intercepts all forged frames whose keys are unknown and legitimate frames whose fields have been tampered with—priority values ​​are involved in the calculation, and attackers cannot tamper with the priority without being detected.

[0038] Step 1022 (Monotonous Counting): Verify the rolling count value, based on the rolling count value detected in this scan. The rolling count value relative to the last successful verification When the increment of the modulus count is within the receiving window, the count is determined to be monotonic. ,and Equation (3) Where mod represents modulo operation, and 65536 is the upper limit of the rolling counter value (corresponding to the modulo value in 16-bit encoding). The value is 0xFFFF+1. This value is used because the width of the rolling count field is 16 bits, and its natural wraparound period is 65536. In other implementations, if the rolling count field uses different bit widths (e.g., 8 bits corresponding to a modulus of 256, 32 bits corresponding to a modulus of...), the value can be changed to 0xFFFF+1. Then the modulus in equation (3) is replaced accordingly. Count the width of the receiving window The values ​​can also be adjusted according to safety requirements (such as 512 or 2048), and are not limited to the values ​​in this embodiment. To determine the width of the counting reception window, this embodiment takes... =1024. When Falling on (0, The time limit was exceeded; =0 indicates a repeated frame; Greater than And less than 65536- Explanation Significantly smaller than Furthermore, if it does not constitute a wraparound, it is deemed a failure. If the modulus increment is greater than or equal to the upper limit of the count minus the width of the counting reception window, it indicates that the scroll count value detected this time is only slightly smaller than the scroll count value that passed the previous check and does not constitute a wraparound. This is mostly a replay of recent frames, which are also outside the reception window, and therefore, it is deemed a failure. For count wraparound: when When the count has exceeded the upper limit and the result wraps around, the modulo operation result naturally falls back to (0, ...). The interval is acceptable without special processing. For sub-locks that have been offline for a long time (such as shunting and grouping, signal blind zone) and then re-enter the network, their modulus increment may exceed the acceptance window at once: the broadcast timestamp of such sub-locks usually passes the time window criterion but the counting criterion does not pass temporarily. The mother lock identifies it as a resynchronization scenario rather than an attack (the timestamp and count of the replay frame do not pass, which can be distinguished from this scenario), does not include it in the continuous verification failure statistics, and waits for its rolling count value to naturally wrap around and fall into the acceptance window as the broadcast continues to advance before resuming acceptance. The recovery time is no more than one counting wrap-around cycle according to the 1-second broadcast cycle; or the counting acceptance window width can be taken to a larger value according to the deployment scenario or a variant of the acceptance window with only a lower bound can be used to shorten the resynchronization time. The physical meaning of equation (3) is: the rolling count value of the legal sub-lock advances slowly at a rate of 1 per broadcast, and the increment of the count value between two broadcasts that pass the verification is usually a small positive number; while the replay frame carries the historical count value, and its increment is either zero or negative offset, or it is too old and far exceeds the window width, and it cannot fall into the acceptance window. In other implementations, the accept window may only have a lower bound (i.e., only require the modulo increment to be greater than zero, which is equivalent to the accept window width being infinite), or it may be expressed in the form of an incremental threshold, all of which are specific implementations of the count monotonic pass determination.

[0039] Step 1023 (Time Window Valid): Verify the broadcast timestamp. If the time deviation calculated modulo the second count period between the broadcast timestamp and the calibrated precise time does not exceed the valid time window, the time window is deemed to have passed. ,and Equation (4) in, The broadcast timestamp carried by the broadcast frame (takes the lower 16 bits of the local real-time clock second count of the sublock). The lower 16 bits of the second count for the current precise time of the mother lock (obtained from satellite positioning time synchronization or network time synchronization in Example 5); This indicates that the smaller value is taken, and the calculation of the modulus time deviation is guaranteed to be correct before and after the low 16 bits are wrapped around. To determine the effective time window width, this embodiment takes... =60 seconds. The basis for setting this window width is: after the local real-time clock of the sub-lock is periodically calibrated by the master lock, the cumulative drift upper limit within a calibration cycle is much less than 60 seconds (see Example 5 for derivation). The timestamp of a legitimate broadcast will inevitably fall within the 60-second annular window based on the accurate time of the master lock, while the historical timestamp carried by the replay frame will far exceed this window.

[0040] Only when all steps 1021 to 1023 pass (i.e., authentication passes, count monotonicity passes, and time window passes), the mother lock's verification is successful, and the child lock that sent the status broadcast is identified as the child lock to be read; if any verification fails, no connection is initiated with the corresponding child lock. An example illustrating the interception effect: Example 1 (replay interception): An attacker intercepts a legitimate broadcast frame from child lock S5 at 9:00 AM (with a rolling count value of 0x1A20) and replays it at 11:00 AM; within two hours, the child lock has continued broadcasting approximately 7200 times, and the mother lock's most recent successful verification... It has been advanced to 0x3640, calculated according to formula (3). =58336, much larger than =1024, step 1022 fails; simultaneously, the timestamp of this frame deviates from the modulo time of the current precise time of the master lock by approximately 2 hours, far exceeding... =60 seconds, step 1023 also fails, the mother lock does not initiate a connection. Example 2 (forged interception): The attacker does not know the key, forges a high-priority broadcast frame by impersonating the identifier of sub-lock S3 and randomly fills in the checksum; the mother lock recalculates the checksum and it is inconsistent with the value in the frame, step 1021 fails. Example 3 (correct reception after wraparound): sub-lock S5's =0xFFF8, its subsequent broadcast wraps around to =0x0003, calculate according to formula (3) =11, falling within (0,1024], is accepted normally. The three criteria are independent of each other, and if any one fails, the other two still serve as a fallback: the authentication criterion uses the key as the root to prevent forgery and tampering, the counting criterion prevents same-source replay, and the time window criterion prevents replay across time periods; all criteria are lightweight operations—one hash and two numerical comparisons, with negligible computational overhead per frame, which is suitable for lock scenarios powered by button batteries and with extremely limited computing resources. This mechanism does not require multi-round handshakes and session maintenance of mature security protocols, and the dual interception of anti-forgery and anti-replay has almost no increase in connection overhead. The triple criteria also form a security linkage with parameter set rotation: after the key parameters of the verification algorithm are rotated periodically with the parameter set, the historical broadcast samples are invalidated for the updated verification (see Example 10 for details of the rotation mechanism), and the security strength does not decrease with running time.

[0041] The HMAC-SHA256 and 16-bit truncation examples mentioned here are only used to illustrate the feasibility of the verification process. Alternative algorithms (such as SHA-3, SM3), truncation width, and key parameters are also discussed. The specific method of obtaining the rotation cycle, etc., is the same as described in Example 10, and will not be repeated in this example. Further, the master lock counts verification failure events: when the broadcast verification failure of the same sub-lock identifier reaches a preset number (8 times in this example, which can be flexibly adjusted according to the security level, channel interference level, and attack risk level of the deployment scenario), it is determined that there is a suspicion of spoofing or replay attack. The sub-lock identifier, along with the count value and timestamp of the most recent several frames, can be recorded in the security event log and uploaded to the cloud platform in step 104. All the above verifications are completed before the connection is established. Intercepted frames do not trigger any connection behavior, and spoofing and replay attacks cannot consume the connection resources of the master lock.

[0042] It should be noted that the aforementioned counting method for consecutive verification failures reaching a preset number is a statistical measure of the number of times the state broadcast verification of the same sublock fails—counted by consecutive count, that is, counting the number of frames that consecutively fail the verification of the same sublock, and resetting the count once a verification passes. In other embodiments, this number can also be counted cumulatively by sliding time window (counting the total number of times the sublock verification fails within the most recent preset time period), or by cumulative count since the first verification failure. Regardless of the statistical measure used, as long as the number of verification failures reaches the preset number of failures, it is determined that there is a suspicion of spoofing or replay attack, generating a security event log containing the identifier of the corresponding sublock and uploading it to the cloud platform. The preset number of failures can be set according to attack tolerance, channel quality, and security level of the deployment scenario, etc. Its value takes into account the attack detection sensitivity and false alarm rate—if the value is too small, it can be triggered by occasional interference, and if the value is too large, the attack detection will be delayed. In this embodiment, 8 times is used as a balanced example. The continuous counting method is sensitive to continuous replay attacks, and the cumulative method is sensitive to intermittent attacks. Both can be selected according to the security strategy of the deployment scenario.

[0043] The above-described embodiment 2 employs a triple anti-replay verification mechanism consisting of authentication verification, monotonic counting verification, and time window verification. This mechanism enables multi-dimensional legality verification of state broadcasts, intercepting forged broadcasts, tampered broadcasts, and replay attacks at the source. This effectively prevents invalid connections from consuming link resources and sub-lock power consumption. Simultaneously, the failure counting mechanism enables the perception and traceability of attack behavior. The generated security event logs are uploaded to the cloud platform along with the business logs, significantly improving the communication security of the broadcast channel and the system's anti-attack capability. This is beneficial for ensuring the stable operation of the system in complex application scenarios and provides traceable behavioral evidence for subsequent security handling. It strengthens the first line of defense for communication security in multi-terminal collaborative networking environments, preventing unauthorized access and malicious attacks from threatening the normal operation of the system and the security of lock control data.

[0044] Example 3: Priority Scheduling and Connection Backoff This embodiment, based on Embodiment 1, further defines the connection scheduling in a multi-sublock concurrent scenario. Specifically, this embodiment defines the newly added log marker as including a priority marker bit, which is a subfield in the newly added log marker used to characterize the urgency of reading. This priority marker bit has multiple values, each representing a different reading priority. For example, the priority marker bit can be a three-bit marker, including eight values. 0 can represent a normal idle state with no unread newly added logs, while 1-7 represent the reading priority. Taking a mapping rule where higher values ​​indicate higher priority, a priority marker value of 7 indicates the highest priority rescue event requiring immediate response, such as forced unlocking or abnormal door sensor triggering; a value of 1 indicates the lowest priority normal event, such as ordinary lock opening / closing operations.

[0045] The method for executing the master lock further includes: when priority flag bits are identified from the status broadcasts of multiple sub-locks, each sub-lock with identified priority flag bits is identified as a sub-lock to be read in descending order of read priority represented by the priority flag bits, and a connection is established with each sub-lock to be read in sequence; when a status broadcast with a higher read priority represented by the priority flag bits is identified during the sequential connection establishment process, a connection is established with the sub-lock that sent the corresponding status broadcast first; wherein, if the waiting time for any sub-lock to be read to be connected exceeds a preset delay time limit, the read priority of the corresponding sub-lock to be read is increased; if the connection establishment with any sub-lock to be read fails, a retry delay is determined according to an exponential backoff strategy, and a connection is re-initiated with the sub-lock to be read that failed to connect after the retry delay expires, and the retry delay increases with the increase of the number of connection failures.

[0046] In the above scheme, the sorting and scheduling takes into account both "urgent priority" and "fair and bounded": sub-locks with the same value are arranged in ascending order according to their sub-lock identifiers to ensure fair round-robin; if a sub-lock with the same value has been in the later position for multiple consecutive rounds, it is moved to the front of the round-robin; the master lock maintains the enqueue time for each queue item, and queue items whose retention time exceeds the preset retention time limit (60 seconds in this embodiment) are temporarily promoted one level regardless of their value, ensuring that the longest waiting time for any log to be read is bounded. The newly added log tag includes a priority flag bit, and different values ​​represent different reading priorities (the value determination mechanism is detailed in step 203 of embodiment 9).

[0047] The scheduling mechanism for the above-mentioned scenario of concurrent read requests from multiple sub-locks can be implemented by maintaining a dynamic priority connection queue. When the master lock identifies the priority flag from the status broadcasts of multiple sub-locks within the same scan cycle and passes the verification, it sequentially identifies each sub-lock with the identified priority flag as a sub-lock to be read, forming a connection queue, and establishes connections with each sub-lock to be read in the order of the queue. For broadcasts with the highest priority value (7 in this embodiment), the master lock adopts an immediate interruption and reordering strategy: suspending the current queue and prioritizing connection establishment with the highest-priority sub-lock, and restoring the original queue after completion. For example, if three sub-locks, S3 (value 7), S5 (value 6), and S2 (value 6), are identified as set and pass the verification within a certain scan cycle, the connection queue is [S3, S2, S5]. The master lock first establishes a connection with S3 for reading, and then processes S2 and S5 sequentially after completion. In other implementations, immediate interruption reordering can also be extended to general preemptive reordering: during the sequential establishment of connections, as long as a priority flag bit with a higher reading priority is identified—not limited to the highest priority value—a connection is established with the sublock that sends the corresponding status broadcast first, thus decoupling the emergency log collection delay from the identification timing.

[0048] It should be noted that multiple sublocks with identified priority flags can be scanned and identified sequentially within the same scan cycle, or scanned and identified sequentially within different scan cycles and added to the connection queue. The connection queue is dynamically ordered according to the current priority value of each sublock. Sublocks with higher priority values ​​added later are inserted into the queue at the front of the queue corresponding to their values. The order of queue members is updated in real time according to the latest value broadcast (e.g., if a sublock's priority value increases due to continuous backlog, its position in the queue will move forward accordingly). The aforementioned preset dwell time limit refers to the maximum time that a sublock to be read is allowed to wait in the connection queue to be connected. The dwell time of a queue item is calculated from the time it is enqueued until the parent lock actually establishes a connection with it. Queue items that exceed the preset dwell time limit are given higher reading priority. The preset dwell time limit balances scheduling fairness and retrieval efficiency: its lower limit should cover the typical time for the mother lock to complete one round of discovery and connection establishment under the lowest scan intensity (silent lower duty cycle), and its upper limit is constrained by the emergency log retrieval delay requirements. In this embodiment, 60 seconds is chosen to balance both. The specific methods for increasing the read priority include temporarily increasing it by one level, increasing it to a specific level, or directly increasing it to the highest position in the queue. As long as the waiting time for any sub-lock to be read to be connected is bounded and not indefinitely delayed due to the continuous appearance of sub-locks with higher values, all of these are implementation methods for increasing the read priority of the corresponding sub-lock when the waiting time for any sub-lock to be read to be connected exceeds the preset dwell time limit.

[0049] When establishing a connection with any child lock to be read fails (e.g., due to busy factor lock channel, signal interference, or temporary unavailability of the child lock), the mother lock determines the retry delay according to the exponential backoff strategy: Equation (5) in, To avoid a base number, this embodiment takes... =500 milliseconds; This represents the number of consecutive connection failures for the same sublock. To set the maximum retry delay, this embodiment takes... =8 seconds. min indicates taking the smaller value, that is, the retry delay is capped at the upper limit of the retry delay. The physical meaning of equation (5) is: for each additional failure, the retry waiting time doubles and is capped at 8 seconds. This allows retry opportunities to spread out rapidly across the timeline, providing recovery time for channel congestion and preventing simultaneous retry requests from multiple sub-locks from creating a connection thundering herd. Furthermore, the retry delay can increase with the number of connection failures. For example, if the connection between the mother lock and sub-lock S4 fails consecutively, the retry delays after each failure are 500 milliseconds, 1000 milliseconds, 2000 milliseconds, 4000 milliseconds, and 8000 milliseconds, respectively, before capping at 8000 milliseconds. When consecutive failures reach a preset upper limit (6 times in this embodiment), the mother lock removes S4 from the current connection queue, awaiting re-evaluation in the next scan cycle.

[0050] The retry delay mentioned above refers to the time the master lock waits from determining a connection failure to re-initiating a connection to the failed child lock; the exponential backoff strategy refers to a backoff method in which the waiting time increases exponentially with the number of connection failures—according to equation (5), the retry delay is equal to the product of the backoff base and 2 raised to the power of the number of connection failures, and is capped at the upper limit of the retry delay. The more connection failures there are, the more stubborn the channel congestion or interference is, and the longer the waiting time is required for channel recovery. Therefore, the retry delay increases with the increase of the number of connection failures. The values ​​of the backoff base and the upper limit of the retry delay take into account both the log collection timeliness and the channel recovery needs—if the base or upper limit is too small, the backoff is insufficient, and retry may still be superimposed during the channel congestion period; if the value is too large, the log collection delay will be lengthened. In this embodiment, 500 milliseconds and 8 seconds are taken as balanced examples; both are master lock operation parameters, which can be configured through parameter sets and adjusted according to the channel environment and service timeliness requirements.

[0051] The above-described embodiment 3 achieves ordered connection scheduling in multi-sublock concurrent scenarios through priority dynamic scheduling, connection queue dynamic sorting, and exponential backoff retry mechanism. It not only ensures priority log collection in emergency scenarios such as rescue events and low power, but also ensures the fairness of regular log collection through the retention time limit enhancement mechanism. At the same time, the exponential backoff strategy effectively avoids channel congestion and connection thundering herd problems when connection fails, which greatly improves the log collection efficiency and system stability in multi-sublock scenarios. It is conducive to reducing the probability of connection conflicts in high-concurrency scenarios, shortening the average collection latency of emergency logs, avoiding high-priority logs being squeezed for a long time due to priority scheduling rules, ensuring the timeliness and reliability of full log collection, and adapting to application scenarios such as large warehouses and fleet transportation with a large number of sublocks online at the same time and a concentration of connection requests, ensuring the scheduling orderliness and operational stability of the system under multi-terminal concurrent access.

[0052] Example 4: Loss of Contact Determination and Resettlement Transmission This embodiment, based on embodiment 1, adds a disconnection determination and a relay transmission mechanism. The method executed by the master lock specifically includes: determining a disconnection threshold based on the scanning cycle and the status broadcast cycle; if the status broadcast of a sub-lock is not scanned before the disconnection threshold is exceeded, the corresponding sub-lock is recorded as an offline sub-lock; when the status broadcast of an offline sub-lock is scanned again and a new log marker is identified from the status broadcast, a connection is established with the offline sub-lock; the rescue event logs stored locally by the offline sub-lock are read first, followed by the newly added logs other than the rescue event logs; and the newly added logs cached by the offline sub-lock during its offline period are retransmitted; if any of the retransmitted newly added logs are missing, an alarm event is generated to characterize the missing logs, and the alarm event is reported to the cloud platform.

[0053] In the above implementation, the disconnection threshold is a parameter reflecting the online status of the sub-lock. Based on the scanning cycle and the status broadcast cycle, it can be determined according to the scanning scheduling strategy and the tolerance for missed scans. For example, considering the requirement of a normal missed scan rate of less than 1% in cold chain transportation scenarios, this embodiment uses four times the equivalent discovery cycle plus a 10-second protection margin as the judgment threshold. When the disconnection threshold is exceeded and the corresponding sub-lock's status broadcast is not detected, the master lock marks the sub-lock as offline and generates an offline event log, synchronously updating the local sub-lock status table without immediately initiating a connection attempt.

[0054] Considering that the master lock has a normal probability of missing scans when scanning with an adaptive duty cycle, the disconnection threshold is the longest time that the master lock determines the child lock has not been scanned since it left the communication range. It cannot be simply taken as a multiple of a single broadcast cycle, but can be calculated based on the equivalent discovery cycle: Equation (6) in, The determination factor for consecutive unscanned items is taken in this embodiment. =4; The equivalent detection period under the current scan duty cycle is estimated as the ratio of the broadcast period to the scan duty cycle (e.g., broadcast period 1 second, ...). When =10%, ≈10 seconds, directly connected with formula (1) of Example 1); The broadcast cycle is 1 second. To provide a protection margin, this embodiment uses 10 seconds. `max` indicates taking the larger value, meaning the disconnection threshold is calculated based on the larger of the equivalent detection period and the broadcast period. The physical meaning of equation (6) is: only if no broadcast of a certain sublock is detected within a duration of "several consecutive equivalent detection periods plus protection margin" can the possibility of a normal missed scan be ruled out, thus determining disconnection. According to the parameters of this embodiment, under normal circumstances... =4×10+10=50 seconds: If the master lock does not scan the status broadcast of slave lock S6 for more than 50 seconds, S6 is recorded as an offline slave lock and an offline event log is generated. This is then reported to the cloud platform via step 104, and the management is informed in real time that "the lock on door number 6 has been disconnected from monitoring." When the trailer tether returns to the main vehicle and the master lock scans the S6 broadcast again, the master lock generates an online recovery event report, forming a complete offline-recovery closed-loop record, providing immediate evidence for compliance verification of trailer tethering operations. When the duty cycle rises to 60%... ≈4×1.7+10≈17 seconds, making the judgment more sensitive and matching the rapid detection capability under high duty cycle.

[0055] It should be noted that the disconnection threshold based on Equation (6) depends not only on the broadcast cycle of the sub-lock side, but also on the scanning schedule of the master lock side: the scanning cycle refers to the time unit for the master lock to organize the scanning schedule. The master lock arranges the scanning window according to the current scanning duty cycle in each scanning cycle (for example, when the scanning cycle is 1 second and the scanning duty cycle is 10%, a total of 100 milliseconds of scanning windows are arranged per second, and the window start time is arranged according to a pseudo-random sequence). The scanning duty cycle is the proportion of the scanning window duration within a unit scanning cycle. The equivalent discovery cycle in Equation (6) is estimated by the ratio of the broadcast cycle to the scanning duty cycle, which simultaneously includes the broadcast cycle of the sub-lock side and the scanning schedule of the master lock side (the scanning cycle and the scanning duty cycle together characterize the scanning duration and broadcast discovery probability per unit time): when the scanning duty cycle is constant, the longer the broadcast cycle, the longer the equivalent discovery cycle; when the broadcast cycle is constant, the lower the scanning duty cycle, the longer the equivalent discovery cycle. Therefore, the disconnection threshold is essentially determined by the scanning cycle of the master lock (and the scanning duty cycle within it) and the broadcast cycle of the status broadcast. An increase in the disconnection threshold or a decrease in the scanning intensity will increase the disconnection threshold, and vice versa. The scanning cycle and the scanning duty cycle are both configurable operating parameters of the master lock in the parameter set (see the parameter set content of Example 12). After the master lock adjusts the scanning schedule, the disconnection threshold is dynamically updated accordingly to ensure that the disconnection judgment has a consistent tolerance for missed scans under different scanning intensities.

[0056] For offline sub-locks, a ferry-based retransmission mechanism is adopted (i.e., the master lock retransmits the logs cached by the offline sub-lock during its offline period to the cloud platform after reading them). Specifically, when the master lock scans its status broadcast again and recognizes the newly added log marker (verification passed), it establishes a connection with the offline sub-lock and reads the logs cached during the offline period in the retransmission order of "rescue event type first, others in global sequence number order": first, it reads the rescue event type logs stored locally by the offline sub-lock, and then reads the abnormal event type and regular operation type logs in global sequence number order. Among them, the logs generated by the sub-lock can be divided into three categories according to the nature of the event: rescue event type logs, which record logs of emergency events such as emergency unlocking, violent damage alarms, and rescue calls; abnormal event type logs, which record logs of abnormal events such as communication abnormalities, sensor failures, lock jamming, and unauthorized card swipe attempts; and regular operation type logs, which record logs of normal unlocking, locking, binding and unbinding, etc. The three types of logs have different processing priorities in mechanisms such as priority fusion, hierarchical eviction, and shuttle retransmission. This event nature classification method is the core mapping rule for the priority flag value. As long as the status broadcast includes a priority field that represents the urgency of the event to distinguish the reading urgency of different types of logs, it can be understood that it falls within the scope of application of the priority scheduling mechanism defined in this embodiment.

[0057] It should be noted that the sub-lock itself has no offline awareness during the period of disconnection - the sub-lock does not maintain a connection with the mother lock and has no way of knowing whether the mother lock has scanned it. Its behavior during the period of disconnection is entirely driven by the local state: continuously generating and caching logs, automatically increasing the priority value as the disconnection time increases according to formula (9) in Example 9, and continuously and periodically sending status broadcasts; the longer the disconnection lasts, the higher the value, and when it re-enters the network, it is recycled by the mother lock with the highest priority. The risk of log backlog during the period of disconnection is mitigated at the system level by the priority climbing mechanism on the sub-lock side, and the disconnection threshold mechanism on the mother lock side is responsible for timely informing the management. The two mechanisms complement each other and do not require any two-way communication during the period of disconnection. For example, the sub-lock S6 was separated from the main vehicle for 72 hours during the semi-trailer swapping operation. During this period, it was unlocked and locked a total of 36 times and generated 2 communication abnormality logs. A total of 38 logs were cached (the cache endpoint value of 3686 in Example 11 was not reached, so it was not triggered to eliminate). Three days later, the swapped trailer was reassembled back into the main vehicle. The main lock scanned the status broadcast of S6 again. After the resynchronization mechanism of Example 2 was used, it passed the verification after its count returned to the window. It was identified that its priority value was 7 (the 72-hour backlog was capped by fusion calculation). S6 was placed in the highest priority position of the connection queue to establish a connection. All 38 cached logs were read according to formula (2) and uploaded. The logs were fully transmitted to the cloud platform through the transfer. No logs were lost due to the 72-hour disconnection. Furthermore, during the transfer and retransmission, the master lock checks the read logs according to the continuity of the global sequence number: when a record is eliminated due to cache overflow or individual record writing failure during offline periods, the global sequence number of the child lock's local log will change. When the master lock detects a sequence number gap, it generates an alarm event indicating a missing log. The alarm event carries the gap range (such as missing sequence numbers 153 to 167) and is reported to the cloud platform along with the log, so that the log is incomplete during the evidence verification process. Combined with the mechanism in Implementation Example 11 that determines the cache endpoint value according to the expected offline duration, the probability of gaps can be reduced from the source. The gap alarm includes "whether the log is complete" itself in the scope of evidence, rather than assuming completeness.

[0058] The above parameters for calculating the loss of contact threshold ( , The order of data transmission and the priority of retransmission (rescue events take precedence) are illustrative examples. In other implementations, It can be adjusted according to the missed scan tolerance (e.g., 3 to 6). The parameters can be adjusted according to channel quality, and the retransmission order can also be set with different priorities according to service requirements. The above-mentioned calculated parameters and retransmission order are only the choices for this embodiment and can be reset according to the deployment scenario. They are no longer limited item by item.

[0059] The above-described embodiment 4, through adaptive disconnection threshold determination, priority scheduling for shuttle retransmission, and log missing alarm mechanism, achieves accurate identification of the offline status of sub-locks and complete recovery of offline logs. It not only ensures the priority transmission of rescue event logs during offline periods, but also makes log integrity verifiable through log missing alarm, effectively solving the problem of log loss and untraceability in sub-lock offline scenarios, improving system reliability in extreme scenarios, and helping to meet the traceability requirements in scenarios of large-scale multi-sub-lock mobile networking and frequent network reorganization. It is also suitable for business scenarios such as trailer swapping and shared warehousing, where sub-locks dynamically enter and exit the communication range of the main lock with the transportation unit, providing complete and reliable data support for the traceability of the entire business operation process.

[0060] Example 5: Clock Calibration and Timestamp Trust Verification This embodiment, based on Embodiment 1, adds a clock calibration and timestamp reliable verification mechanism. The method to be performed by the master lock further includes: obtaining the calibrated precise time through satellite positioning or network time synchronization; periodically calibrating the local real-time clock of each sub-lock according to the precise time and recording the calibration deviation at each calibration; when reading incremental logs, determining the expected deviation range based on the precise time and the calibration deviation recorded at the most recent calibration; when the deviation of the timestamp in the incremental log relative to the precise time exceeds the expected deviation range, determining the corresponding log anomaly and uploading the anomaly identifier along with the log summary to the cloud platform; after reading the incremental logs of multiple sub-locks, cross-validating the logs of multiple sub-locks whose timestamps are within the same time window; when the deviation between the timestamps of different sub-lock logs exceeds the cross-validation threshold determined based on their respective expected deviation ranges, determining the corresponding log anomaly and uploading the anomaly identifier along with the log summary to the cloud platform.

[0061] The above mechanism specifically employs the following three technical means: Firstly, the master lock obtains the calibrated precise time through satellite positioning time synchronization (such as GPS or BeiDou) or network time synchronization (such as Network Time Protocol time synchronization). Based on this precise time, it periodically calibrates the local real-time clocks of each slave lock (the calibration period in this embodiment is 3 days), and records the calibration deviation for each calibration—the calibration deviation being the difference between the slave lock's local real-time clock time at the time of calibration and the calibrated precise time. Regarding the timing of calibration, the master lock prioritizes existing log reading connections: when establishing a connection with the slave lock to read the logs, it sends a calibration message incidentally, without initiating an additional connection specifically for calibration. The time transmission protocol uses a two-stage approach of "timestamp pre-send + timestamp activation" to compensate for transmission delay: the master lock sends a calibration message carrying the future activation time (e.g., "calibrate the clock to T_set in 3 seconds"), and the slave lock, upon confirming receipt, atomically activates the calibration when its local time reaches the estimated transmission completion point, avoiding the fixed deviation introduced by "the message arrival time not equaling the clock sampling time." Here is a complete numerical example of a calibration: At 08:00:00 on a certain day, the master lock establishes a read connection with the slave lock S5, and simultaneously sends a calibration message "The clock will be calibrated to 08:00:03.000 in 3 seconds." The slave lock reads its local clock as 08:00:01.800 immediately upon activation (i.e., the slave lock clock was 1.2 seconds behind the accurate time before activation). The master lock records the calibration deviation of S5 for this calibration. =-1.2 seconds, calibration time 08:00. Calibration only adjusts the clock time reference and does not revert the timestamp of the fixed log. The credibility of the fixed log is determined by the following verification. The responsibilities of clock calibration and timestamp verification are separated to ensure that abnormal timestamps can always be detected rather than being erased by the calibration action. Furthermore, the calibration message also carries an authentication code calculated based on the shared key parameters. The calibration only takes effect after the sub-lock verifies the calibration message, to prevent malicious attacks that would forge calibration messages to disturb the sub-lock's local real-time clock and thus pollute the log timestamp. The calibration link and the broadcast verification link share the same key root, thus forming a complete secure closed loop of time trust from time source, calibration transmission to timestamp verification.

[0062] Secondly, when the master lock reads the incremental log, it checks the timestamp of each log entry against the expected deviation range: Equation (7) in, The expected deviation range is expressed in seconds. This refers to the calibration deviation recorded during the most recent calibration. The drift rate of the local real-time clock of the sublock is expressed in seconds per day. In this embodiment, it is taken as... =2 seconds / day; This is the elapsed time since the most recent calibration, in days. To ensure the margin for verification, this embodiment uses 2 seconds. The physical meaning of equation (7) is: the normal deviation of a log timestamp relative to the precise time consists of three parts: the residual known during calibration, the drift amount that accumulates linearly with time according to the drift rate after calibration, and the miscellaneous margin of the verification process itself. The sum of the three is the upper bound of the dynamic reliable deviation of the sublock at that moment.

[0063] The above formula (7) represents the calculation logic of the expected deviation range: the maximum number of seconds that a sublock's log timestamp can be allowed to differ from is equal to "how many seconds it was already different at the last calibration", plus "how many days have passed since calibration at the rate of drifting by how many seconds per day", plus "the number of extra seconds reserved for calculation and transmission errors". The three terms have different sources and exist simultaneously: the first term is the known residual obtained at the moment of the last calibration (the remaining fraction after the sublock clock is pulled back); the second term is the cumulative amount of the sublock crystal oscillator continuing to deviate at its own drift speed after calibration, which is obtained by multiplying the drift rate by the number of days; the third term is unrelated to the sublock state and is a reserve reserved for timestamp rounding, reading delay and other miscellaneous items. The reason for adding the three terms instead of taking the maximum value is that the three terms are independent of each other and do not cancel each other out. Under normal circumstances, the worst case is that the three terms are superimposed, and the sum can be used as a reliable upper bound that "under normal circumstances will not exceed".

[0064] Example of item-by-item substitution: Sublock S5 was 1.2 seconds slower during the last calibration, i.e. | |=1.2 seconds; its clock drift rate is 2 seconds per day, and 3 days have passed, with the cumulative drift being × =2×3=6 seconds; Miscellaneous margin =2 seconds; adding the three together gives =1.2+6+2=9.2 seconds, which can be rounded up to 10 seconds.

[0065] Usage for judgment: When the master lock reads each log entry of the child lock, it subtracts the log timestamp from the expected time calculated based on the precise time to obtain the actual deviation. The actual deviation shall not exceed [a certain value]. This means the deviation falls within the normal range that can be explained by "known residuals + normal drift + calculated margin"; if it exceeds this range, it indicates that the deviation cannot be explained by normal causes, and the timestamp is judged to be abnormal. Complete example: Sublock S5 calibration deviation -1.2 seconds; 3 days later, the master lock reads and checks each of the 32 log entries recovered in Example 1: =1.2 + 2 × 3 + 2 = 9.2 seconds, rounded up to 10 seconds; the timestamp deviation of all 31 logs is within 3 seconds, which is considered normal; however, the timestamp deviation of log with global sequence number 133 is 38 seconds, far exceeding the limit. =10 seconds, an anomaly is determined and a timestamp anomaly identifier is attached and uploaded with step 104. The cloud platform includes it in the evidence warning list. The drift rate in formula (7) Instead of a fixed factory value, the main lock is corrected online based on previous calibration records: the measured drift rate for each interval is obtained by dividing the deviation change between two adjacent calibrations by the interval length, and the maximum absolute value is taken as the currently used value. —Take the maximum value To cover the worst-case scenario, it's better to be lenient than to omit any cases. For example, the deviations of the sub-lock S5 in the last five calibrations were +1.0, -0.2, -1.6, -3.2, and -4.9 seconds (each at 3-day intervals), with a measured maximum drift rate of approximately 0.57 seconds / day. The main lock adopts this approach accordingly. =0.6 seconds / day Tightening the time to 4.9 + 0.6 × 3 + 2 = 8.7 seconds improves the verification sensitivity; conversely, if the measured drift rate consistently exceeds the specified value (crystal oscillator aging), the maximum measured value is used to relax the lock on the motherboard. It also generates and reports clock health status alerts.

[0066] Thirdly, the master lock performs cross-validation on the logs of multiple child locks whose timestamps are within the same time window (±10 seconds in this embodiment), and the judgment threshold is determined as follows: Equation (8) in, The threshold for determining the log timestamp deviation between sublock i and sublock j is the cross-validation threshold—the maximum possible deviation between the timestamps of two independently timed sublocks under normal circumstances. , These are the respective expected deviation ranges determined by formula (7). The log timestamp deviations of the two sub-locks within the same group exceed... When this happens, the corresponding log is identified as abnormal, and an abnormality flag is attached and uploaded. Continuing with the previous example: Log number 133 with a deviation of 38 seconds (sub-lock S5, The timestamp of 10 seconds is within the window from 10:32:10 to 10:32:20, and there is exactly one locking log entry for sub-lock S1 in the same window. =8 seconds); according to formula (8). =max(10,8)+2=12 seconds. Actual testing showed a 36-second discrepancy between the timestamps of the two log entries for the two locks, exceeding the limit. =12 seconds, cross-validation determines an anomaly - Equation (7) single lock check lock S5 serial number 133 exceeds the tolerance, Equation (8) cross-validation shows that S1 clock is normal but S5 timestamp is significantly inconsistent with it, the two lines of defense corroborate each other, the cloud platform can mark the log as "timestamp suspicious" with high confidence, indicating that there may be human tampering or real clock failure. Conversely, if the log deviation of the two locks in the same window is 9 seconds (not exceeding the tolerance), If the time interval is 12 seconds and the individual lock verification is within the specified range, then the mutual verification is considered normal and no false alarms are generated.

[0067] For logs of three or more child locks within a window, the parent lock enumerates all pairwise combinations and checks them one by one: if the deviation of a lock from all other locks in the window exceeds the threshold while the deviations between other locks are normal, the lock is identified as the abnormal party; if the deviations of all locks from each other exceed the threshold and are in the same direction, it indicates that there may be a group time reference event (such as a time synchronization failure of the parent lock itself), and the parent lock reports the group abnormal event to the cloud platform for manual review. Example of multiple locks: In a window with logs of three child locks S1, S2, and S3, the deviations between S1 and S2 are 3 seconds, S2 and S3 are 4 seconds, and S1 and S3 are 6 seconds, none of which exceed their respective thresholds. (Approximately 12 seconds) The three locks are mutually verified and determined to be normal; if the deviations between S3 and S1 and S2 reach 40 seconds and 41 seconds respectively, while the difference between S1 and S2 is only 3 seconds, then the location of S3 is abnormal, which is consistent with the result of its single lock verification—the more sub-locks and the more dense the events in the same window, the stronger the positioning capability of the mutual verification network, which is in line with the common conditions of multi-door transportation scenarios. The time parameters are set self-consistently according to the following chain: the maximum cumulative drift of the sub-lock clock within one calibration cycle (3 days) is... × The calibration period plus the calibration residual, i.e., 2×3+1.2=7.2 seconds, is much smaller than the effective window of the broadcast timestamp in Example 2. =60 seconds, ensuring that legitimate broadcast frames are not mistakenly rejected by the time window and leaving sufficient margin; the broadcast layer uses a 60-second wide window to quickly filter expired frames, the log layer uses a dynamic narrow window of about 10 seconds to accurately verify the single lock timestamp, and the multi-lock layer uses cross-verification to verify each other, with strictness and leniency in an orderly and progressive manner.

[0068] The calibration period, drift rate, margin, and time window width mentioned above are all exemplary parameters. In other embodiments, the calibration period can be adjusted according to the accuracy of the sub-lock crystal oscillator (e.g., 1 to 7 days), the drift rate can be corrected online according to the crystal oscillator specifications, the effective time window width can be calculated according to the calibration period and the upper limit of the drift, and the cross-validation window can also be adjusted according to the multi-lock deployment density. All of these are specific implementations of the technical solution of this application and do not constitute a specific limitation on the scope of protection. This adaptive parameter adjustment mechanism achieves a dynamic balance between sub-lock clock accuracy and calibration overhead, ensuring the reliability of log timestamps while avoiding unnecessary calibration connections that consume link resources. This allows the clock calibration mechanism to adapt to multi-terminal collaborative scenarios with different cost levels and deployment densities, further enhancing the universality and scenario adaptability of this solution. It helps maintain the accuracy of timestamp verification under actual working conditions such as sub-lock crystal oscillator aging and changes in environmental temperature and humidity, avoiding misjudgments or omissions due to accumulated clock drift in abnormal logs. This provides technical assurance for the reliability of log time dimension and provides an accurate and unified time benchmark for subsequent cross-lock event timing restoration and operational process evidence collection, further strengthening the system's data security defense.

[0069] Example 6: Log Hash Chain Tamper-Proof This embodiment, based on the log recording and recycling mechanisms of the aforementioned embodiments, adds a log hash chain anti-tampering mechanism to provide cryptographic integrity protection for the local logs of the sub-locks. The method to be executed by the mother lock also includes: when reading the incremental logs of the sub-locks, synchronously obtaining the chained hash value carried by each log, verifying the hash continuity one by one according to the hash chain generation rules, and if a hash break occurs, marking the corresponding log and subsequent affected logs as suspected of tampering, and uploading them to the cloud platform along with the log summary.

[0070] The basic principle of log hash chains is as follows: When a sub-lock writes each log entry, it not only saves the log entry's content (category, details, timestamp, global sequence number) but also an additional chained hash value. The input to this chained hash value consists of two parts—the entire content of the current log entry and the chained hash value of the previous log entry—which are then concatenated and hashed using a hash function to obtain the current log entry's chained hash value. Thus, starting from the first log entry of the sub-lock, the chained hash value of each log entry implicitly contains information from all the preceding log entries, forming an indivisible hash chain.

[0071] The specific implementation method is as follows. When the sublock records the log in step 201, it performs the following for each log entry: ,in For the first The chained hash value of each log entry. For the first Concatenate all content fields of the log entry. The chained hash value of the previous log entry (the first log entry's hash value). (Take a preset initial value, such as all zeros). Indicates splicing, The hash function is used (e.g., SHA-256, truncated to 32 bits). The chained hash values ​​are stored along with the logs in local memory slots. Due to the avalanche effect of hash functions, if the content of any log entry is modified afterward (even by just one byte), its own chained hash value changes, causing the chained hash values ​​of all subsequent log entries to differ from the original value. Tampering cannot be concealed by simply modifying the target log; the entire chain must be reconstructed, and reconstruction requires knowledge of the original hash values. This is not feasible without knowing the original content of the log.

[0072] When the mother lock reads the child lock logs (step 103), it verifies the continuity of the hash chain one by one: starting from the first log, it recalculates the chain hash value of each log in turn and compares it with the stored value. The verification result (continuity / break position) is uploaded to the cloud platform along with the logs, and the cloud can independently perform the same verification to review it. For example: in the logs of child lock S5, from sequence number 121 to 152, the log content of sequence number 133 is suspected of being tampered with (timestamp deviation of 38 seconds, see the verification result of formula (7) in Example 5), the mother lock recalculates the chain hash value of sequence number 133. With stored value The chain hash values ​​for sequences 134 to 152 are inconsistent, confirming that the content of sequence 133 was indeed modified, not due to clock drift, and that the modification occurred locally on the child lock (after physical contact), not during transmission (transmission tampering only affects a single record and does not affect subsequent chains). Based on this, the cloud platform can mark sequence 133 as "content tampered with," while sequences 134 to 152, although having inconsistent chain hash values, have not had their own content fields modified (the mother lock recalculates their content). (The value is consistent with the original content), and it is only affected by the break in the previous chain. The cloud can combine the timestamp to verify that its content is still credible.

[0073] The log hash chain in this embodiment and the timestamp verification mechanism in embodiment 5 constitute a complementary dual-evidence system: the timestamp verification identifies anomalies from the "time dimension" (the deviation between the log's time and the precise time exceeds the normal drift range), and the hash chain identifies tampering from the "content dimension" (the cryptographic association between the log's content and previous and subsequent logs is broken). Together, they enhance the credibility of a single-lock log from "default credibility" to "cryptographically verified credibility".

[0074] The hash function described above uses SHA-256 with a 32-bit truncation as an example. In other implementations, SHA-3, SM3 (Chinese national cryptographic standard), or other cryptographic hash functions can be used. The truncation width can be adjusted according to security requirements and storage overhead. (Initial value...) Non-zero preset values ​​may also be used, and none of these constitute a specific limitation on the scope of protection of this application. This mechanism provides an immutable integrity guarantee for the logs stored locally by the sub-lock through the irreversibility and avalanche effect of one-way hashing in cryptography. Even if the sub-lock is physically accessed without supervision, any modification will leave a verifiable and clear trace. Combined with the trusted timestamp verification, it greatly improves the credibility of the logs as judicial evidence, meets the compliance requirements of high-security scenarios such as multi-stage transportation and confidential escort, and helps to ensure the traceability and immutability of the entire business operation log. It provides solid and reliable data support for liability definition, process restoration, and anomaly tracing, and is compatible with the regulatory compliance requirements of high-security transportation businesses.

[0075] Example 7 User-side assisted calibration This embodiment, based on the master lock calibration mechanism of Embodiment 5, adds a user-end auxiliary calibration mechanism as a supplement to the master lock calibration method. It is applicable to local real-time clock maintenance during the period when the sub-lock is not under the management of the master lock. The method to be performed by the master lock specifically includes: reading the calibration source field of the sub-lock; if the calibration source field indicates that it has been calibrated by the user end, then adjusting the expected deviation range verification threshold of the sub-lock in combination with the typical accuracy of the user end calibration link; recording the user end calibration time of the sub-lock; resetting the calibration source field to indicate that it has been calibrated by the master lock after the next active calibration by the master lock, and restoring the original threshold.

[0076] In some application scenarios, the sub-lock may be out of the communication range of the master lock for a long time. For example, in a trailer swapping operation, the trailer (along with its sub-locks) is grouped with another master vehicle (equipped with a different master lock), or the sub-lock is sent to a maintenance center for separate testing. In these scenarios, the periodic calibration of the original master lock cannot cover the sub-lock, and the drift of the local real-time clock will continue to accumulate. If the drift exceeds a certain range, the expected deviation range of the log timestamp after the sub-lock re-enters the network will be too large (see Equation (7)), and the verification sensitivity will be significantly reduced.

[0077] The mechanism for user-side assisted calibration is as follows. The user terminal (e.g., a maintenance personnel's mobile app) obtains the current precise time via the Network Time Protocol (NTP) and establishes a short-range wireless communication connection with the target sub-lock, sending a calibration command. The calibration command carries the following information: the calibrated precise time (user-side network time), a calibration source identifier (identifying "calibrated by user terminal" to distinguish it from "calibrated by master lock"), and an authentication code for the calibration command (calculated based on shared key parameters to prevent forged calibration commands from disturbing the clock; it shares the same key root as the calibration message authentication mechanism in Example 5). After the sub-lock verifies the authentication code, it executes the same two-stage calibration process as the master lock calibration (timestamp pre-sending + timestamp activation), and records "calibrated by user terminal" in the calibration source field. This calibration source field is subsequently read by the master lock along with the logs.

[0078] Here's an example. Sublock S6 was moved with the trailer to another main vehicle, detached from its original master lock M0 for 15 days. During this time, S6's local real-time clock drifted approximately 30 seconds at a rate of 2 seconds per day. On the 10th day, maintenance personnel used a mobile app to perform auxiliary calibration on S6: the app obtained the network time 08:00:00, established a Bluetooth connection with S6, and sent the calibration command "calibrate the clock to 08:00:03.000 in 3 seconds, source = user terminal, authentication code = 0x5A3C"; after S6 verified the calibration, it took effect. At this point, S6's clock was approximately 20 seconds ahead of the accurate time (the drift accumulated in the first 10 days minus the corrected portion), and the calibration brought it back to the accurate reference. S6 recorded the calibration source as "user terminal" and the calibration deviation as +20 seconds. On day 15, S6 was regrouped back into the original master lock M0. During the next calibration, M0 read that the calibration source field of S6 was "user terminal" instead of "master lock". Based on this, it was known that the slave lock had undergone user terminal calibration during the disconnection period. The accuracy of its calibration link (network time → user terminal Bluetooth → slave lock) and the master lock calibration link (satellite / network → master lock Bluetooth → slave lock) may differ (the accuracy of user terminal network time is usually lower than that of satellite time synchronization). Based on this, M0 appropriately relaxed the expected deviation range verification threshold of the slave lock (such as from 10 seconds to 15 seconds) to avoid misjudging the residual difference between different calibration links as timestamp anomalies.

[0079] This embodiment makes the user terminal a supplementary calibration source in the calibration system, filling the clock maintenance gap during the period when the sub-lock is separated from the mother lock, and ensuring that the log timestamps after the sub-lock re-enters the network are still verifiable. The user terminal is not limited to a mobile APP; in other embodiments, it can be a portable calibrator, a vehicle-mounted relay device, or other terminals with network time synchronization and short-range communication capabilities, all of which are specific implementations of the technical solution of this application. Through the user terminal-assisted calibration mechanism, this solution can be adapted to actual application scenarios such as trailer swapping and segmented transportation where the mother and sub-locks are dynamically separated, avoiding the timestamp verification failure caused by the accumulation of clock drift during the separation from the mother lock, further improving the time reliability guarantee system of the entire transportation link, enhancing the robustness of the solution in dynamic networking scenarios, and helping to ensure the timestamp reliability of the sub-lock in any networking state. It avoids the problem of excessive time deviation after a long period of separation from the mother lock, which makes verification impossible, expands the applicable scenarios of the solution, and also reduces the false judgment rate of log anomalies in dynamic separation scenarios, providing more complete support for the log reliability of the entire link and the entire life cycle.

[0080] Example 8: Mother Lock Scan Timing Learning and Prediction This embodiment, based on the adaptive adjustment mechanism of scan duty cycle in Embodiment 1, adds a scan timing learning and prediction mechanism to further reduce the power consumption of invalid scans by the master lock. The master lock execution method specifically includes: maintaining a broadcast timing prediction model for each bound sub-lock; using historical scan success records to linearly regress and fit the actual broadcast period and phase offset of the sub-locks; prioritizing the placement of high duty cycle scan windows near the prediction period of each sub-lock's broadcast when scheduling scan windows; and placing low duty cycle random scan windows during the remaining periods. The scan resource allocation ratio is dynamically adjusted based on the learning confidence of the timing model.

[0081] Example 1 uses random scanning to avoid systematic missed scans. However, when the sub-lock broadcast period is fixed (e.g., 1 second) and the mother lock scan duty cycle is low (e.g., 10%), the mother lock may still scan during periods when the sub-locks are not broadcasting, resulting in invalid scanning overhead. This example adds a temporal learning and prediction layer while maintaining random scanning as a fallback.

[0082] The timing learning mechanism is as follows: The master lock maintains a broadcast timing model for each bound child lock, recording the relative offset between the broadcast timestamps of the child lock's most recent successful scans (16 times in this embodiment) and the master lock's scan timestamps. Since the child lock's broadcast period is driven by the local real-time clock, and the local real-time clock is subject to drift, the actual broadcast interval of the child lock will drift slightly over time—for example, a nominal 1-second broadcast period is actually 1.000023 seconds / scan under a drift rate of 2 seconds / scan, accumulating approximately 1.4 milliseconds of offset per minute. The master lock estimates the actual broadcast period and phase offset of the child lock using linear regression by recording the time intervals between multiple consecutive successful scans, forming a broadcast timing prediction model for that child lock.

[0083] Based on the prediction model, the master lock employs a strategy combining prediction window priority and random fallback when scheduling scan windows: each scan cycle is divided into two parts: a prediction window and a random window. Prediction windows are concentrated near the prediction times broadcast by each sub-lock (e.g., within ±100 milliseconds of the prediction time), while random windows are arranged in a pseudo-random sequence to cover sub-locks that are not modeled or whose models have failed. The scan duty cycle of the prediction window is higher than that of the random window (e.g., 80% duty cycle within the prediction window, 5% duty cycle within the random window), concentrating scan resources on high-probability periods. The time allocation ratio between the prediction window and the random window dynamically adjusts with the learning confidence level: when the model is initially established (low confidence), the random window dominates; after model convergence (high confidence), the prediction window dominates.

[0084] Here's an example. The nominal broadcast period of child lock S5 is 1 second. The mother lock estimates its actual period to be 1.000023 seconds using linear regression from 16 successful scans, with a current phase offset of +0.3 seconds (meaning S5's broadcast time precedes the mother lock's scan time by 0.3 seconds). Based on this, the mother lock predicts S5's next broadcast time and performs concentrated scanning within ±100 milliseconds of the predicted time. After the model confidence reaches 0.8, the time allocation between the prediction window and the random window becomes 8:2. The mother lock's scan hit rate within the prediction window increases from approximately 10% in the purely random method to approximately 70%, while the invalid scan overhead decreases by approximately 60%.

[0085] The temporal learning mechanism is linked to the clock calibration in Example 5: after each calibration of the local real-time clock of the sub-lock, the broadcast phase of the sub-lock will change due to the clock adjustment. When the mother lock detects a sudden increase in the prediction residual, it automatically reduces the confidence level and increases the random window ratio. After accumulating enough scan samples again, the model converges automatically. Thus, the temporal learning mechanism automatically reconstructs after the clock calibration event, without causing persistent prediction failure.

[0086] This embodiment uses time-series learning and prediction to concentrate scanning resources on high-probability periods while maintaining random scanning to ensure no missed scans. This further reduces the power consumption of invalid scans of the master lock. Together with the duty cycle adaptive adjustment mechanism in Embodiment 1, it forms a two-level optimization of macro-intensity adaptation and micro-time-series prediction.

[0087] The number of learning samples (16 times), prediction window width (±100 milliseconds), and confidence threshold (0.8) mentioned above are exemplary parameters. In other implementations, they can be adjusted according to the number of sub-locks, broadcast period, and power budget. The time-series prediction algorithm can also use Kalman filtering or other online learning algorithms. The number of samples, window width, and confidence threshold mentioned above are empirical values ​​under the current configuration and can be adjusted according to the sub-lock size and power budget. This mechanism achieves on-demand and accurate allocation of scanning resources by dynamically fitting the actual broadcast parameters of the sub-locks through historical successful broadcast data. It significantly improves the broadcast discovery efficiency in low duty cycle scanning mode. While ensuring the timeliness of event recognition, it further reduces the power consumption of the mother lock ineffective scanning, enhances the optimization effect of adaptive power management, and helps extend the standby time of the mother lock. It is suitable for low-power vehicle deployment scenarios that rely on the vehicle's own power supply and also supports long-term operation in more offline low-power scenarios. This further expands the applicability of the solution and improves the endurance and operational stability of the mother lock in dynamic networking scenarios with multiple sub-locks.

[0088] (II) Implementation Examples of Methods Applied to Sublocks Example 9: Sublock Log Recording and Status Broadcasting This embodiment provides a method for intelligent multi-terminal collaborative management of sub-locks. This method is applied to sub-locks in an intelligent multi-terminal collaborative management system, which also includes a master lock and a cloud platform. The master lock is communicatively connected to both the sub-locks and the cloud platform. See reference. Figure 2 The method includes steps 201 to 205.

[0089] Step 201: Record the logs generated by yourself and save them locally.

[0090] When the sublock detects unlocking, locking, binding, abnormal alarms, or other events requiring traceability, it generates corresponding logs and saves them locally. Each log entry includes a log category, event details, and a timestamp: the log category indicates whether the log belongs to a rescue event (recording logs of emergency unlocking, forced entry alarms, etc.), an abnormal event (recording logs of abnormal events such as communication anomalies, sensor malfunctions, lock jamming, unauthorized card swipe attempts, etc.), or a routine operation (recording logs of normal unlocking, locking, binding, and unbinding, etc.); the timestamp is determined by the sublock's local real-time clock, and the value of the local real-time clock is read and written to the sublock on the spot at the moment the event occurs, rather than being added afterward, thus eliminating the clock deviation amplification problem during batch writing. The logs can be saved using non-volatile storage media, and are not lost after the sublock is powered off or restarted.

[0091] For example, the sub-lock assigns a global sequence number to each log entry, which is incremented sequentially. That is, for each new log entry, the global sequence number is incremented by 1. The local memory is organized into fixed-length record slots: the log entry with the global sequence number is fixedly stored in the first record slot (after the storage area is full, the record slot is reused according to the hierarchical elimination rule of embodiment 11, and the global sequence number continues to increment without being reset). After the master lock determines the reading range according to formula (2) of embodiment 1, it can directly locate and read in batches according to the record slot address. Moreover, the damage of any record slot only affects a single log entry and does not affect the overall continuity of the log chain.

[0092] For example, at 10:32:15 during transport, the sub-lock S5 is unlocked normally by the on-site operator using an RFID card. A log entry is then generated and saved locally, with the following fields: Log Category = Routine Operation, Event Details = Unlock Source RFID Card / Verification Passed / Execution Successful, Timestamp = 10:32:15, Global Sequence Number = 121 (i.e., the first log entry read by the master lock in step 103 of Example 1). The on-site solidification of the timestamp and the fixed-length recording slot organization also provide physical verifiability for post-event verification: the timestamp is written to the recording slot at the moment the event occurs, rather than being added later, eliminating the possibility of clock deviations being amplified to the entire batch of logs during batch writing; the global sequence number corresponds one-to-one with the recording slot, so if someone attempts to tamper with the content of a log entry, the writing characteristics of its corresponding recording slot will be inconsistent with the preceding and following recording slots. Combined with the hash chain extension in Example 6, a complete anti-tampering evidence chain can be formed.

[0093] Step 202: Periodically send status broadcasts, which do not carry log content.

[0094] Normal operation refers to the daily operating state where no connection is established between the child lock and the mother lock. Status broadcast is a short-frame broadcast signal sent by the child lock to surrounding wireless channels at a fixed period under normal conditions. It carries only status information and no log content. In this state, the child lock only periodically sends status broadcasts at a 1-second broadcast cycle without transmitting log content to the mother lock. The status broadcast frame is short (frame structure detailed in Embodiment 12, total payload only 10 bytes), with a transmission duty cycle of less than one-thousandth. Normal broadcast power consumption is independent of the number of events, and the battery life is measured in years. In contrast, if event content or even log fragments are directly encapsulated into the broadcast frame, the single-frame payload needs to be fragmented and sent multiple times; the more events, the more frequent the broadcast, and the power consumption deteriorates linearly with the number of events. This application compresses the "announcement" to a dozen bytes and leaves the "transfer" to on-demand connections, making normal power consumption essentially independent of the number of events. The status broadcast also carries a checksum, a rolling count value, and a broadcast timestamp for use in the mother lock's anti-replay verification in Embodiment 2 (generation and wraparound mechanisms detailed in Embodiment 10).

[0095] Step 203: When the event triggering condition is met, set a new log flag in the status broadcast. The new log flag includes a priority flag bit. The new log flag indicates that there is a new log in the sub-lock that has not been read by the parent lock.

[0096] The trigger mechanism for adding log tags to sub-locks is based solely on event triggering: the event trigger condition is the generation of an unlock, lock, bind, low battery, or abnormal event, and the corresponding log is saved. The low battery event is one type of event triggering—when the sub-lock detects that its own battery level is below a preset battery threshold, it generates a low battery event and saves the corresponding log. This event shares the same priority fusion mechanism as unlock, lock, and other events, without a separate battery triggering channel, thus avoiding double triggering and repeated descriptions of the same state. In other implementations, event types can be added or removed according to business needs; the above event enumeration and the battery protection priority setting for low battery events are preferred implementations and do not constitute a limitation on the mechanism for setting new log tags.

[0097] Step 2031 (Event Triggering Fusion Value): When the event triggering conditions are met, the value of the priority flag is determined by the sum of the base priority, duration increment, and quantity increment, and does not exceed the upper limit of the value: Equation (9) in, Based on the baseline priority, the events generated are retrieved from the preset event-priority baseline table: 7 for rescue events such as violent damage alarms, emergency unlocking, and rescue calls; 6 for low battery events, which are based on the power guarantee priority—insufficient power directly participates in fusion with a high baseline, ensuring that logs in low battery scenarios receive scheduling priority second only to rescue events; 5 for abnormal events such as communication anomalies, sensor malfunctions, lock jamming, and unauthorized card swiping attempts; and 2 for normal operations such as unlocking, locking, binding and unbinding, and parameter update confirmation. The duration of the earliest unsynchronized record in the log that has not been read by the master lock; The duration increment step is 2 hours in this embodiment; This represents the number of log entries that have not been read. The increment step size is 64 in this embodiment; Indicates rounding down; To set the upper limit of the possible values, this embodiment uses 3-bit encoding. =7, 0 is an unmarked value. The physical meaning of equation (9) is: the more urgent the log, the longer the backlog, and the more backlog there is, the more priority the mother lock should take in reclaiming the log of the child lock. The three factors are linearly superimposed and merged into a unified read priority and capped to prevent overflow of the encoding range. For example, if the child lock S3 detects forced destruction, it queries the baseline table. =7, regardless of the duration and quantity, P=min{7+…,7}=7; Sublock S5 has a backlog of 96 regular unlocking logs, the earliest of which has not been synchronized for 6 hours. —Regular logs with a base priority of only 2 were automatically promoted to 6 after 6 hours and 96 entries, and will not be left unattended for an extended period. For multiple events occurring simultaneously: when multiple events occur sequentially within a broadcast cycle, the event with the highest base priority is used as the... Participate in the fusion process to ensure that the most urgent event always dominates the value selection; for example, if sublock S5 first generates a regular unlock log (baseline 2) and then immediately generates a communication exception log (baseline 5), then according to... =5 fusion, if the duration increment and quantity increment are 1 and 0 respectively, then =min{5+1+0,7}=6.

[0098] In this step, the methods for determining the values ​​based on the baseline priority, duration increment, and quantity increment cover a variety of lower-level implementations: summation (as in equation (9), which is adopted in this embodiment and has been detailed), weighted summation (summing the baseline priority and each increment with different weights, such as increasing the weight of the baseline priority in emergency scenarios), table lookup (looking up the priority table with event category and backlog level as index), and taking the maximum (taking the maximum among the baseline priority and each increment). Taking table lookup as an example: the duration of non-synchronization is divided into three levels: 0 to 2 hours, 2 to 8 hours, and more than 8 hours; the number of non-synchronized records is divided into three levels: 0 to 64, 64 to 256, and more than 256. A lookup table is pre-established to retrieve values ​​from event type, duration level, and number of records. For example, "normal operation, 2 to 8 hours, 64 to 256 records" corresponds to the value 5, and "abnormal event, more than 8 hours, any number of records" corresponds to the value 7. After the sub-lock generates an event and counts the backlog levels, the value is retrieved by looking up the table. No floating-point operations are required, and the computational load is extremely small, making it suitable for sub-locks with limited computing power. In addition, additional factors such as sub-lock power status and lock status can be introduced during the determination process, still within the scope of implementation determined by the baseline priority, duration increment, and quantity increment.

[0099] Step 2032 (Two-level handling of low power events): Low power events are generated using a two-level power threshold classification. When the power level is lower than the first-level threshold (15% in this embodiment), the sub-lock generates a low power event and saves the corresponding log. The baseline priority of this event is the power guarantee priority (6) – even if there are no other log backlogs at this moment (the duration increment and quantity increment are both 0), the result obtained by fusion according to formula (9) =min{6+0+0,7}=6, still can obtain high priority scheduling; if there are other log backlogs at the same time, the duration increment and quantity increment continue to be added on its basis. When the power is further lower than the second level threshold (8% in this embodiment), the sublock generates a serious low power event and saves the corresponding log, whose base priority is the upper limit of 7, and enters the last flush mode: the sublock closes unnecessary sensing and computing loads, concentrates the remaining power for maintaining status broadcast and log provision, and sets the low power alarm indicator bit in the broadcast frame, in conjunction with the immediate interruption and reordering strategy for the highest level broadcast in embodiment 3, to ensure that the log is recycled before the power is exhausted. For example, when the power of sublock S2 drops to 12% (lower than the first level threshold of 15%), a low power event is generated, and the low power alarm indicator bit is set according to formula (9). =6, the mother lock places it in the high position of the connection queue and reads all its unsynchronized logs—the logs were all written to the cloud before the power was exhausted, so even if S2 subsequently stops, the records will not be lost; if the S2 power continues to drop to 7% (below the second-level threshold of 8%), a severe low power event is generated. =7 and enter the final flush mode.

[0100] Step 2033 (Priority Flag Fallback): The priority flag value automatically falls back after the log is fully read and synchronized as confirmed in step 205. After the sub-lock receives the entry confirmation, it re-evaluates the local state. If there are no unread logs and no new events are generated, the priority flag value falls back to the unmarked value of 0 in the next broadcast. If there are still unsynchronized logs, the priority flag is recalculated according to formula (9) based on the remaining logs. The fallback mechanism ensures that the broadcast flag always accurately reflects the state to be reclaimed, and the mother lock does not initiate invalid connections due to historical settings.

[0101] Step 204: In response to the connection initiated by the master lock after recognizing the new log tag, provide the master lock with the unread logs for the master lock to read, disconnect after reading, and summarize and upload the read logs to the cloud platform.

[0102] The child lock receives the connection request initiated by the mother lock based on the tag, establishes a connection with the mother lock, and sends the logs with global sequence numbers greater than the read sequence number pointer carried by the mother lock to the mother lock in the order of global sequence numbers through the connection, so that the mother lock can read only the incremental logs according to step 103 of embodiment 1; after reading is completed, the mother lock disconnects the connection, and the child lock immediately returns to the normal state of only sending state broadcasts, and does not maintain any connection when there are no new logs.

[0103] Step 205: Receive the read confirmation returned by the master lock after successful read, and the database entry confirmation forwarded by the master lock from the cloud platform after successful save. After receiving the database entry confirmation, mark the corresponding log as synchronized.

[0104] Log synchronization adopts a three-level confirmation mechanism: the first level is the master lock read confirmation. The slave lock receives the read confirmation returned by the master lock after successful read (carrying the maximum global sequence number of the successfully read log), and marks the corresponding log as read but keeps it locally; the second level is the cloud platform entry confirmation. After the cloud platform successfully saves the log, the master lock forwards the entry confirmation to the slave lock; the third level is the slave lock synchronization mark. After the slave lock receives the entry confirmation, it marks the corresponding log as synchronized. After that, the log can be eliminated according to the hierarchical strategy of Example 11 when the local storage space is insufficient. Logs that have not obtained entry confirmation will always be marked as pending synchronization. Any abnormality in any link can be recovered: when the read is interrupted, the logs that have not been received will keep the pending synchronization mark and continue to be set. The master lock will continue to read from the pointer according to formula (2); when the confirmation message is lost, the master lock will resend the confirmation in the next connection (the confirmation itself is idempotent). After the slave lock receives it, it completes the marking. The reading side is based on the master lock pointer, the synchronization side is based on the slave lock mark, and the archiving side is based on the cloud entry. Each of the three levels has an authoritative benchmark and does not depend on a single point of state. The following typical abnormal scenarios were verified one by one: Signal interruption during reading – unreceived logs are kept marked as pending synchronization on the sub-lock side, and reading continues from the pointer after reconnection; Power failure and restart of the master lock – the master lock management records are restored from non-volatile memory, and the read but not transmitted portions are re-transmitted according to the cloud database entry sequence number; Power failure and restart of the sub-lock – logs and rolling count values ​​are stored in non-volatile memory, and both the sequence number and count are continued, the judgment criteria on the master lock side are unaffected; In extreme cases, logs have been entered into the cloud database but the sub-lock has not received confirmation for a long time – the batch of logs on the sub-lock side is marked as pending synchronization and continuously set, the master lock judges that reading has been completed according to the pointer, and only resends confirmation without repeating the reading. No loss or duplication occurs in any of the four scenarios.

[0105] The basic process of logging and broadcasting status on the sublock side, as described above, achieves the core effects of no log loss or duplication, dynamic priority adaptation, and consistency of synchronization status through continuous allocation of global log sequence numbers, dynamic fusion of three key elements (priority value, etc.), and a three-level confirmation closed loop. The event-triggered flag setting mechanism ensures no invalid connection overhead under normal conditions. The power consumption of sublock normal broadcasting can usually be reduced by an order of magnitude, which helps to extend the battery life of button battery power supply. This is suitable for the working characteristics of sublocks being disconnected from external power supply for a long time during long-distance multi-vehicle logistics transportation. It ensures that the sublock is always in a connectable and synchronized state during long-term operation, and will not fail to reclaim logs due to premature power depletion. This provides power consumption-level protection for the complete retention of operation logs throughout the entire process.

[0106] Example 10: Check Code Generation Mechanism This embodiment further elaborates on the generation mechanism of the checksum, rolling count value, and broadcast timestamp carried in step 202 of embodiment 9. It defines the generation rules for the broadcast frame field on the sub-lock side. Specifically, the status broadcast also carries a checksum, rolling count value, and broadcast timestamp; the rolling count value increases with each status broadcast and wraps around after reaching the upper limit; the broadcast timestamp is determined by the sub-lock's local real-time clock; the checksum is generated by a pre-agreed checksum algorithm between the sub-lock and the master lock, calculating parameters including its own identifier, priority flag value, rolling count value, and broadcast timestamp.

[0107] Specifically, the rolling count value can be incremented by 1 with each status broadcast, and then wraps around after reaching the upper limit of 65536: for example, the rolling count value of this broadcast is C=0x1A2B, the rolling count value of the next broadcast is C=0x1A2C, and it is incremented to 0xFFFF before wrapping back to 0x0000. The broadcast timestamp is determined by the local real-time clock of the sub-lock, taking the lower 16 bits of the second count, with a wrap-around period of about 18.2 hours. Combined with the counting monotonicity check of formula (3) and the modulus time deviation check of formula (4) in embodiment 2 of the mother lock, it can be correctly checked before and after wrap-around, without the need to carry the absolute time of the full width in the broadcast frame. The check code is calculated and generated by the sub-lock based on the check algorithm agreed upon with the mother lock in advance. An exemplary calculation is expressed as follows: Equation (10) in, The key parameters shared by the master lock and slave locks, distributed via RFID card during system binding; For sub-lock identification, The priority flag is set to a value. This is the rolling count value. For broadcast timestamps, The parameter set version number is indicated by "∥", which means bitwise concatenation. This indicates that the first 16 bits are extracted from the hash output. The physical meaning of equation (10) is: the checksum is a message digest that combines the key with all time-varying parameters and business parameters—an attacker who does not know the key cannot forge a legitimate checksum; the rolling count value increases with each broadcast, and the broadcast timestamp changes over time, so even two broadcasts from the same sublock will have completely different checksums, and intercepted historical broadcast frames cannot be replayed later and pass the parent lock verification; the priority flag value is used in the calculation, and an attacker cannot tamper with the priority value without being detected. For example, the fields of a certain broadcast of sublock S5 are: =0x03A5、 =2、 =6、 =0x1A2B、 =0x2C1F, with Calculate HMAC by truncating the first 16 bits. =0x7C21 is broadcast; the next adjacent broadcast Change to 0x1A2C As it progresses, even Keep it at 6. It is also completely different. It needs to be understood that Equation (10) takes HMAC-SHA256 truncated by 16 bits as an example. Other implementations can adopt lightweight algorithms that combine cyclic redundancy check and key obfuscation, national cryptographic message authentication code algorithms, or other lightweight authentication algorithms. For sub-lock models with extremely weak computing power, a hash function family implemented by table lookup can be used to sacrifice a small amount of security strength in exchange for further reduction of computing power. The algorithm parameters (key, truncation width, polynomial, etc.) of the verification algorithm are uniformly issued by the master lock in the form of a parameter set and support remote updates. The algorithm type identifier and parameters are included in the parameter set management. The master lock can issue them differently according to the sub-lock model. After the update, both parties switch synchronously. Historical intercepted samples are no longer effective for the updated verification. The security strength does not decay with running time.

[0108] The HMAC-SHA256 truncation of 16 bits described above is an exemplary design. In other implementations, SHA-3, SM3 (Chinese national cryptographic standard), or other cryptographic hash algorithms can be used. The truncation width can be adjusted according to security requirements and frame length constraints (e.g., from 8 bits to 32 bits). Key parameters... The rotation cycle can also be flexibly set according to the security strategy, which does not constitute a specific limitation on the scope of protection of this application. The distribution of shared key parameters is completed through the contact channel of the RFID card when the system is bound, without plaintext transmission through the wireless channel, thus avoiding the interception of the key in the air from the source. The above mechanism, through the design of generating a check code by fusing the shared key with multiple parameters, incrementing the rolling count value each time, and dynamically changing the timestamp over time, makes the check code of each broadcast frame unique and unforgeable, eliminating replay attacks and broadcast tampering from the source. Together with the triple verification on the master lock side, it forms a complete broadcast channel security protection system, which is conducive to preventing illegal broadcast frames from misleading the master lock scheduling and forging emergency events to occupy connection resources. It can also prevent attackers from tampering with priority marks to interfere with the normal scheduling process, further ensuring the integrity and authenticity of the status broadcast channel, reducing the risk of malicious attacks interfering with the entire multi-terminal collaborative system, providing real and reliable input information for the connection scheduling and log reading of the master lock, and consolidating the overall security protection boundary of the system.

[0109] Example 11: Cache Endpoint Determination and Tiered Eviction This embodiment adds a cache endpoint value determination and tiered eviction mechanism to the existing embodiment 9. The sub-lock's execution method further includes: when the locally stored logs reach the cache endpoint value, eviction logs are performed according to a tiered strategy; the tiered strategy prioritizes retaining rescue event logs, followed by abnormal event logs, and prioritizes eviction of the earliest recorded regular operation logs; the cache endpoint value is determined based on local storage capacity, log generation rate, and expected offline duration; wherein, the tiered strategy reserves an independent retention quota for rescue event logs, and this independent retention quota is not consumed by the tiered strategy's eviction process.

[0110] The tiered strategy is a method used by sublocks to selectively retain and evict logs based on their category priority when the locally stored logs reach the cache threshold. Its core rule is: prioritize retaining rescue event logs, then exception event logs, and prioritize evictping the oldest regular operation logs. The cache threshold is not a fixed percentage. The cache threshold is the threshold value that sublocks use to determine when local log storage has reached the capacity required to trigger eviction; it is determined based on local storage capacity, log generation rate, and expected offline duration. Equation (11) in, For cached endpoint values, counted in log entries; For local storage capacity (4096 entries in this example); 0.9× The upper limit of the experience ratio is set, and a 10% margin is reserved for memory writing, erasing, and bad block management. The log generation rate is determined based on the number of log entries per hour in historical statistics (in this embodiment, 2 log entries per hour are taken during peak working hours). To estimate the offline duration, the longest lockless recycling period in the transportation scenario is used (in this embodiment, 72 hours is taken for the swapping and long-distance blind zone, which is the same as the scenario parameter of 72 hours offline for S6 in embodiment 4). The physical meaning of equation (11) is: the cache endpoint value is taken as the smaller of the "experienced proportion upper limit" and the "capacity after reserving write space for the estimated longest offline period", which ensures that there is still about 10% physical margin when the eviction is triggered, and that the cache will not overflow after the entire estimated offline period. Calculated according to the parameters of this embodiment: =min{3686,4096-144}=3686 entries. This is the minimum value for the local log. In this scenario, sub-locks are eliminated according to a tiered strategy: rescue event logs are retained first, followed by abnormal event logs, and then the earliest recorded regular operation logs are eliminated first—first eliminating the earliest recorded logs in the regular operation category, and if that's still insufficient, then eliminating the earliest recorded logs in the abnormal event category. Rescue event logs are eliminated last. Furthermore, this embodiment reserves 256 independent retention slots for rescue event logs, which are not encroached upon by the regular elimination process, ensuring the highest survival rate for critical evidence such as violent damage alarms. For example, during a 30-day outage due to a main lock failure, sub-lock S5 accumulates approximately 1440 logs at a rate of 2 logs / hour, which is less than the endpoint value of 3686 logs, so elimination is not triggered. In extreme scenarios, when the cache reaches 3686 logs, the earliest timestamped regular unlocking logs are eliminated first until the cache falls back to a safe level, while rescue event logs are always retained. Therefore, the "complete offline log caching" relied upon by the offline transfer in Embodiment 4 is guaranteed at the storage level by the endpoint value determination and tiered elimination in this step. The two embodiments are interconnected in terms of parameters and logic.

[0111] It should be noted that the independent retention quota is implemented through storage area division: the sub-lock divides the local storage into two parts: a regular cache area and a rescue retention area. The rescue retention area is a dedicated record area allocated according to the independent retention quota (256 items in this embodiment), used only to store rescue event logs. The regular cache area stores all types of logs other than rescue event logs. The tiered eviction process is always limited to logs in the regular cache area. The eviction process does not occupy or erode the rescue retention area—even if the regular operation logs and abnormal event logs in the regular cache area are gradually evictioned to empty, the rescue event logs in the rescue retention area are still completely preserved. When rescue event logs are generated, they are first written to the rescue retention area. The portion exceeding the independent retention quota is then overflowed to the regular cache area in the order of recording time and participates in the regular tiered eviction process. Therefore, in extreme backlog situations (such as cache overflow triggering multiple rounds of eviction after long offline periods), key evidence such as violent damage alarms and emergency unlocking still have the highest survival rate, providing a safety net for subsequent evidence collection.

[0112] The aforementioned storage capacity (4096 records), log generation rate (2 records / hour), and estimated offline duration (72 hours) are exemplary parameters. In other implementations, they can be adjusted according to the sublock storage specifications, operational intensity, and transportation scenario. The independent retention quota (256 records) can also be adjusted according to the historical frequency of rescue event logs. The above capacity, rate, and duration parameters can be set according to the sublock hardware specifications and operational intensity. The aforementioned methods, including dynamic calculation of cache endpoint values, tiered eviction priority strategies, and independent retention areas for rescue event logs, ensure both the log storage capacity for the expected offline duration and the highest survival rate of critical evidence such as forced destruction and emergency unlocking. This provides storage-level reliability assurance for the offline transfer and retransmission mechanism, helps avoid the loss of critical logs due to cache overflow in extreme offline scenarios, ensures the traceability of key operation traces in extreme scenarios, meets the security requirement of retaining core evidence logs even during long-term offline periods in high-security transportation scenarios, further enhances the robustness of the system's evidence-gathering capabilities under extreme conditions, and ensures that sublocks can always retain core evidence data for critical abnormal events regardless of whether storage resources are sufficient, thus safeguarding the final data bottom line for responsibility determination and anomaly tracing.

[0113] Example 12: Broadcast Frame Content and Field Meanings This embodiment further elaborates on the content carried in the status broadcast in step 202 of embodiment 9. It defines the frame structure of the status broadcast and the specific meaning of each field. Each field simultaneously carries three functions: log recycling scheduling, security verification, and status notification. The frame length is strictly controlled within the upper limit of the single-frame payload of Bluetooth Low Energy, eliminating the need for fragmented transmission.

[0114] The status broadcast carries the sublock identifier, lock status, battery level, error code, parameter set version number, priority flag bit, rolling count value, broadcast timestamp, and checksum. An exemplary frame structure, starting from the least significant bit, consists of: frame header (8 bits, taken as a fixed synchronization word); sublock identifier (16 bits, such as 0x03A5 for sublock S5); parameter set version number (4 bits, representing the version of the operating parameter set currently used by the sublock); priority flag bit (3 bits, ranging from 0 to 7, determined according to formula (9) in embodiment 9); low battery alarm indicator bit (1 bit, set to 1 when its own battery level is lower than the second-level threshold, used in conjunction with the highest level value to represent the last flushing mode); rolling count value (16 bits); broadcast timestamp (16 bits, taken as the lower 16 bits of the local real-time clock second count); and checksum (16 bits). All fields total 80 bits, or 10 bytes, which is much smaller than the upper limit of the Bluetooth Low Energy single-frame broadcast payload (31 bytes), and can be fully carried in a single frame without fragmentation.

[0115] A complete example of byte arrangement: In a certain broadcast of sublock S5, the fields are ID=0x03A5, V=2, P=6, low power alarm indicator bit=0, C=0x1A2B, T=0x2C1F, MAC=0x7C21. Then the broadcast payload from the first byte is 0xA5 (frame header), 0x03, 0xA5 (identifier), 0x2C (high 4 bits version number 0010, the following 3 bits priority 110, i.e. 6, the lowest 1 bit low power alarm 0), 0x1A, 0x2B (rolling count), 0x2C, 0x1F (timestamp), 0x7C, 0x21 (checksum), which is exactly 10 bytes.

[0116] The correspondence between the fields within the frame and other mechanisms in this application is as follows: the priority flag is used for sorting and scheduling in Embodiment 3; the rolling count value and broadcast timestamp are used for anti-replay verification in Embodiment 2; the parameter set version number represents the version of the operating parameter set currently used by the sublock. The parameter set is a collection of configuration parameters required for the sublock to operate, including the scan cycle, disconnection threshold calculation parameters, priority fusion step sizes, two-level power thresholds for low power events, verification algorithm parameters, and the encoding version of newly added log markers, etc. The parameter set version number is used by the master lock for version comparison. Upon the next connection, an updated parameter set (including scan cycle, loss threshold calculation parameters, priority fusion step sizes, two-level power thresholds for low power events, and verification algorithm parameters) is distributed. Parameter set distribution employs a dual-zone atomic switching mechanism—the sub-lock parameter storage area is divided into a current zone and a backup zone. New parameters are first downloaded completely to the backup zone and verified as a whole. After successful verification, the roles of the two zones are atomically switched at a predetermined time. If the download is interrupted or verification fails, the current zone remains unchanged, and the sub-lock continues to operate with the old parameters. Any interruption in parameter updates will not cause the sub-lock to enter a state of no parameters or corrupted parameters, avoiding "upgrading to brick." The master lock also distributes parameters in staggered batches according to sub-lock identifiers (e.g., six sub-locks divided into three groups, completed in batches over three days). New and old versions coexist and are compatible at any time. The master lock selects the corresponding parameters for verification based on the version number broadcast by each sub-lock, avoiding instantaneous inconsistencies caused by simultaneous switching of all sub-locks. Among them, the lock status indicates whether the sub-lock is currently locked or unlocked; the power level indicates the current battery level of the sub-lock; the exception code indicates the type of exception detected by the sub-lock, such as communication failure, sensor failure, etc.; the lock status, power level and exception code are used for updating the master lock status table and cloud monitoring, do not participate in log recycling scheduling, and belong to the status announcement fields.

[0117] It should be noted that the aforementioned parameter set channel refers to the channel through which the master lock sends the parameter set and its updated content to the slave lock. This is a short-range wireless connection established on demand between the master lock and the slave lock—the parameter set sending and log reading reuse the same connection without consuming additional communication resources. Parameter updates, such as the temporary energy-saving parameters in Example 13, are all sent through this channel. The aforementioned predetermined time refers to the time when the new parameters take effect, pre-agreed upon by the master lock and slave lock, after the new parameters have been fully downloaded and verified in the backup area (e.g., the next full second after verification or the start of the next broadcast cycle). Upon reaching this time, the slave lock atomically switches the roles of the backup area and the current area in one go. The new parameters in the backup area immediately become the current parameters, and the original current parameters are transferred to the backup area. Since the switch is a single, indivisible action, there is no intermediate state before and after the switch. The master lock and slave lock complete the version switch at the same time, avoiding parsing or verification errors due to inconsistent parameter versions. When the download is interrupted or the verification fails, the original parameters remain unchanged. The current content of the area is never touched during the entire download and verification process, and the sublock continues to operate with the original parameters. When the next connection is re-issued, any interruption in parameter updates will not cause the sublock to enter a state with no parameters or corrupted parameters.

[0118] The above frame structure (field arrangement order and field width) is an exemplary design. In other implementations, the field arrangement order can be adjusted according to the communication standard, and the field width can be adjusted according to management capacity and security requirements (such as extending the sub-lock identifier to 32 bits to support larger-scale deployment). The frame header synchronization word can also take other fixed values, all of which are specific implementations of the technical solution of this application. Through the above-mentioned ultra-short frame design, reuse of three types of functional fields, and dual-zone atomic switching parameter update methods, the normal broadcast transmission duty cycle is less than one-thousandth. A single frame can carry all scheduling, verification, and status information without fragmentation. The parameter update process is risk-free and does not cause downtime. It balances communication efficiency, functional density, and operational reliability, which is conducive to further reducing normal operating power consumption, while ensuring complete functional coverage, meeting the low-power communication requirements of sub-locks, and completing the transmission of multiple types of information without increasing the number of communication times and payload length. It adapts to the long-endurance design requirements of button battery power supply, and also provides a clear and regular input format for the master lock to quickly parse broadcast content and complete scheduling decisions, reducing the parsing calculation load on the master lock side and improving the overall operating efficiency of the scheduling process.

[0119] Example 13 Low Energy Saving Parameters This embodiment, based on the low power event handling mechanism in step 2032 of embodiment 9, adds a low power energy-saving parameter distribution mechanism to further extend the log reclaimability time window of the sub-lock in the low power state. The sub-lock also needs to perform the following methods: after a low power event occurs, it receives temporary energy-saving parameters distributed by the master lock in the next connection. The temporary energy-saving parameters include an extended broadcast period and / or reduced transmission power; it sends a status broadcast according to the temporary energy-saving parameters to reduce power consumption during the log reclamation waiting period; wherein, the temporary energy-saving parameters are distributed through the parameter set channel, and the parameter update of the parameter set channel adopts a dual-zone atomic switching mechanism. The sub-lock parameter storage area is divided into a current area and a backup area. New parameters are first completely downloaded to the backup area and verified, and then switched to the current parameters at a predetermined time; the original parameters remain unchanged when the download is interrupted or the verification fails.

[0120] When a child lock generates a low power event (power level below the first-level threshold of 15%), its priority flag is elevated to the power protection priority (6), and the mother lock will prioritize establishing a connection with it and reading the log in the high-order position of the connection queue. However, before the mother lock completes the reading, the child lock still needs to maintain a normal broadcast cycle (1 second in this embodiment) to ensure that the mother lock can discover and identify its flag. If the child lock's power is extremely low (e.g., dropped to 10%), the overhead of maintaining a 1-second broadcast cycle may shorten its remaining lifespan.

[0121] The low-power energy-saving parameter distribution mechanism works as follows: After the master lock detects a low-power event in a slave lock (with a priority value no lower than the power guarantee priority), it distributes a set of temporary energy-saving parameters to the slave lock during the slave lock's next connection (the same connection for log reading, without initiating additional connections). These temporary energy-saving parameters include: extended broadcast period (e.g., from 1 second to 3 seconds, reducing the transmission duty cycle to one-third of its original value) and reduced transmission power (e.g., from 0dBm to -10dBm, shortening the communication distance but still covering the interior of the carriage). Because the high priority of the low-power event ensures that the slave lock will be read by the master lock first (usually within seconds to minutes), the slave lock can still be detected and its logs can be collected within the short window of the extended broadcast period.

[0122] Temporary energy-saving parameters are sent through the parameter set channel (the dual-zone atomic switching mechanism of Example 12). After receiving the parameters, the sub-lock saves them to the backup area and the atomic switching takes effect. After the sub-lock's power is restored (e.g., by replacing the battery or connecting to a charger), the master lock detects in the next connection that the sub-lock's power has been restored to the normal range (e.g., exceeding 20%), and then sends a command to restore the normal broadcast parameters. The sub-lock then restores its original broadcast cycle and transmission power.

[0123] Here's an example. The button battery of child lock S2 drops to 12% (below the first-level threshold of 15%) one afternoon, generating a low-battery event and raising its priority to 6. The master lock scans S2's broadcast within 3 seconds and recognizes the priority value of 6, placing it high in the connection queue and establishing a connection with S2 within 5 seconds. During this connection, in addition to reading all 12 unsynchronized log entries from S2, the master lock also sends temporary power-saving parameters: the broadcast period is extended from 1 second to 3 seconds, and the transmission power is reduced from 0dBm to -10dBm. S2 receives these parameters and takes effect, subsequently broadcasting at a 3-second interval. If the master lock experiences a 30-minute delay in reading S2's logs due to multiple child locks queuing, S2's broadcast overhead during the waiting period is 30 minutes ÷ 3 seconds = 600 transmissions, only one-third of the normal 1-second cycle (1800 transmissions), saving approximately 66% of transmission power. S2's logs are ultimately collected within 30 minutes under priority scheduling and all are stored in the cloud. Three days later, after replacing the battery in S2, the mother lock detected that the S2 battery level had been restored to 85% during the next connection and then issued a command to restore the normal broadcast parameters. S2 then resumed its 1-second broadcast cycle.

[0124] This embodiment uses a low-power energy-saving parameter mechanism to reduce broadcast power consumption during the waiting period for recycling, while ensuring that low-power sublocks can still be detected in a timely manner and logs can be reclaimed first. This mechanism is connected with the final flush mode (shutting down unnecessary loads) – the final flush deals with extreme scenarios where the power is about to run out, while the low-power energy-saving parameter deals with general scenarios where the power is low but not yet exhausted. Together, they constitute a complete survival strategy for sublocks in low-power states.

[0125] The aforementioned temporary energy-saving parameters (broadcast period extended to 3 seconds, transmission power reduced to -10dBm) and gradient adjustment step size (adjusted by one level for every 3% decrease in power) are exemplary parameters. In other embodiments, the range of values ​​for energy-saving parameters and gradient step size can be adjusted according to the sub-lock hardware specifications and communication distance requirements. The dual-zone atomic switching mechanism can also adopt other atomic update strategies, all of which are specific implementations of the technical solution of this application.

[0126] Based on the above mechanism, as an optional implementation, the master lock can dynamically adjust the intensity of energy-saving parameters according to the current power level reported by the slave lock. Specifically, the master lock reads the current power value of the slave lock in each connection and determines the corresponding broadcast period and transmission power according to a preset gradient mapping relationship—for every preset step size (e.g., 3%) decrease in power, the broadcast period is extended by a preset increment (e.g., 1 second), and the transmission power is reduced by a preset level (e.g., 3dBm), until their respective upper and lower limits are reached. This gradient adjustment mechanism ensures that the slave lock maintains a smooth dynamic balance between broadcast discoverability and power saving as the power gradually decreases from the first threshold to the second threshold, avoiding broadcast interruptions or sudden drops in discoverability caused by parameter mutations. Each parameter switch is completed through an atomic switching mechanism of the parameter set channel, ensuring the atomicity and rollback of the adjustment process.

[0127] The above embodiments, through methods such as forced priority elevation of low-power events, dynamic distribution of temporary energy-saving parameters, and gradient adjustment of broadcast period and transmission power, can significantly reduce broadcast power consumption during the waiting period for recycling while ensuring that low-power sub-locks can be detected in a timely manner. This forms a complete survival strategy in low-power scenarios with the final flush mode, extending the log recycling time window, which is conducive to extending the survival time of sub-locks in low-power states, further improving the log recycling success rate, avoiding premature power depletion that would cause critical logs to fail to synchronize, consolidating log retention guarantees in low-power scenarios, adapting to application scenarios where sub-locks are not powered by external power for a long time, and making the log traceability capability under button battery power supply more robust.

[0128] Example 14: Sublock Log Entry Compression and Difference Synchronization This embodiment, based on the log recording mechanism of Embodiment 9, adds a log entry compression and differential synchronization mechanism to reduce connection time and storage consumption in high-frequency event scenarios. The sub-lock uses incremental differential compression to store consecutive log entries of the same type locally, retaining only the difference field between the first complete entry and subsequent entries. The compression ratio increases with the repetition of events (up to more than ten times in the case of consecutive similar events). After establishing a connection with the sub-lock, the master lock first queries the current compressed block identifier and differential baseline sequence number of the sub-lock, and only transmits differential segments that exceed the synchronized baseline of the master lock, without transmitting complete log blocks. The amount of synchronized data is significantly reduced with the repetition of events.

[0129] In high-frequency operation scenarios such as port container management and turnover container circulation, sublocks may generate a large number of similar logs in a short period of time (such as multiple consecutive normal unlocking and closing). These logs have highly similar log categories and event details, differing only in timestamps and global sequence numbers. Transmitting such similar logs one by one would consume a lot of connection time, while storing them one by one would also accelerate the filling up of local storage.

[0130] The log entry compression mechanism is as follows. When writing logs, the sub-lock detects consecutive similar logs: when multiple consecutive logs meet the following conditions—same log category, same key fields in the event details (e.g., same unlock source, same verification result, same execution result), and the timestamp interval between two adjacent logs does not exceed a preset interval threshold (60 seconds in this embodiment)—the sub-lock compresses this group of consecutive similar logs into a single summary entry. The summary entry includes: log category, event details template (shared key fields), start and end global sequence numbers, start and end timestamps, entry count (i.e., the number of original log entries compressed), and a summary hash value (a hash value calculated over all original log content, used for post-event verification). Summary entries are distinguished from ordinary entries by a compression flag in the log category.

[0131] When the master lock reads a summary entry, it processes it in two modes. First, summary mode: the master lock directly reads and uploads the summary entry. The cloud platform stores the summary instead of each original log entry. This is suitable for scenarios where only frequency and time range statistics are needed, without needing to trace each entry individually (such as daily door opening and closing records in a warehouse). Second, expanded mode: when reading a summary entry, the master lock requests expansion from the child lock. The child lock sends all original logs corresponding to the summary entry in global sequence order. This is suitable for scenarios requiring traceability (such as needing to review detailed records after a security incident). The master lock selects the mode based on the log category and business strategy: routine operation logs use summary mode by default, while rescue event logs and abnormal event logs are forced to use expanded mode.

[0132] Summary entries and regular entries maintain consistent global sequence number allocation: a summary entry occupies the global sequence number of its first original log entry, and the sequence numbers after the global sequence number of its last original log entry are allocated to the next log entry. The read sequence number pointer of the master lock advances according to the last global sequence number of the summary entry, without creating sequence number gaps due to compression.

[0133] Here's an example. In a port yard scenario, sub-lock S3 is continuously unlocked and locked 12 times within one hour. Each unlock originates from the same RFID card, passes verification, and is executed successfully, with each adjacent interval not exceeding 60 seconds. The sub-lock compresses these 12 log entries into a single digest entry: the log category is "Regular Operation" (compression marker 1), the event details template is "Unlock origin: RFID card / Verification passed / Execution successful," the start and end global sequence numbers are 78 to 89, the start and end timestamps are 14:02:15 to 14:12:00, the entry count is 12, and the digest hash value is 0x3B7F. After reading this digest entry, the master lock uploads it to the cloud in digest mode, reducing the connection time from approximately 0.7 seconds for transmitting 12 entries one by one to less than 0.1 seconds for transmitting a single digest. If any abnormal events are found around 14:10 that require backtracking, the master lock reconnects to S3 in expanded mode and requests to expand the summary entries with global sequence numbers 78 to 89. S3 sends the 12 original logs one by one, and the master lock uploads them to the cloud for detailed tracing.

[0134] This embodiment reduces connection time by an order of magnitude in high-frequency event scenarios through log entry compression and differential synchronization, while also slowing down the write speed of local memory. Together with the cache endpoint value mechanism in embodiment 11, it forms a dual storage guarantee of compression and graded eviction.

[0135] The aforementioned interval threshold (60 seconds) and compression mode selection strategy (default summary for regular operations, forced expansion for rescue events) are illustrative examples. In other implementations, the interval threshold can be adjusted according to the work rhythm, and the compression mode can be flexibly configured according to business strategies. The aforementioned threshold and mode arrangement are merely one feasible work convention. By using the aforementioned continuous log incremental compression and adaptive switching between summary and expansion modes, connection time can be reduced by an order of magnitude in high-frequency operation scenarios, while delaying the local memory from filling up. This, combined with the hierarchical elimination mechanism, forms a dual storage optimization of compression and retention, which helps reduce the connection time overhead between the master lock and the slave lock, alleviates the transmission pressure caused by a large number of similar logs in a short period of time, reduces local storage occupation, and extends the offline work duration that the slave lock can carry. This ensures complete traceability when necessary, and reduces the storage and transmission burden of normal operation through on-demand compression, further improving the capacity elasticity of slave lock offline operation and providing efficiency guarantees at the storage and transmission levels for stable operation of slave locks in multiple scenarios.

[0136] (III) System Implementation Examples Example 15 System Example This embodiment provides an intelligent multi-terminal collaborative management system. (See also...) Figure 3The intelligent multi-terminal collaborative management system 300 includes a master lock 310, multiple child locks 320, and a cloud platform 330. The master lock 310 is communicatively connected to each child lock 320 and the cloud platform 330. Each child lock 320 records its own generated logs and saves them locally. It periodically sends status broadcasts without log content and, when an event trigger condition is met, sets a new log marker with a priority flag in the status broadcast. The new log marker indicates that there are new logs on the child lock's local machine that have not been read by the master lock. It responds to connections initiated by the master lock 310 by providing unread logs and, upon receiving read confirmation and data entry confirmation, marks the corresponding log as synchronized. The master lock 310 scans the status broadcasts of each child lock 320 with a scan duty cycle that adjusts with the size of the data to be read and increases with the increase in the size of the data to be read. When a new log marker is identified from the status broadcast, the master lock 310 updates the status. The broadcast carries a verification code for verification. When the verification passes, the sub-lock 320 that sent the status broadcast is identified as the sub-lock to be read. Connections are established with the sub-locks to be read in descending order of reading priority indicated by the priority flag. Incremental logs are determined from the new logs based on the already read records, and only incremental logs are read. After successful reading, a read confirmation is returned to the corresponding sub-lock 320. After reading is completed, the connection is closed, and the read incremental logs are summarized and uploaded to the cloud platform 330. The database entry confirmation returned by the cloud platform 330 after successful saving is forwarded to the corresponding sub-lock 320. The scale of the data to be read is determined based on the number of sub-locks that have identified the new log flag and / or the number of new logs. The already read records are used to represent logs that have been successfully read by the master lock. The cloud platform 330 is used to save the incremental logs uploaded by the master lock 310, and the master lock 310 forwards the database entry confirmation to the sub-lock 320.

[0137] Based on the above embodiments, the master lock 310 and each slave lock 320 can establish a connection through short-range wireless communication. Short-range wireless communication refers to wireless communication methods with a communication distance of tens of meters or less, including but not limited to Bluetooth, Bluetooth Low Energy, Zigbee, or other low-power wireless communication methods. This embodiment uses Bluetooth as an example. The master lock 310 and the cloud platform 330 can establish a connection through wide-area communication. Wide-area communication includes communication methods such as cellular networks, Wi-Fi, or Ethernet. This embodiment uses cellular networks as an example, forming a three-level hierarchical relay architecture of "slave lock 320 → master lock 310 → cloud platform 330". The slave lock 320 is powered by a button battery and integrates a short-range wireless communication module, an RFID module, a lock body control circuit, a local real-time clock, and a local storage with a capacity of 4096 logs. It does not require a wide-area communication module or a satellite positioning module. The master lock 310 integrates a short-range wireless communication module, a wide-area communication module, a satellite positioning module, and a rechargeable lithium battery. The cloud platform 330 is deployed on a remote server and provides management functions such as status monitoring, remote lock opening and closing control, transportation trajectory monitoring, and data analysis. Under this architecture, the sub-lock 320 executes the sub-lock side method steps described in Examples 9 to 14, and the mother lock 310 executes the mother lock side method steps described in Examples 1 to 8. The steps on both sides are connected as a complete collaborative link through status broadcasting and on-demand connection. This example focuses on describing the deployment form and overall operation process of the system.

[0138] See Figure 4 In one specific embodiment, the system includes a master lock (M0) and six sub-locks (S1 to S6, deployed on the six doors respectively) connected to the master lock, a cloud platform, an environmental sensing node (an independent Bluetooth temperature and humidity sensor E0, deployed inside the carriage), a user terminal (mobile APP), and an RFID card. The RFID card and user terminal are connected to the master lock and each sub-lock respectively, while the environmental sensing node only communicates with the master lock. The information transmission relationship is as follows: the cloud platform communicates bidirectionally with the master lock via a 4G network to upload logs and issue remote commands; the master lock communicates bidirectionally with each sub-lock via Bluetooth to perform status scanning, log reading, and unlocking control; the user terminal communicates bidirectionally with both the master lock and each sub-lock via Bluetooth to view status, control unlocking, and configure parameters; the environmental sensing node broadcasts environmental parameters unidirectionally to the master lock via Bluetooth; and the RFID card interacts with the master lock and each sub-lock via card swiping to perform binding operations and unlocking.

[0139] Overall system operation process: (1) Deployment and Binding. The master lock is swiped with an RFID card, and the master lock writes its certificate information to the RFID card. The master lock certificate information includes the master lock identifier and the shared key parameters generated by the master lock. Then, the same RFID card is used to swipe each sub-lock in turn. The sub-lock reads and verifies the master lock certificate information. After successful verification, it saves the master lock identifier and the shared key parameters and sends a binding broadcast containing the sub-lock certificate information. After scanning the binding broadcast, the master lock verifies the sub-lock certificate information. After successful verification, it establishes a Bluetooth connection with the sub-lock, adds the sub-lock identifier to the local bound list, and sends a confirmation command to the sub-lock until all bindings from S1 to S6 are completed. The RFID card, as a physical credential, avoids remote misbinding and malicious binding. The shared key parameters are distributed via a contact channel and transmitted in plaintext via a wireless channel, providing a key basis for the check code calculation in Example 10. After binding is completed, the master lock establishes a management record for each bound sub-lock (read sequence number pointer, uploaded sequence number level, recently verified rolling count value, recently calibrated deviation record, and continuous verification failure count, all initially zero or empty). After binding, the system supports three unlocking entry points: RFID card unlocking—the target lock reads the RFID card and verifies the card's identifier and key; if verification is successful, unlocking is executed. Bluetooth unlocking—the user terminal establishes Bluetooth communication with the target lock and sends an unlocking command carrying the unlocking password; if verification is successful, unlocking is executed, or an unlocking control command is sent from the master lock to the slave lock. Platform remote unlocking—the cloud platform sends an unlocking command to the master lock via the network, and the master lock executes unlocking or sends an unlocking control command to the slave lock. After the lock executes unlocking, the source of unlocking, verification result, execution result, and time information are recorded in the log. This log becomes the object of step recording in Example 9 and is uploaded through the aforementioned recycling link, realizing centralized traceability of each unlocking behavior.

[0140] (2) Normal collaborative operation. Each sub-lock executes steps 201 to 203 of Example 9: record logs and assign global sequence numbers, send short status broadcasts without log content at 1-second intervals, and determine the priority flag value and generate a verification code according to formula (9) when triggered by events such as unlocking, locking, binding, low power or abnormal events; the mother lock executes steps 101 to 104 of Example 1: scan the broadcasts of each sub-lock and the environmental sensor node according to formula (1) with adaptive duty cycle, identify new log flags and verify them according to the triple criteria of Example 2, establish connections according to priority sorting and exponential backoff according to Example 3, read incrementally with pointer according to formula (2) and disconnect immediately after reading, and summarize and upload to the cloud platform after deduplication. After scanning the broadcasts of the environmental sensor node, the mother lock maintains the environmental snapshot cache locally, and associates the most recent environmental snapshot with each log according to the time alignment rule when summarizing and uploading: ,and Equation (12) in, The timestamp of the log; The moment a snapshot of the environment is recorded; This means taking the minimum value between the cached snapshot and the log timestamp; To align the threshold, this embodiment uses 30 seconds (consistent with the broadcast cycle of the sensor node). For example, the unlocking log timestamp of sub-lock S5 global serial number 121 is 10:32:15, and the temperature in the environmental snapshot cache at 10:32:10 is -18.3℃. According to formula (12), the time difference is 5 seconds and does not exceed 30 seconds. The snapshot is associated with the log, and the cloud platform presents the complete context of "the temperature of the carriage at the time of unlocking is -18.3℃". When the environmental parameters associated with the log exceed the preset environmental range (such as the cold chain range [-20℃, -16℃]), the mother lock adds an environmental abnormality mark to the corresponding log and uploads it with the log. The cloud triggers a joint alarm of "unlocking occurred during the temperature limit". The environmental perception and the lock hardware are decoupled, and the log and the environment corroborate each other. The number and type of environmental sensor nodes can be expanded according to monitoring needs without changing the alignment rules: For example, two temperature and humidity nodes and one vibration node at the bottom of the box are deployed in the front and rear of the 40-foot refrigerated box. After alignment, the log can carry multiple snapshots of "front end -18.4℃, rear end -17.9℃, vibration 0.3g" at the same time. When the temperature difference between the front and rear ends exceeds the gradient threshold, the main lock adds an abnormal temperature gradient indicator in the box to indicate a cold air circulation failure. When the vibration amplitude exceeds the vibration threshold, the main lock adds a vibration abnormality indicator to the log in the same window. If there happens to be a rescue event log in the same window, the triple evidence of "vibration evidence + alarm log + timestamp cross-verification" corroborates each other and forms a complete chain of evidence for the damage event.

[0141] (3) Handling of abnormal and extreme scenarios. For signal blind spots (the main lock and the cloud are disconnected), the main lock is cached locally and the transmission is resumed in sequence after the network is restored; for the sub-locks are disconnected (such as being disconnected by a hook-up), the main lock is judged to be offline and reported according to Example 4, the priority of the sub-lock is automatically increased, and the rescue is prioritized for retransmission after re-entering the network; for low power (the sub-lock power is lower than the threshold), the priority is forcibly increased or the last flush mode is entered according to step 2032 of Example 9, and temporary energy-saving parameters are issued according to Example 13 to reduce the broadcast power consumption during the waiting period for recycling, and the log is recycled before the power is exhausted; for broadcast attacks (forgery or replay), all are intercepted before connection according to the triple criteria of Example 2 and a security event log is generated and reported; for timestamp abnormalities, the expected deviation range is checked and cross-verified according to Example 5 to identify and mark the double defense line. A whole operation example of a transportation day is given to verify the numerical consistency of each mechanism: the loading is completed at 7 am, each of the six sub-locks generates a locking log and sets it, and the duty cycle of the main lock is according to formula (1) =6 rises to 40%, scan recognition and triple verification are completed within seconds, connections are established in turn according to priority, all lock logs are read incrementally according to formula (2) and uploaded, each connection is disconnected after reading, each time less than two seconds, after the warehouse is confirmed to be forwarded by the mother lock, the sub-locks are marked as synchronized, the mark bit falls back to 0, the mother lock duty cycle falls back to 10% silent mode; at 12 noon, the sub-lock S2 power drops to 12%, according to formula (9) the bit is forcibly set to 6 (low power is not recorded repeatedly as an event type), the mother lock reclaims all its logs with high priority, and the cloud reminds to replace the battery; at 18:00 in the evening, the sub-locks S3 and S5 are opened, vibration and Temperature exceeding the limit caused the mother lock to add a double environmental anomaly flag to the same window log, triggering a joint alarm in the cloud; at 23:00 at night, someone replayed the legitimate broadcast frame of S5 during the day, and the mother lock judged that the count was not monotonic and the timestamp exceeded the window according to formula (3) (4), and generated a security event log to report after intercepting 8 times in a row. No connection was initiated throughout the process, and then the broadcast with the fake S3 flag was intercepted by the recalculation check code criterion; the next morning, the destination was reached, and all logs were completely stored in the database. The mother lock used the last read connection to complete the distribution of the new parameter set to the old version of the sub-lock in three groups at different times. The key rotated with the parameter set, and all broadcast samples intercepted at night were invalidated from then on. Throughout the transportation day, the power consumption of the six sub-locks in normal broadcast was constant, the total connection time of the mother lock was less than one minute, and there was no log loss, duplication or timestamp misjudgment throughout the process.

[0142] Based on the above operation, the improvement effect of this embodiment can be quantified as follows. In terms of power consumption: Under normal conditions, the RF transmission duty cycle of each sub-lock is less than one-thousandth, which is more than an order of magnitude better than the "broadcast directly carries log content" route (transmission duty cycle increases linearly with the number of events) and the "maintain long connection" route (connection maintenance current is continuous). The button battery life is measured in years. In terms of management capacity: Assuming the average duration of a single incremental read connection is 2 seconds and the arrival rate of the entire system log event is once per minute, the occupancy rate of the master lock connection channel is only about 3.3%; even if fifty sub-locks are running simultaneously and the arrival rate of the entire system event is increased to 5 times per minute, the occupancy rate is still less than 20% - while the long connection scheme is subject to the hard limit of the number of concurrent connections of the master lock (typically single digits to more than ten for Bluetooth), and the management capacity has an insurmountable upper limit. The difference between the two in terms of capacity mechanism is order of magnitude and structural. In terms of security: Forgery and replay broadcasts are intercepted by triple criteria before the connection is established, increasing the attack cost from "forging a single flag" to "breaking the message authentication key and forging monotonic counts and valid timestamps," and key rotation periodically invalidates historical intercepted samples. In terms of evidentiary capabilities: Timestamp verification granularity reaches the second level, and it possesses a dual defense line of single-lock anomaly detection and multi-lock mutual verification. Environmental evidence and log events are aligned and bound along the timeline, providing a complete chain of evidence for cold chain cargo damage disputes.

[0143] The aforementioned system architecture (three-tiered relay of master lock, slave lock, and cloud platform) and the division of modules are exemplary designs. In other implementations, the system architecture can be flexibly adjusted according to the deployment scenario (such as adding edge computing nodes, relay devices, etc.), and the division and functional allocation of each module can also be reset according to hardware capabilities and business needs. None of these constitute a specific limitation on the scope of protection of this application. The aforementioned three-tiered relay architecture, through the design of reducing slave lock hardware costs, reusing master lock capabilities, and unified cloud management, can significantly reduce the overall hardware cost of the system. The number of slave locks that a single master lock can manage is greatly increased. The core mechanism achieves simultaneous optimization of power consumption, cost, capacity, and security in four dimensions through full-link collaboration, which has outstanding structural advantages over existing technologies.

[0144] Example 16 Remote Permission Management This embodiment, based on the system architecture of Embodiment 15, adds a remote access control mechanism, enabling changes to unlocking permissions to be completed remotely via the cloud platform or user terminal without requiring personnel to physically access the locks. This mechanism employs a three-tier architecture: cloud configuration, master lock relay, and sub-lock verification. Permission change requests are initiated by the cloud platform or administrator user terminal. After authentication, an encrypted permission token with an expiration date and operational scope is generated and distributed to the corresponding master lock via a wide-area link. The master lock caches the permission token in its local permission list and distributes it along with the connection request when the corresponding sub-lock's status is subsequently scanned and broadcast. The sub-lock has a built-in independent permission verification module that performs triple verification on the token's signature, expiration date, and operational scope. Upon successful verification, the local permission whitelist is updated, taking effect without requiring a restart. Throughout the entire process, the permission token is end-to-end encrypted. The key is pre-negotiated between the sub-lock and the cloud, and the master lock only acts as a transparent relay, unable to tamper with the permission content, thus balancing the convenience of remote operation with the security of permission changes.

[0145] The core workflow for remote access control is as follows: the cloud platform or user terminal generates an access update command, which is forwarded from the master lock to each sub-lock. The sub-locks save the command and send a confirmation receipt. The master lock then summarizes the confirmation results and reports them to the cloud platform. The access update command includes at least one of the following: an updated RFID card identifier list and a Bluetooth unlocking password. Updating the RFID card identifier list is used to add or remove cards that can be unlocked (e.g., removing lost cards or authorizing new cards). Updating the Bluetooth unlocking password is used to change the authentication credentials for Bluetooth unlocking (e.g., emergency replacement after password leakage). The access update command is issued via an on-demand connection between the master lock and sub-locks, reusing the aforementioned incremental reading connection channel without consuming additional communication resources.

[0146] The specific processing flow consists of three stages. The first stage is command issuance: the cloud platform sends the permission update command to the master lock, which caches the command and forwards it to each child lock individually upon the next connection is established. For child locks with no new logs (not set), the master lock proactively initiates a short connection to forward the permission update command after the next scan of the child lock's status broadcast; the connection is immediately closed after completion. The second stage is child lock confirmation: after receiving the permission update command, the child lock saves it to the permission area in non-volatile memory and returns a confirmation receipt to the master lock (carrying the child lock identifier and command version number). Child locks for which the master lock has not received a confirmation receipt are added to the resend list and resent upon their next connection until all are confirmed. The third stage is result reporting: the master lock summarizes the confirmation results (confirmed / pending resend) of all child locks and reports them to the cloud platform. The administrator can verify the permission status of each lock on the cloud platform.

[0147] Here is a complete example. A cold chain transport fleet has 6 vehicles, each equipped with one master lock and six slave locks. The fleet has a total of 30 RFID cards distributed to drivers and loaders. One day, the driver accidentally lost the RFID card with card number 0x03F2. The administrator performed the following operations on the cloud platform: (1) Select all 36 locks of the 6 vehicles as targets and generate an access update command - remove card number 0x03F2 from the RFID card identification list and increment the command version number to V=5; (2) The command is sent to the 6 master locks via the 4G network; (3) Each master lock forwards the command in the next connection with its respective sub-locks on the same day. For example, the connection between M0 and S1 was only used for log reading before the access forwarding. This time, the access update command is sent in the same connection. S1 saves and returns a confirmation receipt; (4) At 18:00 on the same day, all 36 locks are confirmed to be effective. The master locks summarize the confirmation results and report them to the cloud; (5) The administrator sees the status "36 / 36 confirmed" on the platform and confirms that the lost card is invalid in the entire fleet. If a sub-lock fails to confirm its offline status (e.g., S6 is detached during a swap), the main lock will add it to the list of locks awaiting reissue. Upon S6's first reconnection after re-entering the network, the permissions will be updated, and the lost card will become invalid on that sub-lock. The entire process requires no human contact with any locks, and the time from the administrator discovering the loss to the entire team becoming invalid will not exceed one business day.

[0148] This embodiment improves the timeliness of lock access changes from "personnel on-site configuration for each lock" to "remote batch immediate effect" through a remote access control mechanism. This is particularly suitable for emergency scenarios requiring immediate handling, such as lost cards or leaked passwords during transportation, as well as for unified access changes for large batches of locks (e.g., driver resignation or customer change). Access update instructions are not limited to RFID card identifier lists and Bluetooth unlocking passwords; in other implementations, they may include updates to biometric templates, digital certificates, or other authentication credentials, all of which are specific implementations of the technical solution in this application. The aforementioned cloud-based encrypted token generation, transparent transfer via the master lock, and local verification by the sub-locks provide end-to-end encryption, balancing operational convenience and access security. This improves management efficiency in large-scale multi-lock network scenarios, reduces the manpower and time costs of access changes, and provides a more flexible and secure solution for smart lock management in the logistics and transportation sector.

[0149] Example 17 Multi-scenario Deployment Based on the system architecture of Example 15, this embodiment illustrates the deployment methods and parameter adaptation of the intelligent multi-terminal collaborative management system in various scenarios beyond fleet cold chain transportation. Adhering to the design principles of core mechanism reuse and parameter adaptation adjustment, this embodiment provides deployment architectures, parameter configuration schemes, and practical application examples for three typical multi-terminal collaborative scenarios, enabling rapid adaptation to different industry needs without modifying the underlying system protocol and hardware design.

[0150] The first scenario is warehouse management. In large warehouse parks, master locks are deployed at warehouse management nodes (such as guard rooms or management offices at warehouse entrances), while slave locks are deployed at warehouse doors, shelf cage doors, or doors of valuable goods cabinets. Environmental sensor nodes are deployed inside each warehouse to collect temperature and humidity data. Parameter adaptation: the broadcast cycle can be extended to 3 seconds (warehouse scenarios have lower requirements for detection latency, and slave locks can further reduce power consumption); the upper limit of the scan duty cycle can be reduced to 30% (the master lock is powered by mains electricity, but the slave locks are still powered by batteries); parameters for calculating the disconnection threshold. The time limit can be extended to 60 seconds (in a warehousing environment where the sub-locks do not move and the probability of loss of connection is low, the judgment can be relaxed). Specific deployment example: A warehousing park has 8 warehouses, each warehouse door is equipped with one sub-lock (8 in total), and the rack cage doors are equipped with 12 sub-locks, for a total of 20 sub-locks managed by one master lock; environmental sensor nodes are deployed inside each warehouse (8 in total) to collect temperature and humidity data for monitoring the storage environment of cold chain pharmaceuticals or precision electronic devices. Administrators can remotely monitor the opening and closing status of each warehouse door and environmental parameters through a cloud platform. Any abnormal unlocking (unauthorized time period or unauthorized card) will trigger an alarm.

[0151] The second scenario is port container management. In a container yard, the master lock can be deployed at the yard management node or moved with the container fleet management vehicle, while the sub-locks are deployed on the doors of each container. Parameter adaptation: the broadcast cycle is maintained at 1 second (frequent port operations and numerous unlocking events require rapid retrieval); the priority flag can use 4 bits (high port security levels require differentiation of more emergency levels); the checksum width can be extended to 32 bits (enhanced anti-counterfeiting). Specific deployment example: A yard manages 50 refrigerated containers, each door equipped with a sub-lock (a total of 50 locks, close to the maximum capacity of a single master lock), all centrally managed by a master lock deployed in the yard office. Environmental sensor nodes are deployed inside 5 representative containers to collect internal temperature data for cold chain monitoring. The master lock uploads logs to the terminal management platform via a 4G network, enabling centralized monitoring of door status, unlocking records, and environmental parameters.

[0152] The third scenario is the management of turnover boxes. In urban distribution or pharmaceutical cold chain turnover box scenarios, master locks are deployed at various turnover centers (such as distribution centers and forward warehouses), and sub-locks move between centers with the turnover boxes. Parameter adaptation: the broadcast cycle can be shortened to 0.5 seconds (fast turnover pace requires rapid detection); the disconnection threshold can be shortened to 30 seconds (small turnover center area, normal rapid network access is required). Specific deployment example: A pharmaceutical distribution company deploys 3 master locks at 3 turnover centers, with 200 insulated turnover boxes each equipped with a sub-lock. After the turnover box is loaded with medicine at center A, it is locked, transported via trunk line to center B, unlocked at B, and distributed to various end-point distribution points. The sub-lock generates a locking log when it locks at A and an unlocking log when it unlocks at B. The logs are collected by the master lock and uploaded to the cloud. Environmental sensor nodes are integrated into the inner lid of the insulated box to collect the internal temperature, which, together with the unlocking log, constitutes an evidentiary record of the "internal temperature of the box at the time of unlocking". If a customer complains that the medicine has deteriorated, the cloud platform can retrieve the temperature curve and unlocking records of the entire container to verify whether there was any unauthorized opening or temperature loss during transportation.

[0153] In the three scenarios described above, the core mechanisms such as broadcast tag-driven on-demand log recycling, triple replay protection, priority scheduling, incremental reading, timestamp verification, and relay transmission are all fully reused. Only the deployment location and parameter values ​​need to be adjusted to quickly achieve multi-terminal status monitoring and reliable end-to-end log traceability in the corresponding scenarios. This technical solution can also be deployed in various multi-terminal collaborative scenarios such as medicine cabinet management, smart mailboxes, shared equipment lock control, fleet transportation, warehouse management, port containers, and turnover box circulation. The implementation of these scenarios can be directly obtained through the combination and parameter adaptation of the aforementioned embodiments, and will not be listed individually. Through the design of core mechanism reuse and dynamic parameter set adaptation, scenario adaptation can be completed without modifying the underlying protocol and hardware. Only parameters such as broadcast period, duty cycle, and checksum width need to be adjusted to achieve optimal configuration, demonstrating strong versatility and scalability. This helps reduce the adaptation and development costs of multi-terminal collaborative lock control systems, quickly respond to customized needs in different industries, reserve sufficient design space for future expansion of new application scenarios, and promote the large-scale application of intelligent lock control management technology in more fields.

[0154] Example 18: Joint Solidification of Evidence Packages This embodiment, based on the environment alignment and joint alarm mechanism of embodiment 15, adds an evidence package joint solidification mechanism to provide a complete set of cryptographic endorsements for key events involving cargo damage disputes.

[0155] The triggering conditions for the joint solidification of evidence packages are: the main lock reads the log of a rescue event (such as a violent destruction alarm or emergency unlocking), or detects a scenario in the same window that requires the joint solidification of multiple sources of evidence, such as an environmental limit violation or abnormal vibration. When the triggering conditions are met, the main lock will bundle the following records in the same time window into an evidence package: (1) the log of the triggering event itself (including timestamp, global sequence number, and event details); (2) the relevant logs of other sub-locks in the same window (such as the unlocking logs of each sub-lock when multiple doors are opened at the same time); (3) the environmental snapshot in the same window (temperature, humidity, vibration, etc.); (4) the location record of the main lock (latitude and longitude and timestamp of the satellite positioning module).

[0156] The joint hash is calculated as follows: all records in the evidence package are arranged in a fixed order (global sequence number ascending, environment snapshots and location records in timestamp ascending). The key fields of each record (sequence number, timestamp, event type, and key parameter value) are concatenated sequentially, and a hash function (such as SHA-256, truncating 64 bits) is calculated on the whole to obtain the joint hash value. The joint hash value is uploaded to the cloud platform for storage along with the evidence package.

[0157] Here is a complete example. A refrigerated truck experienced a violent sabotage incident at 18:05 during transport: door S3 was pried open (sublock S3 generated a violent sabotage alarm log, global sequence number 89, timestamp 18:05:12), and door S5 in the same window was also opened (sublock S5 generated an unlocking log, global sequence number 134, timestamp 18:05:18); the vibration amplitude reported by environmental sensor node E0 reached 2.4g in the same window (exceeding the vibration threshold of 2g); the satellite positioning record of the main lock M0 showed that the vehicle was located at 30.52°N, 114.35°E (timestamp 18:05:10). After the master lock reads the rescue event log of S3, it triggers the solidification of the evidence package: the S3 log number 89, the S5 log number 134, the environmental snapshot of E0 from 18:05:00 to 18:05:30 (including vibration of 2.4g and temperature of -15.8℃), and the M0 location record at 18:05:10 are bundled into an evidence package, sorted by sequence number / timestamp, and then concatenated to calculate the joint hash value. =0x7A3F5C2E91B40D86 (64 bits), uploaded to the cloud along with the evidence package. Subsequently, if anyone attempts to tamper with any record in the evidence package (such as changing the temperature value from -15.8℃ to -18.0℃ to cover up an out-of-limit temperature reading), the recalculated joint hash value will inevitably differ from the value stored in the cloud. If there is a discrepancy, the tampering will be detected. In judicial evidence presentation for cargo damage disputes, the court can quickly verify whether the entire set of evidence is complete and has not been tampered with by comparing the joint hash value, without having to check each record one by one.

[0158] The evidence packet co-solidification mechanism in this embodiment complements the log hash chain in embodiment 6: the hash chain protects the integrity of a single-lock log sequence (vertical), while the evidence packet co-solidification protects the integrity of multiple sets of evidence across locks and sources (horizontal). Together, they constitute a complete cryptographic evidence system.

[0159] The hash function (SHA-256, truncated to 64 bits) and the composition of the evidence package (log, environment snapshot, location record) described above are illustrative examples. In other implementations, the hash function may use the national cryptographic standard SM3 or other cryptographic hash algorithms, the truncated width may be adjusted according to the needs of evidence presentation, and the evidence package may also include records from other sources such as user terminal operation records and video snapshots. None of these constitute a specific limitation on the scope of protection of this application. The above mechanism, through cross-source evidence bundling and joint hash calculation solidification, achieves the integrity cryptographic endorsement of the three types of evidence: log, environment, and location. Together with the single-lock log hash chain, it forms a complete evidence presentation system that is both vertical and horizontal, significantly reducing the cost of evidence verification in scenarios such as cargo damage disputes. Evidence tampering can be quickly identified, which is conducive to improving the credibility and efficiency of the disputed evidence presentation process, providing solid and reliable technical support for liability determination, and providing complete and solidified evidence that meets the requirements of electronic evidence preservation for judicial evidence presentation. This further strengthens the credibility and authority of this system in the end-to-end traceability.

[0160] Example 19: Multi-Master Lock Log Relay and Cloud Water Level Synchronization This embodiment, based on the system architecture of Embodiment 15, adds a multi-master lock log relay and cloud water level synchronization mechanism to solve the problem of continuous log collection when sub-locks switch across master locks in scenarios such as trailer swapping. This mechanism is implemented using a two-layer architecture of "cloud global water level synchronization + master lock local cache relay": the cloud platform maintains a global water level for each sub-lock, recording the maximum global sequence number of all logs successfully uploaded to the cloud for that sub-lock; each master lock automatically synchronizes the global water level of all sub-locks within its management scope from the cloud upon startup or after network recovery, updating the local read sequence number pointer to avoid duplicate reading of already-entered logs; when a sub-lock moves from the coverage area of ​​master lock A to the coverage area of ​​master lock B, after master lock B scans the sub-lock's status broadcast, it prioritizes querying the cloud for that sub-lock's status. The latest global water level of the lock is used as a benchmark to read incremental logs that have not been synchronized locally on the sub-locks. After reading, the incremental logs are uploaded to the cloud and the global water level is updated synchronously. The master lock reserves a cross-master lock relay buffer area for each sub-lock (this buffer area can be a component of the local cache, used to store logs that have been read but have not yet been successfully uploaded to the cloud platform). This buffer temporarily stores logs that have not yet been synchronized to the cloud. When a sub-lock moves out of the coverage area, the logs in the buffer area can still be re-uploaded when the sub-lock is scanned by other master locks, ensuring that there are no omissions in the log chain. In the entire process, the sub-locks do not need to be aware of the master lock switching, and the log recycling process is completely transparent. This solves the log gap problem caused by the replacement of master locks in scenarios such as trailer swapping and container cross-yard transfer. Cross-regional log continuous collection can be achieved without modifying the sub-lock hardware and basic communication protocol.

[0161] In fleet transportation scenarios, trailer swapping is a common operation: a trailer (along with its sub-locks) may be unattached from one master vehicle (equipped with a master lock M_A) and then grouped with another master vehicle (equipped with a master lock M_B). The original master lock M_A has already read and uploaded part of the logs of the sub-lock, and the read sequence number pointer has advanced to a certain position; when the new master lock M_B is bound to the sub-lock, if the read status of M_A is not obtained, it will be impossible to distinguish between uploaded and unuploaded logs, resulting in either duplicate reading (wasting connection resources) or missed reading (log gaps).

[0162] The multi-master lock log relay mechanism is as follows: The cloud platform maintains a global inventory level for each bound child lock. This level automatically advances to the maximum global inventory level for that child lock after the cloud platform successfully saves the logs uploaded by the master lock. When a master lock binds a new child lock (after binding via RFID card), it queries the cloud platform for the current global inventory level of that child lock and initializes its local read sequence pointer to that level value. Thus, the new master lock incrementally reads logs starting from the cloud level, neither repeatedly reading uploaded logs nor missing unread logs beyond that level.

[0163] During the transition period when a sublock detaches from its original master lock M_A but has not yet been bound to a new master lock M_B, the sublock continuously generates and caches logs and continuously sends status broadcasts. If the sublock is scanned by a third-party master lock M_C during the transition period (e.g., when other vehicles pass by), although M_C is not bound to the sublock (and cannot establish a connection to read logs), the priority flag in its status broadcast can still be used by M_C for fleet-level status monitoring (e.g., the cloud platform aggregates the scan records of each master lock to know that the sublock is currently online and has a backlog of logs), providing a decision-making basis for scheduling the sublock to be grouped to a suitable master lock as soon as possible.

[0164] Furthermore, based on the global inventory level of the stored serial numbers and the scanning records of each master lock, the cloud platform proactively schedules the cross-master lock retrieval of sub-locks. When the cloud platform detects that the global inventory level of a sub-lock has not progressed for an extended period (e.g., more than 24 hours), and at least one master lock has reported the online status and backlog of the sub-lock, the cloud platform sends a scheduling prompt to the management of the vehicle to which the master lock belongs, suggesting that the sub-lock be grouped into the vehicle to which the master lock belongs as soon as possible to allow the backlog of logs to be retrieved.

[0165] Here is a complete example: Sublock S6 runs on vehicle A (mother lock M_A) with the trailer. M_A has read the global serial number 1 to 200 of S6 and uploaded it to the cloud. The global serial number level in the cloud has advanced to 200. The trailer is unattached and grouped to vehicle B (mother lock M_B) during the trailer swapping operation. After M_B binds to S6 through the radio frequency identification card, it queries the cloud for the global serial number level of S6 and finds that the current level is 200. It then initializes the local read serial number pointer to 200. During the time that S6 is disconnected from M_A, it generates 38 logs with serial numbers 201 to 238 (connecting with the example in Example 4). After scanning the status broadcast of S6, M_B recognizes the newly added log marker, establishes a connection, and reads from serial number 201 to 238 according to formula (2). All 38 logs are uploaded to the cloud by M_B, and the cloud level advances to 238. There is no duplicate reading or log gaps throughout the entire process, and log recycling across parent locks is seamless.

[0166] If S6 is not grouped to any master lock within 72 hours of being disconnected from M_A, and the cloud platform detects that S6's water level has been stagnant at 200 for more than 24 hours, and vehicle C (master lock M_C) reports that S6 is online and its priority value has risen to 7, the cloud platform sends a scheduling prompt to the manager of vehicle C. Based on this, the manager arranges for the trailer to be grouped to vehicle C. After M_C is bound to S6, it starts reading from the cloud water level 200, and the backlog logs are recovered.

[0167] This embodiment utilizes a cloud-based water level synchronization mechanism to eliminate the need for repeated log readings or omissions during sub-lock switching across master locks. This is particularly suitable for scenarios involving sub-lock movement across master locks, such as trailer-swapping and container transfers. By employing the aforementioned cloud-based global water level maintenance, master lock local caching relay, and incremental cross-master lock reading methods, the system resolves the log gaps and repeated reading issues during sub-lock switching across master locks in scenarios like trailer-swapping and cross-yard transfers. It expands the three-level transfer architecture from single master lock management to multi-master lock full-domain collaboration, achieving continuous log collection throughout the sub-lock's lifecycle. This ensures the integrity and continuity of logs across the entire chain, meets the full-process traceability requirements in multi-node transfer scenarios, further expands the system's applicability, and improves management reliability in complex multi-node movement scenarios.

[0168] (iv) Supporting explanations for other conservation topics Based on the above embodiments, other protected subjects and optional extensions for implementing the method of this application are also within the protection scope of this application. These include, but are not limited to: Storage medium – The storage medium stores program data, which, when executed by the processor, implements the steps of the intelligent multi-terminal collaborative management method (applied to the master lock) as described in any one of Embodiments 1 to 8, and / or implements the steps of the intelligent multi-terminal collaborative management method (applied to the slave lock) as described in any one of Embodiments 9 to 14; the storage medium may be a medium capable of storing program code, such as a USB flash drive, mobile hard drive, read-only memory, random access memory, magnetic disk, or optical disk.

[0169] The mother lock device includes a scanning module (adaptive duty cycle scanning according to formula (1), a verification module (performs triple anti-replay verification of embodiment 2), a scheduling module (establishes connections according to priority and exponential backoff according to formula (5), a transfer module (incrementally reads according to formula (2), disconnects immediately after reading and uploads after deduplication), and a time synchronization module (obtains accurate time, performs periodic calibration and checks timestamps and cross-verifies according to formulas (7) and (8)).

[0170] The sub-lock device includes a log recording module (records logs, solidifies timestamps and assigns global serial numbers), a broadcast module (periodically sends status broadcasts of the frame structure described in Example 12), a trigger and priority module (determines priority values ​​by fusing according to formula (9)), a check code generation module (calculates check codes according to formula (10), a cache management module (determines endpoint values ​​and performs graded elimination according to formula (11)), and a parameter management module (receives temporary energy-saving parameters issued by the master lock, updates and takes effect through the dual-zone atomic switching mechanism).

[0171] The hardware components—the main lock side includes a processor, memory, short-range wireless communication module, wide-area communication module, and satellite positioning module; the sub-lock side includes a processor, memory, short-range wireless communication module, radio frequency identification module, lock body control circuit, local real-time clock, and battery.

[0172] The software system includes a first program module that implements the steps on the mother lock side and a second program module that implements the steps on the daughter lock side, which can be deployed in the embedded systems of the mother lock and daughter lock respectively.

[0173] Based on the above embodiments, this application further describes alternative solutions for the bit width and encoding method of each field in the frame and for short-range wireless communication standards, in order to adapt to different deployment scenarios and security requirements.

[0174] Regarding the priority flag bit width: Example 12 uses 3 bits (values ​​0 to 7), suitable for most scenarios. In scenarios with fewer monitoring levels (e.g., only needing to distinguish between "none / normal / emergency" levels), 2 bits (values ​​0 to 3) can be used, reducing the frame length by 1 bit. The event-priority baseline table is correspondingly simplified to three levels (0 for no flag, 2 for normal, and 7 for emergency). The duration step and quantity step can be appropriately widened to reduce the sub-lock calculation overhead. In scenarios requiring finer-grained scheduling (e.g., distinguishing between urgency levels above eight), 4 bits (values ​​0 to 15) can be used to provide coding space for further classification within rescue events (e.g., distinguishing between "violent sabotage alarm" and "emergency unlocking" rescue events of different urgency levels). When the bit width changes, the event-priority baseline table and each step parameter ( , The system adapts proportionally, with bit width information declared according to the parameter set version number. The master lock parses the broadcast frame according to the encoding corresponding to the version number. Taking 4 bits as an example: the base priority is expanded to rescue event 15, severe low battery 14, low battery 13, abnormal event 10, and normal operation 4, with an upper limit for the value. =15; the duration step can be adjusted from 2 hours to 1 hour (more sensitive), and the quantity step can be adjusted from 64 lines to 32 lines, enabling faster priority climbing in high-precision scenarios. Furthermore, different sub-locks can use different bit widths—high-security doors (such as refrigerated doors) are equipped with a 4-bit bit width to support fine-grained scheduling, while ordinary doors are equipped with a 3-bit bit width to save frame length. The master lock is parsed separately according to the parameter set version number of each sub-lock, realizing the hybrid deployment of heterogeneous bit widths within the same system.

[0175] Regarding the checksum truncation width, Example 10 uses 16 bits, a choice made to balance security strength and frame length—the random collision probability of a 16-bit checksum is... With a probability of approximately 0.0015%, the expected collision count over the entire lifecycle of the sub-lock (typically 5 years, 1 frame per second, approximately 160 million broadcasts) is about 2400. Furthermore, a collision frame must pass both the monotonicity of the count and the validity of the time window to be accepted, making the actual false acceptance probability close to zero. In high-value goods transportation scenarios (such as precious metals and pharmaceutical cold chain), the checksum can be extended to 32 bits, improving its resistance to brute-force attacks. The frame length increases by 2 bytes to 12 bytes (still far below the 31-byte payload limit), making it suitable for high-risk scenarios where attackers might use dedicated equipment for long-term eavesdropping and spoofing attacks. In ultra-low-power scenarios (such as ordinary logistics powered by button batteries and with low-value goods), the frame length can be narrowed to 8 bits, reducing it by 1 byte to 9 bytes, but the anti-spoofing strength decreases accordingly. With a collision probability of approximately 0.39%, it is recommended to shorten the key rotation cycle to compensate for the reduced security strength. The truncation width, as part of the parameter set, can be remotely adjusted by the master lock according to the cargo value, transportation duration, and threat level of the transport task. It also supports differentiated configuration by sub-lock—among sub-locks managed by the same master lock, sub-locks for high-value cargo doors use a 32-bit checksum, while sub-locks for ordinary doors use a 16-bit checksum. The master lock selects the corresponding width checksum algorithm based on the parameter set version number of each sub-lock.

[0176] Regarding the rolling count bit width: Example 10 uses 16 bits (65,536 broadcast cycles, approximately 18.2 hours per 1-second broadcast cycle), suitable for scenarios with a 1-second broadcast cycle. In low-power scenarios where the broadcast cycle is extended to more than 3 seconds, the 16-bit wraparound cycle is correspondingly extended to more than approximately 54.6 hours, resulting in a wider effective window for the counting monotonicity criterion. In high-frequency broadcast scenarios requiring longer wraparound cycles (such as port container management using a 0.5-second broadcast cycle), the rolling count field can be extended to 24 bits or 32 bits, with the wraparound cycle extended to approximately 97 days or approximately 68 years, respectively, but the frame length increases by 1 to 2 bytes accordingly. Counting acceptance window width. Adjust proportionally with bit width — for 16 bits =1024 (1 / 64 of the modulus), which can be taken as 32 bits. =67108864 (accounting for 1 / 64 of the modulus value 232), maintaining the same relative acceptance ratio. The bit width information of the rolling count value is declared with the parameter set version number, and the mother lock performs the modulus operation and acceptance window determination of formula (3) according to the bit width corresponding to the version number.

[0177] Regarding the broadcast timestamp bit width. Example 12 uses 16 bits (the lower 16 bits of the second count, with a wraparound period of approximately 18.2 hours), combined with the modulus deviation calculation of the mother lock side (4), which can be correctly verified before and after wraparound. In scenarios where the broadcast period is extended to more than 3 seconds, the wraparound period of the 16-bit timestamp remains unchanged (still 18.2 hours), but the actual number of effective timestamps decreases as the broadcast interval increases. The timestamp can be appropriately narrowed; in scenarios requiring a longer no-wrap window (such as when a child lock re-enters the network several days after going offline), the timestamp field can be extended to 24 bits or 32 bits, with the wraparound period extended to approximately 194 days or approximately 136 years, respectively, but the frame length increases by 1 to 2 bytes accordingly. In other implementations, the broadcast timestamp can also be the lower bit of the millisecond count (higher precision but shorter wraparound period), suitable for precision tracking scenarios requiring millisecond-level time resolution. The timestamp bit width and value precision are declared according to the parameter set version number, and the mother lock performs the modulo deviation check of equation (4) according to the bit width and precision corresponding to the version number.

[0178] Regarding the sub-lock identifier bit width: Example 12 uses 16 bits (supporting 65,536 sub-locks), suitable for single-fleet operations. In large-scale deployment scenarios across fleets and enterprises (such as nationwide logistics networks), the sub-lock identifier can be extended to 24 bits or 32 bits, supporting approximately 16 million or 4.3 billion sub-locks respectively, increasing the frame length by 1 to 2 bytes. In small-scale deployment scenarios (such as 6 sub-locks per truck), it can be narrowed to 8 bits (supporting 256 sub-locks), reducing the frame length by 1 byte. When the sub-lock identifier bit width changes, the master lock management record table and binding process adapt accordingly, and the bit width information is declared along with the parameter set version number.

[0179] Regarding short-range wireless communication standards. The embodiment takes Bluetooth Low Energy (BLE) as an example, whose single-frame broadcast payload limit is 31 bytes, and the 10-byte broadcast frame of this application can fully carry it. Other implementation methods can adopt the following standards: (1) Zigbee - suitable for mesh networking scenarios, the sublock can act as a relay node to extend the communication range, the single-frame payload limit is about 128 bytes, which is much larger than Bluetooth's 31 bytes, and more status fields (such as sensor calibration parameters, firmware version number, digest hash of the most recent logs, etc.) can be included in the broadcast frame without establishing a connection to read them. The cost is that the power consumption of the sublock is slightly higher than that of BLE and the networking configuration is more complicated; (2) Wireless Local Area Network (Wi-Fi) - suitable for warehouse scenarios with Wi-Fi coverage, the communication rate is higher, the single-frame payload limit is about 1500 bytes (far exceeding the 10-byte requirement of this application), but the power consumption is significantly higher than that of BLE and Zigbee is suitable for fixed deployment sublocks powered by mains electricity rather than mobile sublocks powered by batteries; (3) Ultra-wideband (UWB) is suitable for scenarios requiring high-precision positioning. In addition to log collection, it can also provide centimeter-level location information of the sublock. The main lock can use this information to detect whether the sublock has been moved to an unauthorized area. The cost is that the hardware cost is high; (4) Other low-power wireless communication methods, such as LoRa (suitable for long-distance low-speed scenarios, the sublock can be detected by the main lock from several kilometers away, but the broadcast period needs to be extended to tens of seconds to reduce power consumption) and NB-IoT (suitable for wide-area coverage scenarios, the sublock can communicate directly with the cloud platform without the main lock relay, but the module cost and power consumption are higher than BLE). The frame structure is adapted according to the upper limit of the payload of the communication standard used. For standards with a payload upper limit greater than 31 bytes (such as Zigbee and Wi-Fi), extended fields such as environmental sensing data, firmware version number, and recent log summary can be included in the broadcast frame; for standards with a payload upper limit less than 31 bytes, the broadcast frame needs to be simplified or segmented broadcasting needs to be used. The choice of communication standard, as part of the parameter set, can be remotely configured by the master lock according to the deployment scenario or preset at the factory, and is not limited to the low-power Bluetooth used in this embodiment.

[0180] Regarding parameter set version management and compatibility: Alternative solutions for the bit width, encoding method, and communication standard of each field are all managed uniformly through parameter sets. Parameter sets are identified by version numbers, with the master lock and child locks each maintaining their current version number. During version updates, the master lock reads the connection from the log and simultaneously sends out the new parameter set (including the bit width of each field, event-priority baseline table, step size parameters, verification algorithm parameters, communication standard configuration, etc.). The child locks are updated and take effect using a dual-zone atomic switching mechanism (Example 13). The master lock selects the corresponding parameter to parse the broadcast frame according to the version number broadcast by each child lock. Multiple versions of child locks can coexist within the same system—for example, some child locks use a 3-bit priority bit width and a 16-bit checksum (version 1), while other child locks use a 4-bit priority bit width and a 32-bit checksum (version 2). The master lock parses the parameters according to the version number of each child lock, achieving a gradual upgrade without replacing all child locks at once. Version updates employ a grouping and staggered-peak strategy (e.g., six sub-locks are divided into three groups and completed in batches over three days), ensuring that the old and new versions coexist and are compatible at any given time, thus avoiding instantaneous inconsistencies in behavior caused by switching all sub-locks simultaneously.

[0181] All the aforementioned topics, as well as equivalent structural or procedural transformations based on the concepts of this application, are similarly included within the scope of patent protection of this application. The bit width, encoding method, verification algorithm, communication standard, and parameter set management scheme of each of the above fields are all illustrative examples and can be flexibly adjusted in other embodiments according to deployment scenarios, security requirements, cost constraints, and hardware capabilities, and do not constitute a specific limitation on the scope of protection of this application.

[0182] To address the pain points of existing multi-lock collaborative solutions, such as high hardware cost, high power consumption, susceptibility to broadcast forgery and replay, insufficient reliability of log timestamps, and easy loss of logs in offline scenarios, the intelligent multi-terminal collaborative management method and system disclosed in this application constructs a low-power, high-security, and high-reliability collaborative mechanism across the entire chain. The master lock scans the short-state broadcasts of each sub-lock without log content according to an adaptive and upper-limited scanning duty cycle based on the number of sub-locks to be read, completely decoupling the two stages of "declaration of data to be read" and "log data transmission". When there is no data to be read, the master lock maintains low-power operation, and the scanning intensity automatically increases when the amount of data to be read increases, achieving a dynamic balance between power consumption and discovery capability. After identifying a new log marker, it must undergo triple anti-replay verification of recalculation consistency, monotonic counting, and effective time window, intercepting forgery, tampering, and replay attacks at the source, and establishing short connections only with legitimate sub-locks, significantly reducing the resource consumption of invalid connections. After establishing a connection, the master lock reads only incremental logs with global sequence numbers greater than the pointer value based on the read sequence number pointer. After reading, the connection is immediately closed. The duration of a single connection is compressed to a level that strictly matches the scale of new data. Link resources can be efficiently reused among multiple child locks. The number of child locks that a single master lock can manage is significantly increased compared to traditional long connection solutions. On the child lock side, the priority value is determined by combining the urgency of the event, the duration of non-synchronization, and the number of non-synchronizations. Low power events are backed up by power guarantee priority to ensure that emergency logs and logs in low power scenarios are recycled first, avoiding log loss due to power depletion. The master lock obtains precise time through satellite positioning or network time synchronization, periodically calibrates the local real-time clock of the sub-locks, and cross-verifies the timestamps of multiple sub-locks according to the expected deviation range when reading logs to ensure the reliability of the timestamps and ensure that the log times can be used as reliable evidence in disputes. For sub-lock offline scenarios, an adaptive loss threshold judgment and shuttle retransmission mechanism are adopted to prioritize the recovery of rescue event logs during offline periods. At the same time, in conjunction with the sub-lock endpoint value hierarchical elimination strategy, high-value logs are prioritized for retention in storage-constrained scenarios, maximizing the integrity of logs in extreme scenarios such as weak networks and offline conditions. Through the systematic coordination of the above mechanisms, this solution achieves secure, reliable, and verifiable intelligent multi-terminal collaborative management under the constraints of low cost and low power consumption, without requiring sub-locks to be configured with wide-area communication modules. It is particularly suitable for IoT scenarios with high requirements for lock monitoring reliability and large-scale deployment, such as cold chain transportation, dangerous goods transportation, and multi-site asset management.

[0183] The various embodiments in this specification are described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other; the optional implementation methods can be combined arbitrarily, and all are within the protection scope of this application as long as they do not contradict each other; the numerical parameters (each period, each threshold, each step size, each window width, each priority value and each byte arrangement) involved in the various embodiments of this application are all exemplary descriptions and do not constitute a specific limitation on the protection scope of this application.

[0184] The above description is merely an embodiment of this application and does not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A method for intelligent multi-terminal collaborative management, characterized in that, A master lock is used in an intelligent multi-terminal collaborative management system, which also includes multiple sub-locks and a cloud platform. The master lock is communicatively connected to each of the sub-locks and the cloud platform. The intelligent multi-terminal collaborative management method includes: Status broadcasts are periodically sent by each of the sublocks according to a scan duty cycle, wherein the scan duty cycle is adjusted according to the size of the data to be read and increases as the size of the data to be read increases; the size of the data to be read is determined based on the number of sublocks with newly identified log tags and / or the number of newly added logs; the status broadcasts do not carry the contents of the logs stored locally by the sublocks. When the newly added log marker is identified from the status broadcast, the checksum carried in the status broadcast is verified. If the verification passes, the sub-lock that sent the status broadcast is identified as the sub-lock to be read. The newly added log marker indicates that there is a newly added log locally on the sub-lock. The newly added log is a log that has not been read by the parent lock. A connection is established with the sublock to be read, the incremental log is determined from the new log based on the read records, only the incremental log is read, a read confirmation is returned to the sublock to be read after successful reading, and the connection with the sublock to be read is disconnected after reading is completed; the read records are used to represent the logs that have been successfully read by the master lock; The incremental logs read are aggregated and uploaded to the cloud platform for storage. The cloud platform then forwards the entry confirmation returned by the cloud platform after successful storage to the corresponding sub-lock, so that the corresponding sub-lock can mark the corresponding log as synchronized after receiving the entry confirmation.

2. The intelligent multi-terminal collaborative management method according to claim 1, characterized in that, The status broadcast also carries a rolling count value and a broadcast timestamp. The newly added log tag includes a priority flag bit. The checksum is generated by the sub-lock based on a check algorithm pre-agreed with the master lock, using parameters including the identifier of the sub-lock that sent the status broadcast, the value of the priority flag bit, the rolling count value, and the broadcast timestamp. The rolling count value increases each time the sub-lock sends the status broadcast. The step of verifying the checksum carried in the status broadcast, and determining the sub-lock that sent the status broadcast as the sub-lock to be read when the verification passes, includes: The verification code is recalculated. If the recalculated verification code matches the verification code carried in the status broadcast, the authentication is deemed successful. The rolling count value is verified. When the increment of the rolling count value relative to the previously verified rolling count value, modulo a preset upper limit, is within the acceptance window, it is determined that the count has passed monotonically. The broadcast timestamp is verified. If the time deviation between the broadcast timestamp and the current precise time of the master lock, calculated modulo the second counting period, does not exceed the effective time window, the time window is determined to be passed. The verification is considered successful only if authentication, counting monotonicity, and time window are all passed, and the sublock that sends the status broadcast is identified as the sublock to be read; if any of the verifications fails, no connection is initiated with the corresponding sublock. When the number of times the status broadcast verification of the same sublock fails reaches a preset number of failures, a security event log containing the identifier of the corresponding sublock is generated, and the security event log is aggregated and uploaded to the cloud platform.

3. The intelligent multi-terminal collaborative management method according to claim 1, characterized in that, The newly added log tag includes a priority tag bit, which has multiple values, and different values ​​represent different reading priorities. When the priority flag bit is identified from the status broadcasts of multiple sublocks, each sublock whose priority flag bit is identified is identified as the sublock to be read in descending order of read priority represented by the priority flag bit, and a connection is established with each sublock to be read in turn; when a status broadcast with a higher read priority represented by the priority flag bit is identified during the process of establishing a connection in turn, a connection is established with the sublock that sent the corresponding status broadcast; wherein, if the waiting time for any sublock to be read to be connected exceeds a preset delay time limit, the read priority of the corresponding sublock to be read is increased; When a connection to any of the sublocks to be read fails to be established, a retry delay is determined according to an exponential backoff strategy, and a new connection is initiated to the sublock that failed to be connected after the retry delay ends. The retry delay increases with the number of connection failures.

4. The intelligent multi-terminal collaborative management method according to claim 1, characterized in that, The intelligent multi-terminal collaborative management method also includes: The disconnection threshold is determined based on the scanning period and the broadcast period of the status broadcast. If the status broadcast of the sub-lock is not scanned after the disconnection threshold is exceeded, the corresponding sub-lock is recorded as an offline sub-lock. When the status broadcast of the offline sublock is scanned again and the newly added log marker is identified from the status broadcast, a connection is established with the offline sublock. The rescue event logs stored locally by the offline sublock are read first, and then the newly added logs other than the rescue event logs are read. The newly added logs cached by the offline sublock during the offline period are retransmitted. If there are missing newly added logs, an alarm event is generated to represent the missing logs, and the alarm event is reported to the cloud platform.

5. The intelligent multi-terminal collaborative management method according to claim 1, characterized in that, The intelligent multi-terminal collaborative management method also includes: The calibrated precise time is obtained through satellite positioning or network time synchronization. The local real-time clock of each sub-lock is periodically calibrated according to the precise time, and the calibration deviation is recorded for each calibration. When reading the incremental log, the expected deviation range is determined based on the precise time and the calibration deviation recorded during the most recent calibration. When the deviation of the timestamp of the incremental log relative to the precise time exceeds the expected deviation range, the corresponding log is determined to be abnormal, and the abnormality identifier is uploaded to the cloud platform along with the log summary. After reading the incremental logs of multiple sub-locks, cross-validation is performed on the logs of multiple sub-locks whose timestamps are within the same time window. When the deviation between the timestamps of the logs of different sub-locks exceeds the cross-validation threshold determined based on their respective expected deviation ranges, the corresponding log is determined to be abnormal, and the abnormality identifier is uploaded to the cloud platform along with the log summary.

6. A method for intelligent multi-terminal collaborative management, characterized in that, A sub-lock is applied in an intelligent multi-terminal collaborative management system, which also includes a master lock and a cloud platform. The master lock is communicatively connected to the sub-lock and the cloud platform, respectively. The intelligent multi-terminal collaborative management method includes: Record its own generated logs and save them locally; Periodically send status broadcasts, the status broadcasts not carrying the contents of the log; When the event triggering condition is met, a new log flag is set in the status broadcast. The new log flag includes a priority flag bit. The new log flag indicates that there is a new log in the sub-lock that has not been read by the master lock. In response to the connection initiated by the master lock after recognizing the new log tag, the unread log is provided to the master lock for the master lock to read, and the connection is disconnected after reading is completed, and the read log is summarized and uploaded to the cloud platform; The system receives a read confirmation returned by the master lock after successful reading, and an entry confirmation forwarded by the master lock from the cloud platform after successful saving. Upon receiving the entry confirmation, the system marks the corresponding log as synchronized.

7. The intelligent multi-terminal collaborative management method according to claim 6, characterized in that, The status broadcast also carries a checksum, a rolling count value, and a broadcast timestamp; The rolling count value increments with each transmission of the status broadcast and wraps around after the rolling count value reaches the upper limit. The broadcast timestamp is determined by the local real-time clock of the sub-lock; The verification code is generated by the sub-lock based on a verification algorithm pre-agreed with the mother lock, using parameters including its own identifier, the value of the priority flag bit, the rolling count value, and the broadcast timestamp.

8. The intelligent multi-terminal collaborative management method according to claim 6, characterized in that, The intelligent multi-terminal collaborative management method also includes: When the locally stored logs reach the cache endpoint value, the logs are evicted according to a tiered strategy. The tiered strategy prioritizes retaining logs of rescue events, followed by logs of abnormal events, and prioritizes evicting logs of regular operations with the earliest record time. The cache endpoint value is determined based on local storage capacity, log generation rate, and expected offline duration. The tiered strategy reserves an independent retention quota for logs of rescue events, and this independent retention quota is not consumed by the eviction process of the tiered strategy.

9. The intelligent multi-terminal collaborative management method according to claim 6, characterized in that, The intelligent multi-terminal collaborative management method further includes: after a low power event occurs, receiving temporary energy-saving parameters issued by the master lock in the next connection, the temporary energy-saving parameters including an extended broadcast period and / or a reduced transmission power; and sending the status broadcast according to the temporary energy-saving parameters to reduce power consumption during the waiting period for log recycling. The temporary energy-saving parameters are distributed through the parameter set channel. The parameter update of the parameter set channel adopts a dual-zone atomic switching mechanism. The parameter storage area of ​​the sub-lock is divided into a current area and a backup area. The new parameters are first fully downloaded to the backup area and verified before being switched to the current parameters at a predetermined time. If the download is interrupted or the verification fails, the original parameters remain unchanged.

10. An intelligent multi-terminal collaborative management system, characterized in that, It includes a master lock, multiple sub-locks, and a cloud platform; the master lock is communicatively connected to each of the sub-locks and the cloud platform. The sub-lock is used to record its own generated logs and save them locally. It periodically sends status broadcasts without log content and sets a new log flag with a priority flag in the status broadcast when the event triggering condition is met. The new log flag indicates that there are new logs on the sub-lock that have not been read by the parent lock. It responds to the connection initiated by the parent lock by providing the unread logs and marks the corresponding logs as synchronized after receiving read confirmation and database entry confirmation. The master lock is used to scan the status broadcasts of each of the sub-locks according to a scan duty cycle that adjusts with the size of the data to be read and increases with the increase of the size of the data to be read. When a new log marker is identified from the status broadcast, the checksum carried in the status broadcast is verified. If the verification is successful, the sub-lock that sent the status broadcast is identified as the sub-lock to be read. Connections are established with the sub-locks to be read in descending order of reading priority represented by the priority flag bit. Incremental logs are determined from the new logs based on the read records and only the incremental logs are read. After successful reading, a read confirmation is returned to the corresponding sub-lock. After reading is completed, the connection is disconnected, and the read incremental logs are summarized and uploaded to the cloud platform. The database entry confirmation returned by the cloud platform after successful saving is forwarded to the corresponding sub-lock. The size of the data to be read is determined based on the number of child locks that have identified the new log marker and / or the number of new logs; the read records are used to characterize logs that have been successfully read by the parent lock; The cloud platform is used to store the incremental logs uploaded by the master lock, and the master lock forwards them to the child lock for confirmation of entry into the database.

Images