IEC104 protocol conversion method and system based on fusion of IEC61850 model and electric power internet of things model

Abstract

The invention discloses an IEC104 protocol conversion method and system based on fusion of an IEC61850 model and an electric power internet of things model, and the method comprises the steps: constructing a three-dimensional address space model composed of a type identifier TYPE-ID, a transmission reason COT and an information object address IOA based on the structural features of an ASDUs in an IEC104 protocol; mapping a communication semantic mode corresponding to the (TYPE-ID, COT) two-tuple into an API (Application Program Interface); defining a mapping relation between an IEC 61850 model element corresponding to the IOA and an electric power internet of things model element; designing a synchronous request-response message processing mode and an asynchronous event-driven message processing mode; and constructing a localized real-time data mirror image library, and completing mapping between the protocol data and the model object. According to the invention, intelligent conversion and cooperative interaction between the IEC104 protocol and the IEC 61850 model as well as between the IEC104 protocol and the electric power internet of things model are supported, and efficient interoperation and flexible expansion in a multi-protocol and multi-model environment are realized.

Description

TECHNICAL FIELD

[0001] The application relates to the technical field of power system communication, and in particular to an IEC104 protocol conversion method and system based on IEC61850 model and power internet of things model fusion. BACKGROUND

[0002] IEC 60870-5-104 protocol (hereinafter referred to as “IEC104 protocol”) as the core communication protocol in the field of power automation, is widely used in substation automation, power distribution internet of things (D-IoT), integrated energy management system (IEMS) and other key scenes, and undertakes the important responsibility of data interaction between master station and terminal device. However, with the rapid development of new power system towards digitalization and intelligentization, IEC104 protocol faces increasingly prominent problems of model heterogeneity and semantic fusion in cross-system integration.

[0003] Currently, different technical fields adopt significantly different technical architectures in device modeling and data expression: (1) Substation automation system is generally based on IEC 61850 standard, which organizes device functions through predefined logical nodes (Logical Node, LN), uses common data class (Common Data Class, CDC) to standardize the definition of data objects (such as telemetry, remote signaling, set value, etc.) in LN, forms a unified data structure and semantic expression, and is suitable for high-precision information modeling and service interaction at the substation level.

[0004] (2) The power distribution internet of things system mainly follows the power internet of things model defined in “Q / GDW 1207-2021 Unified Modeling Specification for Internet of Things Terminals”, uses the “thing model” method to model terminal devices, emphasizes lightweight, scalability and edge computing capability, supports rapid access and unified management of a large number of terminal devices, and is suitable for wide-area distribution and resource-limited internet of things scenarios.

[0005] (3) Integrated energy management system (IEMS) as a key platform for multi-energy collaboration and energy efficiency optimization, usually needs to fuse data from substation, power distribution internet of things, distributed power, energy storage system and other sources, involving the mixed use of IEC 61850 model, power internet of things model and enterprise self-defined model. This complex architecture of multiple models coexisting puts forward higher requirements for data interconnection, semantic alignment and protocol conversion between systems.

[0006] The modeling methods and communication mechanisms between different technical systems in the power system are significantly different, which leads to the following two core problems of IEC104 protocol in cross-field application: (1) Problems of repetitive development and low reusability in protocol adaptation: Currently, the implementation of the IEC 104 protocol usually requires customized development for different modeling systems (such as the CDC model of IEC 61850 and the power IoT model), resulting in high coupling between the mapping logic of the protocol stack and the model, low code reusability, and high system maintenance and expansion costs. For example, in the substation automation system, the ASDU information body address (IOA) in the IEC 104 protocol needs to be mapped to the logical device (LD) / logical node (LN) structure of IEC 61850; while in the distribution IoT system, the same data structure needs to be converted into property and service definitions in the object model. Due to the differences in data structure and semantic expression between the two types of models, the two mapping logics cannot be shared, resulting in a lot of repetitive development work, which seriously restricts the flexibility and scalability of the system.

[0007] (2) Semantic Gap Issues in Cross-Model Fusion: In hybrid systems that require the integration of IEC 61850 and power IoT models, the two models differ fundamentally in terms of data abstraction level, semantic expression, and communication service mapping mechanism. The IEC 61850 model emphasizes structured and standardized data organization, suitable for high-precision and high-reliability substation control scenarios; while the power IoT model focuses more on lightweight and flexible expansion, suitable for edge computing and large-scale terminal access. During information interaction, this semantic inconsistency can easily lead to data mapping distortion, information loss, or misunderstanding. Currently, there is a lack of a unified modeling language and standardized conversion mechanism, making it difficult to achieve deep fusion between the two models, resulting in high system integration complexity and high development and maintenance costs. Summary of the Invention

[0008] To address the problems of repetitive development for protocol adaptation, semantic gaps across models, and high integration complexity in existing technologies, this invention provides an IEC104 protocol conversion method and system based on the fusion of the IEC61850 model and the power IoT model. It supports intelligent conversion and collaborative interaction between the IEC104 protocol and the IEC 61850 model and the power IoT model, aiming to achieve efficient interoperability and flexible expansion in multi-protocol and multi-model environments.

