An industrial internet of things thing model card based on FPGA technology

Abstract

This application discloses an industrial IoT object model card based on FPGA technology, comprising: a PCIe interface for interconnecting the object model card with the host computer or host PC of a power generation enterprise's business system; a first Ethernet interface for connecting field industrial equipment; a second Ethernet interface for connecting to an IoT platform; and an FPGA chip for hardware acceleration. Using the solution of this application, the parallel processing capabilities of the FPGA are leveraged to accelerate the parsing of complex industrial protocols, achieving microsecond-level real-time data acquisition and command issuance, thus overcoming the performance bottleneck of traditional software gateways. Through dynamic protocol loading and automatic object model generation, the ability to quickly adapt to and plug in and play with massive heterogeneous devices, especially those with proprietary protocols, is greatly enhanced. Simultaneously, security mechanisms such as data encryption and redundant backup are embedded at the hardware level, effectively resisting network and physical attacks.

Description

Technical Field

[0001] This application generally relates to the field of industrial Internet of Things (IIoT) technology. More specifically, this application relates to an IIoT object model card based on FPGA technology. Background Technology

[0002] The traditional object modeling technology commonly used in the current Industrial Internet of Things (IIoT) has significant limitations. Its "static modeling - protocol binding - business invocation" process leads to two main problems: First, the object model is disconnected from the actual capabilities of the equipment. The static model cannot reflect the equipment's status and functional changes in real time. After equipment upgrades, the model update cycle is long, requiring significant manual intervention, which can easily lead to business invocation failures and information delays. Second, the protocol is tightly coupled with the model. When facing changes in equipment interfaces or the integration of heterogeneous devices, a significant amount of time must be spent rewriting driver code, resulting in high system complexity and expensive maintenance costs. This not only causes inconsistencies between the IoT platform and business systems' calls to the object model and the actual equipment situation, but may even lead to production accidents.

[0003] To address these issues, the industry has attempted to use software middleware for protocol conversion and data integration. However, this approach still has shortcomings: high costs for adapting proprietary protocols, slow response to device changes (requiring manual updates to the object model), and a lack of intelligent device protocol matching and error correction capabilities, leading to reliance on manual model verification and a high error rate. Furthermore, existing solutions face configuration difficulties in multi-system collaboration. In terms of information security, software encryption is vulnerable to side-channel attacks, key management is fragmented, and security is particularly poor under older operating systems. Additionally, many industrial control devices suffer from low utilization of computing resources.

[0004] In view of this, there is an urgent need to provide an industrial IoT object model card based on FPGA technology to solve the problems of current industrial IoT technology in terms of object model dynamism, flexible protocol adaptation, intelligent error correction, hardware-level security, and effective utilization of computing resources. Summary of the Invention

[0005] In order to at least address one or more of the technical problems mentioned above, this application proposes an industrial IoT object model card based on FPGA technology in several aspects.

[0006] This application provides an industrial IoT object model card based on FPGA technology, comprising: a PCIe interface for interconnecting the object model card with the host computer or host PC of a power generation enterprise's business system; a first Ethernet interface for connecting field industrial equipment; a second Ethernet interface for connecting to an IoT platform; an FPGA chip for hardware acceleration, including: a protocol identification and parsing module for real-time processing of network packets to obtain communication protocol types and corresponding data of the field industrial equipment; a dynamic modeling module for dynamically generating standardized object models of the field industrial equipment based on the corresponding data; a protocol dynamic loading module for receiving and implementing hardware parsing logic for private protocols during FPGA chip operation; a hardware-level security module for providing encrypted communication for data transmission and redundant backup of internal data; a host status monitoring module for monitoring the operating status indicators of the host PC and generating alarms; and a physical card driver module for the host computer or host PC to identify and interact with the object model card.

[0007] In some embodiments, the protocol identification and parsing module includes: a protocol compatibility identification unit, which extracts protocol identifiers, data frame types, and field structure features by hardware intercepting key fields in the header of network packets, and determines the communication protocol type based on the real-time extracted protocol identifiers, data frame types, and field structure features using a lightweight random forest algorithm that directly maps the decision tree structure to the FPGA chip in a parallel processing manner; and a multi-protocol parsing unit, which performs real-time interception and parsing of protocol data streams from industrial field networks based on the judgment results of the protocol compatibility identification unit.

[0008] In some embodiments, during the real-time interception and parsing of protocol data streams from an industrial field network, the following steps are performed: real-time interception of the protocol data streams from the industrial field network to obtain protocol data frames; verification of the intercepted protocol data frames using a hardware CRC check module to determine whether they are erroneous frames; in response to the intercepted protocol data frames being erroneous frames, discarding the protocol data frames and logging them; in response to the intercepted protocol data frames not being erroneous frames, parsing the protocol data frames to obtain the corresponding data from the industrial equipment in the field.

[0009] In some embodiments, during the process of dynamically generating a standardized object model of the industrial equipment based on the corresponding data of the industrial equipment on site, the dynamic modeling module performs the following steps: constructing a device feature vector containing interface dimension, data dimension, and control dimension based on the corresponding data of the industrial equipment on site extracted by the protocol identification and parsing module; performing cosine similarity matching between the feature vector and each object model template in the pre-set object model template library; determining whether there is an object model template in the pre-set object model template library whose cosine similarity with the feature vector is greater than the matching threshold; in response to the existence of an object model template in the pre-set object model template library whose cosine similarity with the feature vector is greater than the matching threshold, using the object model template with the highest cosine similarity as the standardized object model; in response to the absence of an object model template in the pre-set object model template library whose cosine similarity with the feature vector is greater than the matching threshold, enabling a general template and generating a standardized object model based on the general template.

