An industrial control protocol unified semantic model construction method

Abstract

The application discloses a kind of industrial control protocol uniform semantic model construction methods, it is related to industrial communication and industry control safety technical field, including the following steps: S1 multi-source industrial control protocol sample collection and native feature analysis;S2 constructs industrial control behavior uniform semantic meta-model;S3 establishes cross-protocol control behavior uniform mapping model;S4 executes uniform event standardization processing based on protocol difference elimination;S5 builds data storage and risk analysis framework based on uniform semantics;S6 realizes the semantic model extension mechanism of plug-in.This application, shield the format difference of heterogeneous protocol, realize the cross-protocol uniform expression and lossless conversion of control behavior and event data;Support protocol-independent uniform risk research and whole-link traceability;Significantly reduce the access cost of new protocol and system adaptation difficulty, provide general, high compatible semantic base for the multi-protocol uniform management, monitoring and safety analysis of industrial control scene.

Description

Technical Field

[0001] This invention relates to the fields of industrial communication and industrial control security technology, specifically a method for constructing a unified semantic model for industrial control protocols. Background Technology

[0002] Industrial control systems often feature a coexistence of multiple heterogeneous protocols such as IEC104, Modbus, and MMS. These protocols differ significantly in message format, command definition, event coding, and interaction logic. This results in the need for industrial control monitoring, security analysis, and equipment management systems to develop independent adaptation modules for each protocol, leading to problems such as high development costs, data incompatibility, fragmented analytical capabilities, and difficulty in expansion.

[0003] Existing technologies mostly focus on parsing and standardizing single protocols, or only implement simple field-level format conversion, failing to achieve unified abstraction across protocols from the behavioral semantic level. At the same time, existing solutions generally use static rule mapping, which cannot solve the ambiguity problem of multiple semantics for the same instruction, and lack unified access control and business process-level anomaly detection capabilities across protocols, making it difficult to cope with the security and management needs of complex industrial control scenarios. Summary of the Invention

[0004] To address the shortcomings of existing technologies, this invention provides a method for constructing a unified semantic model for industrial control protocols, which solves the problems mentioned in the background section.

[0005] To achieve the above objectives, the present invention provides the following technical solution: a method for constructing a unified semantic model for industrial control protocols, comprising the following steps:

[0006] S1. Multi-source industrial control protocol sample collection and native feature analysis: Collect standard specifications, field messages and interaction log samples of three types of industrial control protocols: IEC104, Modbus and MMS. Analyze the application layer data unit structure of each protocol and extract three core features: control behavior, data object and event type to build a native protocol feature library.

[0007] S2. Construct a unified semantic meta-model for industrial control behavior: Define the general semantic description dimension, divide the semantic domain of industrial control behavior, define standardized semantic predicates and attribute constraints, and construct a unified behavioral semantic meta-language system decoupled from specific protocol formats;

[0008] S3. Establish a unified mapping model for cross-protocol control behavior: Establish a bidirectional mapping rule base between native protocol instructions and unified semantic predicates, construct a semantic conversion intermediate layer, and realize bidirectional lossless conversion between native protocol instructions and unified semantic instructions;

[0009] S4. Perform unified event standardization processing based on protocol difference elimination: Identify structural, semantic, and format heterogeneous differences between cross-protocol events, define a unified event standardization model, and convert native events of different protocols into standard format events through the difference elimination engine;

[0010] S5. Establish a data storage and risk analysis framework based on unified semantics: Construct a semantic hierarchical storage architecture, build a general risk analysis engine based on a unified semantic model, and output risk status and traceability capabilities in a unified semantic dimension;

[0011] S6. Implement a plug-in-based semantic model extension mechanism: Define standardized plug-in interface specifications, build a plug-in registration and management center, support dynamic loading and hot updates of new protocol plug-ins, and realize scalable access to the semantic model.

[0012] Furthermore, in step S1, a finite state machine combined with a protocol field parsing engine is used to achieve frame-by-frame deep parsing, and core features are extracted for three types of protocols:

[0013] For the Modbus TCP protocol, we parse the transaction identifier, function code, register address and data value, and sort out the read / write and single-point / batch behavior patterns;

[0014] For the IEC104 protocol, we analyzed the APCI control domain, ASDU type identifier, transmission reason and information body address, and sorted out the timing sequence of general call, telemetry, telesignaling and remote control interaction.

[0015] For the MMS protocol, we parse the service primitives, call IDs, object names and variable lists, and sort out the service logic of reading, writing, file transfer and event reporting.

[0016] The native protocol feature library is stored in a structured manner according to three categories: control behavior set, data object set, and event type set, and the field specifications are defined using JSON Schema.

[0017] Furthermore, in step S2, the unified semantic meta-model is formally expressed using a seven-tuple, as shown in the following formula:

[0018]

[0019] in, As an action type, the enumeration includes six basic actions: read, write, control, configuration, alarm, and keep-alive. The operating entity includes device type, device identifier, and permission level attributes; For the objects being operated on, this includes object classification, global unified addressing, and data type attributes; These are operation parameters, including parameter name, data type, value range, and unit attribute; To ensure proper execution timing, linear sequential logic is used to describe the interaction sequence and time constraints. The returned result includes the execution status, returned data value, and status code attributes; For abnormal states, the exception type, exception code, triggering conditions, and handling strategy attributes are included.

[0020] The semantic domain is divided into five categories: data acquisition domain, instruction control domain, parameter configuration domain, event alarm domain, and connection keep-alive domain. Each semantic domain defines atomic semantic predicates, and complex behaviors are composed of combinations of multiple atomic predicates.

