A method and platform for uniform access of internet of things multi-protocol devices

Abstract

The application provides a method and platform for unified access of Internet of Things multi-protocol devices, which comprises the following steps: constructing device communication characteristic information; calling a protocol analysis template matched with a current communication interface to generate a device protocol adaptation rule; extracting each device data field from a message in sequence according to the device protocol adaptation rule and restoring the device data field to a device field value; generating a field source record, a data reading path and a device operation path according to the device field value; combining the field source record, the data reading path and the device operation path into unified access description information; establishing a device access instance based on the unified access description information; and processing a device reading request and a control request initiated by an Internet of Things middle station according to the data reading path and the device operation path. The application effectively reduces the workload of repeated configuration and manual debugging in the process of multi-protocol device access.

Description

Technical Field

[0001] This invention belongs to the field of IoT multi-protocol processing, and particularly relates to a unified access method for IoT multi-protocol devices. Background Technology

[0002] With the development of industrial automation, intelligent manufacturing, and digital equipment management, the number of devices connected to industrial sites is constantly increasing, and the types of devices, communication interfaces, and communication protocols are highly heterogeneous. Existing industrial IoT platforms typically connect to field devices through edge gateways and configure drivers corresponding to communication protocols such as Modbus, Profinet, EtherCAT, OPCUA, Zigbee, and LoRa to parse device messages, convert data, and upload it to the platform. This type of access method is generally based on standard protocol templates or communication documents provided by equipment manufacturers. Engineers configure message boundaries, field positions, field lengths, data arrangement order, request-response relationships, data addresses, and field business meanings before loading the configuration into the gateway. This approach can meet basic access requirements when the device protocol structure is fixed, communication data is complete, and the number of devices is small. However, in actual industrial settings, the same standard protocol often has specific implementation differences between different manufacturers, models, or firmware versions. Devices may add extended fields, reserved fields, or custom data areas to the standard message structure, causing subsequent fields to be partially offset. The message length of some devices may also vary with the number of data items. Request and response messages may also establish a correspondence through device identifiers, operation identifiers, or transaction content. Relying solely on fixed field positions or message front features to select the protocol template can easily lead to field misalignment, incorrect length interpretation, mismatched request and response, and incomplete data area extraction. Even if the gateway can complete the underlying message parsing, the field identifiers, data types, access attributes, and read / write methods used by different protocol templates still differ. The upper-layer platform usually needs to configure data point mapping, read interfaces, and control interfaces separately for different devices, resulting in the separation of protocol parsing configuration and platform access configuration. The same device field lacks a continuous correspondence between the underlying message position, platform standard code, and business call interface. When a large number of devices from different protocols and manufacturers are connected to an industrial site at the same time, engineers need to repeatedly compare protocols, locate fields, convert data types, and configure interfaces. The connection cycle is long, and inconsistencies in local configurations can easily cause abnormal data uploads or control commands to fall into the wrong fields.

[0003] Therefore, existing technologies urgently need to address the challenges in multi-protocol device access scenarios in the Industrial Internet of Things (IIoT). Fixed protocol templates are insufficient to cover the differences in extended structures, variable-length data areas, and corresponding request and response patterns of device manufacturers. Furthermore, the underlying protocol parsing results are difficult to directly form a unified platform call interface. This leads to the need for repeated protocol comparisons, field positioning, and interface configurations for devices from different manufacturers, models, and firmware versions. As a result, device access cycles are long, debugging workload is heavy, and engineering problems such as field misalignment, request and response mismatch, and disconnection between platform interfaces and underlying protocol fields are prone to occur. Summary of the Invention

[0004] The purpose of this invention is to propose a unified access method and platform for multi-protocol IoT devices to solve the above-mentioned problems.

[0005] To achieve the above objectives, a unified access method for multi-protocol IoT devices is provided in a first aspect of the present invention, the method comprising the following steps: S1. Obtain the original communication content generated by the device to be accessed during the actual communication process, and construct the device communication feature information; the device communication feature information includes the communication segment organization method, message length relationship, fixed structure area, variable area, variable length area, length candidate association, interactive correspondence relationship, and the source message, message position, transmission direction and communication segment corresponding to each relationship; S2. Based on the device communication characteristic information, call the protocol parsing template that matches the current communication interface to generate device protocol adaptation rules; S3. According to the device protocol adaptation rules, extract each device data field from the message sequentially and restore it to the device field value; generate a field source record based on the device field value, and generate a data reading path and a device operation path according to the access attribute and template field correspondence in the device protocol adaptation rules; combine the field source record, data reading path and device operation path into unified access description information. S4. Based on the unified access description information, establish a device access instance, convert the communication messages of different protocol devices into standardized device messages containing device identifiers and standard codes and send them to the IoT middleware, and process the device read requests and control requests initiated by the IoT middleware according to the data read path and device operation path.

[0006] Furthermore, in step S1, the method for constructing the device communication feature information is as follows: A message set is established based on the connection port, connection session, and device endpoint, and the device communication messages are organized into communication segments according to the transmission direction and reception order; The messages are grouped according to the number of data locations. Fixed structure areas and variable areas are determined by comparing the consistency of the content at the same location. Common front structure, common back structure and variable length areas are determined by aligning from the beginning and end of the message respectively. After repeatedly verifying the fixed structure region, variable region, variable length region, length candidate association, and interaction correspondence, device communication feature information is generated.

