The establishment of standards for the transmission of telemechanical data in the power industry (IEC 101/104) - features of the development
Hello! My name is Yuri.
Having worked for several years in the energy industry in the subject of data transmission, I want to share with the community the knowledge gained, including how it was.
I’ll just make a reservation that the text will give the names of companies and products that have been on the market for a long time, so I wouldn’t consider it as an advertisement. I also want to note that all the deadlines related to the “non-disclosure of confidential information” have long passed, which allows me to share the information received in the process of work. Some specific names "responsible for" will not be called, because they all developed this direction to one degree or another.
The links in the article are for those who wish to dive a bit deeper into the topic.
For brevity, I will introduce some abbreviations:
')
Increasing requirements for information systems in the modern Russian Energy sector has led to the development of data transmission tools and technologies. In energy this direction is called telemechanics . As a basis for the transmission of telemechanical information, the stack of protocols IEC 870-5-101 was taken and in 2001 its domestic translation of GOST R IEC 870-5-101 appeared.
There were several reasons for its localization:
In 2004, IEC 60870-5-104 was renamed GOST-R IEC 60870-5-10-4-2004. Parallel to this, the famous 603-rd order was issued at RAO UES of Russia , which almost all manufacturers of equipment for the transmission of telemechanical information rushed to execute. Fortunately, the process of “development” of the “Russian IEC” was very quickly transferred to the process of standardization of the seemingly “standard” GOST. I didn’t just formulate “happiness” because By the time of issuing additional regulatory and clarifying sectoral documents, some manufacturers still managed to “distinguish themselves”. But more about that later.
Starting from 2004, a reference model of building complexes for dispatch centers of the branches of this structure was adopted at JSC SO UES. In accordance with this model, which is still in effect, the OIC SK-2000 (and later 2003 and 2007) produced by CJSC Monitor Electric was adopted as the SCADA system, and the SMART -FEP ”produced by RTSoft CJSC , which was a means of collecting telemechanics data from various protocols and transmitted all the collected information to the OIC via IEC 104 protocol.
After a large-scale deployment of these complexes and the start of connecting to them a large number of objects with new or upgraded telemechanics devices, the problem arose of coordinating technical solutions that were based on accepted GOST-e. It would seem that GOST should clearly define how and what to do. But in this case, it provided developers with a set of capabilities that they could implement in different ways, in accordance with their understanding of this standard. At the same time, everyone said “We have everything in accordance with IEC!” And was in its own right. At a certain point, by 2007, the central customer of these systems, SO UES, was tired of this situation, and it was decided that it was necessary to bring the protocol compatibility testing procedure, which RTSoft should perform, since he was the supplier of DSPC.
In fact, during this period there were only two basic documents in Russian - IEC 101 and IEC 104. Later, in 2006, 101 protocols were reprinted and received a clearer and more specific structure with the exception of some functions that were not useful in real life. Many software developers lacked this information and tried to find it from foreign sources. One such document was the well-developed “Norwegian Agreement” - this document was adopted in Norway back in 2000. It looked in detail not only for frame formats, but also diagrams were given of the sequence of procedures for exchanging, setting up a connection, etc., with not only the positive performance of operations but also the description of exceptions. De facto, this document became the basis for the implementation of IEC 101 in all systems that are now manufactured in Russia.
In 2008, SO UES launched a project (implemented by ENITA CJSC) to prepare guidelines for developers of telemechanics systems, thecreation of which was carried out by the branch of OAO SO UES - ODU Ural , branch of OAO SO UES — ODU South And VNIIE .
The result of this development was two detailed fundamental documents that unequivocally determined how to build solutions for software developers and system designers:
It seems to me - this is one of the few examples of an evaluation approach in the development of systems with a positive outcome.
Full title of the document: On bringing the telemechanics and communication systems at generating enterprises of the electric power industry that are part of RAO UES of Russia Holding Company in compliance with the requirements of the balancing market , Order No. 603 dated 09.09.2005 of RAO UES of Russia JSC.
The main requirements of 603 orders in terms of telemechanics systems were:
The deadlines, as always in Russia, were set not real - all reform (stage 3) needed to be completed by September 1, 2007, i.e. for 2 years it was required to redo all telemetry throughout Russia.
Note: Until now, in most parts of Russia, the communication channels operate on old protocols and low speeds, but for newly created systems, the requirements are compulsory fulfilled.
There are several nuances that can not be interpreted in any way unequivocally.
In the foreign implementation of the protocol it is said that it is recommended to use a time stamp in UTC format. Paradoxically, this line is absent for the Russian edition of this document for our multi-hourly country, although it could solve a huge number of problems associated with transferring data from one time zone to another!
In the 7-byte timestamp there is a large amount of free space, which allows you to set the current time zone, if so necessary.
As the practice of using this protocol has shown, out of the entire set of frame types defined in it, a percentage of 20 percent is actually used, maximum. But at the very beginning of its use, domestic developers tried to use the frames reserved for further expansion. This is about the process of “development” of the protocol.
Due to the fact that the energy sector is a sufficiently monetary industry, a large number of companies with their products or services tried to get to the "feeder". Accordingly, the prevalence of a product can be judged by how closely the authorities and the representatives of this or that business have agreed between themselves.
Fortunately, if these arrangements somehow accompanied some product at the first stage were not of the best quality, it was gradually brought to mind, modernized and now it can be said is reliable and not replaceable. But about the complexity of the implementation phase associated with the "dampness" and the lack of consistency of decisions between the various participants should still be remembered.
About
Note: Due to the fact that at that time my work in the company was directly related to testing the equipment of various manufacturers for issuing permits for the implementation of these systems at the sites handed over to JSC “SO UES”, I saw quite a lot of developers, some of which I still maintain a good relationship.
The main features in the implementation of the protocols were associated with a lack of understanding of the procedural part of the implementation of the protocols. Since IEC Section 870-5 regulates only the formats of transmitted data, some manufacturers implied that it is possible to send these data stupidly without performing any procedures associated with setting up a link at the data link level. The procedural part was answered by the section of IEC 870-6, which for some reason none of the “legislators” paid attention to. Nevertheless, having in store a perfectly formulated Norwegian agreement, with all its diagrams and crossed out parts, all manufacturers managed to come to some kind of common understanding of how the exchange should be built.
As far as I know, now the protocol compatibility checking procedure is no longer carried out, since all those who were in this market already managed to debug their implementation of the IEC protocols over the years, and those who did not have time just left the market (there are also such companies).
Preamble
Having worked for several years in the energy industry in the subject of data transmission, I want to share with the community the knowledge gained, including how it was.
I’ll just make a reservation that the text will give the names of companies and products that have been on the market for a long time, so I wouldn’t consider it as an advertisement. I also want to note that all the deadlines related to the “non-disclosure of confidential information” have long passed, which allows me to share the information received in the process of work. Some specific names "responsible for" will not be called, because they all developed this direction to one degree or another.
The links in the article are for those who wish to dive a bit deeper into the topic.
For brevity, I will introduce some abbreviations:
- IEC- protocols in accordance with GOST R IEC 60870-5-101 / 104
- IEC 101 , 101st - protocol according to GOST R IEC 60870-5-101
- IEC 104 , 104th - protocol according to GOST R IEC 60870-5-104
')
How it all began
Increasing requirements for information systems in the modern Russian Energy sector has led to the development of data transmission tools and technologies. In energy this direction is called telemechanics . As a basis for the transmission of telemechanical information, the stack of protocols IEC 870-5-101 was taken and in 2001 its domestic translation of GOST R IEC 870-5-101 appeared.
There were several reasons for its localization:
- at that time, a huge number of implementations of data transfer protocols “got divorced” and this whole “zoo” was more and more difficult to organize;
- all existing protocols had a large number of restrictions, on the capacity of the transmitted data, on the type of the transmitted data, there were no means of diagnosing the quality of the transmitted data, there was no possibility for expansion, etc .;
- Foreign suppliers of solutions and equipment gradually began to enter our market, where the standardization process was already taking place for a long time.
In 2004, IEC 60870-5-104 was renamed GOST-R IEC 60870-5-10-4-2004. Parallel to this, the famous 603-rd order was issued at RAO UES of Russia , which almost all manufacturers of equipment for the transmission of telemechanical information rushed to execute. Fortunately, the process of “development” of the “Russian IEC” was very quickly transferred to the process of standardization of the seemingly “standard” GOST. I didn’t just formulate “happiness” because By the time of issuing additional regulatory and clarifying sectoral documents, some manufacturers still managed to “distinguish themselves”. But more about that later.
Starting from 2004, a reference model of building complexes for dispatch centers of the branches of this structure was adopted at JSC SO UES. In accordance with this model, which is still in effect, the OIC SK-2000 (and later 2003 and 2007) produced by CJSC Monitor Electric was adopted as the SCADA system, and the SMART -FEP ”produced by RTSoft CJSC , which was a means of collecting telemechanics data from various protocols and transmitted all the collected information to the OIC via IEC 104 protocol.
After a large-scale deployment of these complexes and the start of connecting to them a large number of objects with new or upgraded telemechanics devices, the problem arose of coordinating technical solutions that were based on accepted GOST-e. It would seem that GOST should clearly define how and what to do. But in this case, it provided developers with a set of capabilities that they could implement in different ways, in accordance with their understanding of this standard. At the same time, everyone said “We have everything in accordance with IEC!” And was in its own right. At a certain point, by 2007, the central customer of these systems, SO UES, was tired of this situation, and it was decided that it was necessary to bring the protocol compatibility testing procedure, which RTSoft should perform, since he was the supplier of DSPC.
In fact, during this period there were only two basic documents in Russian - IEC 101 and IEC 104. Later, in 2006, 101 protocols were reprinted and received a clearer and more specific structure with the exception of some functions that were not useful in real life. Many software developers lacked this information and tried to find it from foreign sources. One such document was the well-developed “Norwegian Agreement” - this document was adopted in Norway back in 2000. It looked in detail not only for frame formats, but also diagrams were given of the sequence of procedures for exchanging, setting up a connection, etc., with not only the positive performance of operations but also the description of exceptions. De facto, this document became the basis for the implementation of IEC 101 in all systems that are now manufactured in Russia.
In 2008, SO UES launched a project (implemented by ENITA CJSC) to prepare guidelines for developers of telemechanics systems, the
The result of this development was two detailed fundamental documents that unequivocally determined how to build solutions for software developers and system designers:
- Guidelines for the implementation of the information exchange of power facilities with the corporate information system of JSC "SO UES" under the protocol GOST R IEC 60870-5-101
- Guidelines for the implementation of the information exchange of power facilities with the corporate information system of JSC "SO UES" under the protocol GOST R IEC 60870-5-104
It seems to me - this is one of the few examples of an evaluation approach in the development of systems with a positive outcome.
A bit about the 603rd order
Full title of the document: On bringing the telemechanics and communication systems at generating enterprises of the electric power industry that are part of RAO UES of Russia Holding Company in compliance with the requirements of the balancing market , Order No. 603 dated 09.09.2005 of RAO UES of Russia JSC.
The main requirements of 603 orders in terms of telemechanics systems were:
- definition of requirements for communication channels (digital dedicated, at least 64 kbps., reservation);
- setting time limits for the transfer of operational ifnormations (TS - 5 s., TI - 1 s.);
- organization of direct communication channels to control facilities (RDU, ODU, CDU).
The deadlines, as always in Russia, were set not real - all reform (stage 3) needed to be completed by September 1, 2007, i.e. for 2 years it was required to redo all telemetry throughout Russia.
Note: Until now, in most parts of Russia, the communication channels operate on old protocols and low speeds, but for newly created systems, the requirements are compulsory fulfilled.
Disputes of the IEC Protocol
There are several nuances that can not be interpreted in any way unequivocally.
UTC timestamp
In the foreign implementation of the protocol it is said that it is recommended to use a time stamp in UTC format. Paradoxically, this line is absent for the Russian edition of this document for our multi-hourly country, although it could solve a huge number of problems associated with transferring data from one time zone to another!
Lack of time zones
In the 7-byte timestamp there is a large amount of free space, which allows you to set the current time zone, if so necessary.
Expandability
As the practice of using this protocol has shown, out of the entire set of frame types defined in it, a percentage of 20 percent is actually used, maximum. But at the very beginning of its use, domestic developers tried to use the frames reserved for further expansion. This is about the process of “development” of the protocol.
A little about the products of that period and their capabilities
Due to the fact that the energy sector is a sufficiently monetary industry, a large number of companies with their products or services tried to get to the "feeder". Accordingly, the prevalence of a product can be judged by how closely the authorities and the representatives of this or that business have agreed between themselves.
Fortunately, if these arrangements somehow accompanied some product at the first stage were not of the best quality, it was gradually brought to mind, modernized and now it can be said is reliable and not replaceable. But about the complexity of the implementation phase associated with the "dampness" and the lack of consistency of decisions between the various participants should still be remembered.
About jambs features in implementation
Note: Due to the fact that at that time my work in the company was directly related to testing the equipment of various manufacturers for issuing permits for the implementation of these systems at the sites handed over to JSC “SO UES”, I saw quite a lot of developers, some of which I still maintain a good relationship.
The main features in the implementation of the protocols were associated with a lack of understanding of the procedural part of the implementation of the protocols. Since IEC Section 870-5 regulates only the formats of transmitted data, some manufacturers implied that it is possible to send these data stupidly without performing any procedures associated with setting up a link at the data link level. The procedural part was answered by the section of IEC 870-6, which for some reason none of the “legislators” paid attention to. Nevertheless, having in store a perfectly formulated Norwegian agreement, with all its diagrams and crossed out parts, all manufacturers managed to come to some kind of common understanding of how the exchange should be built.
As far as I know, now the protocol compatibility checking procedure is no longer carried out, since all those who were in this market already managed to debug their implementation of the IEC protocols over the years, and those who did not have time just left the market (there are also such companies).
Source: https://habr.com/ru/post/167327/
All Articles