[0021] Furthermore, in step S3, the bidirectional mapping rule base covers three types of mapping modes: one-to-one, one-to-many, and many-to-one. Each mapping rule includes a rule ID, source protocol identifier, native instruction identifier, target semantic predicate, preconditions, parameter conversion formula, and reverse mapping logic.

[0022] The semantic conversion intermediate layer has a built-in address space normalization module, a data type conversion module and a timing logic alignment module. The address space normalization module converts the native addressing methods of each protocol into a three-level global addressing format of "device unique ID + object classification code + instance number".

[0023] Step S3 also includes mapping integrity and accuracy verification. The mapping is verified to be lossless through bidirectional conversion consistency verification, and rule correction is triggered when the error exceeds the threshold.

[0024] Furthermore, in step S4, the unified event standardization model is formally expressed using an octet, as shown in the following formula:

[0025]

[0026]

[0027] in, A globally unique event identifier, generated using the snowflake algorithm; For event semantic types, reuse the event alert domain semantic predicate; They are uniformly divided into five levels: Emergency, Important, General, Warning, and Notice. UTC millisecond-level Unix timestamps; This includes the device identifier and address information of the event source; Provide semantic event description text; For structured event payloads; This is the associated event ID, used for event tracing and correlation analysis;

[0028] The difference elimination engine has built-in level mapping unit, time normalization unit, field alignment unit and encoding conversion unit, which respectively handle heterogeneous differences in event level, time format, field structure and encoding method.

[0029] Furthermore, in step S6, the standardized plug-in interface includes three types: protocol parsing interface, semantic mapping interface, and event conversion interface. The core semantic engine interacts with the plug-in through the standard interface without being aware of the specific protocol implementation details.

[0030] The plugin registration and management center supports plugin registration verification, dynamic loading, sandbox isolation and version management. An abnormality in a single plugin will not affect the operation of the core engine.

[0031] When adding a new industrial protocol, implement the three types of interfaces according to the template and fill in the mapping rules to access the unified semantic system.

[0032] Furthermore, the following steps are also included:

[0033] S7 semantic-level globally unified access control and command security circuit breaker steps are deployed in the semantic translation middleware layer, specifically including:

[0034] S71: Define global permission rules based on three dimensions: operation subject, semantic predicate, and operation object, and construct a three-dimensional permission matrix. The permission determination function formula is as follows:

[0035]

[0036] in, For identifying the operating entity; For semantic predicate actions; Identify the object being operated on;

[0037] S72: Set up dual verification points in the semantic conversion intermediate layer: perform the first permission verification after the native instruction is converted into unified semantics, and perform the second permission verification before the unified semantics is converted into native instructions and issued.

[0038] S73: When the permission determination function outputs a certain value, the semantic level circuit breaker mechanism is triggered, directly intercepting the instruction at the semantic layer without performing protocol conversion and forwarding downward, and generating a standardized unauthorized access alarm event.

[0039] Furthermore, the following steps are also included:

[0040] The S8 semantic sequence-driven cross-protocol business process logic anomaly detection steps are integrated into the risk analysis framework and specifically include:

[0041] S81: Based on a unified semantic predicate system, semantic-level modeling is performed on typical business processes of industrial control, defining legal action sequences, timing constraints, object dependencies and permission preconditions, and building a standard process baseline library.

[0042] S82: Employs a sliding window mechanism to segment and extract real-time semantic streams, and uses a prefix matching algorithm to identify the currently executing business process segment;

[0043] S83: Based on the causal reasoning mechanism, verify whether the action logic, object association and temporal relationship of the semantic sequence conform to the baseline, identify abnormal sequences that deviate from the business logic, and generate process-level abnormal alarms.

[0044] Furthermore, in step S83, an anomaly calculation method that fuses sequence edit distance and causal constraints is adopted. The anomaly calculation formula is as follows:

[0045]

[0046]

[0047] in, For real-time semantic sequences; The matched standard baseline sequence; The edit distance between the two sequences; Baseline sequence length; It is a set of causal constraint rules; This represents the number of times a real-time sequence violates causality constraints. For sequence difference weights, To constrain violations of weights, and satisfy When the anomaly score exceeds the set threshold, it is determined to be an anomaly in the business process logic.

[0048] This invention provides a method for constructing a unified semantic model for industrial control protocols, which has the following beneficial effects:

[0049] 1. This unified semantic model construction method for industrial control protocols completely shields the format differences of heterogeneous protocols from the behavioral semantic level by constructing a unified behavioral semantic meta-model and bidirectional mapping mechanism for IEC104, Modbus, and MMS, achieving cross-protocol unified expression and lossless conversion of control behavior and event data. Combined with event standardization methods to eliminate protocol differences, semantic layered storage, and a risk analysis framework, it breaks down data barriers between multiple protocols, supporting protocol-independent unified risk assessment and end-to-end traceability. Furthermore, the plug-in scalable architecture significantly reduces the access cost of new protocols and the difficulty of system adaptation, providing a universal and highly compatible semantic foundation for unified management, monitoring, and security analysis of multiple protocols in industrial control scenarios.

