IoT collector adaptive identity management method and system

Abstract

The application discloses an IoT collector adaptive identity management method and system, which is suitable for edge collectors needing to connect multiple master devices in an energy storage Internet of Things. The method comprises: double-mode device identification acquisition, supporting two modes of fixed identification and derived identification from a master device; authentication credential linkage update, automatically recalculating Token and triggering system restart when the master device is replaced; and identification ready gating, allowing MQTT connection only when the identification is valid. Further, the method also supports extended features such as dynamic acquisition of cloud protocol configuration, expired callback identification, task dependency arrangement, etc. The application solves the problems of inflexible collector identity management, asynchronous Token and identification change, and waste of resources caused by invalid connection, realizes zero-configuration automatic cloud uploading of the collector and adaptive identity switching when the master device is replaced, improves connection reliability, and reduces operation and maintenance cost.

Description

Technical Field

[0001] This application relates to the field of Internet of Things (IoT) device access technology, and in particular to a method and system for adaptive management of IoT collector device identifiers and linked updating of authentication credentials. Background Technology

[0002] In energy storage IoT systems, the data collector, as an edge device, needs to complete the device-to-cloud connection process: device startup, obtaining device identification, obtaining cloud configuration, establishing an MQTT connection, and normal communication. However, existing technologies have the following problems:

[0003] Inadequacy of existing technology

[0004] Problem 1: Device identification management is simplistic and inflexible. Current mainstream IoT platforms (such as Alibaba Cloud IoT one-device-one-key solution, Huawei Cloud IoT device access solution, and Azure IoT Hub connection string solution) all adopt a "static single identifier" model, requiring devices to have fixed identity credentials burned in at the factory, and the device identifier remains unchanged throughout its lifecycle. A common problem with these solutions is their inability to adapt to scenarios where "the collector needs to dynamically adjust its identifier based on the connected master device." In multi-device environments, a collector may need to connect to different master devices (such as in industrial park equipment inspection scenarios or equipment replacement and maintenance scenarios). Fixed identifiers result in insufficient flexibility; each device replacement requires manual intervention to update the cloud mapping relationship, leading to high maintenance costs and poor scalability.

[0005] Question 2: Token management and SN changes are out of sync. In existing technologies, tokens typically correspond one-to-one with device SNs and are stored in a cloud database. When a device SN changes, the token is not automatically updated, leading to authentication failures or requiring manual intervention. This design can cause inconsistencies in system states, especially in scenarios where device identities need to be dynamically adjusted.

[0006] Question 3: Invalid connections lead to resource waste. In existing technologies, devices immediately attempt to connect to MQTT after startup, and even if the serial number (SN) is not obtained or is invalid, they continue to reconnect, wasting network resources and cloud connection resources.

[0007] Question 4: Challenges in Protocol Configuration Management. In existing technologies, protocol configurations are either embedded in firmware (requiring OTA upgrades for changes) or stored in local Flash memory (increasing storage space consumption, which is detrimental to resource-constrained devices). Modbus protocol parameters are typically embedded in firmware, requiring a new firmware version to be released for each new device model, resulting in low operational efficiency.

[0008] Question 5: Expiration issue of asynchronous HTTP request callbacks. Embedded devices typically use asynchronous HTTP request mechanisms. When the network times out or retryes, multiple HTTP requests may be generated, and the callbacks that arrive later may overwrite the results of earlier requests, leading to data corruption.

[0009] Issue 6: Unintelligent network anomaly handling. Current technology uses fixed-interval retries, disregarding network connectivity and lacking self-protection mechanisms. It continues to attempt HTTP requests even when the network is disconnected, wasting system resources. After persistent failures, it cannot automatically recover, requiring manual device restart.

[0010] Analysis of existing patented technical solutions

[0011] CN110365758A discloses a protocol-adaptive IoT gateway system that achieves gateway-level protocol conversion and edge computing through a protocol adapter. However, this solution is designed for gateway-level devices and does not address issues such as dynamic management of device identifiers, identity change processing, and connection readiness checks at the collector level. Furthermore, protocol adaptation is completed on the gateway side, making it impossible to achieve dynamic configuration at the collector end during runtime.

[0012] CN114205822B discloses an IoT device and its authorization method, which establishes a physical security area through ultra-short-range wireless communication to achieve device authorization and supports multi-layer key management. However, the device identifier in this scheme remains fixed after authorization and does not support dynamic adjustment of the device identifier. Its authorization process relies on the physical proximity trigger of the external control device and cannot automatically update the authentication credentials when the master device connected to the collector changes.

[0013] The aforementioned existing technologies all share the following common limitations: Limitation 1: The device identifier remains fixed—this limitation ignores the actual need for the collector to function solely as a data channel, and the collector's identity should change with the connected master device; Limitation 2: Token and SN are managed separately—this limitation leads to the token not being able to be updated synchronously when the SN changes, resulting in an inconsistent identity; Limitation 3: Configuration must be persisted locally—this limitation ignores the problem of local storage occupying Flash space, which is detrimental to resource-constrained devices. Summary of the Invention

