Communication server self-adaption method and device for IEC61850 multi-protocol version

Abstract

The invention discloses an IEC61850 multi-protocol version oriented communication server-side self-adaption method and device, and the method comprises the steps: carrying out the protocol version dynamic recognition, service interface dynamic configuration and service interface dynamic response for IEC61850 standard protocol versions including ED1.0, ED2.0 and ED2.1, and forming a differential processing mechanism for different protocols, and the automatic switching of the ED1.0 / ED2.0 / ED2.1 protocol can be realized. According to the invention, through compatibility adaptive processing of different versions of difference communication services, system configuration complexity caused by protocol version difference and multi-version maintenance cost of device software are reduced, so that diversified requirements of a power system in multi-scene application and internationalized markets are met; and the flexibility of system configuration and the reliability of device operation are improved.

Description

Technical Field

[0001] The present invention relates to a power communication service end adaptation method and device, and in particular to a communication service end adaptation method and device oriented to IEC61850 multi-protocol versions, belonging to the technical field of power secondary equipment. Background Art

[0002] As the core international specification for power automation, the IEC 61850 standard has evolved from version ED1.0 to ED2.0 and has now been updated to ED2.1. These upgrades primarily encompass data models and communication services. However, structural adjustments to the data model and functional expansion of communication services between versions have led to model conflicts and communication incompatibilities during device interoperability, creating cross-version communication barriers and hindering the widespread application of the standard.

[0003] In terms of data model: ED2.0 version expands the number of logical nodes (LN) to 170, adding process control LN and 6 common data classes (CDC). ED2.1 version further adds distributed energy-specific LN. Although forward compatibility is maintained at the basic model level, a unified mapping mechanism has not yet been established for the differentiated data semantics formed by functional expansion.

[0004] Regarding communication services, significant differences existed between versions in the implementation of key features such as the Reporting Service Control Block (RCB) parameter configuration and the logging service interface protocol. These issues, such as parameter incompatibility and inconsistent operational logic, led to communication failures or the inability to correctly parse communication data. Operations and maintenance personnel were forced to manually configure multiple communication parameter templates for adaptation, severely lacking the dynamic adaptive capabilities required for protocol feature recognition.

[0005] UCAIug (IEC61850 International Certification Authority) ceased certification for ED2.0 and earlier versions in 2024, and ED2.1 certification began in 2021. Research on international market applications reveals that in recent years, the European Union, as a driving force behind the ED2.1 standard, has explicitly mandated that the monitoring functions of grid-connected photovoltaic equipment comply with the IEC61850 ED2.1 communication protocol standard. In Southeast Asia, IEC61850 applications coexist with ED1.0 and ED2.0 versions, with ongoing upgrades. Over 90% of domestic substation automation systems are based on ED1.0, requiring separate specifications for device modeling and communication service applications. This regional differentiation forces equipment vendors to maintain multiple versions of communication software, increasing development and maintenance costs.

[0006] Existing technologies only provide configuration tools, client, and server-side compatibility for the coexistence of IEC61850 ED1.0 and ED2.0 models. These technologies primarily describe the configuration tool's workflow and methods for handling coexisting models, but fail to address server-side strategies for adaptive multi-version protocol adaptation and dynamic response. Furthermore, existing technologies fail to differentiate between service versions and are unable to adapt to the latest ED2.1 version.

[0007] The compatibility issues brought about by multiple versions of the IEC61850 standard are mainly reflected in the lack of a mechanism to perceive the characteristics of the protocol version, insufficient cross-version service semantic conversion capabilities, and gaps in differentiated adaptation strategies for regional standards. Summary of the Invention

[0008] Purpose of the Invention: This invention provides a communication server-side adaptive method for IEC61850 multi-protocol versions. This method, applicable to substation relay protection devices and other power secondary intelligent electronic devices, enables the communication server to analyze protocol version characteristics and handle the differences between multiple communication service versions, thereby enabling communication with IEC61850 clients and reducing the development and maintenance costs of multi-version protocol stack software for device manufacturers. Another object of the invention is to provide a communication server-side adaptive device based on this method.

[0009] Technical solution: The communication server adaptation method for IEC61850 multi-protocol versions of the present invention includes the following steps:

[0010] (1) Dynamically identify protocol versions, including IEC61850 ED1.0, ED2.0, and ED2.1;

[0011] (2) Differentiated configuration of communication service interfaces for different protocols;

[0012] (3) When the client issues a request operation, the communication service interfaces of different protocols respond differently.