[0007] Furthermore, the method for generating the device protocol adaptation rules is as follows: The fixed structural region is established as the message anchor point based on its sequential position in the source message, and the content between adjacent anchor points is divided into independent structural segments. Each fixed structure region is mapped to the frame start field, device addressing field, operation field, data area boundary, or integrity verification region in the protocol parsing template. When the actual message from the device adds extended content based on the standard template, the operation field and the subsequent fixed structure are used as two anchor points to record the segment where the new content is located as the extended segment, and the length field and data area are shifted sequentially to form a field position configuration suitable for the current device.

[0008] Furthermore, the method for determining the protocol parsing template is as follows: The filtered protocol parsing template is applied to all source messages associated with the device communication feature information, and the message boundaries, fixed field positions, length field interpretations, data area ranges, request-response associations, and integrity verification relationships are verified sequentially. When multiple templates can complete the parsing of all source messages, select the template that can interpret the most fixed structure regions, variable regions, variable length regions, length candidate associations, and interactive correspondences; when the number of interpretations is the same, select the template that can determine more request-response associations.

[0009] Furthermore, the step of sequentially extracting each device data field from the message and restoring it to its device field value specifically involves: Based on the field definitions in the device protocol adaptation rules, restore the data location of the field to the device field value; When a field is defined as an unsigned integer, the data positions are combined sequentially according to the data arrangement order. When a field is defined as a signed integer, the sign and value are determined according to the field's range and the two's complement rule. When a field is defined as a floating-point number, it is restored according to the floating-point encoding method, data position order, and word order of the record defined by the field. When a field is defined as a bit field, the target content is extracted according to the starting position and the number of bits occupied in the record defined by the field. When a field is defined as an encoded value, it is converted bit by bit according to the encoding method of the field definition record; when the field definition includes a proportional conversion relationship, the device field value is obtained according to the proportional coefficient and offset of the record after the encoding is restored.

[0010] Furthermore, the data reading path is generated in the following way: For unified access projects with read attributes, a data read path is generated based on the field source record. The data read path records the device binding relationship, request message type, request response associated fields, return message type, data area boundary, field relative position, and data arrangement order. For proactive reporting devices, the data read path records the reporting message type, field relative position, data arrangement order, and corresponding update item. The method for generating the device operation path is as follows: For unified access projects with write or control attributes, a device operation path is generated. The device operation path records the operation message type, target field position, data arrangement order, extended segment position, length field update method, fixed field content, integrity verification method, and associated fields and result fields in the expected return message. After the target content is converted into the encoding form of the target device field value according to the field definition, it is written to the target field according to the device operation path.

[0011] Furthermore, the device read request is processed as follows: Locate the device access instance based on the device identifier, and read the corresponding data reading path according to the standard code; For request-response type devices, the communication interface, request message type and request-response associated fields are determined according to the data reading path. The device protocol adaptation rules are called to generate a reading message and send it to the device. After receiving the return message, the corresponding relationship is confirmed according to the request-response associated fields, and then the device field value is extracted according to the field source record. For devices that actively report, the latest valid field record corresponding to the standard code is read from the gateway cache and returned.

[0012] Furthermore, the processing method for the device control request is as follows: Read the corresponding device operation path based on the device identifier and standard code, and obtain the fixed fields, extended sections, length fields and integrity verification configuration through the device protocol adaptation rules; The target content is converted into the encoded form of the target device field value according to the field definition, and then written into the target field according to the device operation path; Generate a length field based on the written data area, combine the fixed field and extended segment content to generate integrity verification content, and form a device protocol message; After the device returns a result message, the corresponding operation is determined based on the request response associated fields, and the execution result is obtained from the result fields.

[0013] In a second aspect of the present invention, a unified access platform for multi-protocol IoT devices is provided, the platform comprising: An edge high-aggregation gateway is used to acquire the original communication content generated by the device to be accessed during actual communication and construct device communication feature information. This device communication feature information includes communication segment organization methods, message length relationships, fixed structure areas, variable areas, variable length areas, length candidate associations, interaction correspondences, and the source message, message location, transmission direction, and communication segment corresponding to each relationship. Based on the device communication feature information, a protocol parsing template matching the current communication interface is invoked to generate device protocol adaptation rules. According to the device protocol adaptation rules, each device data field is sequentially extracted from the message and restored to its device field value. A field source record is generated based on the device field value, and a data reading path and device operation path are generated according to the access attributes and template field correspondences in the device protocol adaptation rules. The field source record, data reading path, and device operation path are combined into unified access description information. A device access instance is established based on the unified access description information, and communication messages from different protocol devices are converted into standardized device messages containing device identifiers and standard codes and sent to the IoT middleware platform. Device read requests and control requests initiated by the IoT middleware platform are processed according to the data reading path and device operation path. The IoT middleware platform is used to initiate device read and control requests.

[0014] The present invention also provides a storage medium storing an Internet of Things (IoT) multi-protocol device unified access program, wherein when the IoT multi-protocol device unified access program is executed by a processor, it implements the steps of the IoT multi-protocol device unified access method as described in any of the preceding claims.

