CN111131214B - Method for converting SV message into R-SV message between transformer substations - Google Patents
Method for converting SV message into R-SV message between transformer substations Download PDFInfo
- Publication number
- CN111131214B CN111131214B CN201911309175.XA CN201911309175A CN111131214B CN 111131214 B CN111131214 B CN 111131214B CN 201911309175 A CN201911309175 A CN 201911309175A CN 111131214 B CN111131214 B CN 111131214B
- Authority
- CN
- China
- Prior art keywords
- message
- length
- information
- session
- identifier
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/08—Protocols for interworking; Protocol conversion
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/06—Notations for structuring of protocol data, e.g. abstract syntax notation one [ASN.1]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
The invention discloses a method for converting SV messages into R-SV messages between substations, which comprises the following steps: s1, forming an R-SV message template according to the basic structure of the R-SV message; s2, dividing the R-SV message template into SV message information, routing information and check encapsulation information; s3, mapping the obtained SV message information to a position corresponding to an R-SV message template in a memory; s4, extracting the routing information from the SCL file; s5, filling the routing information extracted in the step S4 into a message domain related to the R-SV message and the routing information, and putting the message domain into a memory; and S6, filling the checking encapsulation information of the R-SV message template. The invention breaks through the limitation of the transmission of the traditional SV message in the transformer substation, and can quickly construct the R-SV message according to the original SV message, thereby realizing the transmission of information among a plurality of transformer substations and realizing the interconnection and intercommunication of information among the transformer substations.
Description
Technical Field
The invention belongs to the technical field of protection, control and automation of electric power systems, and particularly relates to a method for converting SV messages into R-SV messages between substations.
Background
With the deep development of the smart grid, the power information system depends more on the communication network and transmits information representing power protection, control and automation states and commands thereof in a message form. A general object-oriented substation event (SV) message is used as an important message [1-2] of an intelligent substation for representing operation commands of tripping, closing and the like of a breaker and breaker position information, and is originally limited in a substation to extend to the whole power system to form an R-SV message with a routing function.
The SV message is only limited to be transmitted inside the transformer substation, and the traditional SV message lacks a transmission layer and a network layer structurally, so that the traditional SV message lacks a related routing function, and information interconnection and intercommunication between the transformer substation and the transformer substation cannot be realized. The R-SV message has a routing function, and the defect that the SV message cannot be applied to electric power wide area information is overcome. However, the R-SV message mentioned in the present R-SV message such as the second Reza Firouzi, Luigi Vanfretti, Albert Ruiz-Alvarez, et al, intervening and completing IEC 61850-90-5Routed-Sampled Value and Routed-GOOSE protocols for IEEE C37.118.2compliant wire-area synchronized vector data transfer [ J ]. Electric Power Systems Research,2017,144, etc. needs to be directly realized by means of a special communication protocol stack, and does not have the ability of converting SV message into R-SV message.
Disclosure of Invention
The invention aims to solve the defects of the prior art and provides an R-SV message which can meet the IEC 61850-90-2 standard so as to realize the transmission of the SV message between substations. Because the R-SV message is transmitted in the special power network, the safety is high, and the content related to the safety algorithm is ignored by default. Because the traditional power microcomputer equipment with lower configuration is difficult to realize the object-oriented modeling and the processing of a protocol stack, a template can be generated in advance during the concrete implementation. The content of the whole R-SV message is divided into three parts: SV message information, routing information and verification encapsulation information.
The invention is realized by at least one of the following technical schemes.
The method for converting the SV message into the R-SV message between the transformer substations comprises the following steps:
s1, forming an R-SV message template according to the basic structure of the R-SV message;
s2, dividing the R-SV message template into SV message information, routing information and check encapsulation information;
s3, mapping the obtained SV message information to a position corresponding to an R-SV message template in a memory;
s4, extracting the routing information from the SCL file;
s5, filling the routing information extracted in the step S4 into a message domain related to the R-SV message and the routing information, and putting the message domain into a memory;
and S6, filling the checking encapsulation information of the R-SV message template.
Further, message domains needing to be filled in the R-SV message basic structure are sequentially arranged to form an R-SV message template
Further, the SV message information includes an integer number (noASDU), a sequence of ASDUs (Sequences of ASDUs), an ASDU, MsvID, a Dataset (Dataset), a sampling counter (SmpCnt), a configuration version number (ConfRev), a transmission buffer refresh time (RefrTm), a boolean number (smpSynch), a sampling number in a rated period (smpRate), sample data (sample), a sample mode (smpMod), and a time stamp t.
Specifically, the ASN1 encoding rule follows the format of Tag (also called Type), Length, Value, TLV for short. In the following, except that the information content such as the voltage of the sample does not comply with the TLV, the rest comply with the TLV:
1. noASDU: tag: filled with 0X80, a value of Tag, conforming to the TLV encoded format using ASN 1; length: 0X 02;
sequences of ASDUS: tag: 0XA 2;
ASDU: tag: 0X 30;
MsvID: unique identifier of MSDU, Tag: 0X 80;
dataset: tag: fill 0X81 as an optional field;
SmpCnt: tag: 0X 82; length: 0X 02;
ConfRev: tag: 0X 83; length: 0X 04;
RefrTm: tag: 0X 84; length: fill 0X08 as an optional field;
smpSynch: tag: 0X 85; length: 0X 01;
smpRate: tag: 0X 86; length: 0X 02;
sample: tag: 0X 87;
smpMod: tag is 0X 88; length: fill 0X02 as an optional field;
13, t: tag: 0X 89; length: fill 0X08 as an optional field;
wherein Tag (identifier) occupies 1 or two bytes, and Bit7 (7 th Bit) and Bit6 (6 th Bit) are 10: Contest-Specific, context-dependent, Bit5 is selected to be 0, i.e., 0X 80; length indicates how many bytes the VALUE of VALUE is made up of; VALUE is the encoded content that is actually to be delivered.
Further, step S3 maps the SV packet information to the relevant packet domain of the R-SV packet in a direct mapping manner.
Further, the routing information in step S4 includes a Destination physical Address (Destination MAC Address), a Source physical Address (Source MAC Address), an IP type, a Version number (Version) of the IP Protocol, a Header Length (IHL) of the IP, a dscp (differentiated Services Code point), an ECN, a Total Length of the IP packet (Total Length), an Identifier (Identification), a Flag (Flag), a Fragment Offset (Fragment Offset), a ttl (time to live), a Protocol (Protocol), a Header check (Header check), a Source IP Address (Source IP Address), a Destination IP Address (Destination IP Address), a Source Port (Source Port), a Destination Port (Destination Port), a Length Identifier (LI), a Transmission Identifier (TI), a Session Identifier (SI), a Session layer Protocol data unit Length Identifier (Length), a Session constant layer Session Length (Identifier), a Header Session Length (Session layer Session Length), and a Header Length unit Length (Header Length), a Header Length, a Header Length, a Header Length, a Header Length, a, Length of session layer protocol data unit (SPDU Length), session protocol Version Number (SPDU Number, Version Number), Time allowed for current key (Time of current key), Time to next key (Time to next key), Security Algorithm, key id (key id), Payload Length, Payload type (Payload type), emulation (Simulation), apdi, and apde Length.
Specifically, the Destination MAC Address: the destination physical address, that is, the physical address of one or more ends of the received message, is the destination MAC address of the SV message actually sent by the sending apparatus. The address is used as one of the identification marks of the receiving device, occupies 6 bytes and is obtained by the prior configuration;
the Source MAC Address: the physical address of the source, that is, the physical address of the end sending the message, is the physical address of the physical network card of the sending device, and the MAC chip is determined when leaving the factory and does not change with the program and the application. 6 bytes are occupied, and the data is obtained by pre-configuration;
the IP type is as follows: filling out 0x0800 for an IP type according to the Ethernet encapsulation type (RFC 894);
the Version: the version number of the IP protocol used for this datagram takes 4 bits. A common IPv4 protocol is generally adopted in the IEC6150-90-5 message, and 0x04 is filled to represent IPv 4;
the IHL is characterized in that: indicating the header length of the IP, which takes 4 bits. The minimum length of the IP header is 20 bytes, and since a variable-length option is included in the header, the maximum length may become 60 bytes. This is the total length of all headers, obtained in IPv 4;
the DSCP (differentiated Services Code Point) represents a differentiated Services Code point, occupies 6bits, renames the 1 byte used by the type of service (TOS) in the IPv4 header, and is used for marking data, defining priority and defining 64 different types of Services (0-63) at most. Where EF denotes unimpeded Forwarding (EF) is defined by RFC2598, DSCP value 0X46 (101110). The EF service is suitable for services with low packet loss rate, low delay, low jitter and guaranteed bandwidth, and the rest 2bits are occupied by ECN and are not filled;
the Total Length: expressed as the total length of the IP message, the maximum length of the IP message is 65535 bytes, namely the length of IHL plus IP payload occupies 2 bytes, and is extracted from the IPv4 structure. The segmentation operation (Fragment) contains the following three parts:
identification-representing identifier, which takes 2 bytes and contains an integer, is used to identify the current datagram. This is a sequence number. The field is used together with flag and Fragment Offest fields to segment (Fragment) the large upper layer packet;
flag, which represents flag bit, occupies 3bits, and is used for controlling and identifying the fragments, wherein:
bit 0 must be 0;
bit 1 (DF) is 0 to indicate that grouping can be carried out, and 1 to indicate that the grouping can not be fragmented;
bit 2 (MF) is 0 to indicate that the data segment is the last data segment in the packet, 1 to indicate that the data segment is also followed, and the data segment is extracted from IPv 4;
fragment Offset: the segment offset is indicated. Occupying 13 bits. Indicating the location of the segment in the data packet for reassembly of the data segment. This field allows the tag field to terminate at a 16Bit boundary, extracted from IPv 4;
flag and Fragment Offset occupy 2 bytes in total;
the TTL (time to live): indicating the time to live, which takes 1 byte. Indicating the time in seconds that the packet is allowed to remain in the network transmission. When the timer is 0, the datagram will be discarded. Filling hexadecimal 0xff of the maximum survival time 255s in order to avoid the message from existing in the network all the time;
the Protocol: 1 byte is occupied, which marks which upper layer protocol will receive the data after the IP processing process is finished, wherein TCP is represented by 6, and UDP is represented by 17; can be extracted from IPv 4;
the Header check represents that the Header check occupies 2 bytes and is used for checking the correctness of the IP data packet, a sender fills in the data packet after calculation according to the check sum standard, a receiver checks the data, if the data packet is not sent wrongly, the 16 bits of the result are all 1, namely 0XFF, and each router has to recalculate the check sum because each router reduces the TTL value;
the Source IP Address: 4 bytes are occupied, the IP address of the sending node is indicated, and the IP address is extracted from IPv 4;
the Destination IP Address: 4 bytes are occupied, the IP address of the receiving node is indicated, and the IP address is extracted from IPv 4;
the Source Port: indicating the starting port, takes 2 bytes. Filling in according to the actual port number when the other party needs to return, and setting the value to be 0 if the other party does not use the port number;
the Destination Port: the target port number occupies 2 bytes, has significance under the condition of a special Internet target address and is filled according to an actual delivery message port;
LI is a length identifier, here 0x 01;
TI, a transmission identifier, here 0x 40;
the SI is the session identifier: represented by the 4 hexadecimal values defined, 0xA 0: a tunnel GOOSE and a sampling value packet; 0xA 1: a non-tunnel GOOSE application protocol data unit; 0xA 2: non-tunnel SV APDUs; 0xA 3: non-tunnel management APDUs, here filled with 0xA 2;
the Length Identifier of a Session layer protocol data unit (SPDU) follows the Session Identifier (SI), and covers the Length of all parameter fields of a Session Header, namely a hexadecimal expression from Common Session Header to Key ID byte Length is 0x 18;
the Common Session Header is a Session layer Header constant and is also a Parameter Identifier (PI) as the beginning of a parameter unit. Typically filled with the hexadecimal value 0x 80;
the Length Identifier: the length identifier of the parameter unit occupies one byte, namely a hexadecimal expression of the length from the SPDU to the Key ID byte is 0x 16; the Parameter Values (PV) of the parameter units contain the following data:
SPDU Length represents the Length of the whole session layer protocol data unit, takes 4 bytes, and is filled in by the actual condition;
SPDU Number is fixed with 4 bytes, used for checking whether there is repeat or unordered data packet transmission, and defined by itself;
version Number, two fixed bytes, filling 0x0004 representing IPv 4;
security Information Security management of application layer data encapsulated in a Session protocol, provided by the specific Key Distribution Center (KDC) protocol of IEC-61850-95, occupying 12 bytes and consisting of:
the Time of current key, the Time allowed by the current key, takes 4 bytes and is defined by self according to the actual situation;
the Time to next key is the Time to the next key, which takes 2 bytes and is defined by the user according to the actual situation;
the Security Algorithm indicates that the encryption type and the Algorithm information generated by a hash information authentication code (HMAC) signature account for 2 bytes;
key ID, which represents secret Key ID, occupies 4 bytes and is provided by a secret Key distribution center;
payload Length, wherein the Length of all session user information from the Payload Length to the Payload part occupies 4 bytes, the maximum value is 65339, and the Payload Length is distributed by KDC;
payload type, 4 types are specified by IEC-61850-90-5, and are non-tunnel GOOSE APDU-0 x81, non-tunnel SV APDU-0 x82, tunnel GOOSE and SV data packet-0 x83, non-tunnel management APDU-0 x84 and 0x82 is filled in;
simulation is a Boolean value occupying one byte, the effective load is 1 when used for testing, otherwise, the effective load is 0;
APPID, application identification, filling 0x 0100;
the Length of APDU is the Length of R-SV message information plus the Length of 2 bytes per se, and occupies 2 bytes.
Further, the SCL file in step S4 is derived from the configured substation configuration file. Extracting routing related information from an SCL file, originating from a set substation configuration file (SCL file), extracting the routing information from the SCL file in advance, and filling a message domain related to the R-SV message and the routing information in advance.
Further, step S5 is to fill the R-SV message template with the routing related information, and place the R-SV message template into the memory.
Further, the check encapsulation information for filling the R-SV message template in step S6 includes PDU check information and HMAC check information.
Further, the PDU check information includes a Length (Length) and a check layer (Checksum). Where Length takes 2 bytes, the user datagram is eight bits long, including the protocol header and data. The minimum length is 8; checksum takes 2 bytes, which is similar to the Header Checksum algorithm in IPV4 for checking the correctness of IP ports, which may be 0 in IPV 4.
Further, the HMAC check information includes a Signature (Signature), a hash operation message authentication code (HMAC), and a length thereof, where: signature is a message domain Signature, and if the Signature is not used for testing, 0 can be taken; length of HMAC is filled in according to the Length of the next part of HMAC; the HMAC message receiving and sending parties judge whether the message is tampered by checking whether the security algorithm HMAC is consistent or not, and the message is obtained through the HMAC algorithm.
Compared with the prior art, the invention has the following beneficial effects:
the method for realizing the conversion from the SV message to the R-SV message is suitable for SV messages of all types, can convert the SV message which can only be transmitted in a single transformer substation into the R-SV message which can be transmitted among the transformer substations, and can acquire each sampling value of the opposite side among the transformer substations according to the R-SV message so as to judge whether the transformer substation of the opposite side has abnormal operation state or fault and quickly adjust the operation state of the power station.
Drawings
Fig. 1 is a flowchart of a method for converting SV messages into R-SV messages between substations according to this embodiment;
fig. 2 is a schematic diagram of a basic structure of an R-SV message according to this embodiment.
Detailed Description
The present invention will be described in further detail with reference to examples and drawings, but the present invention is not limited thereto. As shown in fig. 1, the method for converting an SV message into an R-SV message applicable between substations of this embodiment includes the following steps:
s1, arranging message domains to be filled in the basic structure of the R-SV message in sequence according to the basic structure of the R-SV message to form an R-SV message template;
s2, dividing the R-SV message template into SV message information, route related information and check encapsulation information; because the traditional power microcomputer equipment with lower configuration is difficult to realize object-oriented modeling and protocol stack processing, the content of the whole R-SV message can be divided into three parts during specific implementation: SV message information, route related information, check encapsulation information, as shown in the following table:
TABLE 1 contents of R-SV messages
| SV message information | Routing information | Verifying encapsulation information |
The SV message information comprises an integer number (noastdu), a sequence of the ASDUs (Sequences of ASDUS), the ASDUs, an MsvID, a data set (Dataset), a sampling counter (SmpCnt), a configuration version number (ConfRev), a transmission buffer refreshing time (RefrTm), a Boolean amount (smpSynch), a sampling number in a rated period (smpRate), sample data (sample), a sample mode (smpMod) and a time mark t.
ASN1 encodes rules, and follows the format of Tag (also called Type), Length, Value, TLV for short. In the following, except that the information content such as the voltage of the sample does not comply with the TLV, the rest comply with the TLV:
1. noASDU: tag: filled with 0X80, a value of Tag, conforming to the TLV encoded format using ASN 1; length: filled with 0X 02.
Sequences of ASDUS: tag: filled with 0XA2.
ASDU: tag: filled with 0X 30.
MsvID: unique identifier of MSDU, Tag: filled with 0X 80.
Dataset: tag: fill 0X81 as an optional field.
SmpCnt: tag: 0X 82; length: filled with 0X 02.
ConfRev: tag: 0X 83; length: filled with 0X 04.
RefrTm: tag: 0X 84; length: fill 0X08 as an optional field.
smpSynch: tag: 0X 85; length: filled with 0X 01.
smpRate: tag: 0X 86; length: filled with 0X 02.
Sample: tag: 0X 87; wherein data represents current-voltage information, datan represents nth set of current-voltage information, q represents mass, and qn represents nth set of information.
smpMod: tag is 0X 88; length: fill 0X02 as an optional field.
13, t: tag: 0X 89; length: fill 0X08 as an optional field.
Wherein Tag (identifier) occupies 1 or two bytes, and Bit7 (7 th Bit) and Bit6 (6 th Bit) are 10: Contest-Specific, context-dependent, Bit5 is selected to be 0, i.e., 0X 80; length indicates how many bytes the VALUE of VALUE is made up of; VALUE is the encoded content that is actually to be delivered.
S3, mapping the obtained SV message information to the position corresponding to the R-SV message template of the memory, and mapping the SV message information to the message domain related to the SV message in the R-SV message by adopting a direct mapping mode.
S4, extracting the routing related information from the SCL file, originating from the set substation configuration file (SCL file), extracting the routing information from the SCL file in advance, and filling the message domain of the R-SV message related to the routing information in advance.
The routing information includes a Destination physical Address (Destination MAC Address), a Source physical Address (Source MAC Address), an IP type, a Version number (Version) of an IP Protocol, a Header Length (IHL) of the IP, a dscp (differentiated Services Code point), an ecn (explicit configuration notification), a Total Length (Total Length) of an IP packet, an Identifier (Identification), a Flag (Flag), a Fragment Offset (Fragment Offset), a ttl (time to live), a Protocol (Protocol), a Header check (Header check), a Source IP Address (Source IP Address), a Destination IP Address (Destination IP Address), a Source Port (Source Port), a Destination Port (Destination Port), a Length Identifier (Length), a Transmission Identifier (TI), a Session Identifier (SI), a Session layer data unit Length (Identifier), a Source Session Length (Identifier), a Header Session Length (Identifier), a Header Session Length (Identifier), and a Header Session Length unit (Identifier) Length of session layer protocol data unit (SPDU Length), session protocol Version Number (SPDU Number, Version Number), Time allowed for current key (Time of current key), Time to next key (Time to next key), Security Algorithm, key id (key id), Payload Length, Payload type (Payload type), emulation (Simulation), apdi, and apde Length.
Specifically, (1) Destination MAC Address: the destination physical address, that is, the physical address of one or more ends of the received message, is the destination MAC address of the SV message actually sent by the sending apparatus. This address occupies 6 bytes as one of the identification marks of the receiving device, and is obtained by the prior arrangement.
(2) Source MAC Address: the physical address of the source, that is, the physical address of the end sending the message, is the physical address of the physical network card of the sending device, and the MAC chip is determined when leaving the factory and does not change with the program and the application. It takes 6 bytes and is obtained by pre-configuration.
(3) IP type: the IP type fills in 0x0800 as specified by the ethernet encapsulation type (RFC 894).
(4) Version: the version number of the IP protocol used for this datagram takes 4 bits. A common IPv4 protocol is generally adopted in the IEC6150-90-5 message, and the filling 0x04 represents IPv 4.
(5) IHL: indicating the header length of the IP, which takes 4 bits. The minimum length of the IP header is 20 bytes, and since a variable-length option is included in the header, the maximum length may become 60 bytes. This is the total length of all headers, obtained in IPv 4.
(6) Dscp (differentiated Services Code point) means differentiated Services Code point, 6bits, and renames the 1 byte used by type of service (TOS) in IPv4 header, which is used to mark data, define priority, and can define 64 different types of service (0-63) at most. Where EF denotes unimpeded Forwarding (EF) is defined by RFC2598, DSCP value 0X46 (101110). The EF service is suitable for services with low packet loss rate, low delay, low jitter and guaranteed bandwidth, and the remaining 2bits are occupied by ecn (explicit connectivity notification) and are not filled.
(7) Total Length: expressed as the total length of the IP message, the maximum length of the IP message is 65535 bytes, namely the length of IHL plus IP payload occupies 2 bytes, and is extracted from the IPv4 structure.
The segmentation operation (Fragment) contains three parts:
(8) identification-representing identifier, which takes 2 bytes and contains an integer, is used to identify the current datagram. This is a sequence number. This field is used in conjunction with the Flags and Fragment Offsest fields to perform fragmentation (Fragment) operations on large upper layer packets
(9) Flag, which represents flag bit, occupies 3bits and is used for controlling and identifying the fragments.
Bit 0 must be 0;
bit 1 (DF) is 0 to indicate that grouping can be carried out, and 1 to indicate that the grouping can not be fragmented;
bit 2 (MF) is 0 to indicate that the data segment is the last data segment in the packet, and 1 to indicate that the data segment is also followed, and is extracted from IPv 4.
(10) Fragment Offset: the segment offset is indicated. Occupying 13 bits. Indicating the location of the segment in the data packet for reassembly of the data segment. This field allows the tag field to terminate at a 16Bit boundary, extracted from IPv 4.
(11) Flags and Fragment Offset take up 2 bytes.
(12) Ttl (time to live): indicating the time to live, which takes 1 byte. Indicating the time in seconds that the packet is allowed to remain in the network transmission. When the timer is 0, the datagram will be discarded. To avoid that the message always exists in the network, 0xff in hexadecimal with the maximum lifetime of 255s is filled.
(13) Protocol: 1 byte is occupied, which marks which upper layer protocol will receive the data after the IP processing process is finished, wherein TCP is represented by 6, and UDP is represented by 17; can be extracted from IPv 4.
(14) Header check, which means that Header check takes 2 bytes to check the correctness of the IP packet, the sender performs calculation according to the Checksum standard and then fills in, the receiver performs a Checksum check on the data, if the packet has no transmission error, the result should be 16 bits all of 1, i.e. 0XFF, and each router must recalculate the Checksum since each router will reduce the value of TTL.
(15) Source IP Address: takes 4 bytes, indicates the IP address of the sending node, and is extracted from IPv 4.
(16) Destination IP Address: takes 4 bytes, indicates the IP address of the receiving node, and is extracted from IPv 4.
(17) Source Port: indicating the starting port, takes 2 bytes. When the opposite side is required to return, filling in according to the actual port number, and if the opposite side is not used, setting the value to be 0.
(18) Destination Port: the destination port number, which occupies 2 bytes, has significance under the condition of special internet destination address, and is filled according to the actual delivery message port.
(19) LI is a length identifier, here 0x 01.
(20) TI transmission identifier, here 0x 40.
(21) SI session identifier: represented by the 4 hexadecimal values defined, 0xA 0: a tunnel GOOSE and a sampling value packet; 0xA 1: a non-tunnel GOOSE application protocol data unit; 0xA 2: non-tunnel SV APDUs; 0xA 3: non-tunnel management APDU, here filled with 0xA2.
(22) Length Identifier the Length Identifier of the Session layer protocol data Unit (SPDU), followed by the Session Identifier (SI), covers the Length of all parameter fields of the Session Header, i.e. the hexadecimal representation of Common Session Header to Key ID byte Length, is 0x 18.
(23) Common Session Header is a Session layer Header constant and is also a Parameter Identifier (PI) as the beginning of a parameter unit. Typically filled with the hexadecimal value 0x 80.
(24) Length Identifier: the length identifier of the parameter unit, which occupies one byte, i.e., the hexadecimal expression of the length of the SPDU to Key ID byte, is 0x 16.
The Parameter Values (PV) of the parameter units comprise the following data:
(25) SPDU Length represents the Length of the whole session layer protocol data unit, takes 4 bytes, and is filled in by the actual situation.
(26) SPDU Number fixed 4 bytes for checking if there is a duplicate or out-of-order packet transfer, defined by itself.
(27) Version Number session protocol Version Number, two bytes fixed, fills in 0x0004 representing IPv 4.
(28) Security Information Security management of application layer data encapsulated in a Session protocol, provided by the specific Key Distribution Center (KDC) protocol of IEC-61850-95, occupying 12 bytes and consisting of:
(29) the Time of current key, the Time allowed by the current key, takes 4 bytes, and is defined by self according to the actual situation.
(30) The Time to next key is the Time to the next key, which takes 2 bytes and is defined by the user according to the actual situation.
(31) Security Algorithm: Algorithm information indicating the type of encryption and hash information authentication code (HMAC) signature generation, takes 2 bytes.
(32) Key ID, representing a secret Key ID, occupies 4 bytes and is provided by a secret Key distribution center
(33) And the Payload Length is the Length of all session user information including the Payload Length to the Payload part, takes 4 bytes, has the maximum value of 65339, and is distributed by KDC.
(34) Payload type Payload mapping protocol 4 types are specified by IEC-61850-90-5, namely non-tunneling GOOSE APDU-0 x81, non-tunneling SV APDU-0 x82, tunneling GOOSE and SV data packets-0 x83, non-tunneling management APDU-0 x84, and the data packets are filled with 0x 82.
(35) Simulation is a Boolean value of one byte, and the payload is 1 when used for testing, otherwise it is 0.
(36) APPID application identification, filling is 0x0100
(37) The Length of APDU is the Length of R-SV message information plus the Length of 2 bytes per se, and occupies 2 bytes.
And S5, filling the route related information into the R-SV message template and putting the R-SV message template into a memory.
S6, filling checking encapsulation information of the R-SV message, wherein the checking encapsulation information comprises PDU checking information and HMAC checking information.
The PDU check information includes a Length (Length) and a check layer (Checksum). Where Length takes 2 bytes, the user datagram is eight bits long, including the protocol header and data. The minimum length is 8; checksum takes 2 bytes, which is similar to the Header Checksum algorithm in IPV4 for checking the correctness of IP ports, which may be 0 in IPV 4.
The HMAC check information includes a Signature (Signature), a hash operation message authentication code (HMAC), and a length thereof, wherein: signature is a message domain Signature, and if the Signature is not used for testing, 0 can be taken; length of HMAC is filled in according to the Length of the next part of HMAC; the HMAC message receiving and sending parties judge whether the message is tampered by checking whether the security algorithm HMAC is consistent or not, and the message is obtained through the HMAC algorithm.
All parts of the acquired message information are combined together according to the sequence of fig. 2, so that a complete frame of R-SV message can be obtained, as follows:
00000 c 07ac 35 (destination physical address) 782 b cb 5 fb 52 (source physical address) 0800 (IP type) 45 (version number and Header Length of message) 46(DSCP + ECN) 0054 (Total Length) 0000 (Fragment) ff (ttl)17(Protocol) ff (Header check) c 0a 80 a e (source IP address) c 0a 80 a f (destination IP address) 0000 (source port) 0000 (destination port) 0141 (Length) 0000 (Checksum)01(LI)40(TI) a2(SI)18(Length Identifier)80 (mon connector) 16 (Length) 00000124 (SPDU 0001 Length) 0000 (SPDU 63r) 4 (Length) 483 c 546 (source Length) 0000 (Header) 16 (Length) 0000 23 (Length) 35 (SPDU 0001) 0000 Length) 0000 (spcp) 4) 0000) 01023 a4 (Length) 0000 (Length) 01023 f2 f (Header) 0000 4 f (destination IP address) 0000 (Length) 01023 f (pid 9 (SPDU 0000) c 31 (Length) 0108 (prefix) c 0000) 4 (prefix) Length) of PDU 0000 4 (prefix) 20 (prefix) Length) 20 (prefix) c 0000) 2 f) 4 (prefix) Length) of (prefix Length) 20 (prefix) Length) 20 (prefix) 2 f) 2 (prefix) Length) 20 (prefix) Length) of PDU 0000 4 (prefix Length) 2 (prefix) Length) 20 (prefix) Length) 2 (prefix) of (prefix Length) 20 (prefix) Length) of (prefix Length) 20 (prefix) 2 (prefix Length) 20 (prefix Length) 4 (prefix) 20 (prefix) Length) 4 (prefix) of (prefix) 20 (prefix Length) 20 (prefix) Length) of (prefix) Length) 20 (prefix) Length) 2 (prefix) of (prefix Length) 2 (prefix) 20 (prefix) 2 (prefix) of PDU 00004 (prefix) of (prefix) 20 (prefix) of (prefix) Length) of (prefix Length) of PDU 00004 (prefix Length) of (prefix Length) 20 (prefix Length) of (prefix Length) 20 (prefix) of (prefix) Length) of (prefix) 20 (prefix) of (prefix) 20 (prefix) of (prefix) Length) of (prefix) Length) of (prefix) 20 (prefix) of (prefix) Length) 20 (prefix) Length) 20 (prefix) of prefix) 20 (prefix) of (prefix) Length) of (prefix) Length) of (prefix) of ( 4e 4302 e f 10000000055 f 29813 c ae 14003 f 7a 10000000055 f 29813 c ae 14003 a 80000000055 f 800813 c ae 14003 f b db 6b f 29813 c ae 14003 e 52 ec f 29813 c ae ff 00000000055 f 29813 c ae 1400 b 48 c f 29813 c ae f 29813 c ae f 29813 c ae f 29813 a f 29813 c ae f 29ae f 2981aef 298139126 e 90 8500
00(signature)00(Length of HMAC)00(HMAC)
In summary, the implementation method of the R-SV power message is applicable to the R-SV message of the traditional microcomputer experimental equipment, and the R-SV message can be formed by combining field sampling data according to the R-SV model message template, so that the R-SV message can be used for the communication of various analog quantities among the traditional microcomputer experimental equipment.
The above description is only for the preferred embodiments of the present invention, but the protection scope of the present invention is not limited thereto, and any person skilled in the art can substitute or change the technical solution of the present invention and the inventive concept within the scope of the present invention, which is disclosed by the present invention, and the equivalent or change thereof belongs to the protection scope of the present invention.
Claims (8)
1. The method for converting the SV message into the R-SV message between the transformer substations is characterized by comprising the following steps of:
s1, forming an R-SV message template according to the basic structure of the R-SV message;
s2, dividing the R-SV message template into SV message information, routing information and check encapsulation information;
s3, mapping the obtained SV message information to a position corresponding to an R-SV message template in a memory;
s4, extracting the routing information from the SCL file, wherein the routing information comprises:
(1) destination MAC Address: the destination physical address is used for receiving the physical address of one end or a plurality of ends of the message, and is a destination MAC address of the GOOSE message actually sent by the sending device, and the address is used as one of the identification marks of the receiving device;
(2) source MAC Address: the source physical address is represented, the physical address of one end used for sending the message is the physical address of the physical network card of the sending device;
(3) IP type: an Ethernet encapsulation type is adopted to specify an IP type;
(4) version: a version number indicating an IP protocol used for the datagram;
(5) IHL: a header length indicating an IP;
(6) DSCP representing differentiated services code point;
(7) total Length: expressed as the total length of the IP message;
(8) identification, which is used for identifying the current datagram;
(9) flags, which represents flag bits, is used for controlling and identifying the fragments;
(7) fragment Offset: representing a segment offset indicating the location of the segment in the data packet for reassembly of the data segment;
(12) ttl (time to live): indicating a time-to-live indicating a time allowed for packet retention in network transmission in seconds, when the timer is 0, the datagram will be discarded;
(13) protocol: after the mark is finished in the IP processing process, an upper layer protocol is appointed to receive the data;
(14) header check for checking the correctness of the IP data packet, wherein a sender fills in the data packet after calculation according to a check sum standard, a receiver checks the data, and if the data packet has no sending error, 16 bits are all 1, namely 0 XFF;
(15) source IP Address: specifying an IP address of a sending node;
(16) destination IP Address: specifying an IP address of a receiving node;
(17) source Port: representing a starting port, filling in according to an actual port number when the opposite side replies, and setting the value to be 0 if the opposite side replies are not used;
(18) destination Port: the target port number is filled according to the actual delivery message port;
(19) LI is a length identifier;
(20) TI is a transmission identifier;
(21) SI session identifier: represented by 4 hexadecimal values defined, specifically: 0xA 0: tunnel GOOSE and sample value packet, 0xA 1: non-tunnel GOOSE application protocol data unit, 0xA 2: non-tunnel SV APDUs; 0xA 3: non-tunnel management APDUs;
(22) length Identifier, which represents the Length Identifier of the session layer protocol data unit (SPDU), and follows the Session Identifier (SI), and covers the Length of all parameter fields of the session header;
(23) common Session Header, representing the Session layer Header constant and also a Parameter Identifier (PI), as the beginning of a parameter unit;
(24) length Identifier: a length identifier representing a parameter unit;
(25) SPDU Length represents the Length of the whole session layer protocol data unit;
(26) SPDU Number used for checking whether there is repeated or unordered data packet transmission;
(27) version Number, which represents the Version Number of the session protocol;
(28) security Information, which is used for carrying out Security management on the application layer data encapsulated in the session protocol;
(29) time of current key, which represents the allowed Time of the current key;
(30) a Security Algorithm indicating an encryption type and Algorithm information generated by a hash information authentication code (HMAC) signature;
(31) key ID represents secret Key ID;
(32) payload Length comprising the Length of all session user information from the Payload Length to the Payload part;
(33) payload type, including 4 types, namely non-tunnel GOOSE APDU-0 x81, non-tunnel SV APDU-0 x82, tunnel GOOSE and SV data packet-0 x83, non-tunnel management APDU-0 x 84;
(34) simulation, namely representing that Simulation occupies a Boolean value of one byte, wherein the effective load is 1 when used for testing, and is 0 otherwise;
(35) APPID, representing application identification;
(36) APDU Length represents the information Length of the R-SV message;
s5, filling the routing information extracted in the step S4 into a message domain related to the R-SV message and the routing information, and putting the message domain into a memory;
s6, filling checking and packaging information of the R-SV message template, wherein the checking and packaging information comprises PDU (protocol data Unit) checking information and HMAC (high-speed alternating Current) checking information; the PDU check information comprises Length (Length) and check layer (Checksum); the HMAC check information includes a Signature (Signature), a hash operation message authentication code (HMAC), and a length thereof.
2. The method for converting SV messages into R-SV messages as claimed in claim 1, wherein the step S1 is to sequentially arrange the message fields to be filled in the R-SV message basic structure to form an R-SV message template.
3. The method for converting SV message into R-SV message as claimed in claim 2, wherein the SV message information comprises integer number (noassu), sequence of ASDUs (sequencersof ASDUS), ASDUs, MsvID, Dataset (Dataset), sampling counter (SmpCnt), configuration version number (ConfRev), transmission buffer refresh time (RefrTm), Boolean amount (smpSynch), number of samples in rated period (smpRate), sample data (sample), sample mode (smpMod), and time stamp t.
4. The method for converting the SV message to the R-SV message as recited in claim 1, wherein in step S3, the SV message information is mapped to the relevant message domain of the R-SV message in a direct mapping manner.
5. The method for converting SV messages to R-SV messages according to claim 1, wherein the SCL file in step S4 is derived from a configured substation configuration file.
6. The method for converting SV messages to R-SV messages according to claim 1, wherein the check encapsulation information for filling the R-SV message template in step S6 includes PDU check information and HMAC check information.
7. The method for converting SV message into R-SV message as claimed in claim 6, wherein the PDU check information comprises Length and check layer (Checksum).
8. The method for converting SV messages into R-SV messages as claimed in claim 6, wherein the HMAC verification information comprises Signature (Signature), security algorithm (HMAC) and length thereof.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911309175.XA CN111131214B (en) | 2019-12-18 | 2019-12-18 | Method for converting SV message into R-SV message between transformer substations |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911309175.XA CN111131214B (en) | 2019-12-18 | 2019-12-18 | Method for converting SV message into R-SV message between transformer substations |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111131214A CN111131214A (en) | 2020-05-08 |
| CN111131214B true CN111131214B (en) | 2021-12-21 |
Family
ID=70499632
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201911309175.XA Active CN111131214B (en) | 2019-12-18 | 2019-12-18 | Method for converting SV message into R-SV message between transformer substations |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111131214B (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112003816B (en) * | 2020-06-22 | 2023-04-18 | 武汉光迅科技股份有限公司 | Data transmission method, device, equipment and storage medium |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103297358B (en) * | 2012-02-27 | 2016-12-14 | 北京东土科技股份有限公司 | A kind of intelligent grid transmits system and method across wide area network GOOSE message |
| DE102012103194B4 (en) * | 2012-04-13 | 2014-09-11 | Pilz Gmbh & Co. Kg | Method for transferring process data in an automated controlled system |
| CN109525041B (en) * | 2018-12-29 | 2023-09-26 | 北京智芯微电子科技有限公司 | Secondary relay protection chip of intelligent substation and data interaction method |
-
2019
- 2019-12-18 CN CN201911309175.XA patent/CN111131214B/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| CN111131214A (en) | 2020-05-08 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8160106B2 (en) | Method, device and system for transmitting Ethernet packets | |
| CN104956637B (en) | The method, apparatus and system of encapsulated data packet are prioritized in the connection of multiple logical network | |
| CN103746962B (en) | GOOSE electric real-time message encryption and decryption method | |
| CN106254381A (en) | Protocol analysis method, device and comprise the Layer2 switching system of protocol analysis device | |
| Konka et al. | Traffic generation of IEC 61850 sampled values | |
| US20090207860A1 (en) | Method, apparatus and system for transferring data | |
| CN101827031A (en) | Method and device for packet transmission in user datagram protocol UDP tunnel | |
| CN110995588B (en) | Method suitable for converting GOOSE message into R-GOOSE message | |
| CN114006953A (en) | Method and device for processing message | |
| CN106911436A (en) | A kind of implementation method of parallel double-network redundant | |
| Matoušek | Description of IEC 61850 communication | |
| CN111131213B (en) | Method for realizing R-GOOSE electric power message | |
| CN107370654B (en) | Pseudo wire data message encapsulation and decapsulation methods and related devices | |
| CN111131214B (en) | Method for converting SV message into R-SV message between transformer substations | |
| CN112787902A (en) | Message encapsulation method and device and message de-encapsulation method and device | |
| CN107517225B (en) | Protocol conversion method, gateway equipment and storage medium | |
| CN101645799B (en) | Sending method, receiving method and equipment of digital communication | |
| CN106209697B (en) | In the method that TTE terminal sent, recombinated the data frame of TTP format | |
| US8149731B2 (en) | Technique for transferring data over a packet switched network | |
| Ghanem et al. | Security vs bandwidth: performance analysis between IPsec and OpenVPN in smart grid | |
| KR101787284B1 (en) | Data concentration unit, electronic power meter and method for operating the same | |
| CN102255790A (en) | Method and system for informing congestion control information | |
| WO2011000330A1 (en) | Method, device and system for measuring internet protocol network performance | |
| Pham | Integration of IEC 61850 MMS and LTE to support smart metering communications | |
| CN110086669A (en) | A kind of network based on ZYNQ is given out a contract for a project machine |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |