A dtu logic control system and method supporting one-key cloud configuration

Abstract

The present application belongs to the technical field of industrial internet of things communication and terminal access configuration, and discloses a DTU logic control system and method supporting one-key cloud configuration. The DTU establishes a local maintenance channel through an embedded Web configuration service, issues a visual page to obtain cloud access parameters, writes the parameters into a non-volatile storage area after verification to form a persistent configuration, reads the configuration after restart or exit from the configuration mode, parses the communication protocol type, instantiates the corresponding network protocol stack, and completes the connection and authentication with the cloud platform. The present application introduces a hardware fingerprint dynamic binding process, uses a unique device identifier to replace a wildcard in a configuration template to generate a dedicated communication identifier, and uses a dual-partition storage of a running partition and a candidate partition and an automatic rollback strategy for trial operation. When the connection fails for more than a threshold value, the system is restored to a historical effective configuration, realizes parameter and firmware decoupling, visual configuration, and automatic recovery in an unattended scenario, and improves the deployment efficiency and operation reliability of the DTU.

Description

Technical Field

[0001] This invention belongs to the field of industrial Internet of Things (IoT) communication and terminal access configuration technology, specifically relating to a DTU logic control system and method that supports one-click cloud configuration, and in particular, an IoT terminal access control technology based on cloud access parameter decoupled storage, hardware fingerprint dynamic binding, and configuration trial and error and self-healing rollback mechanism. Background Technology

[0002] With the continuous advancement of the Industrial Internet and smart city construction, Data Transmission Units (DTUs) have gradually become key communication hubs connecting field devices such as street light controllers and photovoltaic inverters with cloud platforms. However, in the entire lifecycle of current IoT project deployment and operation, cloud access and configuration management of DTU devices still face numerous technical challenges.

[0003] In large-scale deployment scenarios, the coupling issue between identity management and firmware for cloud access is particularly prominent. In traditional DTU architectures, parameters such as cloud platform access addresses, ports, and authentication keys are typically fixed in the device firmware, resulting in strong coupling between parameters and firmware. When the cloud operating environment changes, or when migration or private deployment is required between different cloud platforms, it is often necessary to recompile the firmware and re-flash it, leading to high maintenance costs. Furthermore, in application scenarios with hundreds or thousands of devices deployed in batches, operations personnel need to configure a unique ClientID for each device. Manual configuration is prone to input errors, and simply copying uniform parameters can easily cause identity conflicts and connection preemption when devices go online. There is a lack of a mechanism that supports both general configuration templates and automatically generates unique communication identities.

[0004] Existing DTU devices generally lack robust configuration fault tolerance and self-recovery capabilities. This problem is particularly pronounced in unattended or remote maintenance scenarios. Current configuration methods often employ a direct overwrite strategy; if incorrect protocol types, network addresses, or authentication information are mistakenly written, the device may remain in a persistent connection failure state during subsequent operation, repeatedly restarting or retrying without self-recovery. In such cases, maintenance personnel typically need to travel to the site to perform hardware resets or re-flash firmware, resulting in high maintenance costs and risks.

[0005] On-site configuration methods also present a trade-off between convenience and security. While some products offer PC-based configuration tools, these often rely on dedicated host computer software or specific USB drivers, making deployment and use more difficult. Furthermore, the lack of effective management and security control over the activation process of configuration parameters hinders quick on-site configuration by non-professionals. Current technology lacks a DTU logic control solution that can decouple cloud access parameters from firmware logic, support batch automated identity binding based on hardware fingerprints, and possess end-to-end configuration trial-and-error and automatic rollback capabilities. Summary of the Invention

[0006] This invention aims to address the challenges of existing IoT DTU devices. During the entire lifecycle of cloud access configuration, cloud access parameters are highly coupled with device firmware logic, lacking an efficient batch deployment mechanism for large-scale scenarios. Device access parameters are primarily configured manually for each device, which is inefficient and prone to input errors. Simply copying the same configuration can easily lead to device communication identity conflicts. Furthermore, there is a lack of robust configuration fault tolerance and self-healing capabilities. If incorrect access parameters or protocol configurations are written, the device is prone to repeated reconnections or prolonged offline states, requiring manual on-site reset. This fails to meet the system availability and maintenance cost requirements of unattended and remote operation and maintenance scenarios.

[0007] To address the above problems, this invention proposes a DTU logic control method that supports one-click cloud configuration, comprising:

[0008] S1. When the DTU module is in the configuration state, start the embedded local web configuration service and perform a local maintenance channel establishment operation. The local maintenance channel establishment operation establishes a local maintenance channel with the external configuration terminal by activating the local network interface.

[0009] S2. Send a visual configuration page to the external configuration terminal through the local maintenance channel, and receive the cloud access parameter set submitted by the external configuration terminal. The cloud access parameter set includes at least a communication protocol type identifier and a protocol stack configuration item that is mapped to the communication protocol type identifier.

[0010] S3. Perform the verification and writing operation of the cloud access parameter set, and write the verified cloud access parameter set into the non-volatile configuration storage area of ​​the DTU module to generate persistent configuration data independent of the device firmware logic.

[0011] S4. After exiting the configuration mode or restarting the device, perform a dynamic selection and instantiation operation of the network protocol stack. The dynamic selection and instantiation operation of the network protocol stack is used to read the persistent configuration data, select, enable or instantiate the corresponding network protocol stack based on the communication protocol type identifier and protocol stack configuration items, and initiate a connection establishment and identity authentication process for the target cloud platform.

[0012] S5. After successful identity authentication, establish a two-way data pass-through session between the DTU module and the target cloud platform, and perform connection keep-alive control operations to maintain the availability of network connectivity.

[0013] The specific methods for establishing the local maintenance channel include:

[0014] When the local network interface is configured in wireless mode, the Wi-Fi module of the DTU module is switched to access point mode and a preset service set identifier is broadcast for the external configuration terminal to access.

[0015] When the local network interface is configured in wired mode, the Dynamic Host Configuration Protocol (DHCP) service of the DTU module Ethernet interface is enabled to dynamically assign a local IP address to the external configuration terminal connected via a network cable.

[0016] The aforementioned visual configuration page includes:

[0017] S21. Detect the user's selection event for the communication protocol type identifier on the front-end page;

[0018] S22. When the user selects the MQTT protocol, dynamically load and display the MQTT-specific configuration form;

[0019] S23. When the user selects TCP or UDP protocol, dynamically load and display the Socket-specific configuration form.

[0020] The verification and writing operations of the cloud access parameter set specifically include:

[0021] S31. Call the preset verification rules to perform legality verification on the length and value range of the server address field, port number field and string configuration field in the cloud access parameter set, wherein the format of the server address field includes at least the IP address format;

[0022] S32. If the legality verification passes, the cloud access parameter set is converted into a structured data format to generate a serialized data object.

[0023] S33. Write the serialized data object into the storage area of ​​the non-volatile configuration storage area to complete the generation of the persistent configuration data.

[0024] The dynamic selection and instantiation operation of the network protocol stack specifically includes:

[0025] S41. Read the communication protocol type identifier from the persistent configuration data;

[0026] S42. Based on the communication protocol type identifier, call the corresponding protocol processing component from the preset protocol library;

[0027] S43. Load the server address, port and authentication credentials in the protocol stack configuration items into the configuration interface of the protocol processing component, and trigger the connection handshake logic.

[0028] The connection keep-alive control operation specifically includes:

[0029] S51. Set the keep-alive period parameters used to maintain network connectivity;

[0030] S52. Configure a timing mechanism according to the keep-alive cycle parameters, and send a heartbeat message or keep-alive message to the target cloud platform through the network protocol stack when each keep-alive cycle arrives.