[0010] In some embodiments, after obtaining the standardized object model, the dynamic modeling module performs the following steps: obtaining the confidence level of the attributes of the standardized object model; determining whether the confidence level is less than a preset confidence threshold; in response to the confidence level not being less than the preset confidence threshold, recording the attributes of the standardized object model to the object model knowledge base and storing them in a static storage chip, and encapsulating them into a JSON format conforming to the IoT platform specifications, encrypting them through the hardware-level security module, and uploading them to the IoT platform via the second Ethernet interface; in response to the confidence level being less than the preset confidence threshold, generating alarm information and pushing it to the IoT platform for manual review, and updating the standardized object model based on the manual review results.

[0011] In some embodiments, the FPGA chip further includes an intelligent model difference alarm module, which is used to compare the differences between the standardized object model generated by the dynamic modeling module and the historical object model in real time; during the real-time comparison of the differences between the standardized object model generated by the dynamic modeling module and the historical object model, alarm information of the corresponding level is generated based on the difference type between the standardized object model and the historical object model, and the generated alarm information is uploaded to the Internet of Things platform through the second Ethernet interface.

[0012] In some embodiments, when the protocol identification and parsing module fails to obtain the communication protocol type, the protocol dynamic loading module performs the following steps: receiving a JSON-formatted configuration file imported by the user through a client tool, which defines the structure, field parsing rules, and exception handling strategy of the private protocol; pre-dividing a static region and a dynamic reconfiguration region in the FPGA chip, and transmitting the configuration file to the reconfiguration cache in the dynamic reconfiguration region through the PCIE interface; calling a parser to convert the configuration file into an intermediate representation to extract the protocol structure, data field definitions, and processing logic, the processing logic including reconfiguration control logic; and generating a hardware parsing circuit based on the intermediate representation.

[0013] In some embodiments, during the process of generating a hardware parsing circuit based on the intermediate representation, the following steps are performed: pausing the clock signal of the logic unit associated with the dynamic reconfiguration region through the reconfiguration control logic; writing the configuration file corresponding to the intermediate representation from the reconfiguration cache to the configuration memory of the FPGA chip through the reconfiguration control logic to update the configuration and routing information of the logic unit and generate a hardware parsing circuit corresponding to the private protocol; restoring the clock signal of the logic unit to start the generated hardware parsing circuit.

[0014] In some embodiments, the hardware-level security module includes an encryption unit and a secure storage unit; the encryption unit has a built-in root key to establish an encrypted communication channel; the secure storage unit is used to divide the SRAM inside the FPGA chip into a primary partition and a backup partition, and to perform simultaneous write operations on the primary partition and the backup partition for preset key data.

[0015] In some embodiments, the FPGA chip further includes a control instruction execution module, which performs the following steps: receiving standardized control instructions for corresponding field industrial equipment from an IoT platform, wherein the standardized control instructions are obtained by API calling and converting the object model of the IoT platform through a business system; verifying the support of the corresponding field industrial equipment for the standardized control instructions, and determining whether the corresponding field industrial equipment supports the standardized control instructions; in response to the corresponding field industrial equipment not supporting the standardized control instructions, suspending the issuance of the standardized control instructions, returning an error code and triggering an alarm to the IoT platform; in response to the corresponding field industrial equipment supporting the standardized control instructions, converting the standardized control instructions into instruction messages in the communication protocol format corresponding to the corresponding field industrial equipment, and issuing the instruction messages to the corresponding field industrial equipment through a first Ethernet interface; and monitoring the execution status and results of the corresponding field industrial equipment in response to the instruction messages in real time, and feeding back the execution status and results to the IoT platform through a second Ethernet interface.

[0016] Through the FPGA-based industrial IoT object model card provided above, this embodiment of the application utilizes the parallel processing capabilities of FPGA to accelerate the parsing of complex industrial protocols, achieving microsecond-level real-time data acquisition and command issuance, thus overcoming the performance bottleneck of traditional software gateways. By dynamically loading protocols and automatically generating object models, it significantly enhances the ability to quickly adapt to and plug in and play with massive numbers of heterogeneous devices, especially those with proprietary protocols. Simultaneously, it embeds security mechanisms such as data encryption and redundant backup at the hardware level, providing chip-level security protection, effectively resisting network and physical attacks, and independently monitoring host status, ensuring end-to-end reliability and business continuity of the entire data link.

[0017] Furthermore, in some embodiments, by completely embedding the protocol identification and data verification process into the FPGA hardware circuit, the performance bottlenecks and uncertainties of traditional software parsing methods are fundamentally solved. It innovatively maps the Random Forest intelligent identification algorithm directly to hardware logic, leveraging the parallel characteristics of the FPGA to instantly determine the protocol type based on key features in the message header within nanoseconds, achieving a leap from software judgment to hardware intuition. Before formally parsing the data, it uses a dedicated hardware CRC check module to perform integrity verification on each frame of data, enabling the immediate discarding of any erroneous or corrupted data frames at the hardware level. This hardened pipeline operation of identification, verification, and parsing not only ensures that the subsequently processed data is 100% valid, avoiding resource waste, but also compresses the latency of the entire protocol processing process to the physical limit, providing a solid foundation for the real-time performance and reliability of upper-layer applications.

[0018] Furthermore, in some embodiments, through innovative feature vector and cosine similarity matching algorithms, the object model card can analyze the data interface and behavioral characteristics of new devices upon their access, and intelligently match the most suitable object model from the template library. Even for unknown devices, it can use a universal template for guaranteed adaptation, greatly reducing the threshold and debugging cycle for new device access. Simultaneously, through confidence verification, the system automatically adds high-confidence, successfully matched models to the knowledge base. For low-confidence fuzzy matches, it proactively triggers manual review alerts, introducing expert knowledge for correction. This closed-loop mechanism of machine decision-making and human supervision ensures that object models are not only generated quickly but also accurately, and become increasingly intelligent and precise over time with human intervention.