[0015] The beneficial technical effects of the present invention are at least as follows: This invention addresses the challenges of fixed protocol templates failing to cover device manufacturer extension structures, variable-length data regions, and differences in request-response correspondences, as well as the difficulty in directly generating unified platform API calls from underlying protocol parsing results. It proposes a unified access method and platform for multi-protocol IoT devices. The scheme involves an edge high-aggregation gateway acquiring the actual communication messages of the devices to be accessed. Based on message source, communication direction, reception order, fixed structure, variable structure, length variation, and interaction correspondences, device communication characteristic information is generated. This information is then associated with existing protocol parsing templates on the platform. Stable structural positions determine message anchor points; structural differences between adjacent anchor points determine manufacturer extension segments; variable-length regions and length correspondences determine data region boundaries; and interaction correspondences determine the association fields between request and response messages. This generates device protocol adaptation rules that match the actual message structure of the specific device. Based on these rules, the source location, encoding method, and access method of each device's data fields are further determined. The attributes map the field identifiers in different protocol templates to the standard codes in the unified access specification, forming data reading paths and device operation paths corresponding to each standard code. This ensures that the unified access description information includes both the data expression method on the platform side and the protocol execution method on the device side. Based on this, the IoT platform establishes a unified access instance for the device, and completes the unified processing of device registration, data upload, status update, read requests, and control requests through the API gateway and stream processing engine. This connects the actual communication structure of the device, protocol parsing configuration, and platform call interface into a continuous access link, improving the industrial IoT platform's compatibility with devices using different protocols, manufacturers, and message types, and reducing the workload of repetitive configuration and manual debugging during the access of multi-protocol devices. Attached Figure Description

[0016] The present invention will be further described with reference to the accompanying drawings, but the embodiments in the drawings do not constitute any limitation on the present invention. For those skilled in the art, other drawings can be obtained based on the following drawings without creative effort.

[0017] Figure 1 This is a flowchart of a unified access method for multi-protocol IoT devices according to the present invention. Detailed Implementation

[0018] Embodiments of the present invention are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0019] like Figure 1As shown in the figure, an embodiment of the present invention provides a unified access method for IoT multi-protocol devices, the method comprising: S1. Obtain the original communication content generated by the device to be accessed during the actual communication process, and construct the device communication feature information; the device communication feature information includes the communication segment organization method, message length relationship, fixed structure area, variable area, variable length area, length candidate association, interaction correspondence relationship, and the source message, message position, transmission direction and communication segment corresponding to each relationship.

[0020] Specifically, the edge high-convergence gateway obtains the original communication content generated by the device to be connected during actual communication through a serial communication interface, industrial Ethernet interface, fieldbus interface, or wireless communication module interface connected to the device. The original communication content is read from the receive buffer by the corresponding interface driver and stored before protocol parsing and field conversion, while recording the connection port, connection session, device endpoint, transmission direction, receiving order, and message boundaries.

[0021] Among them, the connection port is used to determine the physical interface or communication module through which the original communication content enters the edge high-convergence gateway; the connection session is used to distinguish different communication connections on the industrial Ethernet interface; the device endpoint is used to distinguish different devices in the same communication link; the transmission direction is used to distinguish the communication content sent by the edge high-convergence gateway to the device and the communication content returned by the device to the edge high-convergence gateway; and the receiving order is used to restore the sequential relationship between multiple communication contents.

[0022] Understandably, when the interface driver can directly submit a complete data frame, the data frame submitted by the interface driver is determined as a device communication message; when the interface driver submits a continuous data stream, the message boundary is determined first based on the receive end flag provided by the interface driver, the data length information provided by the connection layer, or the data frame end flag provided by the communication module.

[0023] For continuous data streams without directly provided message boundaries, the edge high-aggregation gateway writes continuously arriving communication content into the same receive buffer. After a stable interruption occurs during continuous reception, the communication content before the interruption is identified as a candidate message. The stable interruption is determined by the frame interval configured by the interface driver, the minimum silent time of the connection layer, the frame end parameters of the communication module, or the upper limit of the arrival interval of adjacent bytes or adjacent data blocks obtained during access configuration. Subsequently, by checking whether the same front structure, back structure, or length relationship repeatedly appears in multiple subsequent candidate messages, it is confirmed whether the boundaries of the candidate messages can be used for subsequent structural analysis. Taking a shared serial communication link as an example, each device to be accessed can be enabled sequentially during device access configuration, so that the device communication messages obtained in the same acquisition period correspond to the same device, thereby establishing a definite relationship between the connection port, the acquisition period, and the device to be accessed.