[0050] 2. This unified semantic model construction method for industrial control protocols features semantic-level global access control and cross-protocol business process anomaly detection mechanisms. It further extends security protection capabilities based on a unified semantic foundation: the former addresses the issue of access silos in multi-protocol scenarios through a three-dimensional access control matrix of "operating subject-semantic predicate-operating object" and a dual-verification point semantic circuit breaker mechanism, achieving fine-grained cross-protocol instruction security control; the latter, based on semantic sequence baseline modeling and an anomaly degree algorithm that integrates edit distance and causal constraints, overcomes the limitations of traditional single-instruction anomaly detection, identifying business logic attacks formed by combinations of single legitimate instructions, significantly improving the depth, breadth, and accuracy of risk detection in industrial control systems. Attached Figure Description

[0051] Figure 1 This is a flowchart illustrating steps S1-S6 of the method for constructing a unified semantic model for industrial control protocols according to the present invention. Detailed Implementation

[0052] The embodiments of the present invention will be described in further detail below with reference to the accompanying drawings and examples. The following examples are for illustrative purposes only and should not be construed as limiting the scope of the invention.

[0053] like Figure 1 As shown, the present invention provides a technical solution: a method for constructing a unified semantic model for industrial control protocols, comprising the following implementation steps:

[0054] Implementation Step S1: Multi-source Industrial Control Protocol Sample Acquisition and Native Feature Analysis

[0055] This step is a prerequisite for building the entire semantic model, completing the full feature decomposition and structured storage of the target protocol. The specific implementation process is as follows:

[0056] 1. Multi-dimensional protocol sample collection

[0057] A complete sample set is constructed from three types of data sources: First, standard specification sources, including official standard texts of IEC 60870-5-104, Modbus TCP, and IEC 61850 MMS, from which baseline information such as protocol format definitions, service primitives, and interaction processes are extracted; second, field message sources, which collect real interaction messages from power, manufacturing, and other scenarios through industrial switch port mirroring and industrial control gateway bypass deployment, covering three types of scenarios: normal business, abnormal alarms, and fault interactions; and third, simulation generation sources, which construct boundary scenario messages based on industrial control protocol simulation tools, including ultra-long frames, abnormal function codes, non-standard addresses, and malformed messages, to improve the robustness of the model.

[0058] After data collection, preprocessing is performed: data cleaning is completed through message deduplication, time sequence alignment, and invalid frame filtering. The data is then categorized by protocol type, device type, and business scenario to construct a fully labeled protocol sample set.

[0059] 2. Structured analysis of protocol native features

[0060] A frame-by-frame deep parsing architecture is implemented using a finite state machine (FSM) and a protocol field parsing engine. For each protocol, predefined state machine transition rules are used to parse the application layer data unit bit by bit, byte by byte, to identify all fields of information such as the message header, function code / ASDU type, address field, data field, and check field.

[0061] The core features of targeted protocol resolution for three types of targets:

[0062] Modbus TCP: Parses transaction identifiers, protocol identifiers, length fields, unit identifiers, function codes, register addresses, register counts, and data values; identifies behavioral patterns such as read, write, single-point, and batch processing; and records the exception types corresponding to exception codes.

[0063] IEC104: Analyze the APCI control field (start character, length, control field) and ASDU structure (type identifier, variable structure qualifier, transmission reason, common address, information body address, information body element), sort out the interaction sequence of general call, telemetry, tele-signaling, remote control, time synchronization, etc., and record the event types corresponding to different transmission reasons;

[0064] MMS: Parses service primitive types (confirmed / unconfirmed), call ID, object naming path, variable list, and service result code, and sorts out service logic such as variable reading and writing, file transfer, event reporting, and control commands.

[0065] 3. Construction of the native protocol feature library

[0066] A structured feature library is built based on three dimensions: control behavior, data object, and event type. JSON Schema is used to define the field specifications for each dimension.

[0067] Control behavior set: Stores the unique identifier of the behavior, its protocol, triggering conditions, interaction sequence, request / response format, and exception return code;

[0068] Data object collection: stores object type, addressing mode, data type, value range, and physical quantity mapping relationship;

[0069] Event type collection: Stores event triggering rules, level definitions, field structures, and reporting mechanisms.

[0070] The feature library supports incremental updates, providing a standardized input source for subsequent semantic abstraction.

[0071] Implementation step S2: Construct a unified semantic meta-model for industrial control behavior

[0072] This step implements a protocol-independent behavioral semantic standardization definition, and the specific implementation process is as follows:

[0073] 1. Formal Definition of Semantic Metamodel

[0074] The unified behavioral semantic unit is formally expressed using a seven-tuple, as shown in the following formula:

[0075]

[0076] The attribute domains and constraint rules for each tuple element are defined as follows:

[0077] As an action type, the enumeration includes six basic actions: read, write, control, configuration, alarm, and keep-alive. It supports sub-action extensions, and each sub-action corresponds to an atomic semantic predicate.

[0078] As the operating entity, it describes the initiator of the command, including device type, device identifier, and permission level attributes, and is used for permission verification and traceability;

[0079] As the operation object, it describes the object being operated on and includes three attributes: object classification (analog quantity, digital quantity, parameter item, file, etc.), global unified addressing, and data type. It is the core carrier of address space normalization.

[0080] For operation parameters, describe the input parameters of the operation, including four attributes: parameter name, data type, value range, and unit, and support multiple parameter combinations;

[0081] To execute the timing sequence, linear timing logic (LTL) is used to describe the interaction sequence and time constraints. For example, the standard remote control timing sequence is described as "request → confirmation → execution → return", while defining the time threshold for each step.

[0082] To return a result, describe the operation execution result, including three attributes: success / failure status (execution status), returned data value, and standard status code;

[0083] For abnormal states, describe the abnormal scenario, including four attributes: abnormal type, abnormal code, triggering condition, and handling strategy.