[0019] Furthermore, in some embodiments, the ability to parse entirely new proprietary protocols is dynamically injected into the FPGA during device operation, completely breaking the limitations of traditional fixed hardware logic. When encountering unrecognized proprietary protocols, the system is no longer helpless but allows users to teach the hardware how to parse them through a simple JSON configuration file. This enables the physical model card to infinitely expand its protocol library, easily handling the ever-increasing number of non-standard devices in industrial environments. This process completely shields the user from the complexity of protocol adaptation. Users only need to provide a high-level JSON definition file, and the system can automatically parse, convert, and dynamically generate a dedicated, high-performance hardware parsing circuit. This achieves a shift from software plug-in to native hardware support, ensuring that newly added proprietary protocols can also enjoy the same microsecond-level hardware acceleration performance as other protocols. Attached Figure Description

[0020] The above and other objects, features, and advantages of exemplary embodiments of this application will become readily understood by reading the following detailed description with reference to the accompanying drawings. In the drawings, several embodiments of this application are illustrated by way of example and not limitation, and the same or corresponding reference numerals denote the same or corresponding parts, wherein: Figure 1 This paper illustrates an exemplary composition diagram of an industrial IoT object model card based on FPGA technology, according to an embodiment of this application. Figure 2 An exemplary flowchart illustrating real-time interception and parsing of protocol data streams from an industrial field network, according to an embodiment of this application, is shown. Figure 3 An exemplary flowchart illustrating an embodiment of this application shows how to dynamically generate a standardized physical model of an industrial equipment based on corresponding data from the industrial equipment in the field. Figure 4 An exemplary flowchart illustrating the corresponding processing of the confidence level of the properties based on the standardized object model in an embodiment of this application is shown; Figure 5 An exemplary flowchart illustrating the hardware parsing logic for receiving and implementing a proprietary protocol according to an embodiment of this application is shown; Figure 6 An exemplary flowchart of the hardware parsing circuit based on intermediate representation generation according to an embodiment of this application is shown; Figure 7 An exemplary flowchart illustrating how this application embodiment processes standardized control commands received from an IoT platform for corresponding field industrial equipment is shown. Detailed Implementation

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

[0022] It should be understood that the terms "comprising" and "including" used in the specification and claims of this application indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0023] It should also be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the application. As used in this specification and claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in this specification and claims refers to any combination and all possible combinations of one or more of the associated listed items, and includes such combinations.

[0024] As used in this specification and claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if [described condition or event] is detected" may be interpreted, depending on the context, as "once determined," "in response to determination," "once [described condition or event] is detected," or "in response to detection of [described condition or event]."

[0025] The specific embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0026] Figure 1An exemplary composition diagram of an industrial Internet of Things (IoT) object model card 100 based on FPGA technology according to an embodiment of this application is shown.

[0027] like Figure 1 As shown, the physical model card 100 includes a PCIe interface 110, a first Ethernet interface 120, a second Ethernet interface 130, and an FPGA chip 140.

[0028] Specifically, the PCIe interface 110 is used for interconnection between the physical model card and the host computer or host PC of the power generation enterprise's business system.

[0029] Specifically, the first Ethernet interface 120 is used to connect field industrial equipment.

[0030] Specifically, the second Ethernet interface 130 is used to connect to the Internet of Things (IoT) platform.

[0031] Specifically, the FPGA chip 140 is used to implement hardware acceleration, including: a protocol identification and parsing module 141, a dynamic modeling module 142, a protocol dynamic loading module 143, a hardware-level security module 144, a host status monitoring module 145, and a physical card driver module 146.

[0032] Specifically, the protocol identification and parsing module 141 is used to process network packets in real time to obtain the communication protocol type and the corresponding data of the industrial equipment on site.

[0033] Specifically, the dynamic modeling module 142 is used to dynamically generate standardized physical models of the industrial equipment on-site based on the corresponding data of the industrial equipment on-site.

[0034] Specifically, the protocol dynamic loading module 143 is used to receive and implement the hardware parsing logic of the private protocol during FPGA chip runtime.

[0035] Specifically, the hardware-level security module 144 is used to provide encrypted communication for data transmission and redundant backup of internal data.

[0036] Specifically, the host status monitoring module 145 is used to monitor the operating status indicators of the host PC and generate alarms.

[0037] Specifically, the physical card driver module 146 is used for the host computer or host PC to identify and interact with the physical card 100.

[0038] In the embodiments of this application, the protocol identification and parsing module 141 includes a protocol compatibility identification unit and a multi-protocol parsing unit.

[0039] Specifically, the protocol compatibility identification unit intercepts key fields in the header of network packets through hardware, extracts protocol identifiers, data frame types, and field structure features, and uses a lightweight random forest algorithm that directly maps the decision tree structure to the FPGA chip to determine the communication protocol type in parallel processing based on the real-time extracted protocol identifiers, data frame types, and field structure features.

[0040] In the embodiments of this application, the protocol compatibility identification unit utilizes the high-speed parallel processing capability of the FPGA chip to quickly extract the first 64 bytes (such as Modbus transaction ID, OPC UA session identifier) ​​during message transmission, and extracts information such as protocol identifier, data frame type (such as request / response), and field structure characteristics through specific logic circuits. For example, specific byte bits of the message are stored and analyzed through dedicated registers and logic units to identify different protocol characteristics.

[0041] In the embodiments of this application, a lightweight random forest algorithm is used to determine the protocol type in real time. The decision tree structure of the lightweight random forest algorithm is mapped into the logic units of the FPGA chip, and classification efficiency is improved by computing multiple decision trees in parallel. Simultaneously, hardware optimizations are performed on the lightweight random forest algorithm. For example, when computing multiple decision trees, the number of decision trees computed simultaneously can be determined based on the number of logic units and bandwidth of the FPGA chip, avoiding excessive parallelism that leads to resource waste. Alternatively, the node judgment process of the decision tree can be divided into multiple pipeline stages, with each pipeline stage responsible for completing a portion of the computational task. This improves the processing speed of the algorithm while fully utilizing FPGA resources and reducing idle time.