[0031] S53. After sending the heartbeat message or keep-alive message, start the timeout detection mechanism. If no confirmation response or downlink valid service data is detected from the target cloud platform within the preset time window, determine that the current network connection is abnormal and trigger the reconnection mechanism.

[0032] S54. During the reconnection process, maintain the number of reconnection failures. When the number of reconnection failures exceeds the preset threshold, stop further reconnection and enter the fault protection state.

[0033] The bidirectional data pass-through session further includes a field device data forwarding process, specifically including:

[0034] S61. Initialize the local peripheral interface of the DTU module;

[0035] S62. Receive uplink data frames from the field controlled devices through the local peripheral interface, encapsulate them into data packets that match the target cloud platform, and send them to the target cloud platform through the bidirectional data pass-through session.

[0036] S63. Receive the service control command issued by the target cloud platform, parse the service control command and remove the network protocol header information, and transmit the obtained valid command payload to the field controlled device through the local peripheral interface.

[0037] The method further includes a hardware fingerprint dynamic binding process, specifically including:

[0038] S71. Allow the client identifier field and message topic field in the cloud access parameter set to be configured using preset wildcard placeholders;

[0039] S72. Before initiating the connection establishment and identity authentication process for the target cloud platform, read the hardware unique identifier set at the bottom layer of the DTU module.

[0040] S73. Dynamically replace the wildcard placeholder with the hardware unique identifier read from the hardware unique identifier set to generate a device-specific protocol stack configuration item.

[0041] The method further includes configuring a trial-and-error and automatic rollback process, specifically including:

[0042] S81. Logically divide the non-volatile configuration storage area into a running configuration partition and a candidate configuration partition, write the newly received cloud access parameter set into the candidate configuration partition, and mark the configuration status as pending verification.

[0043] S82. When initializing the network protocol stack and initiating a connection establishment attempt to the target cloud platform, read the parameters in the candidate configuration partition as the current connection parameters.

[0044] S83. If the connection established based on the candidate configuration partition parameters is successful and the identity authentication is passed, the data of the candidate configuration partition is synchronously overwritten to the running configuration partition, and the configuration state is updated to a stable state.

[0045] S84. If the number of connection attempts based on the candidate configuration partition parameters fails exceeds a preset threshold, an automatic rollback strategy is triggered to mark the candidate configuration partition as invalid and reload the historical valid parameter set in the running configuration partition to restore network connectivity.

[0046] A DTU logic control system that supports one-click cloud configuration includes:

[0047] The local maintenance channel establishment module is used to start the embedded local web configuration service and perform a local maintenance channel establishment operation when the DTU module is in the configuration state. The local maintenance channel establishment operation establishes a local maintenance channel with the external configuration terminal by activating the local network interface.

[0048] The visual configuration interaction module is used to send a visual configuration page to the external configuration terminal through the local maintenance channel and receive the cloud access parameter set submitted by the external configuration terminal. The cloud access parameter set includes at least a communication protocol type identifier and a protocol stack configuration item that is mapped to the communication protocol type identifier.

[0049] The parameter verification and storage module is used to perform verification and writing operations on the cloud access parameter set, and write the verified cloud access parameter set into the non-volatile configuration storage area of ​​the DTU module to generate persistent configuration data independent of the device firmware logic.

[0050] The network protocol stack dynamic selection and instantiation module is used to perform network protocol stack dynamic selection and instantiation operations after exiting the configuration mode or restarting the device. The network protocol stack dynamic selection and instantiation operations are used to read the persistent configuration data, select, enable or instantiate the corresponding network protocol stack based on the communication protocol type identifier and protocol stack configuration items therein, and initiate a connection establishment and identity authentication process for the target cloud platform.

[0051] The session establishment and keep-alive module is used to establish a bidirectional data pass-through session between the DTU module and the target cloud platform after successful identity authentication, and to perform connection keep-alive control operations to maintain the availability of network connectivity.

[0052] Compared with the prior art, the present invention has the following significant advantages and beneficial effects:

[0053] This invention provides a DTU logic control system and method supporting one-click cloud configuration. Through the collaboration of a local visual interactive interface and an underlying logic control mechanism, it offers comprehensive technical advantages in system architecture flexibility, unattended operation reliability, and batch deployment efficiency. Architecturally, this invention sets up a non-volatile configuration storage area in the DTU and, combined with a dynamic selection and instantiation mechanism for network protocol stacks, persistently stores and manages cloud access parameters as configuration data independent of the firmware. During operation, the DTU dynamically selects and loads different protocol stacks such as MQTT, TCP, and UDP based on the configuration data, rather than fixing them during the firmware compilation stage. Cloud platform switching and business migration can be achieved simply by updating configuration parameters, improving system maintainability and adaptability.

[0054] Regarding operational reliability, this invention employs a dual-partition storage strategy, consisting of a configuration partition and a candidate configuration partition, to introduce a configuration trial-and-error mechanism and automatic rollback mechanism for parameter temporary storage, trial operation, verification and solidification, and failure rollback. When a newly issued configuration causes consecutive device connection failures exceeding a preset threshold, the system automatically abandons the current candidate configuration and rolls back to the previously verified valid configuration, preventing prolonged device disconnection or repeated restarts due to remote misconfiguration. Through this mechanism, devices can automatically recover to a usable configuration state in unattended and unstable network environments, reducing the need for on-site manual intervention and improving the overall system robustness and availability.

[0055] In terms of batch deployment and on-site operation and maintenance, this invention achieves a balance between efficient configuration and ease of use by combining hardware fingerprinting technology based on dynamic placeholders with a local visual interactive interface embedded in the web. By pre-setting wildcards in a general configuration template and dynamically reading the device's unique hardware identifier during the protocol stack initialization phase, this unique hardware identifier is used to replace the wildcards in the configuration template. The unique hardware identifier includes one or more of the following: International Mobile Equipment Identity (IMEI), Media Access Control (MAC) address, or chip serial number. This allows for the automatic generation of non-conflicting communication identities for multiple devices under the same template, reducing manual configuration for each device and mitigating the risk of identity conflicts. Simultaneously, the DTU embeds a lightweight web server and establishes a local maintenance channel, enabling construction and maintenance personnel to complete the structured configuration of cloud access parameters and on-site communication parameters simply by accessing the local configuration page through a browser, without needing to install dedicated software. This lowers the barrier to entry and facilitates widespread application in engineering projects. Attached Figure Description

[0056] Figure 1 A schematic diagram of the hardware architecture and logical partitioning structure of the DTU logic control system;

[0057] Figure 2 The main flowchart of a DTU logic control method that supports one-click cloud configuration;

[0058] Figure 3 A flowchart for local web visualization configuration and parameter structure processing;

[0059] Figure 4 This is a schematic diagram illustrating the hardware fingerprint binding principle based on dynamic placeholders.

[0060] Figure 5 A schematic diagram illustrating the state flow of configuring trial and error and automatic rollback mechanisms across the entire link.

[0061] Implementation Method 1

[0062] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below in conjunction with the claims and embodiments. Obviously, the described embodiments are merely some embodiments of this invention, and not all embodiments. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0063] like Figure 2 As shown, a DTU logic control method supporting one-click cloud configuration includes:

[0064] S1. When the DTU module is in the configuration state, start the embedded local web configuration service and perform a local maintenance channel establishment operation. The local maintenance channel establishment operation establishes a local maintenance channel with the external configuration terminal by activating the local network interface.

[0065] S2. Send a visual configuration page to the external configuration terminal through the local maintenance channel, and receive the cloud access parameter set submitted by the external configuration terminal. The cloud access parameter set includes at least a communication protocol type identifier and a protocol stack configuration item that is mapped to the communication protocol type identifier.

[0066] S3. Perform the verification and writing operation of the cloud access parameter set, and write the verified cloud access parameter set into the non-volatile configuration storage area of ​​the DTU module to generate persistent configuration data independent of the device firmware logic.