[0024] The edge high-convergence gateway establishes message sets based on connection ports, connection sessions, and device endpoints, with each message set corresponding to a device to be connected. For industrial Ethernet devices, message sets are divided according to connection ports and connection sessions; for wireless communication devices, message sets are divided according to the device endpoints submitted by the communication module; for fieldbus devices, message sets are divided according to the station identifiers provided by the interface driver or bus controller. After completing the message source division, the device communication messages are first organized into an initial sequence of communication segments according to the transmission direction and receiving order. For the communication mode where the edge high-convergence gateway sends communication messages first and the device to be connected subsequently returns communication messages, messages with opposite directions, adjacent receiving orders, and belonging to the same continuous interaction process are recorded as candidate bidirectional communication segments; when the edge high-convergence gateway sends multiple messages consecutively, the sequential relationship between each sent message and its subsequent candidate return message is retained, and the final request-response pairing is not directly determined in S1. For the communication mode where the device to be connected actively reports data, multiple messages with the same device endpoint, the same transmission direction, and consecutive occurrences are grouped into a unidirectional communication segment. Taking the reading process of an industrial controller as an example, after the edge high-aggregation gateway sends a reading message, it receives a response message returned by the controller. The two constitute a candidate bidirectional communication segment. Taking the periodic reporting process of a wireless sensor as an example, multiple reporting messages continuously sent by the same sensor constitute a unidirectional communication segment.

[0025] The edge high-aggregation gateway groups messages from the same device according to the number of data locations contained in the device communication messages, and retains the correspondence between each message group and its corresponding communication segment. For messages with the same number of data locations, the content at the same location is compared sequentially starting from the message start position. If the position and content of a continuous region remain consistent in multiple messages, the continuous region is recorded as a candidate fixed structure region; if the position of a continuous region remains consistent but some of its content changes, the continuous region is recorded as a candidate variable region. For messages with different numbers of data locations, alignment is performed from the message start and message end. First, a common front structure that appears continuously in different messages is determined, then a common back structure that appears continuously from the message end forward is determined. The region between the common front structure and the common back structure, where the number of data locations varies with the message, is recorded as a candidate variable length region. For example, the same device forms a shorter message when returning one data item and a longer message when returning multiple data items. Both types of messages have the same front and back structure, with only the middle part extending as the number of data items increases. Based on this, the edge high-aggregation gateway records the middle part as a candidate variable length region and simultaneously associates and saves the shorter and longer messages that form this judgment.

[0026] Based on the initial sequence of the aforementioned communication segments, the edge high-aggregation gateway further retains candidate pairing relationships in request-response communication according to the transmission direction, receiving order, connection session, and device endpoint. For request-response communication, the edge high-aggregation gateway establishes candidate bidirectional communication segments for each sent message and includes return messages arriving after the sent message and originating from the same connection session and device endpoint within the candidate pairing range. When multiple sent messages that have not yet been paired exist consecutively in the same connection session, the sequential relationship, fixed content correspondence, and variable content correspondence between each sent message and the candidate return message are retained to form candidate pairing relationships. Step two determines the return message corresponding to each sent message from the candidate pairing relationships based on the interaction correspondence and the request-response association fields specified in the protocol parsing template. For communication methods where devices actively report data, multiple messages from the same device endpoint, with the same transmission direction, and appearing consecutively are grouped into a unidirectional communication segment. Taking the reading process of an industrial controller as an example, the edge high-aggregation gateway organizes the reading message and its candidate response message into candidate bidirectional communication segments, and then the corresponding relationship is determined by step two based on the transaction content or operation content; taking the periodic reporting process of a wireless sensor as an example, multiple reporting messages continuously sent by the same sensor constitute a unidirectional communication segment.

[0027] The edge high-aggregation gateway repeatedly confirms the candidate fixed structure region, candidate variable region, candidate variable length region, length candidate association, and interaction correspondence.

[0028] Specifically, a candidate fixed structure region is defined as a region that maintains the same position and content in multiple messages within the same message group. A candidate variable region is defined as a region that maintains the same boundary in multiple messages, or whose boundaries are all limited by the same fixed structure region and the same length field interpretation result, and whose internal content changes. A candidate variable length region is defined as a region that simultaneously has a common front structure and a common back structure in different message groups. Length candidate associations are retained when they occur repeatedly under multiple message length conditions. Interactive correspondences are retained when they occur repeatedly in multiple bidirectional communication segments. Each confirmed structural relationship is associated with the source message that forms the structural relationship, and the corresponding message position, message group, communication segment, and transmission direction are recorded. The final generated device communication feature information includes communication segment organization method, message length relationship, fixed structure region, variable region, variable length region, length candidate association, interactive correspondence, and the source message, message position, transmission direction, and communication segment corresponding to each structural relationship.

[0029] S2. Based on the device communication characteristic information, call the protocol parsing template that matches the current communication interface to generate device protocol adaptation rules.

[0030] Specifically, the edge high-aggregation gateway reads the device communication characteristic information output in step one and, according to the communication segment organization method, message length relationship, fixed structure area, variable area, variable length area, length candidate association, interaction correspondence, and the corresponding source message, message location, transmission direction, and belonging communication segment, calls the protocol parsing template that matches the current communication interface. The protocol parsing template is formed by the industrial protocol drivers already supported by the platform, protocol standard documents, device manufacturer communication documents, and on-site debugging configurations. The template records the communication organization method, message boundaries, fixed fields, length fields, data areas, request-response correspondence, data arrangement order, and integrity verification method. The communication segment organization method and transmission direction are used to filter request-response type templates or proactive reporting type templates, and the message length relationship is used to filter fixed length templates or variable length templates, ensuring that the template selection is consistent with the actual communication form of the device.