[0013] Optionally, the rules for dynamic identification in step (1) include:

[0014] If the IED element attributes originalSclVersion, originalSclRevision, and originalSclRelease of the parsed model CID file are not configured, the default values ​​of these attributes are 2003, A, and 1, respectively. In this case, the server protocol version is ED1.0.

[0015] If originalSclVersion is configured as 2003, the server protocol version is ED1.0.

[0016] If originalSclVersion is set to 2007 and originalSclRevision is set to A; or if originalSclVersion is set to 2007 and originalSclRevision is set to B, and originalSclRelease is not set or is set to 4 or lower, the server protocol version is ED2.0.

[0017] If originalSclVersion is set to 2007, originalSclRevision is set to B, and originalSclRelease is set to 4 or above, the server protocol version is ED2.1.

[0018] Optionally, step (2) includes configuring at least one of the following services for different protocol versions, including but not limited to: a reporting service, a fixed value service, and a log service.

[0019] Optionally, reporting services for different protocol versions can be configured based on the report control block attributes and the dynamic declaration principle of ReportSettings in the model.

[0020] Optionally, for fixed value services of different protocol versions, they can be configured according to fixed value control block attributes and according to model dynamic mapping principles.

[0021] Optionally, for log services of different protocol versions, they can be configured according to the log management granularity and LogReference format mapping principles.

[0022] Optionally, the configuration of the reporting service includes:

[0023] When the protocol is ED1.0, the model report control block does not add the ResvTms and Owner attributes;

[0024] When the protocol is ED2.0 or ED2.1, the ResvTms and Owner declarations in the ReportSettings of the Services element in the IED element of the model are parsed to determine whether they are configured. If not configured, the model control block does not add this attribute. If configured and the value is TRUE, this attribute is added.

[0025] Optionally, the configuration of the fixed value service includes:

[0026] When the protocol is ED1.0, the ResvTms attribute is not added to the constant value control block; when the protocol is other versions, the ResvTms attribute is added;

[0027] When the protocol is ED1.0, the fixed value model FC=SG maps the dynamic FC=SE copy; when the protocol is ED2.0 or ED2.1, the fixed value model FC=SE maps the dynamic FC=SG copy.

[0028] Optionally, the configuration of the log service includes:

[0029] When the protocol is ED1.0, the LogReference format is LDName / LDName;

[0030] When the protocol is ED2.0 or ED2.1, the LogReference format is LDName / LNName.LogName.

[0031] Optionally, the step (3) includes: dynamically responding to the report service and the log service accordingly.

[0032] The dynamic response of the report service includes: the client responding according to the ResvTms and Owner attribute operations; the server sending the code of the reason in the report item according to different protocols;

[0033] The dynamic response of the log service includes: constructing a variable tag and a valueSpecification according to the mapping rules from reasonCode to protocol log entry MMS under different protocol versions.

[0034] Optionally, the client responding according to the ResvTms and Owner attribute operations includes:

[0035] When the protocol is ED1.0, any operation request involving the ResvTms and Owner attributes will be rejected and a negative response will be returned;

[0036] When the protocol is ED2.0, the specific behavior is determined by the device model configuration;

[0037] When the protocol is ED2.1, based on the requirements of the ED2.0 protocol, there are strict restrictions on the enabling of the report control block. The enabling of the report control block must first meet the following conditions: ResvTms>0 or Resv=true, otherwise a negative response is returned.

[0038] Optionally, the code of the reason in the report entry sent by the server includes:

[0039] When the protocol is ED1.0 or ED2.1, a 6-bit bit string encoding is used;

[0040] When the protocol is ED2.0, a 7-bit bit string encoding is used, and an application-trigger bit is added to mark reports actively triggered by the application layer.

[0041] Optionally, the construction of the variable tag includes:

[0042] When the protocol is ED1.0, it is mapped to "LD1 / MMXU.MX.V|reasonCode";

[0043] When the protocol is ED2.0, it is mapped to "LD1 / MMXU$MX$V|reasonCode";

[0044] When the protocol is ED2.1, it is mapped to "ReasonCode".

[0045] Optionally, the construction of the valueSpecification includes:

[0046] When the protocol is ED1.0, 6-bit bit string encoding is used.

[0047] When the protocol is ED2.0 or ED2.1, a 7-bit bit string encoding is used and an application-trigger bit is added to distinguish log records actively requested by the application.