[0067] S4. After exiting the configuration mode or restarting the device, perform a dynamic selection and instantiation operation of the network protocol stack. The dynamic selection and instantiation operation of the network protocol stack is used to read the persistent configuration data, select, enable or instantiate the corresponding network protocol stack based on the communication protocol type identifier and protocol stack configuration items, and initiate a connection establishment and identity authentication process for the target cloud platform.

[0068] S5. After successful identity authentication, establish a two-way data pass-through session between the DTU module and the target cloud platform, and perform connection keep-alive control operations to maintain the availability of network connectivity.

[0069] The specific methods for establishing the local maintenance channel include:

[0070] When the local network interface is configured in wireless mode, the Wi-Fi module of the DTU module is switched to access point mode and a preset service set identifier is broadcast for the external configuration terminal to access.

[0071] When the local network interface is configured in wired mode, the Dynamic Host Configuration Protocol (DHCP) service of the DTU module Ethernet interface is enabled to dynamically assign a local IP address to the external configuration terminal connected via a network cable.

[0072] Specifically, a DTU logic control method supporting one-click cloud configuration runs on the DTU module side. The DTU module can be deployed as a standalone device or integrated into a smart terminal controller. For example... Figure 1 As shown, the hardware architecture of the DTU module includes at least a microprocessor, a cellular communication unit, a Wi-Fi communication unit, and an Ethernet physical interface. The main flow of the logic control method is as follows: Figure 2As shown, the specific implementation process for activating the local network interface to establish a local maintenance channel is as follows.

[0073] When the DTU module detects a trigger condition for entering the configuration state, the system reads maintenance channel policy parameters from the non-volatile configuration storage area. The trigger condition can be a debouncing long-press signal or a system initial startup status flag. The maintenance channel policy parameters can be configured as adaptive mode, wireless priority mode, or wired priority mode. Based on the maintenance channel policy and the current physical interface connection status, the system determines whether to establish a local maintenance channel wirelessly or via a wired connection.

[0074] When the system determines that a wireless mode is to be used, the microprocessor controls the Wi-Fi communication unit to switch its operating mode from terminal mode to access point mode. The Wi-Fi communication unit activates the radio frequency circuit and broadcasts a preset Service Set Identifier (SSID). The SSID can be generated according to a naming rule of a fixed prefix plus a hardware identifier field, which is used to facilitate on-site construction personnel to identify the access point. Regarding access security, the access point encryption method can be configured to secure mode, and the encryption algorithm can be WPA2-PSK. In specific debugging scenarios, it can also be configured to open access mode. After the access point mode is ready, the DTU module activates the local DHCP service module, sets a preset private IP address pool to allocate LAN IP addresses to access terminals, and configures the DTU module's own IP address as the local gateway address. The address pool and gateway address can be selected from a segment of the private network, where the address pool can be set to 192.168.10.100 to 192.168.10.200, and the gateway address can be set to 192.168.10.1. In this state, on-site construction personnel use external configuration terminals such as mobile phones and tablets to connect to the aforementioned SSID via Wi-Fi and obtain an IP address from the DHCP service, thereby establishing a local wireless maintenance channel based on the Wi-Fi link.

[0075] When the system determines to use a wired connection, the criteria may include detecting a valid physical connection on the Ethernet interface or configuring the maintenance channel policy to prioritize wired connections. The system activates the Ethernet interface in the network protocol stack and starts the DHCP server function to assign addresses to external configuration terminals. The system receives DHCP request messages on the preset service port of the UDP protocol to handle the address allocation process. To avoid conflicts with the network segment of the upstream routing equipment, the DHCP address pool is configured to an infrequently used private network segment, such as the 192.168.100.x network segment, and the DTU module's local IP address can be configured as the gateway address of this network segment, 192.168.100.1. When an external configuration terminal, such as a laptop, is directly connected to the DTU module via a network cable, the DTU module sends offer and acknowledgment messages to the external configuration terminal according to the Dynamic Host Configuration Protocol (DHCP) interaction process, dynamically assigning a LAN IP address to the external configuration terminal, thereby establishing a local wired maintenance channel based on the Ethernet link.

[0076] After establishing a local maintenance channel using any of the above methods, the lightweight web server embedded in the DTU module binds to a preset service port of the local gateway IP address and begins receiving HTTP or HTTPS access requests from external configuration terminals. The preset service port can be port 80 or port 8080. When an external configuration terminal accesses the gateway address through a browser, it triggers the distribution of a visual configuration page, entering a local visual configuration interface for cloud access parameters and field communication parameters. Through the establishment of this local maintenance channel, the system provides a standardized, low-barrier local interactive entry point for subsequent cloud access parameter configuration without requiring the installation of dedicated drivers and host computer software. This allows on-site construction and maintenance personnel to directly access the device through a browser to complete configuration operations. Furthermore, to ensure device operational security, when the DTU module detects a configuration completion command or if no valid operation is detected within a preset time threshold, it will automatically shut down the local web configuration service and DHCP service, restore the network interface to normal operating mode, and exit the pending configuration state, thereby reducing the security risks caused by long-term exposure of the local maintenance channel.

[0077] The aforementioned visual configuration page includes:

[0078] S21. Detect the user's selection event for the communication protocol type identifier on the front-end page;

[0079] S22. When the user selects the MQTT protocol, dynamically load and display the MQTT-specific configuration form;

[0080] S23. When the user selects TCP or UDP protocol, dynamically load and display the Socket-specific configuration form.

[0081] This step is used to build upon the aforementioned local maintenance channel, and its specific processing flow is as follows: Figure 3 As shown, a cloud-based access parameter input interface is provided to users, offering an intuitive and user-friendly interface. Specifically, after the external configuration terminal successfully connects to the local maintenance channel, the lightweight Web service component embedded in the DTU module sends visual configuration page resources to the external configuration terminal. These page resources include page structure description code, style description code, and front-end script code. When the front-end page finishes loading, the built-in script automatically executes the initialization process, obtains the currently stored configuration status through the configuration query interface, and drives the page to execute dynamic rendering logic based on the obtained communication protocol type identifier.

[0082] During the dynamic rendering of the visual configuration page, the front-end script continuously monitors the user's actions on the communication protocol type selection controls. When it detects that the user has set the communication protocol type to Message Queuing Telemetry Transmission Protocol, the script loads and displays a dedicated configuration area corresponding to that protocol on the page. This dedicated configuration area displays input controls for server address, service port, client identifier, authentication information, and message topic. The server address field supports both domain name and IP address input. The service port field can be automatically filled with a preset service port, which can be set to 1883, or modified by the user as needed. The client identifier field is used to input the device's cloud-based identifier information. The client identifier input box can be automatically generated; the front-end script obtains the device's hardware identifier data by accessing the interface provided by the DTU module and automatically generates and fills in the client identifier accordingly. Authentication information includes fields such as access account and access password, and message topics include fields such as subscription topics and published topics. When the front-end script detects that the user has set the communication protocol type to Transmission Control Protocol (TCP) or User Datagram Protocol (UDP), it hides the configuration controls related to Message Queuing Telemetry Transport Protocol (MQTP), retaining only the basic network configuration controls related to socket communication, including at least the server IP address input box and the port number input box. The value range of the port number input box is restricted to a preset range of valid ports, which can be set to 1 to 65535, to prevent the user from entering a port number that is obviously not compliant with the specifications.