[0031] The edge high-aggregation gateway establishes message anchors based on the sequential position of fixed structural regions within the source message, and divides the content between adjacent anchors into independent structural segments. Each fixed structural region corresponds to the frame start field, device addressing field, operation field, data area boundary, or integrity verification area in the protocol parsing template. For devices with vendor-extended fields under the same protocol, the extended segment is determined based on the actual interval between adjacent anchors, and the actual positions of the length field, data field, and subsequent fields within that segment are adjusted accordingly. For example, if the operation field in the basic template is immediately followed by the length field, and the actual device message adds fixed extended content between the two, the operation field and the subsequent fixed structure are used as two anchors. The segment containing the newly added content is recorded as the extended segment, and the length field and data area are sequentially shifted to the next position within that segment, thus forming a field position configuration and extended segment position suitable for the current device.

[0032] Furthermore, the edge high-aggregation gateway utilizes variable regions and variable-length regions to determine the device data area.

[0033] For fixed-length messages, the data area specified in the template is mapped to the variable area, and the start and end positions of the data area are determined using adjacent fixed structure areas. For variable-length messages, the end position of the common front structure is determined as the start point of the data area, and the start position of the common back structure is determined as the termination condition of the data area. Length candidate association is used to confirm the length field and its interpretation method. Specifically, the length content of each source message is read from the candidate position, restored according to the data arrangement order specified in the template, and the end point of the data area is located based on the restoration result. When multiple source messages of different lengths can accurately connect to the common back structure according to the same field position and the same interpretation method, that position is determined as the length field, and the corresponding length field interpretation method is written into the device protocol adaptation rules.

[0034] For bidirectional communication segments, the edge high-aggregation gateway uses interactive mapping relationships to determine the associated fields between sent and returned messages. Based on the sending position, returning position, and paired source messages recorded in the interactive mapping relationship, it verifies the correspondence between device identifiers, operation identifiers, or transaction content in the sent and returned messages group by group. When the field content in multiple groups of communication segments remains consistent, the sending-side position, returning-side position, and field reading order are written into the request-response association configuration. This configuration is used to accurately map returned messages to the corresponding sent messages when the device continuously processes multiple requests, ensuring that subsequent data parsing uses the correct communication segment.

[0035] Furthermore, the edge high-aggregation gateway applies the filtered protocol parsing template to all source messages associated with the device communication feature information, sequentially verifying message boundaries, fixed field positions, length field interpretations, data area ranges, request-response associations, and integrity verification relationships.

[0036] For candidate bidirectional communication segments, the corresponding content in the sent message and candidate return message is read according to the request-response association fields specified in the template. Messages with consistent association content are identified as the same bidirectional communication segment. The template is discontinued if any source message exhibits overlapping fields, length interpretations exceeding message boundaries, data areas crossing common back-end structures, or request-response associations that are not valid. For multiple templates capable of parsing all source messages, the template that can interpret the most fixed-structure regions, variable regions, variable-length regions, length candidate associations, and interaction correspondences is selected first. If the number of interpretations is the same, the template that can determine more request-response associations is selected. If they are still the same, the template with fewer extended segments is selected, thus determining the protocol parsing template corresponding to the current device.

[0037] The edge high-convergence gateway generates device protocol adaptation rules based on the determined protocol parsing template, extended segment location, length field interpretation method, and request-response association location, and binds these rules to the current device's connection port, connection session, or device endpoint. The device protocol adaptation rules include the protocol parsing template identifier, message boundary determination method, communication segment organization method, fixed field location, extended segment location, length field location and interpretation method, request-response association field location, data area start and end conditions, data arrangement order, and integrity verification method. The device protocol adaptation rules also include field definitions in the protocol parsing template and template field correspondences. The field definitions record field identifiers, data types, encoding methods, field occupancy ranges, data arrangement orders, access attributes, and proportional conversion relationships. The template field correspondences record the correspondence between vendor field identifiers and platform standard field identifiers.

[0038] S3. According to the device protocol adaptation rules, extract each device data field from the message in sequence and restore it to the device field value; generate a field source record according to the device field value, and generate a data reading path and a device operation path according to the access attribute and template field correspondence in the device protocol adaptation rules; combine the field source record, data reading path and device operation path into unified access description information.

[0039] Specifically, the edge high-aggregation gateway reads the device protocol adaptation rules output in step two and establishes a message parsing instance for the current device based on the connection port, connection session, or device endpoint bound to the rules. The parsing instance obtains the complete message from the interface receive buffer according to the message boundary determination method, determines whether the message belongs to a sent message, return message, or active reporting message according to the communication segment organization method, identifies the message type according to the fixed field position, determines the actual position of each field after the manufacturer's extended content according to the extended segment position, determines the end position of the variable-length data area according to the length field position and interpretation method, assigns the return message to the corresponding request process according to the request-response association field, and confirms the message content according to the integrity verification method. After completing the above processing, the parsing instance sequentially obtains the device data fields from the message according to the data area start position, end condition, and data arrangement order, ensuring that the message boundaries, communication organization, fixed fields, extended segments, length fields, request-response association, data areas, arrangement order, and integrity verification configuration in the device protocol adaptation rules all participate in the extraction of device data fields.