[0014] Technical problems to be solved

[0015] The technical problem to be solved by this application is to provide an adaptive identity management method and system for IoT collectors, so as to solve the problems of inflexible device identification management, asynchronous changes of token and SN, and waste of resources due to invalid connections in the existing technology.

[0016] Technical solution

[0017] To solve the above-mentioned technical problems, this application adopts the following technical solution:

[0018] The following steps S1 to S3 are numbered according to functional modules to define the three core functions of identity management. The step numbers do not represent the actual execution order. When extended features are included, the actual execution order is uniformly scheduled by the task dependency orchestration mechanism of step S6.

[0019] like Figure 2 As shown, an adaptive identity management method for IoT data collectors includes the following steps:

[0020] Step S1: Obtain the dual-mode device identifier. For example... Figure 3 As shown, according to the preset SN acquisition mode, one of the following operations is performed: (a) Fixed SN mode: read the fixed identifier in the non-volatile storage of the collector as the device identifier; (b) Adaptive SN mode: obtain the master device identifier from the connected master device and generate the collector identifier through a derivation algorithm. The master device identifier is obtained through methods including: reading the device serial number register through communication with the master device via UART serial port, reading device information through communication with the master device via CAN bus, and reading device feature values ​​through communication with the master device via Bluetooth BLE. The derivation algorithm includes: first, detecting the legality of the master device identifier, including length check, character set check, and format check; then, extracting a specific number of characters from the master device identifier as a feature part; concatenating the collector-specific prefix with the feature part; embedding the master device type code and manufacturer identification code in the derived collector identifier; calculating the checksum using CRC16, CRC32, or XOR algorithms; and concatenating the prefix, feature part, and checksum to form the collector identifier. The acquired device identifier is marked as ready.

[0021] Step S2: Authentication credentials are updated in conjunction with the authentication process. For example... Figure 4 As shown, based on the acquired device identifier, the device identifier is concatenated with a preset salt value, and a hash value is calculated using MD5, SHA-1, or SHA-256 algorithms. The first N bits of the hash value are extracted as the authentication token, where N is an integer between 16 and 64. Device identifier change events are monitored. When an identifier change is detected: (a) an identifier change log is recorded, including the original identifier, the new identifier, and the change timestamp; (b) the token is automatically recalculated; (c) the existing MQTT connection is disconnected; (d) TCP and DNS caches are cleared; (e) system resources such as FreeRTOS tasks, timers, and message queues are cleared; (f) the restart reason is recorded as "identifier change" in non-volatile storage; (g) a system restart is triggered after a delay of T seconds, where T is an integer between 3 and 10, allowing time for log recording and state cleanup to ensure global state consistency.

[0022] Step S3: Identify the ready gate. For example... Figure 5As shown, before attempting to establish an MQTT connection, a three-state model is used to perform a ready flag gating: In the not-ready state, the flag has not yet been acquired or the master device is not connected, and the MQTT connection is prohibited; in the ready state, the flag has been acquired and is a valid non-empty string, and the MQTT connection is allowed; in the changed state, the flag has changed, and the system needs to be reinitialized. If the gating check is in the not-ready or changed state, the MQTT connection attempt is blocked and a retry is delayed.

[0023] Through the above steps S1 to S3, the collector obtains a valid device identifier and calculates an authentication token. After passing the identifier-ready gate check, it uses the identifier and token to establish an MQTT connection to realize the device's cloud access.

[0024] Periodic identifier change proactive detection: During normal operation of the equipment, the system proactively queries whether the main device identifier has changed at a preset period T, where T is an integer between 10 and 60 seconds; if an identifier change is detected, steps S1 to S3 are re-executed to achieve adaptive identity update after the main device is replaced.

[0025] In some embodiments, the method further includes:

[0026] Step S4: Dynamically obtain cloud protocol configuration. For example... Figure 6 As shown, device protocol configuration data is retrieved from the cloud via an HTTP request. The HTTP request method is GET or POST. The request header carries the device MAC address, firmware version, and request timestamp. The request body carries parameters such as the collector identifier, device model, and protocol type. The timeout is T seconds, where T is an integer between 10 and 30. Each request is assigned a monotonically increasing request ID. The protocol configuration data includes: communication protocol parameters, namely baud rate, data bits, stop bits, parity bits, and slave address; a register mapping table, namely register address, data type, scaling factor, and unit; configuration version number; and retrieval timestamp. Configuration data parsing supports JSON or Protobuf format parsing. After parsing, configuration validity checks are performed, including parameter range checks and required field checks, and the configuration version number is compared. The configuration is only updated if the version number is higher than the current version. The protocol configuration data is stored only in the device's memory and is not persistently stored locally.