[0084] 2. Semantic domain partitioning and semantic predicate system construction

[0085] Based on the general functional logic of industrial control scenarios, all protocol behaviors are divided into 5 semantic domains. Standardized atomic semantic predicates are defined under each semantic domain, forming a meta-language system that is independent of protocols:

[0086] Data acquisition domain: includes predicates such as single-point telemetry reading, batch telemetry reading, total call acquisition, and switch status reading;

[0087] Command control domain: includes predicates such as single-point remote control, batch remote control, setpoint setting, and equipment start / stop control;

[0088] Parameter configuration field: contains predicates such as parameter reading, parameter modification, parameter download, and configuration synchronization;

[0089] Event alarm domain: includes predicates such as status change alarm, limit overrun alarm, fault alarm, and equipment abnormality alarm;

[0090] Connection keep-alive domain: includes predicates such as link establishment, link testing, heartbeat keep-alive, and link disconnection.

[0091] Semantic predicates follow the principle of minimum granularity, with each predicate corresponding to a single atomic operation; complex business behaviors are composed of multiple atomic predicates combined in sequence, ensuring the flexibility and accuracy of semantic expression.

[0092] 3. Metamodel Constraints and Inference Rule Design

[0093] Define two types of semantic constraint rules to ensure semantic consistency:

[0094] Static constraints include object-action matching constraints (e.g., switch objects only support reading and control actions, but do not support analog writing), parameter validity constraints, and data type matching constraints.

[0095] Temporal constraints: Define standard interaction timing for different semantic domains and prohibit the generation of semantic instances with reversed timing.

[0096] It also incorporates basic semantic reasoning rules, supporting the derivation of implicit semantics based on known semantic units. For example, it can derive the semantics of "link communication anomaly" from "multiple consecutive batch read failures", providing a reasoning basis for subsequent risk analysis.

[0097] Implementation step S3: Establish a unified mapping model for cross-protocol control behavior

[0098] This step enables bidirectional conversion between native protocol behavior and unified semantics. The specific implementation process is as follows:

[0099] 1. Construction of a bidirectional mapping rule base

[0100] The mapping relationship is established by using a combination of manual calibration and semantic similarity verification. For each native instruction of IEC104, Modbus, and MMS, the corresponding semantic predicate is matched one by one, resulting in three types of mapping patterns:

[0101] One-to-one mapping: A single native instruction corresponds to an atomic semantic predicate. For example, Modbus function code 0x02 (read discrete input) is mapped to "batch switch quantity read", IEC104 C_SC_NA_1 (single command) is mapped to "single point remote control", and MMS Read service is mapped to "single point variable read".

[0102] One-to-many mapping: A single native instruction corresponds to a combination of multiple atomic semantic predicates. For example, the IEC104 general call C_IC_NA_1 is mapped to a timing combination of three predicates: "general call instruction issued + multiple batches of telemetry data returned + general call confirmation ended".

[0103] Many-to-one mapping: Multiple native instructions are combined to correspond to one atomic semantic predicate. For example, the Modbus function code 0x06 (write a single register) and 0x10 (write multiple registers) are combined to implement parameter downloading, which is uniformly mapped to the "parameter write" semantic.

[0104] Each mapping rule contains six core fields: rule ID, source protocol identifier, native instruction identifier, target semantic predicate, preconditions, parameter conversion formula, and reverse mapping logic, which are stored in the mapping rule library.

[0105] 2. Core Implementation of Semantic Transformation Intermediate Layer

[0106] The middleware layer is deployed between the native protocol and the unified semantics, and has three built-in adaptation modules to achieve lossless bidirectional conversion:

[0107] Address space normalization module: This module unifies the native addressing methods of various protocols into a three-level global addressing format of "device unique ID + object classification code + instance number". For example, it converts Modbus's "holding register address 40001" into "Device001+AI+0001" and IEC104's "information body address 1001" into "Device002+DI+0001", completely masking the differences in native address spaces.

[0108] Data type conversion module: Establishes a unified data type system (Boolean, integer, floating-point, string, and structure), and designs bidirectional conversion formulas and precision compensation algorithms for the data types specific to each protocol. For example, the normalized value of IEC104 is converted to a standard floating-point value using the following formula:

[0109]

[0110] in, This represents the actual engineering value. The original message value, The scaling factor is... The offset is controlled within one-thousandth of the industrial allowable range;

[0111] Timing logic alignment module: In response to the differences in interaction timing between different protocols, the module uses state machine caching and timing reorganization to align asynchronous, multi-frame native interactions into a standard "request-response" semantic timing, ensuring the timing consistency of semantic instances.

[0112] 3. Mapping integrity and accuracy verification

[0113] Design a dual verification mechanism to ensure mapping quality:

[0114] Coverage verification: Automatically traverse all behaviors in the native protocol feature library, verify whether corresponding mapping rules exist, generate alarms for missing items, and ensure 100% coverage of core instructions;

[0115] Bidirectional consistency verification: Convert the original instruction into a unified semantics and then back into the original instruction. Compare the instruction function and data value before and after the conversion to verify the lossless mapping. When the error exceeds the threshold, the rule correction process is automatically triggered.

[0116] Implementation Step S4: Standardized Event Processing Based on Protocol Difference Elimination

[0117] This step outputs a protocol-independent standardized event stream. The specific implementation process is as follows:

[0118] 1. Identification of heterogeneous differences in cross-protocol events

[0119] The heterogeneous items of events are analyzed from three dimensions: structure, semantics, and format, and a difference feature matrix is ​​established:

