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
- indicates
- 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
- 238000000034 method Methods 0.000 title claims abstract description 21
- 230000005540 biological transmission Effects 0.000 claims abstract description 18
- 238000005538 encapsulation Methods 0.000 claims abstract description 17
- 238000012795 verification Methods 0.000 claims abstract description 11
- 238000013507 mapping Methods 0.000 claims abstract description 10
- 239000012634 fragment Substances 0.000 claims description 21
- 238000004422 calculation algorithm Methods 0.000 claims description 16
- 241000272814 Anser sp. Species 0.000 claims description 12
- 238000007726 management method Methods 0.000 claims description 9
- 238000005070 sampling Methods 0.000 claims description 9
- 238000004088 simulation Methods 0.000 claims description 6
- 238000012545 processing Methods 0.000 claims description 5
- 238000012360 testing method Methods 0.000 claims description 5
- 238000006243 chemical reaction Methods 0.000 claims description 4
- HRULVFRXEOZUMJ-UHFFFAOYSA-K potassium;disodium;2-(4-chloro-2-methylphenoxy)propanoate;methyl-dioxido-oxo-$l^{5}-arsane Chemical compound [Na+].[Na+].[K+].C[As]([O-])([O-])=O.[O-]C(=O)C(C)OC1=CC=C(Cl)C=C1C HRULVFRXEOZUMJ-UHFFFAOYSA-K 0.000 claims 1
- 238000004806 packaging method and process Methods 0.000 abstract 1
- 230000005641 tunneling Effects 0.000 description 4
- 238000004891 communication Methods 0.000 description 3
- 230000006870 function Effects 0.000 description 3
- 101150069304 ASN1 gene Proteins 0.000 description 2
- 238000004364 calculation method Methods 0.000 description 2
- 230000007547 defect Effects 0.000 description 2
- 230000001419 dependent effect Effects 0.000 description 2
- 230000011218 segmentation Effects 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- 230000002159 abnormal effect Effects 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000018109 developmental process Effects 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 238000013467 fragmentation Methods 0.000 description 1
- 238000006062 fragmentation reaction Methods 0.000 description 1
- 238000011160 research Methods 0.000 description 1
- 230000004083 survival effect Effects 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
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
本发明公开了适用于变电站之间的SV报文向R‑SV报文的转换方法，包括以下步骤：S1、根据R‑SV报文的基本结构，形成R‑SV报文模板；S2、将R‑SV报文模板划分成SV报文信息、路由信息和校验封装信息三个部分；S3、将所获得的SV报文信息映射到内存的R‑SV报文模板对应的位置；S4、从SCL文件中提取路由信息；S5、将步骤S4提取到的路由信息填充到R‑SV报文与路由信息相关的报文域，并放入内存；S6、填充R‑SV报文模板的校验封装信息。本发明突破了传统SV报文在变电站内部传输的局限，能够快速根据原有SV报文构建R‑SV报文，从而实现了多个变电站之间信息的传输，实现了变电站之间信息的互联、互通。
The invention discloses a method for converting SV messages between substations to R-SV messages, comprising the following steps: S1, forming an R-SV message template according to the basic structure of the R-SV message; S2, converting The R-SV message template is divided into three parts: SV message information, routing information and verification and encapsulation information; S3, mapping the obtained SV message information to the corresponding position of the R-SV message template in the memory; S4, Extract routing information from the SCL file; S5, fill the routing information extracted in step S4 into the message field of the R-SV message and the routing information, and put it into the memory; S6, fill the calibration of the R-SV message template Check the packaging information. The invention breaks through the limitation of traditional SV message transmission inside the substation, and can quickly construct the R-SV message according to the original SV message, thereby realizing the transmission of information between multiple substations and realizing the interconnection of information between the substations. , Interoperability.
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)
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 |
|---|---|---|
| EP4181463A1 (en) | Method and device for processing message | |
| US7869450B2 (en) | Method and apparatus for processing labeled flows in a communication access network | |
| WO2010031324A1 (en) | Method, device and system for data transmission | |
| CN101827031A (en) | Method and device for packet transmission in user datagram protocol UDP tunnel | |
| Konka et al. | Traffic generation of IEC 61850 sampled values | |
| WO2010020197A1 (en) | Data transmission method, communication equipment and communication system | |
| US8160106B2 (en) | Method, device and system for transmitting Ethernet packets | |
| CN109450875A (en) | MAC layer encapsulation method and device | |
| Matoušek | Description of IEC 61850 communication | |
| CN110995588B (en) | Method suitable for converting GOOSE message into R-GOOSE message | |
| CN106209697B (en) | In the method that TTE terminal sent, recombinated the data frame of TTP format | |
| CN111131214B (en) | Method for converting SV message into R-SV message between transformer substations | |
| CN111131213B (en) | Method for realizing R-GOOSE electric power message | |
| CN107370654B (en) | Pseudo wire data message encapsulation and decapsulation methods and related devices | |
| CN112787902A (en) | Message encapsulation method and device and message de-encapsulation method and device | |
| CN107517225A (en) | A kind of method for converting protocol, gateway device and storage medium | |
| CN111031136B (en) | Method for realizing R-SV power message | |
| CN102255790A (en) | Method and system for informing congestion control information | |
| KR101787284B1 (en) | Data concentration unit, electronic power meter and method for operating the same | |
| Hegazi et al. | IEC-61850 GOOSE traffic modeling and generation | |
| JP5658279B2 (en) | Method and apparatus for realizing time division multiplexed data transmission | |
| CN101471937B (en) | Method and device for multiplexing and demultiplexing Ethernet packets | |
| Sakamoto et al. | Poster: Implementation and Performance Evaluation of TCP/IP Communication over Private LoRa | |
| US20100329245A1 (en) | Transparent Mapping of Cell Streams to Packet Services | |
| CN102523150A (en) | Method, device and system for tunnel message processing |
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 |