[0027] Step S5: Asynchronous callback expiration identification and discarding. For example... Figure 7 As shown, in the HTTP asynchronous callback function: (a) compare the request ID carried in the callback with the latest request ID; (b) if the request ID of the callback is less than the latest request ID, it is determined to be an expired callback and automatically discarded; (c) if the callback is valid, parse and store the configuration data into memory.

[0028] In some embodiments, the method further includes:

[0029] Step S6: Task dependency orchestration and execution. For example... Figure 8 As shown, a state machine model is used to execute the device cloud process in a strict sequence. Each stage maintains four states: pending execution, in-process execution, success, and failure. The state transition rules are as follows: the pending execution state transitions to the in-process execution state when execution is triggered; the in-process execution state transitions to the success or failure state based on the execution result; the failure state transitions back to the in-process execution state after retrying; subsequent stages are only allowed to transition from the pending execution state to the in-process execution state if the preceding stage is in the success state. The specific process is as follows: In the first stage, step S4 is executed to obtain the cloud configuration. If successful, it proceeds to the next stage; if it fails, it retryes. In the second stage, step S1 is executed to obtain the device identifier. If the identifier is successfully obtained, step S2 is immediately executed to calculate the authentication token. If successful, it proceeds to the next stage; if it fails, it waits for the master device to connect. In the third stage, step S3 is executed to establish an MQTT connection after the identifier-ready gating check is passed. The execution of subsequent stages is blocked if the preceding stage fails.

[0030] Step S7: Network state-aware intelligent retry. For example... Figure 9 As shown, when configuration acquisition or identification acquisition fails: (a) check the network connection status. If the network is not connected, skip the retry request; (b) if the network is connected, use an exponential backoff strategy to retry. The retry interval is doubled from the initial value T0 until it reaches the maximum value Tmax, where T0 is 1 to 5 seconds and Tmax is 60 to 120 seconds; (c) record the number of consecutive failures.

[0031] Step S8: Automatic restart protection for consecutive failures. When the number of consecutive failures in configuration acquisition or identification acquisition reaches a preset threshold N, where N is an integer between 5 and 20: (a) record the reason for system restart to non-volatile storage; (b) trigger automatic system restart.

[0032] Step S9: Configure Update Subscription. After the MQTT connection is established, subscribe to the RPC command topic and the configuration update topic. When the cloud pushes a configuration update notification, repeat steps S4 and S5 to achieve dynamic updates of the runtime configuration.

[0033] This application also provides an adaptive identity management system for IoT data collectors, such as... Figure 1 As shown, the system includes a cloud platform 101, a network communication layer 105, an IoT collector 106, and a main device layer 110; the IoT collector 106 includes:

[0034] The identity adaptive management module 107 includes a dual-mode identifier acquisition unit, a token linkage update unit, and an identifier ready gating unit.

[0035] The cloud-based configuration dynamic acquisition module 108 includes a configuration acquisition unit, an expired callback identification unit, a network-aware retry unit, and an automatic restart protection unit.

[0036] Task dependency orchestration module 109 is used to execute the device cloud process in a strict order, and to block subsequent tasks when the preceding task fails.

[0037] The cloud platform 101 includes a configuration management service 102, a device authentication service 103, and a data receiving service 104; the main device layer 110 includes an inverter 111, a battery system 112, and other energy storage devices 113. The IoT collector 106 communicates with the cloud platform 101 through the network communication layer 105 and with the main device layer 110 through a serial port protocol.

[0038] Beneficial effects

[0039] This application creatively combines three core technical features—"SN derived from the main device," "Token linked updates," and "SN ready gating"—to produce unexpected synergistic technical effects.

[0040] Synergy Effect 1: Unification of Variable Identity and Self-Recovery of Connections

[0041] In traditional solutions, device identity is fixed, and connection status depends on device identity, with the two tightly coupled. Once a device identity needs to be changed, manual intervention is required to reconfigure the cloud mapping relationship. This application achieves a balance between variable identity and stable connection through SN derivation, Token linkage, and a gating mechanism: when the SN changes, a Token update and system restart are automatically triggered. After restarting, the gating mechanism ensures the new identity is valid before establishing a connection, all without manual intervention. This combined capability of "variable identity + automatic credential synchronization + connection self-recovery" is impossible to achieve with a single technical feature. Without an SN derivation mechanism, it cannot adapt to changes in the master device; without Token linkage updates, authentication will fail; without a gating mechanism, attempts to connect using an invalid identity will occur.

[0042] Synergistic Effect 2: Balancing the flexibility of dual-mode identification with the security of gating.

[0043] The dual-mode SN acquisition mechanism of this application supports flexible switching between fixed and adaptive modes. However, this flexibility introduces the risk of identity uncertainty: in adaptive mode, the SN may be empty or invalid when the master device is not connected. The gating mechanism effectively addresses this risk by using a three-state model to ensure that MQTT connections are only allowed when the identifier is valid. This combination of "flexible acquisition + strict gating" maintains flexibility while ensuring connection security.

[0044] Synergistic Effect 3: Bootstrap Loop of Self-Recovery Capability