[0120] Structural differences: The number of event fields, field names, field order, and nesting structure are different;

[0121] Semantic differences: Event classification standards, alarm level definitions, event type naming, and triggering logic are different;

[0122] Format differences: The timestamp format, byte order, encoding method, and numerical unit are different.

[0123] Differences were identified for the three target protocols: for example, IEC104 events are classified by transmission cause, Modbus events are classified by exception code, and MMS events are classified by event priority field. The classification dimensions and thresholds of the three are not consistent.

[0124] 2. Standardized Model Definition for Unified Events

[0125] Define the octet unified event model as follows:

[0126]

[0127]

[0128] 2. The definitions of each field are as follows:

[0129] A globally unique event identifier, generated using the snowflake algorithm to ensure uniqueness in distributed scenarios;

[0130] Event semantic type: reuse the semantic predicate of the event alarm domain in S2 to achieve semantic uniformity;

[0131] The levels are uniformly divided into five categories: Emergency, Important, General, Warning, and Notification, each corresponding to a different response priority.

[0132] It uses a unified UTC millisecond-level Unix timestamp and supports automatic time zone conversion and latency calibration.

[0133] The event source device identifier and network address information are used for tracing and locating the source.

[0134] Semantic event description text, automatically generated using a unified template, is easy for human readers;

[0135] Structured event payloads use a unified JSON format to store event details, preserving all information about the original event.

[0136] : Associated event ID, used for event tracing and multi-event correlation analysis.

[0137] The event model uses JSON Schema to define field constraints, data types, and required fields. All output events must pass Schema validity validation.

[0138] 3. Implementation of the Difference Elimination Engine Core

[0139] The engine adopts a rule-driven and semantic completion architecture, and has four core processing units built in:

[0140] Level Mapping Unit: Establishes a mapping table between the native event levels of each protocol and a unified five-level level system, supporting fuzzy mapping based on thresholds. For example, it maps IEC104 Level 1 / 2 alarms, Modbus critical / general anomalies, and MMS high / medium / low priority to a unified standard level system;

[0141] Time normalization unit: Automatically recognizes the timestamp format of native events (BCD code, relative time, local time, etc.) and converts it into a standard UTC timestamp; it also supports clock skew calibration based on network latency to correct clock asynchrony issues between different devices;

[0142] Field alignment unit: Based on semantic similarity matching algorithm, it maps heterogeneous fields of native events to standard fields of unified event model; it fills in missing non-mandatory fields with default values ​​and retains redundant fields in extended payload to ensure that no information is lost;

[0143] Encoding conversion unit: Automatically handles byte order (big-endian / little-endian) conversion, binary / ASCII encoding conversion, and numerical unit normalization (e.g., unifying current, voltage, and temperature units to international standard units), eliminating format differences.

[0144] Implementation Step S5: Build a data storage and risk analysis framework based on unified semantics.

[0145] This step enables the practical application of the semantic model. The specific implementation process is as follows:

[0146] 1. Semantic hierarchical storage architecture design

[0147] A three-tier storage architecture is adopted to balance the retention of raw data and the performance of semantic data query and analysis:

[0148] Raw message layer: It adopts distributed append storage to fully store metadata such as raw binary messages, collection time, collection port, and protocol type. It supports fast retrieval of raw messages by time and device for post-event traceability and auditing.

[0149] Standard semantic layer: It is divided into time series data sub-database and event data sub-database. The time series data sub-database uses a time series database to store semantically encoded telemetry and teleindication time series data, and indexes are built according to semantic predicates and devices. The event data sub-database uses a document-oriented database to store standardized events, and supports multi-dimensional retrieval by event level, type, and source device.

[0150] Semantic Indexing Layer: Constructs a semantic knowledge graph and inverted index, and models the association between semantic predicates, devices, objects, and events. It supports semantic queries and can retrieve corresponding behaviors and events without specifying a specific protocol.

[0151] 2. Construction of a general risk analysis engine

[0152] A protocol-agnostic risk analysis engine is built based on a unified semantic model, comprising two main modules:

[0153] Anomaly detection module: Based on the semantic sequence of normal business, establish a behavior whitelist baseline, define legal action-object combinations, execution sequence, and operation frequency; use the isolated forest algorithm to perform anomaly detection on the real-time semantic stream, identify abnormal behaviors that deviate from the baseline, such as unauthorized object operations, abnormal command frequency, and illegal interactions with reversed timing.

[0154] Cross-protocol threat association module: Based on semantic reasoning rules, it performs correlation analysis on standardized events of different protocols and devices to reconstruct the attack chain; for example, it associates three cross-protocol events, namely, abnormal writing to Modbus register, unauthorized use of IEC104 remote control commands, and tampering with MMS configuration files, into a complete attack scenario.

[0155] 3. Unified output of risk situation

[0156] A unified risk scoring model is established to calculate the risk value of a single event and the global risk value based on four dimensions: event level, asset value, frequency of occurrence, and scope of impact, outputting a unified risk profile. Semantic-level end-to-end tracing is supported: risk alarms can be directly traced back to the corresponding standardized semantic instance, original protocol message, and original device, realizing a complete tracing chain of "risk alarm → semantic behavior → original message".

[0157] Implementation step S6: Implement a plug-in semantic model extension mechanism

[0158] This step ensures the model's scalability, and the specific implementation process is as follows:

[0159] 1. Standardized Plug-in Interface Specification Definition

[0160] Adopting an interface-oriented design approach, the three major standard plugin interfaces are separated to decouple the core semantic engine from the protocol adaptation logic:

[0161] Protocol parsing interface (IProtocolParser): Defines two core methods: parse(raw_data) and build(frame_obj). The raw binary message is input and the structured native protocol frame object is output. Conversely, the frame is encapsulated. Plugins need to implement message validity verification, field parsing, and state machine maintenance logic.

[0162] The semantic mapping interface (ISemanticMapper) defines two core methods, to_semantic(frame_obj) and to_frame(semantic_unit), to implement bidirectional mapping between native protocol frames and unified semantic units.

[0163] Event Conversion Interface (IEventConverter): Defines the to_standard_event(raw_event) method to convert raw events into standard events.

[0164] All interfaces use a unified input / output data structure specification. The core semantic engine interacts with plugins only through standard interfaces and is unaware of the implementation details of specific protocols.

[0165] 2. Plugin Registration and Lifecycle Management

[0166] Establish a plugin management center to achieve full lifecycle control of plugins:

[0167] Registration verification: During plugin registration, the integrity of the interface implementation, the legality of the mapping rules, and the standardization of the format are automatically verified. Only after the verification is passed can it be added to the database.

[0168] Dynamic loading: Supports hot reloading mechanism; adding new protocol plugins does not require restarting the core engine and takes effect immediately after registration.

[0169] Sandbox isolation: Each plugin runs in an independent sandbox. An error in a single plugin only affects the parsing of the corresponding protocol and will not cause the core engine to crash.

[0170] Version management: Supports plugin version iteration, rollback, enable / disable control, and is compatible with different version protocol variants.

[0171] 3. Plugin Development Templates and Toolchains

[0172] We provide a standardized plugin development SDK, including an abstract interface implementation framework, protocol feature configuration file templates, mapping rule configuration templates, and unit test case templates. When adding a new industrial protocol, developers only need to implement the three main interfaces according to the templates and fill in the protocol parsing logic and mapping rules. No modification to the core semantic model and analysis engine code is required, enabling low-cost and rapid expansion. We also provide automated plugin testing tools that can automatically verify the plugin's parsing accuracy, mapping correctness, and event conversion coverage.

[0173] Implementation Step S7: Semantic-level Global Unified Access Control and Command Security Circuit Breaker

[0174] This step is deployed in the S3 semantic transformation intermediate layer, and the specific implementation process is as follows:

[0175] 1. Construction of three-dimensional global permission rules

[0176] Global permission rules are defined based on three dimensions: "operation subject + semantic predicate + operation object," constructing a three-dimensional permission matrix. Permission determination is implemented using Boolean functions, as shown in the following formula:

[0177]

[0178] in, For identifying the operating entity; For semantic predicate actions; Identifier for the object being operated on.

[0179] 2. Dual-checkpoint deployment and execution process

[0180] Two verification points are set at the beginning and end of the semantic transformation intermediate layer to achieve end-to-end access control:

[0181] Uplink verification point: After the original command is parsed by the protocol and its semantics are converted into a unified semantic unit, the permission determination function is immediately called to perform the first verification; if the verification fails, it is directly intercepted and does not enter the subsequent processing flow.

[0182] Downlink verification point: Before the unified semantic command issued by the upper layer application is converted into a native protocol frame, a second permission verification is performed; if the verification fails, the conversion is terminated and the command is prohibited from being issued.

[0183] The dual-checkpoint mechanism covers both uplink data acquisition and downlink command control, ensuring that all semantic actions are subject to global permission constraints.

[0184] 3. Semantic-level circuit breaking and alarm output

[0185] When the permission determination function outputs 0, the semantic level circuit breaker mechanism is triggered: the instruction is intercepted directly at the semantic layer without performing protocol conversion and forwarding downwards, and the interception action is unrelated to the specific protocol; at the same time, a standardized unauthorized alarm event is automatically generated, which includes information such as the operation subject, attempted action, operation object, and interception time, and is incorporated into the S5 risk analysis framework for unified display and statistics.

[0186] Implementation Step S8: Semantic Sequence-Driven Cross-Protocol Business Process Logic Anomaly Detection

[0187] This step is integrated into the S5 risk analysis framework, reusing a unified semantic data and storage architecture. The specific implementation process is as follows:

[0188] 1. Semantic-level business process baseline modeling

[0189] Based on a unified semantic predicate system, semantic-level modeling is performed on typical industrial control business processes (general call inspection, remote control operation, parameter tuning, fault handling, firmware upgrade, etc.). Each standard process baseline contains four elements:

[0190] Action sequence: A sequence of atomic semantic predicates arranged in the order of execution. For example, the baseline of the remote control process is "remote control selection → remote control confirmation → remote control execution → result return".

[0191] Timing constraints: time thresholds for each step and overall process duration thresholds;

[0192] Object dependency: The correspondence between actions and the objects they operate on. For example, the parameter tuning process must read the parameters before writing them, and the objects they operate on must be consistent.

[0193] Priority permissions: The level of principal permissions required to execute this process.

[0194] All baselines are built based on semantic predicates and are independent of specific protocols; the same business process baseline can be adapted to corresponding business scenarios of multiple protocols such as IEC104, Modbus, and MMS.

[0195] 2. Real-time semantic stream process segment matching

[0196] A sliding window mechanism is used to segment and extract real-time semantic streams, with the window length dynamically adjusted based on the average number of steps in a typical business process. A prefix matching algorithm is used to compare the real-time semantic sequence with process sequences in a baseline database to identify the type and progress of the currently executing business process. The matching process supports cross-protocol semantic sequence concatenation, meaning that the same business process can contain semantic actions from different protocols, achieving end-to-end process identification.