[0040] The edge high-convergence gateway generates a field source record for each device's data field. This record includes the current device's connection binding relationship, protocol parsing template identifier, corresponding message type, request type, return message association method, the field's relative position in the data area, the field's occupied range, and the data arrangement order. In fixed-length messages, the field position is directly determined by the device protocol adaptation rules; in variable-length messages, the field position is determined based on the starting position of the data area, combined with the interpretation result of the length field; when extended segments exist, the extended actual position recorded in the device protocol adaptation rules is used.

[0041] Furthermore, the edge high-aggregation gateway restores the data location of the field to the device field value according to the field definitions in the device protocol adaptation rules. When the field is defined as an unsigned integer, the data positions are combined sequentially according to the data arrangement order; when the field is defined as a signed integer, the sign and value are determined according to the field's occupancy range and two's complement rules; when the field is defined as a floating-point number, it is restored according to the floating-point encoding method, data position order, and word order recorded in the field definition; when the field is defined as a bit field, the target content is extracted according to the starting bit and occupied number of bits recorded in the field definition; when the field is defined as an encoded value, it is converted bit by bit according to the encoding method recorded in the field definition. When the field definition contains a proportional conversion relationship, after completing the encoding restoration, the device field value is obtained according to the proportional coefficient and offset recorded in the field definition. Subsequent unified access description information and standardized device messages all use "device field value" to represent the above processing results.

[0042] Furthermore, the edge high-aggregation gateway reads the field identifier, data type, and access attribute from the field definition, and converts the vendor field identifier into the standard code in the unified access specification based on the template field correspondence in the device protocol adaptation rules. The unified access specification records the standard code, data name, data type, access method, update conditions, and transmission format. For unified access projects with read attributes, a data read path is generated based on the field source record. This data read path records the device binding relationship, request message type, request-response associated fields, return message type, data area boundary, field relative position, and data arrangement order. For proactive reporting devices, the data read path records the reporting message type, field relative position, data arrangement order, and corresponding update item. For unified access projects with write or control attributes, a device operation path is generated. This device operation path records the operation message type, target field position, data arrangement order, extended segment position, length field update method, fixed field content, integrity verification method, and associated and result fields in the expected return message.

[0043] Finally, the edge high-convergence gateway merges the field source records, data read paths, and device operation paths corresponding to the same standard code into a unified access description item. The unified access description item includes device binding relationships, device protocol adaptation rule reference identifiers, standard codes, data names, data types, access methods, update conditions, transmission formats, and underlying protocol execution paths. All unified access description items corresponding to the current device together constitute the unified access description information.

[0044] S4. Based on the unified access description information, establish a device access instance, convert the communication messages of different protocol devices into standardized device messages containing device identifiers and standard codes and send them to the IoT middleware, and process the device read requests and control requests initiated by the IoT middleware according to the data read path and device operation path.

[0045] Specifically, the edge high-aggregation gateway reads the unified access description information generated in step three and establishes a device access instance corresponding to the connection port, connection session, or device endpoint based on the device binding relationship. During the initial device registration, the edge high-aggregation gateway submits the device binding relationship, gateway identifier, and unified access project list to the IoT platform via the API gateway. The IoT platform assigns a device identifier to the device and returns it to the edge high-aggregation gateway. The edge high-aggregation gateway saves the mapping between the device identifier and the device binding relationship, and the device identifier is used again when the device reconnects subsequently. The device access instance loads the device protocol adaptation rule reference identifier, standard code, data name, data type, access method, update condition, transmission format, field source record, data read path, and device operation path from the unified access description information, enabling the IoT platform to call the attributes, status, and operations of devices with different protocols through the device identifier and standard code.

[0046] When a device actively sends a communication message, the edge high-aggregation gateway determines the device to which the message belongs based on the device binding relationship. It then invokes the corresponding device protocol adaptation rule using the device protocol adaptation rule reference identifier to complete message boundary confirmation, message type identification, data area location, and device field value extraction. Based on the field source record, the edge high-aggregation gateway writes the device field value into the corresponding unified access project and saves the standard code, device field value, message type, and message reception order in the gateway cache. Records that complete protocol parsing and integrity verification and can retrieve the target field according to the field source record are determined as valid field records; for the same standard code, the latest valid field record is saved according to the message reception order. The edge high-aggregation gateway generates standardized device messages according to the data type and transmission format specified in the unified access project. These standardized device messages include device identifier, standard code, data name, device field value, and message reception order, and are sent to the stream processing engine through the API gateway. The stream processing engine then distributes these messages to the corresponding device attribute channel, device status channel, or operation result channel.

[0047] When the IoT platform initiates a device read request, the API gateway sends the device identifier and target standard code to the edge high-aggregation gateway. The edge high-aggregation gateway locates the device access instance based on the device identifier and reads the corresponding data read path according to the standard code. For request-response devices, the edge high-aggregation gateway determines the communication interface, request message type, and request-response associated fields based on the data read path, generates a read message by calling the device protocol adaptation rules, and sends it to the device. Upon receiving the return message, it confirms the correspondence based on the request-response associated fields and then extracts the device field value according to the field source record. For proactively reporting devices, the edge high-aggregation gateway reads the latest valid field record corresponding to the standard code from the gateway cache. If the cache has already been formed, it directly returns the device field value; if the cache has not yet been formed, it attaches the read request to the corresponding unified access project and returns the device field value after the next valid reporting message is written to the cache. The read result is returned to the IoT platform via the API gateway according to the data type and transmission format specified by the unified access project.

