End side standard container based on Internet of Things equipment and access method

Abstract

The invention discloses an end side standard container based on Internet of Things equipment and an access method, and relates to the technical field of Internet of Things. According to the system, an end-side standard container is deployed on Internet of Things terminal equipment to serve as a unified adaptive middle layer, and the container adopts a three-layer architecture of an access layer, a kernel layer and an output layer; the access layer realizes protocol compatibility, equipment authentication and data preprocessing; the kernel layer analyzes original data into structured data through a protocol analysis module, a signal conversion module and a data encapsulation module, converts the structured data into unified data type, and encapsulates the structured data into a standard data packet; and the output layer is responsible for secure transmission, edge cloud collaboration and platform docking. Through plug-in protocol compatibility and hot-updatable kernel layer configuration, the problems of Internet of Things equipment protocol fragmentation, safety certification deficiency and poor equipment compatibility are solved, and rapid access, safe and reliable transmission and flexible expansion of the equipment are realized.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) device technology, and more particularly to edge-side standard containers and access methods based on IoT devices. Background Technology

[0002] With the popularization of the Internet of Things (IoT) in fire protection, various fire protection equipment (such as fire alarm controllers, wireless smoke sensors, smart fire hydrants, and AI fire alarm cameras) need to be connected to a unified management platform to achieve real-time fire alarm monitoring and remote operation and maintenance of equipment status. However, the current connection of fire protection equipment faces the following core pain points.

[0003] 1. Protocol incompatibility and high adaptation costs: In the current fire protection equipment market, different manufacturers' equipment uses proprietary communication protocols (such as GB4717-2005 protocol extension, manufacturer-defined RS485 protocol, and LoRa proprietary frame structure). When connecting to a unified management platform, a dedicated protocol parsing module needs to be developed for each type of equipment. For example, connecting 10 types of smoke sensors from different manufacturers requires developing 10 sets of independent parsing code, with an adaptation cycle of 2-4 weeks for a single type of equipment. When adding new equipment later (such as AI fire alarm cameras), the underlying logic of the platform needs to be modified repeatedly, and the operation and maintenance costs increase linearly.

[0004] 2. The lack of a secure authentication mechanism poses a significant risk: Fire equipment access often relies on a simple authentication method of "device ID + static password," lacking verification of device uniqueness and dynamic anti-counterfeiting mechanisms. Unauthorized devices can access the platform by forging device IDs, tampering with fire alarm data (e.g., concealing real fire alarms) or forging alarm information (e.g., false fire alarms), severely impacting the accuracy of fire command decisions and potentially leading to serious consequences such as "misjudgment delaying rescue" or "false alarms wasting resources." This fails to meet the security requirements of "credible identity and complete data" in the "Requirements for Security Level Protection of Fire Information Systems" (GA / T1686-2020).

[0005] 3. Poor device compatibility leads to expansion difficulties: Existing access solutions are tied to specific hardware architectures and operating systems. For example, they only support Linux fire alarm control panels with x86 architecture and are not compatible with low-power wireless smoke detectors of the ARM Cortex-M series (most of which have less than 128MB of memory). When adding devices with different architectures or protocols, the core logic of the access framework needs to be reconstructed. The adaptation period is long and it is easy to cause system stability problems, making it difficult to respond to the emergency needs of "quickly launching new devices" in fire protection scenarios. Summary of the Invention

[0006] The purpose of this invention is to address the problems existing in the background art by proposing a method for rapid access to standard containers on the edge side of IoT devices.

[0007] The technical solution of this invention: a standard container for the edge of an IoT device, wherein the standard container for the edge adopts a three-layer architecture of access layer, kernel layer and output layer, and the construction of the standard container for the edge includes the following steps: S1: Edge-side standard container initialization: Define the hardware compatibility baseline and system compatibility baseline for adapting to IoT terminal devices, and deploy a container basic framework that supports multi-language calls; S2: Access layer construction, including: development protocol compatibility module, terminal device authentication module and raw data preprocessing module. The access layer receives raw data output by IoT terminal devices, and after protocol parsing, identity verification and data preprocessing, outputs standardized raw data in protocol identifier and binary stream format. S3: Kernel layer construction, including: a protocol parsing module, used to load the protocol rule base and perform structured parsing on the standardized raw data received from the access layer; a data fault tolerance and resilience module, used to implement multiple fault tolerance mechanisms during data transmission; a signal conversion module, used to convert the parsed data into a unified data type according to a preset data type mapping table; a data encapsulation module, used to encapsulate standardized data into data packets of a specific format according to a data format template; and a configuration module, used to store and manage the protocol rule base, data type mapping table, and data format template. S4: Output Layer Construction: Develop a secure transmission module, an edge cloud collaboration module, and a platform docking module. The output layer receives standardized data output from the kernel layer, and after encrypted transmission, edge local processing, and standard interface adaptation, completes the access of IoT terminal devices and management platforms.

[0008] As a further improvement of this application, a standard container on the edge is provided with a built-in device management function module. The device management function module is connected to the kernel layer and the output layer and is used to monitor and manage the lifecycle of the IoT terminal device carrying the container. The device management function module includes: a power monitoring unit, a data SIM card management unit, and a remote configuration unit.

[0009] As a further improvement of this application, the power monitoring unit is used to collect device battery power data in real time and generate low power alarm information when the power is lower than a preset threshold, and report it to the IoT platform through the output layer; the data card management unit is used to monitor the data usage and connection status of the IoT SIM card, and trigger an alarm when the data is exhausted or the card is abnormal; the remote configuration unit provides a remote command interface for receiving and executing configuration update or firmware upgrade commands from the IoT platform to realize remote hot update of the container.

[0010] As a further improvement to this application, the hardware compatibility baseline is configured to support mainstream embedded architectures, including ARM architecture, x86 architecture and MIPS architecture. The system compatibility baseline is achieved through the operating system adaptation layer. The OSAL layer is configured to be compatible with Linux, RTOS and Android systems. In the RTOS environment, the container process priority is configured to be 3-5 levels, and the container process priority is 1-2 levels lower than the priority of the core monitoring task of the IoT terminal device. The multi-language calling interface of the container infrastructure includes a C language dynamic library, a Java Jar package, and a Python module.

[0011] As a further improvement of this application, the protocol parsing module is used to load the protocol rule base and perform structured parsing on the standardized raw data received from the access layer; wherein, the protocol rule base defines the frame structure and parsing algorithm of various communication protocols, and the protocol parsing module automatically selects the corresponding rule by analyzing the header features of the data packet, and deconstructs the binary stream into structured data in the form of key-value pairs; The signal conversion module is connected to the protocol parsing module and is used to convert the structured data into a unified data type according to a preset data type mapping table. The data type mapping table defines the mapping relationship between input key name, original type, scaling ratio, offset and output key name, standard type and standard unit, and completes the standardization conversion between numerical value and type through calculation. The data encapsulation module is connected to the signal conversion module and is used to encapsulate the converted standardized data into a data packet of a specific format according to a predefined data format template. The data format template is formally described using JSON Schema, and the encapsulation process includes injecting a unique device identifier and a data acquisition timestamp to generate a complete data object that the platform can recognize.

[0012] As a further improvement to this application, the data fault tolerance and resilience module includes: a critical data multiple backup unit, which stores key fields such as fire alarm status, equipment location, and sensor readings in real time with multiple copies; a data integrity verification unit, which uses a dual verification mechanism of CRC32 and SHA-256 to verify the integrity of the data before and after parsing; and a data self-repair unit, which performs intelligent repair and supplementation based on historical data patterns and data from adjacent nodes when partial data corruption is detected.

[0013] As a further improvement to this application, the kernel layer also includes a configuration module for maintaining lightweight storage inside the container to persistently manage the protocol rule base, data type mapping table, and data format template; the configuration module also includes a remote command interface, which exposes a dedicated configuration topic through the output layer for receiving, parsing, and executing JSON update commands conforming to a predetermined format from the IoT management platform, thereby realizing dynamic hot updates of the protocol rule base, data type mapping table, or data format template without restarting the device or container.

[0014] As a further improvement to this application, the protocol compatibility module is configured to support common communication protocols in IoT scenarios, including RS485 protocol, LoRa protocol and NB-IoT protocol, and adopts a plug-in design, with each protocol plug-in having a size of ≤500KB, and uniformly providing data parsing interface and data encapsulation interface; The terminal device authentication module is implemented as a two-factor authentication mechanism, specifically including: Initial connection: Collect the hardware fingerprint and device-specific identifier of the IoT terminal device; Subsequent access: IoT terminal devices submit the device identity certificate and the temporary verification code issued by the management platform. Only after successful authentication can a data connection be established. The raw data preprocessing module is implemented as a three-level process: noise reduction, caching, and format unification.

[0015] As a further improvement of this application, the configuration module includes a remote command interface for receiving update commands from the IoT platform through the output layer, and dynamically updating the stored protocol rule base, data type mapping table or data format template based on the commands. The protocol parsing module loads multiple protocol rules in parallel and automatically selects the corresponding rule for parsing by analyzing the header features of the data packets.

[0016] As a further improvement to this application, the secure transmission module is configured as an encrypted transmission mechanism based on the MQTT protocol.

[0017] As a further improvement to this application, the edge cloud collaboration module is configured in an edge local processing and cloud aggregation and control mode, wherein: Edge nodes: Deployed at edge control nodes, they enable local judgment of high-priority data, filtering of regular data, and triggering of emergency alarms, while only reporting high-priority and medium-priority data to the cloud; Cloud: Receives key data uploaded by edge nodes, summarizes the regional IoT status, and issues global control commands to edge nodes.

[0018] As a further improvement to this application, the platform interface module is configured with a standardized interface and an automated testing suite, wherein: Standardized interfaces: including HTTPRESTful API and MQTT topics, with both API request bodies and MQTT message bodies being JSON format data output from the kernel layer; Automated testing suite: Simulates abnormal operating conditions in IoT scenarios, with test indicators including data transmission success rate ≥99.5%, high-priority data AoL deviation ≤100ms, and generates device access acceptance reports.

[0019] The method for accessing standard containers on the edge based on IoT devices includes the following steps: Deploy the container executable file to the IoT device file system and start running it; The device's raw data is captured by the access layer, parsed, fault-tolerant and damage-resistant processed, converted and encapsulated by the kernel layer to form a standardized data packet, which is then sent to the IoT platform through the output layer. The IoT platform sends management commands to the output layer, which are then parsed and executed by the configuration module to complete the parameter configuration or operation control of the device.

[0020] Compared with existing technologies, the beneficial effects of this invention are: 1. This invention solves the problem of fragmented IoT protocols, enabling rapid device integration and low-cost adaptation. Through a plug-in-designed protocol compatibility module and a dynamically updatable kernel-level protocol rule library, it modularizes and standardizes the parsing functions of various private / heterogeneous protocols. When adding a new device type, only the corresponding protocol plugin needs to be developed, without modifying the platform's core code. This shortens the adaptation cycle for a single device type from weeks to days, significantly reducing development and subsequent maintenance costs, and enabling plug-and-play functionality for rapid device integration.

[0021] 2. This invention achieves deep standardization of IoT device data through refined kernel-level construction, significantly improving the system's data processing capabilities and adaptability. The kernel layer, relying on a dynamically updatable protocol rule base, can parse multiple private or heterogeneous protocols in parallel, accurately converting raw binary data into structured information. Through a pre-defined data type mapping table, it automatically completes unified conversion and type standardization of data units, resolving the pain point of semantic inconsistencies in multi-source data. Based on configurable data format templates, heterogeneous data is encapsulated into standardized data packets that the platform can directly recognize, greatly simplifying the processing logic of upper-layer applications. This series of processes allows for rapid adaptation by updating the kernel-level configuration without modifying the platform architecture when adding new device types. Simultaneously, the configuration module supports remote hot-update commands, dynamically adjusting parsing rules, mapping relationships, and encapsulation templates without system downtime, enabling continuous evolution and on-site optimization. This effectively reduces system maintenance costs and upgrade risks, comprehensively improving the standardization, flexibility, and maintainability of data access. Attached Figure Description

[0022] Figure 1 This is a schematic diagram of the structure of the standard container on the end side in an embodiment of the present invention; Figure 2 This is a flowchart of the method for rapid access to standard containers on the edge side based on IoT devices proposed in this invention. Detailed Implementation

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

[0024] See attached document Figure 1 The edge-side standard container, based on IoT devices, is applied in IoT scenarios. It serves as a unified adaptation middleware layer between IoT terminal devices and management platforms. The edge-side standard container adopts a three-layer architecture consisting of an access layer, a kernel layer, and an output layer. The construction of the edge-side standard container includes the following steps: S1: Edge-side standard container initialization: Define the hardware compatibility baseline and system compatibility baseline for adapting to IoT terminal devices, and deploy a container basic framework that supports multi-language calls; S2: Access layer construction, including: development protocol compatibility module, terminal device authentication module and raw data preprocessing module. The access layer receives raw data output by IoT terminal devices, and after protocol parsing, authentication and data preprocessing, outputs standardized raw data in protocol identifier and binary stream format. S3: Kernel layer construction, including: a protocol parsing module, used to load the protocol rule base and perform structured parsing on the standardized raw data received from the access layer; a data fault tolerance and resilience module, used to implement multiple fault tolerance mechanisms during data transmission; a signal conversion module, used to convert the parsed data into a unified data type according to a preset data type mapping table; a data encapsulation module, used to encapsulate standardized data into specific format data packets according to data format templates; and a configuration module, used to store and manage the protocol rule base, data type mapping table, and data format templates. S4: Output Layer Construction: Develop a secure transmission module, an edge cloud collaboration module, and a platform docking module. The output layer receives standardized data output from the kernel layer, and after encrypted transmission, edge local processing, and standard interface adaptation, completes the access of IoT terminal devices and management platforms.

[0025] In step S1, specifically, the hardware compatibility baseline is configured to support mainstream embedded architectures, including ARM, x86, and MIPS architectures, wherein: ARM architecture devices have a minimum operating memory of ≥20MB and a minimum storage capacity of ≥10MB. x86 architecture devices have a minimum running memory of ≥64MB and a minimum storage capacity of ≥32MB. MIPS architecture devices have a minimum running memory of ≥32MB and a minimum storage capacity of ≥16MB. This allows it to be adapted to low-power sensors and high-performance control devices.

[0026] In addition, the system compatibility baseline is achieved through the operating system adaptation layer. The OSAL layer is configured to be compatible with Linux, RTOS and Android systems. In the RTOS environment, the container process priority is configured to be 3-5 levels. The container process priority is 1-2 levels lower than the core monitoring task priority of IoT terminal device to avoid resource contention. The container infrastructure framework's multi-language calling interface includes a C language dynamic library, a Java Jar package, and a Python module. The C language dynamic library supports ARM and x86 architectures; the Java Jar package version is 1.0; and the Python module supports Python 3.6 and above.

[0027] In step S2, specifically, the protocol compatibility module is configured to support common communication protocols in IoT scenarios, including RS485, LoRa and NB-IoT protocols, and adopts a plug-in design, with each protocol plug-in having a size of ≤500KB, and uniformly providing data parsing interface and data encapsulation interface.

[0028] In this embodiment, the protocol_parse() (data parsing) and protocol_pack() (data encapsulation) interfaces are provided uniformly, and new protocols only require the development of dedicated plugins.

[0029] In addition, the terminal device authentication module is implemented as a two-factor authentication mechanism, specifically including: Initial connection: Collect the hardware fingerprint and device-specific identifier of the IoT terminal device. Specifically, generate a device identity certificate in X.509V3 format. The hardware fingerprint includes the CPU serial number, MAC address and operating system version. The device-specific identifier is a 10-character fixed format string. Subsequent access: IoT terminal devices submit their device identity certificate and temporary verification code issued by the management platform. Data connection can only be established after authentication is successful.

[0030] Specifically, in this embodiment, the raw data preprocessing module is implemented as a three-level processing of noise reduction, caching, and format unification, including: using sliding window average filtering to reduce data interference, with the filtered data error ≤ ±0.1%; using a circular buffer to temporarily store burst data, triggering an overflow alarm and discarding the earliest data when the buffer is full; and encapsulating the preprocessed data into a 1-byte protocol identifier and a binary stream format, with the protocol identifier corresponding one-to-one with the communication protocol.

[0031] Specifically, in this embodiment, noise reduction can be achieved through a 5-point sliding window filter, and burst data can be temporarily stored using a circular buffer, ultimately encapsulated into a "1-byte protocol identifier + binary stream" format.

[0032] In step S3, specifically, the protocol parsing module is used to load the protocol rule base and perform structured parsing on the standardized raw data received from the access layer; wherein, the protocol rule base defines the frame structure and parsing algorithm of various communication protocols, and the protocol parsing module automatically selects the corresponding rule by analyzing the header features of the data packet, and deconstructs the binary stream into structured data in the form of key-value pairs; The data fault tolerance and resilience module includes: a critical data multiple backup unit, which stores key fields such as fire alarm status, equipment location, and sensor readings in real time with multiple copies; a data integrity verification unit, which uses CRC32 and SHA-256 dual verification mechanisms to verify the integrity of data before and after parsing; and a data self-repair unit, which performs intelligent repair and supplementation based on historical data patterns and data from adjacent nodes when partial data corruption is detected. The signal conversion module is connected to the protocol parsing module and is used to convert structured data into a unified data type according to a preset data type mapping table. The data type mapping table defines the mapping relationship between input key name, primitive type, scaling ratio, offset and output key name, standard type, standard unit, and completes the standardized conversion between numerical value and type through calculation. The data encapsulation module is connected to the signal conversion module and is used to encapsulate the converted standardized data into a data packet of a specific format according to a predefined data format template. The data format template is formally described using JSON Schema. The encapsulation process includes injecting a unique device identifier and a data acquisition timestamp to generate a complete data object that the platform can recognize.

[0033] The kernel layer also includes a configuration module, which maintains lightweight storage inside the container to persistently manage the protocol rule base, data type mapping table, and data format templates. The configuration module also includes a remote command interface, which exposes a dedicated configuration topic through the output layer to receive, parse, and execute JSON update commands conforming to a predetermined format from the IoT management platform, thereby enabling dynamic hot updates of the protocol rule base, data type mapping table, or data format templates without restarting the device or container.

[0034] Step S3 specifically includes the following steps: S31: Protocol parsing module: The protocol rule base contains a set of configurable data structures that describe how to parse various device protocols. For example, a rule base supporting Modbus RTU and custom binary protocols would include the following: Frame structure definition: The Modbus protocol rules define the start bit (implicit), device address field, function code field, data field, and CRC check field.

[0035] Parsing Algorithm: A corresponding parsing function is written for each protocol. In this embodiment, the Modbus parsing function extracts each field value sequentially and verifies the CRC checksum. For custom protocols, the rule base defines the specific positions of the header, trailer identifiers, and length field.

[0036] Rule Index: Each rule has a unique identifier, which makes it easy for the configuration module to call it.

[0037] Workflow: After obtaining the raw binary data stream from the access layer, the protocol parsing module first performs a frame integrity check, and then calls the corresponding parsing algorithm based on the currently active protocol_id to deconstruct the binary stream into semantic key-value pairs.

[0038] S32: Signal conversion module The pre-defined data type mapping table contains the following: This mapping table is a two-dimensional relational table whose purpose is to unify data parsed from different devices that have the same meaning but different representations into the standard format specified by the platform. This table must contain at least the following fields: input_key: The key name of the data after protocol parsing; input_type: The primitive type of the input data; input_scale: The scaling factor for the input data; input_offset: The offset of the input data; output_key: The standard key name of the output after conversion; output_type: The standard type of the output data; output_unit: The standard unit of output data.

[0039] Workflow: The signal conversion module receives key-value pairs from the protocol parsing module. Using `input_key` as an index, it queries the data type mapping table. Upon finding a match, it performs a conversion calculation: Output value = (Input value * input_scale) + input_offset, and converts the data type of the result to `output_type`. The specific calculation method is: "Output value = (Input value × Scaling ratio) + Offset".

[0040] S33: Data encapsulation module: The data format template defines the structure of the final data packet reported to the IoT platform. It uses JSON Schema or a similar formal description, specifically: { "deviceId":"STRING", / / Unique identifier for the device "timestamp":"INT64", / / Data collection timestamp "payload":{ "temperature":"FLOAT", "humidity":"FLOAT", "status":"INT" } }; Workflow: The data encapsulation module receives the transformed, standardized data. It retrieves the deviceId from the container configuration, the current timestamp, and the transformed data, then populates the data according to a template to generate a complete JSON object. Example: {"deviceId":"SN12345","timestamp":1697012345678,"payload":{"temperature":-14.4,"humidity":65.2}}.

[0041] S34: Configuration module. This module includes a remote command interface for receiving update commands from the IoT platform via the output layer. Based on these commands, it dynamically updates the stored protocol rule base, data type mapping table, or data format template. The protocol parsing module loads multiple protocol rules in parallel and automatically selects the corresponding rule for parsing by analyzing packet header features. Specifically: Storage and Management: The configuration module maintains a lightweight database or configuration file inside the container to persistently store the aforementioned protocol rule base, data type mapping table, and data format templates.

[0042] Remote command interface: This module exposes a dedicated configuration topic at the output layer. When the IoT platform publishes a JSON command conforming to a predefined format to this topic, the configuration module receives, parses, and executes the command, dynamically updating its internally stored mapping tables or rule bases to achieve hot updates of container behavior without restarting the device.

[0043] This invention achieves deep standardization of IoT device data through refined kernel-level construction, significantly improving the system's data processing capabilities and adaptability. The kernel layer, relying on a dynamically updatable protocol rule base, can parse multiple private or heterogeneous protocols in parallel, accurately converting raw binary data into structured information. Through a pre-defined data type mapping table, it automatically completes unified conversion and type standardization of data units, resolving the pain point of semantic inconsistencies in multi-source data. Based on configurable data format templates, heterogeneous data is encapsulated into standardized data packets that the platform can directly recognize, greatly simplifying the processing logic of upper-layer applications. This series of processes allows for rapid adaptation to new device types without modifying the platform architecture; only kernel-level configuration updates are needed. Simultaneously, the configuration module supports remote hot-update commands, dynamically adjusting parsing rules, mapping relationships, and encapsulation templates without system downtime. This enables the system to continuously evolve and be optimized in the field, effectively reducing system maintenance costs and upgrade risks, and comprehensively improving the standardization, flexibility, and maintainability of data access.

[0044] It should also be noted that, in step S3, the data fault tolerance and resilience module included in the kernel layer of this invention is designed with a multi-layered protection mechanism to address the special conditions in fire scenarios where fires may cause equipment damage, data loss, or communication interruptions, including: Multiple backups for critical data: For critical fields such as fire alarm status, equipment coordinates, and sensor thresholds, three copies are stored synchronously in container memory, local flash memory, and edge nodes to ensure that a single point of failure does not affect data integrity. Dual verification mechanism: CRC32 fast verification and SHA-256 strong verification are performed before and after protocol parsing, respectively, and a retransmission or repair process is triggered when data corruption is detected; Intelligent data repair: When sensor data such as temperature and smoke concentration become abnormal due to fire interference, a lightweight ARIMA model is used to perform real-time interpolation and prediction based on historical data trends and readings of nearby sensors, outputting reasonable values ​​after repair, and marking the repaired:true field in the data packet. Fire Emergency Mode: When the system detects that the ambient temperature continues to exceed 85℃ or the network signal strength is below -100dBm, the emergency transmission mode is automatically activated. Only core information such as fire alarm identifier, device ID, and GPS coordinates are sent. The system uses a simplified binary protocol encapsulation to ensure that alarms can still be issued under extreme conditions.