[0083] During parameter submission, when the user completes the form and triggers the save operation on the visual configuration page, the front-end script extracts the values ​​of each configuration field from the corresponding configuration form based on the currently selected communication protocol type and encapsulates them into a unified structured data object. This structured data object contains at least a communication protocol type identifier and protocol stack configuration items that have a one-to-one mapping relationship with that identifier. The structured data format can be organized in key-value pairs, and the data encoding format can use common text-based data exchange formats. The front-end script then sends this structured data object as message content to the DTU module's preset receiving interface through the Hypertext Transfer Protocol (HTTP) submission interface. The back-end then parses and stores this structured data. Through the aforementioned dynamic control rendering based on protocol type and the structured encapsulation mechanism of parameters, the system shields configuration items and interference information unrelated to the current protocol at the front-end page layer. Complex protocol differences and verification logic are solidified in the device-side back-end processing flow, while the visual configuration page primarily serves as the front-end interaction entry point for the entire logic control system. This reduces the operational complexity and configuration error rate for on-site construction personnel in multi-protocol configuration scenarios.

[0084] The verification and writing operations of the cloud access parameter set specifically include:

[0085] S31. Call the preset verification rules to perform legality verification on the length and value range of the server address field, port number field and string configuration field in the cloud access parameter set, wherein the format of the server address field includes at least the IP address format;

[0086] S32. If the legality verification passes, the cloud access parameter set is converted into a structured data format to generate a serialized data object;

[0087] S33. Write the serialized data object into a specific storage area of ​​the non-volatile configuration storage area to complete the generation of the persistent configuration data.

[0088] This step is executed by the DTU module's main control microprocessor (MCU) to ensure the validity of the configuration data and to decouple the cloud access parameters from the device firmware logic. For example... Figure 3 As shown in the backend processing section, the processing flow can include three stages: parameter validity verification, data serialization and integrity protection, and non-volatile storage writing.

[0089] Specifically, during the parameter validity verification phase, the MCU invokes preset verification logic to check the cloud access parameters in the buffer. For the server address field, the MCU uses string parsing and matching logic to determine whether its format conforms to preset rules. When the server address is in IP address format, it checks whether it conforms to dotted decimal notation and whether the values ​​of each segment are within the allowed range; when the server address is in domain name format, it verifies the length and character set according to domain name naming conventions to avoid non-standard character combinations. For the port number field, the port parameter is converted to integer form, and it is determined whether it falls within the preset legal port range, rejecting obviously illegal values ​​such as zero port numbers. For the message queue topic, client identifier, and authentication fields, the MCU checks whether its byte length exceeds the preset length limit of the protocol stack buffer. The length limit can be set to a fixed value according to the specific implementation or determined by the compilation configuration, and scans for control characters or other illegal characters that may cause parsing errors. When any verification item fails, the system terminates the subsequent writing process and returns an error message through the configuration interface, ensuring that illegal parameters are not written to the non-volatile configuration storage area.

[0090] During the data serialization and integrity protection phase, after all verification items pass, the system converts the discrete configuration parameters into structured data objects suitable for storage and transmission. Specifically, this step encapsulates the parameter set using JSON text format and organizes it into a key-value pair structure according to a predetermined field order to facilitate subsequent field expansion and parsing and display on the visual configuration page. To improve the reliability of stored data, the system appends an integrity checksum to the end of the serialized data. This integrity checksum is generated using a cyclic redundancy check algorithm and is used to verify whether errors or corruption occurred during the writing and storage processes when the configuration data is read out.

[0091] During the isolation storage and firmware decoupling phase, the system writes serialized data to the non-volatile configuration memory area on the DTU module through the underlying storage driver interface. The non-volatile configuration memory area is implemented using dedicated configuration sectors in the onboard SPI Flash memory. These configuration sectors are planned as specific address regions in the storage mapping, and are separated from the firmware program storage area in both physical layout and logical address planning, thereby avoiding interference between configuration data and firmware code. During the writing process, the system performs storage operations in the order of unlocking, sector erasure, data writing, and locking. After writing is complete, the system reads back the configuration data from the target address and calculates the integrity check code. The integrity check code calculated from the readback data is compared with the integrity check code generated before writing. If the comparison results match, the writing is confirmed as successful. Through the aforementioned independent configuration data storage strategy, cloud access parameters are persistently saved in a form that is separate from firmware logic. When it is necessary to change the cloud platform address, protocol type, or authentication information, only the data in the configuration storage area needs to be updated to complete the switch of the access environment. There is no need to modify or re-flash the firmware program, thereby achieving decoupling of configuration parameters and firmware logic and reducing the complexity of system operation and maintenance.

[0092] With the configuration trial and automatic rollback mechanism enabled, the specific address can correspond to the starting address of the candidate configuration partition. The system first writes the new configuration data to the candidate configuration partition, and then synchronizes it to the running configuration partition after the trial run verification is passed. This further improves the security and recoverability of the configuration update process while keeping the parameters and firmware decoupled.

[0093] The dynamic selection and instantiation operation of the network protocol stack specifically includes:

[0094] S41. Read the communication protocol type identifier from the persistent configuration data;

[0095] S42. Based on the communication protocol type identifier, call the corresponding protocol processing component from the preset protocol library;

[0096] S43. Load the server address, port and authentication credentials in the protocol stack configuration items into the configuration interface of the protocol processing component, and trigger the connection handshake logic.

[0097] This step utilizes cloud access configuration data to drive network protocol stack loading, decoupling cloud access parameters from device firmware logic. The device can switch between different cloud access modes while maintaining the firmware program, relying solely on configuration data in the non-volatile configuration storage area, thus adapting the same firmware to various application scenarios.

[0098] Specifically, the relevant operations are executed by the main control processor of the DTU module. This main control processor can be a microcontroller (MCU) or a system-on-a-chip (SoC) controller. To shield the differences between different underlying communication carriers, a Protocol Abstraction Layer (PAL) is set in the firmware. The PAL encapsulates the underlying network access interface downwards, allowing access through a unified abstract interface regardless of whether the underlying layer uses an embedded TCP / IP protocol stack or an AT command interface provided by an external communication module. Upwards, the PAL provides a unified calling interface for upper-layer business logic. This calling interface includes operations such as connection establishment, data transmission, data reception, and connection release, thus ensuring that upper-layer business logic does not directly depend on specific network protocol stack implementations or communication hardware configurations.

[0099] When the DTU module is in operation, including its normal working state after exiting the configuration state and its working state after power-on restart, the control program initiates the dynamic instantiation process of the network protocol stack based on the stored persistent configuration data. The system first reads the communication protocol type identifier from the configuration data structure in memory. This identifier is defined as an enumeration value during implementation, with different enumeration values ​​corresponding to different communication modes such as message queue telemetry transmission mode, Transmission Control Protocol (TCP) transparent transmission mode, User Datagram Protocol (UDP) transparent transmission mode, Hypertext Transfer Protocol (HTP) mode, Secure Hypertext Transfer Protocol (STP) mode, or Restricted Application Protocol (RAP) mode. The system maintains a pre-built protocol processing component library, which encapsulates various protocol processing components in a modular manner. Based on the read communication protocol type identifier, the control program determines the target protocol component to be activated using a lookup table or conditional branching method, and then performs instantiation operations on that target protocol component: For message queue telemetry transmission mode, the message queue client component is called to allocate the memory resources required for the protocol control block and initialize its internal state machine; for Transmission Control Protocol (TCP) mode or User Datagram Protocol (UDP) mode, the socket communication component is called to create a connection-oriented streaming communication channel or a connectionless datagram communication channel; for Hypertext Transfer Protocol (HTP) mode or Secure Hypertext Transfer Protocol (STP) mode, the hypertext client component is called to initialize session parameters. Through this on-demand instantiation mechanism, the system only creates the protocol stack resources required for the current configuration. When switching between different cloud access modes is required, only the communication protocol type identifier and related parameters in the non-volatile configuration storage area need to be modified to switch between different protocol modes, without recompiling and flashing the firmware code, thus achieving firmware universality and configuration-driven protocol stack selection.