[0009] This invention discloses an IEC104 protocol conversion method based on the fusion of the IEC61850 model and the power IoT model, comprising: Step 1, based on the structural features of the application service data unit (ASDU) in the IEC104 protocol, a three-dimensional address space model composed of a type identifier (TYPE-ID), a transmission reason (COT) and an information object address (IOA) is constructed; wherein, the communication semantic mode corresponding to the (TYPE-ID, COT) binary tuple is uniquely determined, and semantic abstraction and classification management of the protocol information model are realized; Step 2, the communication semantic mode corresponding to the (TYPE-ID, COT) binary tuple is mapped to a standardized API interface operation, further realizing service semantic alignment and interface binding between the API interface and the IEC 61850 service model and the power internet of things model, and supporting automatic conversion of protocol semantics to service interfaces; Step 3, the mapping relationship between the IEC 61850 model elements (such as LD / LN / DO) corresponding to the configuration file definition information object address (IOA) and the power internet of things model elements (such as attributes, services and events) is adopted, and flexible configuration and dynamic loading of the hybrid protocol model are realized; Step 4, according to the communication scene requirement, two kinds of message processing modes of synchronous request-response and asynchronous event driving are designed, which are used to ensure the timing consistency and transaction integrity of the control instruction between the IEC104 protocol and the IEC 61850 / MMS protocol or the power internet of things protocol, and improve the system response efficiency and reliability; Step 5, a localized real-time data mirror library is constructed, the caching and synchronization of the underlying device data are realized, and efficient mapping between protocol data and model objects is completed through the CPitfmData module, and fast data access and cross-protocol data consistency maintenance are supported.

[0010] As a further improvement of the application, in the step 1, The coding range of the type identifier (TYPE-ID) is 0-255, which is used to distinguish different types of messages, such as remote signaling, remote measurement, remote control and remote adjustment, and define the structure and purpose of data; The value range of the transmission reason (COT) is 1-127, which is used to identify the transmission characteristics of the message, such as burst data, periodic data, initialization response and request response, and express the context semantics of data; The address space range of the information object address (IOA) is 0-16777215, which is used to uniquely identify specific data objects in the device, and realize fine-grained addressing of power equipment.

[0011] As a further improvement of the application, in the step 2, Based on the type identifier (TYPE-ID) and the transmission reason (COT), three kinds of core function interface types are defined, which are: Synchronous read interface sync_read: suitable for scenarios where the type identifier TYPE-ID is 1, 3, 9, 13 or 30, and the transmission cause is 2 (initialization response), and is used for synchronous reading of remote signaling and remote measurement data; Asynchronous write interface async_write: suitable for scenarios where the type identifier is 45, 46 or 200, and the transmission cause is 6 (activation command), and is used for asynchronous execution of remote control and remote adjustment operations; Event subscription interface event_sub: suitable for scenarios where the type identifier is 9, 13 or 42, and the transmission cause is 3 (burst data), and is used for subscribing to event notifications such as remote signaling state changes; Among them, The specific API interfaces corresponding to the synchronous read interface sync_read include: GetYXValue: get remote signaling current data, GetYCValue: get remote measurement current data, GetLineYxInfo: get remote signaling change queue data of a specified master station, and GetLineYcInfo: get remote measurement change queue data of a specified master station. The specific API interfaces corresponding to the asynchronous write interface async_write include: SetYKCmd: set remote control command, SetYTCmd: set remote adjustment command, and GetYKYTReturn: get remote control and remote adjustment command execution result. The specific API interfaces corresponding to the event subscription interface event_sub include: SubLineYx: subscribe to remote signaling full information of a master station, and SubLineYc: subscribe to remote measurement full information of a master station.

[0012] As a further improvement of the present application, in step 3, By unifying the communication service API interface, bidirectional mapping between the IEC 61850 model and the power Internet of Things model is realized, and semantic alignment and data conversion across models and protocols are supported; specifically including: (1) IEC 61850 interaction mapping based on communication service API Request-response mode: Synchronous data operation: the corresponding API interface is GetYXValue, GetYCValue, GetLineYxInfo and GetLineYcInfo; Asynchronous command operation: the corresponding API interface is SetYKCmd, SetYTCmd and GetYKYTReturn; Subscription-publishing mode: Subscription stage: the corresponding API interface is SubLineYx and SubLineYc; Release phase: The corresponding API interfaces are GetLineYxInfo and GetLineYcInfo; (2) Power IoT Model Interaction Mapping Based on Communication Service API GET operations: The corresponding API interfaces are GetYXValue, GetYCValue, GetLineYxInfo, and GetLineYcInfo; The set operation corresponds to the API interfaces SetYTCmd and GetYKYTReturn. Action operations: The corresponding API interfaces are SetYKCmd and GetYKYTReturn; Report operations: The corresponding API interfaces are GetLineYxInfo and GetLineYcInfo; (3) Object mapping A hybrid protocol mapping configuration for object mapping is implemented using configuration files, and dynamic loading and online updates of configuration files are supported, improving system flexibility and maintainability.