[0045] SN change triggers Token update → Token update triggers system restart → After system restart, the identifier is reacquired → After the identifier is acquired, the Token is recalculated → After the gating check passes, the connection is re-established, forming a complete self-recovery closed loop without manual intervention. Furthermore, combined with extended features such as cloud configuration acquisition (steps S4-S5) and task dependency orchestration (step S6), this self-recovery capability can be extended to the reconstruction of the entire cloud migration process, including configuration updates. This "trigger-update-restart-recovery" cyclical mechanism is the result of the synergistic effect of three core features, rather than a simple superposition of single technical features.

[0046] Compared with the prior art, this application has the following beneficial effects:

[0047] Benefit 1: Significantly improved flexibility in device identity management

[0048] This application utilizes a dual-mode SN acquisition mechanism, supporting flexible switching between fixed SN mode and adaptive SN mode. In adaptive mode, the collector can derive its own SN from the master device's SN, adapting to multi-device environments. Compared to Alibaba Cloud IoT's fixed identifier scheme of one device, one password, this application's adaptive derivation mechanism can dynamically adjust the collector's identifier based on the connected master device, eliminating the need for pre-programming fixed credentials and reconfiguration when replacing devices, significantly improving operational efficiency.

[0049] Benefit 2: Automation of authentication credential management

[0050] This application implements an SN-Token linkage update mechanism to automatically update the authentication token when the device identifier changes. When a SN change is detected, the system automatically recalculates the token, disconnects the existing connection, clears the network state, and triggers a system restart to ensure global state consistency. This linkage mechanism avoids the authentication failure problem caused by the Token and SN being out of sync in existing technologies, and can complete the identity switch without manual intervention.

[0051] Benefit 3: Effective prevention of invalid connections and significant saving of network resources.

[0052] This application employs a SN-ready gating mechanism to force a check of SN readiness before connecting to MQTT. In scenarios where the master device is not connected during a cold start of the data collector, the ungated solution continuously attempts invalid connections at fixed retry intervals, while the gating solution only retryes when SN acquisition fails, significantly reducing the number of invalid connections. This significantly improves the MQTT connection success rate and noticeably shortens the average connection establishment time.

[0053] Benefit 4: Significantly reduced storage space usage

[0054] This application utilizes pure cloud-based configuration management, storing configuration data solely in device memory without local Flash persistence. Technical analysis indicates that existing technologies typically require approximately 4KB of Flash memory to store protocol configuration data, while this application achieves zero Flash usage, requiring only approximately 3KB of RAM for runtime configuration storage. For resource-constrained embedded devices, saving Flash space is of significant value, reducing device BOM costs.

[0055] Technical Analysis and Storage Space Comparison: Based on the LF686 data acquisition platform, the comparison scheme uses a traditional scheme that stores protocol configuration locally in Flash memory. Flash Usage Analysis: The comparison scheme requires storing Modbus protocol parameters (baud rate, data bits, stop bits, parity bits, slave address, etc., approximately 1KB) and a register mapping table (supporting 9 device models, each approximately 300 bytes, totaling approximately 3KB, including register address, data type, scaling factor, unit, etc.), totaling approximately 4KB. Our solution: Configuration data is stored only in RAM (in the form of global variables), occupying approximately 3KB of RAM (including Modbus protocol parameter structure, register mapping table array, configuration version number, etc.), with 0KB of Flash memory occupied, saving 4KB of Flash space. For resource-constrained embedded devices, the saved 4KB of Flash space can be used for firmware expansion functions (such as OTA buffer, log storage, device model expansion, etc.), improving the device's functional expansion capabilities and reducing reliance on larger capacity Flash chips.

[0056] Benefit 5: Ensures data consistency and avoids pollution from expired callbacks.

[0057] This application effectively solves the expiration problem of asynchronous HTTP callbacks by using a monotonically increasing request ID and an expired callback identification mechanism. In scenarios with unstable network signals, comparative solutions without expired callback identification may result in expired callback pollution events and system deadlock events, leading to a low configuration retrieval success rate. This application's solution automatically discards expired callbacks through request ID verification, effectively avoiding expired data pollution and system deadlock, and significantly improving the configuration retrieval success rate.

[0058] Benefit 6: Intelligent handling of network anomalies and strong automatic recovery capabilities.

[0059] This application implements intelligent handling and automatic recovery in the event of network anomalies through a network-aware intelligent retry and automatic restart protection mechanism. When the network is disconnected, HTTP requests are skipped to avoid resource waste; an exponential backoff strategy is adopted (retry intervals gradually double from 1 second to a maximum of 60 seconds) to avoid frequent retries consuming resources; and the system is automatically restarted when consecutive failures reach a threshold. In scenarios with intermittent network disconnections, comparative solutions still attempt to make requests during the network outage, generating a large number of invalid requests. The network-aware mechanism of this application does not initiate invalid requests during the network outage and retry promptly after the network is restored, significantly improving the configuration acquisition success rate.