[0042] Specifically, the multi-protocol parsing unit intercepts and parses the protocol data stream from the industrial field network in real time based on the judgment result of the protocol compatibility identification unit.

[0043] For details on the real-time interception and parsing of protocol data streams from industrial field networks in the embodiments of this application, please refer to [link / reference needed]. Figure 2 .

[0044] Figure 2 An exemplary flowchart illustrating real-time interception and parsing of protocol data streams from an industrial field network, according to an embodiment of this application, is shown.

[0045] like Figure 2As shown, in step S210, the protocol data stream from the industrial field network is intercepted in real time to obtain protocol data frames. In step S220, a hardware CRC check module is used to verify the intercepted protocol data frames to determine whether they are erroneous frames. If the intercepted protocol data frame is an erroneous frame, in step S230, the protocol data frame is discarded and logged. If the intercepted protocol data frame is not an erroneous frame, in step S240, the protocol data frame is parsed to obtain the corresponding data from the industrial equipment in the field.

[0046] In the embodiments of this application, the FPGA chip embeds a multi-protocol parsing engine (supporting mainstream industrial protocols such as Modbus, OPC UA, and IEC61850), interacts with the device based on communication protocols, and accurately extracts the following data from the field industrial equipment: Device attributes: including sensor data (such as temperature, pressure, voltage), real-time parameters such as device operating status (such as running, stopped, fault), providing basic data support for the object model. Device events: identifying device alarm triggering conditions (such as overload, communication interruption, over-temperature) and associating event levels (such as emergency, warning, alert) to ensure timely response from the IoT platform and business system. Device methods: parsing the control commands supported by the device (such as start / stop, power adjustment, mode switching), clarifying the input parameter type (such as integer, floating-point) and execution constraints (such as mutual exclusion operations). Device indicators: quantifying the device's communication capabilities (such as data update frequency, transmission delay) and control response performance (such as command execution time, failure rate), providing a basis for resource scheduling.

[0047] In one embodiment of this application, during the hardware-level interception and parsing of Modbus TCP packets, the transaction ID (2 bytes), protocol identifier (2 bytes), and length field (2 bytes) are extracted first. Next, the function code (1 byte) is parsed; if it is 03 (read holding register), the register address (2 bytes) and data length (2 bytes) are extracted. Then, the hardware CRC check module verifies data integrity; erroneous frames are discarded and logged. Finally, data extraction is performed to obtain attributes (e.g., gas turbine register 40001 is parsed as "ActivePower" (unit: kW, value range 0-2000)), events (e.g., detecting changes in the "Overload" node status in the OPC UA event subscription and marking it as an emergency alarm), and methods (e.g., identifying "Start" and "Stop" control commands in the IEC 61850 MMS service and recording the parameter format).

[0048] In the embodiments of this application, the hardware acceleration capability of the FPGA chip enables the protocol parsing latency to be less than 1ms, supports concurrent processing of multiple devices, and improves performance by more than 50 times compared with the traditional CPU solution (latency > 50ms), fully meeting the stringent real-time requirements of smart power plants.

[0049] In the embodiments of this application, the specific process involved in the dynamic modeling module 142 dynamically generating a standardized physical model of the industrial equipment based on the corresponding data of the industrial equipment on site can be found in [reference needed]. Figure 3 .

[0050] Figure 3 An exemplary flowchart illustrating how this application embodiment dynamically generates a standardized physical model of an industrial equipment based on corresponding data from the industrial equipment in the field.

[0051] like Figure 3 As shown, in step S310, based on the corresponding data of the on-site industrial equipment extracted by the protocol identification and parsing module, a device feature vector containing interface, data, and control dimensions is constructed. In step S320, the feature vector is matched with each object model template in the pre-set object model template library using cosine similarity to determine whether there exists an object model template in the pre-set object model template library whose cosine similarity to the device feature vector is greater than the matching threshold. In response to the existence of an object model template in the pre-set object model template library whose cosine similarity to the feature vector is greater than the matching threshold, in step S330, the object model template corresponding to the maximum cosine similarity is used as the standardized object model. In response to the absence of an object model template in the pre-set object model template library whose cosine similarity to the feature vector is greater than the matching threshold, in step S340, a general template is enabled, and a standardized object model is generated based on the general template.

[0052] In the embodiments of this application, during step S310, feature extraction is performed to statistically analyze the protocol types supported by the industrial equipment in the field (e.g., Modbus, OPC UA) and the number of physical interfaces (physical interfaces include Ethernet x2, RS-485 x1, etc.), generating a 30-dimensional interface dimension. Next, the device data types are analyzed (e.g., Float32 accounts for 70%, Int16 accounts for 20%), and the mean and variance are calculated to generate a 50-dimensional data dimension vector. Then, the method parameter structure is evaluated (e.g., "power regulation" requires 3 floating-point parameters), generating a 48-dimensional control dimension vector.

[0053] In some embodiments of this application, in step S320, the 128-dimensional feature vector is compared with the object model template library such as IEC 61970 CIM using cosine similarity calculation, and the matching threshold is set to 85%. For example, a gas turbine is matched to the "GasTurbine_CIM" template with a similarity of 91%, and a standard object model containing "ActivePower", "Temperature", and "FaultCode" is automatically generated.

[0054] In the embodiments of this application, after obtaining the standardized object model, the dynamic modeling module 142 performs corresponding processing based on the confidence level of the attributes of the standardized object model.

[0055] Specifically, the detailed steps involved in the dynamic modeling module 142's processing based on the confidence level of the properties of the standardized object model can be found in [reference needed]. Figure 4 .

[0056] Figure 4 An exemplary flowchart illustrating the processing of confidence levels of properties based on a standardized object model according to an embodiment of this application is shown.