[0045] The data fault tolerance and resilience module is specifically designed for extreme emergency scenarios such as firefighting. It aims to ensure that critical fire safety information (such as fire alarm status and equipment location) remains intact, verifiable, recoverable, and reliably transmitted even in the event of partial equipment damage, unstable communication links, or corrupted data packets due to fire. The specific implementation steps for this module are as follows: The critical data multi-backup unit provides real-time, multi-layered redundant storage for critical data in fire protection operations, ensuring that a single storage point failure does not lead to permanent data loss. This includes: critical field identification, extracting fields from structured data output by the signal conversion module based on a predefined list of critical fire protection fields, including but not limited to: fire_alarm status, device_id, GPS coordinates location, sensor_type, and battery_level. Real-time multi-copy writing includes: a memory copy (maintaining a protected circular memory buffer within the container to immediately write the latest values ​​of critical data); a local persistent copy (appending critical data to a dedicated log file in the device's flash file system using an append-only write mode to reduce write wear); and an edge collaborative copy (if the system is configured with edge collaborative nodes, critical data is synchronously sent to edge nodes for temporary storage via the output layer). Storage space management employs a rolling update strategy for local log files; when a file size exceeds a preset threshold, old files are automatically archived and new files are created, retaining only detailed data from the most recent 72 hours.

[0046] The data integrity verification unit performs dual verification at critical nodes in the data lifecycle to ensure that the data is not tampered with or damaged during the parsing and encapsulation process. This includes: Pre-parsing verification (CRC32 fast check): Before processing by the protocol parsing module, a CRC32 checksum is calculated on the raw binary data stream received from the access layer; the calculation result is compared with the checksum embedded in the data packet. If the verification fails, the data packet is immediately discarded, and the access layer requests the device to retransmit. Post-encapsulation verification (SHA-256 strong check): After the data encapsulation module generates the final standardized data packet (JSON format), the SHA-256 hash value of the entire JSON string is calculated. This hash value is used as the integrity_hash field and injected into the root level of the data packet, which is sent to the IoT platform along with the main data. Platform-side verification: After receiving the data packet, the IoT platform recalculates the SHA-256 hash value of the received content and compares it with the integrity_hash field. If they do not match, the data is determined to have been damaged during transmission, a log is recorded, and a retransmission may be requested from the end-side.

[0047] The data self-repair unit attempts to intelligently repair and complete data when it is missing, abnormal, or partially lost due to temporary sensor malfunction, transmission interference, or local hardware damage. This includes: Anomaly detection and triggering: Real-time monitoring of the data stream triggers a self-repair process if key fields are continuously missing for more than three reporting cycles, or if a sensor reading suddenly drops to zero or exceeds the reasonable range of physical measurements. Repair strategy selection and execution: Based on historical pattern time-series prediction, for missing data from its own sensors, the unit obtains the sensor's historical data for the most recent hour and uses a weighted moving average algorithm for interpolation. Neighbor node reference based on spatial correlation: For sensor networks with similar geographical locations (such as multiple smoke detectors on the same floor), if a device's data is completely lost, the unit queries the local network for data from neighboring (preset list) normally functioning sensors of the same type, taking their average or worst value as an estimate. Rule base backup: For missing non-numerical data (such as fire alarm status), inference is made based on preset emergency rules. Repaired data identification: All data supplemented or corrected by the self-repair unit is marked with "data_quality": "repaired" in the final data packet, and the "repair_info" field briefly explains the repair method and basis for platform-side credibility analysis and auditing.

[0048] The above solutions address industry pain points such as equipment vulnerability, data loss, and communication interruption in fire environments, as well as the issue of insufficient data reliability of traditional IoT devices under extreme conditions.

[0049] It should also be noted that in step S3, the present invention further provides an innovative non-standard protocol processing solution, which solves the industry pain point that a large number of proprietary protocols and non-standard protocols are difficult to quickly access in the Internet of Things field.

[0050] Traditional non-standard protocol processing often faces a dilemma: either develop a customized parsing module for each non-standard protocol, resulting in extremely high development and maintenance costs; or use a general protocol conversion gateway, but which is often inefficient and lacks flexibility.

[0051] Specifically, the kernel layer of this invention also includes a non-standard protocol intelligent adaptation module for handling non-standard communication protocols. The non-standard protocol intelligent adaptation module includes: The protocol feature self-learning unit is used to automatically identify and extract the communication protocol of non-standard protocols by analyzing the statistical characteristics, timing patterns and frame structure rules of the input data stream without prior knowledge. A dynamic protocol stack construction unit, connected to the protocol feature self-learning unit, is used to dynamically construct the corresponding protocol parsing stack in memory based on the extracted communication protocol. The balanced routing decision unit is used to assess the current system load and the complexity of non-standard protocol processing, and dynamically decide whether to route non-standard protocol data to a lightweight custom gateway or the built-in protocol parsing module for processing. The decision logic of the balanced routing decision unit includes: When the complexity of a non-standard protocol structure is detected to be lower than a preset threshold and system resources are sufficient, the dynamic protocol stack construction unit will be given priority to complete the parsing within the end-side container.

[0052] When a non-standard protocol structure is detected to be abnormally complex or system resources are scarce, the original data stream is routed to a lightweight custom gateway for processing. The lightweight custom gateway works in conjunction with the core message middleware to complete the protocol conversion and then send back standardized data.

[0053] It should be further explained that the protocol feature self-learning unit is used to automatically identify and extract the communication protocol of non-standard protocols by passively listening to and analyzing the input data stream without prior knowledge. It performs the following steps: During the preset learning period after the device is first connected, it passively listens to and caches the raw binary stream of all input data. Perform statistical analysis on the data stream in the buffer, calculate the aggregation mode of message length and the frequency distribution of byte values, and preliminarily delineate message boundaries based on this; For the initially segmented message sequences, the statistical patterns of their time intervals are analyzed, and a multi-sequence alignment algorithm is used to locate the fixed frame header, frame tail, and delimiter byte sequences in variable-length messages. Based on the identified structural patterns, specification hypotheses regarding frame structure, address field, data field, and checksum are proposed. The hypothesis is then iteratively verified and optimized by finding counterexamples in subsequent data streams, ultimately generating a protocol description file.

[0054] It should be further noted that the dynamic protocol stack construction unit, connected to the protocol feature self-learning unit, is used to dynamically construct the corresponding protocol parsing stack in memory based on the protocol description file, and performs the following steps: Based on the frame structure definition in the protocol description file, automatically generate targeted parsing function code snippets; The generated parsing function code is compiled into executable code and registered and bound in the kernel-level protocol rule library to form a temporary protocol parsing plugin.

[0055] It should be further explained that the balancing routing decision unit is used to assess the current system load and the complexity of processing non-standard protocols, and dynamically decide the processing path for non-standard protocol data. The execution steps of the balancing routing decision unit include: Based on the protocol description file, the structural complexity score of the protocol is calculated. The scoring factors include: the number of protocol fields, the nesting depth, and the variability of field types. Real-time acquisition of CPU load, available memory, and network bandwidth of the current edge device; Dynamic routing decision: If the structural complexity score is lower than the first threshold and the CPU load is lower than the second threshold, the decision is made by the dynamic protocol stack construction unit within the end-side container; if the structural complexity score is higher than the first threshold or the CPU load is higher than the second threshold, the decision is to package the original data stream and route it to an external lightweight custom gateway for processing through the secure transmission module. If the route is routed to an external gateway, the kernel layer receives the parsed, standardized data returned by the gateway and sends it to the data encapsulation module for final encapsulation.

[0056] Furthermore, the lightweight custom gateway works in collaboration with the core message middleware in the form of a microservice. The gateway has a pre-built expert rule base, which contains precise parsing templates for known non-standard protocols. When the gateway receives raw data streams from the end-side container, it first attempts to match them with the expert rule base. If the match fails, it invokes the same protocol feature self-learning logic as the end-side container to perform collaborative learning on the cloud side, and synchronizes the newly learned protocol description files to the expert rule bases of the end-side container and the gateway, thus completing system-level knowledge evolution.

[0057] This setup solves the "cold start" problem for non-standard protocol access: through the self-learning capability of protocol features, the system can gradually understand the specifications and achieve basic parsing even when faced with completely unknown non-standard protocols, realizing intelligent selection of processing paths; by balancing routing decisions, the system finds the optimal balance between performance and resource consumption, providing excellent scalability and maintainability; the microservice-based gateway architecture makes new protocol support simple and fast, greatly reducing the long-term maintenance cost of the system and ensuring the stability and reliability of the core system; by offloading the complex processing of non-standard protocols to a dedicated gateway instance, the stable operation of the core message middleware and the end-side container is ensured.

[0058] In step S4, specifically, the secure transmission module is configured with an encrypted transmission mechanism based on the MQTT protocol, which includes: Connection parameters: Uses a dedicated Broker address and encrypted port for the management platform, the client ID is the device identifier field, the heartbeat interval is 30 seconds, and exponential backoff reconnection is used when the connection is lost; QoS configuration: High priority data uses QoS=2, medium priority data uses QoS=1, and low priority data uses QoS=0; Data encryption: TLS 1.3 encryption is enabled, and the certificate is issued by an authoritative organization to ensure secure data transmission.

[0059] Specifically, the edge cloud collaboration module is configured with both edge local processing and cloud aggregation and management modes, wherein: Edge nodes: Deployed at edge control nodes, they enable local judgment of high-priority data, filtering of regular data, and triggering of emergency alarms, while only reporting high-priority and medium-priority data to the cloud; Cloud: Receives key data uploaded by edge nodes, summarizes the regional IoT status, and issues global control commands to edge nodes.

[0060] It should also be noted that the platform integration module is configured with standardized interfaces and an automated testing suite, including: Standardized interfaces: including HTTPRESTful API and MQTT topics, with both API request bodies and MQTT message bodies being JSON format data output from the kernel layer; Automated testing suite: Simulates abnormal operating conditions in IoT scenarios, with test indicators including data transmission success rate ≥99.5%, high-priority data AoL deviation ≤100ms, and generates device access acceptance reports.

[0061] This invention provides a device management function module built into the standard container on the edge. The device management function module is connected to the kernel layer and the output layer and is used to monitor and manage the lifecycle of the IoT terminal device carrying the container. The device management function module includes: a power monitoring unit, a data SIM card management unit, and a remote configuration unit.

[0062] The power monitoring unit is used to collect device battery power data in real time and generate low power alarm information when the power is lower than a preset threshold, and report it to the IoT platform through the output layer; the data card management unit is used to monitor the data usage and connection status of the IoT SIM card, and trigger alarms when the data is exhausted or the card is abnormal; the remote configuration unit provides a remote command interface for receiving and executing configuration update or firmware upgrade commands from the IoT platform to realize remote hot updates of containers.

[0063] Specifically, the device management module can be a subsequent step, namely step S5. This module operates independently of the data processing pipeline, working in conjunction with the kernel and output layers to provide containers with critical device lifecycle management capabilities. The specific construction of this module includes the following units: S51: Power monitoring unit. This unit periodically reads the battery voltage and remaining power percentage by calling the power management interface provided by the device operating system.

[0064] Monitoring strategy: Set low battery thresholds (e.g., 15%) and critical low battery thresholds (e.g., 5%). When the battery level falls below the low battery threshold, the unit generates a JSON-formatted alarm message containing the device ID, current battery level, and timestamp, and immediately reports it to the platform via the secure transmission module in the output layer. When the battery level falls below the critical low battery threshold, in addition to reporting the alarm, the configuration module in the kernel layer can be activated to automatically adjust the data collection frequency to the lowest mode to maximize the device's standby time.

[0065] S52: Data SIM card management unit, which manages IoT SIM cards by monitoring the network interface of the device and communication with the operator gateway.

[0066] Traffic monitoring: The unit periodically reads network traffic statistics provided by the operating system (such as the / proc / net / dev file in Linux) and calculates the data consumption within a specified time interval. Users can preset the traffic package limit in the container configuration (such as 100MB / month). When the usage reaches 80% of the limit, an alert is triggered, and when it reaches 95%, an over-limit alarm is triggered.

[0067] Connection status monitoring: The unit periodically sends heartbeat packets or Ping commands to the cloud to check whether the SIM card is in arrears, suspended, and whether the network connection is normal. If multiple heartbeats fail consecutively, it is determined that the connection is abnormal, and an alarm of "network disconnected" or "SIM card abnormal" is immediately generated and reported.

[0068] S53: Remote Configuration Unit. This unit is key to bidirectional command interaction between containers and IoT platforms and is the core of remote operation and maintenance.

[0069] Command Interface: This unit exposes a dedicated MQTT topic (such as device / DEV_001 / config / update) or an HTTPS API endpoint at the output layer. The IoT platform publishes JSON commands conforming to a predefined format to this topic or endpoint.

[0070] Command Parsing and Execution: After receiving commands, the remote configuration unit performs security verification and parsing. Supported command types include: Configuration Updates, used to dynamically modify the content of protocol rule bases, data type mapping tables, or data format templates in the kernel layer. For example, the platform can issue commands to add a parsing rule for a private protocol. Firmware Upgrades, where the platform issues commands containing the download address of the new version container image. After verifying the signature, the unit downloads the image file and automatically completes the container's own replacement and restart within the specified maintenance time window, achieving seamless upgrades. Control Commands, used to remotely control device behavior, such as restarting the device or resetting the network module.

[0071] refer to Figure 2The present invention also discloses a method for accessing standard containers on the edge of an IoT device, comprising the following steps: S100: Deploy the container executable to the IoT device file system and start it; S200: The device’s raw data is captured by the access layer, parsed, fault-tolerant and damage-resistant processed, converted and encapsulated by the kernel layer to form a standardized data packet, which is then sent to the IoT platform through the output layer. S300: The IoT platform sends management commands to the output layer, which are then parsed and executed by the configuration module to complete the parameter configuration or operation control of the device.

[0072] Specifically, the first step is to deploy the standard container executable file on the device to the IoT device's file system. The container version must be matched to the device's hardware / system: if the device is an ARM architecture and RTOS system, select the container file compatible with ARM+RTOS and burn it to the specified directory via USB or a remote firmware interface. After the container starts, compatibility checks are performed automatically: the hardware layer checks whether the memory and storage meet the baseline; the system layer adapts to the RTOS through the OSAL layer, and the container process priority can be set to level 3-5.

[0073] For example, it is set to level 4, which is 1-2 levels lower than the priority of the core monitoring task of the device, so as to avoid preempting resources; then the framework layer loads the multi-language interface, and after the verification is passed, the container enters the ready state and sends a "startup successful" notification to the platform.

[0074] Access layer processing: The device outputs raw LoRa protocol data, the protocol compatibility module loads the LoRa plugin, and calls the protocol_parse() interface to parse it; the terminal device authentication module performs two-factor authentication. For the first access, an X.509V3 certificate has been generated. For subsequent accesses, a certificate and a platform temporary verification code must be submitted. After successful authentication, the data enters the preprocessing stage; the raw data preprocessing module uses a 5-point sliding window filter and a circular buffer to finally encapsulate it into "1-byte protocol identifier (0x02 for LoRa) + binary stream"; Kernel layer processing: The protocol parsing module loads the rule base, matches LoRa parsing rules based on packet header features, and converts the binary stream into key-value pairs; the data fault tolerance and resilience module provides multiple fault tolerance guarantees for the parsed key-value pair data: real-time multi-copy backup of key fields such as fire alarm status; dual CRC32 and SHA-256 mechanisms are used to verify data integrity; if data anomalies or missing data are detected, intelligent repair and completion are performed based on historical patterns or neighboring node data; the signal conversion module uses a data type mapping table; the data encapsulation module fills in the deviceId, timestamp, and converted data according to a JSON template to generate standardized data packets; Output layer transmission: The edge cloud collaboration module determines data priority, uploading only high / medium priority data; the secure transmission module uses MQTT encryption, configuring the Broker address and encryption port. Medium priority data is set to QoS=1 and TLS1.3 encryption is enabled, and it is sent to the platform via a standard MQTT topic. In case of transmission failure, the container temporarily stores the data and resends it after the network is restored.

[0075] Finally, the IoT platform issues management commands to the devices via containers. The platform sends JSON commands through HTTP RESTful API or MQTT topics. The output layer platform interface module receives these commands and passes them to the kernel layer configuration module. The configuration module parses the commands through a remote command interface and dynamically updates the locally stored parameter configurations without restarting the container or device. After execution, the configuration module generates an "execution successful" response and sends it back to the platform through the output layer. This method, through container standardization capabilities, enables devices to connect quickly within 1-3 days, with a data transmission success rate of ≥99.5% and a high-priority data AoL deviation of ≤100ms, fully meeting the compatibility, security, and reliability requirements in the initial patent draft.

[0076] In the description of this invention, it should be understood that the above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. A semiconductor medium can be a solid-state drive.

[0077] It should be understood that the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. A and B can be singular or plural. Additionally, the character " / " in this article generally indicates an "or" relationship between the preceding and following related objects, but it can also represent an "and / or" relationship. Please refer to the context for a more accurate understanding.

[0078] In this application, "at least one" means one or more, and "more than one" means two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or multiple items. For example, at least one of a, b, or c can mean: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple.

[0079] It should be understood that in the various embodiments of this application, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0080] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0081] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0082] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0083] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0084] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0085] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0086] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A standard end-side container based on Internet of Things (IoT) devices, characterized in that: The container includes an access layer for receiving and preprocessing raw data from IoT terminal devices and outputting standardized data. The kernel layer, connected to the access layer, is used to parse, transform, and encapsulate the standardized data to form a standard data packet that the platform can recognize; The output layer, connected to the kernel layer, is used to securely transmit the standard data packets to the IoT management platform. The kernel layer includes a protocol parsing module for loading the protocol rule base and performing structured parsing on the standardized raw data received from the access layer; a data fault tolerance and resilience module for implementing multiple fault tolerance mechanisms during data transmission; a signal conversion module for converting the parsed data into a unified data type according to a preset data type mapping table; a data encapsulation module for encapsulating standardized data into data packets of a specific format according to a data format template; and a configuration module for storing and managing the protocol rule base, data type mapping table, and data format template. The data fault tolerance and resilience module includes: a critical data multiple backup unit, which stores key fields such as fire alarm status, equipment location, and sensor readings in real time with multiple copies; a data integrity verification unit, which uses CRC32 and SHA-256 dual verification mechanisms to verify the integrity of data before and after parsing; and a data self-repair unit, which performs intelligent repair and supplementation based on historical data patterns and data from adjacent nodes when partial data corruption is detected.