[0048] When the IoT platform initiates a write or control request, the API gateway sends the device identifier, target standard code, and target content to the edge high-aggregation gateway. The edge high-aggregation gateway reads the corresponding device operation path based on the device identifier and standard code, and obtains the fixed fields, extended segments, length field, and integrity verification configuration by referencing the identifier through device protocol adaptation rules. The target content is converted into the encoded form of the target device field values ​​according to the field definitions, and then written to the target fields according to the device operation path. The edge high-aggregation gateway generates a length field based on the written data area, combines the fixed fields and extended segment content, and generates integrity verification content to form a device protocol message. After the device returns a result message, the edge high-aggregation gateway determines the corresponding operation based on the request-response association fields, obtains the execution result from the result field, and returns it to the IoT platform according to the transmission format specified in the unified access project.

[0049] The stream processing engine processes standardized device messages according to device identifier, standard code, and message reception order. The IoT platform updates device registration records, attribute values, operating status, and operation results accordingly, and provides a unified API interface to upper-layer business systems. Upper-layer business systems execute read, write, or control requests using device identifiers and standard codes. The edge high-aggregation gateway selects the appropriate data read path or device operation path based on unified access description information to complete the underlying protocol communication.

[0050] Furthermore, a second embodiment of the present invention provides a unified access platform for IoT multi-protocol devices, the platform comprising: An edge high-aggregation gateway is used to acquire the original communication content generated by the device to be accessed during actual communication and construct device communication feature information. This device communication feature information includes communication segment organization methods, message length relationships, fixed structure areas, variable areas, variable length areas, length candidate associations, interaction correspondences, and the source message, message location, transmission direction, and communication segment corresponding to each relationship. Based on the device communication feature information, a protocol parsing template matching the current communication interface is invoked to generate device protocol adaptation rules. According to the device protocol adaptation rules, each device data field is sequentially extracted from the message and restored to its device field value. A field source record is generated based on the device field value, and a data reading path and device operation path are generated according to the access attributes and template field correspondences in the device protocol adaptation rules. The field source record, data reading path, and device operation path are combined into unified access description information. A device access instance is established based on the unified access description information, and communication messages from different protocol devices are converted into standardized device messages containing device identifiers and standard codes and sent to the IoT middleware platform. Device read requests and control requests initiated by the IoT middleware platform are processed according to the data reading path and device operation path. The IoT middleware platform is used to initiate device read and control requests.

[0051] The present invention also provides a storage medium storing an Internet of Things (IoT) multi-protocol device unified access program, wherein when the IoT multi-protocol device unified access program is executed by a processor, it implements the steps of the IoT multi-protocol device unified access method as described in any of the preceding claims.

[0052] 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.

[0053] Although embodiments of the invention have been shown and described, those skilled in the art will understand that various changes, modifications, substitutions and variations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the claims and their equivalents.

Claims

1. A unified access method for multi-protocol devices in the Internet of Things, characterized in that, Includes the following steps: S1. Obtain the original communication content generated by the device to be accessed during the actual communication process, and construct the device communication feature information; the device communication feature information includes the communication segment organization method, message length relationship, fixed structure area, variable area, variable length area, length candidate association, interactive correspondence relationship, and the source message, message position, transmission direction and communication segment corresponding to each relationship; S2. Based on the device communication characteristic information, call the protocol parsing template that matches the current communication interface to generate device protocol adaptation rules; S3. According to the device protocol adaptation rules, extract each device data field from the message sequentially and restore it to the device field value; generate a field source record based on the device field value, and generate a data reading path and a device operation path according to the access attribute and template field correspondence in the device protocol adaptation rules; combine the field source record, data reading path and device operation path into unified access description information. S4. Based on the unified access description information, establish a device access instance, convert the communication messages of different protocol devices into standardized device messages containing device identifiers and standard codes and send them to the IoT middleware, and process the device read requests and control requests initiated by the IoT middleware according to the data read path and device operation path.

2. The method for unified access of multi-protocol IoT devices according to claim 1, characterized in that, In step S1, the method for constructing the device communication feature information is as follows: A message set is established based on the connection port, connection session, and device endpoint, and the device communication messages are organized into communication segments according to the transmission direction and reception order; The messages are grouped according to the number of data locations. Fixed structure areas and variable areas are determined by comparing the consistency of the content at the same location. Common front structure, common back structure and variable length areas are determined by aligning from the beginning and end of the message respectively. After repeatedly verifying the fixed structure region, variable region, variable length region, length candidate association, and interaction correspondence, device communication feature information is generated.