[0060] Benefit 7: Improved ease of operation and maintenance management

[0061] This application's pure cloud-based configuration solution supports unified cloud management of protocol configurations for all devices, and supports batch updates, version management, and rollback operations. Devices automatically acquire the latest configuration after restarting, eliminating the need for OTA firmware upgrades. This design significantly simplifies the operation and maintenance process and reduces maintenance costs. The same data collector firmware can be configured via the cloud to adapt to devices using different protocols such as Modbus RTU, Modbus TCP, and CAN bus, allowing one firmware to support multiple device models and improving system scalability. Attached Figure Description

[0062] Figure 1 This is a schematic diagram of the overall system architecture of this application.

[0063] Figure 2 This is a flowchart of the core method for identity management in this application, showing the core functional logic of steps S1 to S3.

[0064] Figure 3 This is a flowchart of the dual-mode SN acquisition process.

[0065] Figure 4 This is a flowchart of the SN-Token linkage update process.

[0066] Figure 5 This is the SN ready gating check flowchart.

[0067] Figure 6 This is a flowchart of the cloud configuration dynamic acquisition process.

[0068] Figure 7 This is a flowchart for identifying and discarding expired callbacks.

[0069] Figure 8 This is a schematic diagram of a task-dependent orchestration state machine.

[0070] Figure 9 This is a flowchart of network-aware intelligent retry.

[0071] Figure 10 This is a complete flowchart of the equipment startup process.

[0072] Explanation of reference numerals in the attached figures

[0073] 101-Cloud Platform; 102-Configuration Management Service; 103-Device Authentication Service; 104-Data Reception Service; 105-Network Communication Layer; 106-IoT Collector; 107-Identity Adaptive Management Module; 108-Cloud Configuration Dynamic Acquisition Module; 109-Task Dependency Orchestration Module; 110-Main Device Layer; 111-Inverter; 112-Battery System; 113-Other Energy Storage Devices. Detailed Implementation

[0074] The present application will now be described in further detail with reference to the accompanying drawings and specific embodiments.

[0075] Example 1: Cloud-based scenario for home energy storage data collectors

[0076] This embodiment demonstrates the complete cloud migration process, including all extended features (steps S4 to S9).

[0077] Application Background

[0078] The user installed a photovoltaic inverter (main device) at home, with serial number "INV-G1470-123456". The user purchased an IoT data collector (the device described in this application) to report inverter data to a cloud monitoring platform.

[0079] Technical implementation process

[0080] (1) As Figure 10 As shown, the data collector enters the complete device-to-cloud process upon startup. (As...) Figure 8 As shown, the collector enters the task dependency orchestration process. The first stage (cloud configuration acquisition) transitions from the pending state to the executing state. For example... Figure 6 As shown, the data collector obtains the protocol configuration from the cloud configuration service interface via an HTTP GET request. The request header carries the collector's MAC address "AA:BB:CC:DD:EE:FF" and firmware version "v2.1.0". The system assigns a request ID of 1. The cloud identifies the device model corresponding to this data collector as "Inverter G1470" and returns the Modbus RTU protocol configuration: baud rate 9600, data bits 8, stop bits 1, parity bits N, slave address 1, and register mapping table. The data collector receives the HTTP response, and the callback function checks that the request ID is 1, which is equal to the latest ID. If it is determined to be a valid callback, the JSON configuration data is parsed and stored in a global variable, occupying only about 2KB of RAM and not written to Flash. If the configuration is successfully obtained, the first stage transitions from the executing state to the successful state, triggering the second stage from the pending state to the executing state.

[0081] (2) Second stage, such as Figure 3 As shown, the data collector begins acquiring the device identifier. Since the data collector is configured in adaptive SN mode during compilation, the system sends a Modbus read command to the inverter via the UART serial port to read the inverter's device serial number register and obtain the master device identifier as "INV-G1470-123456". The data collector executes the identifier derivation algorithm: extracting the last 6 bits of the master device identifier "123456", adding the data collector-specific prefix "COLL-", embedding the device type code "1470" (representing the G1470 model), calculating the XOR checksum to obtain "3A", and generating the data collector identifier as "COLL-1470-123456-3A". The system marks the data collector identifier as ready. The second stage transitions from the executing state to the successful state.

[0082] (3) The collector calculates the authentication token based on the identifier. The MD5 algorithm is used to calculate: Token = MD5(“COLL-1470-123456-3A” + “SALT_STRING_2025”), resulting in a 32-byte MD5 hash value “a1b2c3d4e5f6…”. The token calculation is complete.

[0083] (4) Third stage (MQTT connection establishment): The process transitions from the pending state to the executing state, and the collector attempts to establish an MQTT connection. Before establishing the connection, such as... Figure 5 As shown, the system performs a ready gating check: checking if the identifier has been marked as ready and if the identifier is a valid non-empty string "COLL-1470-123456-3A". The gating check passes. The collector establishes an MQTT connection using the following parameters: cloud MQTT server address, port 1883, ClientID "COLL-1470-123456-3A", Username "COLL-1470-123456-3A", and Password Token "a1b2c3d4e5f6…". The MQTT connection is successfully established, and the third stage transitions from the executing state to the successful state.