[0057] like Figure 4 As shown, in step S410, the confidence level of the attributes of the standardized object model is obtained. In step S420, it is determined whether the confidence level is less than a preset confidence threshold. In response to the confidence level not being less than the preset confidence threshold, in step S430, the attributes of the standardized object model are recorded to the object model knowledge base and stored in a static storage chip, and encapsulated in JSON format conforming to the IoT platform specifications. After being encrypted by a hardware-level security module, they are uploaded to the IoT platform via the second Ethernet interface. In response to the confidence level being less than the preset confidence threshold, in step S440, an alarm message is generated and pushed to the IoT platform for manual review, and the standardized object model is updated based on the manual review results.

[0058] In some embodiments of this application, the confidence threshold is set to 90%. When the confidence level is ≥90%, the attributes of the standardized object model are recorded in the object model knowledge base and stored in the static storage chip. If the confidence level is <90%, an alarm is generated and pushed to the IoT platform, where engineers confirm and update the model. For example: "WindingTemperature": 92%; "AmbientTemperature": 7%; "OilTemperature": 1%; "WindingTemperature" is automatically selected when the confidence level is ≥90% and recorded in the object model knowledge base. If the confidence level is <90% (e.g., "Pressure" is mapped to "InletPressure" and "OutletPressure" both at 75%), an alarm is generated and pushed to the IoT platform in real time, where engineers confirm and update the model. The engineer's review results serve as annotation data to gradually improve the model's accuracy.

[0059] In the embodiments of this application, the attributes of the standardized object models in the object model knowledge base are encapsulated in JSON format (conforming to the unified specification of the object model description format of the Internet of Things platform), which includes field names, data types, units, threshold ranges, etc.

[0060] In the embodiments of this application, the aforementioned FPGA chip 140 further includes an intelligent model difference alarm module, which is used to compare the differences between the standardized object model generated by the dynamic modeling module 142 and the historical object model in real time.

[0061] In the embodiments of this application, during the real-time comparison of the differences between the standardized object model generated by the dynamic modeling module and the historical object model, alarm information of corresponding levels is generated based on the type of difference between the standardized object model and the historical object model, and the generated alarm information is uploaded to the IoT platform through the second Ethernet interface. For example, if the standardized object model adds a field (such as "Vibration") compared to the historical object model, a low-level alarm is generated. If the standardized object model has a deleted key field (such as "Voltage") compared to the historical object model, a high-level alarm is generated, and device operation permissions are locked.

[0062] The intelligent model difference alarm module proactively pushes information about equipment model changes—a critical event—to maintenance personnel, significantly reducing the time required for fault detection and localization. Maintenance personnel no longer need to search for problems like looking for a needle in a haystack; instead, they can directly pinpoint the root cause based on precise alarm information (such as "the temperature control range parameter of a certain device has been modified"). This achieves a shift from passive response to proactive intervention, effectively ensuring production continuity and safety.

[0063] In the embodiments of this application, when the protocol identification and parsing module 141 fails to obtain the communication protocol type, the protocol dynamic loading module 143 performs the step of receiving and implementing the hardware parsing logic of the private protocol.

[0064] Specifically, the detailed process involved in the protocol dynamic loading module 143 executing the hardware parsing logic to receive and implement the private protocol can be found in [reference needed]. Figure 5 .

[0065] Figure 5 An exemplary flowchart illustrating the hardware parsing logic for receiving and implementing a proprietary protocol according to an embodiment of this application is shown.

[0066] like Figure 5 As shown, in step S510, the client tool receives a JSON-formatted configuration file imported by the user to define a private protocol. This configuration file defines the structure, field parsing rules, and exception handling strategy of the private protocol. In step S520, a static region and a dynamic reconfiguration region are pre-divided in the FPGA chip, and the configuration file is transmitted to the reconfiguration cache within the dynamic reconfiguration region via the PCIe interface. In step S530, a parser is invoked to convert the configuration file into an intermediate representation to extract the protocol structure, data field definitions, and processing logic, including reconfiguration control logic. In step S540, a hardware parsing circuit is generated based on the intermediate representation.

[0067] In the embodiments of this application, the user imports a private protocol configuration file in JSON format through a client tool. This file defines the protocol structure (such as Modbus function code, OPC UA node ID), field parsing rules (such as data length, verification algorithm), and exception handling strategies (such as reconfiguration control logic).

[0068] In the embodiments of this application, during the FPGA chip design phase, static regions (such as control logic and communication interfaces) and dynamic reconfiguration regions (such as protocol parsing) are pre-divided. User-uploaded rule files are transmitted via the PCIe interface to the reconfiguration cache within the dynamic reconfiguration region (independent reconfiguration cache regions are allocated for different protocols, supporting simultaneous operation of protocols such as Modbus and OPCUA). The parser is first called to convert the rule file into an intermediate representation (IR), extracting the protocol structure, data field definitions, and processing logic.

[0069] In the embodiments of this application, the specific process involved in generating the hardware parsing circuit based on the intermediate representation can be found in [reference needed]. Figure 6 .

[0070] Figure 6An exemplary flowchart of the hardware parsing circuit based on intermediate representation generation according to an embodiment of this application is shown.

[0071] like Figure 6 As shown, in step S610, the clock signals of the logic units related to the dynamic reconfiguration region are paused by the reconfiguration control logic. In step S620, the configuration file corresponding to the intermediate representation is written from the reconfiguration cache to the configuration memory of the FPGA chip by the reconfiguration control logic to update the configuration and routing information of the logic units and generate the hardware parsing circuit corresponding to the private protocol. In step S630, the clock signals of the logic units are restored, causing the generated hardware parsing circuit to start running.

[0072] In the embodiments of this application, the reconfiguration control logic pauses the clock signals of the logic units associated with the region to be reconfigured, ensuring that these logic units are in a stable state and will not generate erroneous outputs during the configuration process. The reconfiguration control logic writes the new configuration data from the reconfiguration cache to the corresponding configuration memory area in a predetermined order and manner, updating the configuration information and wiring information of the logic units. After the configuration data update is complete, the reconfiguration control logic restores the clock signals of the relevant logic units, enabling these logic units to start operating according to the new configuration.