[0100] After the target protocol component is successfully instantiated, the system executes the parameter loading and connection handshake process, mapping the general cloud access parameter set to the configuration structure used internally by the selected protocol component. The control program reads the server address and port number parameters from the persistent configuration data, and fills the server domain name or IP address and corresponding port number into the underlying connection parameter structure. When the server address is represented in the form of a domain name, the domain name resolution process is triggered to obtain the actual IP address used. Regarding authentication information loading, for message queue telemetry transmission mode, the system loads fields such as client identifier, access account, and access password into the corresponding areas of the connection message; for hypertext transfer mode or secure hypertext transfer mode, the system writes token information or other authentication information into the authentication field in the message header; for Transmission Control Protocol pass-through mode or User Datagram Protocol pass-through mode, the system mainly establishes the data transmission channel based on network layer and transport layer parameters, and usually does not attach a separate authentication field to the application layer message. After loading the address and authentication parameters, the control program calls the connection establishment interface provided by the protocol abstraction layer to trigger the connection establishment process with the target cloud platform. This connection establishment process includes steps such as transport layer handshake, application layer session establishment, and authentication confirmation. When the underlying network protocol stack or protocol processing component returns a status indication that the connection has been successfully established and authentication has been completed, the system updates the device's network connection status to online.

[0101] During dynamic selection and instantiation, if the read communication protocol type identifier is not supported by the pre-built component library, or if instantiation fails due to insufficient memory resources, the system records the fault information and switches the device state to fault protection state or back to configuration state so that the external configuration terminal can reissue valid configuration parameters. Through the above-described dynamic selection and instantiation process of the protocol stack driven by configuration data, the device's communication behavior is determined by the cloud access parameters stored in the non-volatile configuration storage area. The firmware itself remains stable and unchanged. Combined with the hardware fingerprint dynamic binding mechanism and the configuration trial and error and automatic rollback mechanism, a highly reliable DTU logical control closed loop centered on configuration data is formed.

[0102] The connection keep-alive control operation specifically includes:

[0103] S51. Set the keep-alive period parameters used to maintain network connectivity;

[0104] S52. Configure a timing mechanism according to the keep-alive cycle parameters, and send a connection keep-alive message to the target cloud platform through the network protocol stack when each keep-alive cycle arrives.

[0105] S53. After sending the connection keep-alive message, start the timeout detection mechanism. If no confirmation response or valid downlink service data is detected from the target cloud platform within the preset time window, determine that the current network connection is abnormal and trigger the reconnection mechanism.

[0106] S54. During the reconnection process, maintain the number of reconnection failures. When the number of reconnection failures exceeds the preset threshold, stop further reconnection and enter the fault protection state.

[0107] This step is executed by the network guardian task running on the DTU module's main control processor. The network guardian task is used to periodically detect the network connection status and handle abnormal situations. By combining timed detection with abnormal handling, the availability of the communication link between the DTU module and the target cloud platform is maintained, and the connection is prevented from being in a dead state for a long time.

[0108] Specifically, after a successful cloud connection establishment, the control program parses connection keep-alive related parameters from persistent configuration data. The system reads the preset keep-alive period parameter, which can be set to a number of seconds, such as sixty seconds, depending on the application scenario. For different communication protocols, the system maps the keep-alive period to the corresponding connection keep-alive configuration content. For Message Queuing Telemetry Transport Protocol (MQTP), the system configures the keep-alive period in the keep-alive field of the connection message and maintains connection activity through the interaction of keep-alive request and keep-alive response messages. For Transmission Control Protocol (TCP) pass-through mode or User Datagram Protocol (UDP) pass-through mode, the system parses user-defined keep-alive data units from the configuration data. Custom keep-alive data can be a hexadecimal byte sequence or a specific string. Simultaneously, the system parses the user-defined keep-alive sending strategy, which can be set to always send according to the keep-alive period or only send when the link is idle.

[0109] During the timed keep-alive phase, the system sets a timer based on the keep-alive period parameters. This timer can be a hardware timer or a software timer based on a real-time operating system. When the timer count reaches the preset keep-alive period, the network daemon triggers the keep-alive message sending logic, calling the underlying network protocol stack interface to send a connection keep-alive message to the target cloud platform. For Message Queuing Telemetry Transport Protocol (MQTP), a standard keep-alive request message is sent; for Transmission Control Protocol (TCP) or User Datagram Protocol (UDP), a user-configured keep-alive data unit (BAG) is sent. In one implementation, the system can enable a traffic-saving strategy: if valid service data is detected within the current keep-alive period, it is considered that the service data also reflects connection activity. The system can reset the timer and skip sending the connection keep-alive message for this period to reduce communication traffic and device power consumption.

[0110] During the timeout detection and disconnection determination phase, the system initiates a timeout detection mechanism simultaneously with sending a connection keep-alive message. This mechanism can be implemented using a countdown counter or status flags to monitor whether the expected response from the cloud platform is received within a preset time window. The length of the preset time window can be set to several seconds, for example, five to ten seconds, depending on the network environment. When a keep-alive response message is received from the cloud platform within the timeout period, or valid downlink business data is received, the system determines that the current connection is healthy and clears the timeout flag associated with this keep-alive process. If the expected response is not received by the end of the timeout period, or if the underlying network interface returns write failure, link unreachable, or other error messages during transmission, the system determines that the current connection has been disconnected or is in a suspended state. At this point, the network daemon closes the current socket connection or communication channel, releases related resources, and triggers the connection reconstruction process.

[0111] To prevent signaling storms caused by a large number of devices simultaneously reconnecting due to network outages or server congestion, a quantitative decision-making model based on discrete-time backoff is introduced in the reconnection control phase. The system maintains a reconnection failure counter. And calculate the waiting time for the next reconnection in real time based on the following mathematical model. .

[0112] ;

[0113] in, To find the minimum value function, It is the base time slice, representing the minimum response period of the physical link; It is an exponential growth term, used to calculate based on the number of failures. Dynamically simulate the nonlinear growth of network congestion; This is an introduced random jitter term used to break up reconnection requests from a large number of devices along the timeline. This is the preset jitter amplitude coefficient; This is a preset maximum waiting time limit to prevent the waiting time from expanding indefinitely. The main control processor sets the system wake-up timer based on the calculation result of the above formula to achieve non-linear adaptive reconnection. When the number of reconnection failures exceeds the preset threshold or the total continuous reconnection time exceeds the set limit, the system determines that it is currently in an unrecoverable fault state and stops reconnection to enter fault protection mode. Depending on the application scenario, the system performs a soft reset self-healing or rollback to configuration. Soft reset self-healing automatically performs a system restart and reinitializes the protocol stack to attempt recovery. Rollback to configuration restarts and automatically enters the configuration state, opening the local maintenance channel to await manual troubleshooting.

[0114] Through the above-mentioned fault self-healing mechanism, the device can maintain the connection activity with the cloud platform when the network environment is normal. In the event of network or configuration abnormalities, it can avoid resource exhaustion or long-term disconnection due to frequent reconnection by using hierarchical reconnection, exponential backoff and fault protection strategies, thereby improving the system's operational reliability in unattended and complex network environments.

[0115] The bidirectional data pass-through session further includes a field device data forwarding process, specifically including:

[0116] S61. Initialize the local peripheral interface of the DTU module;

[0117] S62. Receive uplink data frames from the field controlled devices through the local peripheral interface, encapsulate them into data packets that match the target cloud platform, and send them to the target cloud platform through the bidirectional data pass-through session.

[0118] S63. Receive the service control command issued by the target cloud platform, parse the service control command and remove the network protocol header information, and transmit the obtained valid command payload to the field controlled device through the local peripheral interface.

