A method and system for interworking and adapting industrial data in a multi-protocol environment

Abstract

The application belongs to the technical field of industrial internet data communication, and relates to a method and system for intercommunication and adaptation of industrial data in a multi-protocol environment, comprising: collecting original data carrying protocol identifiers from a device layer, an application layer and a platform layer based on a pre-set three-layer interconnected bus; performing analysis and processing on the original data based on a pre-set protocol stack, and obtaining intermediate data in a unified format; performing semantic adaptation on the intermediate data based on a pre-set information exchange semantic model, and obtaining semantic specification data; performing data preprocessing on the semantic specification data, and obtaining standardized semantic specification data; and performing layered transmission of target data in the standardized semantic specification data through a corresponding interconnected bus according to a specified interaction mode of a target layer. The application can improve the protocol coverage rate of an industrial scene, realize semantic unification and data intercommunication, improve the cross-system collaborative analysis efficiency, and reduce the deployment time and configuration cost.

Description

Technical Field

[0001] This invention relates to the field of industrial internet data communication technology, and in particular to a method and system for interoperability and adaptation of industrial data in a multi-protocol environment. Background Technology

[0002] In the current industrial internet scenario, there are dozens of protocol types at the industrial equipment layer, application layer, and cross-platform layer. The fragmentation of protocol types has made the communication differences between multi-source heterogeneous systems and devices a core bottleneck for data interoperability. At present, industrial data interoperability usually adopts the following methods: point-to-point protocol adaptation, centralized protocol conversion gateway, protocol format conversion, etc.

[0003] However, the existing solutions mentioned above have significant drawbacks. First, point-to-point protocol adaptation requires developing dedicated adaptation components for each pair of interacting devices / systems, resulting in extremely poor scalability. Adding new devices necessitates redeveloping the entire adaptation logic, and maintenance costs increase exponentially with system size. Second, centralized protocol conversion gateways achieve conversion of a few protocols through a single hardware gateway, but are limited by hardware performance and cannot cover all levels of protocols across devices, applications, and platforms. Furthermore, upgrading the gateway requires downtime, impacting the continuity of industrial production. Third, protocol format conversion only converts data formats from one protocol to another without unifying data semantics, leading to data being "accessible but not used," creating data silos. Meanwhile, as industrial scenarios evolve, real-time collaboration across devices, systems, and platforms is fundamental to achieving intelligent manufacturing and optimized decision-making. However, existing solutions cannot simultaneously address the three core requirements of multi-protocol coverage, flexible expansion, and semantic unification, thus hindering the effective utilization and development of industrial data. Summary of the Invention

[0004] Based on the above analysis, the embodiments of the present invention aim to provide a method and system for interoperability and adaptation of industrial data in a multi-protocol environment, in order to solve the problems that the existing technology cannot cope with dynamic expansion, cannot cover all scenarios and all levels of protocols, and cannot achieve semantic uniformity.

[0005] On one hand, embodiments of the present invention provide a method for interoperability and adaptation of industrial data in a multi-protocol environment, including:

[0006] Based on a pre-configured three-layer interconnect bus, raw data carrying protocol identifiers are collected from the device layer, application layer and platform layer respectively;

[0007] Based on a pre-set protocol stack, the raw data is parsed and processed to obtain intermediate data in a unified format;

[0008] Based on a pre-set information exchange semantic model, the intermediate data is semantically adapted to obtain semantically standardized data.

[0009] The semantic specification data is preprocessed to obtain standardized semantic specification data;

[0010] According to the interaction mode specified by the target level, the target data in the standardized semantic specification data is transmitted in layers through the corresponding interconnect bus; the target level includes any one or more of the device layer, application layer and platform layer.

[0011] Furthermore, the three-layer interconnect bus includes: a device interconnect bus, an application interconnect bus, and an open interconnect bus; the raw data includes: first raw data, second raw data, and third raw data;

[0012] The system, based on a pre-configured three-layer interconnect bus, collects raw data carrying protocol identifiers from the device layer, application layer, and platform layer, including:

[0013] Based on the device interconnect bus, the first raw data is collected from the device layer; based on the application interconnect bus, the second raw data is collected from the application layer; based on the open interconnect bus, the third raw data is collected from the platform layer.

[0014] Furthermore, the device interconnection bus's adaptation protocols include at least: Modbus protocol, Profibus protocol, OPC UA protocol, NB-IoT protocol, and MQTT protocol;

[0015] The application interconnect bus is compatible with at least the following protocols: HTTP / HTTPS, MQ, and MQTT.

[0016] The adaptation protocols of the open interconnect bus include at least: AMQP protocol, MQ protocol, HTTP / HTTPS protocol and SOAP protocol.

[0017] Furthermore, the process of parsing the raw data based on a pre-set protocol stack to obtain intermediate data in a unified format includes:

[0018] According to the scenario requirements, corresponding protocol parsing modules are configured for the device interconnect bus, application interconnect bus and open interconnect bus respectively to construct the protocol stack;

[0019] Based on the protocol identifiers carried by the first, second, and third raw data, the corresponding protocol parsing modules are selected from the protocol stack respectively;

[0020] The protocol parsing modules perform protocol parsing and format conversion on the corresponding raw data to obtain the intermediate data corresponding to each layer.

[0021] Furthermore, the process of semantically adapting the intermediate data based on a pre-set information exchange semantic model to obtain semantically standardized data includes:

[0022] For the intermediate data at different layers, metadata associated with the intermediate data at each layer is obtained from a preset static database; the contextual semantics of the corresponding intermediate data are completed based on the metadata, and the completed metadata for each layer is obtained.

[0023] According to the preset metadata standardization rules, the metadata of each layer is structured to obtain standardized metadata;

[0024] Based on preset semantic mapping rules and association verification rules, semantic mapping and association verification are performed on the standardized metadata of each layer;

[0025] Based on the results of semantic mapping and association verification, the semantic specification data with a unified semantic identifier is generated.

[0026] Furthermore, the semantic specification data is preprocessed, including at least the following: outlier removal, missing value completion, and unit conversion.

[0027] Furthermore, the interaction modes specified in the target level include at least: request-response interaction mode and subscription-publish interaction mode;

[0028] The step of transmitting the target data in the standardized semantic specification data in layers through the corresponding interconnect bus includes:

[0029] According to the request-response interaction mode specified by the target level, the target request data in the standardized semantic specification data is transmitted in layers through the corresponding interconnect bus;

[0030] And / or, according to the subscription-publish interaction mode specified by the target level, the target subscription data in the standardized semantic specification data is transmitted in layers through the corresponding interconnect bus.

[0031] Furthermore, the method also includes: monitoring the data transmission status of the device interconnect bus, application interconnect bus and open interconnect bus in real time through a pre-set protocol adaptation component;

[0032] When data transmission is abnormal, an audible and visual warning is triggered, and the primary communication channel of the abnormal interconnect bus is switched to the backup communication channel to continue transmission.

[0033] On the other hand, embodiments of the present invention provide an interoperability and adaptation system for industrial data in a multi-protocol environment, including:

[0034] The data acquisition module is used to acquire raw data carrying protocol identifiers from the device layer, application layer and platform layer respectively based on a pre-configured three-layer interconnection bus;

[0035] The protocol stack parsing module is used to parse and process the raw data based on a pre-set protocol stack and obtain intermediate data in a unified format.

[0036] The heterogeneous information interaction module is used to semantically adapt the intermediate data based on a pre-set information exchange semantic model and obtain semantically standardized data.

[0037] The data preprocessing module is used to preprocess the semantic specification data to obtain standardized semantic specification data;