[0073] In the embodiments of this application, the generated hardware parsing circuit (such as state machine, data buffer) does not require re-burning firmware, and the adaptation cycle is shortened from several weeks to minutes.

[0074] In the embodiments of this application, the aforementioned hardware-level security module 144 includes an encryption unit and a secure storage unit.

[0075] Specifically, the encryption unit has a built-in root key to establish an encrypted communication channel, preventing information from being tampered with or destroyed during transmission. By embedding an immutable root key in the hardware, it establishes a hardware root of trust. All external data transmissions are hardware-accelerated and encrypted via this dedicated encryption unit, ensuring the confidentiality and integrity of the communication link. This method fundamentally eliminates the risk of the key being stolen or replaced in memory, providing security for data transmission.

[0076] Specifically, the secure storage unit is used to divide the SRAM inside the FPGA chip into a primary partition and a backup partition, and to perform simultaneous write operations on the primary partition and the backup partition for preset critical data.

[0077] In the embodiments of this application, the object model FPGA chip adopts "data mirroring" technology, which retains more than two backups of critical data within the chip. The chip logically divides the SRAM into a primary partition and a backup partition. All write operations on critical data are performed simultaneously in both partitions. When both partitions are normal, data can be read from either partition. If one partition fails, data can still be read from the other partition.

[0078] Hardware-level real-time redundancy backup is implemented in the SRAM inside the chip. Core data such as object models and critical configurations are written synchronously to the primary and backup physical partitions. This means that even if data in a certain storage area inside the chip is corrupted due to instantaneous high-energy particles, hardware failures, or even physical attacks, the data in the backup partition can ensure that the system state is not lost and services are not interrupted, achieving the highest level of data high availability.

[0079] In the embodiments of this application, the host status monitoring module 145 collects performance indicators and abnormal event data to ensure stable system operation and timely detection of potential problems. It periodically collects the following information from the host device: Hardware information: including CPU model, memory size, storage device details, etc. Device communication interface information: all network interfaces of the device and their status. MAC address: the physical address of the network interface, used to uniquely identify the device in the network. IP address: the logical address of the device in the network, used for network communication. Memory usage: current memory usage, used to assess system memory pressure. Storage usage: storage device usage, used to assess storage space adequacy. CPU utilization: CPU usage, used to assess processing power pressure. Last boot time: records the time of the device's last startup. Current time: the device's current system time. Threshold alarms: thresholds can be set for key performance indicators (such as memory usage, storage utilization, CPU utilization, etc.). When these indicators exceed the preset thresholds, the monitoring software module will generate real-time alarms. Alarm Upload: Generated alarm information is uploaded to the control loop, enabling system administrators or other monitoring systems to respond promptly and take necessary maintenance measures. Control Loop Integration: The propagation of alarm information within the control loop ensures that the smart power plant's business systems can quickly respond to potential hardware problems or performance bottlenecks, thereby reducing downtime and improving overall reliability. Security: The monitoring module also needs to ensure the security of collected data, prevent the leakage of sensitive information, and ensure that the monitoring process itself does not become a weakness in system security.

[0080] Through the host status monitoring module 145, the power plant can gain in-depth insights and real-time monitoring of key control systems, improve system transparency and controllability, and ensure efficient and safe operation of the power plant.

[0081] In the embodiments of this application, the physical card driver module 146 provides operating system driver software to ensure that the physical card can correctly interact with the host PC-like device or host computer. The driver includes the following functions: Hardware recognition: The driver software enables the operating system to recognize the physical card hardware, allowing the system to know the physical card's existence and communicate with it correctly. Interface standardization: The driver software provides standardized interfaces, enabling applications to exchange data with the physical card through these interfaces. Performance optimization: The driver software can optimize the physical card's performance, ensuring high-speed and stable data transmission. Error handling: The driver software can handle hardware errors and exceptions, ensuring stable system operation. Compatibility guarantee: The driver software ensures that the physical card is compatible with different versions of operating systems, such as Windows and Linux. Bridge between user space and kernel space: The driver software acts as a bridge between user space and kernel space, enabling applications to securely access hardware resources. Logging: The driver software can record operation logs for easy problem diagnosis and performance monitoring. Updates and maintenance: The driver software needs to be updated regularly to support new operating system versions or fix known issues.

[0082] The host status monitoring module 145 not only provides a communication bridge between the hardware and the operating system, but also ensures the high performance and security of the physical card.

[0083] In embodiments of this application, the FPGA chip 140 further includes a control instruction execution module.

[0084] In the embodiments of this application, the control command execution module processes the standardized control commands received from the Internet of Things platform for the corresponding field industrial equipment.

[0085] Specifically, the detailed process for processing standardized control commands received from the IoT platform for corresponding field industrial equipment can be found in [reference needed]. Figure 7 .

[0086] Figure 7 An exemplary flowchart illustrating how this application embodiment processes standardized control commands received from an IoT platform for corresponding field industrial equipment is shown.

[0087] like Figure 7As shown, in step S710, standardized control commands for the corresponding field industrial equipment are received from the IoT platform. This is achieved by the business system calling and converting the object model of the IoT platform via API to obtain the standardized control commands. In step S720, the support of the corresponding field industrial equipment for the standardized control commands is verified to determine whether the equipment supports them. If the corresponding field industrial equipment does not support the standardized control commands, in step S730, the issuance of the standardized control commands is stopped, and an error code is returned to the IoT platform, triggering an alarm. If the corresponding field industrial equipment supports the standardized control commands, in step S740, the standardized control commands are converted into command messages in the communication protocol format corresponding to the corresponding field industrial equipment, and the command messages are sent to the corresponding field industrial equipment through the first Ethernet interface. Next, in step S750, the execution status and results of the corresponding field industrial equipment in response to the command messages are monitored in real time, and the execution status and results are fed back to the IoT platform through the second Ethernet interface.