[0013] As a further improvement of the present invention, in step 4... The path of the synchronous request-response message processing mode is: API request → CPltfmData data mirroring → SignalEmitter signal distribution → Receiver data processing → Database (DB) interaction → return result; this path ensures the integrity and consistency of data operations. The path for asynchronous event-driven message processing is: database (DB) change event → SignalEmitter push → Receiver processing → CPltfmData image update → notification to upper-layer module; this path supports event-driven and proactive push, and is suitable for scenarios such as remote signaling changes and telemetry updates.

[0014] As a further improvement of the present invention, step 4 further includes: a timeout message recycling strategy; The timeout message recycling strategy is as follows: when a synchronous message response times out (TTL expires), the system automatically converts it to asynchronous channel processing to avoid blocking the main thread and ensure the overall stability and responsiveness of the system.

[0015] As a further improvement of the present invention, in step 5... The adaptation layer maintains a local data mirror repository (CPltfmData), and the synchronization mechanism is actively triggered by data mirror repository change events (instead of polling) to achieve millisecond-level data updates, significantly reducing the pressure of high-frequency database access.

[0016] This invention also discloses an IEC104 protocol conversion system based on the fusion of the IEC61850 model and the power IoT model, comprising: The model unification abstraction module is used to implement steps 1 to 2 of the method as described in any one of claims 1 to 7; The model mapping module is used to implement step 3 of the method as described in any one of claims 1 to 7; The message processing and real-time library mapping module is used to implement steps 4 to 5 of the method as described in any one of claims 1 to 7.

[0017] Compared with the prior art, the beneficial effects of the present invention are as follows: 1. High development efficiency: Traditional methods require 3 to 6 months to complete the development of a protocol stack for a single model type, while the configurable method of this invention can shorten the development cycle to no more than 2 weeks, which greatly improves the project's startup speed and ability to respond to market changes.

[0018] 2. Low maintenance cost: Traditional adaptation layer adjustments require code recompilation, which increases maintenance complexity and time cost. This invention supports online updates of object mapping configuration files without restarting the system or rewriting code, thus significantly reducing maintenance difficulty and cost.

[0019] 3. Excellent transmission performance: The instruction transmission delay of traditional solutions is usually between 200 and 500 milliseconds, while the transmission delay of this invention is reduced to no more than 50 milliseconds after optimization by using a synchronous channel, which significantly improves real-time data processing capabilities and user experience.

[0020] 4. Strong data fusion capability: Previous technologies struggled to achieve cross-model data fusion, limiting system compatibility and flexibility. This invention can automatically fuse data from different models, enhancing system adaptability and making it suitable for more complex integration environments. Attached Figure Description

[0021] Figure 1 This is a flowchart of the IEC104 protocol conversion method based on the fusion of the IEC61850 model and the power IoT model disclosed in this invention; Figure 2 This is a framework diagram of the IEC104 protocol conversion system based on the fusion of the IEC61850 model and the power IoT model disclosed in this invention. Figure 3 The flowcharts are of the model unification abstraction module and the model mapping module disclosed in this invention. Figure 4 This is a flowchart of the message processing and real-time library mapping module disclosed in this invention. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0023] The present invention will now be described in further detail with reference to the accompanying drawings: This invention provides an IEC 104 protocol conversion method and system based on the fusion of the IEC 61850 model and the Internet of Things (IoT) power system. It achieves efficient interoperability and dynamic mapping between the IEC 104 protocol and the IEC 61850 and IoT power systems by constructing a rule-engine-driven intelligent adaptation layer system; it is used to solve: (1) Decoupling mapping of protocol and model: By introducing a configurable mapping mechanism, the logical decoupling between IEC 104 protocol and IEC 61850 model and power IoT model is realized, breaking the coupling limitation brought about by the traditional hard-coded implementation method, avoiding repeated development for different model and protocol combinations, and improving the maintainability and adaptation efficiency of the system.

[0024] (2) Semantic Automated Conversion: Construct a unified general semantic description layer to support semantic alignment and automatic mapping between information objects (ASDU) in the IEC 104 protocol and the "hierarchical structure (LD / LN / DO) + ​​common data class (CDC) template" in IEC 61850, as well as attributes, services and message structures in the power IoT model, so as to realize intelligent parsing and conversion of information across models and protocols.

[0025] (3) Cross-protocol timing consistency guarantee: In view of the differences between the master-slave question-and-answer communication mechanism of IEC 104 protocol and the asynchronous communication mode of IEC61850 MMS / Power IoT protocol, a transaction state synchronization and event-driven mechanism is designed to ensure the timing correctness and transaction integrity of key operations such as control commands and status feedback in the cross-protocol interaction process, thereby improving the reliability and collaborative efficiency of system operation.