[0038] The layered transmission module is used to transmit the target data in the standardized semantic specification data in layers through the corresponding interconnect bus according to the interaction mode specified by the target layer; the target layer includes any one or more of the device layer, application layer and platform layer.

[0039] Furthermore, the three-layer interconnect bus includes: a device interconnect bus, an application interconnect bus, and an open interconnect bus;

[0040] The system also includes: a protocol adaptation component module, used to monitor the data transmission status of the device interconnect bus, application interconnect bus and open interconnect bus in real time through a pre-set protocol adaptation component;

[0041] When data transmission is abnormal, an audible and visual warning is triggered, and the primary communication channel of the abnormal interconnect bus is switched to the backup communication channel to continue transmission.

[0042] Compared with the prior art, the present invention can achieve at least one of the following beneficial effects:

[0043] First, unlike related technologies that cannot cover all scenarios and all levels of protocols, this invention constructs a three-layer independent collaborative architecture of device interconnection bus, application interconnection bus, and open interconnection bus, which can respectively adapt to the differentiated protocol requirements of the device layer, application layer, and cross-platform layer in industrial scenarios, achieving full-level protocol coverage; it overcomes the limitations of centralized gateways in terms of limited protocol coverage and reliance on hardware performance, thus improving the protocol coverage rate in industrial scenarios; at the same time, by establishing a full-process monitoring and high-reliability assurance mechanism, it reduces operation and maintenance risks.

[0044] Second, unlike related technologies that cannot achieve semantic uniformity, this invention breaks down data silos by adding semantic uniformity and data cleaning steps; it unifies data meaning and solves semantic ambiguity by constructing an information exchange semantic model and establishing a bidirectional mapping dictionary of "original parameters - standard semantics"; and it cleans the semantically standardized data after semantic uniformity to ensure data quality, solving the problem of data being "accessible but not used" due to only using protocol conversion, improving the efficiency of cross-system collaborative analysis, and enhancing the accuracy of cross-system data semantic uniformity.

[0045] Secondly, unlike related technologies which suffer from poor scalability and low versatility, this invention, based on a "standardized SDK + OSGi framework + Docker container" architecture, achieves efficient development and hot deployment of protocol adaptation components. New protocol components can be directly called, reducing repetitive coding, eliminating the need to stop bus operation, lowering deployment time and configuration threshold, and improving scalability. At the same time, the semantic model and configuration interface support custom scene tags and industry rules, improving scene versatility and enabling rapid adaptation to multiple industrial scenarios such as non-ferrous metal smelting, chemical industry, and automotive industry, without the need to refactor core logic, thus reducing costs.

[0046] In this invention, the above-described technical solutions can be combined with each other to achieve more preferred combinations. Other features and advantages of this invention will be set forth in the following description, and some advantages may become apparent from the description or be learned by practicing the invention. The objects and other advantages of this invention can be realized and obtained from what is particularly pointed out in the description and drawings. Attached Figure Description

[0047] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Throughout the drawings, the same reference numerals denote the same parts.

[0048] Figure 1 This is a flowchart of a method for interoperability and adaptation of industrial data in a multi-protocol environment according to an embodiment of the present invention;

[0049] Figure 2 This is a schematic diagram of the layered decoupling and layered interconnection architecture according to an embodiment of the present invention;

[0050] Figure 3 This is a schematic diagram of the main modules of the industrial data interoperability and adaptation system under a multi-protocol environment according to an embodiment of the present invention. Detailed Implementation

[0051] Preferred embodiments of the present invention will now be described in detail with reference to the accompanying drawings, which form part of this application and are used together with the embodiments of the present invention to illustrate the principles of the present invention, but are not intended to limit the scope of the present invention.

[0052] A specific embodiment of the present invention discloses a method for interoperability and adaptation of industrial data in a multi-protocol environment, such as... Figure 1 As shown, the steps S1 to S5 are as follows:

[0053] Step S1: Based on the pre-configured three-layer interconnection bus, raw data carrying protocol identifiers are collected from the device layer, application layer and platform layer respectively.

[0054] This invention is applicable to data interaction scenarios in industrial production control areas, office information areas, and across industrial internet platforms. It can solve the problems of protocol differences and semantic inconsistencies in multi-source heterogeneous industrial systems, and support the implementation of intelligent manufacturing and industrial digitalization.

[0055] Specifically, the three-layer interconnect bus includes: a device interconnect bus, an application interconnect bus, and an open interconnect bus; the raw data includes: first raw data, second raw data, and third raw data. Collecting raw data carrying protocol identifiers includes: collecting the first raw data from the device layer based on the device interconnect bus; collecting the second raw data from the application layer based on the application interconnect bus; and collecting the third raw data from the platform layer based on the open interconnect bus.

[0056] The equipment layer, corresponding to the industrial production control area, refers to the layer composed of various industrial equipment and systems deployed on the production site, directly responsible for process control and parameter sensing. Its core entities include, but are not limited to, programmable logic controllers (PLCs), distributed control systems (DCS), sensors, and actuators. The application layer, corresponding to the office information area, refers to the information system layer built to support specific production operations and business management activities of an enterprise. Its core entities include manufacturing execution systems (MES), enterprise resource planning systems (ERP), warehouse management systems (WMS), and supervisory control and data acquisition (SCADA) systems. The platform layer refers to the industrial internet platform and external collaboration system layer built to achieve cross-enterprise, cross-platform, and cross-regional data collaboration. Its core entities include various industrial internet platforms. The first type of raw data is the raw data of the equipment layer, the second type is the raw data of the application layer, and the third type is the raw data of the platform layer; each type of raw data contains multiple heterogeneous communication protocol data.

[0057] It should be noted that the three-layer interconnect bus refers to the software architecture that enables communication and scheduling within each layer of the system. The embodiments of the present invention do not require any new dedicated hardware; they can be deployed and operated simply by reusing existing equipment and infrastructure in the industrial field.

[0058] Preferably, refer to Figure 2As shown, the device interconnection bus's adaptation protocols include at least: Modbus protocol, Profibus protocol, OPC UA protocol, NB-IoT protocol, and MQTT protocol;

[0059] The device interconnect bus enables data access from devices such as PLC systems, DCS systems, low-power sensors, and edge devices, as well as data communication with industrial internet platforms, meeting real-time requirements (latency ≤100ms).

[0060] The application interconnect bus is compatible with at least the following protocols: HTTP / HTTPS, MQ, and MQTT (for lightweight real-time data scenarios).

[0061] The application interconnect bus enables data access for application systems such as PLM, MES, and ERP, as well as data interoperability with industrial internet platforms, and supports high-bandwidth data transmission (≥100Mbps).

[0062] The adaptation protocols of the open interconnect bus include at least: AMQP protocol, MQ protocol, HTTP / HTTPS protocol and SOAP protocol;

[0063] Open interconnect bus enables data access and interoperability between different industrial internet platforms, and supports cross-regional data transmission, such as transmitting file data using HTTP / HTTPS protocol and transmitting highly reliable message data using AMQP protocol.

[0064] Preferably, the above data acquisition process relies on pre-set protocol adaptation components at each level. The protocol adaptation component is an auxiliary component that supports the operation of the protocol stack. It is first called in the data acquisition stage to complete the communication establishment and the acquisition of raw data. Then, in the protocol parsing stage, the component will continue to perform in-depth parsing, format conversion and real-time monitoring of the raw data. Other related functions of the component will be described in detail later.