[0088] In the embodiments of this application, the business system calls the object model API of the IoT platform (such as "SetPower (1500kW)"). The IoT platform then converts the API call into a standard command and sends it to the control command execution module. The control command execution module first verifies the actual support of the device. If the device does not support the "SetPower" method, it returns the error code "API_NOT_SUPPORTED" and triggers an alarm. The control command execution module then converts the standardized command into the device protocol (such as Modbus function code 06 written to register 40001) and sends it to the device via Ethernet. The control command execution module monitors the device's execution of the command in real time and feeds back to the IoT platform.

[0089] The control command execution module first determines whether the current device supports the operation. This mechanism effectively intercepts any invalid or unauthorized control commands, avoiding the risk of abnormal device operation due to misoperation or platform vulnerabilities, and providing a solid guarantee for safe production in the physical world. After the command is issued, the module tracks the execution status and final result of the command in real time and feeds this complete process back to the IoT platform. This closed-loop management of "issuance-execution-feedback" not only ensures the accuracy and reliability of control, but also provides a clear and complete data chain for subsequent auditing, traceability, and optimization.

[0090] In summary, through the FPGA-based industrial IoT object model card provided above, this embodiment of the application utilizes the parallel processing capabilities of FPGA to accelerate the parsing of complex industrial protocols, achieving microsecond-level real-time data acquisition and command issuance, thus overcoming the performance bottleneck of traditional software gateways. Through dynamic protocol loading and automatic object model generation, it significantly enhances the ability to quickly adapt to and plug-and-play a massive number of heterogeneous devices, especially those with proprietary protocols. Simultaneously, it embeds security mechanisms such as data encryption and redundancy backup at the hardware level, providing chip-level security protection, effectively resisting network and physical attacks, and independently monitoring host status, ensuring end-to-end reliability and business continuity of the entire data link.

[0091] Furthermore, in some embodiments, by completely embedding the protocol identification and data verification process into the FPGA hardware circuit, the performance bottlenecks and uncertainties of traditional software parsing methods are fundamentally solved. It innovatively maps the Random Forest intelligent identification algorithm directly to hardware logic, leveraging the parallel characteristics of the FPGA to instantly determine the protocol type based on key features in the message header within nanoseconds, achieving a leap from software judgment to hardware intuition. Before formally parsing the data, it uses a dedicated hardware CRC check module to perform integrity verification on each frame of data, enabling the immediate discarding of any erroneous or corrupted data frames at the hardware level. This hardened pipeline operation of identification, verification, and parsing not only ensures that the subsequently processed data is 100% valid, avoiding resource waste, but also compresses the latency of the entire protocol processing process to the physical limit, providing a solid foundation for the real-time performance and reliability of upper-layer applications.

[0092] Furthermore, in some embodiments, through innovative feature vector and cosine similarity matching algorithms, the object model card can analyze the data interface and behavioral characteristics of new devices upon their access, and intelligently match the most suitable object model from the template library. Even for unknown devices, it can use a universal template for guaranteed adaptation, greatly reducing the threshold and debugging cycle for new device access. Simultaneously, through confidence verification, the system automatically adds high-confidence, successfully matched models to the knowledge base. For low-confidence fuzzy matches, it proactively triggers manual review alerts, introducing expert knowledge for correction. This closed-loop mechanism of machine decision-making and human supervision ensures that object models are not only generated quickly but also accurately, and become increasingly intelligent and precise over time with human intervention.

[0093] Furthermore, in some embodiments, the ability to parse entirely new proprietary protocols is dynamically injected into the FPGA during device operation, completely breaking the limitations of traditional fixed hardware logic. When encountering unrecognized proprietary protocols, the system is no longer helpless but allows users to teach the hardware how to parse them through a simple JSON configuration file. This enables the physical model card to infinitely expand its protocol library, easily handling the ever-increasing number of non-standard devices in industrial environments. This process completely shields the user from the complexity of protocol adaptation. Users only need to provide a high-level JSON definition file, and the system can automatically parse, convert, and dynamically generate a dedicated, high-performance hardware parsing circuit. This achieves a shift from software plug-in to native hardware support, ensuring that newly added proprietary protocols can also enjoy the same microsecond-level hardware acceleration performance as other protocols.

[0094] While numerous embodiments of this application have been shown and described herein, it will be apparent to those skilled in the art that such embodiments are provided by way of example only. Many modifications, alterations, and alternatives will arise for those skilled in the art without departing from the spirit and intent of this application. It should be understood that various alternatives to the embodiments of this application described herein may be employed in the practice of this application. The appended claims are intended to define the scope of protection of this application and therefore cover equivalents or alternatives within the scope of these claims.

Claims

1. An industrial IoT object model card based on FPGA technology, characterized in that, include: The PCIe interface is used for interconnection between the physical model card and the host computer or host PC of the power generation enterprise's business system. The first Ethernet interface is used to connect field industrial equipment; The second Ethernet interface is used to connect to the IoT platform; FPGA chips, used to implement hardware acceleration, include: The protocol identification and parsing module is used to process network packets in real time to obtain communication protocol types and corresponding data of on-site industrial equipment; The dynamic modeling module is used to dynamically generate standardized physical models of industrial equipment based on relevant data from the equipment on site. The protocol dynamic loading module is used to receive and implement the hardware parsing logic of the private protocol during FPGA chip runtime; Hardware-level security modules are used to provide encrypted communication for data transmission and redundant backup of internal data; The host status monitoring module is used to monitor the operating status indicators of the host PC and generate alarms; and The physical card driver module is used for the host computer or the host PC to identify and interact with the physical card.