[0026] like Figure 1 As shown, this invention provides an IEC104 protocol conversion method based on the fusion of the IEC61850 model and the power IoT model, comprising: Step 1: Based on the structural characteristics of the Application Service Data Unit (ASDU) in the IEC104 protocol, construct a three-dimensional address space model consisting of the type identifier (TYPE-ID), the transmission reason (COT), and the information object address (IOA). The communication semantic pattern is uniquely determined by the (TYPE-ID, COT) tuple, thereby realizing the semantic abstraction and classification management of the protocol information model. Step 2: Map the communication semantic pattern corresponding to the (TYPE-ID, COT) tuple to a standardized API interface operation, further realizing the service semantic alignment and interface binding between the API interface and the IEC 61850 service model and the power IoT model, supporting the automatic conversion of protocol semantics to service interface; Specifically: Based on the type identifier TYPE-ID and the transmission reason COT, three core functional interface types are defined as follows: Synchronous read interface sync_read: Applicable to scenarios where the type identifier TYPE-ID is 1, 3, 9, 13 or 30 and the transmission reason is 2 (initialization response), used for synchronous reading of remote signaling and telemetry data; The asynchronous write interface async_write is suitable for scenarios where the type identifier is 45, 46, or 200 and the transmission reason is 6 (activation command), and is used to perform remote control and remote adjustment operations asynchronously. The event subscription interface event_sub is suitable for scenarios where the type identifier is 9, 13, or 42 and the transmission reason is 3 (burst data), and is used to subscribe to event notifications such as remote signaling status changes; in, The specific API interfaces corresponding to the synchronous read interface sync_read include: GetYXValue: Get the current remote signaling data; GetYCValue: Get the current telemetry data; GetLineYxInfo: Get the remote signaling change queue data of the specified master station; GetLineYcInfo: Get the telemetry change queue data of the specified master station. The specific API interfaces corresponding to the asynchronous write interface async_write include: SetYKCmd: set remote control command, SetYTCmd: set remote adjustment command, GetYKYTReturn: get the execution result of the remote control command; The specific API interfaces corresponding to the event subscription interface event_sub include: SubLineYx: subscribe to the full remote signaling information of the master station, and SubLineYc: subscribe to the full telemetry information of the master station.

[0027] Step 3: Define the mapping relationship between the IEC 61850 model elements (such as LD / LN / DO) and the power IoT model elements (such as attributes, services, events) corresponding to the information object address IOA using a configuration file. Enables flexible configuration and dynamic loading of hybrid protocol models; Specifically: Through the unified communication service API interface, bidirectional mapping between the IEC 61850 model and the power IoT model is achieved, supporting semantic alignment and data conversion across models and protocols; specifically including: (1) IEC61850 interactive mapping based on communication service API Request-response pattern: Synchronization data operations: The corresponding API interfaces are GetYXValue, GetYCValue, GetLineYxInfo, and GetLineYcInfo; Asynchronous command operations: The corresponding API interfaces are SetYKCmd, SetYTCmd, and GetYKYTReturn; Subscription-publishing model: Subscription phase: The corresponding API interfaces are SubLineYx and SubLineYc; Release phase: The corresponding API interfaces are GetLineYxInfo and GetLineYcInfo; (2) Power IoT Model Interaction Mapping Based on Communication Service API GET operations: The corresponding API interfaces are GetYXValue, GetYCValue, GetLineYxInfo, and GetLineYcInfo; The set operation corresponds to the API interfaces SetYTCmd and GetYKYTReturn. Action operations: The corresponding API interfaces are SetYKCmd and GetYKYTReturn; Report operations: The corresponding API interfaces are GetLineYxInfo and GetLineYcInfo; (3) Object mapping A hybrid protocol mapping configuration for object mapping is implemented using configuration files, and dynamic loading and online updates of configuration files are supported, improving system flexibility and maintainability.

[0028] Configuration files can be in formats such as YAML, JSON, and XML. Below is an example of a YAML configuration file: # ===================================== # Hybrid Protocol Mapping Configuration File # Functionality: IEC104 → IEC61850 + IoT object model # Version: 1.2 # ===================================== mappings: # ===== Example 1: 10kV voltage (IEC61850) ===== - id: "1" # Unique identifier for the mapping rule, ASDU (IOA) Description: "10kV bus A-phase voltage dual-mode mapping" # Source Protocol Configuration source: protocol: "iec104" quality_check: # Quality bit rule - mask: 0x80 # Validity bit valid_value: 0x00 targets: # Objective 1: IEC61850 CDC Model - model: "iec61850" path: "MMXU1 / A.phsA.mag.f" # LN-DO-DA path transform: scaling: 0.01 # ===== Example 2: Ambient Temperature (IoT) ===== - id: "201" # Unique identifier for the mapping rule, ASDU (IOA) Description: "Smart Terminal Ambient Temperature Monitoring" source: protocol: "iec104" targets: - model: "iot" product_key: "PM_001" device_key: "bay01_sensors property: "temperature" transform: scaling: 0.1 # Original value * 0.1 → ℃ offset: -10.0 # Temperature calibration offset unit: "raw → ℃" Step 4: Based on the communication scenario requirements, design two message processing modes: synchronous request-response and asynchronous event-driven, to ensure the timing consistency and transaction integrity of control commands between the IEC104 protocol and the IEC 61850 / MMS protocol or the Internet of Things protocol, thereby improving system response efficiency and reliability. Specifically: The path of the synchronous request-response message processing mode is: API request → CPltfmData data mirroring → SignalEmitter signal distribution → Receiver data processing → Database (DB) interaction → return result; this path ensures the integrity and consistency of data operations. The path for asynchronous event-driven message processing is: database (DB) change event → SignalEmitter push → Receiver processing → CPltfmData image update → notification to upper-layer module; this path supports event-driven and proactive push, and is suitable for scenarios such as remote signaling changes and telemetry updates.

[0029] The timeout message recycling strategy is as follows: when a synchronous message response times out (TTL expires), the system automatically converts it to asynchronous channel processing to avoid blocking the main thread and ensure the overall stability and responsiveness of the system.

[0030] Step 5: Build a localized real-time data mirror library to achieve caching and synchronization of underlying device data, and complete the efficient mapping between protocol data and model objects through the CPltfmData module, supporting fast data access and cross-protocol data consistency maintenance.

[0031] Specifically: By maintaining a local data mirror repository (CPltfmData) at the adaptation layer, and proactively triggering a synchronization mechanism (rather than polling) through data mirror repository change events, millisecond-level data updates are achieved, significantly reducing the pressure of high-frequency database access. Real-world testing data shows that this mechanism can reduce database access frequency by more than 90%, ensuring API response time remains stable within 50ms, and significantly improving system performance and real-time performance.

[0032] This invention provides an IEC104 protocol conversion system based on the fusion of the IEC61850 model and the power IoT model, comprising: The unified abstraction module for the model is used to implement steps 1-2 of the above method; The model mapping module is used to implement step 3 of the above method; The message processing and real-time library mapping module is used to implement steps 4 and 5 of the above method.

[0033] Specifically: like Figure 2 As shown, the system of the present invention includes: (1) Protocol Parsing Layer: This layer consists of an IEC 60870-5-104 protocol server, responsible for processing the IEC 104 communication protocol widely used in the power industry. This module completes the reception, parsing, and encapsulation of protocol messages, realizing communication interaction with the master station system. The protocol server exchanges data with the adaptation layer through a standard API interface, shielding the underlying communication details and providing a unified data access interface for the upper layer.

[0034] (2) Core Conversion Layer (Adaptation Layer): The adaptation layer is the core conversion hub of the system, responsible for semantic mapping and data conversion between protocols and models. This layer realizes bidirectional interoperability between the IEC 60870-5-104 protocol and the IEC 61850 model and the Internet of Things (IoT) model, and supports data structure standardization, semantic alignment, and service interface mapping. The adaptation layer adopts a configuration-based approach to support flexible expansion, has good compatibility and maintainability, and effectively solves the problem of repetitive development of protocol adaptation in multi-model fusion scenarios.

[0035] (2) Database Layer: This layer consists of two data storage modules oriented towards different modeling systems. The first is the power IoT model database, built on the "Q / GDW 1207-2021 Unified Modeling Specification for IoT Terminals," which provides lightweight and scalable object modeling capabilities for power IoT devices, supporting unified access and data management for massive numbers of terminal devices. The second is the IEC 61850 model database, designed for substation automation systems. It organizes device functions based on logical nodes (LNs) and common data classes (CDCs) defined in the IEC 61850 standard, achieving high-precision, structured data modeling and service interaction. The two model databases achieve data interoperability and semantic fusion through an adaptation layer, supporting cross-model data querying, control, and event subscription.

[0036] (4) Business Application Layer: This layer includes two types of edge micro-applications, each targeting different modeling systems and application scenarios. The power IoT model edge micro-application, built upon the power IoT model, is mainly used in scenarios such as distribution IoT and intelligent fusion terminals, supporting IoT business functions such as edge computing, equipment management, and status monitoring. The IEC 61850 edge micro-application, built upon the IEC 61850 model, is mainly used in scenarios such as substation automation and distribution automation, supporting functions such as standard service interface calls, equipment control, and data acquisition. Both types of micro-applications achieve compatible access to the 104 protocol through a unified adaptation layer, improving the system's flexibility and deployment efficiency in a multi-model fusion environment.

[0037] like Figure 3 As shown, the model unification abstraction module and model mapping module of this invention include: (1) IEC104 Protocol Feature Abstraction Layer: This layer abstracts and encapsulates the key communication features of the IEC 104 protocol, including core elements such as message structure, communication state machine, service primitives, and data identifiers. It shields the implementation details of the underlying protocol and provides a unified protocol semantic expression for the upper layer, which facilitates subsequent mapping and integration with other models and services.

[0038] (2) Unified Communication Service API Layer, which serves as the core interaction interface of the system, provides an abstract interface for communication services that is independent of specific protocols. It exposes basic communication capabilities such as data reading and writing, event subscription, and control operations to the upper level in a unified manner, enabling standardized access to services in a multi-protocol and multi-model environment, and improving the scalability and interoperability of the system.

[0039] (3) Atomic API operation layer: This module further refines various communication services into atomic operation units that can be called independently (such as read, write, subscribe, control, etc.), supports flexible combination and scheduling, improves the granular control capability and business adaptability of the interface, and meets the fine control requirements of different application scenarios.

[0040] (4) IEC61850 Service Mapping Layer, which is responsible for mapping unified communication services to service models that conform to the IEC 61850 standard, including structured access and service calls of logical devices (LD), logical nodes (LN), data objects (DO) and common data classes (CDC), to ensure efficient connection and semantic consistency with substation automation systems.

[0041] (5) Power IoT Model Mapping Layer, which is oriented towards power IoT devices and edge computing platforms. This module realizes the semantic mapping between unified communication services and power IoT models, supports standardized access and interaction of IoT device attributes, services, events and other information, and promotes the rapid integration and interconnection of new intelligent terminals in the power system.

[0042] likeFigure 4 As shown, the message processing and real-time library mapping module of the present invention includes: (1) API Interface Service Layer: Provides a unified abstract application programming interface (API), encapsulates the differences in underlying protocols and models, shields communication details from upper-layer applications, realizes the standardization and service-oriented nature of interface calls, and supports flexible system integration and functional expansion.

[0043] (2)CPltfmData: Responsible for real-time data mirroring and multi-format conversion processing, supporting data structure mapping and semantic alignment between different models and protocols, ensuring efficient data flow and consistent expression in heterogeneous systems.

[0044] (3) SignalEmitter: It adopts an event-driven architecture based on the signal-slot mechanism to realize loosely coupled message communication between modules, improve the responsiveness and concurrent processing capability of the system, and support the efficient distribution and processing of asynchronous events.

[0045] (4) Receiver: Responsible for receiving response data from the database, parsing, verifying and encapsulating it, and feeding back the processed results to the upper-level module or calling interface in a unified format to ensure the integrity and accuracy of data flow.

[0046] (5) Database interaction: It has intelligent adaptation capabilities and can automatically match the corresponding IEC 61850 service interface or power IoT service interface according to the context information of the upper-layer interface call, so as to achieve seamless connection with different data sources and improve the system's compatibility and access efficiency for multi-source heterogeneous databases. Example

[0047] This invention uses the IEC 60870-5-104 protocol parsing module as an independently running micro-application, responsible for handling communication modeling, message parsing, and master station interaction for the 104 protocol. The adaptation layer is integrated into the 104 protocol parsing micro-application as a dynamic link library (DLL or SO), serving as the core component for multi-model fusion and protocol conversion. It provides a unified API interface to support intelligent mapping and data interaction between the IEC 61850 model and the power IoT model.

[0048] All functional interfaces of the adaptation layer are encapsulated through interface classes to ensure the consistency and extensibility of interface calls. The main functional interfaces are defined as follows: (1) Full subscription interface for line remote signaling / telemetry It supports full subscription to remote signaling (YX) or telemetry (YC) data for a specified line, and can receive data change events in real time after subscription. It is suitable for scenarios where a complete data view can be quickly established after the master station is initialized.

[0049] long SubLineYx(int ​​iLineId,const vector<GA_SIGPARAM> & vSigParam); long SubLineYc(int iLineId,const vector<GA_SIGPARAM> & vSigParam); (2) Interface for obtaining current values ​​of telemetry / telecommunications signals Used to obtain the latest value of current telemetry or teleindication data, suitable for single-point query or main station polling scenarios.

[0050] long GetYXValue(GA_YXVALUE& stVal); / / Retrieves remote signal value long GetYCValue(GA_TYCVALUE& stVal); / / Retrieves telemetry value (3) Obtain the line telemetry / telemetry change queue interface Retrieves queue information of changes in remote signaling or telemetry data by line ID, reading one change record from the head of the queue each time. This is suitable for scenarios where the master station receives change data in sequence.

[0051] bool GetLineYxInfo(int iLineId, std::vector<GA_YXVALUE> & stVal); bool GetLineYcInfo(int iLineId, std::vector<GA_TYCVALUE> & stVal); (4) Control command sending interface (remote control, remote adjustment) Supports the issuance of remote control (YK) and remote adjustment (YT) commands. The system allows only one control command to be executed at a time. If a command is currently being executed, the newly issued command will be rejected to prevent concurrent control conflicts.

[0052] long SetYKCmd(GA_YKCMD stCmd); / / Set remote control command long SetYTCmd(GA_YTCMD stCmd); / / Set the remote control command (5) Control command execution result query interface Used to query the execution results of remote control or teleading commands, the system is set to a maximum waiting time of 60 seconds. After the timeout, it will return a failure status to ensure the traceability and security of control operations.

[0053] long GetYKYTReturn(GA_CMDRET& stCmdRet); This invention aims to achieve efficient collaboration and data consistency between the IEC 60870-5-104 protocol and the IEC 61850 model and power IoT model in power systems, supporting real-time data mirroring, subscription push, and command execution across models and protocols. The specific process is as follows: S1: Dynamic loading of model object mapping files The system checks for changes to model object mapping files (such as XML or JSON format) at set intervals (e.g., every minute). If a file update is detected, the latest mapping rules are immediately loaded, ensuring that the system dynamically adapts to model changes without interrupting operation, thus improving the system's flexibility and maintainability.

[0054] S2: CPltfmData Data Initialization and Real-Time Library Mirror Construction Based on the loaded model mapping file and running parameters, the CPltfmData module is initialized to build a real-time data mirror library consistent with the actual device status, providing a unified data view and access interface for subsequent data reading, writing, subscription, and push.

[0055] S3: Configuration-based subscription of telemetry and teleindication data Based on the configuration files of each 104 master station, a subscription request for remote signaling and telemetry data is initiated to the data center to dynamically obtain information on changes in device status and realize real-time monitoring and updating of key data.

[0056] S4: Real-time push notifications of data center changes When the data center detects a change in the subscribed data, it uses an event-driven mechanism to push the updated data to the CPltfmData module in real time, synchronously updating the local mirror library to ensure the consistency and timeliness of local data with the source data.

[0057] S5:104 protocol parser periodically pushes data. The 104 protocol parsing module periodically polls the push queue, encapsulates the changed data in the queue into 104 protocol messages according to the master station's subscription rules, and pushes them to the corresponding 104 master station in a timely manner to ensure the real-time performance and integrity of the data on the master station.

[0058] S6:104 Local Response to Data Read Request When processing remote signaling and telemetry data reading requests from the 104 master station, the protocol parsing program directly retrieves data from the CPltfmData local mirror library, avoiding frequent access to the remote database and improving response speed and overall system performance.

[0059] S7: Asynchronous execution and result feedback of remote control and teleading commands. When a remote control or teleading command is received from the 104 master station, the 104 protocol parsing program forwards the command to the corresponding control module and uses an asynchronous method to query the command execution result through the GetYKYTReturn interface to ensure the reliability and timing consistency of the control operation, while avoiding blocking the main thread and affecting the system response efficiency.

[0060] The advantages of this invention are: 1. Technological advantages (1) High development efficiency: Traditional methods require 3 to 6 months to complete the development of a protocol stack for a single model type, while the configurable method of this invention can shorten the development cycle to no more than 2 weeks, which greatly improves the project's startup speed and ability to respond to market changes.

[0061] (2) Low maintenance cost: Traditional adaptation layer adjustments require code recompilation, which increases the complexity and time cost of maintenance. This invention supports online updates of object mapping configuration files without restarting the system or rewriting the code, thereby significantly reducing the difficulty and cost of maintenance.

[0062] (3) Excellent transmission performance: The instruction transmission delay of traditional solutions is usually between 200 and 500 milliseconds, while the transmission delay of this invention is reduced to no more than 50 milliseconds after optimization by using a synchronous channel, which significantly improves the real-time data processing capability and user experience.

[0063] (4) Strong data fusion capability: Previous technologies have difficulty in achieving cross-model data fusion, which limits the system's compatibility and flexibility. This invention can automatically fuse data from different models, enhancing the system's adaptability and making it suitable for more complex integration environments.

[0064] 2. Economic benefits (1) Reduced development costs: Compared with customized development methods, this solution reduces the amount of protocol adaptation code by more than 70%, effectively reducing R&D costs.

[0065] (2) Improved operation and maintenance efficiency: When the model changes, only the corresponding configuration file needs to be modified. The time required for system restart has been reduced from hours to minutes, which greatly improves operation and maintenance efficiency and service continuity.

[0066] (3) Hardware cost savings: For application scenarios that integrate IEC 61850 and the Internet of Things model, existing old equipment can be fully utilized to avoid unnecessary equipment upgrades or the cost of adding conversion devices.

[0067] 3. Industry promotion value The results of this invention patent are applicable to the following three typical application scenarios: (1) Substation service gateway (IEC61850 system) scenario: In this scenario, the substation service gateway adopts an edge micro-application architecture. The data center is built according to the IEC 61850 standard. The southbound auxiliary control equipment is connected according to this standard, and the northbound auxiliary control system is connected through the 104 protocol.

[0068] (2) Smart converged terminal in distribution area (power IoT model system): The smart converged terminal in distribution area in distribution IoT also adopts the edge micro-application architecture. Its data center is established based on the object model system. The southbound smart terminal equipment is connected according to the IoT model, and the northbound is connected to the distribution IV area main station through the 104 protocol.

[0069] (3) Rapid integration scenario of hybrid photovoltaic power plant system: In the intelligent construction of photovoltaic power plants, the monitoring equipment involved follows the IEC 61850 standard, while the environmental monitoring equipment is based on the Internet of Things system. In order to achieve rapid integration and reduce equipment modification work, the two systems can be deployed in a hybrid manner in the south, while the 104 protocol is used to access the management master station in the north, which simplifies the system integration process.