2. The standard container for the end-side based on an IoT device according to claim 1, characterized in that, The container has a built-in device management module, which is connected to the kernel layer and the output layer and is used to monitor and manage the lifecycle of the IoT terminal device that carries the container. The device management function module includes: a power monitoring unit, a data SIM card management unit, and a remote configuration unit; The power monitoring unit is used to collect device battery power data in real time and generate low power alarm information when the power is lower than a preset threshold, and report it to the IoT platform through the output layer; the data card management unit is used to monitor the data usage and connection status of the IoT SIM card, and trigger an alarm when the data is exhausted or the card is abnormal; the remote configuration unit provides a remote command interface for receiving and executing configuration update or firmware upgrade commands from the IoT platform to realize remote hot update of the container.

3. The standard container for the end-side based on an IoT device according to claim 1, characterized in that, The access layer is constructed including: a development protocol compatibility module, a terminal device authentication module, and a raw data preprocessing module. The access layer receives raw data output by IoT terminal devices, and after protocol parsing, authentication, and data preprocessing, outputs standardized raw data in protocol identifier and binary stream format. The output layer is constructed by developing a secure transmission module, an edge cloud collaboration module, and a platform docking module. The output layer receives standardized data output from the kernel layer, and after encrypted transmission, edge local processing, and standard interface adaptation, completes the access of IoT terminal devices and management platforms.

