Logistics electronic lock instruction execution method and system based on artificial intelligence, storage medium and electronic equipment

Abstract

The invention discloses a logistics electronic lock instruction execution method and system based on artificial intelligence, a storage medium and electronic equipment. The method comprises the steps that multiple types of function control instructions of a logistics electronic lock are received; instruction type analysis and priority ranking are carried out on the multiple types of function control instructions, and an instruction execution sequence with time sensitivity marks is generated; based on the instruction execution sequence, performing dynamic analysis and resource allocation through a multi-modal fusion decision model, and generating an instruction execution scheme including an execution time sequence and resource scheduling; and according to the instruction execution scheme, driving a corresponding lock function module to execute operation, and verifying an instruction execution result in real time in the execution process. By utilizing the embodiment of the invention, efficient and collaborative scheduling and resource allocation of the concurrent instructions of the logistics electronic lock can be realized, and the accuracy and timeliness of instruction execution and the utilization rate of system resources are improved.

Description

Technical Field

[0001] This invention belongs to the field of logistics electronic lock technology, and in particular to an artificial intelligence-based logistics electronic lock instruction execution method, system, storage medium and electronic device. Background Technology

[0002] With the rapid development of the smart logistics industry, logistics electronic locks have evolved from simple mechanical locks into intelligent IoT terminals integrating multiple functions such as identity authentication, real-time positioning, and status monitoring. Current technologies primarily use single or sequential execution modes for control commands on logistics electronic locks, lacking the ability to collaboratively manage and intelligently schedule multi-source, heterogeneous commands (such as facial recognition, location tracking, and security authentication). When multiple commands are executed concurrently, resource contention or timing conflicts can easily lead to system response delays and the blocking of critical commands, making it difficult to meet the high security and real-time requirements of logistics management. Especially in complex logistics scenarios, ensuring that various commands are executed quickly and accurately according to their urgency and importance, and optimizing the allocation of execution resources, has become a key technological bottleneck for improving logistics safety and efficiency. Summary of the Invention

[0003] The purpose of this invention is to provide an artificial intelligence-based logistics electronic lock instruction execution method, system, storage medium, and electronic device to overcome the shortcomings of the prior art, enabling efficient and coordinated scheduling and resource allocation of concurrent instructions from logistics electronic locks, and improving the accuracy, timeliness, and utilization rate of instruction execution and system resources.

[0004] One embodiment of this application provides a logistics electronic lock instruction execution method based on artificial intelligence, the method comprising: The system receives various functional control commands from the logistics electronic lock, including at least facial recognition control commands, location tracking control commands, and security authentication control commands. The instruction types of the various function control instructions are parsed and prioritized to generate an instruction execution sequence with time-sensitive markers; Based on the instruction execution sequence, a multimodal fusion decision model is used for dynamic analysis and resource allocation to generate an instruction execution scheme that includes execution timing and resource scheduling. The corresponding lock function module is driven to perform operations according to the instruction execution scheme, and the instruction execution result is verified in real time during the execution process.

[0005] Another embodiment of this application provides an artificial intelligence-based logistics electronic lock instruction execution system, the system comprising: The receiving module is used to receive various functional control commands from the logistics electronic lock, wherein the functional control commands include at least face recognition control commands, location tracking control commands, and security authentication control commands; The parsing module is used to parse the instruction types and prioritize the multi-function control instructions to generate an instruction execution sequence with time-sensitive markers. The allocation module is used to dynamically analyze and allocate resources based on the instruction execution sequence through a multimodal fusion decision model, and generate an instruction execution scheme that includes execution timing and resource scheduling. The execution module is used to drive the corresponding lock function module to perform operations according to the instruction execution scheme, and to verify the instruction execution results in real time during the execution process.

[0006] Another embodiment of this application provides a storage medium storing a computer program, wherein the computer program is configured to execute the method described in any of the preceding claims when running.

[0007] Another embodiment of this application provides an electronic device including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the method described in any of the preceding claims.

[0008] Compared with existing technologies, this invention provides an AI-based logistics electronic lock instruction execution method. This method receives multiple functional control instructions from the logistics electronic lock; parses and prioritizes these instructions to generate an instruction execution sequence with time-sensitive markers; based on the instruction execution sequence, it dynamically analyzes and allocates resources through a multimodal fusion decision model to generate an instruction execution scheme that includes execution timing and resource scheduling; and drives the corresponding lock function modules to perform operations according to the instruction execution scheme, verifying the instruction execution results in real time during execution. This enables efficient and collaborative scheduling and resource allocation of concurrent instructions from the logistics electronic lock, improving the accuracy, timeliness, and utilization of system resources. Attached Figure Description

[0009] Figure 1 A hardware structure block diagram of a computer terminal for an artificial intelligence-based logistics electronic lock instruction execution method provided in an embodiment of the present invention; Figure 2 A flowchart illustrating an artificial intelligence-based logistics electronic lock instruction execution method provided in an embodiment of the present invention; Figure 3 A flowchart illustrating another AI-based logistics electronic lock instruction execution system provided in an embodiment of the present invention; Figure 4A flowchart illustrating another AI-based logistics electronic lock instruction execution system provided in an embodiment of the present invention; Figure 5 This is a schematic diagram of the structure of an artificial intelligence-based logistics electronic lock instruction execution system provided in an embodiment of the present invention. Detailed Implementation

[0010] The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0011] This invention first provides an artificial intelligence-based logistics electronic lock instruction execution method, which can be applied to electronic devices, such as computer terminals, specifically ordinary computers.

[0012] The following detailed explanation uses a computer terminal as an example. Figure 1 This is a hardware structure block diagram of a computer terminal for an artificial intelligence-based logistics electronic lock instruction execution method, provided as an embodiment of the present invention. (See diagram below.) Figure 1 As shown, the computer device includes a processor, memory, and network interface connected via a system bus, wherein the memory may include non-volatile storage media and internal memory.

[0013] See Figure 2 The present invention provides an artificial intelligence-based logistics electronic lock instruction execution method, which may include the following steps: S201, receiving multiple function control commands from the logistics electronic lock, wherein the function control commands include at least face recognition control commands, location tracking control commands, and security authentication control commands; Specifically, the wireless communication module of the logistics electronic lock can receive the original instruction data stream sent from the cloud platform or mobile terminal, ensuring the integrity and real-time performance of the data stream, and thus obtaining the original instruction data stream. Logistics electronic locks need to be equipped with multi-mode wireless communication modules to adapt to different scenarios (such as short-range communication within warehouses and long-range communication during transportation). The EL-200 logistics electronic lock is selected here. Its communication module supports three modes: 4G Cat.1 (long-range), Bluetooth 5.0 (short-range), and Wi-Fi 802.11b / g / n (LAN), and can automatically switch according to the signal environment. Specifically, the 4G mode has a communication rate ≥1Mbps (transmitting 1 megabit of data per second, ensuring fast command transmission) and a communication latency ≤100ms (meeting real-time control requirements); the Bluetooth mode has a communication distance ≤10 meters, suitable for short-range terminal debugging; and the Wi-Fi mode is suitable for stable network environments within warehouses, with a bandwidth ≥20Mbps.

[0014] The receiving process must simultaneously ensure both "integrity" and "real-time performance": Integrity is achieved through CRC16 cyclic redundancy check. The original command data stream adopts a fixed frame structure, containing "start character (1 byte, fixed as 0xAA) + frame length (2 bytes, indicating the number of subsequent data bytes) + command type (1 byte) + payload content (N bytes, varying with command type) + CRC16 checksum (2 bytes) + end character (1 byte, fixed as 0x55)". For example, the face recognition control command data stream sent by the cloud platform is "0xAA 0x00 0x18 0x01 0x00 0x64 0x01 0x02 ... 0x3C 0x55" (a total of 26 bytes, frame length 0x0018, i.e., 24 bytes, command type 0x01 representing face recognition). After receiving the data, the electronic lock first verifies whether the start character and end character match, and then performs the CRC16 algorithm (polynomial x¹)... 6 +x¹ 5 +x²+1) calculates the check value of the payload content and instruction type, and compares it with the CRC16 field in the frame. If they match, the data is complete; otherwise, a retransmission request is triggered (retransmission count ≤ 3 times, interval 500ms).

[0015] Real-time performance is ensured through a "timeout mechanism": The electronic lock is set to receive commands with a timeout of 500ms. If a complete frame is not received within 500ms (no end marker is detected) starting from the start of the command, the incomplete data is discarded, and the system relistens for the next command. Simultaneously, if the cloud platform / terminal does not receive a "receive confirmation" from the electronic lock within 100ms after sending a command (0x00 indicates confirmation, 0x01 indicates retransmission), it automatically retransmits, ensuring that the command is received within 1 second, meeting the real-time control requirements in logistics scenarios (such as rapid unlocking during loading and unloading). The final raw command data stream is stored in the electronic lock's temporary buffer (1KB capacity to prevent data overflow) for subsequent parsing.