[0048] The communication server adaptation device for IEC61850 multi-protocol version includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, some or all of the steps in the above-mentioned communication server adaptation method for IEC61850 multi-protocol version are implemented.

[0049] Beneficial effects: Compared with the existing technology, the present invention has the following significant advantages: through the analytical model, the dynamic identification of protocol versions, service differentiation configuration and service differentiation dynamic response functions are realized in sequence, and the adaptive switching of ED1.0, ED2.0 and ED2.1 protocols by the IEC61850 server is realized. By establishing a protocol version identification mechanism and clarifying the rule division standards between different versions, the risk of protocol downgrade can be effectively prevented and the accuracy of version matching can be ensured; at the same time, differentiated service configuration and response compatibility processing are performed according to different protocol versions to improve communication accuracy. The present invention can meet the diverse needs of smart substations, new energy stations and cross-border projects, and improve system flexibility and reliability. BRIEF DESCRIPTION OF THE DRAWINGS

[0050] Figure 1 This is a flow chart of the version identification rules in the method of the present invention. DETAILED DESCRIPTION

[0051] The technical solution of the present invention will be further described below with reference to the accompanying drawings.

[0052] The communication server adaptation method for IEC61850 multi-protocol version includes the following steps:

[0053] (1) Dynamic identification of protocol version.

[0054] (11) Based on the following specifications and in combination with communication requirements, according to the protocol version information, the following attributes are configured first in the device ICD modeling phase.

[0055] The IEC 61850-6 (Edition 2.1 2018-06) specification specifies the syntax and semantics of the substation configuration description language (SCL). In the device model file (ICD file), the standard version can be set by configuring element classes such as originalSclVersion, originalSclRevision, and originalSclRelease.

[0056] originalSclVersion indicates the major version number of the SCL schema of the IED configuration file (such as "2003" corresponds to ED1.0, and "2007" corresponds to ED2.0). originalSclRevision indicates the revision number or minor version number of the SCL schema of the IED configuration file (such as "A" and "B"), which is used to distinguish functional updates or patches under the same major version. originalSclRel ease indicates the update release of the SCL schema of the IED configuration file.

[0057] (12) Figure 1 As shown, based on the above IEC61850 specification requirements, the protocol version is dynamically identified as follows:

[0058] The server parses the IED element attributes originalSclVersion, originalSclRevision, and originalSclRelease in the model CID file and distinguishes ED1.0, ED2.0, and ED2.1 based on the attribute values ​​and the protocol version division rules. The protocol version rules are as follows:

[0059] 1) If the model is not configured with the above properties, the default value of originalSclVersion is 2003, the default value of originalSclRevision is A, and the default value of originalSclRelease is 1, then the server protocol version is ED1.0;

[0060] 2) If originalSclVersion is configured as 2003, the server protocol version is ED1.0;

[0061] 3) If originalSclVersion is set to 2007 and originalSclRevision is set to A, the server protocol version is ED2.0;

[0062] Alternatively, if originalSclVersion is set to 2007, originalSclRevision is set to B, and originalSclRelease is not set or is set to 4 or less, the server protocol version is also ED2.0.

[0063] 4) If originalSclVersion is set to 2007, originalSclRevision is set to B, and originalSclRelease is set to 4 or above, the server protocol version is ED2.1.

[0064] (2) Differentiate the configuration of communication service interfaces for different protocols.

[0065] The communication service interface configuration, i.e., the initialization of the communication service interface, is described. The IEC61850 protocol includes multiple services, among which reporting services, fixed value services, and logging services vary significantly between different protocol versions. To address these differences, the present invention configures one or more of the reporting services, fixed value services, and logging services for different versions of the communication service interface, as appropriate. For example, for relay protection devices or dispatch master stations, these three services generally require compatibility configuration.

[0066] To achieve compatibility among model services, data services, and dataset services, and to achieve unified configuration, the following are provided:

[0067] Table 1 shows the differentiated service configuration method.

[0068]

[0069]

[0070] Table 1 Differentiated service configuration

[0071] (21) Report service configuration

[0072] According to the evolution of the IEC 61850-7-2 standard, ED2.0 and subsequent versions enhance the management of report control block operation permissions by adding optional ResvTms (retention time) and Owner (owner identification) attributes. Report control blocks of different protocol versions are configured as follows:

[0073] 1) When the protocol is ED1.0, the model report control block does not add the ResvTms and Owner attributes;

