CN110995588A - Method suitable for converting GOOSE message into R-GOOSE message - Google Patents
Method suitable for converting GOOSE message into R-GOOSE message Download PDFInfo
- Publication number
- CN110995588A CN110995588A CN201911353153.3A CN201911353153A CN110995588A CN 110995588 A CN110995588 A CN 110995588A CN 201911353153 A CN201911353153 A CN 201911353153A CN 110995588 A CN110995588 A CN 110995588A
- Authority
- CN
- China
- Prior art keywords
- length
- goose message
- information
- message
- goose
- 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.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/02—Topology update or discovery
- H04L45/04—Interdomain routing, e.g. hierarchical routing
-
- 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/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/164—Adaptation or special uses of UDP protocol
-
- 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/22—Parsing or analysis of headers
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
The invention discloses a method for converting a GOOSE message into an R-GOOSE message, which comprises the following steps: s1, forming a R-GOOSE message template according to the SCL file configuration information; s2, dividing the R-GOOSE message template into three parts of GOOSE message information, routing information and checking and packaging information; s3, mapping the GOOSE message information to the related message domain of the R-GOOSE message; s4, extracting the routing information from the SCL file; s5, filling the routing information into the R-GOOSE message template and putting the R-GOOSE message template into a memory; and S6, filling the checking and packaging information of the R-GOOSE message template. The method is efficient and simple, and is particularly suitable for power microcomputer experimental devices with limited performance in the fields of experiments, tests, education, training and the like.
Description
Technical Field
The invention relates to a method for converting a GOOSE message into an R-GOOSE message, in particular to a method for converting the GOOSE message into the R-GOOSE message, which is suitable for a power substation. Belongs to the protection, control and automation technology of an electric power system.
Background
The Generic Object Oriented Substation Event (GOOSE) is a fast message communication mechanism designed for real-time communication by an IEC61850 standard system, and is mainly used for fast transmission of switching value messages between bay level Intelligent Electronic Devices (IEDs) and between bay level IEDs and process level intelligent terminals, and in a power system communication network, the GOOSE messages are mainly used for representing important occasions such as operation commands of tripping and closing of a circuit breaker, position information of the circuit breaker and the like. The GOOSE messages can only be transmitted in the transformer substation, information exchange between the transformer substations cannot be carried out, the GOOSE messages do not have a routing function, and interaction between a cross-station (transformer substation) and a station control (control center) of the transformer substation cannot be carried out.
Along with the requirement of electric power wide area information interaction, the R-GOOSE message with the routing function can make up the defect that the GOOSE message can only be limited to local area information exchange. However, the present descriptions of R-GOOSE messages, such as s.r.Firouzi, L.Vanfretti, A.Ruiz-Alvarez, F.Mahood, H.Hooshar and I.Cairo, An IEC 61850-90-5Gateway for IEEE C37.118.2Synchropasor Data Transfer, the proceedings of the IEEE Power Engineering Society (PES) General Meeting, Boston, USA, July 2016, etc., all use a special communication protocol stack to implement directly, and there is currently no description of a method for converting GOOSE messages into R-GOOSE messages, especially a method for converting GOOSE messages into R-GOOSE messages in conventional microcomputer experimental equipment with limited hardware resources.
Disclosure of Invention
Aiming at the condition that the traditional microcomputer experimental equipment is limited by self performance and is difficult to realize complex R-GOOSE messages, the patent provides an efficient conversion method from the GOOSE messages to the R-GOOSE messages. Therefore, the conversion from the GOOSE message to the R-GOOSE message can be realized without additionally adding extra protocol stack support to the traditional electric microcomputer equipment without the R-GOOSE function, such as the traditional electric intelligent electronic equipment, the electric experiment test equipment and the like.
The method divides the component of the R-GOOSE message into two parts, namely GOOSE message information and routing information. The GOOSE message information is derived from the GOOSE message, and the GOOSE message information is directly mapped to a related message domain of the R-GOOSE message; the routing information comes from the set substation configuration file, and after the routing information is obtained from the SCL file in advance, the message domain related to the R-GOOSE message and the routing information is filled in advance, so that the conversion from the GOOSE message to the R-GOOSE message is quickly realized. The method is efficient and simple, and is particularly suitable for power microcomputer experimental devices with limited performance in the fields of experiments, tests, education, training and the like.
The invention is realized by at least one of the following technical schemes.
The method for converting the GOOSE message into the R-GOOSE message comprises the following steps:
s1, forming a R-GOOSE message template according to the SCL file configuration information;
s2, dividing the R-GOOSE message template into three parts of GOOSE message information, routing information and checking and packaging information;
s3, mapping the GOOSE message information to the related message domain of the R-GOOSE message;
s4, extracting the routing information from the SCL file;
s5, filling the routing information into the R-GOOSE message template and putting the R-GOOSE message template into a memory;
and S6, filling the checking and packaging information of the R-GOOSE message template.
Further, step S1 is specifically to form an R-GOOSE message template according to SCL file configuration information, where the SCL file configuration information includes a Destination physical Address (Destination MAC Address), a Source physical Address (Source MAC Address), a header Length of an IP (IHL), a Total Length of an IP message (Total Length), an identifier (Identification), a Flag bit (Flag), a segment Offset (Fragment Offset), a Protocol (Protocol), a Source IP Address (Source IP Address), a Destination IP Address (Destination IP Address), a Source Port (Source), a Destination Port Number (Destination Port), a Length of a session layer Protocol data unit (Length, SPDU Length), a Time allowed by a current key (SPDU Number, Time current, a Time to next key, a load Length (path), and an application Protocol data unit (Length).
Further, the GOOSE packet information includes a gotbcef string, a time Allowed live (Times Allowed), a DataSet string, a GoID string, a packet sending time T, a change number (StNum), a packet sequence number (SqNum), a Test flag (Test), a configuration version number (ConfRev), a necessity of control block configuration (NdsCom), a number of switching information circuits (numdataset entries), and All Data.
Further, in step S3, the GOOSE message information is mapped to the related message domain of the R-GOOSE message by using a direct mapping method.
Further, the routing information includes a Destination physical Address (Destination MAC Address), a Source physical Address (Source MAC Address), an IP type, and an IP Datagram (IP Datagram), wherein the IP Datagram includes a Version number (Version) of an IP Protocol, a Header Length (IHL) of an IP, a dscp (differentiated Services codepoint), an ECN, 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 data Identifier (SI), a Session data unit Identifier (Identifier), and a Header constant Session Header Length (Session constant layer) of a Session Session layer protocol data unit Length Identifier (Length Identifier), session layer protocol data unit Length (SPDU Length), session protocol Version Number (SPDU Number, Version Number), Time allowed by the current key (Time of current key), Time to next key (Time to next key), Security Algorithm (Security Algorithm), key id (key id), load Length (Payload Length), load type (Payload type), emulation (Simulation), application identification (APPID), application protocol data unit Length (APDULength).
Furthermore, the SCL file is originated from a set substation configuration file, and after the routing information is extracted from the SCL file, a message domain related to the R-GOOSE message and the routing information is filled in advance.
Further, the check encapsulation information includes UDP check information and HMAC check information.
Compared with the prior art, the invention has the following beneficial effects:
1. the limitation that the traditional GOOSE message limits the transmission range is solved, the practicability of the GOOSE message is improved, and all transformer stations can transmit the GOOSE message through the network.
2. Therefore, the conversion from the GOOSE message to the R-GOOSE message can be realized without additionally adding extra protocol stack support to the traditional electric microcomputer equipment without the R-GOOSE function, such as the traditional electric intelligent electronic equipment, the electric experiment test equipment and the like.
Drawings
Fig. 1 is a flowchart of a method for converting GOOSE messages into R-GOOSE messages according to this embodiment;
fig. 2 is a schematic diagram of a reference format of the R-GOOSE packet in this embodiment.
Detailed Description
The present embodiment is described in further detail below with reference to the following embodiments and the accompanying drawings, but the embodiments of the present invention are not limited thereto.
As shown in fig. 1, the method for converting GOOSE messages into R-GOOSE messages according to this embodiment includes the following steps:
s1, as shown in FIG. 2, forming a R-GOOSE message template according to the SCL file configuration information;
s2, because the traditional power microcomputer equipment with lower configuration is difficult to realize object-oriented modeling and protocol stack processing, dividing the R-GOOSE message template into three parts of GOOSE message information, routing information and check encapsulation information, thereby quickly realizing the conversion from the GOOSE message to the R-GOOSE message, as shown in the following table:
TABLE 1 contents of R-GOOSE messages
| GOOSE message information | Routing information | Verifying encapsulation information |
S3, mapping the GOOSE message information to the related message domain of the R-GOOSE message by adopting direct mapping; the GOOSE message information includes: the GOOSE message information includes: GoCBRef string, Times Allowed To live, DataSet string, GoID string, T (message sending time), StNum (change number), Sqnum (message sequence number), Test (Test mark), ConfRev (configuration version number), NdsCom (control block configuration necessity), NumdataSetEntries (switching value information path number), All Data, and the specific contents are as follows:
(1) GoCBRef: ASN1 encoding rule is used to follow the format of TAG (also called TYPE), LENGTH, VALUE, TLV for short;
TAG: 1 or two bytes, and Bit7 and Bit6 adopt 10: Contest-Specific, context-dependent, Bit5 is selected to be 0, i.e., 0X80
LENGTH: represents how many bytes the VALUE of VALUE is made up of;
VALUE: the representation value, i.e. the encoded content that is actually to be delivered.
(2) Times Allowed To live: representing the survival time of the message, and using an ASN1 encoding rule;
TAG: 1 or two bytes, Contest-Specific, context dependent, i.e., 0X 81;
LENGTH: represents how many bytes the VALUE of VALUE is composed of, the VALUE is 0X 04;
the unit of the VALUE is millisecond, and the default is twice the heartbeat message time, namely 10000ms, which is expressed as 0X 00002710.
(3) DataSet: the format TLV is encoded using ASN1, following the format of TAG (also known as TYPE), LENGTH, VALUE.
TAG: 1 or two bytes, Contest-Specific, context dependent, i.e., 0X 82;
LENGTH: represents how many bytes the VALUE of VALUE is made up of;
VALUE: the representation value, i.e. the encoded content that is actually to be delivered.
(4) GoID: the format TLV is encoded using ASN1, following the format of TAG (also known as TYPE), LENGTH, VALUE.
TAG: 1 or two bytes, Contest-Specific, context dependent, i.e., 0X 83;
LENGTH: represents how many bytes the VALUE of VALUE is made up of;
VALUE: the representation value, i.e. the encoded content that is actually to be delivered.
(5) T: stnum (change number) plus 1 time, accurate to milliseconds, uses ASN1 to encode the format TLV, following the format of TAG (also known as TYPE), LENGTH, VALUE. TAG: 1 or two bytes, Contest-Specific, context dependent, i.e., 0X 84;
LENGTH: represents how many bytes the VALUE of VALUE is made up of, here 0X 08;
VALUE: the representation value, i.e. the encoded content that is actually to be delivered.
(6) StNum SqNum: indicating the number of states and sequence number, and when the following All Data does not match the last All Data value, StNum +1 and SqNum is 0. When StNum is consistent, SqNum +1, StNum is 1 and SqNum is 1 when the device sender powers on the first frame. The device receiver powers up the first frame with StNum ═ SqNum ═ 0.
ASN1 is used to encode the format TLV, following the format of TAG (also known as TYPE), LENGTH, VALUE.
StNum：
TAG: 1 or two bytes, Contest-Specific, context dependent, i.e., 0X 85;
LENGTH: represents how many bytes the VALUE of VALUE is made up of, here 0X 04;
VALUE: the representation value, i.e. the encoded content that is actually to be delivered.
SqNum：
TAG: 1 or two bytes, Contest-Specific, context dependent, i.e., 0X 86;
LENGTH: represents how many bytes the VALUE of VALUE is made up of, here 0X 04;
VALUE: the representation value, i.e. the encoded content that is actually to be delivered.
(7) Test: when the device overhaul pressing plate is put in, the Test in the R-GOOSE message sent by the device is set, the R-GOOSE receiving device compares the received Test in the R-GOOSE message with the state of the overhaul pressing plate of the device, and only when the Test in the R-GOOSE message is consistent with the state of the overhaul pressing plate of the device, the signal is taken as an effective signal to be processed or acted.
(8) ConfRev: the configuration of the logical device instance, i.e., the counter of the DataSet configuration change, is identified.
(9) NdsCom: indicating the necessity of configuring the control block, when the attribute DataSet value is NULL, the NdsCom value should be TRUE, indicating that the control block needs to be further configured.
(10) NumdataSetEntries: indicating how many paths of switching value information are in All Data.
(11) All Data: the remote signaling information included in the GOOSE message includes three parts:
StVal: representing a data state value, takes N3 bytes.
t: the time stamp takes 8 bytes.
q: quality, takes 2 bytes.
The GOOSE message information obtained in this embodiment is as follows:
01 0C CD 01 00 04 44 46 35 30 30 30 30 88B8 10 04 01 18 00 00 00 0061 82 01 0C 80 1A 50 52 53 2D 37 33 39 35 52 50 49 54 2F 4C 4C 4E 30 20 47 4F24 67 6F 63 62 31 81 04 00 00 27 10 82 1A 50 52 53 2D 37 33 39 35 52 50 49 542F 4C 4C 4E 30 24 64 73 47 4F 4F 53 45 31 83 1A 54 45 4D 50 4C 41 54 45 52 5049 54 2F 4C 4C 4E 30 24 47 4F 24 67 6F 63 62 31 84 08 00 00 0A 2B AF 4B 15 0085 04 00 00 00 02 86 04 00 00 00 00 87 01 00 88 04 00 00 00 00 89 01 2C 8A 0400 00 00 2D AB 81 87 83 01 01 83 01 00 83 01 00 83 01 00 83 01 00 83 01 00 8301 00 83 01 00 83 01 00 83 01 00 83 01 00 83 01 00 83 01 00 83 01 00 83 01 0083 01 00 83 01 00 83 01 00 83 01 00 83 01 00 83 01 00 83 01 00 83 01 00 83 0100 83 01 00 83 01 00 83 01 00 83 01 00 83 01 00 83 01 00 83 01 00 83 01 00 8301 00 83 01 00 83 01 00 83 01 00 83 01 00 83 01 00 83 01 00 83 01 00 83 01 0083 0100 83 01 00 83 01 00 83 01 00 83 01 00
and S4, extracting the routing information from the SCL file, wherein the SCL file is originated from the set substation configuration file, and pre-filling a message domain related to the R-GOOSE message and the routing information after extracting the routing information from the SCL file.
S5, filling the routing information into the R-GOOSE message template, and putting the R-GOOSE message template into the memory, wherein the filled routing information comprises the following contents: destination MAC Address, Source MAC Address, IP type, Version of IP Protocol, IHL Header Length of IP, dscp (differentiated Services codepoint), ECN, Total Length of IP packet, Identification, Flag, Fragment Offset, ttl (time to live), Protocol, Header check, Source IP Address, Destination IP Address, Source Port, Destination Port, Length Identifier, TI (transport Identifier), SI (Session Identifier), Length Identifier, Session layer Protocol data unit Length, Session layer Header Length, Length Identifier of Session layer Protocol data unit, Session layer Header, Length Identifier of Session layer Protocol data unit, Session Identifier, Source MAC Address, Length Identifier of Session layer Protocol data unit, Length Identifier of Session layer Header, Length Identifier of Session layer Protocol data unit, Length of Session layer Header, Length of Session Header of Session layer Protocol data unit, Length of Session Header of Session layer Protocol data unit, Length of Session layer Header, Length of Session Header of Session layer Header, Session Header of Session layer Protocol data unit, Session Header Length of Session Header of Session layer Header, Session Header, SPDU Number, Version Number, Time of current Key (Time allowed by current Key), Time to next Key (Time of next Key), Security Algorithm, Key ID, Payload Length, Payload type, Simulation, APDU (application ID), APDU Length, and the following specific contents:
(1) destination MAC Address: and the destination physical address is represented, namely the physical address of one end or multiple ends of the received message, and is the destination MAC address of the GOOSE message actually sent by the sending device. 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: 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 rest 2bits are occupied by ECN 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: occupying 1 byte, marking which upper layer protocol will receive the data after the IP processing process is finished, wherein TCP is represented by 6, and UDP Segment 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 4 hexadecimal values defined, 0xA0, tunnel GOOSE, and sample value packet; 0xA1, non-tunnel GOOSE application protocol data unit; 0xA2, non-tunneled SV APDU; 0xA3, non-tunnel management APDU, here filled with 0xA1.
(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 81.
(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 APDU Length is the Length of the R-GOOSE message information plus the Length of 2 bytes per se, and occupies 2 bytes.
S6, filling checking and packaging information of the R-GOOSE message template, wherein the filled content comprises UDP (user Datagram protocol) checking information and HMAC (high-speed Link control access) checking information;
the UDP check information is as follows:
(1) length: taking 2 bytes. The user datagram is eight bits long, including the protocol header and data. The minimum length is 8.
(2) Checksum: taking 2 bytes. It is similar to the Header Checksum algorithm in the IPV4 protocol and is used to verify the correctness of the IP port. Checksum may be 0 in the IPV4 protocol.
The HMAC check information is as follows:
(1) and Signature, wherein the Signature of the message domain can be 0 if the Signature is not used for testing.
(2) Length of HMAC according to the Length of the next partial HMAC.
(3) HMAC: the 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 receiving and sending parties are obtained through the HMAC algorithm.
Combining the parts of the message information obtained in the steps S3, S4, S5, and S6 according to the sequence of fig. 2 to obtain a complete R-GOOSE message, as follows:
010C CD 010004 (destination physical address) 463530303030 (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 Checksum) C0A 80A E (source IP address) C0A 80A F (destination IP address) 0000 (source port) 0000 (destination port) 0141 (Length) 0000 (checkpoint) 01(LI)40(TI) A1(SI)18 (Length) 80(Common Session Header)16 (Length) 0000012F SPDU Length (SPDU 0001) number 4 (Length) 0000003C 463530303030 (destination physical address) 0800 (IP type) 0000 (TTL) FF 31 (TTL) 0000 1(Length) 0000 (Length) 0000 (PDU 0000) 00004 (Length) A00007 (GOlength) A0000) 80(Common Session Header)16 (Length) 0003624F 0000) SPDU Length (PDU Length) 0000 (prefix) 0000F 80 (Session Header) Length) A0000 (GOlength) A0000F 80 (Length) A0000F 80 (Session Length) A0000) E80 (Session Header Length) A0000 (duration of APD 80 (Session Length) A0000F 80 (Session Length) E80 (Session Length) A0000) E80 (Session Length) A0000E 80 (Session Length) E D37333935525049542F 4C 4E 30246473474F 4F 534531 (Dataset) 831 a 54454D 504C 415445525049542F 4C 3024474F 24676F 636231 (GoID) 840800000 A2B AF 4B 1500 (T) 850400000002 (StNum) 860400000000 (SqNum) 870100 (test bit ═ 0) 880400000000 (ConRev) 89012C (ndscom)8a 040000002D (numdatasetentries) AB 81(TAG)87(LENGTH th ═ 0X87 ═ 135) 830101830100830100830100830100830100830100830100830100830100830100830100830100830100830100830100830100830100830100830100830100830100830100830100830100830100830100830100830100830100830100830100830100830100830100830100830100830100830100830100830100830100830100830100830100 (All Date)00(signature)00(LENGTH of HMAC)00(HMAC)
In summary, the method for converting the GOOSE message into the R-GOOSE message is applicable to the GOOSE message stored in the transformer substation, can extract message information to recombine to achieve the purpose of obtaining the R-GOOSE message, solves the limitation of the traditional GOOSE message on limiting the transmission range, greatly improves the practicability of the GOOSE message, and enables each transformer substation to quickly and accurately master power utilization information through network transmission.
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 (7)
1. The method for converting the GOOSE message into the R-GOOSE message is characterized by comprising the following steps of: the method comprises the following steps:
s1, forming a R-GOOSE message template according to the SCL file configuration information;
s2, dividing the R-GOOSE message template into three parts of GOOSE message information, routing information and checking and packaging information;
s3, mapping the GOOSE message information to the related message domain of the R-GOOSE message;
s4, extracting the routing information from the SCL file;
s5, filling the routing information into the R-GOOSE message template and putting the R-GOOSE message template into a memory;
and S6, filling the checking and packaging information of the R-GOOSE message template.
2. The method as claimed in claim 1, wherein the method is suitable for converting GOOSE message into R-GOOSE message, and comprises: step S1 is specifically to form an R-GOOSE message template according to the SCL file configuration information, where the SCL file configuration information includes a Destination physical Address (Destination MAC Address), a Source physical Address (Source MAC Address), a header Length of an IP (IHL), a Total Length of an IP message (Total Length), an identifier (Identification), a Flag bit (Flag), a segment Offset (Fragment Offset), a Protocol (Protocol), a Source IP Address (Source IP Address), a Destination IP Address (Destination IP Address), a departure Port (Source Port), a Destination Port Number (Destination Port), a Length of a session layer Protocol data unit (Length, SPDU Length), a Time allowed by a current key (SPDU Number, Time of current), a Time to next key (Time _ next), a load Length (payload), and an application data unit Length (APDU Length).
3. The method as claimed in claim 2, wherein the method is suitable for converting GOOSE message into R-GOOSE message, and comprises: the GOOSE message information includes a gotbcef string, a time Allowed live (Times Allowed), a DataSet string, a GoID string, a message sending time T, a change sequence number (StNum), a message sequence number (SqNum), a Test flag (Test), a configuration version number (ConfRev), a necessity of control block configuration (NdsCom), a number of switching information circuits (NumdataSetEntries), and All Data.
4. The method as claimed in claim 1, wherein the method is suitable for converting GOOSE message into R-GOOSE message, and comprises: step S3 is to map GOOSE message information to the related message domain of the R-GOOSE message by using a direct mapping method.
5. The method as claimed in claim 1, wherein the method is suitable for converting GOOSE message into R-GOOSE message, and comprises: the routing information includes a Destination physical Address (Destination MAC Address), a Source physical Address (Source MAC Address), an IP type, and an IP Datagram (IP Datagram), wherein the IP Datagram includes a Version number (Version) of an IP Protocol, a Header Length (IHL) of an IP, a dscp (differentiated Services Code point), an ECN, an IP packet Total Length (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 (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), and a Header Session Length (Session Protocol) unit Length, Length of session layer protocol data unit (SPDULength), 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 (Security Algorithm), key id (key id), load Length (Payload Length), load type (Payload type), emulation (Simulation), application identification (APPID), application protocol data unit Length (APDU Length).
6. The method as claimed in claim 1, wherein the method is suitable for converting GOOSE message into R-GOOSE message, and comprises: the SCL file is originated from a set substation configuration file, and after the routing information is extracted from the SCL file, a message domain related to the R-GOOSE message and the routing information is filled in advance.
7. The method as claimed in claim 1, wherein the method is suitable for converting GOOSE message into R-GOOSE message, and comprises: the check encapsulation information comprises UDP check information and HMAC check information.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911353153.3A CN110995588B (en) | 2019-12-25 | 2019-12-25 | Method suitable for converting GOOSE message into R-GOOSE message |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911353153.3A CN110995588B (en) | 2019-12-25 | 2019-12-25 | Method suitable for converting GOOSE message into R-GOOSE message |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN110995588A true CN110995588A (en) | 2020-04-10 |
| CN110995588B CN110995588B (en) | 2022-01-21 |
Family
ID=70075251
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201911353153.3A Active CN110995588B (en) | 2019-12-25 | 2019-12-25 | Method suitable for converting GOOSE message into R-GOOSE message |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN110995588B (en) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111970278A (en) * | 2020-08-18 | 2020-11-20 | 金华八达集团有限公司科技信息分公司 | Intelligent distributed FA communication method based on improved UDP transmission mode |
| CN114363424A (en) * | 2022-01-05 | 2022-04-15 | 广东电网有限责任公司 | Communication protocol converter, communication protocol conversion method and distributed feeder system |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103297358A (en) * | 2012-02-27 | 2013-09-11 | 北京东土科技股份有限公司 | System and method for smart power grid to transmit GOOSE messages across wide area network |
| CN103378654A (en) * | 2012-04-27 | 2013-10-30 | 南京南瑞继保电气有限公司 | Method for filtering network messages of process level of intelligent substation |
| CN106209418A (en) * | 2016-06-27 | 2016-12-07 | 哈尔滨工业大学 | A kind of intelligent substation GOOSE message simulation generates and detection method |
| CN106953813A (en) * | 2017-03-14 | 2017-07-14 | 哈尔滨工业大学 | A kind of GOOSE message receive-transmit system and its control method |
| CN106953855A (en) * | 2017-03-16 | 2017-07-14 | 国网江苏省电力公司淮安供电公司 | A kind of method of intrusion detection to IEC61850 digital transformer substation GOOSE messages |
| US9894080B1 (en) * | 2016-10-04 | 2018-02-13 | The Florida International University Board Of Trustees | Sequence hopping algorithm for securing goose messages |
-
2019
- 2019-12-25 CN CN201911353153.3A patent/CN110995588B/en active Active
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103297358A (en) * | 2012-02-27 | 2013-09-11 | 北京东土科技股份有限公司 | System and method for smart power grid to transmit GOOSE messages across wide area network |
| CN103378654A (en) * | 2012-04-27 | 2013-10-30 | 南京南瑞继保电气有限公司 | Method for filtering network messages of process level of intelligent substation |
| CN106209418A (en) * | 2016-06-27 | 2016-12-07 | 哈尔滨工业大学 | A kind of intelligent substation GOOSE message simulation generates and detection method |
| US9894080B1 (en) * | 2016-10-04 | 2018-02-13 | The Florida International University Board Of Trustees | Sequence hopping algorithm for securing goose messages |
| CN106953813A (en) * | 2017-03-14 | 2017-07-14 | 哈尔滨工业大学 | A kind of GOOSE message receive-transmit system and its control method |
| CN106953855A (en) * | 2017-03-16 | 2017-07-14 | 国网江苏省电力公司淮安供电公司 | A kind of method of intrusion detection to IEC61850 digital transformer substation GOOSE messages |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111970278A (en) * | 2020-08-18 | 2020-11-20 | 金华八达集团有限公司科技信息分公司 | Intelligent distributed FA communication method based on improved UDP transmission mode |
| CN114363424A (en) * | 2022-01-05 | 2022-04-15 | 广东电网有限责任公司 | Communication protocol converter, communication protocol conversion method and distributed feeder system |
| CN114363424B (en) * | 2022-01-05 | 2023-06-30 | 广东电网有限责任公司 | Communication protocol converter, communication protocol conversion method and distributed feeder system |
Also Published As
| Publication number | Publication date |
|---|---|
| CN110995588B (en) | 2022-01-21 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8160106B2 (en) | Method, device and system for transmitting Ethernet packets | |
| US10404605B2 (en) | Packet processing method, device and computer storage medium | |
| CN103746962B (en) | GOOSE electric real-time message encryption and decryption method | |
| CN110995588B (en) | Method suitable for converting GOOSE message into R-GOOSE message | |
| CN111131213B (en) | Method for realizing R-GOOSE electric power message | |
| EP4181463A1 (en) | Method and device for processing message | |
| WO2009012688A1 (en) | Method, system and apparatus for forwarding message in three-layer virtual private network | |
| Konka et al. | Traffic generation of IEC 61850 sampled values | |
| US20090207860A1 (en) | Method, apparatus and system for transferring data | |
| CN111277679B (en) | Wireless sensor network communication method based on LoRaWAN and IPv6 protocol | |
| CN106911436A (en) | A kind of implementation method of parallel double-network redundant | |
| CN107835102A (en) | One kind decomposes and decomposed fuzz testing method for protocol characteristic | |
| CN111935009B (en) | Data packet routing method, device, equipment, system and storage medium | |
| Matoušek | Description of IEC 61850 communication | |
| CN107517225A (en) | A kind of method for converting protocol, gateway device and storage medium | |
| CN111131214B (en) | Method for converting SV message into R-SV message between transformer substations | |
| US8149731B2 (en) | Technique for transferring data over a packet switched network | |
| CN110086669A (en) | A kind of network based on ZYNQ is given out a contract for a project machine | |
| US20210126989A1 (en) | Techniques for packet data conversion | |
| CN107948217A (en) | Switch system and communication means | |
| CN104795892B (en) | GOOSE message implementation method applied to traditional electric microcomputer experiment device | |
| CN111031136B (en) | Method for realizing R-SV power message | |
| JP5658279B2 (en) | Method and apparatus for realizing time division multiplexed data transmission | |
| CN102611631A (en) | Method, device and system for protecting protocol under pseudo-wire scene | |
| CN107231309B (en) | Obtain method, controller and the purpose switching node of SDN the whole network view |
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 |