[0065] For example, through the corresponding protocol adaptation components at each level, raw data can be collected from data sources such as PLC systems (mainly involving Modbus protocol), DCS systems (mainly involving Profibus protocol), NB-IoT sensors, MES systems (mainly involving HTTP / MQTT protocol), and external platforms (mainly involving SOAP / HTTP protocol). Each type of raw data carries a corresponding protocol identifier, such as "Modbus_RTU" or "SOAP_V1.2". The collection process supports offline caching of devices. When edge devices are offline, the raw data is temporarily stored locally and then uploaded in batches after going online.

[0066] As can be seen, the embodiments of the present invention adopt a layered decoupled architecture of a three-layer interconnect bus, in which each layer operates independently and can collaborate through protocol adaptation components. It can adapt to protocols of all scenarios and all levels of the device layer, application layer and platform layer, providing support for subsequent realization of accurate protocol adaptation, semantic unification and reliable transmission.

[0067] Step S2: Based on the pre-set protocol stack, the original data is parsed and processed to obtain intermediate data in a unified format.

[0068] In practice, the specific steps include: configuring corresponding protocol parsing modules for the device interconnect bus, application interconnect bus, and open interconnect bus according to scenario requirements to construct the protocol stack; selecting corresponding protocol parsing modules from the protocol stack based on the protocol identifiers carried by the first, second, and third raw data; performing protocol parsing and format conversion on the corresponding raw data through each protocol parsing module to obtain the intermediate data corresponding to each layer; and simultaneously, the parsed data will carry the corresponding layer identifier.

[0069] The parsing of raw data relies on the protocol parsing module, which is managed by the protocol stack management module. The data parsing process specifically includes the following:

[0070] (1) Protocol stack construction: Configure a protocol parsing module for the three-layer interconnect bus according to the scenario requirements. For example, configure a protocol parsing module of "Modbus protocol + Profibus protocol + NB-IoT protocol" for the device interconnect bus, thereby forming a dynamically adjustable software-defined protocol stack. The configuration logic supports automatic recommendation of protocol combinations based on industrial scenario tags. For example, it can automatically recommend corresponding protocol combinations based on scenario tags such as "non-ferrous smelting" and "automobile assembly" to reduce manual operation.

[0071] (2) Multi-protocol parsing: Converts the heterogeneous protocol raw data from various interconnected buses into intermediate data in a standard format; that is, converts the raw data into intermediate data containing four elements: "data source, parameter name, value, and unit". For example, converts the raw data "PLC_005,25.5" transmitted based on the Modbus protocol RTU format into intermediate data of "data source: PLC_005, parameter name: temperature, value: 25.5, unit: ℃". At the same time, the parsing process supports protocol version compatibility, such as automatic recognition of Modbus protocol RTU V1.0 and V2.0 formats. Preferably, when parsing fails (e.g., data frame corruption), the retry mechanism of the protocol adaptation component can be triggered (retry times ≤ 3 times, interval of 1 second) to perform parsing again.

[0072] (3) Parsing result management: A time-series database (such as InfluxDB database) is used to store intermediate data in a unified format after parsing, and record metadata such as asset ID (such as "PLC_001"), protocol type, and acquisition time. It supports data traceability and anomaly backtracking to meet the reading and writing needs of high-frequency data in industrial scenarios.

[0073] (4) Cross-domain configuration: Provides a visual interface that supports user-defined data interaction rules, such as setting the data interaction frequency between the MES system and the PLC system to 5 seconds / time and the interaction frequency between edge devices and the industrial Internet platform to 30 seconds / time; The visual interface has built-in industry templates, such as non-ferrous industrial equipment interaction templates and chemical ERP data templates, which lowers the configuration threshold.

[0074] It is understood that the protocol stack in this embodiment of the invention is a software-based whole composed of multiple protocol parsing modules; the protocol parsing module is responsible for parsing specific protocols, which converts the raw data of the specific protocol into intermediate data in a standard format; while the protocol adaptation component is an auxiliary component of the protocol parsing module, responsible for ensuring protocol adaptation, fault retry, version compatibility and other safeguards.

[0075] Specifically, the correspondence between the protocol adaptation component and the protocol parsing module is as follows:

[0076] (1) Modbus protocol adapter component: It adopts an independent design and corresponds to the Modbus protocol parsing module. This protocol parsing module is used to parse the RTU format unique to the Modbus protocol (such as "PLC_005,25.5") and supports V1.0 / V2.0 version compatibility.

[0077] (2) Profibus protocol adapter component: It adopts an independent design and corresponds to the Profibus protocol parsing module. This protocol parsing module is used to parse the frame structure unique to the Profibus DP protocol in order to extract equipment data such as DCS pressure.

[0078] (3) NB-IoT protocol adapter component: It adopts an independent design and corresponds to the NB-IoT protocol parsing module. The protocol parsing module is used to parse the low-power device binary format data of the NB-IoT protocol and adapt the sensor for lightweight transmission.

[0079] (4) MQTT protocol adaptation component: It adopts an independent design and corresponds to the MQTT protocol parsing module. The protocol parsing module is used to parse the message topic and payload of the MQTT protocol to extract real-time data from edge devices / application layers.

[0080] (5) HTTP Protocol Adaptation Component: It adopts an independent design and corresponds to the HTTP protocol parsing module. This protocol parsing module is used to parse the JSON / form format data transmitted by the HTTP protocol in order to extract the business parameters of the application layer (such as production plan, etc.).

[0081] (6) HTTPS protocol adapter component: It also corresponds to the HTTP protocol parsing module. Since the core data format of this protocol (such as JSON, file stream, etc.) is consistent with the HTTP protocol, encryption / breakpoint resume is only handled in the adapter component. Therefore, this protocol adapter component adopts a reuse design.

[0082] (7) MQ Protocol Adaptation Component: It adopts an independent design and corresponds to the MQ protocol parsing module. This protocol parsing module is used to parse the message queue structure transmitted by the MQ protocol in order to extract persistent data such as materials in the ERP system.

[0083] (8) SOAP protocol adapter component: It also corresponds to the HTTP protocol parsing module. The SOAP protocol transmits XML format data based on the HTTP protocol. The core parsing logic is to "extract the XML parameters carried by the HTTP protocol". Only SOAP protocol-specific tags need to be added for verification. Therefore, this protocol adapter component adopts a reuse design.

[0084] (9) AMQP protocol adaptation component: It also corresponds to the MQ protocol parsing module. Since the AMQP protocol and the MQ protocol are both message-type protocols, the core parsing logic is to "extract business data from the message frame". Only the high reliability mechanism unique to the AMQP protocol needs to be added. Therefore, this protocol adaptation component adopts a reuse design.

[0085] As can be seen, this invention can adapt to various industrial protocols such as Modbus, Profibus, NB-IoT, MQTT, HTTP / HTTPS, MQ, SOAP, and AMQP, and parse various raw data transmitted based on the above protocols, thereby improving the protocol coverage and parsing accuracy across all levels and scenarios.

[0086] Step S3: Based on the pre-set information exchange semantic model, perform semantic adaptation on the intermediate data to obtain semantically standardized data.

[0087] In practice, the specific steps include: for the intermediate data at different layers, obtaining metadata associated with each layer of intermediate data from a preset static database; completing the contextual semantics of the corresponding intermediate data based on the metadata, and obtaining the completed metadata for each layer; performing structured processing on the metadata for each layer according to preset metadata standardization rules to obtain standardized metadata; performing semantic mapping and association verification on the standardized metadata for each layer based on preset semantic mapping rules and association verification rules; and generating the semantically standardized data with a unified semantic identifier based on the results of semantic mapping and association verification.

[0088] The information exchange semantic model can unify data semantics. The model structure and construction rules are as follows:

[0089] (1) Model structure: Construct an information exchange semantic model consisting of three parts: Header metadata area (wrapper ID, asset ID), Context semantic context area (collection time, source system, scene label), and Body payload data area (data value, unit, data type);