[0074] 2) When the protocol is ED2.0 or ED2.1, the ResvTms and Owner declarations in the Services element ReportSettings of the model IED element are parsed to determine whether they are configured. If not, the model control block does not add these attributes. If they are configured and set to TRUE, the model control block does add these attributes. For example, if ResvTms = TRUE is declared in the IED element → Services element → ReportSettings element, the ResvTms attribute is added during report control block configuration; if Owner = TRUE is not declared, the report control block does not add the Owner attribute.

[0075] (22) Fixed value service configuration

[0076] The properties of the fixed value control block and the principles of dynamic mapping based on the model vary. Different protocol versions are configured as follows:

[0077] 1) When the protocol is ED1.0, the ResvTms attribute is not added to the constant value control block; when the protocol is other versions, the ResvTms attribute is added;

[0078] 2) When the protocol is ED1.0, the fixed value model FC=SG maps to the dynamic FC=SE copy; when the protocol is ED2.0 or ED2.1, the fixed value model FC=SE maps to the dynamic FC=SG copy.

[0079] (23) Log service configuration

[0080] Log management has been adjusted from logical device (LD) management to logical node (LN) management to achieve refined log management. Logs for different protocol versions are configured as follows:

[0081] 1) When the protocol is ED1.0, the LogReference format is LDName / LDName;

[0082] 2) When the protocol is ED2.0 / ED2.1, the LogReference format is LDName / LNName.LogName.

[0083] (3) When the client issues a request operation, the communication service interfaces of different protocols respond differently, as shown in Table 2 below.

[0084] Table 2 Differentiated service dynamic response

[0085]

[0086] (31) Dynamic responses of the reporting service include:

[0087] 1) Client response to ResvTms and Owner attribute operations

[0088] When the protocol is ED1.0, the ResvTms and Owner attributes are not defined, so any operation request involving these two attributes (such as read, set, etc.) will be rejected and a negative response will be returned.

[0089] When the protocol is ED2.0, the ResvTms and Owner attributes are fully supported, and their specific behavior is determined by the device model configuration.

[0090] When the protocol is ED2.1, based on the ED2.0 requirements, the reporting control block enable is further strictly restricted. The reporting control block enable needs to meet the conditions (ResvTms>0 or Resv=true) first, otherwise a negative response is returned.

[0091] 2) The code of the reason (reasonCode) in the report item sent by the server

[0092] When the protocol is ED1.0 or ED2.1, 6-bit bit string (bitstring6) encoding is used.

[0093] When the protocol is ED2.0, a 7-bit bit string (bitstring7) encoding is used, and an application-trigger bit (bit6) is added to mark the report actively triggered by the application layer.

[0094] (32) Dynamic response of log service.

[0095] Log entry content is stored in a unified format. According to the IEC61850-8-1 specification, the mapping of reasonCode to MMS rules varies across different protocol versions, primarily in the mapping of variabletag and valueSpecification to MMS protocol log entries. Therefore, the dynamic response of the log service includes:

[0096] 1) The variable tag that constitutes the log entry.

[0097] When the protocol is ED1.0, it is mapped to "LD1 / MMXU.MX.V|reasonCode" (separated by periods).

[0098] When the protocol is ED2.0, the mapping is "LD1 / MMXU$MX$V|reasonCode" (separated by $).

[0099] When the protocol is ED2.1, it is mapped to "ReasonCode" (simplified format).

[0100] 2) The valueSpecification (bitstring format) that constitutes the log entry.

[0101] When the protocol is ED1.0, bitstring6 encoding is used.

[0102] When the protocol is ED2.0 / ED2.1, bitstring7 encoding is used and a new seventh bit (application-trigger) is added to distinguish log records actively requested by the application.

[0103] The present invention also provides a device for executing the communication server adaptation method for IEC61850 multi-protocol versions, comprising a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the computer program, some or all of the steps in the communication server adaptation method for IEC61850 multi-protocol versions are implemented.

Claims

1. A communication server adaptation method for IEC61850 multi-protocol versions, characterized in that: The method comprises the following steps: (1) Dynamically identify protocol versions, including IEC61850 ED1.0, ED2.0, and ED2.1; (2) Differentiated configuration of communication service interfaces for different protocols; (3) When the client issues a request operation, the communication service interfaces of different protocols respond differently.

2. The communication service end adaptation method for IEC61850 multi-protocol version according to claim 1 is characterized in that: The rules for dynamic identification in step (1) include: If the IED element attributes originalSclVersion, originalSclRevision, and originalSclRelease of the parsed model CID file are not configured, the default values ​​of these attributes are 2003, A, and 1 respectively. In this case, the server protocol version is ED1.