3. The method for unified access of multi-protocol IoT devices according to claim 1, characterized in that, The method for generating the device protocol adaptation rules is as follows: The fixed structural region is established as the message anchor point based on its sequential position in the source message, and the content between adjacent anchor points is divided into independent structural segments. Each fixed structure region is mapped to the frame start field, device addressing field, operation field, data area boundary, or integrity verification region in the protocol parsing template. When the actual message from the device adds extended content based on the standard template, the operation field and the subsequent fixed structure are used as two anchor points to record the segment where the new content is located as the extended segment, and the length field and data area are shifted sequentially to form a field position configuration suitable for the current device.

4. The method for unified access of multi-protocol IoT devices according to claim 3, characterized in that, The method for determining the protocol parsing template is as follows: The filtered protocol parsing template is applied to all source messages associated with the device communication feature information, and the message boundaries, fixed field positions, length field interpretations, data area ranges, request-response associations, and integrity verification relationships are verified sequentially. When multiple templates can complete the parsing of all source messages, the template that can interpret the most fixed structure regions, variable regions, variable length regions, length candidate associations and interactive correspondences is selected. When the number of interpretations is the same, choose the template that can determine more request-response relationships.

5. The method for unified access of multi-protocol IoT devices according to claim 1, characterized in that, The step of sequentially extracting each device data field from the message and restoring it to its device field value specifically involves: Based on the field definitions in the device protocol adaptation rules, restore the data location of the field to the device field value; When a field is defined as an unsigned integer, the data positions are combined sequentially according to the data arrangement order. When a field is defined as a signed integer, the sign and value are determined according to the field's range and the two's complement rule. When a field is defined as a floating-point number, it is restored according to the floating-point encoding method, data position order, and word order of the record defined by the field. When a field is defined as a bit field, the target content is extracted according to the starting position and the number of bits occupied in the record defined by the field. When a field is defined as an encoded value, it is converted bit by bit according to the encoding method of the field definition record; when the field definition includes a proportional conversion relationship, the device field value is obtained according to the proportional coefficient and offset of the record after the encoding is restored.

6. The method for unified access of multi-protocol IoT devices according to claim 1, characterized in that, The data reading path is generated in the following way: For unified access projects with read attributes, a data read path is generated based on the field source record. The data read path records the device binding relationship, request message type, request response associated fields, return message type, data area boundary, field relative position, and data arrangement order. For proactive reporting devices, the data reading path records the reporting message type, relative position of fields, data arrangement order, and corresponding update items; The method for generating the device operation path is as follows: For unified access projects with write or control attributes, a device operation path is generated. The device operation path records the operation message type, target field position, data arrangement order, extended segment position, length field update method, fixed field content, integrity verification method, and associated fields and result fields in the expected return message. After the target content is converted into the encoding form of the target device field value according to the field definition, it is written to the target field according to the device operation path.

7. The method for unified access of multi-protocol IoT devices according to claim 1, characterized in that, The device read request is processed as follows: Locate the device access instance based on the device identifier, and read the corresponding data reading path according to the standard code; For request-response type devices, the communication interface, request message type and request-response associated fields are determined according to the data reading path. The device protocol adaptation rules are called to generate a reading message and send it to the device. After receiving the return message, the corresponding relationship is confirmed according to the request-response associated fields, and then the device field value is extracted according to the field source record. For devices that actively report, the latest valid field record corresponding to the standard code is read from the gateway cache and returned.

8. The method for unified access of multi-protocol IoT devices according to claim 1, characterized in that, The device control request is processed as follows: Read the corresponding device operation path based on the device identifier and standard code, and obtain the fixed fields, extended sections, length fields and integrity verification configuration through the device protocol adaptation rules; The target content is converted into the encoded form of the target device field value according to the field definition, and then written into the target field according to the device operation path; Generate a length field based on the written data area, combine the fixed field and extended segment content to generate integrity verification content, and form a device protocol message; After the device returns a result message, the corresponding operation is determined based on the request response associated fields, and the execution result is obtained from the result fields.

9. A unified access platform for multi-protocol IoT devices, characterized in that, The platform includes: An edge high-aggregation gateway is used to acquire the original communication content generated by the device to be accessed during actual communication and construct device communication feature information. This device communication feature information includes communication segment organization methods, message length relationships, fixed structure areas, variable areas, variable length areas, length candidate associations, interaction correspondences, and the source message, message location, transmission direction, and communication segment corresponding to each relationship. Based on the device communication feature information, a protocol parsing template matching the current communication interface is invoked to generate device protocol adaptation rules. According to the device protocol adaptation rules, each device data field is sequentially extracted from the message and restored to its device field value. A field source record is generated based on the device field value, and a data reading path and device operation path are generated according to the access attributes and template field correspondences in the device protocol adaptation rules. The field source record, data reading path, and device operation path are combined into unified access description information. A device access instance is established based on the unified access description information, and communication messages from different protocol devices are converted into standardized device messages containing device identifiers and standard codes and sent to the IoT middleware platform. Device read requests and control requests initiated by the IoT middleware platform are processed according to the data reading path and device operation path. The IoT middleware platform is used to initiate device read and control requests.

10. A storage medium, characterized in that, The storage medium stores a unified access program for IoT multi-protocol devices, which, when executed by a processor, implements the steps of the unified access method for IoT multi-protocol devices as described in any one of claims 1 to 8.

Images