[0016] The original instruction data stream is parsed and format verified, the instruction header information and payload content are extracted, the instruction type and parameters are identified, and a set of parsed instruction objects is generated. The original instruction data stream needs to be parsed according to the "Logistics Electronic Lock Control Protocol (LECP, Custom Lightweight Protocol)". The core is to separate the "header information" and "payload content" and exclude illegal instructions through format verification to ensure that the instructions are executable.

[0017] First, protocol parsing is performed: The first step is to extract the header information. From the complete data stream (such as the face recognition instruction mentioned above), the first 4 bytes after the start character (frame length, instruction type) are extracted. The frame length 0x0018 (24 bytes) indicates that the following 24 bytes are "instruction type + payload content + CRC16". The instruction type 0x01 (face recognition), payload content (21 bytes, including face recognition threshold, timeout, and other parameters), and CRC16 checksum (2 bytes) need to be further separated. The second step is to parse the payload content. Different instruction types have different payload formats, for example: Face recognition control command (0x01): The first 2 bytes of the payload are the "face matching threshold" (0x0064, i.e., 100, representing a matching degree of ≥100 / 255≈39%), the next 2 bytes are the "recognition timeout" (0x0102, i.e., 258 seconds, if recognition fails within the timeout, the face will be locked), and the following 17 bytes are the "authorized face template ID" (e.g., 0x00010203...). Location tracking control command (0x02): The first 2 bytes of the payload are the "tracking frequency" (0x003C, i.e., 60 seconds / time), the next 4 bytes are the "positioning mode" (0x00000001 represents GPS + Beidou dual mode), and the following 8 bytes are the "tracking duration" (0x0000000000015180, i.e., 100000 seconds, approximately 27 hours); Security authentication control instruction (0x03): The first 8 bytes of the payload are the "key validity period" (time stamp format, such as 0x20250928120000, which means it will expire on September 28, 2025 at 12:00:00), and the following 6 bytes are the "dynamic key" (such as 0x1A2B3C4D5E6F).

[0018] After parsing, a format verification is required, which includes three checks: First, field length verification, verifying whether the number of bytes in the payload content is consistent with "frame length - 4" (frame length includes 1 byte of instruction type + N bytes of payload + 2 bytes of CRC16, so N = frame length - 3). For example, if the face recognition instruction frame length is 24 bytes, the payload should be 21 bytes (24-3=21). If it is actually 20 bytes, it is judged as a format error. Second, data type verification, checking whether the parameters meet the preset range. For example, the location tracking frequency should be between 10-3600 seconds / time (to avoid excessive power consumption due to excessive frequency or missed location due to excessively low frequency). If the parsed frequency is 5 seconds / time, it is judged as illegal. Third, permission verification, verifying whether the ID of the instruction sender (cloud platform / terminal) is in the electronic lock's authorization list (the authorization ID is stored in non-volatile memory, such as 0x0001 representing the main platform). Instructions sent without an authorized ID are directly discarded.

[0019] After successful verification, each instruction is encapsulated into an "instruction object," which includes "instruction ID (UUID format, such as 6f4a8d2c-7b1e-439c-8d5a-1234567890ab), instruction type (0x01 / 0x02 / 0x03), parameter set (key-value pair format, such as {"matching threshold":100, "timeout":258}), sender ID (0x0001), and receiving timestamp (YYYYMMDDHHMMSS, such as 20250928143000)." Multiple instruction objects form a parsed instruction object set. For example, the set may contain three objects: face recognition instruction (ID1), location tracking instruction (ID2), and security authentication instruction (ID3).

[0020] The parsed instruction object set is categorized by instruction type and stored in the instruction cache queue, with a receiving timestamp appended to generate the categorized instruction cache queue.

[0021] The parsed instruction objects need to be stored according to type to avoid mixing different functional instructions and causing execution chaos. At the same time, a precise timestamp should be attached to facilitate subsequent priority sorting (the urgency can be judged by the time of receipt).

[0022] First, determine the instruction type classification rules. Based on the instruction type field of the LECP protocol, instructions are divided into three queues: Face recognition instruction queue (Type-01): Stores objects with instruction type 0x01, used to drive the face recognition module of the electronic lock (such as the front camera and face algorithm chip). The queue adopts the FIFO (first-in, first-out) mechanism and has a capacity of 20 (to meet multiple face recognition requests in a short period of time, such as multiple trucks unloading cargo in succession). Location tracking instruction queue (Type-02): Stores objects with instruction type 0x02, used to drive the GPS / BeiDou positioning module. The queue capacity is 10 (location tracking instructions have long execution cycles, so a large-capacity cache is not required). Security Authentication Instruction Queue (Type-03): Stores objects with instruction type 0x03, used to drive the encryption chip to complete key verification. The queue capacity is 5 (security authentication instructions have high priority and need to be executed quickly, so the cache size is small to avoid backlog).

[0023] During storage, a "receive timestamp" (accurate to milliseconds, format YYYYMMDDHHMMSSfff, e.g., 20250928143000123) must be appended to each instruction object. The timestamp is provided by the electronic lock's RTC real-time clock module (accuracy ±1 second / day, ensuring time accuracy). For example: The face recognition instruction object (ID1) was received at 14:30:00.123 and stored in the Type-01 queue, located at position 1 in the queue; The location tracking instruction object (ID2) was received at 14:30:01.456 and stored in the Type-02 queue, located at position 1. The security authentication instruction object (ID3) was received at 14:30:02.789 and stored in the Type-03 queue, located at position 1.