0. If originalSclVersion is configured as 2003, the server protocol version is ED1.0; If originalSclVersion is set to 2007 and originalSclRevision is set to A; or if originalSclVersion is set to 2007 and originalSclRevision is set to B, and originalSclRelease is not set or is set to 4 or less, the server protocol version is ED2.

0. If originalSclVersion is set to 2007, originalSclRevision is set to B, and originalSclRelease is set to 4 or above, the server protocol version is ED2.

1.

3. The communication service end adaptation method for IEC61850 multi-protocol version according to claim 1 is characterized in that: The step (2) includes configuring at least one of the following services for different protocol versions: a reporting service, a setting value service, and a log service; The reporting services of different protocol versions are configured according to the dynamic declaration principle of ReportSettings in the report control block attributes and models; The fixed value services of different protocol versions are configured according to the fixed value control block attributes and according to the model dynamic mapping principle; Log services for different protocol versions are configured based on the log management granularity and LogReference format mapping principles.

4. The communication service end adaptation method for IEC61850 multi-protocol version according to claim 3 is characterized in that: The configuration of the reporting service includes: When the protocol is ED1.0, the model report control block does not add the ResvTms and Owner attributes; When the protocol is ED2.0 or ED2.1, the ResvTms and Owner declarations in the ReportSettings of the Services element in the IED element of the model are parsed to determine whether they are configured. If not configured, the model control block does not add this attribute. If configured and the value is TRUE, this attribute is added.

5. The communication service end adaptation method for IEC61850 multi-protocol version according to claim 3 is characterized in that: The configuration of the fixed value service includes: When the protocol is ED1.0, the ResvTms attribute is not added to the constant value control block; when the protocol is other versions, the ResvTms attribute is added; When the protocol is ED1.0, the fixed value model FC=SG maps the dynamic FC=SE copy; when the protocol is ED2.0 or ED2.1, the fixed value model FC=SE maps the dynamic FC=SG copy.

6. The communication service end adaptation method for IEC61850 multi-protocol version according to claim 3, characterized in that: The configuration of the log service includes: When the protocol is ED1.0, the LogReference format is LDName / LDName; When the protocol is ED2.0 or ED2.1, the LogReference format is LDName / LNName.LogName.

7. The communication service end adaptation method for IEC61850 multi-protocol version according to claim 1, characterized in that: The step (3) includes: performing corresponding dynamic responses to the report service and the log service; wherein, The dynamic response of the report service includes: the client responding according to the ResvTms and Owner attribute operations; the server sending the code of the reason in the report item according to different protocols; The dynamic response of the log service includes: constructing a variable tag and a valueSpecification according to the mapping rules from reasonCode to protocol log entry MMS under different protocol versions.

8. The communication service end adaptation method for IEC61850 multi-protocol versions according to claim 7, characterized in that: The client responds according to the ResvTms and Owner attribute operations, including: When the protocol is ED1.0, any operation request involving the ResvTms and Owner attributes will be rejected and a negative response will be returned; When the protocol is ED2.0, the specific behavior is determined by the device model configuration; When the protocol is ED2.1, based on the requirements of the ED2.0 protocol, strict restrictions are imposed on the reporting control block enablement, so that the reporting control block enablement meets the conditions: ResvTms>0 or Resv=true, otherwise a negative response is returned; The reason code in the report item sent by the server includes: When the protocol is ED1.0 or ED2.1, a 6-bit bit string encoding is used; When the protocol is ED2.0, a 7-bit bit string encoding is used, and an application-trigger bit is added to mark reports actively triggered by the application layer.

9. The communication service end adaptation method for IEC61850 multi-protocol versions according to claim 7, characterized in that: The construction of the variable tag includes: When the protocol is ED1.0, it is mapped to "LD1 / MMXU.MX.V|reasonCode"; When the protocol is ED2.0, it is mapped to "LD1 / MMXU$MX$V|reasonCode"; When the protocol is ED2.1, it is mapped to "ReasonCode"; The construction of the valueSpecification includes: When the protocol is ED1.0, 6-bit bit string encoding is used. When the protocol is ED2.0 or ED2.1, a 7-bit bit string encoding is used and an application-trigger bit is added to distinguish log records actively requested by the application.

10. A communication server adaptation device for IEC61850 multi-protocol versions, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the communication service end adaptation method for IEC61850 multi-protocol version is implemented as described in any one of claims 1 to 9.

Images