[0070] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. An IEC104 protocol conversion method based on the fusion of IEC61850 model and power internet of things model, characterized in that, Comprise: Step 1, based on the structural features of the application service data unit (ASDU) in the IEC104 protocol, a three-dimensional address space model composed of type identifier (TYPE-ID), transmission reason (COT) and information object address (IOA) is constructed; wherein, the communication semantic mode is uniquely determined by the (TYPE-ID, COT) binary tuple; Step 2, the communication semantic mode corresponding to the (TYPE-ID, COT) binary tuple is mapped to the standardized API interface operation; Step 3, the mapping relationship between the IEC 61850 model elements and the power internet of things model elements corresponding to the information object address (IOA) is defined by the configuration file; Step 4, according to the communication scene requirement, two kinds of message processing modes of synchronous request-response and asynchronous event driving are designed to ensure the timing consistency and transaction integrity of the control instruction between the IEC104 protocol and the IEC 61850 / MMS protocol or the power internet of things protocol; Step 5, a localized real-time data mirror library is constructed to realize the caching and synchronization of the underlying device data, and the mapping between the protocol data and the model object is completed through the CPitfmData module.

2. The method of claim 1, wherein, In the step 1, The coding range of the type identifier (TYPE-ID) is 0-255, which is used to distinguish different types of messages; The value range of the transmission reason (COT) is 1-127, which is used to identify the transmission characteristics of the message and express the context semantics of the data; The address space range of the information object address (IOA) is 0-16777215, which is used to uniquely identify the specific data object in the device and realize the fine-grained addressing of the power equipment.

3. The method of claim 2, wherein, In the step 2, Based on the type identifier (TYPE-ID) and the transmission reason (COT), three kinds of core function interface types are defined, which are: Synchronous read interface sync_read: suitable for the scene where the type identifier (TYPE-ID) is 1, 3, 9, 13 or 30 and the transmission reason is 2, used for synchronous reading of remote signaling and remote measurement data; Asynchronous write interface async_write: suitable for the scene where the type identifier is 45, 46 or 200 and the transmission reason is 6, used for asynchronous execution of remote control and remote adjustment operation; Event subscription interface event_sub: suitable for the scene where the type identifier is 9, 13 or 42 and the transmission reason is 3, used for subscribing to event notifications such as remote signaling state change; Among them, The specific API interfaces corresponding to the synchronous read interface sync_read include: GetYXValue: get the current remote signaling data, GetYCValue: get the current remote measurement data, GetLineYxInfo: get the remote signaling change queue data of the specified master station, GetLineYcInfo: get the remote measurement change queue data of the specified master station; The specific API interfaces corresponding to the asynchronous write interface async_write include: SetYKCmd: set remote control command, SetYTCmd: set remote adjustment command, GetYKYTReturn: get the execution result of the remote control and remote adjustment command. The specific API interface corresponding to the event subscription interface event_sub includes: SubLineYx, which subscribes to the full information of the remote signaling of the master station, and SubLineYc, which subscribes to the full information of the remote measurement of the master station.

4. The method of claim 3, wherein, In the step 3, Through the unified communication service API interface, bidirectional mapping between the IEC 61850 model and the power internet of things model is realized, and semantic alignment and data conversion across models and protocols are supported. Specifically, the method comprises: (1) IEC 61850 interaction mapping based on communication service API Request-response mode: Synchronous data operation: the corresponding API interface is GetYXValue, GetYCValue, GetLineYxInfo and GetLineYcInfo; Asynchronous command operation: the corresponding API interface is SetYKCmd, SetYTCmd and GetYKYTReturn; Subscription-published mode: Subscription stage: the corresponding API interface is SubLineYx and SubLineYc; Published stage: the corresponding API interface is GetLineYxInfo and GetLineYcInfo; (2) Power internet of things model interaction mapping based on communication service API Get operation: the corresponding API interface is GetYXValue, GetYCValue, GetLineYxInfo and GetLineYcInfo; Set operation: the corresponding API interface is SetYTCmd and GetYKYTReturn; Action operation: the corresponding API interface is SetYKCmd and GetYKYTReturn; Report operation: the corresponding API interface is GetLineYxInfo and GetLineYcInfo; (3) Object mapping The mixed protocol mapping configuration of object mapping is realized by using a configuration file, and dynamic loading and online updating of the configuration file are supported.

5. The method of claim 4, wherein, In the step 4, The path of the synchronous request-response message processing mode is: API request→CPltfmData data mirror→SignalEmitter signal distribution→Receiver data processing→database interaction→return result; The path of the asynchronous event-driven message processing mode is: database change event→SignalEmitter push→Receiver processing→CPltfmData mirror update→notify upper module.

6. The method of claim 5, wherein, The step 4 further comprises a timeout message recycling strategy; The timeout message recycling strategy is: when the synchronous message response is timed out, the system automatically converts it into an asynchronous channel processing.

7. The method of claim 5, wherein, In the step 5, A local data mirror library is maintained in the adaptation layer, and the synchronous mechanism is actively triggered by a data mirror library change event.

8. An IEC104 protocol conversion system based on IEC61850 model and fusion of power internet of things model, characterized in that, It comprises: A model unified abstraction module for realizing steps 1-2 of the method in any one of claims 1-7; A model mapping module for realizing step 3 of the method in any one of claims 1-7; a message handling and real-time library mapping module for implementing steps 4-5 of the method of any of claims 1-7.

Images