[0197] 3. Anomaly Calculation with Integrating Causal Constraints

[0198] For the matched process segments, the anomaly score is calculated using a fusion of sequence edit distance and causal constraints, as shown in the following formula:

[0199]

[0200]

[0201] 3. Formula parameter definition:

[0202] For the current real-time semantic sequence, The matched standard baseline sequence;

[0203] The Levenstein edit distance between two sequences measures the difference in the order and composition of actions in the sequences.

[0204] The length of the baseline sequence is used to normalize the edit distance;

[0205] It is a set of causal constraint rules, including three types of rules: time-series constraints, object dependency constraints, and pre-access constraints.

[0206] This represents the total number of times the real-time sequence violates the causality constraint rules.

[0207] This is the sequence difference weight, with a default value of 0.4; To constrain violations, the default value is 0.6, and the following conditions must be met: The weights can be adjusted according to the scenario.

[0208] When the anomaly score exceeds the set threshold (default 0.3), it is determined to be a business process logic anomaly, generating a process-level anomaly alarm, supporting the tracing of the complete anomaly sequence and the corresponding original message.

[0209] This method can identify attacks where each individual instruction is legal, but the combination of these instructions violates business logic. For example, attackers may carry out attacks through multiple legal operations such as "reading a set value → unauthorized modification of parameters → issuing remote control commands → covering up alarms," ​​thus breaking through the capability limits of traditional single-instruction detection.

[0210] In summary, this unified semantic model construction method for industrial control protocols completely shields the format differences of heterogeneous protocols at the behavioral semantic level by constructing a unified behavioral semantic meta-model and bidirectional mapping mechanism for IEC104, Modbus, and MMS, achieving unified expression and lossless conversion of control behavior and event data across protocols. Combined with event standardization methods to eliminate protocol differences, semantic layered storage, and a risk analysis framework, it breaks down data barriers between multiple protocols, supporting protocol-independent unified risk assessment and end-to-end traceability. Furthermore, the pluggable, scalable architecture significantly reduces the access cost and system adaptation difficulty of new protocols, providing a universal and highly compatible semantic foundation for unified management, monitoring, and security analysis of multiple protocols in industrial control scenarios.

[0211] It features semantic-level global access control and cross-protocol business process anomaly detection mechanisms, further extending security protection capabilities based on a unified semantic foundation: the former solves the problem of access silos in multi-protocol scenarios from the root by using a three-dimensional access control matrix of "operation subject-semantic predicate-operation object" and a dual-verification point semantic circuit breaker mechanism, achieving fine-grained instruction security control across protocols; the latter, based on semantic sequence baseline modeling and anomaly degree algorithm that integrates edit distance and causal constraints, breaks through the limitations of traditional single instruction anomaly detection, can identify business logic attacks formed by combinations of single legitimate instructions, and significantly improves the depth, breadth and accuracy of risk detection in industrial control systems.

[0212] The embodiments of the present invention are given for illustrative and descriptive purposes only, and are not intended to be exhaustive or to limit the invention to the forms disclosed. Many modifications and variations will be apparent to those skilled in the art. The embodiments were chosen and described in order to better illustrate the principles and practical application of the invention, and to enable those skilled in the art to understand the invention and to design various embodiments with various modifications suitable for a particular purpose.

Claims

1. A method for constructing a unified semantic model for industrial control protocols, characterized in that: Includes the following steps: S1. Multi-source industrial control protocol sample collection and native feature analysis: Collect standard specifications, field messages and interaction log samples of three types of industrial control protocols: IEC104, Modbus and MMS. Analyze the application layer data unit structure of each protocol and extract three core features: control behavior, data object and event type to build a native protocol feature library. S2. Construct a unified semantic meta-model for industrial control behavior: Define the general semantic description dimension, divide the semantic domain of industrial control behavior, define standardized semantic predicates and attribute constraints, and construct a unified behavioral semantic meta-language system decoupled from specific protocol formats; S3. Establish a unified mapping model for cross-protocol control behavior: Establish a bidirectional mapping rule base between native protocol instructions and unified semantic predicates, construct a semantic conversion intermediate layer, and realize bidirectional lossless conversion between native protocol instructions and unified semantic instructions; S4. Perform unified event standardization processing based on protocol difference elimination: Identify structural, semantic, and format heterogeneous differences between cross-protocol events, define a unified event standardization model, and convert native events of different protocols into standard format events through the difference elimination engine; S5. Establish a data storage and risk analysis framework based on unified semantics: Construct a semantic hierarchical storage architecture, build a general risk analysis engine based on a unified semantic model, and output risk status and traceability capabilities in a unified semantic dimension; S6. Implement a plug-in-based semantic model extension mechanism: Define standardized plug-in interface specifications, build a plug-in registration and management center, support dynamic loading and hot updates of new protocol plug-ins, and realize scalable access to the semantic model.

2. The method for constructing a unified semantic model for industrial control protocols according to claim 1, characterized in that: In step S1, a finite state machine combined with a protocol field parsing engine is used to perform frame-by-frame deep parsing, extracting core features for three types of protocols: For the Modbus TCP protocol, we parse the transaction identifier, function code, register address and data value, and sort out the read / write and single-point / batch behavior patterns; For the IEC104 protocol, we analyzed the APCI control domain, ASDU type identifier, transmission reason and information body address, and sorted out the timing sequence of general call, telemetry, telesignaling and remote control interaction. For the MMS protocol, we parse the service primitives, call IDs, object names and variable lists, and sort out the service logic of reading, writing, file transfer and event reporting. The native protocol feature library is stored in a structured manner according to three categories: control behavior set, data object set, and event type set, and the field specifications are defined using JSON Schema.