[0119] This step establishes a transparent data channel between the target cloud platform and the field-controlled devices. These field-controlled devices may include programmable logic controllers (PLCs), various sensors, and instruments. A DTU logic control system supporting one-click cloud configuration completes this process by running transparent transmission service tasks through the main control processor.

[0120] Specifically, during the local peripheral interface initialization phase, after startup or network connection establishment, the system reads serial port-related parameters from persistent configuration data to initialize the local peripheral interface of the DTU module. This local peripheral interface can be a general asynchronous transceiver interface or a differential bus interface. The initialization process includes configuring preset communication rate parameters, data bit depth, stop bit depth, and parity checking method to match the communication specifications of the controlled field devices. For differential bus interfaces, the system initializes the general-purpose input / output pins used for transceiver control, setting their initial state to receive. To address the rate mismatch between high-speed network transmission and low-speed local serial port transmission, the system allocates a circular buffer in memory to temporarily store the data stream received from the field devices. In one implementation, direct memory access can also be enabled to write the received data into the buffer. Simultaneously, the system configures a buffer overflow protection strategy. When the buffer occupancy rate exceeds a preset safety threshold, some new data is discarded and an exception log is recorded to prevent system anomalies caused by buffer exhaustion.

[0121] During the sensor data encapsulation and reporting phase, the system receives input data from the local peripheral interface via interrupt triggering or polling, and identifies frame boundaries according to preset framing rules. Framing rules can include framing based on byte gap timeout, framing based on fixed frame length, or framing based on specific protocol terminators. Using these framing rules, after detecting the completion of a received frame, the system moves the entire frame from the hardware receive buffer to the application layer buffer, preventing data concatenation or frame truncation. Subsequently, the system encapsulates the original data frame according to the currently active network protocol stack type and prepares it for reporting. For message queue mode, the system fills the uplink publish message with the original data frame as payload and sets a preset publish topic. For Transmission Control Protocol (TCP) mode or User Datagram Protocol (UDP) mode, the system writes the original data frame to the socket send buffer. In one implementation, a custom header can be appended to the original data, carrying a device identifier or length field for cloud-based message identification and parsing. For hypertext transmission mode, the system can perform binary-to-text encoding conversion on the original data frame, such as based on 64-bit or hexadecimal encoding, and encapsulate the converted text data into the message body of the uplink request message. After encapsulation, the transparent transmission service task calls the network sending interface to send the data packet to the target cloud platform through the established bidirectional data transparent transmission session.

[0122] During the business instruction reception and transparent transmission phase, the system continuously receives downlink data from the target cloud platform through the network protocol stack. When a business control instruction data packet is received from the cloud platform, the system first performs a protocol integrity check according to preset rules. Integrity check can use a cyclic redundancy check (CRC) code, a checksum algorithm, or other verification algorithms. Processing continues only if the check result indicates the data is correct. Subsequently, the system strips the network protocol header and extracts the valid instruction payload based on the currently used network protocol type. In message queue mode, the system parses the downlink distribution message, stripping fixed header information and subject fields, retaining only the binary instruction data in the payload. In Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) mode, the system reads data from the socket receive buffer. When a custom header is detected, it is parsed according to a preset format and the custom header is removed, retaining only the subsequent instruction data. In structured text-based business modes, the cloud platform can issue instructions in structured text format. The system parses the text object structure, extracts the content named "data field," and converts this content into binary instruction data using an agreed-upon encoding method, such as converting a hexadecimal string into its corresponding byte sequence or decoding a hexadecimal-encoded string into binary data.

[0123] After receiving a valid instruction payload, the system sends the instruction data to the controlled field devices through the local peripheral interface, achieving transparent forwarding of downlink service instructions. For the differential bus interface, the system strictly controls the timing of the transmit / receive state switching before transmission. By setting the transmit / receive control pin to the transmit enable state, the bus is driven into transmit mode. After data transmission is completed and the transmit buffer is confirmed to be free, the transmit / receive control pin is immediately restored to the receive state, ensuring the reliability of the bus in half-duplex communication mode. Through the complete process of receiving and framing from the local peripheral, encapsulating and reporting on the network side, parsing and reverse transparent transmission of local instructions, the system achieves bidirectional transparent data transmission with the cloud platform without changing the original communication protocol of the field devices. While ensuring data real-time performance and integrity, it provides field devices with unified access capabilities to the cloud.

[0124] The method further includes a hardware fingerprint dynamic binding process, specifically including:

[0125] S71. Allow the client identifier field and message topic field in the cloud access parameter set to be configured using preset wildcard placeholders;

[0126] S72. Before initiating the connection establishment and identity authentication process for the target cloud platform, read the hardware unique identifier set at the bottom layer of the DTU module.

[0127] S73. Dynamically replace the wildcard placeholder with the hardware unique identifier read from the hardware unique identifier set to generate a device-specific protocol stack configuration item.

[0128] This step is executed collaboratively during the configuration distribution and connection initialization phases to address issues such as low efficiency of manual configuration on a per-device basis and conflicts in device communication identities during batch deployments. Figure 4 As shown, based on the data flow path within the system, this process can be divided into three stages: configuration template distribution, hardware fingerprint reading, and dynamic replacement and identity generation. The configuration template distribution stage occurs when cloud access parameters are written to the non-volatile configuration storage area through the local maintenance channel. The hardware fingerprint reading and dynamic replacement and identity generation stages occur before the network protocol stack is initialized during device runtime. This timing arrangement, which stores the original template during configuration writing and performs dynamic replacement based on the hardware fingerprint during runtime, decouples the configuration data from the specific device identifier in time.

[0129] During the configuration template distribution phase, operations and maintenance personnel can create a general configuration template through an external configuration terminal or cloud configuration platform, eliminating the need to fill in specific serial numbers or identification fields for each device individually. When generating structured configuration instructions, wildcard placeholders can be set in the client identification field or message subject field as placeholders for hardware fingerprints. Wildcard placeholders use text markers with specific symbols to indicate the filling position for unique hardware identifiers such as International Mobile Equipment Identity (IMISA), Media Access Control (MAC) addresses, or chip serial numbers. For example, a user can set the client identification field to a string consisting of a fixed prefix plus an IISA placeholder, indicating that the placeholder will be replaced by the device's own IISA. The aforementioned structured configuration instructions are distributed to the DTU module through the target cloud platform, which can be done via pass-through. After receiving the structured configuration instructions, the DTU module writes the configuration template containing the wildcard placeholders into the non-volatile configuration storage area in its original form. At this point, the storage area stores the original template data with placeholders, not the final communication identity that has been replaced, thus decoupling the template content from the specific device fingerprint at the storage level.

[0130] During the hardware fingerprint reading phase, when the DTU module powers on and prepares to initialize the network protocol stack, the control program reads the device's unique hardware identifier set through the underlying driver interface. The unique hardware identifier set includes at least one or more of the following identifiers: For devices with integrated cellular communication units, the system reads the International Mobile Equipment Identity (IMSI) or International Mobile Subscriber Identity (IMSSI) through the cellular communication unit interface; for devices with wireless LAN or Ethernet interfaces, the system reads the Media Access Control (MAC) address through the network controller driver; for devices with a unique identifier register on the main control chip or an external security chip, the system can read the unique identifier inside the chip or the serial number of the security chip. This hardware identifier data is written into the system information data structure in memory. During implementation, a priority strategy for identifier usage can be set, such as prioritizing the IMSI and using the MAC address or chip serial number as a fallback when the IMSI cannot be obtained, to ensure that each device has at least one usable unique identifier source.

[0131] During the dynamic replacement and identity generation phase, before loading the cloud access configuration parameters into the network protocol stack and initiating a connection with the target cloud platform, the data processing logic within the DTU module performs string scanning and replacement operations on the configuration template loaded from the non-volatile configuration storage area into memory. The system traverses fields related to communication identity, such as the client identifier field and message subject field, checking for wildcard placeholders that conform to preset rules. When a placeholder is detected, the system reads the corresponding type of real hardware identifier value from the system information data structure and replaces the placeholder text in the template with this hardware identifier value. For example, if the client identifier template consists of a project prefix plus an International Mobile Equipment Identity (IMSI) placeholder, and the IMSI actually read by the device is a specific numeric string, the system replaces the placeholder with that numeric string, thereby generating a specific client identifier string. During the replacement process, the system organizes the combined identifier according to preset formatting rules to meet the target cloud platform's specifications for identifier fields. Formatting rules can include character cleansing operations such as removing separators from media access control addresses and standardizing letter case. When the length of the replaced string exceeds the maximum length allowed by the cloud, a truncation strategy can be used to cut off the first few characters of the maximum length, or a hash mapping strategy can be used to calculate a digest value of the original long string and use the digest result as part of the identifier to ensure uniqueness while meeting the length limit. When the replacement result contains special characters that are not accepted by the cloud platform, it can be corrected by character escaping or replacing them with allowed characters. Through the collaborative process of template distribution, hardware fingerprint reading, and dynamic replacement and formatting, multiple DTU devices using the same configuration template can automatically generate non-conflicting communication identity identifiers based on their respective unique hardware identifiers, thereby significantly reducing the workload of manual configuration and the risk of identity conflicts in batch deployment and remote configuration scenarios.

[0132] The method further includes configuring a trial-and-error and automatic rollback process, specifically including:

[0133] S81. Logically divide the non-volatile configuration storage area into a running configuration partition and a candidate configuration partition, write the newly received cloud access parameter set into the candidate configuration partition, and mark the configuration status as pending verification.

[0134] S82. When initializing the network protocol stack and initiating a connection establishment attempt to the target cloud platform, read the parameters in the candidate configuration partition as the current connection parameters.

[0135] S83. If the connection established based on the candidate configuration partition parameters is successful and the identity authentication is passed, the data of the candidate configuration partition is synchronously overwritten to the running configuration partition, and the configuration state is updated to a stable state.

[0136] S84. If the number of connection attempts based on the candidate configuration partition parameters fails exceeds a preset threshold, an automatic rollback strategy is triggered to mark the candidate configuration partition as invalid and reload the historical valid parameter set in the running configuration partition to restore network connectivity.

[0137] This step is completed jointly by the DTU module's main control processor and non-volatile storage management logic. It is used to prevent prolonged device downtime and achieve self-healing in unattended scenarios when configuration parameters issued from the cloud are mismatched or unavailable. For example... Figure 5 As shown, the system adopts a dual-partition mechanism of running configuration partition and candidate configuration partition in terms of storage structure and connection control logic, and controls the configuration activation process through the state flow of trial operation, verification, solidification or rollback.

[0138] During the storage partitioning and configuration caching phase, the system logically or physically divides the non-volatile configuration storage area into two isolated regions during initialization. One region serves as the running configuration partition, storing historically valid parameters that have been verified and ensure normal device network connectivity. The other region serves as the candidate configuration partition, temporarily storing newly issued but unverified parameters for testing. A configuration status flag is set in the storage area to indicate whether the current configuration is in a stable or pending verification state. When the DTU module receives a new set of access parameters from the cloud and completes parameter validity verification, the system does not overwrite the historically valid parameters in the running configuration partition. Instead, it writes the new parameter set to the candidate configuration partition and updates the configuration status flag to pending verification. At this time, the parameters in the running configuration partition remain unchanged, serving as a rollback baseline in case of potential rollback operations.

[0139] During the candidate parameter priority reading and trial operation phase, when the network protocol stack is initialized, the control program first reads the configuration status flag. When the configuration status is pending verification, the system prioritizes loading configuration parameters from the candidate configuration partition and performs integrity verification on the loaded data. Integrity verification can be achieved through methods such as checksum comparison. If the candidate configuration data fails verification, the candidate configuration is ignored, and historically valid parameters are loaded from the running configuration partition and used for connection initialization with that parameter set. If the candidate configuration data is intact, the network protocol stack is instantiated using this candidate parameter set, and a connection establishment and authentication process is initiated to the target cloud platform. During this process, the system maintains a retry counter and a trial operation timer to record the number of connection attempts based on the candidate configuration and the duration of the trial operation.

[0140] During the connection success and configuration solidification phase, when a connection attempt based on a candidate configuration succeeds—specifically, when the network protocol stack reports a successful connection establishment and authentication—the system determines the current candidate configuration as valid. The system then executes the configuration solidification process, completely copying and overwriting the data blocks from the candidate configuration partition to the running configuration partition, ensuring data consistency between the two. The configuration status flag is then updated to a stable state, and the retry counter is cleared. Through this process, the new configuration parameters are officially solidified as the current valid configuration. Upon subsequent power failures and restarts, the system will directly load this configuration from the running configuration partition to continue operation.

[0141] During the automatic rollback and connection recovery phase, when connection attempts based on the candidate configuration continuously fail and preset rollback trigger conditions are met, the system initiates an automatic rollback strategy. Rollback trigger conditions may include the number of connection retries based on the candidate configuration exceeding a preset rollback threshold (which can be set to a certain number of retries), the trial run duration exceeding a preset time threshold (which can be set to a certain number of minutes), or the underlying communication interface returning a clear, unrecoverable error state, such as the communication module being unresponsive. When any of the above conditions are met, the system determines that the current candidate configuration is unavailable, immediately performs a rollback operation, restores the configuration status flag to a stable state, and may erase or mark the candidate configuration partition as invalid to prevent subsequent misuse of the invalid configuration. Subsequently, the system switches the configuration loading logic back to the running configuration partition, reloads the historical valid parameter set from the running configuration partition, reinitializes the network protocol stack based on this parameter set, and initiates the connection establishment process. Under this mechanism, even if the cloud sends out an incorrect access address, port, or authentication information, the device can automatically identify the unavailability of the configuration and roll back to the last available configuration through a limited number of trial runs in an unattended environment. This restores the communication connection with the cloud platform, improves the device's online rate, and enhances the system's robustness in remote configuration scenarios.

[0142] Example 2

[0143] like Figure 1 As shown, a DTU logic control system that supports one-click cloud configuration includes:

[0144] The local maintenance channel establishment module is used to start the embedded local web configuration service and perform a local maintenance channel establishment operation when the DTU module is in the configuration state. The local maintenance channel establishment operation establishes a local maintenance channel with the external configuration terminal by activating the local network interface.

[0145] The visual configuration interaction module is used to send a visual configuration page to the external configuration terminal through the local maintenance channel and receive the cloud access parameter set submitted by the external configuration terminal. The cloud access parameter set includes at least a communication protocol type identifier and a protocol stack configuration item that is mapped to the communication protocol type identifier.

[0146] The parameter verification and storage module is used to perform verification and writing operations on the cloud access parameter set, and write the verified cloud access parameter set into the non-volatile configuration storage area of ​​the DTU module to generate persistent configuration data independent of the device firmware logic.

[0147] The network protocol stack dynamic selection and instantiation module is used to perform network protocol stack dynamic selection and instantiation operations after exiting the configuration mode or restarting the device. The network protocol stack dynamic selection and instantiation operations are used to read the persistent configuration data, select, enable or instantiate the corresponding network protocol stack based on the communication protocol type identifier and protocol stack configuration items therein, and initiate a connection establishment and identity authentication process for the target cloud platform.

[0148] The session establishment and keep-alive module is used to establish a bidirectional data pass-through session between the DTU module and the target cloud platform after successful identity authentication, and to perform connection keep-alive control operations to maintain the availability of network connectivity.

[0149] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the invention. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