[0090] (2) Field definition rules:

[0091] Packaging ID: Use the format of "company abbreviation + project number", for example, "XJYS_001" for an industrial production project, to ensure cross-company uniqueness;

[0092] Asset ID: Use the format "Equipment Type_Number_Workstation". For example, "PLC_005_Smelting Furnace 3" to support equipment traceability;

[0093] Data collection time: accuracy is in the second, and the time zone is uniformly set to East 8 (GMT+8) to avoid cross-regional time deviation;

[0094] Scene tags: Label the type of industrial scene, such as "non-ferrous smelting" or "chemical reaction", for subsequent scene-based data processing.

[0095] (3) Semantic mapping rules: Establish a bidirectional mapping dictionary of "original parameters - standard semantics":

[0096] This dictionary is essentially a rule-based knowledge base that establishes deterministic transformation relationships between raw parameters collected from various heterogeneous data layers and a unified semantic model defined within the system. This mapping is bidirectional: the forward mapping converts raw parameters parsed from the protocol stack into semantically unified and unambiguous standardized information; the reverse mapping supports locating semantically unified standardized information based on instructions initiated from the semantic model and converting it into a specified raw parameter format. The processing procedure is as follows:

[0097] Preset dictionary: Covers parameters of mainstream industrial systems, such as "Temp1" and "Press2" in PLC systems, which are mapped to "Asset ID_Temperature" and "Asset ID_Pressure" respectively;

[0098] Custom mapping: Users can add mapping relationships in the visual interface. For example, in the ERP system, "steel material 001" can be mapped to "asset ID_steel inventory".

[0099] Ambiguity resolution: When the same original parameter corresponds to multiple semantics, automatic matching can be achieved by combining scene tags and source systems; for example, "Load" may refer to "equipment load" or "material weight". If the source is an edge device, it is mapped to "equipment load", and if the source is an ERP system, it is mapped to "material weight".

[0100] The following will take the equipment layer PLC system and the application layer MES system as examples to explain in detail the semantic unification process of cross-system data in the embodiments of the present invention.

[0101] To unify the semantics of "PLC side Temp1" and "MES side equipment 1 temperature" into "PLC_005_smelting furnace 3_temperature", the following steps are involved:

[0102] First, obtain intermediate data parsed by the protocol stack from heterogeneous data sources and metadata associated with the intermediate data in the static database. The core is to complete the contextual semantics behind the data.

[0103] The root cause of semantic confusion is that it only looks at the data name (Temp1 / device 1 temperature) without contextual semantics. Therefore, the first step is to collect the metadata of the data itself and the corresponding physical / business attributes to cover both the PLC system and the MES system.

[0104] (1) For intermediate data and metadata on the PLC side:

[0105] First, the raw data from the PLC system is parsed using the Modbus protocol parsing module to obtain intermediate data (the real-time value of Temp1 is 250℃); then, additional device-level metadata of the PLC system is collected from the static database (the metadata is extracted from the PLC configuration file or equipment ledger); the details are as follows:

[0106] Intermediate data: Signal name "Temp1", value "250℃";

[0107] Meta information: PLC hardware identifier: PLC number "PLC_005" (read from the PLC device nameplate / configuration software);

[0108] Physical device association: The “Temp1” signal of this PLC system corresponds to the temperature sensor of “Smelting Furnace 3” (extracted from the PLC’s IO mapping table, such as IO address 0x00A corresponding to the temperature acquisition point of Smelting Furnace 3);

[0109] Parameter type: Temperature (obtained from PLC signal annotations or process documentation).

[0110] (2) For intermediate data and metadata on the MES side:

[0111] First, the raw data from the MES system is parsed using the HTTP / HTTPS / MQTT protocol parsing module to obtain intermediate data (the real-time value of "Equipment 1 temperature" is 250℃); then, additional business-level metadata of the MES system is collected from the static database (extracted from the MES equipment ledger and process management modules); as detailed below:

[0112] Intermediate data: Data name "Device 1 Temperature", Value "250℃";

[0113] Meta information: MES equipment code: The unique identifier of "equipment 1" in the MES system corresponds to "smelting furnace 3" (find "equipment 1 = smelting furnace 3" from the MES equipment ledger, including furnace body number, location, etc.);

[0114] Parameter type: Temperature (confirmed from the MES parameter dictionary);

[0115] Data source association: The source of this temperature data is "PLC_005" (the original data of "device 1 temperature" found in the MES data acquisition configuration comes from PLC_005).

[0116] Second, standardize metadata processing to eliminate differences in description formats and establish a unified language.

[0117] The metadata formats obtained from the PLC system and MES system may be inconsistent. For example, the format of PLC is "PLC_005" while that of MES is "Device 1"; the format of PLC is "IO mapping" while that of MES is "Device code", etc. Therefore, the second step is to structure the metadata of both systems according to a unified metadata standardization rule to ensure that the same attribute is described by the same field.

[0118] (1) Structure the PLC-side metadata:

[0119] Organize the PLC system's metadata according to standardized fields (such as data source number, physical device name, parameter type, and original signal name), fill in missing fields, and standardize the format;

[0120] The standardized PLC system metadata includes: data source number: PLC_005; physical device name: smelting furnace 3; parameter type: temperature; signal original name: Temp1.

[0121] (2) Structure the metadata on the MES side:

[0122] Organize the metadata of the MES system according to the same standardized fields, and eliminate custom naming on the business side (replace "Device 1" with the actual physical device name);

[0123] The standardized MES system metadata includes: data source number: PLC_005; physical device name: smelting furnace 3; parameter type: temperature; signal original name: device 1 temperature.

[0124] Third, construct semantic mapping rules and association verification rules to prove that the two types of standardized metadata point to the same physical object.

[0125] Based on standardized metadata, rule matching and physical attribute verification are used to confirm whether "Temp1 of PLC system" and "temperature of equipment 1 of MES system" correspond to the same physical object (temperature of smelting furnace 3) to avoid incorrect association.

[0126] (1) Semantic mapping rule construction:

[0127] Preset metadata matching rules for the same physical object:

[0128] Core matching fields: Data source number (consistent, e.g., both are PLC_005); Physical equipment name (consistent, e.g., both are smelting furnace 3); Parameter type (consistent, e.g., both are temperature);

[0129] Auxiliary matching field: numerical range (e.g., the range of Temp1 in PLC system is 0-500℃; the temperature range of Equipment 1 in MES system is 0-500℃, which can be cross-validated).

[0130] Perform field matching on the metadata of the mapped PLC system and MES system:

[0131] Core fields: Data source number = PLC_005 (consistent); Physical equipment name = Smelting furnace 3 (consistent); Parameter type = Temperature (consistent);

[0132] Auxiliary fields: The numerical range is 0-500℃ (consistent).

[0133] (2) Association Conflict Detection:

[0134] If the matching fields are inconsistent, for example, the physical device name of the PLC is "Smelting Furnace 2" and the physical device name of the MES is "Smelting Furnace 3", a conflict alarm will be triggered. The secondary verification will be performed by manual confirmation or by calling the device topology diagram (the IO correspondence diagram of PLC_005).

[0135] No conflict in matching: All matching fields are consistent, thus confirming that "Temp1" and "Device 1 Temperature" point to the same physical object, that is, the temperature of smelting furnace 3 pointed to by PLC_005.

[0136] Fourth, generate semantic specification data with unified semantic identifiers, output the final unified name, and ensure its availability across the entire chain.

[0137] After confirming that the association is correct, a semantic identifier is generated according to the preset unified naming rules and synchronized to the PLC system, MES system and various data platforms (such as data lake, industrial Internet platform, etc.) to ensure that each system uses the unified name when calling the semantic specification data in the future.

[0138] (1) Generation of unified semantic identifiers

[0139] Based on the naming rules of "data source number, physical device name, parameter type", uniqueness and readability are ensured to generate the final unified name.

[0140] The naming rules include: data source number (PLC_005), physical equipment name (smelting furnace 3), and parameter type (temperature); thus, the semantically standardized data with a unified semantic label is obtained as "PLC_005_smelting furnace 3_temperature".

[0141] (2) System-wide semantic synchronization

[0142] First, the unified identifier is written into the industrial data semantic registry for centralized storage (so that all systems can query it); then, the data name mapping between the PLC side and the MES side is updated through the API interface; for example, on the PLC side, the original signal name Temp1 is retained, but "unified identifier = PLC_005_smelting furnace 3_temperature" is associated in the metadata; on the MES side, the display name / storage name of "equipment 1 temperature" is updated to "PLC_005_smelting furnace 3_temperature", or a unified identifier field is added to the database on the MES side.

[0143] The final output includes: PLC data processed by the Modbus protocol parsing module, which carries a unified semantic identifier when transmitted to the data platform; MES data processed by the HTTP / MQTT protocol processing module, which is directly stored and retrieved with a unified semantic identifier; and "PLC_005_Smelting Furnace 3_Temperature" is used in subsequent reports, warnings, and data analysis to eliminate semantic ambiguity.

[0144] As can be seen, this invention can assign accurate and unambiguous standard semantics to raw data collected across systems, and finally generate standardized semantic data with standardized structure and unified semantics for subsequent verification, transmission and application, thereby improving the efficiency of cross-system collaborative analysis and breaking down data silos.

[0145] Step S4: Perform data preprocessing on the semantic specification data to obtain standardized semantic specification data.

[0146] During implementation, the semantic specification data undergoes data preprocessing, including at least: outlier removal, missing value completion, and unit conversion. Specifically, this includes:

[0147] Outlier Removal: A triple-judgment logic is employed, combining industry-preset thresholds, a 3σ algorithm, and user-defined rules. First, obvious outliers are filtered based on industry-preset thresholds, such as the normal temperature range for non-ferrous smelting PLCs being -20 to 500℃; values ​​exceeding this range are considered outliers. Second, latent outliers are identified using the 3σ algorithm (mean ± 3 times standard deviation). Finally, user-defined rules are combined to optimize the processing results and improve the outlier removal rate, such as excluding data within 10 seconds of equipment start-up and shutdown from being considered outliers.

[0148] Missing value completion: Linear interpolation is preferred, as it is suitable for continuously collected data such as temperature and pressure; the mean value of adjacent time points is used as a second choice, as it is suitable for discrete data such as equipment status; after completion, a "completion marker" is marked, which facilitates subsequent data traceability and improves data accuracy.

[0149] Unit Conversion: Built-in industrial unit conversion dictionary supports automatic identification of data units and conversion to target units; at the same time, users can preset the target unit system in the visual interface, such as the default units for the non-ferrous metals industry being "tons, ℃, MPa", etc.

[0150] Step S5: Based on the interaction mode specified by the target level, the target data in the standardized semantic specification data is transmitted in layers through the corresponding interconnect bus; the target level includes any one or more of the device layer, application layer, and platform layer.

[0151] In practice, the range of data transmitted at the target level is determined by the requested / subscribed content. It is not limited to the data collected by that level itself, but can also be data from other levels. In other words, the present invention can realize on-demand customized data services.

[0152] The main applicable scenarios for data transmission of this invention include: the platform layer (including multiple Internet platforms) receiving standardized semantic specification data collected from the device layer and the application layer and processed by the system of this invention; the device layer / application layer can receive standardized semantic specification data from its own layer, but does not involve scenarios of data exchange between the device layer and the application layer.

[0153] When selecting an interconnect bus for transmission, two factors need to be considered: whether it crosses external platforms and the data source level.

[0154] Preferably, the specific rules for layered transmission are as follows: When data transmission occurs within this system, i.e., when the target layer (platform layer / device layer / application layer) receives data sent from this system, the corresponding dedicated interconnect bus is selected according to the data source layer. Data from the device layer is transmitted to the target layer through the device interconnect bus, and data from the application layer is transmitted to the target layer through the application interconnect bus. When data is transmitted across external platforms (between two platforms), an open interconnect bus must be selected for transmission.

[0155] For example, the device-level data processed by this system (such as PLC temperature, sensor humidity, etc.) is transmitted to platform A via the device interconnect bus; the application-level data processed by this system (such as MES production plans, ERP material data, etc.) is transmitted to platform A via the application interconnect bus. Cross-platform data (such as quality data, report files, etc.) is transmitted to various Internet platforms via the open interconnect bus. Platform A transmits the quality data processed by this system to platform B via the SOAP protocol, and transmits the monthly reports processed by this system to platform B via the HTTP / HTTPS protocol. At the same time, if the SOAP protocol connection is interrupted, the system automatically switches to the AMQP protocol to transmit quality data, and transmits the alarm message "Edge_01 load exceeds 80%" to platform B via the MQ protocol. Both platform A and platform B are industrial Internet platforms at the platform layer.

[0156] The interaction modes specified in the target level include at least: request-response interaction mode and subscription-publishing interaction mode; the standardized semantic specification data will be transmitted in layers, specifically including:

[0157] According to the request-response interaction mode specified by the target level, the target request data in the standardized semantic specification data is transmitted in layers through the corresponding interconnect bus;

[0158] And / or, according to the subscription-publish interaction mode specified by the target level, the target subscription data in the standardized semantic specification data is transmitted in layers through the corresponding interconnect bus.

[0159] For example, the request-response interaction mode includes: the platform layer sends explicit data query or instruction execution requests to a designated device layer or application layer via this system, and schedules the corresponding bus, protocol parsing module, and protocol adaptation component through this system to return the data processing result to the initiating platform layer. The subscription-publishing interaction mode includes: the platform layer registers its long-term interest in a specific type of data through this system, and this system maintains this subscription relationship and, upon detecting relevant data generation or status updates from the device layer or application layer, automatically pushes the relevant data as a published message to all platform layers subscribed to that topic.

[0160] It needs to be clarified that the request / subscription interaction mode specified by the target layer is essentially the distribution of data to the target layer through the system of this invention (the system is the initiator of the request / subscription). For example, the system transmits standardized semantic specification data to the device layer / application layer / external platform layer, etc. It only applies to the platform layer requesting data from the device layer or application layer through this system, rather than the device layer / application layer actively requesting data from other layers (platform layer), and it does not involve direct mutual requests between layers. The core of all requests / subscriptions is the system itself, not the layers themselves.

[0161] Preferably, the method further includes: monitoring the data transmission status of the device interconnect bus, application interconnect bus and open interconnect bus in real time through a pre-set protocol adaptation component;

[0162] When data transmission is abnormal, an audible and visual warning is triggered, and the primary communication channel of the abnormal interconnect bus is switched to the backup communication channel to continue transmission.

[0163] Specifically, the main functions of the protocol adaptation component include:

[0164] (1) Component development support:

[0165] It provides standardized interfaces, such as RESTAPI, Java SDK, and C++ SDK, and supports the development of new protocol adaptation components, such as the new CoAP protocol adaptation component. At the same time, the SDK has built-in general protocol parsing functions, such as data format verification and frame structure parsing functions, which can be directly called during component development to reduce repetitive coding. The component output format must conform to the unified specification of "input protocol identifier, data conversion logic, and output standard format" to ensure compatibility with the Layer 3 interconnect bus.

[0166] (2) Component deployment and updates:

[0167] It supports hot deployment of protocol adaptation components, which can be implemented based on the OSGi modular framework and Docker lightweight containers. The OSGi framework is responsible for the dynamic loading / unloading of components, and the Docker container is used to isolate the component from the bus environment. When adding / upgrading components, the Docker container first completes the component pre-startup and compatibility verification, and then the OSGi framework connects the component to the bus without stopping the bus operation. In addition, during the deployment process, a circular cache queue is used to temporarily store the data to be transmitted, ensuring data continuity and reducing deployment time and cost.

[0168] (3) Adaptation verification and monitoring:

[0169] The system provides real-time monitoring of operational status, including metrics such as data throughput, adaptation success rate, and transmission latency. These metrics are collected through the Prometheus monitoring system and visualized using the Grafana visualization system. When adaptation fails (e.g., due to protocol format errors), an audible and visual alarm is triggered, and a fault log is recorded, including the error type, abnormal data frame, and occurrence time, ensuring fault location within 5 minutes. Customizable monitoring thresholds are also supported, such as triggering an alarm when the Modbus protocol adaptation success rate falls below 99%. This allows users to view real-time monitoring curves and historical logs through a visual interface, enabling rapid fault location and troubleshooting.

[0170] To further illustrate the data interoperability and adaptation process of this invention, a specific embodiment is provided below.

[0171] Taking a specific industrial production scenario as an example, the process for achieving data interoperability and adaptation between the production control area, office information area, and external platforms is as follows:

[0172] First, scenario requirements:

[0173] (1) Equipment layer: PLC system (adapted to Modbus RTU V2.0 protocol), DCS system (adapted to Profibus DP protocol), low power temperature and humidity sensor (adapted to NB-IoT protocol), and edge computing node (adapted to MQTT V3.1 protocol) need to be connected to the industrial Internet platform A; among them, the PLC system is used to collect the temperature of the smelting furnace (collection frequency 1 second / time), the DCS system collects the pressure of the smelting furnace (collection frequency 2 seconds / time), the sensor collects the humidity of the workshop (collection frequency 10 seconds / time), and the edge node collects the equipment load (collection frequency 5 seconds / time).

[0174] (2) Application layer: The MES system needs to transmit production plan data via HTTP protocol (transmission frequency 1 time / hour) and real-time production line status data via MQTT protocol (transmission frequency 5 seconds / time) to platform A; the ERP system transmits material data via MQ protocol (transmission frequency 1 time / day) to platform A.

[0175] (3) Platform layer: Platform A needs to transmit production line quality data to external platform B via SOAP V1.2 protocol (transmission frequency 10 seconds / time), and transmit monthly production report files to platform B via HTTP / HTTPS protocol (transmission frequency 1 time / month); at the same time, AMQP protocol serves as a backup communication channel when SOAP protocol fails, and transmits cross-platform device alarm data via MQ protocol, such as pushing alarm information in real time when the edge node load exceeds 80%.

[0176] Second, architecture configuration:

[0177] (1) Device interconnection bus: Deploy Modbus protocol adapter component (interfacing with PLC system, supporting RTU V1.0 / V2.0 version compatibility), Profibus protocol adapter component (interfacing with DCS system, DP protocol dedicated), NB-IoT protocol adapter component (interfacing with low power sensor, supporting low power mode data wake-up), MQTT protocol adapter component (interfacing with edge node, V3.1 protocol); Configure device interaction rules through visual interface: PLC system interacts with platform A at a frequency of 1 second / time, sensor interacts with platform A at a frequency of 10 seconds / time.

[0178] (2) Application Interconnection Bus: Deploy HTTP protocol adapter component (interfacing with MES production plan, supporting JSON data format), MQTT protocol adapter component (interfacing with MES production line status, supporting V3.1 protocol), MQ protocol adapter component (interfacing with ERP material data, supporting message queue persistence); Configure the interaction frequency between the MES system and platform A production line status at 5 seconds / time, and the interaction frequency between the ERP system and platform A material data at 1 time / day.

[0179] (3) Open Interconnection Bus: Deploy SOAP protocol adapter components (primary communication channel, interface with platform B quality data, V1.2 protocol), HTTP / HTTPS protocol adapter components (interface with platform B report files, supports breakpoint resume), AMQP protocol adapter components (backup communication channel, switchover when SOAP protocol fails, supports message confirmation mechanism), MQ protocol adapter components (interface with platform B alarm data, supports real-time push); Configure SOAP protocol fault judgment rules: connection timeout of 3 seconds, 3 consecutive transmission failures, packet loss rate > 5%; Switchover rollback conditions: SOAP protocol without failure for 5 consecutive minutes.

[0180] (4) Configure the information exchange semantic model according to preset rules:

[0181] Header metadata area: Wrapper ID, such as "XJYS_001" (XJYS is an abbreviation for industrial production, and 001 is the project number); Asset ID, such as "PLC_005_Smelting Furnace 3", "DCS_02_Reaction Tank 1", "Sensor_03_Workshop 2";

[0182] Context semantic context area: Acquisition time precision in seconds ("2025-10-17 15:00:00"); Time zone East 8; Source system "PLC", "MES", "ERP"; Scene label "Nonferrous Smelting";

[0183] Body payload data area: data value "25.5"; unit "℃" "MPa" "%RH"; data type "numeric" "file", where the report file is "file" and the annotation file path is " / platformA / report / 10.xlsx".

[0184] (5) Visual configuration interface: Load the "Nonferrous Smelting Scene Template" and configure the following information:

[0185] The data exchange frequency between the MES system and the PLC system is 5 seconds per time.

[0186] The edge node pushes data to platform A every 30 seconds.

[0187] When the SOAP protocol fails, it automatically switches to the AMQP system. After the switch, it sends a protocol switch notification to platform B, which includes: "The primary SOAP is faulty. We are currently using AMQP to transmit high-quality data. UUID prefix: AMQP_20251017".

[0188] Abnormal value judgment rules: PLC temperature normal range -20~500℃; DCS pressure normal range 0.1~1.0MPa; edge load normal range 0~80%.

[0189] Third, implementation steps:

[0190] Phase 1: Data Collection.

[0191] Modbus protocol adapter component acquires PLC temperature data (original format: "PLC_005,25.5", protocol identifier: "Modbus_RTU_V2.0");

[0192] The Profibus protocol adapter component collects DCS pressure data (raw format: "DCS_02,0.8", protocol identifier: "Profibus_DP");

[0193] The NB-IoT protocol adapter component collects sensor humidity data (raw format: "Sensor_03,45", protocol identifier: "NB-IoT_V1.0");

[0194] Edge nodes transmit device payload data via the MQTT protocol (raw format: "Edge_01,60", protocol identifier: "MQTT_V3.1");

[0195] The MES system transmits production plans via HTTP (original format: "MES_01, 300 pieces / day", protocol identifier: "HTTP_JSON") and production line status via MQTT (original format: "MES_01, normal", protocol identifier: "MQTT_V3.1").

[0196] The ERP system transmits material data via the MQ protocol (original format: "ERP_01, steel 0.005 thousand tons", protocol identifier: "MQ_Persistent").

[0197] Phase Two: Protocol Resolution.

[0198] The Modbus protocol parsing module is called by the protocol stack management module to convert PLC data into intermediate data in a standard format: "Data source: PLC_005, parameter name: temperature, value: 25.5, unit: ℃";

[0199] The Profibus protocol parsing module is invoked to convert DCS data into intermediate data: "Data source: DCS_02, parameter name: pressure, value: 0.8, unit: MPa";