[0084] (5) The data collector subscribes to the RPC command topic "v1 / devices / me / rpc / request / +" and the configuration update topic "v1 / devices / me / attributes". It begins periodically reporting inverter telemetry data, including voltage, current, power, and power generation.

[0085] Technical effect

[0086] The entire cloud migration process requires no manual input of device identifiers or protocol parameters from the user. The collector automatically obtains the identifier from the host device and the protocol configuration from the cloud, achieving zero-configuration cloud migration. The collector firmware does not persist any configuration data, saving approximately 4KB of Flash storage space. Under good network signal conditions, the MQTT connection establishment time is approximately 15 to 40 seconds (depending on cloud response latency and network conditions); in this embodiment, the measured time is approximately 25 seconds. One firmware can adapt to multiple device models (supporting different protocols such as Modbus RTU and CAN bus through cloud configuration). After the host device is replaced, the collector automatically adapts to the new device without manual reconfiguration, significantly improving operational efficiency.

[0087] Example 2: Network Anomaly and Automatic Recovery Scenario

[0088] Application Background

[0089] A data collector was deployed in a remote mountainous area, connecting to the cloud via a 4G network. The signal in the mountainous area is unstable; it is normal during the day but frequently disconnects at night.

[0090] Technical implementation process

[0091] (1) The collector works normally during the day and reports data through the 4G network.

[0092] (2) At 23:00, the data collector detected a device restart (due to unstable voltage) and re-entered the task dependency orchestration process. In the first phase, the data collector attempts to obtain cloud configuration. For example... Figure 9 As shown, the network-aware intelligent retry mechanism plays a role in this process. The system assigns request ID 100 and initiates an HTTP GET request. Due to weak 4G signal, the request times out after 30 seconds without a response. Network status detection shows that the network is connected. A retry is triggered, and the system assigns request ID 101, employing an exponential backoff strategy, initiating a second request after an initial retry interval of 2 seconds.

[0093] (3) At 23:01, the second request was sent, and a response was received 20 seconds later, indicating successful configuration parsing. The configuration data was stored in RAM. At this time, the delayed response to the first request arrived, such as... Figure 7 As shown, the callback function detected that the request ID was 100, which is less than the current ID of 101, and determined it to be an expired callback, which was automatically discarded. The log recorded "Discard expired HTTP response, ID=100 (current=101)". Configuration retrieval was successful, and the first phase was completed.

[0094] (4) In the second stage, the collector successfully reads the master device identifier and derives the collector identifier. In the third stage, the collector successfully establishes an MQTT connection.

[0095] (5) At 00:00, the network signal is completely disconnected. The collector periodically checks the network status and finds that the network is not connected. The system skips all HTTP requests and MQTT connection attempts to avoid wasting resources and enters a waiting state.

[0096] (6) At 06:00 AM, network signal was restored. A network status change event was triggered, and the collector immediately attempted to acquire configuration data. The system assigned request ID 102, initiated an HTTP request successfully, and updated the configuration data. The MQTT connection was successfully re-established.

[0097] (7) Suppose a network anomaly causes 10 consecutive configuration acquisition failures. The system records that the number of consecutive failures has reached the threshold of 10, records the reason for restarting as "consecutive failures to acquire configuration", and automatically restarts the system after a 5-second delay. After restarting, the complete cloud migration process is executed again, the configuration is successfully acquired and the connection is established, and the system automatically returns to normal.

[0098] Technical effect

[0099] Requests are intelligently skipped in case of network anomalies to avoid resource waste. Expired callbacks are automatically discarded to prevent data corruption. Automatic recovery is performed in case of continuous failures, requiring no manual intervention. The entire process requires no manual intervention; the system automatically adapts to the network environment, significantly improving the success rate of configuration retrieval and preventing system deadlocks or data corruption events.

[0100] Example 3: Master Device Replacement and Adaptive Identity Update Scenario

[0101] Application Background

[0102] An industrial park deployed a data acquisition unit, initially connected to an inverter G1470 (serial number "INV-G1470-123456"). Due to equipment upgrades, maintenance personnel replaced the main device with a new inverter model G1618X (serial number "INV-G1618X-789012").

[0103] Technical implementation process

[0104] (1) The collector has been working normally through the complete cloud migration process. The current collector is identified as “COLL-1470-123456-3A”, and the token calculated using the MD5 algorithm is “a1b2c3d4e5f6…”. The MQTT connection is normal and it is periodically reporting inverter telemetry data.

[0105] (2) The maintenance personnel disconnect the old inverter G1470 and connect the new inverter G1618X. The periodic identifier change detection mechanism of the data acquisition unit is triggered in the next detection cycle. It sends a Modbus read command to the master device through the UART serial port and reads the new master device identifier "INV-G1618X-789012".

[0106] (3) The system detects a change in the master device identifier and triggers the derivation algorithm in step S1. First, the new identifier is checked for validity, including length (16 characters, valid), character set (alphanumeric and hyphens, valid), and format (conforms to the "model-serial number" format, valid). Then, the feature part "789012" is extracted, the collector-specific prefix "COLL-" is added, the device type code "1618" (representing the G1618X model) is embedded, and the checksum "5B" is calculated using the XOR algorithm to generate the new collector identifier "COLL-1618-789012-5B".

[0107] (4) Figure 4 As shown, the identifier change triggers the linked update process in step S2. The system records the identifier change log: "Original identifier COLL-1470-123456-3A, new identifier COLL-1618-789012-5B, change time 2025-08-15 14:30:00". The token is recalculated using the MD5 algorithm: Token = MD5("COLL-1618-789012-5B" + "SALT_STRING_2025"), resulting in a 32-byte MD5 hash value as the new token "x7y8z9...". Subsequently, the existing MQTT connection is disconnected, TCP and DNS caches are cleared, FreeRTOS tasks, timers, and message queue resources are cleared, and the restart reason is recorded in Flash as "identifier change". After a 5-second delay, the system restarts.

[0108] (5) After the system restarts, it re-enters the task dependency orchestration process. In the first stage, the collector obtains the protocol configuration from the cloud via an HTTP GET request. The request header carries the MAC address and firmware version. The cloud identifies the new device model as "Inverter G1618X" and returns the corresponding Modbus RTU protocol configuration. The system assigns a request ID of 1. After the callback function verifies the validity of the request ID, it parses the configuration data in JSON format, performs parameter range checks and required field checks, and updates the configuration after confirming that the configuration version number is higher than the current version, storing it in memory.

[0109] (6) In the second stage, the data collector reads the master device identifier "INV-G1618X-789012" and the derived data collector identifier "COLL-1618-789012-5B", marking it as ready. In the third stage, the gating check confirms that the identifier is in the ready state, establishes an MQTT connection using the new identifier and the new token, and the connection is successful. The system subscribes to the configuration update topic (step S9) and begins reporting the telemetry data of the new inverter.

[0110] Technical effect

[0111] During the entire main device replacement process, maintenance personnel only need to physically replace the device; there is no need to modify the device mapping relationship in the cloud, nor is it necessary to re-flash firmware or reconfigure the collector. The collector automatically completes identity update, token recalculation, configuration acquisition, and connection reconstruction, all without manual intervention. From the replacement of the main device to the collector returning to normal operation, the entire process takes approximately 40 seconds (including a 5-second delay restart time).

[0112] The above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. An adaptive identity management method for IoT data collectors, characterized in that... This includes the following steps: Step S1: Dual-mode device identifier acquisition. Perform one of the following operations according to the preset SN acquisition mode: (a) Fixed SN mode: Read the fixed identifier in the collector's non-volatile storage as the device identifier; (b) Adaptive SN mode: Read the master device identifier from the connected master device and generate the collector identifier through a derivation algorithm, wherein the derivation algorithm includes extracting the feature part of the master device identifier, adding a collector-specific prefix, and calculating a checksum; mark the generated device identifier as ready. Step S2: Authentication credential linkage update. Based on the collector identifier, the authentication token is calculated using a hash algorithm. The change event of the collector identifier is monitored. When an identifier change is detected, the authentication token is automatically recalculated, the existing MQTT connection is disconnected, the network connection status and system resources are cleared, and the system restart is triggered. Step S3: Identify Ready Gating. Before attempting to establish an MQTT connection, check whether the collector identifier has been marked as ready and is a valid non-empty string. If the check fails, prevent the MQTT connection attempt; if the check passes, allow the MQTT connection to be established.

2. An adaptive identity management system for IoT data collectors, characterized in that... ,include: The identity adaptive management module includes: an identifier acquisition and derivation unit, used to perform one of the following operations according to a preset SN acquisition mode: (a) Fixed SN mode: read a fixed identifier from the collector's non-volatile storage; (b) Adaptive SN mode: read the master device identifier from the master device and generate a collector identifier through a derivation algorithm, wherein the derivation process includes extracting the master device identifier features, adding a collector-specific prefix, and calculating a checksum; a Token linkage update unit, used to calculate an authentication token based on the collector identifier using a hash algorithm, and automatically recalculate the authentication token, disconnect, clean up network connection status and system resources, and trigger a system restart when the identifier changes; and an identifier ready gating unit, used to check whether the collector identifier has been marked as ready and is a valid non-empty string before MQTT connection, preventing MQTT connection attempts if the check fails, and triggering MQTT connection establishment after the check passes.