3. The method for constructing a unified semantic model for industrial control protocols according to claim 1, characterized in that: In step S2, the unified semantic meta-model is formally expressed using a seven-tuple, as shown in the following formula: in, As an action type, the enumeration includes six basic actions: read, write, control, configuration, alarm, and keep-alive. The operating entity includes device type, device identifier, and permission level attributes; For the objects being operated on, this includes object classification, global unified addressing, and data type attributes; These are operation parameters, including parameter name, data type, value range, and unit attribute; To ensure proper execution timing, linear sequential logic is used to describe the interaction sequence and time constraints. The returned result includes the execution status, returned data value, and status code attributes; For abnormal states, the exception type, exception code, triggering conditions, and handling strategy attributes are included. The semantic domain is divided into five categories: data acquisition domain, instruction control domain, parameter configuration domain, event alarm domain, and connection keep-alive domain. Each semantic domain defines atomic semantic predicates, and complex behaviors are composed of combinations of multiple atomic predicates.

4. The method for constructing a unified semantic model for industrial control protocols according to claim 1, characterized in that: In step S3, the bidirectional mapping rule base covers three types of mapping modes: one-to-one, one-to-many, and many-to-one. Each mapping rule includes a rule ID, source protocol identifier, native instruction identifier, target semantic predicate, preconditions, parameter conversion formula, and reverse mapping logic. The semantic conversion intermediate layer has a built-in address space normalization module, a data type conversion module, and a timing logic alignment module. The address space normalization module converts the native addressing methods of each protocol into a three-level global addressing format of "device unique ID + object classification code + instance number". Step S3 also includes mapping integrity and accuracy verification. The mapping is verified to be lossless through bidirectional conversion consistency verification, and rule correction is triggered when the error exceeds the threshold.

5. The method for constructing a unified semantic model for industrial control protocols according to claim 1, characterized in that: In step S4, the unified event standardization model is formally expressed using octet formulas, as follows: in, A globally unique event identifier, generated using the snowflake algorithm; For event semantic types, reuse the event alert domain semantic predicate; They are uniformly divided into five levels: Emergency, Important, General, Warning, and Notice. UTC millisecond-level Unix timestamps; This includes the device identifier and address information of the event source; Provide semantic event description text; For structured event payloads; This is the associated event ID, used for event tracing and correlation analysis; The difference elimination engine has built-in level mapping unit, time normalization unit, field alignment unit and encoding conversion unit, which respectively handle heterogeneous differences in event level, time format, field structure and encoding method.

6. The method for constructing a unified semantic model for industrial control protocols according to claim 1, characterized in that: In step S6, the standardized plug-in interface includes three types: protocol parsing interface, semantic mapping interface, and event conversion interface. The core semantic engine interacts with the plug-in through the standard interface and is unaware of the specific protocol implementation details. The plugin registration and management center supports plugin registration verification, dynamic loading, sandbox isolation and version management. An abnormality in a single plugin will not affect the operation of the core engine. When adding a new industrial protocol, implement the three types of interfaces according to the template and fill in the mapping rules to access the unified semantic system.

7. The method for constructing a unified semantic model for industrial control protocols according to claim 1, characterized in that: It also includes the following steps: S7 semantic-level globally unified access control and command security circuit breaker steps are deployed in the semantic translation middleware layer, specifically including: S71: Define global permission rules based on three dimensions: operation subject, semantic predicate, and operation object, and construct a three-dimensional permission matrix. The permission determination function formula is as follows: in, For identifying the operating entity; For semantic predicate actions; Identify the object being operated on; S72: Set up dual verification points in the semantic conversion intermediate layer: perform the first permission verification after the native instruction is converted into unified semantics, and perform the second permission verification before the unified semantics is converted into native instructions and issued. S73: When the permission determination function outputs a certain value, the semantic level circuit breaker mechanism is triggered, directly intercepting the instruction at the semantic layer without performing protocol conversion and forwarding downward, and generating a standardized unauthorized access alarm event.

8. The method for constructing a unified semantic model for industrial control protocols according to claim 1, characterized in that: It also includes the following steps: S8. Semantic sequence-driven cross-protocol business process logic anomaly detection steps, integrated into the risk analysis framework, specifically include: S81: Based on a unified semantic predicate system, semantic-level modeling is performed on typical business processes of industrial control, defining legal action sequences, timing constraints, object dependencies and permission preconditions, and building a standard process baseline library. S82: Employs a sliding window mechanism to segment and extract real-time semantic streams, and uses a prefix matching algorithm to identify the currently executing business process segment; S83: Based on the causal reasoning mechanism, verify whether the action logic, object association and temporal relationship of the semantic sequence conform to the baseline, identify abnormal sequences that deviate from the business logic, and generate process-level abnormal alarms.

9. The method for constructing a unified semantic model for industrial control protocols according to claim 8, characterized in that: In step S83, an anomaly calculation method that fuses sequence edit distance and causal constraints is adopted. The anomaly calculation formula is as follows: in, For real-time semantic sequences; The matched standard baseline sequence; The edit distance between the two sequences; Baseline sequence length; It is a set of causal constraint rules; This represents the number of times a real-time sequence violates causal constraints. For sequence difference weights, To constrain violations of weights, and satisfy When the anomaly score exceeds the set threshold, it is determined to be an anomaly in the business process logic.

Images