[0150] The preset parameters or preset thresholds mentioned above are all set by those skilled in the art based on actual conditions or obtained through large-scale data simulation.

[0151] The above embodiments are only used to illustrate the technical methods of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical methods of the present invention without departing from the spirit and scope of the technical methods of the present invention.

Claims

1. A DTU logic control method supporting one-click cloud configuration, characterized in that, include: S1. When the DTU module is in the configuration state, start the embedded local web configuration service and perform a local maintenance channel establishment operation. The local maintenance channel establishment operation establishes a local maintenance channel with the external configuration terminal by activating the local network interface. S2. Send a visual configuration page to the external configuration terminal through the local maintenance channel, and receive the cloud access parameter set submitted by the external configuration terminal. The cloud access parameter set includes at least a communication protocol type identifier and a protocol stack configuration item that is mapped to the communication protocol type identifier. S3. Perform the verification and writing operation of the cloud access parameter set, and write the verified cloud access parameter set into the non-volatile configuration storage area of ​​the DTU module to generate persistent configuration data independent of the device firmware logic. S4. After exiting the configuration mode or restarting the device, perform a dynamic selection and instantiation operation of the network protocol stack. The dynamic selection and instantiation operation of the network protocol stack is used to read the persistent configuration data, select, enable or instantiate the corresponding network protocol stack based on the communication protocol type identifier and protocol stack configuration items, and initiate a connection establishment and identity authentication process for the target cloud platform. S5. After successful identity authentication, establish a two-way data pass-through session between the DTU module and the target cloud platform, and perform connection keep-alive control operations to maintain the availability of network connectivity.

2. The DTU logic control method supporting one-click cloud configuration according to claim 1, characterized in that, The specific methods for establishing the local maintenance channel include: When the local network interface is configured in wireless mode, the Wi-Fi module of the DTU module is switched to access point mode and a preset service set identifier is broadcast for the external configuration terminal to access. When the local network interface is configured in wired mode, the Dynamic Host Configuration Protocol (DHCP) service of the DTU module Ethernet interface is enabled to dynamically assign a local IP address to the external configuration terminal connected via a network cable.

3. The DTU logic control method supporting one-click cloud configuration according to claim 2, characterized in that, The aforementioned visual configuration page includes: S21. Detect the user's selection event for the communication protocol type identifier on the front-end page; S22. When the user selects the MQTT protocol, dynamically load and display the MQTT-specific configuration form; S23. When the user selects TCP or UDP protocol, dynamically load and display the Socket-specific configuration form.

4. The DTU logic control method supporting one-click cloud configuration according to claim 3, characterized in that, The verification and writing operations of the cloud access parameter set specifically include: S31. Call the preset verification rules to perform legality verification on the length and value range of the server address field, port number field and string configuration field in the cloud access parameter set, wherein the format of the server address field includes at least the IP address format; S32. If the legality verification passes, the cloud access parameter set is converted into a structured data format to generate a serialized data object. S33. Write the serialized data object into the storage area of ​​the non-volatile configuration storage area to complete the generation of the persistent configuration data.

5. The DTU logic control method supporting one-click cloud configuration according to claim 4, characterized in that, The dynamic selection and instantiation operation of the network protocol stack specifically includes: S41. Read the communication protocol type identifier from the persistent configuration data; S42. Based on the communication protocol type identifier, call the corresponding protocol processing component from the preset protocol library; S43. Load the server address, port and authentication credentials in the protocol stack configuration items into the configuration interface of the protocol processing component, and trigger the connection handshake logic.

6. The DTU logic control method supporting one-click cloud configuration according to claim 5, characterized in that, The connection keep-alive control operation specifically includes: S51. Set the keep-alive period parameters used to maintain network connectivity; S52. Configure a timing mechanism according to the keep-alive cycle parameters, and send a heartbeat message or keep-alive message to the target cloud platform through the network protocol stack when each keep-alive cycle arrives. S53. After sending the heartbeat message or keep-alive message, start the timeout detection mechanism. If no confirmation response or downlink valid service data is detected from the target cloud platform within the preset time window, determine that the current network connection is abnormal and trigger the reconnection mechanism. S54. During the reconnection process, maintain the number of reconnection failures. When the number of reconnection failures exceeds the preset threshold, stop further reconnection and enter the fault protection state.

7. The DTU logic control method supporting one-click cloud configuration according to claim 6, characterized in that, The bidirectional data pass-through session further includes a field device data forwarding process, specifically including: S61. Initialize the local peripheral interface of the DTU module; S62. Receive uplink data frames from the field controlled devices through the local peripheral interface, encapsulate them into data packets that match the target cloud platform, and send them to the target cloud platform through the bidirectional data pass-through session. S63. Receive the service control command issued by the target cloud platform, parse the service control command and remove the network protocol header information, and transmit the obtained valid command payload to the field controlled device through the local peripheral interface.

8. The DTU logic control method supporting one-click cloud configuration according to claim 7, characterized in that, The method further includes a hardware fingerprint dynamic binding process, specifically including: S71. Allow the client identifier field and message topic field in the cloud access parameter set to be configured using preset wildcard placeholders; S72. Before initiating the connection establishment and identity authentication process for the target cloud platform, read the hardware unique identifier set at the bottom layer of the DTU module. S73. Dynamically replace the wildcard placeholder with the hardware unique identifier read from the hardware unique identifier set to generate a device-specific protocol stack configuration item.

9. A DTU logic control method supporting one-click cloud configuration according to claim 8, characterized in that, The method further includes configuring a trial-and-error and automatic rollback process, specifically including: S81. Logically divide the non-volatile configuration storage area into a running configuration partition and a candidate configuration partition, write the newly received cloud access parameter set into the candidate configuration partition, and mark the configuration status as pending verification. S82. When initializing the network protocol stack and initiating a connection establishment attempt to the target cloud platform, read the parameters in the candidate configuration partition as the current connection parameters. S83. If the connection established based on the candidate configuration partition parameters is successful and the identity authentication is passed, the data of the candidate configuration partition is synchronously overwritten to the running configuration partition, and the configuration state is updated to a stable state. S84. If the number of connection attempts based on the candidate configuration partition parameters fails exceeds a preset threshold, an automatic rollback strategy is triggered to mark the candidate configuration partition as invalid and reload the historical valid parameter set in the running configuration partition to restore network connectivity.

10. A DTU logic control system supporting one-click cloud configuration, comprising: The local maintenance channel establishment module is used to start the embedded local web configuration service and perform a local maintenance channel establishment operation when the DTU module is in the configuration state. The local maintenance channel establishment operation establishes a local maintenance channel with the external configuration terminal by activating the local network interface. The visual configuration interaction module is used to send a visual configuration page to the external configuration terminal through the local maintenance channel and receive the cloud access parameter set submitted by the external configuration terminal. The cloud access parameter set includes at least a communication protocol type identifier and a protocol stack configuration item that is mapped to the communication protocol type identifier. The parameter verification and storage module is used to perform verification and writing operations on the cloud access parameter set, and write the verified cloud access parameter set into the non-volatile configuration storage area of ​​the DTU module to generate persistent configuration data independent of the device firmware logic. The network protocol stack dynamic selection and instantiation module is used to perform network protocol stack dynamic selection and instantiation operations after exiting the configuration mode or restarting the device. The network protocol stack dynamic selection and instantiation operations are used to read the persistent configuration data, select, enable or instantiate the corresponding network protocol stack based on the communication protocol type identifier and protocol stack configuration items therein, and initiate a connection establishment and identity authentication process for the target cloud platform. The session establishment and keep-alive module is used to establish a bidirectional data pass-through session between the DTU module and the target cloud platform after successful identity authentication, and to perform connection keep-alive control operations to maintain the availability of network connectivity.

Images