[0200] The NB-IoT protocol parsing module is called to convert the sensor data into intermediate data: "Data source: Sensor_03, parameter name: humidity, value: 45, unit: %RH";

[0201] Call the MQTT protocol parsing module to convert edge node data into intermediate data: "Data source: Edge_01, parameter name: load, value: 60, unit: %";

[0202] Call the HTTP protocol parsing module to convert the MES production plan into intermediate data: "Data source: MES_01, parameter name: production plan, value: 300, unit: pieces / day";

[0203] Call the MQ protocol parsing module to convert ERP material data into intermediate data: "Data source: ERP_01, parameter name: steel inventory, value: 0.005, unit: thousand tons".

[0204] Phase 3: Semantic adaptation.

[0205] Add semantics to the intermediate data of PLC: Header(XJYS_001 / PLC_005_Smelting Furnace 3), Context(2025-10-1715:00:00 / PLC / Nonferrous Smelting), Body(25.5 / ℃ / Numerical type);

[0206] Add semantics to the intermediate DCS data: Header(XJYS_001 / DCS_02_Reaction Vessel 1), Context(2025-10-1715:00:02 / DCS / Nonferrous Smelting), Body(0.8 / MPa / Numerical).

[0207] Add semantics to the intermediate data in the report file (monthly production report):

[0208] Header(XJYS_001 / Report_10_202509), Context(2025-10-1723:00:00 / PlatformA / Nonferrous Smelting), Body( / platformA / report / 10.xlsx / File Type / Excel);

[0209] All semantics passed the verification: the PLC asset ID "PLC_005_Smelting Furnace 3" conforms to the format "Equipment Type_Number_Workstation", the report file type "Excel" is within the allowed range, and there are no verification anomalies.

[0210] Phase 4: Data Preprocessing.

[0211] Outlier removal: If a data entry "PLC_005,1000℃" is found in the PLC, which exceeds the temperature range of non-ferrous smelting (-20~500℃), it is determined to be an anomaly and removed.

[0212] Missing value completion: Sensor_03 has no humidity data at 15:02. Linear interpolation of 45%RH at 15:01 and 44.6%RH at 15:03 is used to obtain "44.8%RH", which is marked with "completion mark".

[0213] Unit conversion: Convert the ERP material data "0.005 thousand tons" to "5 tons" using the built-in dictionary to ensure consistency with the unit system of Platform A.

[0214] Phase 5: Layered transmission.

[0215] (1) Equipment data (PLC temperature, DCS pressure, sensor humidity, edge load) are transmitted to platform A via the equipment interconnection bus, with a transmission delay of ≤100ms;

[0216] (2) Application data (MES production plan, production line status, ERP material data) are transmitted to platform A via the application interconnection bus. The transmission bandwidth of MES production line status is ≥100Mbps.

[0217] (3) Cross-platform transmission:

[0218] Platform A transmits high-quality data to Platform B via SOAP protocol with a transmission latency of 50ms and a packet loss rate of 0%. Platform A transmits monthly reports to Platform B via HTTP / HTTPS protocol with a transmission rate of 2Mbps and supports resume transmission after interruption. After a transmission interruption and restart, it resumes from 60% of the transmission completed.

[0219] Simulated SOAP protocol failure (SOAP connection disconnection): The system detects a connection timeout of 3 seconds, determines that the primary communication channel has failed, immediately starts the AMQP protocol backup communication channel, buffers 10 untransmitted quality data, and sends a protocol switching notification to platform B. The AMQP protocol transmission delay is 60ms, and the switching takes 2 seconds.

[0220] When the load on the edge node rises to 85%, platform A pushes alarm data to platform B via the MQ protocol: "Header: XJYS_001 / Edge_01_Smelting Workshop, Context: 2025-10-17 15:10:00 / Edge_01 / Nonferrous Smelting, Body: 85% / Load / Alarm Type".

[0221] Phase Six: Monitoring and Verification.

[0222] (1) Monitoring metrics for protocol adaptation components:

[0223] Modbus protocol adapter component: throughput 500 messages / second, adaptation success rate 100%, transmission latency 40ms;

[0224] SOAP protocol adaptation component: Before the failure, the throughput was 200 messages / second with a latency of 50ms; after the failure, it switched to the AMQP protocol with a throughput of 180 messages / second and a latency of 60ms.

[0225] HTTP / HTTPS protocol adaptation component: Report transmission rate 2Mbps, 100% success rate of resuming interrupted downloads;

[0226] (2) Fault simulation and handling:

[0227] Injecting erroneous data "PLC_005,abc" (protocol format error) into the PLC triggered a red alarm light and a buzzer sound. The log recorded: "Error type: protocol format error, occurrence time: 2025-10-17 15:15:00, abnormal data: PLC_005,abc, protocol identifier: Modbus_RTU_V2.0", and the fault location took 3 minutes.

[0228] After restoring the SOAP primary communication channel connection, the system detects that the SOAP protocol has been fault-free for 5 consecutive minutes, automatically switches back to the SOAP primary communication channel to continue transmission, and uses the UUID identification code to remove duplicates, discarding the 80 data messages already transmitted through the AMQP backup communication channel to ensure no duplicates.

[0229] Fourth, implementation results:

[0230] (1) Protocol coverage: It is compatible with various industrial protocols such as Modbus, Profibus, NB-IoT, MQTT, HTTP / HTTPS, MQ, SOAP, and AMQP, covering all the protocol types that need to be accessed in this industrial production scenario, resulting in a coverage rate of 98%.

[0231] (2) Scalability: When adding a smart valve device with CoAP protocol, the adapter component is developed based on Java SDK, the frame structure parsing function built into SDK is called, and the device is pre-started with Docker container and hot-deployed with OSGi framework. The time taken is 45 minutes, which improves the scalability by 96.7%.

[0232] (3) Collaborative efficiency: Collaborative analysis of quality data between Platform A and Platform B (such as combining quality data from both locations to optimize smelting parameters) increases efficiency by 60%, and reduces the time spent on monthly report data interaction to 1 / 3 of the traditional solution.

[0233] (4) Monitoring integrity: Realize full monitoring of "throughput, adaptation success rate, transmission delay and packet loss rate", with 100% visualization rate of indicators and fault location time not exceeding 3 minutes.

[0234] (5) Data quality: 100% outlier removal rate, all 100 injected outlier data were removed, 98% accuracy rate for missing value completion (deviation from actual value ≤0.5%), 100% semantic consistency of cross-system data, and no semantic ambiguity.

[0235] It is understood that the above implementation methods are only for ease of understanding and simplification of description, and should not be construed as limiting the present invention. The present invention does not specifically limit the protocol type, applicable level, information exchange semantic model and parsing method, etc.

[0236] Therefore, it can be seen that the embodiments of the present invention can achieve one of the following beneficial effects:

[0237] First, multi-protocol full-layer coverage: It solves the problem of insufficient protocol coverage of centralized gateways, adapts to multiple protocols at all levels of devices, applications and platforms, and meets the data interoperability needs of multiple scenarios such as low power consumption and real-time transmission, without relying on hardware gateways.

[0238] Second, high scalability and flexibility: The modular design supports hot deployment, shortening the adaptation time for new protocols / devices; at the same time, the visual interface has built-in industry templates, which lowers the operating threshold and solves the problem of poor scalability in point-to-point adaptation.

[0239] Third, semantic-protocol two-layer interoperability: the information exchange semantic model enables multi-source heterogeneous data to be "interoperable and usable", and combined with data cleaning operations, it improves the efficiency of cross-system collaborative analysis and completely breaks down data silos.