4. The standard container for the end-side based on an IoT device according to claim 3, characterized in that, The protocol parsing module is used to load the protocol rule base and perform structured parsing on the standardized raw data received from the access layer. The protocol rule base defines the frame structure and parsing algorithm of various communication protocols. The protocol parsing module automatically selects the corresponding rule by analyzing the header features of the data packet, and deconstructs the binary stream into structured data in the form of key-value pairs. The signal conversion module is connected to the protocol parsing module and is used to convert the structured data into a unified data type according to a preset data type mapping table; The data encapsulation module is connected to the signal conversion module and is used to encapsulate the converted standardized data into a data packet of a specific format according to a predefined data format template. The data format template is formally described using JSON Schema, and the encapsulation process includes injecting a unique device identifier and a data acquisition timestamp to generate a complete data object that the platform can recognize. The secure transmission module is configured with an encrypted transmission mechanism based on the MQTT protocol. The edge cloud collaboration module is configured with edge local processing and cloud aggregation and control modes. Edge local processing realizes local judgment of high-priority data, filtering of regular data and triggering of emergency alarms, and only reports high-priority and medium-priority data to the cloud. The cloud aggregation and control mode receives key data uploaded by edge nodes, summarizes the regional IoT status, and issues global control commands to edge nodes. The platform integration module is configured with standardized interfaces and an automated testing suite, wherein: Standardized interfaces: including HTTPRESTful API and MQTT topics, with both API request bodies and MQTT message bodies being JSON format data output from the kernel layer; Automated testing suite: Simulates abnormal operating conditions in IoT scenarios, with test indicators including data transmission success rate ≥99.5%, high-priority data AoL deviation ≤100ms, and generates device access acceptance reports.