3. The system according to claim 2, characterized in that... It also includes: a cloud configuration dynamic acquisition module, comprising: a configuration acquisition unit, used to obtain the device's protocol configuration data from the cloud platform via HTTP requests and store it in the device's memory; a request ID management unit, used to assign a monotonically increasing request ID to each HTTP request; and an expired callback identification unit, used to compare the request ID carried in the HTTP asynchronous callback with the latest request ID, and identify and discard expired callbacks.

4. The system according to claim 2, characterized in that... It also includes: a task dependency orchestration module, which uses a state machine model to execute the device cloud process in a preset order. Each stage maintains four states: pending execution, in execution, success, and failure. Subsequent stages are allowed to execute only when the preceding stage is in a success state.

5. The method according to claim 1, characterized in that... In step S2, when an identifier change is detected: (a) record the identifier change log, including the original identifier, the new identifier, and the change timestamp; (b) clear the TCP and DNS caches; (c) clear system resources such as FreeRTOS tasks, timers, and message queues; (d) record the restart reason as "identifier change" in the non-volatile storage for fault diagnosis after system restart; (e) trigger system restart after a delay of T seconds, where T is an integer between 3 and 10.

6. The method according to claim 1, characterized in that... The ready flag gating in step S3 adopts a three-state model: not ready state, the flag has not been acquired or the master device is not connected, and MQTT connection is prohibited; ready state, the flag has been acquired and is valid, and MQTT connection is allowed; changed state, the flag has changed, and the system needs to be reinitialized.

7. The method according to claim 1, characterized in that... The derived algorithm for the adaptive SN mode in step S1 further includes: detecting the legality of the master device identifier, including length check, character set check, and format check; extracting characters of a specific number of digits from the master device identifier as a feature part; calculating the check code using CRC16, CRC32, or XOR algorithms; embedding the master device type code and manufacturer identification code in the derived collector identifier; the master device identifier acquisition method in step S1 includes: communicating with the master device through UART serial port, CAN bus, or Bluetooth BLE to read the device identifier information of the master device.

8. The method according to claim 1, characterized in that... The hash algorithm in step S2 includes: concatenating the collector identifier with a preset salt value, calculating the hash value using MD5, SHA-1 or SHA-256 algorithms, and extracting the first N bits of the hash value as the authentication token, where N is an integer between 16 and 64.

9. The method according to claim 1, characterized in that... It also includes: a periodic identifier change active detection step: during normal operation of the device, actively query whether the main device identifier has changed at a preset period T, where T is an integer between 10 and 60 seconds; if an identifier change is detected, then re-execute steps S1 to S3.

10. The method according to claim 1, characterized in that... It also includes: Step S4: Cloud configuration acquisition, obtaining the device's protocol configuration data from the cloud via an HTTP request, assigning a monotonically increasing request ID to each request, and storing the protocol configuration data only in the device's memory without local persistence.

11. The method according to claim 10, characterized in that... It also includes: Step S5: Expired callback identification. In the HTTP asynchronous callback function, the request ID carried in the callback is compared with the current latest request ID. If the request ID of the callback is less than the current latest request ID, it is determined to be an expired callback and discarded.

12. The method according to claim 10, characterized in that... The protocol configuration data in step S4 includes communication protocol parameters and a register mapping table; the HTTP request carries the device MAC address, firmware version, collector identifier, and device model, with a timeout of T seconds, where T is an integer between 10 and 30; the configuration data parsing includes JSON format parsing or Protobuf format parsing, configuration validity verification includes parameter range checking and required field checking, and configuration version number comparison, updating the configuration only when the version number is higher than the current version.

13. The method according to claim 10, characterized in that... It also includes: Step S6: Task dependency orchestration. In the complete process of cloud computing on the device, it is executed in strict order of "Step S4 to obtain cloud configuration → Step S1 to obtain device identifier and execute Step S2 to calculate authentication token → Step S3 to establish MQTT connection after the identifier is ready and the gate check is passed". It adopts a state machine model, and each stage maintains four states: pending execution, in execution, success and failure. The subsequent stage is allowed to execute only when the preceding stage is in a successful state. If the preceding task fails, the execution of the subsequent task is blocked.

14. The method according to claim 10, characterized in that... It also includes: Step S7: Network status-aware retry mechanism, which checks the network connection status when configuration acquisition or identification acquisition fails. If the network is not connected, the retry request is skipped. If the network is connected, an exponential backoff strategy is adopted for retry. The retry interval is doubled from the initial value T0 until it reaches the maximum value Tmax, where T0 is 1 to 5 seconds and Tmax is 60 to 120 seconds.

15. The method according to claim 10, characterized in that... It also includes: Step S8: Automatic restart after consecutive failures. When the number of consecutive failures in configuration acquisition or identification acquisition reaches a preset threshold N, the reason for system restart is recorded and the system is automatically restarted, where N is an integer between 5 and 20.

16. The method according to claim 11, characterized in that... It also includes: Step S9: After the MQTT connection is established, subscribe to the RPC command topic and the configuration update topic. When the cloud pushes the configuration update notification, re-execute steps S4 and S5.

Images