[0024] Queue management needs to handle the "queue full" scenario: When a queue reaches its capacity limit (e.g., the Type-01 queue already has 20 instructions), newly received instructions of the same type will trigger a "discard policy"—discarding the oldest instruction received in the queue (FIFO principle), and simultaneously recording a discard log (stored in the electronic lock's Flash memory, the log includes instruction ID, discard time, and queue capacity) to prevent queue overflow from preventing subsequent instructions from being received. For example, after the Type-01 queue is full, a newly received ID4 face recognition instruction will discard the oldest ID1 instruction, and ID4 will be stored in the 20th position of the queue.

[0025] The final generated classification instruction cache queue must maintain "type independence and time order". The instructions in each queue are arranged in ascending order according to the received timestamp, which facilitates the quick retrieval of the latest instructions in subsequent steps. At the same time, it supports cross-queue priority scheduling (such as security authentication instructions taking precedence over face recognition instructions), laying the foundation for the generation of instruction execution sequences.

[0026] S202, perform instruction type parsing and priority sorting on the multi-type function control instructions to generate an instruction execution sequence with time-sensitive markers; Specifically, it may include: S2021, reading a set of instruction objects from the classification instruction cache queue, extracting the type identifier and parameter information of each instruction object, and generating an instruction attribute dataset; The categorized instruction cache queue contains three independent queues, each corresponding to different functional instructions: Queue Type-01 stores face recognition control instructions (instruction type identifier 0x01), Queue Type-02 stores location tracking control instructions (identifier 0x02), and Queue Type-03 stores security authentication control instructions (identifier 0x03). Each queue is arranged in ascending order of its received timestamp (the earliest received instruction is located at the head of the queue). The reading process requires traversing all queues and extracting unexecuted instruction objects from each queue (executed instructions are marked "complete" and are not read). For example, the security authentication instruction object (ID3) is read from Queue Type-03, the face recognition instruction object (ID1) from Queue Type-01, and the location tracking instruction object (ID2) from Queue Type-02, forming a set containing three instruction objects.

[0027] When extracting the "type identifier" and "parameter information," parsing must be based on the preset structure of the instruction object: the type identifier is a 1-byte field (0x01 / 0x02 / 0x03), which is extracted directly from the instruction object header; the parameter information is in key-value pair format, and the parameter fields differ for different instruction types, requiring extraction according to the protocol definition. Face recognition control command (ID1, type identifier 0x01): Parameters include "face matching threshold" (value range 0-255, corresponding to matching degree 0%-100%, in this example the value is 0x64, i.e. 100, representing a matching degree ≥39%), "recognition timeout" (value range 10-300 seconds, in this example the value is 0x0102, i.e. 258 seconds, if recognition is not performed within the timeout, the lock will be locked), and "authorization template ID" (string format, in this example "FACE-20250928-001", corresponding to the pre-stored face template); Location tracking control command (ID2, type identifier 0x02): Parameters include "tracking frequency" (range 10-3600 seconds / time, in this example the value is 0x003C, i.e., 60 seconds / time), "positioning mode" (0x0001 represents GPS single mode, 0x0002 represents GPS + Beidou dual mode, in this example 0x0002), and "tracking duration" (range 3600-86400 seconds, in this example the value is 0x00015180, i.e., 100000 seconds, approximately 27.8 hours); Security authentication control command (ID3, type identifier 0x03): Parameters include "key validity period" (timestamp format, 0x20250928150000 in this example, representing expiration on September 28, 2025 at 15:00:00), "dynamic key" (hexadecimal string, "1A2B3C4D5E6F7A8B" in this example), and "number of authentication retries" (value range 1-5 times, 0x03 in this example, i.e. 3 times; if the number of retries is exceeded, the lock will alarm).

[0028] The final generated command attribute dataset must contain four core fields: "Command ID, Type Identifier, Parameter List, and Receive Timestamp". An example dataset fragment is as follows: "Command ID3: Type Identifier 0x03, Parameters {Key Validity: 20250928150000, Dynamic Key: 1A2B3C4D5E6F7A8B, Retry Count: 3}, Receive Timestamp: 20250928143002789; Command ID1: Type Identifier 0x01, Parameters {Matching Threshold: 100, Timeout: 258, Template ID: FACE-20250928-001}, Receive Timestamp: 20250928143000123; Command ID2: Type Identifier 0x02, Parameters {Tracking Frequency: 60, Location Mode: 0x0002, ... Tracking duration: 100,000, receiving timestamp: 20250928143001456, ensuring that subsequent steps can be directly based on this dataset for priority calculation.

[0029] S2022, based on the instruction attribute dataset, uses a rule engine to analyze the urgency of instructions, and combines the time constraints defined by the instruction type to calculate the initial priority score of each instruction, thus obtaining the instruction priority score set; The rule engine is the core tool for analyzing the urgency of instructions. Here, the Drools rule engine (a lightweight industrial-grade rule engine that supports dynamically loaded rules) is selected. Rule design needs to be combined with the business scenario of logistics electronic locks—security authentication involves lock access control and has the highest urgency; facial recognition is associated with loading and unloading efficiency and has the second highest urgency; location tracking is for periodic monitoring and has the lowest urgency. At the same time, "time constraints" (time-related fields in the instruction parameters) need to be introduced as the basis for adjusting the urgency to avoid priority deviations caused by sorting by type alone.

[0030] 1. Core rule definition of the rule engine The rules adopt a "condition-action" structure. Conditions are based on instruction type and time constraints, and actions adjust scores according to urgency (positive adjustments add points, negative adjustments deduct points). The specific rules are as follows: Rule 1 (Urgency of Security Authentication Commands): If the command type is identified as 0x03 (Security Authentication), the basic urgency level is adjusted by +20 points; if "Key Expiration - Current Time" < 3600 seconds (1 hour), an additional 10 points are added (the key is about to expire and authentication should be prioritized); if "Number of Authentication Retry Counts" ≤ 2, an additional 5 points are added (few retry opportunities, alarms should be avoided due to excessive retry counts). Rule 2 (Urgency of Face Recognition Commands): If the command type is identified as 0x01 (Face Recognition), the basic urgency level is adjusted by +10 points; if the "Recognition Timeout" is <300 seconds (5 minutes), an additional 3 points are added (timeout will lock the system, affecting loading and unloading); if the "Face Matching Threshold" is >128 (matching accuracy requirement ≥50%), an additional 2 points are deducted (high recognition difficulty, can be appropriately delayed); Rule 3 (Urgency of Location Tracking Commands): If the command type is identified as 0x02 (Location Tracking), the base urgency level is adjusted by +5 points; if the "tracking frequency" is <300 seconds (5 minutes / time), an additional 2 points are added (high-frequency tracking should be initialized first); if the "tracking duration" is >86400 seconds (24 hours), an additional 3 points are deducted (long-term tracking can be started later). Rule 4 (General Time Constraint Rule): If "Current Time - Command Received Timestamp" > 60 seconds (the command has been received for more than 1 minute without being processed), add 5 points regardless of the type (to avoid command backlog).

[0031] 2. Initial priority score calculation Initial priority score = base score + urgency adjustment score, where the "base score" is preset according to the instruction type (based on business importance): security authentication instruction base score 80 points, face recognition instruction base score 60 points, location tracking instruction base score 50 points; the adjustment score is calculated by the rule engine according to the above rules, and the current time is set to 20250928143030000 (processed within 30 seconds after instruction is received, rule 4 will not be triggered).

[0032] Taking three instructions from the instruction attribute dataset as an example, the specific calculation process is as follows: Command ID3 (Security Authentication): Base score 80 points; Rule 1 triggered, base adjustment score +20 points, "Key validity period - current time" = 20250928150000 - 20250928143030 = 2970 seconds (>3600 seconds, no extra points), "Number of retries = 3 times (>2 times, no extra points)," total adjustment score +20 points; initial priority score = 80 + 20 = 100 points; Instruction ID1 (Face Recognition): Base score 60 points; Rule 2 triggered, base adjustment score +10 points, "Recognition timeout = 258 seconds (<300 seconds, add 3 points)", "Matching threshold = 100 (<128, no deduction)", total adjustment score +13 points; Initial priority score = 60 + 13 = 73 points; Command ID2 (Location Tracking): Base score 50 points; Rule 3 triggered, base adjustment score +5 points, "tracking frequency = 60 seconds (<300 seconds, add 2 points)", "tracking duration = 100000 seconds (>86400 seconds, subtract 3 points)", total adjustment score +4 points; initial priority score = 50 + 4 = 54 points; The final set of instruction priority scores is: "ID3: 100 points, ID1: 73 points, ID2: 54 points". These scores only reflect the urgency of the instruction itself and do not take into account the real-time operating status of the electronic lock. Further dynamic adjustments are needed.

[0033] S2023: Based on the real-time status data of the electronic lock, including battery level, network bandwidth and the current working mode of the lock, the command priority score is dynamically adjusted to obtain a dynamic priority score set. The real-time status of an electronic lock directly affects the executability of commands. When the battery is low, low-power commands should be prioritized; when the network is poor, bandwidth-intensive commands should be avoided. The current operating mode will affect the resource consumption of new commands. Real-time status data is collected by the electronic lock's built-in sensors and modules at a sampling frequency of 1 second per scan to ensure data timeliness. The adjustment logic must be designed based on "status-command compatibility" to avoid command execution failures due to status mismatches (such as low battery triggering a high-power positioning module, causing the lock to lose power).

[0034] 1. Real-time status data acquisition and classification Battery power: The battery voltage (the electronic lock uses a 3.7V lithium battery with a capacity of 5000mAh) is collected by a voltage sensor and converted into the remaining power percentage: high power level (≥80%, corresponding voltage ≥3.7V), medium power level (30%-80%, corresponding voltage 3.3-3.7V), low power level (<30%, corresponding voltage <3.3V). In this example, the collected value is 3.5V, which is converted to 60%, belonging to the medium power level. Network bandwidth: Real-time uplink / downlink bandwidth is collected through the wireless communication module (4G Cat.1), and the average value is taken as the network bandwidth: high bandwidth level (≥500kbps, meeting the requirements of face recognition image transmission), medium bandwidth level (100-500kbps, meeting the requirements of location data transmission), low bandwidth level (<100kbps, only able to transmit small-sized commands). In this example, the collected value is 350kbps, which belongs to the medium bandwidth level. The current working mode of the lock can be read through the system status register, including standby mode (no module running, lowest power consumption), face recognition mode (camera + algorithm chip running, medium power consumption), positioning mode (GPS / BeiDou module running, high power consumption), and authentication mode (encryption chip running, low power consumption). In this example, the electronic lock is currently in standby mode (no module occupied).

[0035] 2. Dynamic adjustment rules and score calculation Dynamic adjustment score = initial priority score + state adaptation adjustment score. The adjustment score is set according to the adaptability of "state-instruction". Higher adaptability adds points (ensuring priority execution), and lower adaptability subtracts points (avoiding execution failure). The specific adjustment rules are as follows: Battery power adaptation adjustment: Security authentication command (encryption chip power consumption ≤ 50mA) adapts to all power levels, add 2 points; Face recognition command (camera + algorithm chip power consumption ≤ 150mA) adds 1 point for high / medium power, subtracts 5 points for low power; Location tracking command (positioning module power consumption ≤ 300mA) adds 1 point for high power, no adjustment for medium power, subtracts 10 points for low power. Network bandwidth adaptation adjustment: Security authentication command (key transmission amount ≤ 100 bytes, low bandwidth requirement) adds 2 points; Face recognition command (image transmission amount ≥ 500KB, high bandwidth requirement) adds 3 points on high bandwidth, no adjustment on medium bandwidth, and subtracts 8 points on low bandwidth; Location tracking command (location data ≤ 100 bytes, low bandwidth requirement) adds 1 point. Current working mode adaptation and adjustment: If the current mode does not conflict with the module that the instruction needs to start (e.g., standby mode adapts to all instructions), add 3 points; if there is a conflict (e.g., in the current positioning mode, new positioning instructions need to wait), subtract 5 points; Based on the real-time status of this example (medium battery level, medium bandwidth, standby mode), the dynamic adjustments to the three commands are as follows: Command ID3 (Security Authentication): Battery compatibility +2 points, network compatibility +2 points, mode compatibility +3 points, total adjustment score +7 points; Dynamic priority score = 100 + 7 = 107 points; Command ID1 (Face Recognition): Battery adaptation (medium battery level) +1 point, network adaptation (medium bandwidth) no adjustment, mode adaptation +3 points, total adjustment points +4 points; dynamic priority score = 73 + 4 = 77 points; Command ID2 (Location Tracking): Battery adaptation (medium battery level) no adjustment, network adaptation +1 point, mode adaptation +3 points, total adjustment score +4 points; dynamic priority score = 54 + 4 = 58 points; If the real-time status changes to "Low power (25%), low bandwidth (80kbps), location mode", the adjustment results will be different: Command ID2 (location tracking) loses 10 points due to low power and 5 points due to mode conflict, resulting in a dynamic score of 54 - 10 - 5 + 1 (network adaptation) = 40 points; Command ID1 (face recognition) loses 5 points due to low power and 8 points due to low bandwidth, resulting in a dynamic score of 73 - 5 - 8 + 3 (mode adaptation) = 63 points. It is evident that the real-time status significantly impacts priority, and dynamic adjustment ensures the feasibility of command execution. In this example, the final dynamic priority score set is: "ID3: 107 points, ID1: 77 points, ID2: 58 points".

[0036] S2024, based on a dynamic priority score set, uses a time sensitivity assessment algorithm to label each instruction with a time sensitivity level according to the instruction failure time and execution delay risk, generating a time sensitivity label set; Time sensitivity reflects the "risk level of delayed execution" of an instruction—the closer the expiration time, the higher the risk of delay, and the higher the sensitivity level, requiring priority execution. The time sensitivity assessment algorithm quantifies the "expiration time window" (the difference between the instruction's expiration time and the current time) and the "delay risk coefficient" (the smaller the window, the larger the coefficient), ultimately mapping to a three-level sensitivity (High H, Medium M, Low L). This avoids prioritizing instructions with "high scores but low sensitivity" simply by ranking them by priority score (e.g., high-score instructions that are valid for a long time can be delayed).

[0037] 1. Definition and Calculation of Key Parameters Command expiration time: Extract time-related fields from the command parameters as the expiration time. For commands without an explicit time field (such as position tracking without timeout), the default expiration time is "current time + 86400 seconds (24 hours)". Security Authentication Command (ID3): Expiration Time = Key Validity Period = 20250928150000; Face recognition command (ID1): Expiration time = Received timestamp + Recognition timeout = 20250928143000123 + 258 seconds = 20250928143418123; Location tracking command (ID2): Expiration time = current time + 86400 seconds = 20250929143030000; Failure time window ΔT = Failure time - Current time (current time 20250928143030000): ID3: ΔT = 20250928150000 - 20250928143030 = 2970 seconds (approximately 49.5 minutes); ID1: ΔT = 20250928143418123 - 20250928143030000 = 228 seconds (approximately 3.8 minutes); ID2: ΔT = 20250929143030000 - 20250928143030000 = 86400 seconds (24 hours); Delay risk coefficient R: R = 100 / ΔT (ΔT is in seconds). The larger the coefficient, the higher the risk of delayed execution (the smaller ΔT is, the larger R is): ID3: R = 100 / 2970 ≈ 0.034; ID1: R = 100 / 228 ≈ 0.439; ID2: R = 100 / 86400 ≈ 0.001; 2. Sensitivity Level Mapping Rules By combining "dynamic priority score" and "delay risk coefficient", a three-level sensitivity mapping rule is set: High sensitivity (H): meets any of the following conditions: ΔT < 300 seconds (5 minutes), or R ≥ 0.3, or (dynamic score ≥ 80 points and ΔT < 3600 seconds); Medium sensitivity (M): meets any of the following conditions: 300 seconds ≤ ΔT < 3600 seconds, or 0.02 ≤ R < 0.3, or (dynamic score 60-79 points and ΔT < 86400 seconds); Low sensitivity (L): ΔT ≥ 3600 seconds, R < 0.02, and dynamic score < 60 points; Label the sensitivity levels of the three instructions according to the rules: Instruction ID1 (ΔT = 228 seconds < 300 seconds, R = 0.439 ≥ 0.3): High sensitivity (H); Command ID3 (Dynamic score 107 points ≥ 80 points, ΔT = 2970 seconds < 3600 seconds): High sensitivity (H); Instruction ID2 (ΔT=86400 seconds ≥ 3600 seconds, R=0.001<0.02, dynamic score 58 points < 60 points): Low sensitivity (L); It should be noted here that both ID1 and ID3 are highly sensitive, but ID1 has a smaller ΔT (higher risk of delay), and further differentiation is needed in subsequent sorting; ID2 is low sensitive and can be executed last. The final generated time-sensitive tag set is: "ID3: H, ID1: H, ID2: L".

[0038] S2025 integrates the dynamic priority score set and the time-sensitive tag set, and uses a sorting algorithm to generate an instruction execution sequence with time-sensitive tags and priority information.

[0039] The sorting algorithm needs to consider both "time sensitivity level" and "dynamic priority score," while also taking into account "instruction reception timestamp" (instructions with the same level and score are executed first, with priority given to those received earlier), to avoid logical loopholes caused by single-dimensional sorting (e.g., instructions with high sensitivity but low score should be prioritized over instructions with low sensitivity and high score). Here, a "multi-key sorting algorithm" is chosen, with sorting priority from highest to lowest as follows: time sensitivity level (H>M>L) → dynamic priority score (descending order) → instruction reception timestamp (ascending order).

[0040] 1. Sorting process and rule application First, the two datasets are integrated to form a relational table of "Instruction ID - Dynamic Score - Sensitivity Level - Receipt Timestamp": ID3: Dynamic score 107, sensitivity H, reception time 20250928143002789; ID1: Dynamic score 77, sensitivity H, reception time 20250928143000123; ID2: Dynamic score 58, sensitivity L, reception time 20250928143001456; The first step is to group by "sensitivity level": high sensitivity group (ID3, ID1) and low sensitivity group (ID2), with the high sensitivity group taking precedence over the low sensitivity group as a whole; the second step is to sort within the high sensitivity group by "dynamic score in descending order": ID3 (107 points) > ID1 (77 points), so the order of the high sensitivity group is ID3 → ID1; the third step is to sort within the low sensitivity group by "dynamic score in descending order": only ID2, so the order is ID2; the fourth step is to sort if there are "same level and same score" instructions (such as another ID4 instruction, dynamic score 77 points, sensitivity H, reception time 20250928143003000), then sort by "reception timestamp in ascending order", with ID1 (14:30:00) taking precedence over ID4 (14:30:03).

[0041] 2. Generation of the final instruction execution sequence The sequence must include "execution order, instruction ID, instruction type, dynamic priority score, time sensitivity level, and estimated execution time" (the estimated execution time is based on historical execution data statistics; security authentication takes approximately 2 seconds, face recognition approximately 5 seconds, and location tracking approximately 3 seconds), to facilitate subsequent resource allocation. Execution sequence 1: Instruction ID3, type security authentication (0x03), dynamic score 107, sensitivity H, estimated execution time 2 seconds; Execution sequence 2: Instruction ID1, type: face recognition (0x01), dynamic score: 77, sensitivity: H, estimated execution time: 5 seconds; Execution sequence 3: Instruction ID2, type location tracking (0x02), dynamic score 58, sensitivity L, estimated execution time 3 seconds; This sequence ensures that high-sensitivity instructions are executed first (avoiding ID1 timeout locking), distinguishes the priority of instructions with the same sensitivity according to dynamic scores (ID3 security authentication is more important), and provides a time basis for subsequent resource scheduling by predicting the execution time, ensuring that the instructions are executed in an orderly and efficient manner, and meeting the needs of concurrent processing of multiple instructions in logistics scenarios.

[0042] S203, Based on the instruction execution sequence, a multimodal fusion decision model is used for dynamic analysis and resource allocation to generate an instruction execution scheme that includes execution timing and resource scheduling; Specifically, it may include: S2031, reading the instruction execution sequence, extracting the time sensitivity markers and priority information from the instruction sequence, and generating sequence analysis data; The instruction execution sequence is an ordered set of instructions sorted by priority and marked with time sensitivity, containing core information such as execution order, instruction ID, type identifier, dynamic priority score, time sensitivity level, and estimated execution time. The reading process requires the electronic lock's central processing unit (CPU, using an ARM Cortex-M4 core, 80MHz clock speed) to traverse the sequence list and load the complete sequence data from non-volatile memory (Flash, 1MB capacity), ensuring a data read speed ≥100KB / s (meeting real-time processing requirements).

[0043] When extracting information, two types of key data need to be parsed for each instruction object: time sensitivity markers and priority information. Time sensitivity markers are divided into three levels: high (H), medium (M), and low (L), and are read directly from the sequence field; priority information includes a dynamic priority score (0-100 points) and a relative priority order (execution order). Taking the actual instruction sequence of a logistics electronic lock as an example, it contains three instructions: Instruction 1: ID=SEC-20250928-001, Type=Security Authentication (0x03), Dynamic Priority Score=107, Time Sensitivity=H, Estimated Execution Time=2 seconds, Execution Order=1; Instruction 2: ID=FACE-20250928-001, Type=Face Recognition (0x01), Dynamic Priority Score=77, Time Sensitivity=H, Estimated Execution Time=5 seconds, Execution Order=2; Command 3: ID=GPS-20250928-001, Type=Location Tracking (0x02), Dynamic Priority Score=58, Time Sensitivity=L, Estimated Execution Time=3 seconds, Execution Order=3.

[0044] The generated sequence analysis data needs to integrate the above information in a structured format, including six fields: "unique instruction identifier, execution priority ranking, time sensitivity level, dynamic priority quantification value, function type, and estimated resource consumption time." For example: "SEC-20250928-001: Priority 1, sensitivity H, score 107, type security authentication, estimated 2 seconds; FACE-20250928-001: Priority 2, sensitivity H, score 77, type face recognition, estimated 5 seconds; GPS-20250928-001: Priority 3, sensitivity L, score 58, type location tracking, estimated 3 seconds." This data will serve as input to the multimodal fusion decision model, providing a basis for resource requirement calculation.

[0045] S2032, based on sequence analysis data and system resource status, calculates the resource type and resource quantity required for each instruction through an AI-based multimodal fusion decision model, and generates a resource requirement mapping table; System resource status is a fundamental constraint for instruction execution and needs to be collected and quantified in real time. The multimodal fusion decision model is responsible for combining sequence analysis data with resource status to accurately predict the resource requirements of each instruction. The resource requirement mapping table needs to clearly define the correspondence between instructions and "resource type - resource quantity" to provide a basis for subsequent allocation.

[0046] 1. Collection and quantification of system resource status The system resources of an electronic lock include hardware and software resources, which are collected in real time and quantified into calculable values ​​through a built-in monitoring module (sampling frequency 10Hz): Hardware resources: CPU (ARM Cortex-M4): Current utilization rate (0%-100%, 15% in this example), available computing power (clock frequency × number of cores × (1 - utilization rate) = 80MHz × 1 × 85% = 68MHz); Memory (RAM, capacity 256KB): 100KB used, 156KB available; Encryption chip (Chinese national cryptographic SM4 algorithm): Current status (idle / occupied, idle in this example), processing rate (100KB / s); Camera module (2 megapixels): Current status (idle), power consumption (150mA when working); GPS / BeiDou module: Current status (idle), positioning time (cold start 30 seconds, warm start 5 seconds), power consumption (300mA when working); Wireless communication module (4G Cat.1): Current bandwidth (350kbps uplink, 500kbps downlink), signal strength (-75dBm, good).

[0047] Software resources: Face recognition algorithm process: Current state (not running), required memory (50KB); Location service process: Current status (not running), required memory (30KB).

[0048] 2. Structure and Reasoning Process of Multimodal Fusion Decision Model The model employs a dual-modal fusion architecture of "rule-based reasoning + deep learning," balancing decision interpretability and prediction accuracy. Rule reasoning module: Determines resource types based on preset business rules, such as "security authentication commands must call the encryption chip" and "face recognition commands must enable the camera and face algorithm process"; Deep learning module: It adopts a lightweight neural network (MobileNetV2 compressed version, with about 1 million parameters). The input is "instruction type, dynamic priority score, expected execution time, and current system resource utilization". The output is the resource quantity prediction value (such as CPU utilization and memory requirement). The model is trained with 5,000 historical instruction data and the resource quantity prediction error is ≤5%.

[0049] Taking instruction 1 (security authentication) as an example, the model inference process is as follows: Rule-based reasoning: Determine that the encryption chip, CPU (for data interaction), and communication module (for uploading key verification results) need to be invoked. Deep Learning: Input "Type = Security Authentication, Score = 107, Duration = 2 seconds, CPU Utilization = 15%", Output resource requirements: Encryption chip 100% (exclusive throughout), CPU Utilization 30% (within 2 seconds), Communication module bandwidth requirement 50kbps (uploading verification results), Memory requirement 20KB (storing temporary keys).

[0050] Similarly, the inference result of instruction 2 (face recognition) is: camera usage 100% (5 seconds), face algorithm process uses 50KB of memory, CPU usage 60% (image processing), and communication module bandwidth requirement 300kbps (uploading face features); the inference result of instruction 3 (location tracking) is: GPS module usage 100% (3 seconds), CPU usage 20% (data parsing), and memory requirement 30KB (storing location data).

[0051] 3. Generation of the resource requirement mapping table The mapping table adopts a four-dimensional structure of "Instruction ID - Resource Type - Resource Quantity - Demand Period", which clearly defines the specific resource requirements of each instruction during execution. For example: SEC-20250928-001: Encryption chip (100%, 0-2 seconds), CPU (30%, 0-2 seconds), communication module (50kbps, 1.5-2 seconds), memory (20KB, 0-2 seconds); FACE-20250928-001: Camera (100%, 2-7 seconds), Face algorithm process (100%, 2-7 seconds), CPU (60%, 2-7 seconds), Communication module (300kbps, 6-7 seconds), Memory (50KB, 2-7 seconds); GPS-20250928-001: GPS module (100%, 7-10 seconds), CPU (20%, 7-10 seconds), memory (30KB, 7-10 seconds).

[0052] S2033 employs a resource allocation algorithm, combines a resource demand mapping table to optimize resource scheduling, avoid resource conflicts, determine the execution time window of instructions, and generate a preliminary resource allocation scheme. The core of resource allocation is to avoid multiple instructions simultaneously occupying the same resource (resource conflict) while meeting the resource requirements of each instruction. It also involves determining the execution time window (start time and end time) based on instruction priority and expected duration. An improved greedy algorithm (balancing priority and resource utilization) is used here to ensure that high-sensitivity, high-priority instructions receive resources first, and that the overall system resource utilization is ≥70% (avoiding resource waste).

[0053] 1. Resource conflict detection and resolution mechanism The algorithm first traverses the resource demand mapping table to identify potential conflicts: a conflict occurs when multiple instructions request the same resource within the same time period. For example, if both instruction 1 and instruction 2 require CPU time and their initial estimated time windows overlap (0-2 seconds and 2-7 seconds overlap by 0.5 seconds), then it is determined to be a CPU resource conflict. The resolution mechanism follows the "priority preemption" principle: high-priority instructions retain their original time windows, while low-priority instructions are deferred until the resource becomes available.

[0054] Taking CPU resources as an example, instruction 1 (priority 1) needs to occupy 30% of the CPU in the first 0-2 seconds, and instruction 2 (priority 2) needs to occupy 60% of the CPU in the first 2-7 seconds. There is a 0.1-second overlap at the 2-second mark (instruction 1 ends at 2.0 seconds, and instruction 2 is scheduled to start at 2.0 seconds), triggering a conflict. The algorithm delays the start time of instruction 2 by 0.1 seconds to 2.1 seconds, and correspondingly delays its end time to 7.1 seconds, ensuring that CPU resources are completely released before being occupied again in the 2.0-2.1 seconds period, thus resolving the conflict.

[0055] 2. Determining the execution time window The time window is calculated based on "the end time of the preceding instruction + the resource preparation time". The resource preparation time refers to the time it takes for the module to start from idle (0.1 seconds for the encryption chip, 0.5 seconds for the camera, and 0.2 seconds for the GPS module's hot start). Instruction 1 (Security Authentication): As the first instruction to be executed, the start time is equal to the current system time (20250928143030.000), the resource preparation time is 0.1 seconds (encryption chip starts), and the actual execution window is 143030.100-143032.100 (2 seconds). Instruction 2 (Face Recognition): Precedence instruction end time 143032.100, resource preparation time 0.5 seconds (camera start), start time = 143032.600, execution window = 143032.600-143037.600 (5 seconds); Command 3 (Location Tracking): Precedence command end time 143037.600, resource preparation time 0.2 seconds (GPS module starts), start time = 143037.800, execution window = 143037.800-143040.800 (3 seconds).

[0056] 3. Contents of the preliminary resource allocation plan The solution must include an "instruction execution timing table" and a "resource usage matrix": Timing table: Clearly defines the start time, end time, execution duration, and delay reason (if any) for each instruction. For example, "Instruction 1: 143030.100-143032.100 (2 seconds, no delay); Instruction 2: 143032.600-143037.600 (5 seconds, delayed by 0.1 seconds due to CPU conflict); Instruction 3: 143037.800-143040.800 (3 seconds, no delay)". Resource occupancy matrix: Records the occupancy of each resource according to the time axis, for example, "Encryption chip: 143030.100-143032.100 (occupied by instruction 1); Camera: 143032.600-143037.600 (occupied by instruction 2); GPS module: 143037.800-143040.800 (occupied by instruction 3); CPU: 143030.100-143032.100 (30%), 143032.600-143037.600 (60%), 143037.800-143040.800 (20%)".

[0057] S2034, combining instruction dependencies and system constraints of the electronic lock, performs timing optimization on the preliminary resource allocation scheme, and finally generates an instruction execution scheme that includes execution timing and resource scheduling.

[0058] The initial solution may have unconsidered instruction dependencies (e.g., one instruction requires the result of another instruction as input) and system constraints (e.g., battery power limits high-power operations), requiring further optimization to ensure feasibility. Timing optimization employs a "constraint satisfaction algorithm" to minimize the total execution time (instruction 3 end time - instruction 1 start time) while satisfying all dependencies and constraints, thereby improving execution efficiency.

[0059] 1. Identification and processing of instruction dependencies Instruction dependencies are divided into "hard dependencies" (must be satisfied, otherwise instruction execution will fail) and "soft dependencies" (recommended to be satisfied to improve execution performance): Hard dependencies: For example, "the face recognition command (command 2) requires the successful result of the security authentication command (command 1) as a prerequisite" (users who fail security authentication cannot trigger face recognition unlocking). Command 2 can only start after command 1 is executed successfully. Soft dependency: For example, "If the location tracking instruction (instruction 3) is executed after the face recognition instruction (instruction 2), it can associate people with location information", but the order is not mandatory.

[0060] In this example, instruction 2 has a hard dependency on instruction 1. Therefore, a "verification step for instruction 1 execution result" (0.2 seconds) needs to be added to the initial plan: After instruction 1 finishes (143032.100), the system uses 0.2 seconds to verify its success. If successful, instruction 2 will start as planned at 143032.600; if it fails, instruction 2 will be terminated to avoid invalid execution. Therefore, the actual start time of instruction 2 = instruction 1 end time + verification time + resource preparation time = 143032.100 + 0.2 + 0.5 = 143032.800, and the execution window is adjusted to 143032.800-143037.800.

[0061] 2. Application of system constraints The system constraints are set based on the hardware performance and operating status of the electronic lock. The core constraints include: Battery power constraint: Current battery level is 60% (medium battery level). The duration of a single high-power operation (such as GPS module, 300mA) is ≤10 seconds to avoid rapid battery depletion. In this example, the GPS module in instruction 3 is used for 3 seconds, which meets the constraint. Temperature constraint: When the CPU temperature is ≥60℃, the CPU utilization rate needs to be reduced to below 50%; the current temperature is 45℃, so there is no impact. Communication constraints: When the signal strength is <-90dBm, pause commands that depend on communication; the current signal strength is -75dBm, which meets the requirements.

[0062] If the battery level drops to 20% (low battery), the execution parameters of instruction 3 need to be adjusted: reduce the GPS module's working time to 2 seconds (only one location acquisition), and reduce the CPU utilization to 15%, ensuring that the total power consumption is ≤50mA·h.

[0063] 3. Generation of the final instruction execution plan The integrated and optimized timing and resource scheduling information comprises four core parts: Execution timeline summary: Clearly defines the final time window for all instructions, for example, "Instruction 1: 143030.100-143032.100 (security authentication, successful verification); Instruction 2: 143032.800-143037.800 (face recognition, dependent on instruction 1, successful); Instruction 3: 143038.000-143041.000 (location tracking, no dependency)". Resource scheduling details: List the time periods and utilization rates by resource type, for example, "CPU: 143030.100-143032.100 (30%), 143032.800-143037.800 (60%), 143038.000-143041.000 (20%); Communication module: 143031.600-143032.100 (50kbps, instruction 1), 143037.300-143037.800 (300kbps, instruction 2)"; Dependency description: Mark hard dependencies, such as "Instruction 2 depends on the successful execution of instruction 1, and the verification process takes 0.2 seconds"; Constraint fulfillment verification: Confirm that all constraints are met, such as "Battery charge is 60%, total power consumption is expected to be 25mA・h (≤5000mAh×30%=1500mAh), which meets the low power protection requirements".

[0064] This solution can be directly used as an operational guide for electronic locks to execute commands, ensuring that all modules work together, avoiding resource conflicts and execution failures, and meeting the needs for efficient and secure command processing in logistics scenarios.

[0065] S204, drive the corresponding lock function module to perform operations according to the instruction execution scheme, and verify the instruction execution result in real time during the execution process.

[0066] Specifically, it can parse the execution timing and resource scheduling information in the instruction execution scheme to generate a module-driven instruction set; The instruction execution plan includes three core types of information: "execution timing summary table", "resource scheduling details", and "dependency description". The parsing process requires the central control unit of the electronic lock (CPU adopts ARM Cortex-M4, main frequency 80MHz) to traverse the scheme data structure, decompose the macro execution plan into specific drive instructions that can be recognized by each lock functional module (encryption chip, camera, GPS module, etc.), and ensure that each instruction contains four key elements: "module identifier, operation type, parameter configuration, and execution time window" to avoid execution deviations caused by missing parameters.

[0067] Taking the actual implementation scheme of a logistics electronic lock as an example, the scheme clearly defines the key information of three instructions: Security authentication command (ID: SEC-20250928-001): Execution sequence 143030.100-143032.100, resource scheduling is encryption chip (100% utilization), CPU (30% utilization), communication module (50kbps bandwidth, upload from 143031.600-143032.100), no dependencies; Face recognition command (ID: FACE-20250928-001): Execution time 143032.800-143037.800, resource scheduling is camera (100% utilization), face algorithm chip (50KB memory), CPU (60% utilization), security authentication command successful; Location tracking instruction (ID: GPS-20250928-001): Execution time 143038.000-143041.000, resource scheduling is GPS module (100% utilization), memory (30KB), CPU (20% utilization), no dependencies.

[0068] During parsing, the splitting instruction must be based on the "module dimension": Encryption chip module (model: SM4 hardware encryption chip): The driver instruction must include "Operation type = key verification", "Key data = 1A2B3C4D5E6F7A8B", "Timeout = 2 seconds", and "Execution window = 143030.100-143032.100". The "Key data" parameter comes from the resource requirement mapping table of the execution scheme, and the "Timeout" matches the expected execution time. Camera module (model: 2-megapixel CMOS camera): The driving instructions are "Operation type = Image acquisition", "Resolution = 640×480", "Frame rate = 30fps", "Exposure time = 10ms", and "Execution window = 143032.800-143037.800". The resolution and frame rate configuration must match the processing power of the face recognition algorithm chip (the algorithm supports a maximum resolution of 1280×720, and 30fps can meet real-time recognition). GPS module (model: Beidou + GPS dual-mode positioning module): The driving commands are "Operation type = positioning data acquisition", "Positioning mode = hot start", "Sampling frequency = 1Hz", and "Execution window = 143038.000-143041.000". The hot start mode can shorten the positioning time (from 30 seconds for cold start to 5 seconds, matching the expected 3-second execution time). CPU and memory modules: The driver instructions are "CPU utilization configuration = security authentication stage 30%, face recognition stage 60%, location tracking stage 20%" and "memory allocation = face algorithm 50KB, GPS data 30KB, temporary cache 20KB", ensuring that the resource usage in each stage does not exceed the system limit (maximum CPU utilization 90%, total memory capacity 256KB).

[0069] The final generated module driver instruction set is sorted according to execution sequence. Each instruction includes "module ID, instruction priority, and number of retries" (the default number of retries is 3, and an alarm is triggered if there is no response within a timeout). Example instruction snippets are: "Module ID=ENC-01 (encryption chip), instruction= key verification (key: 1A2B3C4D5E6F7A8B, timeout 2 seconds), execution window= 143030.100-143032.100, priority 1, retries 3 times; Module ID=CAM-01 (camera), instruction= image acquisition (resolution 640×480, frame rate 30fps), execution window= 143032.800-143037.800, priority 2, retries 3 times."

[0070] The corresponding lock function module's driver program is called according to the module driver instruction set, triggering the module to perform the operation; Module drivers act as a bridge between "driver instructions" and "hardware modules." Dedicated drivers need to be developed for the different hardware interfaces (SPI, UART, GPIO, etc.) of each module to ensure that instruction parameters are accurately translated into hardware operation signals. The calling process follows a four-step flow: "initialization - configuration - execution - status feedback," to prevent execution failure due to incomplete module initialization.

[0071] 1. Driver type and interface adaptation The drivers for each module need to be compatible with the hardware interface protocol, as detailed below: Encryption chip driver: Developed based on SPI interface, following the national standard SM4 hardware encryption protocol. The driver is stored in the 0x08010000-0x0801FFFF address range (64KB) of the electronic lock's Flash memory. It supports three types of operations: "key writing, encryption operation, and result reading". The interface rate is configured to 1Mbps (balancing transmission speed and stability). Camera driver: Developed based on the USB 2.0 interface and conforming to the V4L2 (Video for Linux 2) standard protocol, the driver supports "resolution switching, exposure adjustment, and frame capture" functions. It communicates with the camera via the UVC (USB Video Class) protocol, ensuring an image data transmission rate ≥10Mbps (meeting the bandwidth requirements of 640×480@30fps: 640×480×3×30=27.648Mbps, USB 2.0 maximum speed 480Mbps, fully compatible). GPS module driver: Developed based on UART interface, conforming to NMEA 0183 protocol (general protocol for positioning devices). The driver supports "positioning mode configuration, sampling frequency setting, and NMEA statement parsing". The UART baud rate is configured to 9600bps (the default output rate of the GPS module to avoid data loss). CPU and memory drivers: Integrated into the real-time operating system (RTOS, using FreeRTOS) kernel of the electronic lock, CPU utilization is controlled through a task scheduling mechanism (creating priority tasks for different instructions, with higher priority tasks occupying more CPU time slices), and memory partitioning and allocation are implemented through a memory management unit (MMU) (dividing 256KB of memory into "algorithm area, data area, and cache area" to avoid memory fragmentation).

[0072] 2. Example of driver invocation process Taking "face recognition command calling camera driver" as an example, the specific process is as follows: Initialization phase: The CPU sends an "initialization instruction (0x01)" to the camera driver. The driver detects the camera hardware connection status (enumerates the device via the USB bus and returns the device ID "CAM-202509"). If the detection is successful, it returns an initialization success code (0x00); if it fails (e.g., poor USB contact), it returns an error code (0x01) and triggers a retry (up to 3 times). Parameter configuration stage: The CPU writes the parameters "resolution 640×480, frame rate 30fps, exposure 10ms" to the camera's registers through the driver (resolution configuration is written to register 0x0002, frame rate is written to register 0x0003). The driver verifies the validity of the parameters (e.g., whether the resolution is within the camera's supported range of 160×120-1280×720). After successful verification, a configuration confirmation code (0x02) is returned. Execution phase: The CPU sends a "start acquisition command (0x03)", and the driver controls the camera to start capturing images. Each frame of the image is transferred to the "image buffer" in memory (address 0x20008000-0x2000FFFF, capacity 512KB) via the USB interface. At the same time, a frame synchronization signal is sent to the CPU (GPIO pin PA5 is set high) to notify the face algorithm chip to read the image. Status feedback phase: During the acquisition process, the driver sends a status feedback to the CPU every 100ms (e.g., "10 frames acquired, no frame drops"). If frame drops occur (frame sequence numbers are not consecutive), a warning code (0x04) is returned and the USB transfer buffer size is automatically adjusted (from 64KB to 128KB) to ensure execution stability.

[0073] The calling process for other modules is similar: when calling the encryption chip driver, the key must be written first before starting the encryption operation; when calling the GPS module driver, an NMEA configuration command (such as "$PMTK101,0,0,0,0,0*32" to set up a hot start) must be sent first before reading the positioning data. The calling results of all drivers are fed back to the CPU in real time. If a module fails to call three times in a row, the CPU triggers an audible and visual alarm (a buzzer sounds and a red LED flashes) and reports the fault information to the cloud platform through the communication module.

[0074] The module execution status data is collected in real time through sensors and data interfaces to generate an execution status data stream. Module execution status data is the core basis for determining whether instructions are executed correctly. It needs to be collected through a "dedicated sensor + standard data interface" to ensure the real-time performance (collection frequency ≥10Hz) and accuracy (error ≤5%) of the data. The collected content includes three types of information: "module working status, key parameter values, and abnormal events". The data stream format must be uniform to facilitate subsequent comparison and verification.

[0075] 1. Sensor and Data Interface Configuration The status acquisition methods and interfaces for each module are as follows: Encryption chip status acquisition: The working status (high level = in operation, low level = idle) is acquired through the status pin (pin PA0) of the GPIO interface, and the operation results (such as the encrypted ciphertext and key verification results) are read through the SPI interface. The acquisition frequency is 10Hz, the SPI interface rate is 1Mbps, and the result reading delay is ≤10ms. Camera status acquisition: Frame status (frame number, frame drop rate, image brightness) is acquired via the UVC feedback endpoint of the USB interface. The internal temperature of the camera is read via the I2C interface (to avoid image distortion caused by overheating). The acquisition frequency is 5Hz (matching the frame rate of 30fps, acquired once every 6 frames), and the I2C interface speed is 100kHz. GPS module status acquisition: Receives NMEA statements via UART interface (mainly parses $GNGGA statements, including latitude and longitude, positioning accuracy, and number of satellites), acquires module power supply voltage via GPIO interface (3.3V±0.1V, abnormal voltage will cause positioning drift), acquisition frequency 1Hz (consistent with GPS sampling frequency), UART baud rate 9600bps; CPU and memory status acquisition: CPU utilization is acquired through the CPU's internal performance monitoring unit (PMU) (statistics are collected every 100ms), and memory utilization (used memory / total memory × 100%) is acquired through the memory management unit (MMU). The acquisition frequency is 10Hz, and the data is directly transmitted to the status buffer through the internal bus without the need for an external interface.

[0076] 2. Generation and format of execution status data stream The data stream uses an ASCII format of "timestamp + module ID + status code + parameter list". Each data entry is 64 bytes long (for easy parsing). The timestamp is accurate to milliseconds (format YYYYMMDDHHMMSSfff). The status code uses a 1-byte hexadecimal value (0x00 = normal, 0x01 = initialization failure, 0x02 = parameter error, 0x03 = execution timeout, 0x04 = data error). The parameter list is arranged in key-value pairs of "parameter name = value", as shown in the example below: Encryption chip status data: "20250928143030.100,ENC-01,0x00, Status = In operation, Key verification progress = 10%, SPI rate = 1Mbps" "20250928143032.000,ENC-01,0x00, Status = Idle, Verification result = Success, Ciphertext = 8A7B6C5D4E3F2A1B"; Camera status data: "20250928143032.800,CAM-01,0x00, Status = Acquiring, Frame Number = 1, Brightness = 500cd / m², Temperature = 42℃" "20250928143037.800,CAM-01,0x00, Status = Idle, Total Frames = 150, Frame Drop Rate = 0%, Matching Degree = 92%"; GPS module status data: "20250928143038.000,GPS-01,0x00, Status = Locating, Number of Satellites = 12, Voltage = 3.3V" "20250928143041.000,GPS-01,0x00, Status = Idle, Latitude = 30.123456°, Longitude = 120.654321°, Accuracy = 5m"; CPU and memory status data: "20250928143030.100,SYS-01,0x00,CPU utilization = 30%,Memory utilization = 39% (100KB / 256KB)" "20250928143032.800,SYS-01,0x00,CPU utilization = 60%,Memory utilization = 54% (138KB / 256KB)".

[0077] The data stream is stored in real time in the circular buffer of the electronic lock (4KB capacity, which cyclically overwrites old data), and at the same time, key data (such as verification results and location data) is uploaded to the cloud platform through the communication module (4G Cat.1) at a frequency of 1 time / second to ensure that the remote monitoring end can keep track of the execution progress in real time.

[0078] The execution status data stream is compared with the expected results in the instruction execution plan. A verification algorithm is used to determine whether the instruction execution was successful, and an instruction execution verification report is generated.

[0079] The verification process requires designing dedicated verification algorithms for the core objectives of different commands. By quantitatively comparing "actual state data" with "expected results," random errors (such as GPS positioning accuracy ±1m) are eliminated, ensuring the reliability of the judgment results. The verification report must include "execution results, verification basis, and anomaly analysis" to provide a basis for subsequent troubleshooting.

[0080] 1. Verification Algorithm Design and Application Examples The verification algorithm needs to be combined with the core requirements of the instruction type, as follows: Security authentication command verification: The core objective is "key verification successful", employing the CRC16 cyclic redundancy check algorithm (polynomial x¹). 6 +x¹ 5+x²+1) performs a CRC calculation between the expected ciphertext in the execution plan (e.g., 8A7B6C5D4E3F2A1B) and the actual ciphertext collected. If the CRC values ​​of the two are consistent (expected CRC=0x1234, actual CRC=0x1234), the verification is considered successful; if they are inconsistent, the error rate is calculated (e.g., for a 1-byte difference, the error rate is 1 / 16=6.25%). If the error rate is ≤10%, it is considered "partially successful, and re-verification is required"; otherwise, it is considered a failure. Face recognition command verification: The core objective is "face matching degree ≥ 80%". A threshold comparison algorithm is used. The execution plan expects a matching degree of ≥ 80%. The actual matching degree collected is 92% (from camera status data). 92% ≥ 80%, so it is judged as successful. If the actual matching degree is 75%, the reason is further analyzed (such as "brightness = 300cd / m² < 400cd / m²" in the status data, which is judged to be due to insufficient lighting leading to low matching degree). Location tracking command verification: The core objective is "positioning accuracy ≤ 10m". An error range judgment algorithm is used. The expected accuracy of the execution plan is ≤ 10m. The actual collected positioning accuracy is 5m (from GPS status data). 5m ≤ 10m, so the judgment is successful. If the actual accuracy is 15m, check "number of satellites = 6 < 8" in the GPS status data. It is determined that the satellite signal is weak, resulting in insufficient accuracy. System resource verification: The core objective is "CPU utilization ≤ 90%, memory utilization ≤ 80%". An upper limit comparison algorithm is used. The actual maximum CPU utilization is 60% ≤ 90%, and the maximum memory utilization is 54% ≤ 80%. If these conditions are met, the system resources are determined to be not overloaded.

[0081] 2. Instruction execution verification report generation The report uses a structured text format and includes four parts: "Basic Instruction Information, Execution Results, Verification Details, and Anomaly Handling Suggestions," as shown in the example below: Report generation time: 20250928143042.000, Electronic lock ID: EL-20250928-001; 1. Security Authentication Directive (ID: SEC-20250928-001) Execution period: 143030.100-143032.100 (actual duration 2.0 seconds, consistent with expectations); Execution result: Success; Verification details: Key verification: Actual ciphertext 8A7B6C5D4E3F2A1B, consistent with expected ciphertext, CRC checksum 0x1234 (consistent); Resource usage: CPU usage up to 30% (≤30% expected), no timeout for encryption chip (2.0 seconds ≤ 2 seconds expected); Anomaly handling suggestion: No anomalies.

[0082] 2. Face recognition command (ID: FACE-20250928-001) Execution period: 143032.800-143037.800 (actual duration 5.0 seconds, consistent with expectations); Execution result: Success; Verification details: Face matching: Actual matching accuracy 92% (≥80% expected), total of 150 frames captured (0% frame drop rate); Hardware status: Camera temperature 42℃ (≤50℃ safety threshold), image brightness 500cd / m² (≥400cd / m² recommended value); Anomaly handling suggestions: No anomalies.

[0083] 3. Location tracking command (ID: GPS-20250928-001) Execution period: 143038.000-143041.000 (actual duration 3.0 seconds, consistent with expectations); Execution result: Success.

[0084] Verification details: Positioning data: Latitude 30.123456°, Longitude 120.654321°, accuracy 5m (≤10m expected); Module status: Number of satellites 12 (≥8 recommended value), power supply voltage 3.3V (compliant with 3.3V±0.1V standard); Anomaly handling suggestions: No anomalies.

[0085] 4. System Resource Summary CPU utilization: Maximum 60% (≤90% limit); Memory utilization: Maximum 54% (≤80% limit); Communication upload: 100% success rate for critical data upload.

[0086] After the report is generated, it is stored in the Flash memory of the electronic lock (address 0x08020000-0x0803FFFF, capacity 128KB) and simultaneously uploaded to the cloud platform's operation and maintenance management system via a 4G module, making it easy for managers to trace the execution process. If a command verification fails, the report must list the exception code and troubleshooting steps in detail (e.g., "GPS command verification failed, exception code 0x03, it is recommended to check the antenna connection") to guide on-site operation and maintenance personnel in handling the issue.

[0087] Another embodiment of the present invention provides an artificial intelligence-based logistics electronic lock instruction execution system, see [link to relevant documentation]. Figure 3 The system may include: The receiving module 301 is used to receive various functional control commands from the logistics electronic lock, wherein the functional control commands include at least face recognition control commands, location tracking control commands, and security authentication control commands; The parsing module 302 is used to parse the instruction types and prioritize the multi-type function control instructions to generate an instruction execution sequence with time-sensitive markers. The allocation module 303 is used to dynamically analyze and allocate resources based on the instruction execution sequence through a multimodal fusion decision model, and generate an instruction execution scheme that includes execution timing and resource scheduling. The execution module 304 is used to drive the corresponding lock function module to perform operations according to the instruction execution scheme, and to verify the instruction execution result in real time during the execution process.

[0088] The above description, based on the embodiments shown in the figures, details the structure, features, and effects of the present invention. The above description is only a preferred embodiment of the present invention, but the present invention is not limited to the scope of implementation shown in the figures. Any changes made in accordance with the concept of the present invention, or equivalent embodiments modified to have equivalent changes, that do not exceed the spirit covered by the specification and figures, should be within the protection scope of the present invention.

Claims

1. A logistics electronic lock instruction execution method based on artificial intelligence, characterized in that, The method includes: The system receives various functional control commands from the logistics electronic lock, including at least facial recognition control commands, location tracking control commands, and security authentication control commands. The instruction types of the various function control instructions are parsed and prioritized to generate an instruction execution sequence with time-sensitive markers; Based on the instruction execution sequence, a multimodal fusion decision model is used for dynamic analysis and resource allocation to generate an instruction execution scheme that includes execution timing and resource scheduling. The corresponding lock function module is driven to perform operations according to the instruction execution scheme, and the instruction execution result is verified in real time during the execution process.

2. The method according to claim 1, characterized in that, The receiving logistics electronic lock receives various functional control commands, including at least facial recognition control commands, location tracking control commands, and security authentication control commands, among others: The wireless communication module of the logistics electronic lock receives the original instruction data stream sent from the cloud platform or mobile terminal, ensuring the integrity and real-time performance of the data stream, and thus obtaining the original instruction data stream. The original instruction data stream is parsed and format verified, the instruction header information and payload content are extracted, the instruction type and parameters are identified, and a set of parsed instruction objects is generated. The parsed instruction object set is categorized by instruction type and stored in the instruction cache queue, with a receiving timestamp appended to generate the categorized instruction cache queue.

3. The method according to claim 2, characterized in that, The step of parsing and prioritizing the various types of function control instructions to generate an instruction execution sequence with time-sensitive markers includes: Read the set of instruction objects from the classification instruction cache queue, extract the type identifier and parameter information of each instruction object, and generate an instruction attribute dataset; Based on the instruction attribute dataset, a rule engine is used to analyze the urgency of instructions. Combined with the time constraints defined by the instruction type, the initial priority score of each instruction is calculated to obtain the instruction priority score set. Based on the real-time status data of the electronic lock, including battery level, network bandwidth and the current working mode of the lock, the command priority score is dynamically adjusted to obtain a dynamic priority score set. Based on a dynamic priority score set, and using a time sensitivity assessment algorithm, each instruction is labeled with a time sensitivity level according to its failure time and execution delay risk, generating a time sensitivity label set. By integrating the dynamic priority score set and the time-sensitive tag set, a sorting algorithm is used to generate an instruction execution sequence with time-sensitive tags and priority information.

4. The method according to claim 3, characterized in that, The step of dynamically analyzing and allocating resources based on the instruction execution sequence using a multimodal fusion decision model to generate an instruction execution scheme that includes execution timing and resource scheduling includes: Read the instruction execution sequence, extract the time sensitivity markers and priority information from the instruction sequence, and generate sequence analysis data; Based on sequence analysis data and system resource status, the resource type and quantity required for each instruction are calculated using an AI-based multimodal fusion decision model, generating a resource requirement mapping table. A resource allocation algorithm is adopted, combined with a resource demand mapping table to optimize resource scheduling, avoid resource conflicts, determine the execution time window of instructions, and generate a preliminary resource allocation scheme. By combining instruction dependencies and the system constraints of the electronic lock, the initial resource allocation scheme is optimized in terms of timing, and finally an instruction execution scheme including execution timing and resource scheduling is generated.

5. The method according to claim 4, characterized in that, The step of driving the corresponding lock function module to perform operations according to the instruction execution scheme, and verifying the instruction execution result in real time during the execution process, includes: Analyze the execution timing and resource scheduling information in the instruction execution plan to generate a module-driven instruction set; The corresponding lock function module's driver program is called according to the module driver instruction set, triggering the module to perform the operation; The module execution status data is collected in real time through sensors and data interfaces to generate an execution status data stream. The execution status data stream is compared with the expected results in the instruction execution plan. A verification algorithm is used to determine whether the instruction execution was successful, and an instruction execution verification report is generated.

6. A logistics electronic lock instruction execution system based on artificial intelligence, characterized in that, The system includes: The receiving module is used to receive various functional control commands from the logistics electronic lock, wherein the functional control commands include at least face recognition control commands, location tracking control commands, and security authentication control commands; The parsing module is used to parse the instruction types and prioritize the multi-function control instructions to generate an instruction execution sequence with time-sensitive markers. The allocation module is used to dynamically analyze and allocate resources based on the instruction execution sequence through a multimodal fusion decision model, and generate an instruction execution scheme that includes execution timing and resource scheduling. The execution module is used to drive the corresponding lock function module to perform operations according to the instruction execution scheme, and to verify the instruction execution results in real time during the execution process.

7. The system according to claim 6, characterized in that, The receiving module is specifically used for: The wireless communication module of the logistics electronic lock receives the original instruction data stream sent from the cloud platform or mobile terminal, ensuring the integrity and real-time performance of the data stream, and thus obtaining the original instruction data stream. The original instruction data stream is parsed and format verified, the instruction header information and payload content are extracted, the instruction type and parameters are identified, and a set of parsed instruction objects is generated. The parsed instruction object set is categorized by instruction type and stored in the instruction cache queue, with a receiving timestamp appended to generate the categorized instruction cache queue.

8. The system according to claim 7, characterized in that, The parsing module is specifically used for: Read the set of instruction objects from the classification instruction cache queue, extract the type identifier and parameter information of each instruction object, and generate an instruction attribute dataset; Based on the instruction attribute dataset, a rule engine is used to analyze the urgency of instructions. Combined with the time constraints defined by the instruction type, the initial priority score of each instruction is calculated to obtain the instruction priority score set. Based on the real-time status data of the electronic lock, including battery level, network bandwidth and the current working mode of the lock, the command priority score is dynamically adjusted to obtain a dynamic priority score set. Based on a dynamic priority score set, and using a time sensitivity assessment algorithm, each instruction is labeled with a time sensitivity level according to its failure time and execution delay risk, generating a time sensitivity label set. By integrating the dynamic priority score set and the time-sensitive tag set, a sorting algorithm is used to generate an instruction execution sequence with time-sensitive tags and priority information.

9. A storage medium, characterized in that, The storage medium stores a computer program, wherein the computer program is configured to execute the method of any one of claims 1-5 when it is run.

10. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to run the computer program to perform the method of any one of claims 1-5.

Images