5. The standard container for the end side based on an IoT device according to claim 1, characterized in that, The kernel layer also includes a configuration module, which maintains lightweight storage inside the container to persistently manage the protocol rule base, data type mapping table, and data format template. The configuration module also includes a remote command interface, which exposes a dedicated configuration topic through the output layer to receive, parse, and execute JSON update commands conforming to a predetermined format from the IoT management platform, thereby enabling dynamic hot updates of the protocol rule base, data type mapping table, or data format template.

6. The standard container for the end-side based on an IoT device according to claim 5, characterized in that, The kernel layer also includes a non-standard protocol intelligent adaptation module for handling non-standard communication protocols. This non-standard protocol intelligent adaptation module includes: The protocol feature self-learning unit is used to automatically identify and extract the communication protocol of non-standard protocols by analyzing the statistical characteristics, timing patterns and frame structure rules of the input data stream without prior knowledge. A dynamic protocol stack construction unit, connected to the protocol feature self-learning unit, is used to dynamically construct the corresponding protocol parsing stack in memory based on the extracted communication protocol. The balanced routing decision unit is used to assess the current system load and the complexity of non-standard protocol processing, and dynamically decide whether to route non-standard protocol data to a lightweight custom gateway or the built-in protocol parsing module for processing. The decision logic of the balanced routing decision unit includes: When the complexity of a non-standard protocol structure is detected to be lower than a preset threshold and system resources are sufficient, the dynamic protocol stack construction unit shall preferentially complete the parsing within the end-side container. When a non-standard protocol structure is detected to be abnormally complex or system resources are scarce, the original data stream is routed to a lightweight custom gateway for processing. The lightweight custom gateway works in conjunction with the core message middleware to complete the protocol conversion and then send back standardized data.

7. The standard container for the end-side based on an IoT device according to claim 1, characterized in that, The container's hardware compatibility baseline is configured to support mainstream embedded architectures, including ARM, x86, and MIPS architectures. The system compatibility baseline of the container is achieved through the operating system adaptation layer. The OSAL layer is configured to be compatible with Linux, RTOS and Android systems. In the RTOS environment, the container process priority is configured to be 3-5 levels, which is 1-2 levels lower than the priority of the core monitoring task of the IoT terminal device.

8. The standard container for the end-side based on an IoT device according to claim 3, characterized in that, The protocol compatibility module is configured to support common communication protocols in IoT scenarios, including RS485, LoRa and NB-IoT protocols, and adopts a plug-in design. Each protocol plug-in is ≤500KB in size and provides a unified data parsing interface and data encapsulation interface. The terminal device authentication module is implemented as a two-factor authentication mechanism, specifically including: Initial connection: Collect the hardware fingerprint and device-specific identifier of the IoT terminal device; Subsequent access: IoT terminal devices submit the device identity certificate and the temporary verification code issued by the management platform. Only after successful authentication can a data connection be established. The raw data preprocessing module is implemented as a three-level process: noise reduction, caching, and format unification.

9. The standard container for the end-side of an IoT device according to claim 5, characterized in that, The configuration module includes a remote command interface for receiving update commands from the IoT platform through the output layer and dynamically updating the stored protocol rule base, data type mapping table, or data format template based on the commands. The protocol parsing module loads multiple protocol rules in parallel and automatically selects the corresponding rule for parsing by analyzing the header features of the data packets.

10. A method for accessing a standard container on the edge of an IoT device, used to execute the standard container on the edge of an IoT device as described in claim 1, characterized in that, Includes the following steps: Deploy the aforementioned standard container executable file to the IoT device file system and start running it; The device's raw data is captured by the access layer, parsed, fault-tolerant and damage-resistant processed, converted and encapsulated by the kernel layer to form a standardized data packet, which is then sent to the IoT platform through the output layer. The IoT platform sends management commands to the output layer, which are then parsed and executed by the configuration module to complete the parameter configuration or operation control of the device.

Images