[0240] Fourth, end-to-end monitoring and high reliability: Real-time monitoring of indicators such as throughput, success rate, latency, and packet loss rate shortens the time for fault location; at the same time, based on backup protocol channels and data caching mechanisms, transmission continuity is ensured, reducing maintenance costs and the risk of production interruption.

[0241] Fifth, strong industry adaptability: The information exchange semantic model supports scene tags and industry preset rules, which can be quickly adapted to different industrial scenarios such as non-ferrous metal smelting, chemical industry, and automobile assembly without large-scale modification of the core architecture, thus reducing adaptation costs.

[0242] In another embodiment of the present invention, an interoperability and adaptation system for industrial data in a multi-protocol environment is proposed, such as... Figure 3 As shown, it specifically includes the following modules:

[0243] The data acquisition module is used to acquire raw data carrying protocol identifiers from the device layer, application layer and platform layer respectively based on a pre-configured three-layer interconnection bus;

[0244] The protocol stack parsing module is used to parse and process the raw data based on a pre-set protocol stack and obtain intermediate data in a unified format.

[0245] The heterogeneous information interaction module is used to semantically adapt the intermediate data based on a pre-set information exchange semantic model and obtain semantically standardized data.

[0246] The data preprocessing module is used to preprocess the semantic specification data to obtain standardized semantic specification data;

[0247] The layered transmission module is used to transmit the target data in the standardized semantic specification data in layers through the corresponding interconnect bus according to the interaction mode specified by the target layer; the target layer includes any one or more of the device layer, application layer and platform layer.

[0248] Preferably, the three-layer interconnect bus includes: a device interconnect bus, an application interconnect bus, and an open interconnect bus, and the system further includes:

[0249] The protocol adaptation component module is used to monitor the data transmission status of the device interconnect bus, application interconnect bus and open interconnect bus in real time through pre-set protocol adaptation components;

[0250] When data transmission is abnormal, an audible and visual warning is triggered, and the primary communication channel of the abnormal interconnect bus is switched to the backup communication channel to continue transmission.

[0251] The above-described method and system embodiments are based on the same principles, and their related aspects can be referenced from each other to achieve the same technical effects. For specific implementation processes, please refer to the foregoing embodiments, which will not be repeated here.

[0252] Those skilled in the art will understand that all or part of the processes of the methods described in the above embodiments can be implemented by a computer program instructing related hardware, and the program can be stored in a computer-readable storage medium. The computer-readable storage medium may be a disk, optical disk, read-only memory, or random access memory, etc.

[0253] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for interoperability and adaptation of industrial data in a multi-protocol environment, characterized in that, include: Based on a pre-configured three-layer interconnect bus, raw data carrying protocol identifiers are collected from the device layer, application layer and platform layer respectively; Based on a pre-set protocol stack, the raw data is parsed and processed to obtain intermediate data in a unified format; Based on a pre-set information exchange semantic model, the intermediate data is semantically adapted to obtain semantically standardized data. The semantic specification data is preprocessed to obtain standardized semantic specification data; According to the interaction mode specified by the target level, the target data in the standardized semantic specification data is transmitted in layers through the corresponding interconnect bus; the target level includes any one or more of the device layer, application layer and platform layer.

2. The adaptation method according to claim 1, characterized in that, The three-layer interconnect bus includes: a device interconnect bus, an application interconnect bus, and an open interconnect bus; the raw data includes: first raw data, second raw data, and third raw data. The system, based on a pre-configured three-layer interconnect bus, collects raw data carrying protocol identifiers from the device layer, application layer, and platform layer, including: Based on the device interconnect bus, the first raw data is collected from the device layer; based on the application interconnect bus, the second raw data is collected from the application layer; based on the open interconnect bus, the third raw data is collected from the platform layer.

3. The adaptation method according to claim 2, characterized in that, The device interconnect bus's adaptation protocols include at least: Modbus protocol, Profibus protocol, OPC UA protocol, NB-IoT protocol, and MQTT protocol; The application interconnect bus is compatible with at least the following protocols: HTTP / HTTPS, MQ, and MQTT. The adaptation protocols of the open interconnect bus include at least: AMQP protocol, MQ protocol, HTTP / HTTPS protocol and SOAP protocol.

4. The adaptation method according to claim 3, characterized in that, The process of parsing the raw data based on a pre-configured protocol stack to obtain intermediate data in a unified format includes: According to the scenario requirements, corresponding protocol parsing modules are configured for the device interconnect bus, application interconnect bus and open interconnect bus respectively to construct the protocol stack; Based on the protocol identifiers carried by the first, second, and third raw data, the corresponding protocol parsing modules are selected from the protocol stack respectively; The protocol parsing modules perform protocol parsing and format conversion on the corresponding raw data to obtain the intermediate data corresponding to each layer.

5. The adaptation method according to claim 1, characterized in that, The process of semantically adapting the intermediate data based on a pre-set information exchange semantic model to obtain semantically standardized data includes: For the intermediate data at different layers, metadata associated with the intermediate data at each layer is obtained from a preset static database; the contextual semantics of the corresponding intermediate data are completed based on the metadata, and the completed metadata for each layer is obtained. According to the preset metadata standardization rules, the metadata of each layer is structured to obtain standardized metadata; Based on preset semantic mapping rules and association verification rules, semantic mapping and association verification are performed on the standardized metadata of each layer; Based on the results of semantic mapping and association verification, the semantic specification data with a unified semantic identifier is generated.

6. The adaptation method according to claim 1, characterized in that, Data preprocessing of the semantic specification data includes at least: outlier removal, missing value completion, and unit conversion.

7. The adaptation method according to claim 1, characterized in that, The interaction modes specified in the target level include at least: request-response interaction mode and subscription-publish interaction mode; The step of transmitting the target data in the standardized semantic specification data in layers through the corresponding interconnect bus includes: According to the request-response interaction mode specified by the target level, the target request data in the standardized semantic specification data is transmitted in layers through the corresponding interconnect bus; And / or, according to the subscription-publish interaction mode specified by the target level, the target subscription data in the standardized semantic specification data is transmitted in layers through the corresponding interconnect bus.

8. The adaptation method according to claim 2, characterized in that, The method further includes: The data transmission status of the device interconnect bus, application interconnect bus and open interconnect bus can be monitored in real time through pre-configured protocol adaptation components. When data transmission is abnormal, an audible and visual warning is triggered, and the primary communication channel of the abnormal interconnect bus is switched to the backup communication channel to continue transmission.

9. A system for interoperability and adaptation of industrial data in a multi-protocol environment, characterized in that, include: The data acquisition module is used to acquire raw data carrying protocol identifiers from the device layer, application layer and platform layer respectively based on a pre-configured three-layer interconnection bus; The protocol stack parsing module is used to parse and process the raw data based on a pre-set protocol stack and obtain intermediate data in a unified format. The heterogeneous information interaction module is used to semantically adapt the intermediate data based on a pre-set information exchange semantic model and obtain semantically standardized data. The data preprocessing module is used to preprocess the semantic specification data to obtain standardized semantic specification data; The layered transmission module is used to transmit the target data in the standardized semantic specification data in layers through the corresponding interconnect bus according to the interaction mode specified by the target layer; the target layer includes any one or more of the device layer, application layer and platform layer.

10. The adaptation system according to claim 9, characterized in that, The three-layer interconnect bus includes: device interconnect bus, application interconnect bus, and open interconnect bus; The system also includes: The protocol adaptation component module is used to monitor the data transmission status of the device interconnect bus, application interconnect bus and open interconnect bus in real time through pre-set protocol adaptation components; When data transmission is abnormal, an audible and visual warning is triggered, and the primary communication channel of the abnormal interconnect bus is switched to the backup communication channel to continue transmission.

Images