2. The industrial IoT object model card based on FPGA technology according to claim 1, characterized in that, The protocol identification and parsing module includes: The protocol compatibility identification unit extracts key header fields from network packets via hardware, identifies the protocol identifier, data frame type, and field structure features. It then uses a lightweight random forest algorithm, which directly maps the decision tree structure to the FPGA chip, to determine the communication protocol type in parallel processing based on the real-time extracted protocol identifier, data frame type, and field structure features. The multi-protocol parsing unit, based on the judgment result of the protocol compatibility identification unit, performs real-time interception and parsing of protocol data streams from the industrial field network.

3. The industrial IoT object model card based on FPGA technology according to claim 2, characterized in that, The following steps are performed during the real-time capture and parsing of protocol data streams from industrial field networks: The protocol data stream from the industrial field network is captured in real time to obtain protocol data frames; A hardware CRC check module is used to verify the intercepted protocol data frame and determine whether it is an erroneous frame. If the intercepted protocol data frame is found to be an erroneous frame, the protocol data frame will be discarded and logged. If the intercepted protocol data frame is not an error frame, the protocol data frame is parsed to obtain the corresponding data of the field industrial equipment.

4. The industrial IoT object model card based on FPGA technology according to claim 1, characterized in that, In the process of dynamically generating a standardized physical model of the industrial equipment based on the corresponding data from the industrial equipment on site, the dynamic modeling module performs the following steps: Based on the corresponding data of the field industrial equipment extracted by the protocol identification and parsing module, a device feature vector containing interface dimension, data dimension and control dimension is constructed; The feature vector is matched with each object model template in the pre-built object model template library using cosine similarity. Determine whether there exists an object model template in the pre-set object model template library whose cosine similarity to the feature vector is greater than the matching threshold; In response to the existence of a pre-built object model template library with a cosine similarity greater than the matching threshold with the feature vector, the object model template with the maximum cosine similarity is taken as the standardized object model. In response to the absence of a pre-built object model template in the object model template library with a cosine similarity greater than the matching threshold with the feature vector, a general template is enabled, and a standardized object model is generated based on the general template.

5. The industrial IoT object model card based on FPGA technology according to claim 1 or 4, characterized in that, After obtaining the standardized object model, the dynamic modeling module performs the following steps: Obtain the confidence level of the properties of the standardized object model; Determine if the confidence level is less than a preset confidence threshold; In response to a confidence level not less than a preset confidence threshold, the attributes of the standardized object model are recorded in the object model knowledge base and stored in a static storage chip, and encapsulated in JSON format conforming to the IoT platform specifications. After being encrypted by the hardware-level security module, the data is uploaded to the IoT platform via the second Ethernet interface. In response to a confidence level lower than a preset confidence threshold, an alarm message is generated and pushed to the IoT platform for manual review, and the standardized object model is updated based on the results of the manual review.

6. The industrial IoT object model card based on FPGA technology according to claim 1 or 4, characterized in that, The FPGA chip also includes an intelligent model difference alarm module, which is used to compare the differences between the standardized object model generated by the dynamic modeling module and the historical object model in real time. During the real-time comparison of the differences between the standardized object model and the historical object model generated by the dynamic modeling module, alarm information of corresponding levels is generated based on the difference type between the standardized object model and the historical object model, and the generated alarm information is uploaded to the Internet of Things platform through the second Ethernet interface.

7. The industrial IoT object model card based on FPGA technology according to claim 1, characterized in that, When the protocol identification and parsing module fails to obtain the communication protocol type, the protocol dynamic loading module performs the following steps: The client tool receives a JSON-formatted configuration file imported by the user to define a private protocol. The configuration file defines the structure, field parsing rules, and exception handling strategy of the private protocol. In the FPGA chip, a static region and a dynamic reconfiguration region are pre-divided, and the configuration file is transmitted to the reconfiguration cache in the dynamic reconfiguration region through the PCIE interface; The parser is invoked to convert the configuration file into an intermediate representation to extract the protocol structure, data field definitions, and processing logic, including reconfiguration control logic. The hardware parsing circuit is generated based on the intermediate representation.

8. The industrial IoT object model card based on FPGA technology according to claim 7, characterized in that, In the process of generating the hardware parsing circuit based on the intermediate representation, the following steps are performed: The clock signals of the logic units associated with the dynamic reconfiguration region are paused by the reconfiguration control logic. The reconfiguration control logic writes the configuration file corresponding to the intermediate representation from the reconfiguration cache to the configuration memory of the FPGA chip to update the configuration and routing information of the logic unit and generate a hardware parsing circuit corresponding to the private protocol. Restore the clock signal of the logic unit to enable the generated hardware parsing circuit to start running.

9. The industrial IoT object model card based on FPGA technology according to claim 1, characterized in that, The hardware-level security module includes an encryption unit and a secure storage unit; The encryption unit has a built-in root key to establish an encrypted communication channel; The secure storage unit is used to divide the SRAM inside the FPGA chip into a primary partition and a backup partition, and to perform simultaneous write operations on the primary partition and the backup partition for preset key data.

10. The industrial IoT object model card based on FPGA technology according to claim 1, characterized in that, The FPGA chip also includes a control instruction execution module, which performs the following steps: The system receives standardized control commands for corresponding industrial equipment on-site from the IoT platform, wherein the standardized control commands are obtained by API calls and conversion of the object model of the IoT platform through the business system. Verify the support of the corresponding field industrial equipment for the standardized control commands, and determine whether the corresponding field industrial equipment supports the standardized control commands; In response to the corresponding on-site industrial equipment not supporting the standardized control commands, the issuance of standardized control commands is stopped, and an error code is returned to the IoT platform and an alarm is triggered. In response to the support of the standardized control commands by the corresponding field industrial equipment, the standardized control commands are converted into command messages in the communication protocol format corresponding to the corresponding field industrial equipment, and the command messages are sent to the corresponding field industrial equipment through the first Ethernet interface; The system monitors the execution status and results of the command messages by the corresponding industrial equipment in the field in real time, and feeds back the execution status and results to the IoT platform through the second Ethernet interface.

Images