Using IEC 61850 for remote disturbance analysis

Using IEC 61850 for remote disturbance analysisRoland Hamrénrhn02003@student.mdh.seMaster Thesis in Computer Science, 20p D-levelMälardalen UniversityPowel Energy Management ABÖstersund, Sweden

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 07Table of contents1 INTRODUCTION ....................................................................................................................................... 11.1 PURPOSE............................................................................................................................................... 11.2 GOAL.................................................................................................................................................... 11.3 CONSTRAINTS....................................................................................................................................... 22 RELATED WORK AND THEORY.......................................................................................................... 32.1 THE OPEN SYSTEMS INTERCONNECTION REFERENCE MODEL .............................................................. 32.2 CONVENTIONAL SUBSTATION COMMUNICATION PROTOCOLS ............................................................... 52.2.1 Modbus communication .................................................................................................................. 52.2.2 IEC 60870-5-103 substation communication.................................................................................. 72.2.3 Why a international standard was needed ...................................................................................... 82.3 IEC 61850, COMMUNICATION NETWORKS AND SYSTEMS IN SUBSTATIONS........................................... 92.3.1 Different parts of IEC 61850 standard series ................................................................................. 92.3.2 IEC 61850-7-2 Abstract Communication Service Interface.......................................................... 102.3.3 Information exchange.................................................................................................................... 112.3.4 Substation Configuration Language ............................................................................................. 122.3.5 Manufacturing Message Specification .......................................................................................... 132.4 TCP CLIENT ....................................................................................................................................... 133 STINA - DISTURBANCE AND FAULT INFORMATION COLLECTION AND ANALYSIS ... 143.1 HARDWARE ARCHITECTURE ............................................................................................................... 143.2 SOFTWARE DESIGN ............................................................................................................................. 163.2.1 Communication server software.................................................................................................... 163.2.2 Adaptor principle .......................................................................................................................... 173.3 NAVIGATOR........................................................................................................................................ 183.4 ADMINISTRATOR ................................................................................................................................ 183.5 COMTRADE VIEWER ....................................................................................................................... 194 LAB EQUIPMENT ................................................................................................................................... 205 COMTRADE - COMMON FORMAT FOR TRANSIENT DATA EXCHANGE .............................. 216 ABSTRACT SYNTAX NOTATION ONE.............................................................................................. 237 PROBLEM FORMULATION ................................................................................................................. 248 PROBLEM ANALYSIS............................................................................................................................ 259 METHODOLOGY .................................................................................................................................... 269.1 IDENTIFICATION OF SUITABLE INFORMATION MODELS........................................................................ 269.1.1 Connection Establishment............................................................................................................. 269.1.2 Downloading of COMTRADE files ............................................................................................... 279.2 MAPPING OF ABSTRACT SERVICES ...................................................................................................... 289.3 COMMUNICATION STACK ................................................................................................................... 289.3.1 Communication stack design considerations ................................................................................ 289.3.2 Useable Tools................................................................................................................................ 299.4 CREATING A STINA IEC 61850 COMMUNICATION PROTOTYPE.......................................................... 2910 SOLUTION................................................................................................................................................ 3010.1 ABSTRACT SERVICES.......................................................................................................................... 3010.1.1 The Associate Service............................................................................................................... 3010.1.2 The Abort Service ..................................................................................................................... 3010.1.3 The Release Service.................................................................................................................. 3110.1.4 The GetServerDirectory Service............................................................................................... 3110.1.5 The GetFile Service .................................................................................................................. 3210.1.6 The GetFileAttributeValues Service ......................................................................................... 3210.2 MAPPING OF ABSTRACT SERVICES ...................................................................................................... 3310.2.1 Mapping of Associate Service................................................................................................... 3310.2.2 Mapping of Abort Service......................................................................................................... 3310.2.3 Mapping of Release Service ..................................................................................................... 33III

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 0710.2.4 Mapping of GetServerDirectory Service .................................................................................. 3310.2.5 Mapping of GetFile .................................................................................................................. 3410.2.6 Mapping of GetFileAttributeValues ......................................................................................... 3410.3 MANUFACTURING MESSAGE SPECIFICATION...................................................................................... 3510.3.1 Protocol Data Units ................................................................................................................. 3510.3.2 Initiate Service.......................................................................................................................... 3510.3.3 Conclude-Service...................................................................................................................... 3710.3.4 Abort......................................................................................................................................... 3710.3.5 File services.............................................................................................................................. 3710.3.6 FileOpen................................................................................................................................... 3810.3.7 FileRead ................................................................................................................................... 3910.3.8 FileClose .................................................................................................................................. 3910.3.9 FileDirectory ............................................................................................................................ 3910.4 BER ENCODING/DECODING................................................................................................................ 4010.5 MAPPINGS BETWEEN C++ AND ASN.1 ............................................................................................... 4310.6 COMMUNICATION STACK ................................................................................................................... 4410.6.1 Communication stack specified by IEC 61850-8-1................................................................... 4510.6.2 Reduced communication stack.................................................................................................. 4610.7 STINA IEC 61850 COMMUNICATION PROTOTYPE .............................................................................. 5510.7.1 STINA IEC 61850 - Communication adapter........................................................................... 5510.7.2 STINA IEC 61850 - Process adapter........................................................................................ 5911 TESTING OF THE PROTOTYPE’S FUNCTIONALITY ................................................................... 6212 CONCLUSION.......................................................................................................................................... 6413 GLOSSARY ............................................................................................................................................... 6514 REFERENCES .......................................................................................................................................... 6715 APPENDIX A - ASN.1 AND BER............................................................................................................ 7015.1 TYPES ................................................................................................................................................. 7015.1.1 Simple type ............................................................................................................................... 7015.1.2 Structured type ......................................................................................................................... 7015.1.3 Tagged type .............................................................................................................................. 7115.1.4 Other types ............................................................................................................................... 7215.2 TAG CLASSES...................................................................................................................................... 7315.2.1 Universal .................................................................................................................................. 7315.2.2 Application ............................................................................................................................... 7315.2.3 Private ...................................................................................................................................... 7415.2.4 Context-specific ........................................................................................................................ 7415.3 ASN.1 TYPE EXAMPLE....................................................................................................................... 7415.4 BASIC ENCODING RULES .................................................................................................................... 7515.5 PRIMITIVE, DEFINITE-LENGTH METHOD .............................................................................................. 7615.5.1 Identifier octets......................................................................................................................... 7615.5.2 Length octets............................................................................................................................. 7615.5.3 Contents octets ......................................................................................................................... 7715.6 CONSTRUCTED, DEFINITE-LENGTH METHOD ....................................................................................... 7715.7 CONSTRUCTED, INDEFINITE-LENGTH METHOD.................................................................................... 77IV

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 07List of figuresFIGURE 2-1 – OSI MODEL [RAD07].......................................................................................................................... 3FIGURE 2-2 – MODBUS ON TCP/IP [PLA06]............................................................................................................. 6FIGURE 2-3 – IEC 60870-5-103 DATA MODEL [1] .................................................................................................... 7FIGURE 2-4 – CONCEPTUAL VIEW OF ACSI BASIC INFORMATION MODELS............................................................. 10FIGURE 2-5 – COMPATIBLE LOGICAL NODE............................................................................................................ 11FIGURE 3-1 – STINA HARDWARE ARCHITECTURE [POW06].................................................................................. 14FIGURE 3-2 – STINA SOFTWARE DESIGN .............................................................................................................. 16FIGURE 3-3 – STINA ADAPTOR PRINCIPLE............................................................................................................ 17FIGURE 3-4 – STINA NAVIGATOR......................................................................................................................... 18FIGURE 3-5 – STINA ADMINISTRATOR ................................................................................................................. 18FIGURE 3-6 – STINA COMTRADE-VIEWER........................................................................................................ 19FIGURE 4-1 – ABB 670 IED [ABB06B].................................................................................................................. 20FIGURE 5-1 – COMTRADE INVESTIGATED IN A GRAPHICAL COMTRADE VIEWER ............................................ 22FIGURE 10-1 – ACSI ASSOCIATE SERVICE............................................................................................................. 30FIGURE 10-2 – ACSI ABORT SERVICE.................................................................................................................... 30FIGURE 10-3 – ACSI RELEASE SERVICE................................................................................................................. 31FIGURE 10-4 – ACSI GETSERVERDIRECTORY SERVICE......................................................................................... 31FIGURE 10-5 – ACSI GETFILE SERVICE ................................................................................................................. 32FIGURE 10-6 – ACSI GETFILEATTRIBUTEVALUES SERVICE.................................................................................. 32FIGURE 10-7 – MAPPING OF GETSERVERDIRECTORY SERVICE TO MMS............................................................... 33FIGURE 10-8 – MAPPING OF GETFILE SERVICE TO MMS ....................................................................................... 34FIGURE 10-9 – MAPPING OF GETFILEATTRIBUTEVALUES SERVICE TO MMS........................................................ 34FIGURE 10-10 – REDUCED COMMUNICATION STACK DESIGN ................................................................................. 46FIGURE 10-11– TRANSPORT LAYER - SETIP .......................................................................................................... 47FIGURE 10-12 – TRANSPORT LAYER - CONNECTIONREQUEST ............................................................................... 48FIGURE 10-13 – TRANSPORT LAYER - SENDDATA................................................................................................. 48FIGURE 10-14 – TRANSPORT LAYER - RECEIVEDATA............................................................................................ 48FIGURE 10-15 – TRANSPORT LAYER -DISCONNECT ............................................................................................... 49FIGURE 10-16 – SESSION LAYER - SETIP ............................................................................................................... 49FIGURE 10-17 – SESSION LAYER - CONNECT ......................................................................................................... 49FIGURE 10-18 – SESSION LAYER - DATATRANSFER............................................................................................... 50FIGURE 10-19 – SESSION LAYER - FINISH .............................................................................................................. 50FIGURE 10-20 – PRESENTATION LAYER - SETIP .................................................................................................... 51FIGURE 10-21 – PRESENTATION LAYER - CONNECT .............................................................................................. 51FIGURE 10-22 – PRESENTATION LAYER - DATAREQUESTRESPONSE ..................................................................... 51FIGURE 10-23 – PRESENTATION LAYER - RELEASE................................................................................................ 52FIGURE 10-24 – APPLICATION LAYER - SETIP ....................................................................................................... 52FIGURE 10-25 – APPLICATION LAYER - INITIATE................................................................................................... 52FIGURE 10-26 – APPLICATION LAYER - GETFILE................................................................................................... 53FIGURE 10-27 – APPLICATION LAYER - GETDIRECTORY ....................................................................................... 53FIGURE 10-28 – APPLICATION LAYER - CONCLUDE............................................................................................... 53FIGURE 10-29 – STINA IEC 61850 COMMUNICATION ADAPTER DESIGN............................................................... 55FIGURE 10-30 – COMMUNICATION ADAPTER- INIT ................................................................................................ 56FIGURE 10-31 – COMMUNICATION ADAPTER - GETDATA ...................................................................................... 57FIGURE 10-32 – COMMUNICATION ADAPTER - CLEANUP....................................................................................... 58FIGURE 10-33 – STINA IEC 61850 PROCESS ADAPTER DESIGN............................................................................. 59FIGURE 10-34 – PROCESS ADAPTER - INIT.............................................................................................................. 59FIGURE 10-35 – PROCESS ADAPTER - PROCESSDATA............................................................................................. 60V

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 07FIGURE 10-36 – PROCESS ADAPTER - CLEANUP..................................................................................................... 61FIGURE 11-1 – STINA NAVIGATOR SHOWING DOWNLOADED DISTURBANCE INFORMATION ................................. 62FIGURE 11-2 – SELECTION OF COMTRADE IN STINA NAVIGATOR .................................................................... 62FIGURE 11-3 – INVESTIGATION OF A COMTRADE IN STINA COMTRADE-VIEWER ......................................... 63VI

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 07List of tablesTABLE 2-1 – PARTS OF IEC 61850 STANDARD SERIES ............................................................................................. 9TABLE 2-2 – LOGICAL NODE GROUPS [2] ............................................................................................................... 11TABLE 2-3 – SELECTION OF ACSI INFORMATION MODELS..................................................................................... 12TABLE 9-1 – FILE CLASS....................................................................................................................................... 27TABLE 9-2 – GETSERVERDIRECTORY SERVICE...................................................................................................... 27TABLE 10-1 – MMS BASED ON TCP/IP T-PROFILE ................................................................................................ 45TABLE 10-2 – TRANSPORT PACKET FORMAT.......................................................................................................... 47TABLE 15-1 – UNIVERSAL TYPES [OBJ07] ............................................................................................................. 73TABLE 15-2 – BER ENCODING OF TAG CLASSES [DER07] ...................................................................................... 76VII

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 07PrefaceFirst I want to thank Powel Energy Management for giving me the opportunity to do aninteresting and instructive master thesis covering the latest technology for substationcommunication.I would also like to thank Leif Nordin at E.ON in Sundsvall for lending me the equipmentneeded in this thesis, without the equipment it would have been almost impossible to producea good result.Finally I want to thank my supervisor Jan Gustafsson at Mälardalen University for goodadvice regarding the making and the finalization of this thesis report.VIII

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 071 IntroductionPower networks are monitored and controlled by different types of substation automationdevices in order to handle line failures, protect expensive equipment, control power flow, andto register power disturbances. Different vendors of substation automation devices havetraditionally developed their own proprietary communication solutions, which have led to theexistence of several different communication protocols for the same type of communication.This multitude of protocols has resulted in difficulties in integrating equipment from differentmanufactures in the same substation since various types of protocol converters are needed. Anew global standard named IEC 61850 has however emerged during the last few years withthe goal to solve the different problems regarding substation communication and integration.Powel Energy Management AB, which is a Swedish subsidiary of the fast growingNorwegian Powel ASA group, provides IT-solutions to municipalities, utilities and othercompanies in the energy market. Powel Energy Management AB has developed a system fordisturbance analysis, called STINA [Pow06] (a Swedish acronym for STörning, INsamling,Analys). STINA is currently the dominating tool for disturbance analysis on the Nordicenergy market and it is used by Svenska Kraftnät, Vattenfall, Fortum, and E.ON amongothers. The STINA system collects and normalizes information from different types andbrands of protection and disturbance recording devices, and thus makes it easier for users todo disturbance analysis and fault locating since only one tool is needed regardless of themanufacturer of the device. Previously, disturbance engineers had to use different proprietarytools for different devices. In order to communicate with different manufacturers’ protectiondevices the system currently needs several different communication adapters or gateways.The latest trend however is that several manufacturers, for example ABB, Siemens, Areva,Vamp etc., are supporting the new global substation communication standard IEC 61850 intheir new devices. Powel is now interested in integrating support for communication withdevices supporting the new standard into their system, and the purpose of this thesis is toshow how the standard can be used in practice, even outside the substation communicationbus.1.1 PurposeThe purpose of this master’s thesis in computer science is to show that it is possible tointegrate communication with IEC 61850 compliant devices in an already existing system fordisturbance analysis. In other words, the purpose shows how the new global substationcommunication standard IEC 61850 can be applied in the area of remote disturbance analysis.The thesis will not only focus on the integration of IEC 61850 communications with thedisturbance analysis system STINA, a theoretical study will also be conducted with thepurpose to answer the question: “What is the difference between IEC 61850 and earliersubstation communication protocols?”1.2 GoalThe goal with this thesis is to develop a prototype for IEC 61850 communication between thedisturbance analysis system called STINA [Pow06] and IEC 61860 compliant devices. Theprototype should theoretically be able to communicate with equipment developed by ABB,Areva, Siemens, Vamp, or by any other company, as long as the equipment complies with thenew standard. In this way, the number of necessary STINA adapters will in time decrease asthe energy companies replaces their old equipment with newer IEC 61850 compliant ones.1

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 071.3 ConstraintsThe thesis should be completed after approximately 20 weeks, and therefore it was delimitedto only a small part of IEC 61850. The minimum requirements of the prototype were stated inthe beginning of the project.• The prototype should be able to communicate with devices supporting IEC 61850, andprovide STINA information useable for remote disturbance analysis.2

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 072 Related work and theory2.1 The Open Systems Interconnection Reference ModelThe Open Systems Interconnection Reference model, shortly called the OSI model, is ageneric model that describes how different applications may communicate with each other.The model defines a communication stack with seven different layers (Layer 1 to 7). Layerdiagrams are usually drawn with layer one at the bottom and layer seven at the top of thecommunication stack according to Figure 2-1. Each layer uses services provided by the layerbelow and in turn provides services to the layer above. [Pcs07]Figure 2-1 – OSI model [Rad07]Layer 1 – Physical LayerThe physical layer in the OSI-model defines all the physical and electrical specifications of anetwork device.Layer 2 – Data Link LayerThe second layer, the data link layer, defines the access strategy for sharing the physicalmedium including data link and media access issues. The data link layer is responsible fornode to node packet delivery.Layer 3 – Network LayerThe network layer provides functionality for transferring data from a source to a destinationvia one or more networks. This layer is thereby responsible for addressing the messages andend to end packet delivery. The IP protocol is one of the most well known network layerprotocols.3

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 07Layer 4 – Transport LayerThe transport layer provides functionality for reliable data transfer between hosts and isusually responsible for communication error recovery and flow control. TCP is currently oneof the most used transport Layers, and can be considered as common knowledge.Layer 5 – Session LayerThe session layer provides the functionality for establishing, managing and terminatingcommunication sessions between end-user processes.Layer 6 – Presentation LayerThe presentation layer is responsible for the delivery and formatting of data, so that the datalater can be processed by the application layer, or sent via the Session Layer.Layer 7 – Application LayerThe application layer is closest to the end-user and provides services that make it possible forone application (end-user) to communicate with an application on another computer.4

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 072.2 Conventional Substation communication protocolsIEC 60870-5-103 and the Modbus protocol are two of the many protocols that are supportedby STINA today. These two is also two of the most used conventional substationcommunication protocols, which make them appropriate for a comparison with IEC 61850. Ashort introduction to these two protocols will be presented in the next two sections (2.2.1,2.2.2), this in order to easier explain why a new global standard was needed.2.2.1 Modbus communicationIn 1979 the PLC manufacturer Modicon introduced a simple field-bus communicationprotocol called Modbus. Modbus can be considered as the industry’s first “open field bus”communication protocol and it is now a de facto standard. [Wik07][Pla06]Modbus is an application layer protocol that provides client/server communication betweendevices. It is mostly used on slow serial communication interfaces (RS232, RS485) but it canbe used on any other physical interface, e.g. Ethernet. The conversation between a client and aserver is based on Modbus protocol data units. [Jam06]Modbus Protocol Data UnitThe Modbus protocol specifies three different types of protocol data units (PDUs): the requestPDU, the response PDU and the exception response PDU. All PDUs are constructedaccording to the same format; all data units consist of a function code and a data field. Aconversation is initiated by the client when it sends a request PDU to the server, the serveranswers to the request by sending a function specific response PDU if everything worked as itshould or an exception response if an error occurred. [Jam06]Request PDU1) Function code – Function2) Data - Function specific dataResponse PDU1) Function code - Code corresponding to the request2) Data - Response specific dataException response PDU1) Function code - Code corresponding to the request + 1282) Data – Exception codeModbus functionsModbus specifies a number of standardized functions and exceptions, each function orexception is assigned to a specific function code. Function codes in the range from 1 to 127specify functions, codes between 129 and 255 represents exceptions. The latest Modbusversion divides the function codes into three categories: public, user defined and reserved.[Jam06]Public function codes are guaranteed to be unique, and they specify functions that are welldefined and publicly documented. The function documentation consists of a function5

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 07description, the assigned function code, the Request PDU, the Response PDU and theException Response PDU, among other useful information.User defined function codes are available for companies who want to implement their ownfunctions not covered by the Modbus protocol. There is no guarantee that a user definedfunction code is unique.Reserved function codes are currently used by some companies for legacy products and thesecodes are not available for public use.Transmission of dataModbus protocol data units are mapped into Modbus application data units, shortly calledADUs. An application data unit consists of an address, a Modbus protocol data unit and a 16-bit checksum used for communication error detection. The address is represented by a numberbetween 0 and 247 where 0 is used as a broadcast address. [Jam06]There are two different modes for serial transmission between Modbus clients and Modbusservers: the ASCII-mode and the RTU-mode. In ASCII mode the messages are sent in areadable format by encoding every byte as two ASCII characters. In RTU-mode the bytes areinstead transferred as two four-bit hexadecimal digits. The main advantage of the RTU-modeis the higher throughput. [Jam06]The Modbus protocol can also be used on Ethernet networks. This is done by encapsulatingthe Modbus packets into TCP/IP packets according to Figure 2-2. The 16-bits Modbuschecksum is replaced by the 32-bits TCP/IP checksum. [Pla06]TransactionIdentifierProtocolIdentifierLengthFieldModbusFrameTCP FRAMEMODBUS FRAMEADDRESSFUNCTIONCODEDATACHECKSUMFigure 2-2 – Modbus on TCP/IP [Pla06]Advantages and disadvantagesThe Modbus/ModbusTCP protocol is relatively easy to understand and to implement whichhas made it successful. One other advantage with Modbus is that the standard is open foreverybody, specifications and implementation examples are available for free at SchneiderAutomation website. [Pla06] The Modbus protocol is as earlier stated simple, but itssimplicity is also its biggest disadvantage. The data model used by Modbus/Modbus TCP istoo simple and cannot provide support for complex object structures, self-describing devices,automatic configuration etc. Nor does the standard cover all functions used by different typesof substation devices. [Wik07] The manufacturers have instead been forced to define theirown private functions, and that has resulted in decreased operability and compatibilitybetween different manufacturers.6

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 072.2.2 IEC 60870-5-103 substation communicationIEC 60870-5 is another substation communication standard that has been, and is still, widelyused. This standard was introduced in the early nineties and it is said to be forerunner to IEC61850. IEC 60870-5 is constructed according to the Enhanced Performance Architecture(EPA) reference model. The EPA model uses three of the seven layers defined by the OSImodel:the physical layer, the link layer and the application layer. [Ipc06]The companion standard IEC 60870-5-103 defines an application layer, based on IEC 60870-5, designed for communication with protection devices. It defines two different methods forinformation exchange. One of the methods is based on explicitly specified ApplicationService Data Units (ASDUs) and application procedures used for transmission ofstandardized messages. The other method is based on generic services for transferring alltypes of information. IEC 60870-5-103 is currently mostly used on slow serial physical layersbut fiber optics is also supported. [Ipc06]Data modelThe standardized functionality is based on Application Service Data Units (ASDUs)constructed according to Figure 2-3. The data unit is divided into several fields, which arealways transferred in the same sequence (TOP-DOWN)The first octet of the Data UnitIdentifier is the Type identificationfield. Only type numbers between1 and 31 are specified by thestandard and only those can beused for compatible data exchange.All other types (32 – 255) belongto the private range which can beused differently by differentmanufacturers. The data modelwill not be explained any further,more information about it and thedifferent fields can be found inIEC 60870-5-103 specification [1].7Figure 2-3 – IEC 60870-5-103 data model [1]DisadvantagesIEC 60870-5-103 is a relative well used protocol and several manufacturers are supportingthis standard in their protection devices, but it has several limitations.IEC 60870-5-103 is limited to 255 types and only 31 of those are standardized. Whenmanufacturers define their own types, the interoperability and compatibility between devicesfrom different manufacturers decrease. [Ipc06]The data representation (ASDU) is a part of the communication stack, functionalityrepresented by the data model is thereby mixed together with functionality provided by thecommunication services, and that makes the standard hard to adapt to future communicationtechnologies. [Hog04] Further, it does not provide support for self describing objects andautomatic device configuration. The scope of IEC 60870-5-103 is communication withprotection devices and not communication with all kinds of substation devices. [Sch02]

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 072.2.3 Why a international standard was neededTraditionally, different manufacturers of substation devices have developed their ownproprietary communication solutions for substations and it has therefore been difficult tointegrate devices from different vendors in one substation. Gateways and different types ofprotocol converters have been used to make it possible for devices from differentmanufacturers to communicate with each other. This solution to interoperability is howevernot a good one since the extra equipment may introduce communication errors and delays. Abetter way to solve the interoperability problem in substations is to have one global standardthat cover all aspects of communication in substations. [Sch03]One of the most common and largest drawbacks of the different standards available today,e.g. Modbus and IEC 60870-5-103, is that they do not separate the data representation fromthe communication services and the protocol stacks. It is not unusual that the standards definespecific bit-sequences for the messages. A bit-sequence is dependent on the communicationprotocol and the protocol is dependent on the communication technology, and whentechnology changes then the bit-sequences must be updated to fit the new technology. Acommunication standard based on protocol dependent bit sequences is therefore not a futureproofsolution. [Hog04]One other drawback with the legacy protocols is that the data models provided by theseprotocols are too simple and cannot provide support for all possible functions in substationdevices. In addition they do not specify how the information should be organized in thephysical devices which have resulted in that system engineers have been forced to manuallyconfigure objects and functions by mapping them to system variables, low-level registers, I/Omodules etc. [Mac06]The biggest disadvantage with the traditional substation communication standards washowever that none of them covered all aspects of substation communication. The new globalstandard IEC 61850 was designed to solve the problems with substation communication, andits purpose is to provide a future-proof standardized way to communicate. IEC 61850separates the data representation, communication services and protocol stacks from eachother, and it is therefore a future-proof solution and can easily be updated to fit newcommunication technologies without changing the standardized data models. The data modelof IEC 61850 is object-oriented and provides support for all possible functions in substations,function names and their data are also specified. A new configuration language format (SCL)is also provided by IEC 61850 which makes the configuration of devices a lot easier thanbefore. This new standard is very extensive and it is much more than just a substationcommunication protocol. [Hog04]8

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 072.3 IEC 61850, Communication networks and systems insubstationsIEC 61850, Communication networks and systems in substations, is a new internationalstandard for substation automation systems. It is the first and only global standard that coversall the communication needs within substations and it is also made to be a future proofsolution to substation automation problems. The main goal with this new standard is toprovide interoperability between substation devices. [Hog04] A more detailed overview ofIEC 61850 describing the standard and its features can be found in [Mac06]2.3.1 Different parts of IEC 61850 standard seriesThe standard is divided into several parts which cover different aspects regarding substationautomation. IEC 61850 is, as one can see from Table 2-1, very extensive; it does not onlycover the communication but also for example conformance testing, requirements and thespecification of a new configuration language. [Mac06] This thesis has its focus onintegrating support for communication with IEC 61850 compliant devices in an existingsystem for remote disturbance analysis and not on substation automation in general, the thesiswill therefore not be affected by all parts of this new standard.Parts of IEC 61850 standard seriesIEC 61850-1Introduction and overviewIEC/TS 61850-2GlossaryIEC 61850-3General requirementsIEC 61850-4System and project managementIEC 61850-5Communication requirements for functions and device modelsIEC 61850-6Configuration description language for communication in electrical substations related to IEDs.IEC 61850-7-1Basic communication structure for substation and feeder equipment - Principles and modelsIEC 61850-7-2Basic communication structure for substation and feeder equipment - Abstract communication service interface(ACSI)IEC 61850-7-3Basic communication structure for substation and feeder equipment - Common data classesIEC 61850-7-4Basic communication structure for substation and feeder equipment - Compatible logical node classes and dataclassesIEC 61850-8-1Specific Communication Service Mapping (SCSM) - Mappings to MMS (ISO 9506-1 and ISO 9506-2) and toISO/IEC 8802-3IEC 61850-9-1Specific Communication Service Mapping (SCSM) - Sampled values over serial unidirectional multidrop pointto point linkIEC 61850-9-2Specific Communication Service Mapping (SCSM) - Sampled values over ISO/IEC 8802-3IEC 61850-10Conformance testingTable 2-1 – Parts of IEC 61850 standard series9

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 072.3.2 IEC 61850-7-2 Abstract Communication Service InterfaceIEC 61850 uses an object-oriented approach to define the standardized functionality insubstation devices. The Abstract Communication Service Interface (ACSI) specified by IEC61850-7-2 provides information models that describe how the information should beorganized and how it should be exchanged between different devices. Some of models arebasic information models, which are used to build up domain specific information models.The ACSI also provides other information models, e.g. models for file transfer andapplication associations. All ACSI models are defined as classes which both contain attributesand services for information exchange. [3]Basic information modelsThe basic information models are a fundamental part of IEC 61850 since they are used tobuild up other domain specific models, for example substation automation models. Figure 2-4shows how the different models are related. Note that every model in the diagram except theSERVER has a Name. The name consists of an ObjectName and an ObjectReference. TheObjectReference is a concatenation of Object Names from the different containers in whichthe object is found. [3]SERVERThe SERVER-model represents a physical device. Allother models provided by the ACSI are part of theSERVER. The main purpose of the SERVER is tocommunicate with clients and peer-devices.LOGICAL-DEVICEA LOGICAL-DEVICE (LD) works like a container forlogical nodes. A LOGICAL-DEVICE should usuallycontain nodes with the same type of functionality, e.g.several nodes with protection related functionality canbe grouped into one logical device and nodes withcontrol functionality can be grouped into another. Aphysical device can in this way consist of one or severallogical devices.LOGICAL-NODEThe LOGICAL-NODE model represents a specificfunction and contains the consumed or producedinformation (DATA)Figure 2-4 – Conceptual view of ACSIbasic information modelsDATAThe DATA-model is used to specify typed information,for example a sample value. Data contains a few orseveral data attributes.10

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 07Figure 2-5 – Compatible logical nodeLogical nodesThe basic information models are, as earlier stated,used to build up domain specific informationmodels. IEC 61850-7-4 defines about 90 differentlogical node classes, called compatible logicalnodes, with standardized names and data. Thesenodes are divided into 13 groups, shown by Table2-2, and cover the most of the functionality usedby different types of substation devices. There arealso standardized rules which should be used tocreate new logical node classes when extrafunctionality not covered by the standard is needed.Figure 2-5 shows how the compatible logical nodeclasses are built up by using the basic informationmodels. [2]Logical node groupsNumber of logical nodesSystem logical nodes 3Protection functions 28Protection related function 10Supervisory control 5Generic references 3Interfacing and archiving 4Automatic control 4Metering and measurement 8Sensors and monitoring 4Switchgear 2Instrument transformer 2Power transformer 4Further power system equipment 15Total number of logical nodes 92Table 2-2 – Logical node groups [2]2.3.3 Information exchangeThe Abstract communication service interface is, as it sounds, only abstract. The servicesdefined by the ACSI models are called abstract services and they only describe the requiredactions on the receiving side of a service (The server side). In order to make datacommunication possible the services must be mapped to a real communication protocol. Themapping to a real communication protocol is specified by a Specific Communication ServiceMapping (SCSM). In this way the standardized functionality in IEC 61850-7-2 is not directlydependent on a specific communication protocol and that makes IEC 61850 to a future-proofsolution. The communication technology can be changed to a newer technology but thestandardized information models will always be the same. Today, the most of the ACSIservices are mapped to the Manufacturing Message Specification (MMS) as specified by61850-8-1. [Mac06] Table 2-3 shows an overview of some of the models and abstractservices provided by IEC 61850-7-2.11

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 07Server modelGetServerDirectoryAssociation modelAssociateAbortReleaseData-set modelGetDataSetValuesSetDataSetValuesCreateDataSetDeleteDataSetGetDataSetDirectoryData-modelGetDataValuesSetDataValuesGetDataDirectoryGetDataDefinitionACSI modelsLogical-Device modelGetLogicalDeviceDirectoryLogical-node modelGetLogicalNodeDirectoryGetAllDataValuesControl modelSelectSelectWithValueCancelOperateCommandTerminationTimeActivatedOperateFile transfer modelGetFileSetFileDeleteFileGetFileAttributeValuesTable 2-3 – Selection of ACSI information models2.3.4 Substation Configuration LanguageIEC 61850-6-1 specifies a new Substation Configuration Language (SCL) based on theeXtensible Markup Language (XML) to describe the configuration of substation automationsystems based on the IEC 61850 standard. A hierarchy of XML-based configuration files isspecified by SCL, all files in the hierarchy have the same format but different scopes. Fourdifferent types of configuration files are specified:• System Specification Description (SSD) files• IED Capability Description files (ICD) files• Substation Configuration Description (SCD) files• Configured IED Description (CID) filesThe SCL files needed for IED configuration can be generated by off-line system developmenttools, which eliminates most, if not all, manual configuration. Another advantage with SCL isthat it enables the sharing of IED configuration among users and suppliers, which reduces theinconsistencies and misunderstandings in system configuration and requirements. Users canprovide their own SCL files to ensure that the devices will be delivered properly configured.[Mac06]SCL does not only make it possible to build up and configure substation automation systems,it can also be used for specification of new ones. [Hog04]12

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 072.3.5 Manufacturing Message SpecificationThe Manufacturing Message Specification (MMS) is an international standard that defineshow networked devices and/or computer applications may communicate with each other.MMS (ISO 9506) was developed by Technical Committee Number 184 (TC184), IndustrialAutomation, of the International Organization for Standardization (ISO), during the lateeighties, and it is today jointly managed by TC184 in collaboration with the InternationalElectro technical Commission (IEC).The MMS standard is based on the Open Systems Interconnection (OSI) networking modeland provides messaging services appropriate for a variety of different application, devices,and industries. The standard is divided into several parts, where the two first acts like the“core” of MMS. The first part (ISO 9506-1) is the service specification, and the second part(ISO 9506-2) is the protocol specification. The protocol specification defines the rules ofcommunication, e.g. sequencing of messages, message format, interaction with other layers ofthe OSI model etc.A presentation layer standard called Abstract Syntax Notation One (ASN.1 – ISO 8824) isutilized by the MMS protocol specification to specify the format of he messages used by theMMS services. The services provide for example functionality for initializing and managingof application associations (connections), file transfer, reading/writing of named variables,and remote program control. [Sis95]MMS provides much of the functionality needed for implementation of the abstract servicesdefined by IEC 61850-7-2, and that’s the reason for why the mapping of abstract services toMMS exists.2.4 TCP ClientThe Borland C++ Builder 6.0 environment provides a class called TIdTCPClient whichencapsulates a complete TCP client. The class can for example be used for initialization of aTCP/IP connection with a specific server, and for bi-directional data transfer between a clientand a server. It should in other word be stupid to implement the TCP/IP protocol, since it isalready available for use.TCP/IP is today a widely used protocol for data communication, and I feel that it would beunnecessary to explain TCP/IP in detail, since there are several solutions available for TCP/IPcommunication, e.g. the TIdTCPClient provided by Borland C++ Builder 6.0. But those whowant to have some more information about TCP/IP can always visit the free online dictionaryWikipedia: http://en.wikipedia.org/wiki/Internet_protocol_suite13

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 073 STINA - Disturbance and Fault Information Collectionand AnalysisThe disturbance analysis and surveillance system STINA was originally developed for TheNational Grid as an extra support system for gathering and analysis of disturbances and faulton electricity networks. The STINA system collects and normalizes information fromdifferent types and brands of protection and disturbance recording devices, and thus makeseasier for users to do disturbance analysis and fault locating since only one tool is neededregardless of the manufacturer of the device. Information is not only gathered from physicaldevices, it can also be retrieved via for example emails and reports from operationstechnician. The information about STINA and the figures describing the system are from theSTINA product brochure [Pow06].3.1 Hardware architectureThe STINA system has client/server hardware architecture, and it comprises client units, acommunications server, and a data server as modeled by Figure 3-1. STINA gathers andnormalizes data related to disturbances on power networks and makes the informationaccessible for disturbance analysis. Information is retrieved from different sources, e.g.disturbance recorders, fault locators, and event recorders.DR – Disturbance recordersPR – Protection relaysER – Event recordersFL – Fault locatorsPQ – Power quality metersFigure 3-1 – STINA Hardware architecture [Pow06]Communications serverThis part of STINA is responsible for gathering andprocessing of data. It comprises software that acts likethe engine of the system, in order to ensure lowresponse times for data access.14

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 07Database serverThe database server is used for long-term data storage.Data is stored in its file system and in the Oracledatabase.Database and File SystemDisturbance information is primarily stored in theOracle database. Not only disturbance data is stored inthe database, information regarding substations,equipments, schedules, logs, and connections are alsolocated here. COMTRADE files, documents, and otherfiles are stored in the file system.ClientsThe client tools provided by STINA can be used foradministration and configuration of the system, dataaccess, disturbance analysis, and fault locating.The NAVIGATOR client tool is used for locating and structuring of data. It can also be usedfor manual downloading of information from equipment in substations.The ADMINISTRATOR client tool is used for administration and configuration of thesystem.The ARCHIVER client tool can be used to make a backup of the present information, and ifneeded to restore the system.The COMTRADE-VIEWER is used for investigation of COMTRADE files.Communications equipmentDisturbance Information can be gathered from differentsources via for example multiple modem connections,TCP/IP, and other types of communication solutions.Remote equipmentDifferent types of remote equipment is supported, e.g.Disturbance recorders (DR) and Protection Relays(PR).Local networksLocal Area Network is used for communication withinSTINA (between Clients and Server), as well as forcommunication with some of the remote equipment.15

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 073.2 Software designThe software of STINA is divided into several sub-systems, which together form ahomogenous system. Each sub-system has its own area of responsibility and clearly definedinterfaces. This approach was chosen to minimize the dependencies between different parts ofSTINA, and to make the architecture flexible for future additions and modifications. Figure3-2 shows an overview of the software parts included in a STINA system.Figure 3-2 – STINA Software designThe purpose of this thesis was to show how IEC 61850 could be used for disturbanceanalysis, and the goal was to develop an integration of IEC 61850 communication to STINA.To be able to understand the presented solution, the reader must to have some basicknowledge about some software parts in the STINA communication server.3.2.1 Communication server softwareThe communication server software is separated into layers. The upper layer provides anoverall general framework, while the lower layers consist of the parts of the software adaptedto manage customer specific requirements and equipments, and partly of support functions inthe form of adaptation to the database and outside units.KernelSrvKernelSrv corresponds to the highest layer in the communication server software andprovides the overall general framework, its main functionality is to control and administrateall jobs in the system. It handles the DCOM-based communication between the clients and thecommunication server and reacts on requests from the Clients, e.g. to start manuallydownloading of disturbance data from a specific station/device. KernelSrv uses servicesprovided by CommSrv and ProcSrv in order to gather and process disturbance data.CommSrvCommSrv’s responsibility is to handle communication and to collect disturbance data fromdifferent kinds of physical devices. The adaptor principle is used to be able to communicatewith a variety of different types of devices.16

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 07ProcSrvProcSrv’s responsibility is to convert and normalize the data downloaded by the CommSrv.The adaptor principle is used to be able to support a variety of different devices.DispatchSrvDispatchSrv’s responsibility is to administrate all scheduled activities in STINA, e.g.schedules for automatic collecting of disturbance data from physical devices located insubstations. DispatchSrv can start jobs, e.g. collecting of data, by using services provided byKernelSrv.3.2.2 Adaptor principleThe adaptor principle is used by STINA to be able to communicate with several differenttypes of devices. For each type of device separate adaptors are developed. The number ofadaptors used by STINA depends on the number of different types of equipment integrated inthe system. An adaptor is in real term a COM object encapsulated in a DLL. Two adaptors areneeded for each type of device, a communication (COMM) adaptor used by CommSrv todownload the data and store it as temporary files, and a process (PROC) adaptor used byProcSrv in order to process and normalize the downloaded data. The integration of IEC 61850communication in STINA will result in a COMM adapter for communication to IEC 61850compliant devices, and a PROC adapter that should process and normalize the downloadedinformation. Figure 3-3 gives an overview of the adaptor principle.Device XCommunicationmediaGeneralServer softwareProcSrvDatabaseAdaptorX_PROCAdaptorX_COMMCommSrvFigure 3-3 – STINA Adaptor principle17

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 073.3 NavigatorThe Navigator is STINA’s ordinary user’s client tool for searching, organizing, and viewingdata. It is also possible to initialize manual downloading of disturbance data by using thistool. The Graphical user interface is similar to the GUI used by Windows Explorer, it isdivided into two parts where the left shows a tree structure of catalogs and the right oneshows the contents of the current catalog. (See Figure 3-4)Figure 3-4 – STINA Navigator3.4 AdministratorThe Administrator tool is used for administration and configuration of STINA. This toolprovides for example functionality for adding, changing, removing, installations of stations,devices in substations, and communication settings. Figure 3-5 shows the STINAadministrator tool.Figure 3-5 – STINA Administrator18

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 073.5 COMTRADE ViewerThe STINA COMTRADE Viewer, shown by Figure 3-6, is used for investigating disturbancedata saved as COMTRADE files. Disturbance recordings downloaded from different types ofdevices are converted by STINA, if applicable, into the standard COMTRADE format, whichmakes it possible to compare disturbance recordings downloaded from different devices in asimple way.Figure 3-6 – STINA COMTRADE-Viewer19

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 074 Lab equipmentABB has developed a new series of products, the IED670 product series, for substationautomation. These new products implement all aspects of IEC 61850, and can interoperatewith other IEC 61850 compliant devices, tools, and systems. They do not only support IEC61850, IEC 60870-5-103 and older ABB specific communication protocols are alsosupported, which makes it possible to use these new products in parallel with older ones fromABB.The IED670 products are delivered pre-configured, type tested and with default parameters, tomake them easy to use. They are designed for TCP/IP and high-speed Ethernet based onreliable and disturbance free optical communication. They are available in three differentsizes as shown by Figure 4-1. [Abb05][Abb06a] A REL670, which is designed for protection,monitoring and control of overhead lines and cables, was used in this thesis during thedevelopment and for verifying of functionality of the final prototype.Figure 4-1 – ABB 670 IED [Abb06b]20

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 075 COMTRADE - Common Format for Transient DataExchangeCOMTRADE (IEEE STD C37.111) specifies a common format for transient data exchange.Transient data is used for analysis and identification of undesirable sources of harmonics andunbalances, fault locating and analysis of events causing power network instability. TheCOMTRADE format consists of four different files, a configuration file, a data file, a headerfile, and an information file. [CMT07a][CMT07b]COMTRADE filesThe configuration file (*.CFG) contains information about:• Station name, used for identification.• Number of digital channels• Number of analog channels• Channel names, units and conversion factors• Line frequency• Sample rate• Number of samples• Start time (Date and time of first data value)• Trig time (Date and time of trigger point)• Data file type (BINARY or ASCII)The data file (*.DAT), which either can be in ASCII or BINARY format, contains the actualtransient data. The header file (*.HDR), which is optional, can be used to provide informationabout the source, the location, the data format etc. The information file (*.INF) is optional andcan be used to provide setup information.Figure 5-1 gives an example of a COMTRADE being investigated in a graphicalCOMTRADE-viewer. The COMTRADE graph shows recorded sample values from bothanalogical and digital channels around the time of a disturbance. The information displayedby the viewer is useful when doing different kinds of disturbance analysis. Disturbanceanalysis is however a subject not covered by this report, but COMTRADE files will be usedin the prototype implementation.21

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 07Figure 5-1 – COMTRADE investigated in a graphical COMTRADE viewer22

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 077 Problem formulationPowel has developed a disturbance collecting/analysis system called STINA. STINAcurrently supports a variety of legacy substation communication protocols. Different vendorsof protection devices and other substation devices, however have started to build in supportfor the new global substation automation standard IEC 61850 into their devices and Powel isnow interested in integrating support for IEC 61850 communication into their system.The IEC61850 substation communication standard is very extensive and covers all aspectsregarding communication in substations. The purpose of this thesis is to show how the newsubstation automation standard can be used outside the substations. The major goal is todevelop an IEC 61850 communication prototype to STINA, not a complete product. Thework was intended to follow these steps:• Study of the disturbance analysis system STINA.• Study of IEC 61850 standard series and other conventional substation communicationprotocols• Installation of lab equipment, e.g. ABB REL670.• Design of a STINA IEC 61850 communication prototype• Implementation• Testing• Report writing• Presentation of the STINA IEC 61850 communication prototype24

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 078 Problem AnalysisThe major problem, which is to develop an STINA IEC 61850 communication prototype, canbe divided into several sub-problems. This section describes the different sub-problems tosolve.Identification of suitable information modelsSTINA needs information suitable for disturbance analysis. Which of the information modelsprovided by IEC 61850 can be used to retrieve this information?Mapping of abstract servicesThe identified information models provide abstract services for information exchange. Whichof these abstract services is useable by the STINA IEC 61850 communication prototype, andhow does the mapping to the real communication protocol look like?Communication StackThe protocol mappings are by themselves not enough to make communication possible. Whatcommunication stack should be used, and how should it be implemented?The implemented communication stack should be used for integrating support for IEC 61850communication in STINA.Creating a STINA IEC 61850 communication prototypeThe goal of this thesis is to make and show that it is possible to integrate support for IEC61850 compliant devices in STINA. The final prototype must be able to provide STINA withsome useful information. To be able to do that, knowledge in both STINA and IEC 61850 isneeded. How should the downloaded information be accessible by STINA?25

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 079 MethodologyThe sub-problems, which all had to be solved in order to make a functional and usable STINAIEC 61850 communication prototype, were solved by using the following methods.9.1 Identification of suitable information modelsSTINA and earlier STINA communication was investigated to find out which kind ofinformation STINA needs. It was found out that a lot of the earlier STINA communicationsolutions provide the system with COMTRADE files in one way or another. Some of thesolutions generated COMTRADE files from raw transient data, and other solutionsdownloaded instead COMTRADE files directly from the physical devices. The COMTRADEfiles can later be investigated by using the graphical COMTRADE-viewer provided by theSTINA system. A communication prototype that can provide STINA with COMTRADE filescontaining disturbance information from IEC 61850 compliant devices, either bydownloading COMTRADE files directly from the devices or generating COMTRADE filesfrom raw transient data, seemed to be good and useable for remote disturbance analysis.IEC 61850 was studied to see how the information needed to make a COMTRADE could beaccessed. It was however found out that COMTRADE files are generated by the disturbancerecorder (Logical node RDRE specified in IEC 61850-7-4) in IEC 61850 compliant devicesand stored within the server file store. It should thereby be possible to download generatedCOMTRADE files directly from IEC 61850 compliant devices as long as they have adisturbance recorder. The Logical Nodes and Device models of the ACSI will not be used bythe STINA IEC 61850 communication prototype, since file transfer is described by a separateACSI information model called the File-Transfer model.9.1.1 Connection EstablishmentA connection must be established before we can use services provided by the File-Transfermodel to download the wanted COMTRADE files. IEC 61850-7-2 specifies a model calledthe TWO-PARTY-APPLICATION-ASSOCIATION (TPAA) model which describes theactions on the Server side for establishing, managing, and terminating, of connectionsbetween IEC 61850 clients and servers. [3] The following abstract services are provided bythe TPAA model:The Associate ServiceThe Associate Service should be used to establish an association between aclient and a server. [3]The Abort ServiceThe Abort Service should be used to abort the association. [3]The Release ServiceThe Release Service should be used to terminate an association. [3]26

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 079.1.2 Downloading of COMTRADE filesThe File-Transfer model specified by IEC 61850-7-2 defines how files are constructed,services for managing and transferring of files are also described in an abstract way. A Filestored in the server should according to IEC 61850-7-2, FileTransfer model, have a formataccording to Table 9-1.FILEAttribute NameAttribute TypeFileName VISIBLE STRING 255FileSizeINT32ULastModifiedTimeStampServicesGetFileSetFileDeleteFileGetFileAttributeValuesTable 9-1 – FILE classTwo of the services provided by the FILE class describe functionality needed by the STINAIEC 61850 communication prototype, the GetFileAttributeValues service and the GetFileservice. The GetFileAttributeValues service can be used by a client to get the size and lastmodified time of a specific file. [3] This information is needed to sort out files that havealready been downloaded by the prototype, so that a specific COMTRADE file is onlydownloaded one time. The GetFile service will be used for downloading of COMTRADEfiles.File SelectionThe FILE class provides only functionality for managing files and file transfer. To be able touse the GetFile or the GetFileAttributeValues service provided by the FILE class, we mustknow what files we can download. All files are stored in the server file store, and a list withfile names can be received by using the GetServerDirectory service provided by theSERVER model. The prototype will use this functionality to retrieve a list of accessible files,and then sort out which files to download by using file attributes like filename, and lastmodified time. The GetServerDirectory service is described by Table 9-2.GetServerDirectoryRequestObjectClassResponse+Reference[0..n]Response-ServiceErrorRequest:The ObjectClass parameter specifies if we use theservice for getting a list with filenames or a list withobject references to logical devices. [3] Theprototype should only be able to get the filenames.Table 9-2 – GetServerDirectory serviceResponse+:Reference shall contain file names or object references to logical devices [3]. Only filenameswill be received by the STINA IEC 61850 prototype.Response-A Response- indicates that the request failed [3]. An appropriate ServiceError is sent fromthe Server.27

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 079.2 Mapping of abstract servicesThe prototype will only use Client/Server communication services identified in Clause 9.1.Those services should according to IEC 61850-8-1 be implemented by using servicesprovided by Manufacturing Message Specification.9.3 Communication StackLab equipment was needed for testing during developing and for verifying the functionality ofthe communication stack. An ABB REL670 relay [Abb05] was borrowed from E.ON inSundsvall and installed at Powel Energy Management in Östersund. The relay was connectedto Powel’s Local Area Network with an Ethernet-fiber optical network converter.9.3.1 Communication stack design considerationsTo be able to implement the MMS services which should be used to perform the functionalitydescribed by the abstract services (Clause 9.1) so is a MMS communication stack with allnecessary layers included needed.There are several ways to implement a MMS communication stack. One way is to buy animplementation of it from another company, but this is expensive and not suitable for theSTINA IEC 61850 communication prototype since only a small subset of the communicationstack will be needed.The MMS application layer is specified in ASN.1 format. One way to implement layerswritten in ASN.1 is to use an ASN.1 tool [Oss07b]. An ASN.1 tool takes the ASN.1specification and generates data structures (e.g. C/C++ structures) and code for serializing/deserializingthe data structures. This could have been a very good way to solve the problem iflarger parts of the MMS application layer should have been used, but since only small parts ofit was needed it felt more instructive not to use a ASN.1 compiler, and instead learn the basicsof ASN.1. It also felt unnecessary to buy a license to an ASN.1 tool since the tool wouldn’t beused too much. Mappings to C++ structures and serializing/de-serializing methods wereinstead written from scratch.Two different types of T-Profiles (OSI Layer 1-4) can be used by the MMS communicationstack, the OSI or TCP/IP T-profile. [4] The TCP/IP T-profile will be used by the prototype,since the ABB REL670 relay uses TCP/IP communication. IEC 61850-8-1 does also state thatat least the TCP/IP profile should be supported.The selected method for creating the communication stack became to implement the differentcommunication layers used by MMS on top of a TCP client. Only the absolutely necessaryparts of the communication stack were implemented, in order to make it small, simple, andcompact. This was done by first identifying the needed services top-down in thecommunication stack, before implementing the communication stack bottom - up. A smalltest application was created to be able to test the functionality of the communication stackseparately from the STINA system.28

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 079.3.2 Useable ToolsA packet capture file with IP traffic between an ABB 670 IED and a MMS client wasreceived from ABB Power Technologies. This file became very useful during implementationof the communication stack, since it gave an example of how the “real bits on the wire” maylook like.A program called Ethereal was used during implementation of the communication stack tocapture the IP traffic between the small test application and the ABB relay, this program madeit a lot easier to do debugging and to find coding flaws. Ethereal is a very useful tool and mustbe recommended for analyzing of protocol implementations.9.4 Creating a STINA IEC 61850 communication prototypeSTINA and the earlier STINA adapters were investigated to find out how they were designedand how the internal communication in the system worked. The new STINA IEC 61850communication prototype is designed as the earlier adapters and reuses functionality providedby already implemented base classes.The prototype was developed in Borland C++ Builder 6.0 since most of STINA is developedwith this tool. The Borland Development Environment is still used at Powel in Östersund.29

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 0710 SolutionA STINA IEC 61850 communication prototype has been developed during this thesis. Theprototype is based on information models provided by IEC 61850-7-2 and protocol mappingsprovided by IEC 61850-8-1.10.1 Abstract ServicesThe information models provided by the Abstract Communication Service Interface (ACSI)define abstract services that should be used for information exchange. The following abstractservices describe functionality used by the Prototype.10.1.1 The Associate ServiceThe Associate Service provided by the TWO-PARTY-APPLICATION-ASSOCIATIONmodel [3] is used by the STINA IEC 61850 communication prototype to establish a two-partyapplication association with a specific IEC 61850 hardware device. Figure 10-1 describes theAssociate Service in a simple way, the real service definition can be found in IEC 61850-7-2,Clause 7.4.2. This abstract service will be used by the prototype to establish a connection.CLIENTRequest succeededAssociate requestAssociate response+SERVERCLIENTRequest failedAssociate requestAssociate response-SERVERFigure 10-1 – ACSI Associate service10.1.2 The Abort ServiceThe Abort Service provided by the TWO-PARTY-APPLICATION-ASSOCIATION model isused to abort a two-party-application association. All service request issued by the client shallbe discarded, and no further service shall be processed. [3] The definition of this service canbe found in IEC 61850-7-2, Clause 7.4.2. Figure 10-2 shows the main functionality of theAbort Service. The association can be aborted by the Server or the Client.CLIENTAbortAbortAbortSERVERFigure 10-2 – ACSI Abort service30

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 0710.1.3 The Release ServiceThe Release Service provide by the TWO-PARTY-APPLICATION-ASSOCIATION model[3] is used by the STINA IEC 61850 prototype to terminate an association between itself andan IEC 61850 server. All service request issued shall be completed before the termination ofthe association. The definition of this service can be found in IEC 61850-7-2, Clause 7.4.2.Figure 10-3 describes the Release service in a simplified way.Request succeededRequest failedCLIENTRelease requestRelease response+SERVERCLIENTRelease requestRelease response-SERVERFigure 10-3 – ACSI Release service10.1.4 The GetServerDirectory ServiceThe GetServerDirectory service provided by the SERVER-model can be used to retrieve a listof all accessible LOGICAL-DEVICES or Files. [3] It is used by the STINA IEC 61850prototype to get the names of accessible files in a specific IEC 61850 device. The definitionof this service can be found in IEC 61850-7-2, Clause 6.2.2. Figure 10-4 describes theGetServerDirectory service in a simplified way.Request succeededRequest failedCLIENTGetServerDirectory reqGetServerDirectory resp+SERVERCLIENTGetServerDirectory reqGetServerDirectory resp-SERVERFigure 10-4 – ACSI GetServerDirectory service31

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 0710.1.5 The GetFile ServiceThe GetFile service should be used by a client to get the contents of a specific file within theserver file store. [3] This service is used by the STINA IEC 61850 prototype to downloadCOMTRADE files. The definition of this service can be found in IEC 61850-7-2, Clause20.2.1. Figure 10-5 describes the GetFile service in a simplified way.CLIENTRequest succeededGetFile reqGetFile resp+SERVERCLIENTRequest failedGetFile reqGetFile resp-SERVERFigure 10-5 – ACSI GetFile service10.1.6 The GetFileAttributeValues ServiceThe GetFileAttributeValues service is used to get the attributes, including the last modifiedtime and size, of a specific file. [3] The attributes is used by the prototype to select if a fileshould be downloaded or not, to avoid downloading the same COMTRADE file severaltimes. It is not enough to check the Filenames, since a new COMTRADE can be generatedwith the same name as an old one. The definition of this service can be found in IEC 61850-7-2, Clause 20.2.4. Figure 10-6 describes the GetFileAttributeValues service in a simplifiedway.Request succeededRequest failedCLIENTGetFileAttributeValues reqGetFileAttributeValues resp+SERVERCLIENTGetFileAttributeValues reqGetFileAttributeValues resp-SERVERFigure 10-6 – ACSI GetFileAttributeValues service32

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 0710.2 Mapping of abstract servicesThe abstract services described in Clause 10.1 only describe the functionality in an abstractway, and they must be implemented by using a specific communication protocol. Thoseservices should according to IEC 61850-8-1 be implemented by using the MMS applicationlayer.The information below describes the mappings specified by IEC 61850-8-1 in a simplifiedway to make them as easy as possible to understand. More information about the mappingscan be found in IEC 61850-8-1. The MMS services identified by doing this mapping will laterbe used by the prototype to communicate with IEC 61850 compliant devices.10.2.1 Mapping of Associate ServiceThe ACSI Associate Service (10.1.1) should be mapped directly to the MMS initiate service[4]. The prototype uses the MMS initiate service to establish a connection with an IEC 61850-compliant device.10.2.2 Mapping of Abort ServiceThe ACSI Abort Service (10.1.2) should be mapped directly to the MMS Abort service. [4]10.2.3 Mapping of Release ServiceThe ACSI Release Service (10.1.3) should be mapped directly to the MMS conclude service.[4] The prototype uses the MMS conclude service to release the connection.10.2.4 Mapping of GetServerDirectory ServiceThe GetServerDirectory (10.1.4) should be implemented by using the MMS FileDirectory asdescribed by Figure 10-7. COMTRADE files should be stored within a directory called“COMTRADE”, and zip files located in that directory shall contain compressedCOMTRADEs. [4] The prototype uses the MMS FileDirectory Service for downloading ofnames of the files contained in the Server. This mapping is only valid when names of filesshould be received, another mapping should be used when object reference to logical devicesare wanted. The prototype will however only handle files.ACSI ClientGetServerDirectory.reqGetServerDirectory.resp+MMS ProviderFileDirectory.reqFileDirectory.conf+Note1Several FileDirectory requestshould be sent untilMoreFollows == false in theFileDirectory confirm.Note2A MMS service conf- responseshould generate aGetServerDirectory resp-.Figure 10-7 – Mapping of GetServerDirectory service to MMS33

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 0710.2.5 Mapping of GetFileThe GetFile service (10.1.5) should be mapped to a sequence of MMS FileOpen, FileReadand FileClose services according to Figure 10-8. [4] The prototype uses this functionality todownload COMTRADE files.ACSI ClientGetFile.reqMMS ProviderFileOpen.reqGetFile.respFileOpen.conf+FileRead.reqFileRead.conf+FileClose.reqFileClose.conf+Note1Several FileRead requestsshould be sent untilMoreFollows == false in theFileRead confirm.Note2A MMS service conf- responseshould generate a GetFile resp-.Figure 10-8 – Mapping of GetFile service to MMS10.2.6 Mapping of GetFileAttributeValuesThe GetServerDirectory (10.1.6) should be implemented by using the MMS FileDirectory asdescribed by Figure 10-9. [4] Note that this mapping uses the same MMS service as themapping for the GetServerDirectory service (10.2.4), it should thereby be possible todownload the filenames of files contained in a server and other attributes at the same time,which the final prototype also does.ACSI ClientGetFileAttributeValues.reqGetFileAttributeValues.resp+MMS ProviderFileDirectory.reqFileDirectory.conf+Note1Several FileDirectory requestshould be sent untilMoreFollows == false in theFileDirectory confirm.Note2A MMS service conf- responseshould generate aGetFileAttributeValues resp-.Figure 10-9 – Mapping of GetFileAttributeValues service to MMS34

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 0710.3 Manufacturing Message SpecificationThe protocol specification of Manufacturing Message Specification is defined in ASN.1notation. Appendix A provides more basic information about ASN.1 and BER encoding. Thissection of the report is instead supposed to give the reader extra information about the MMSservices used by the developed prototype. The ASN.1 notation that appears in this report issometimes simplified to make them more understandable and easier to read. The originalASN.1 notation can be found in ISO 9506-2.10.3.1 Protocol Data UnitsMMS defines fourteen types of protocol data units (PDUs) [5], only 9 of these is used forcommunication between the STINA IEC 61850 prototype and IEC 61850 compliant devices.The different types used by the prototype can be described by the ASN.1 syntax below, whichis a subset of the syntax specified by IEC 9506-2.MMSpdu ::= CHOICE {--SIMPLIFIED NOTATIONconfirmed-RequestPDUconfirmed-ResponsePDUconfimed-ErrorPDUinitiate-RequestPDUinitiate-ResponsePDUinitiate-ErrorPDUconclude-RequestPDUconclude-ResponsePDUconclude-ErrorPDU}[0] IMPLICIT Confirmed-RequestPDU,[1] IMPLICIT Confirmed-ResponsePDU,[2] IMPLICIT Confimed-ErrorPDU,[8] IMPLICIT Initiate-RequestPDU,[9] IMPLICIT Initiate-ResponsePDU,[10] IMPLICIT Initiate-ErrorPDU,[11] IMPLICIT Conclude-RequestPDU,[12] IMPLICIT Conclude-ResponsePDU,[13] IMPLICIT Conclude-ErrorPDUThe initiate PDUs are used by the initiate Service. The confirmed-request, the confirmedresponse,and the confirmed-error PDUs are used by different client/server services, e.g. fileservices. The conclude PDUs are used by the MMS conclude service. Error PDUs are notfully handled by the prototype. If an error is received, then the communication stack detectsan invalid reply and as a consequence of that an exception is thrown.10.3.2 Initiate ServiceAn Initiate-RequestPDU is sent by the client to establish a connection, and a response shouldbe received. An incoming Error-PDU indicates that the initialization failed. [5] The ASN.1notation below describes the structure of the request. Some parts are optional and not used bythe prototype implementation.Abstract syntax: Initiate-RequestPDUInitiate-RequestPDU ::= SEQUENCE {localDetailCalling[0] IMPLICIT Integer32 OPTIONAL,proposedMaxServOutStandingCalling [1] IMPLICIT Integer16,proposedMaxServOutStandingCalled [2] IMPLICIT Integer16,proposedDataStructureNestingLevel [3] IMPLICIT Integer8 OPTIONAL,initRequestDetail [4] IMPLICIT SEQUENCE {proposedVersionNumber [0] IMPLICIT Integer16,proposedParameterCBB [1] IMPLICIT ParameterSupportOptions,servicesSupportedCalling [2] IMPLICIT ServiceSupportOptions,…IF (csr cspi) -- NOT USED BY THE PROTOTYPE IMPLEMENTATION, additionalSupportedCalling [3] IMPLICIT AdditionalSupportOptions35

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 07ENDIFIF (cspi) – NOT USED BY THE PROTOTYPE IMPLEMENTATION, additionalCbbSupportedCalling [4] IMPLICITAdditionalCBBOptions,privilegeClassIdentityCalling [5] IMPLICIT VisibleStringENDIF}}The following values are used by the prototype:localDetailCalling = 8000 (Max MMS PDU size)proposedMaxServOutStandingCalling = 1proposedMaxServOutStandingCalled = 1proposedDataStructureNestingLevel = 5proposedVersionNumber = 1 (Defined by MMS standard)proposedParameterCBB = str1 (ArraySupport) and str2 (StructureSupport)servicesSupportedCalling = 0 -- The client does not provide any services, it only uses service provided bythe IEC 61850 compliant deviceAn Initiate-ResponsePDU should be received after the request has been sent. The responseshould have a format according to the abstract syntax below. The initiate response PDU is notparsed by the implemented Client. A check is performed to see that we received a correctresponse, but the different parameters are not controlled.Abstract syntax: Initiate-ResponsePDUInitiate-ResponsePDU ::= SEQUENCE {localDetailCalled[0] IMPLICIT Integer32 OPTIONAL,negotiatedMaxServOutStandingCalling [1] IMPLICIT Integer16,negotiatedMaxServOutStandingCalled [2] IMPLICIT Integer16,negotiatedDataStructureNestingLevel [3] IMPLICIT Integer8 OPTIONAL,initResponseDetail [4] IMPLICIT SEQUENCE {negotiatedVersionNumber [0] IMPLICIT Integer16,negotiatedParameterCBB [1] IMPLICIT ParameterSupportOptions,servicesSupportedCalled [2] IMPLICIT ServiceSupportOptions,…IF (csr cspi), additionalSupportedCalling [3] IMPLICIT AdditionalSupportOptionsENDIFIF (cspi), additionalCbbSupportedCalled [4] IMPLICITAdditionalCBBOptionsprivilegeClassIdentityCalled [5] IMPLICIT VisibleStringENDIF}}An incoming Initiate-ErrorPDU instead of an incoming Initiate-ResponsePDU indicates thatthe initialization failed.Abstract syntax: Initiate-ErrorPDUInitiate-ErrorPDU ::= ServiceError36

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 0710.3.3 Conclude-ServiceThe Conclude service shall be used to gracefully terminate a connection. Gracefully meansthat the connection is released without any loss of information, all other issued requests mustbe completed before the connection can be terminated.The conclude service PDUs are simple, the Conclude-RequestPDU and the Conclude-Response corresponds to NULL, and the Conclude-ErrorPDU corresponds to a ServiceError.Abstract syntax: ConcludeConclude-RequestPDU ::= NULLConclude-ResponsePDU ::= NULLConclude-ErrorPDU ::= ServiceError10.3.4 AbortAbort service should be directly mapped to the M-U-ABORT service provided by ACSE(ISO 8649/8650) [5]. The Abort service is not actually used by the prototype, and willtherefore not be explained. Abortion of the association was instead implemented by closingthe TCP/IP connection directly, which works like a hard but yet effective abort.10.3.5 File servicesFile services uses the Confirmed-RequestPDU, the Confirmed-ResponsePDU, and theConfirmed-ErrorPDU. A Confirmed-RequestPDU is sent by the client to request a service,and a Confirmed-ResponsePDU should be received.Abstract syntax: Confirmed-RequestPDUConfirmed-RequestPDU ::= SEQUENCE{invokeID Unsigned32service ConfirmedServiceRequest,}The service parameter of type ConfirmedServiceRequest shall correspond to specific servicerequest, e.g. a FileDirectory-Request. [5]Abstract syntax: Confirmed-ResponsePDUConfirmed-ResponsePDU ::= SEQUENCE {invokeID Unsigned32service ConfirmedServiceResponse,}The service parameter of type ConfirmedServiceResponse shall correspond to a specificservice response, a FileDirectory-Response if a FileDirectory-Request was sent. An incomingConfirmed-ErrorPDU indicates that the request failed. [5]Abstract syntax: Confirmed-ErrorPDUConfirmed-ErrorPDU ::= SEQUENCE {invokeID [0] IMPLICIT Unsigned32serviceError [2] IMPLICIT ServiceError,}The serviceError parameter contains a specific ServiceError.37

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 07All confirmed service PDUs contains an invokeID. The invoke id is used to relate a responsewith a specific request. The invoke id of the RequestPDU should be the same as the invoke idof the ResponsePDU or ErrorPDU. [5] Confirmed-Error PDUs are not fully handled by theprototype; an incoming ErrorPDU will result in the generation of an exception. The exceptionis handled by the prototype by closing down the communication.There are a lot of different MMS confirmed services that can be used, but only four are usedby the STINA IEC 61850 communication prototype. These are: FileOpen, FileRead,FileClose, and FileDirectory.Abstract syntax: ConfirmedServiceRequestConfirmedServiceRequest ::= CHOICE {--Selection of servicesfileOpen [72] IMPLICIT FileOpen-RequestfileRead [73] IMPLICIT FileRead-RequestfileClose [74] IMPLICIT FileClose-RequestfileDirectory [77] IMPLICIT FileDirectory-Request}Abstract syntax: ConfirmedServiceResponseConfirmedServiceResponse ::= CHOICE {--Selection of servicesfileOpen [72] IMPLICIT FileOpen-ResponsefileRead [73] IMPLICIT FileRead-ResponsefileClose [74] IMPLICIT FileClose-ResponsefileDirectory [77] IMPLICIT FileDirectory-Response}10.3.6 FileOpenA FileOpen-Request is sent by the client to open a file in the server file store and make itavailable for file transfer. The request takes two parameters, the filename and the initialposition. The initial position should be set to zero to download the complete file. [5]A FileOpen-Response should be received. The response contains two parameters, the frsmIdand file attributes. The attributes consist of the file size and last modified time of the file. ThefrsmId (file resource manager id) shall be used by the FileRead service. [5]Abstract syntax: FileOpenFileAttributes ::= SEQUENCE {sizeOfFile [0] IMPLICIT Unsigned 32,lastModified [1] IMPLICIT GeneralizedTime OPTIONAL }FileName ::= SEQUENCE OF GraphicStringFileOpen-Request ::= SEQUENCE {fileName[0] IMPLICIT FileName,initialPosition [1] IMPLICIT Unsigned32 }FileOpen-Response ::= SEQUENCE {frsmID[0] IMPLICIT Integer32,fileAttributes [1] IMPLICIT FileAttributes }38

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 0710.3.7 FileReadWhen the file has been opened then it is available for transfer. The Client should send aFileRead-Request equals to the frsmId from the FileOpen-Response to retrieve the contentsof the file. The Server should response with a FileRead-Response containing fileData andthe moreFollows parameter. If moreFollows = true, then one more FileRead-Request shouldbe sent by the client until the moreFollows = false in the new Response. [5]Abstract syntax: FileReadFileRead-Request ::= Integer32 -- FRSM IDFileRead-Response ::= SEQUENCE {fileDatamoreFollows[0] IMPLICIT OCTET STRING,[1] IMPLICIT BOOLEAN DEFAULT TRUE}10.3.8 FileCloseAfter the contents of the file have been received, then the client should close the file in theserver file store by using the FileClose service. A FileClose-Request should be sent by theClient, and a FileClose-Response should be received. [5]Abstract syntax: FileCloseFileClose-Request ::= Integer32 – FRSM IDFileClose-Response ::= NULL10.3.9 FileDirectoryThe FileDirectory service should be used to retrieve a list of names and other attributes ofavailable files within a MMS server file store. A FileDirectory-Request should be sent, and aFileDirectory-Response should be received. [5]Abstract syntax: FileDirectory-RequestFileDirectory-Request ::= SEQUENCE {fileSpecification[0] IMPLICIT FileName OPTIONAL,continueAfter [1] IMPLICIT FileNAme OPTIONAL }The parameter fileSpecifiaction is optional. When it is present then it shall identify a file or agroup of file in the server file store whose attributes are desired. If it isn’t present, thenattributes of a default group of files are requested.The continueAfter parameter is optional. When it is present, then it shall identify a startingpoint within an ordered list of the complete group of files selected by the fileSpecificationparameter. Only attributes of the proceeding files are included in the result. [5]Abstract syntax: FileDirectory-ResponseFileDirectory-Response ::= SEQUENCE {listOfDirectoryEntry [0] SEQUENCE OF DirectoryEntrymoreFollows [1] IMPLICIT BOOLEN DEFAULT FALSE }The listOfDirectoryEntry parameter shall contain a list with directory entries.39

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 07If moreFollows = true, then one more FileDirectory-Request should be sent untilmoreFollows = false in the response. [5]A directory entry consists of the filename and other file attributes, like size and last modifiedtime, according to the syntax below.Abstract syntax: Directory-EntryDirectoryEntry ::= SEQUENCE {fileNamefileAttributes}[0] IMPLICIT FileName,[1] IMPLICIT FileAttributesFileAttributes ::= SEQUENCE {sizeOfFile [0] IMPLICIT Unsigned 32,lastModified [1] IMPLICIT GeneralizedTime OPTIONAL }10.4 BER Encoding/DecodingManufacturing message specification is defined in ASN.1 syntax. The prototype uses simplemethods for BER encoding and decoding. The example below describes how messages areencoded and decoded when using Basic Encoding Rules. (ISO 8825-1, X.690)Example:The abstract service GetFile shall be mapped to a sequence of MMS FileOpen, FileRead andFileClose. This example will show how the FileOpen-Request is encoded, and how anincoming FileOpen-Response is decoded. More information about ASN.1 and BER encodingcan be found in appendix A, which shall be used as a extra help to understand how ASN.1types is built up, and how they are encoded/decoded.The client sends a FileOpen-Request message to start downloading a specific file. We assumethat the filename of the wanted file is “/flash/drec/drec_31.zip” (corresponds to one of thefiles available in the test equipment) and that the complete file should be downloaded.(initialPosition == 0) Lets also assume that the invoke id = 0.The FileOpen request can be described as below. This is a simplification of the ASN.1 syntaxdefined in 10.3.5 and 10.3.6.confirmedRequest [0] IMPLICIT SEQUENCE{invokeID Unsigned32fileOpen-Request [72] IMPLICIT SEQUENCE{fileName[0] IMPLICIT Sequence of graphic string,initialPosition [1] IMPLICIT Unsigned32}}40

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 07Decoding of the FileOpen-Response:[1] IMPLICIT SEQUENCE (Confirmed-ResponsePDU)T L V0xA1 0x23 Unsigned32 (InvokeID)T L V0x02 0x01 0x00[72] IMPLICIT SEQUENCE (FileOpen-Response)T L V0xBF, 0x48 0x1D [0] IMPLICIT Integer32 (frsmId = 125954832)(0xBF => tag > 30) T L V0x80 0x04 0x07, 0x81, 0xEB, 0x10[1] IMPLICIT SEQUENCE (FileAttributes)T L V0x81 0x15 [0] IMPLICIT Unsigned 32 (size = 5243)T L V0x80 0x02 0x14, 0x7b[1] IMPLICIT GeneralizedTimeT L V0x81 0x0F 0x32, 0x30, 0x30, 0x36,0x31, 0x31, 0x31 0x30,0x31, 0x33, 0x32, 0x39,0x32, 0x30, 0x5A(lastModified = 20061110 132920Z)There are three types of encodings for GeneralizedTime, the ’Z’ means that the timecorresponds to GMT (Greenwich Mean Time).The decoding can be described by the following ASN.1 notation:FileOpenResponse [1] IMPLICIT SEQUENCE{invokeID Unsigned32 -- (invokeID = 0),fileOpen-Response [72] IMPLICIT SEQUENCE{}frsmId [0] IMPLICIT Integer32 -- (frsmId = 125954832),fileAttributes [1] IMPLICIT FileAttributes}FileAttributes ::= SEQUENCE {sizeOfFile [0] IMPLICIT Unsigned 32 -- (size = 5243)lastModified[1] IMPLICIT GeneralizedTime--(lastModified = 20061110 132920Z)}Result: InvokeId = 0, frsmID = 125954832, sizeOfFile = 5243,lastModified = 2006-11-10 13:29:20 (GMT)Note: The frsmId shall later be used to retrieve the contents of the opened file.42

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 0710.5 Mappings between C++ and ASN.1The implemented communication stack uses a simple method for mapping of ASN.1 syntax toc++. Here is an example of how the ASN.1 syntax for FileOpen-Request can be described inC++.A FileOpen-Request is transferred in a CConfirmedRequestPDU (See 10.3.5). TheConfirmedRequestPDU can be implemented in C++ as:class CConfirmedRequestPDU{public://methods for setting of attributesvoid SetService(CConfirmedServiceRequest * ccsrService);void SetInvokeID(unsigned int invokeid);//methods for encoding/decodingvirtual void GetFrame(byte ** buf, int &len);virtual void SetFrame(byte * buf, int len);private:unsigned int invokeID;CConfirmedServiceRequest * service;};The FileOpen-Request is only one of several existing service requests. All service requestshave the same syntax, which can be implemented by a pure virtual base class.class CConfirmedServiceRequest{public://Encodingvirtual void GetFrame(byte ** buf, int &len)=0;//Decodingvoid SetFrame(byte * buf, int len){//No need for decoding of request, they will only be sent from the client.}};The ASN.1 notation for FileOpen-Request (10.3.6) can be implemented by a realization of thepure virtual base class CConfirmedServiceRequest.class CFileOpenRequest : public CConfirmedServiceRequest{public:void SetFileName(char * filename, unsigned int length);void SetInitialPosition(unsigned int initPos);void GetFrame(byte ** buf, int &len);private:char * fileName;unsigned int initialPosition;};The serialization of the classes is implemented in the GetFrame method, and the deserializationis implemented in the SetFrame method. There is however no need for deserializationof requests, since they will only be sent by the client. In the same way is there noneed for serialization of response messages, since they will only be received by the prototype.The SetFrame and GetFrame methods use the rules defined by BER.43

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 07My own reflections regarding ASN.1 and BERThe ASN.1 notation can be mapped to C++ in several different ways. The serialized bytestreammust however always correspond to the serialization of the ASN.1 notation, since it isalways in the end the “bytes on the wire” that matters. But it is also good to have a mappingthat looks like the object oriented ASN.1 syntax, since it makes it easier to do a correctencoding/decoding.10.6 Communication StackTo be able to implement the MMS services identified by doing the abstract service mapping(section 8.2), a small subset of the communication stack specified by the IEC 61850-8-1standard is needed. The goal became to develop a simple and compact but yet functionalcommunication stack, which makes it possible for the STINA IEC 61850 prototype todownload disturbance information (COMTRADE files) from IEC 61850 compliant devices.The following MMS services were identified by doing the service mapping:• Initiate• (Abort)• Conclude• FileDirectory• FileOpen• FileRead• FileCloseA communication stack that supported those services had to be implemented in order toprovide the prototype the desired functionality. The Abort service became however laterunnecessary for the prototype, and is because of that not supported by the finalcommunication stack. The communication between the Client and the Server can instead beaborted by closing the transport connection directly. If the server sends an Abort message tothe client, the client will recognize an unsupported message and as a consequence of that thetransport layer will be disconnected.44

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 0710.6.1 Communication stack specified by IEC 61850-8-1The IEC 61850-8-1 standard specifies that a communication stack according to Table 10-1should be used for Client/Server services based on MMS on top of TCP/IP. A small subset ofthis communication stack was implemented and used for downloading disturbanceinformation to STINA.OSI modellayerApplicationPresentationSessionSpecificationNameManufacturingMessageSpecificationAssociation ControlService ElementConnectionOrientedPresentationServiceSpecificationProtocolSpecificationISO 9506-1:2003 ISO 9506-2:2003 mISO/IEC 8649:1996 ISO/IEC 8650:1996 mISO/IEC 8822:1994 ISO/IEC 8823-1:1994Abstract Syntax ISO/IEC 8824-1:1999Connection ISO/IEC 8326:1996Oriented Session (X.225)ISO/IEC 8825-1ISO/IEC 8327-1:1997 (X.225)m/ommMTransportISO transport on RFC 1006 (RFC 905)mtop of TCPInternet ControlMessage ProtocolRFC 792mTransport Control RFC 793mProtocolNetwork Internet Protocol RFC 791 mAn Ethernet RFC 826mAddress Resolutionprotocol (ARP)DataLinkPhysical(option 1)Physical(option 2)Standard for thetransmission of IPdatagrams overEthernet networksCarrier SenseMultiple Accesswith collisiondetection(CSMA/CD)10Base-T/100Base-TInterface connectorand contactassignments forISDN Basic AccessInterfaceFiber Opticaltransmission system100Base-FXBasic Optical FiberConnectorTable 10-1 – MMS based on TCP/IP T-profileRFC 894ISO/IEC 8802-3:2001ISO/IEC 8802-3:2001ISO/IEC 8877:1992ISO/IEC 8802-3:2001IEC 60874-10-1, IEC 60874-10-2 and IEC60874-10-3mmm (Option 1 or 2)m (Option 1 or 2)45

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 0710.6.2 Reduced communication stackA reduced version of the MMS communication stack specified by Table 10-1 was needed toprovide the STINA IEC 61850 communication prototype the desired functionality. Theimplemented communication stack use the same framing as the communication stackspecified by IEC 61850-8-1, but the internal architecture is a bit different.Figure 10-10 – Reduced communicationstack designOverall DesignFigure 10-10 shows the structure ofthe implemented communicationstack, where theIEC61850ClientFileServices classacts like the application layer, andthe TIDTCPClient class provided byBorland implements the most of thefunctionality in the transport layer.The implemented communicationstack provides the followingmethods to its user:• SetIP• GetFile• GetDirectory (Only filenames)• Initiate• ConcludeThe architecture of thecommunication stack is layered, butthe different layers should not beseen as independent layers, as theyonly implement the functionalityneeded by the layer above. Theimplemented communication stackcan thereby be seen as an STINAIEC 61850 specific communicationstack.46

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 07Transport LayerMost of the Transport Layer was implemented by using the TCP/IP client (TIdTCPClient)provided by the Borland C++ Builder Environment, only the part “ISO transport on top ofTCP/IP” had to be implemented. The implementation does not follow RFC1006 (see Table10-1) strictly, it is instead only implemented to look like the protocol described by RFC1006.Packet FormatThe protocol described by RFC1006 [7] defines a simple packet format. Each packet, termedTPKT, has a format according to Table 10-2.TPKTPacket HeaderTPDUByte 0 Byte 1 Byte 2 & Byte 3 Byte 4 –Vrsn reserved packet length dataTable 10-2 – Transport packet formatvrsn – This field is always 0x03 for the version of the protocol described by RFC 1006.[7]reserved – This field is reserved; value 0x00 could be usedpacket length – This field contains the length (in bytes) of the entire TPKT. [7]RFC905 describes the services provided by the transport layer (ISO 8073) and the usedtransport protocol data units (TPDUs). Five different transport protocols are described byRFC905, RFC1006 specifies that transport protocol class 0 (TP0) should be used. TP0performs segmentation and reassembling of data.The implemented class called CTPKT provides methods for initializing a TCP/IP connection,for sending TPDUs (Transport Protocol Data Units), for receiving TPDUs, and for closing theinitialized connection. The cTCPClient class is an extension of the TCP client provided byBorland, it implements a new read method with timeout control. The transport layer isimplemented by the CCOTP class and provides the following methods.SetIpThe SetIP method, described by Figure 10-11,sets the IP number used by the TCP client. Thismethod is used instead of transferring the IPaddress as a parameter in the ConnectionRequestmethod.void SetIp(AnsiString asIP)The asIP parameter shall contain the IP number.Figure 10-11– Transport Layer - SetIP47

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 07Figure 10-12 – Transport Layer -ConnectionRequestConnectionRequestThe ConnectionRequest method described byFigure 10-12 should be used to initiate a transportconnection. The method sends a CR TPDU andexpects a CC TPDU. More information aboutconnection establishment can be found in RFC905.int ConnectionRequest(unsigned shortsource_ref);The source_ref parameter is used to identify thesource of the request. The function returns 1 onsuccess, and generates exception on error.SendDataThe SendData method described by Figure 10-13should be used by the session layer to send userdata. The data is packed into a DT TPDU asdefined by RFC905. Segmentation (fragmenting)of data is not implemented since only small datablocks will be sent by the STINA IEC 61850prototype.Figure 10-13 – Transport Layer - SendDatavoid SendData(byte * buffer, int len);The buffer parameter shall contain the data to besent.The len parameter shall specify the length of thedata.ReceiveDataThe ReceiveData method described by Figure10-14 shall be used by the session layer to receiveuser data. Data is unpacked from DT TPDUs asdefined by RFC 905. Reassembling of data isimplemented to make it possible to reassemblesegmented data sent from the server.Figure 10-14 – Transport Layer - ReceiveDatavoid ReceiveData(byte ** buffer, int &len);The buffer parameter contains the received data.The len parameter specifies the length of thereceived data.48

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 07DisconnectThe Disconnect method should be used by thesession layer to disconnect the transportconnection. The implicit disconnect methoddefined by RFC905 is used. The transport layer isdisconnected by closing the TCP/IP connectiondirectly.void Disconnect();Figure 10-15 – Transport Layer -DisconnectSession LayerThe Session Layer is implemented by using the methods provided by the implementation ofthe transport layer (the CCOTP class). The implementation of the session layer (ISO 8327) isbased on ITU-T recommendation X.225 and provides four methods to the layer above. Themethods are implemented sequentially, they sends a request and waits for a response. Theimplementation provides functionality for session management and data transfer. Moreinformation about the session layer (ISO 8327) can be found at [Jav07b].SetIPThe SetIP method should be used to set the IPnumberused by the transport layer. Thismethod is used instead of transferring the IPnumberas a parameter in the Connect method.Figure 10-16 – Session Layer - SetIPConnectThe Connect method should be used toestablish a Session connection, it works as theS-CONNECT service defined by ITU-Trecommendation X.225.The ConnectionRequest method provided bythe implementation of the transport layer isfirst used to establish a transport connection.The second step is to use the SendData methodprovided by the transport layer to send a CNSession Protocol Data Unit (SPDU)Figure 10-17 – Session Layer - ConnectAn AC SPDU should later be received if therequest succeeded. [ITU88]49

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 07DataTransferThe DataTransfer method should be used totransfer session user data between a client anda server, and it used the same framing asnormal data transfer (the S-DATA service)defined by X.225. The outgoing data is packedinto DT SPDUs, and incoming data isunpacked from DT SPDUs. Theimplementation uses methods provided by thetransport layer according to Figure 10-18.Figure 10-18 – Session Layer - DataTransferFinishThe Finish method should be used to terminatethe connection. This method uses the sameframing as the S-RELEASE service defined byX.255. A FINISH SPDU is sent, and aDISCONNECT SPDU should be received[ITU88]. The implementation uses methodsprovided by the transport layer according toFigure 10-19.Figure 10-19 – Session Layer - Finish50

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 07Presentation LayerThe presentation layer ISO 8823 has two responsibilities, negotiation of transfer syntaxes andtransformation to and from transfer syntax. [Jav07c] IEC 61850-8-1 specifies that the BERtransfer syntax should be used, and only BER is supported by the implementation. Theimplementation of the presentation layer encodes/decodes messages and adds thecorresponding framing for MMS and ACSE (Association Control Service Element)application layers.SetIPThe SetIP method is used to specify the IPnumber of a specific server. This method isused instead of transferring the IP-numberas a parameter in the Connect method.Figure 10-20 – Presentation Layer - SetIPConnectThe Connect method should be used toestablish an association. It uses the sameframing as the P-CONNECT servicedefined by ISO 8822/8823-1. Theimplementation uses methods provided bythe session layer according to Figure10-21.Figure 10-21 – Presentation Layer - ConnectDataRequestResponseThe DataRequestResponse method shouldbe used to transfer user data. It uses thesame framing as the P-DATA servicedefined by ISO 8822/8823-1. A request issent and a response should be received byusing the DataTransfer method provided bythe session layer according to Figure 10-22.The BER transfer syntax is used.Figure 10-22 – Presentation Layer -DataRequestResponse51

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 07Figure 10-23 – Presentation Layer - ReleaseReleaseThe Release method should be used by theapplication layer to release an association.It uses the same framing as the P-RELEASE service defined by ISO8822/8823-1. The implementation uses theFinish method provided by the sessionlayer as shown by Figure 10-23. The P-RELEASE service is used by the ACSE A-RELEASE service.Application LayerThe application layer, implemented by the IEC61850ClientFileServices class, is a mixture ofseveral protocols, it implements MMS (ISO 9506) services, ACSE functionality, and providesits user with only a few methods which are simple to use. This class does also implement themappings between abstract services defined by IEC 61850-7-2 and MMS as defined by IEC61850-8-1. The ACSE protocol is defined by ISO 8650 and provides functionality forestablishing and releasing application associations [Jav07d]. MMS uses TCP/IP port 102[Kir07], which has been “hard coded” in the transport layer.Figure 10-24 – Application Layer - SetIPSetIPThe SetIP method should be use tospecify the IP-number of the server(physical equipment) with which theapplication should communicate. Thismethod is used instead of transferringthe IP-number as a parameter in theInitiate method. The implementationuses the SetIP method provided by thepresentation layer as shown by Figure10-24.InitiateThe Initiate method should be used toinitiate an association with a MMSserver. It implements the MMS Initiateservice (10.3.2), and adds also theframing used by the ACSE A-ASSOCIATE service. The Initiatemethod uses functionality provided bythe presentation layer as shown byFigure 10-25.Figure 10-25 – Application Layer - Initiate52

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 07Figure 10-26 – Application Layer - GetFileGetFileThe GetFile method should be used toget the contents of a specific file. Themethod takes the FileName as aparameter, and returns the contents ofthe file.The MMS FileOpen service (10.3.6) isused to open the file in the server filestore, the MMS FileRead service(10.3.7) is used to get the contents of thefile, and the FileClose service (10.3.8) isused to close the file. At last the contentsof the specific file are retuned. Theimplementation uses methods providedby the presentation layer as shown byFigure 10-26.GetDirectoryThe GetDirectory method should beused to get a list with names of availablefiles. Attributes like file-size and lastmodified time are also returned.Figure 10-27 – Application Layer - GetDirectoryThe MMS FileDirectory service (10.3.9)is implemented by this method and theimplementation uses functionalityprovided by the presentation layer asshown by Figure 10-27.ConcludeThe Conclude method should be use toterminate an association with a server.This method implements the MMSConclude service (10.3.3). A MMSConclude request is sent, and a responseshould be received. After the responsehas been received, then the ACSE A-RELEASE service is used for finaltermination of the connection. Theimplementation uses services providedby the presentation layer as shown byFigure 10-28.Figure 10-28 – Application Layer - Conclude53

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 07AbortThe MMS abort service has, as earlier stated, not been implemented. The communicationbetween STINA IEC 61850 prototype and IEC 61850 compliant devices can instead beaborted by disconnecting the transport connection directly.The reason why it wasn’t implemented• The Abort service is not needed to be able to download files or filenames.• When something goes wrong in the communication, an exception is thrown from thelayer were the error appeared. The exception is handled by disconnecting the transportconnection. (The Implicit release variant specified by RFC 905 is used)• The implicit release variant specifies that the lifetime of a transport connection relatesto the lifetime of the network connection. When the socket connection is being closed,then the transport layer on the other side will be notified. [6]• Closing the transport connection works like a hard, but very simple Abort service.This method is possible since the implemented transport layer will only be used byone application, the STINA IEC61850 prototype.54

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 0710.7 STINA IEC 61850 communication prototypeThe developed STINA IEC 61850 communication prototype will be presented in this part ofthe thesis report. The prototype should however not be considered as a general solution, butinstead as an example of how IEC 61850 can be used for remote disturbance analysis. TheABB REL670 line protection relay provided only compressed COMTRADE files (zip-files).The prototype was designed to be as simple as possible and provides consequently onlysupport for downloading of compressed COMTRADE files. The communication stack canhowever be used to download any kind of file, and only a small modification will be neededto make the prototype to work with uncompressed COMTRADE files.The new STINA IEC 61850 communication prototype is like all earlier STINAcommunication solutions divided into two parts: a communication (COMM) adapter and adata process (PROC) adapter.10.7.1 STINA IEC 61850 - Communication adapterFigure 10-29 – STINA IEC 61850communication adapter designAll STINA communication adaptersshould implement a COM interface calledUnitInterface. Figure 10.29 shows thedesign of the communication adapter.The base class called CCommBase isused by almost all STINAcommunication adapters and provides alot of useful functionality, e.g. methodsfor internal communication in STINA,reading of database parameters etc.The STINA IEC 61850 communicationadapter uses the implementedcommunication stack to downloadcompressed COMTRADE files.IUnitInterface specificationIUnitInterface contains the followingmethods:• Init• GetData• CleanUp• SetUnitLocalTime• GetUnitLocalTime55

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 07InitThe purpose of the Init method is to initiate thecommunication adapter with useful information. Figure10-30 shows the basic functionality of this method.The following database parameters are read fromSTINA’s database by using the GetParam functionprovided by the CCommBase base class:IPNR: The adapter is initiated with an IP-number to anIEC 61850 compliant physical device.Figure 10-30 – Communication adapter-InitFILEFILTER: The adapter is initiated with a filefilter, which makes it possible to select the format ofthe wanted COMTRADE files. IEC 61850-8-1specifies that the COMTRADE files should be locatedin a specific directory called “COMTRADE”, this partof IEC 61850-8-1 was apparently not followed byABB, since the COMTRADE files were located in thedefault directory which was “/flash/drec/”. TheFileFilter database parameter makes it possible tospecify the format of the compressed COMTRADEfiles, so that only compressed COMTRADE files willbe downloaded and no other zip-files. This method wasused since ABB didn’t follow the standard exactly.NROFDAYS: This parameter makes it possible to filter out too old disturbance information.56

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 07GetDataThe GetData method described by Figure 10-31 is used by CommSrv to downloadcompressed COMTRADE files from IEC 61850 compliant relays according to IEC 61850-8-1. The IP-number is set to the number retrieved from the IPNR database parameter.Get DisturbancesThe CIEC61850DEVICE class (see Figure 10-31) uses the Initiate service provided by thecommunication stack to initiate an association with a specific Server. When an association hasbeen established, then the GetDirectory service (see Figure 10-31) is used to retrieve a list ofavailable files, file attributes like size and last modified time is also retrieved.Only files according to the parameter FileFilter will later be downloaded. If the FileFilterparameter is empty, then this filter is inactivated, and all available zip-files are valid.The NROFDAYS database parameter is used filter out too old files. This formula is used tocalculate if a file can be downloaded or not:57Figure 10-31 – Communication adapter - GetDataLastModifiedDate > Current Time – NROFDAYSIf the two first criteria are fulfilled, then the file is downloaded by the STINA IEC 61850communication adapter if the current file has not been downloaded by STINA before. To beable to know if a file has been downloaded before so is a string named “chunk” generated bythe adapter. The chunk is a concatenation of the filename and the last modified time of thefile. The adapter looks up the chunk in the database to see if the current file has beendownloaded (the chunk is inserted by the process adapter). If the chunk is not found, then thefile can be downloaded by the adapter. This check is made to avoid downloading unnecessaryinformation, and is used by almost all STINA communication adapters. When all files thatfulfilled the different requirements have been downloaded, then the connection to the Serveris disconnected.

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 07Save DisturbancesFor every downloaded disturbance file, the STINA IEC 61850 communication adaptergenerates two temporary files in a folder specified by STINA (as parameter in the GetDatamethod)The files have the same names, only the type differs.• “NewFilename.dat” contains the original filename, the fetch time, and the lastmodified date of the downloaded file. This information is needed when we shouldgenerate the chunk.• “NewFilename.zip” contains the downloaded information (a set of compressedCOMTRADE files, at least a *.dat and a *.cfg file)The filename is generated by using the current date and time, to make sure that the newfilename will be unique in the folder used by STINA. All names of the *.dat files are added toa list, which is later returned to the user (CommSrv) of the adapter via a pointer in theGetData method interface.CleanUpThe CleanUp method shown by Figure 10-32 isused by CommSrv to clean up resources allocatedby the COMM adapter.Figure 10-32 – Communication adapter -CleanUpSetUnitLocalTime and GetUnitLocalTimeThese two methods are not supported by the STINA IEC 61850 communication prototype,and the implementation of them does not perform anything useful.58

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 0710.7.2 STINA IEC 61850 - Process adapterThe process (PROC) adapter processes and normalizes the data downloaded by thecommunication adapter. All STINA Proc adapters implement the COM interface calledProcInterface. The base class CProcBase which is used by most STINA process adaptersmakes implementation a lot easier. This base class provides for example functionality forDatabase access, inserting chunks, inserting disturbance information (e.g. COMTRADEs) etc.Figure 10-33 shows the design of the STINA IEC61850 process adapter.IProcnterface Specification• Init• ProcessData• CleanUpFigure 10-33 – STINA IEC 61850 process adapter designInitThe Init method, described by Figure 10-34, should be used by the ProvSrv to initiate theadapter. A parameter called EXTRACT is read from the database.Figure 10-34 – Process adapter - Init59

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 07ProcessDataThe STINA IEC 61850 communication adapter generates a file list with the names of thegenerated *.dat files. This file list is sent to the Proc adapter via a parameter in theProcessData function. The process adapter knows that for every *.dat file there is also a *.zipfile with the same name. Every *.dat file is processed by using the same method. Figure 10-35shows the functionality of the ProcessData method.Process data fileThe PROC adapter generates a string, normally called chunk, by using the informationprovided by the *.dat file. The chunk is generated by concatenating the last modified timewith the original filename. (In the same way as in the COMM adapter)The processDataFile method decompresses the zip file to a unique folder. (Folder name isgenerated by the name of the .dat file) During the decompressing the zip-file, the Unzip filemethod searches after a CFG file. A COMTRADE consists of at least a CFG file, and a DATfile, and some times could also a HDR and an INF file be included. All files should have thesame names, only the file types should differ.Figure 10-35 – Process adapter - ProcessDataThe unpacked COMTRADE file is processed bythe processComtradeFile method. TheprocessComtradeFile method takes twoparameters, the name of the CFG file, and thegenerated chunk. It first checks first that thecurrent file hasn’t been added to the databasebefore. If the current file has been processed, thenit continues with the next *.dat file. This check isperformed by using the generated chunk. If ithasn’t been processed, then the COMTRADE fileis processed and added to STINA by using theAddSS (SS = StörningsSkrivare) method providedby CProcBase. Only the name of theCOMTRADE CFG file is added to the database,the real files are copied to a folder specified bySTINA. If the EXTRACT parameter of typeBoolean read from the database was true, thenevents are extracted from the COMTRADE file.An event occurs when a digital channel ischanging its state, going from zero to one, or fromone to zero. Events are inserted by using theAddHS method (HS = Händelse Skrivare)provided by CProcBase. After the currentCOMTRADE has been processed and added to thedatabase correctly, then the chunk is added to thedatabase. All these steps is done for every *.datfile until every file has been processed.60

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 07CleanUpThe CleanUp method described by Figure 10-36 should be used to release allocated resources.Figure 10-36 – Process adapter - CleanUp61

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 0711 Testing of the prototype’s functionalityThis thesis has resulted in a prototype for communication between the disturbance analysisand disturbance collecting system named STINA and IEC 61850 compliant devices. Theprototype implements functionality needed for downloading of COMTRADE files to STINAdirectly from IEC 61850 compliant devices and makes them accessible to the rest of thesystem. The prototype, which has only been tested with an ABB REL670 line protectionrelay, shall be used to download zipped COMTRADE files. Only a small modification shouldbe needed to make it work with regular COMTRADE files.The functionality of the prototype was verified in the end of the project by installing thedeveloped software into a STINA system at Powel’s office in Östersund. The STINAadministrator tool was used to configure STINA for communication with the borrowed ABBREL670 relay. Downloading of information from the device was initialized by using thefunctionality for manual downloading of data provided by the STINA Navigator. SeveralCOMTRADE files were in this way downloaded from the ABB REL670 relay. Figure 11-1shows the STINA Navigator and the selected row corresponds to one of the downloadedCOMTRADE files.Figure 11-1 – STINA Navigator showing downloaded disturbance informationThe COMTRADE can be opened in the STINA COMTRADE Viewer by double clicking it inthe STINA Navigator.Figure 11-2 – Selection of COMTRADE in STINA NavigatorThe HS fields, e.g. TRIP ON (see Figure 11-2), show events which have been extracted fromthe COMTRADE (see 10.7.2). The time shown in the selected row (Figure 11-2) correspondsto the time when the disturbance was recorded. Figure 11-3 shows how the selecteddisturbance recording looks like in the STINA COMTRADE-Viewer. The COMTRADE fileshows a recording of sample values, from both analog and digital channels, around the time ofa disturbance.62

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 07The information provided by COMTRADE files are useful in analyzing of disturbances onpower networks and the prototype thereby fulfills the minimum requirement which was toprovide STINA with information from IEC 61850 compliant devices useable for disturbanceanalysisFigure 11-3 – Investigation of a COMTRADE in STINA COMTRADE-Viewer63

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 0712 ConclusionThe new global standard IEC 61850 standard for substation automation is probably here tostay, since it covers all aspects of substation automation and is future-proof. But one of theproblems with all standards is that they also must be supported by the manufacturers, in thisthesis was it found out that one part of IEC 61850-8-1 regarding COMTRADE files wasn’tfollowed by ABB, the COMTRADE files were not located in a standardized directory. Thisbecame no problem, however, since the COMTRADE files were located in the defaultdirectory (”/flash/drec/”). But it can be a problem if several vendors start to put theirCOMTRADE files in un-standardized directories, since it will make it more difficult to findthe correct files.The developed STINA IEC 61850 communication prototype downloads compressedCOMTRADE files from IEC 61850 compliant devices. A lot of protocol specification had tobe read in order to develop the prototype, and several standards had to be bought. Thisbecame however much cheaper than to buy an implementation of an IEC 61850communication stack. But it is also understandable that the available IEC 61850 solutions isexpensive, since a lot of work is needed to implement the IEC 61850 standard. Only a smallpart of it was implemented in this thesis, but it was still hard enough. It became also a bit hardto describe the work in an understandable way, since it spanned over several subjects, e.g.disturbance analysis, substation automation, MMS, and integration to STINA.The developed solution is only a prototype, and a more extensive STINA IEC 61850communication solution can probably be developed. Only COMTRADE files are handled bythe current solution, additional functionality for reading information contained in logicalnodes could also be useful.The solution must however be seen as successful since it is able to provide STINA withinformation suitable for disturbance analysis. STINA can now be used for both downloadingof disturbance information from devices based on older communication protocols (e.g.Modbus and IEC 60870-5-103), and for downloading of disturbance information from newerdevices supporting IEC 61850, which makes the tool even better than before. The prototype ishowever not a complete product, and small modifications will be needed to make it work withuncompressed COMTRADE files. The modification will mainly consist of removing thedecompressing of files in the PROC adapter.64

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 0713 GlossaryACSE:ACSI:Adapter:APDU:ASDU:ASN.1:BER:COM:COMM adapter:CommSrv:COMTRADE:DCOM:DLL:IEC:IED:IP:ISO:ITU:ITU-T:KernelSrv:LAN:LD:LN:MMS:OSI Model:PPDU:PROC adapter:ProcSrv:RFC:RTU:SCL:SCSM:SPDU:STINA:TCP:TPDU:TPKT:X.225:Association Control Service ElementAbstract Communication Service InterfaceMicrosoft COM object encapsulated in a DLL.Application Protocol Data UnitApplication Service Data UnitAbstract Syntax Notation One (ISO 8824-1, X.680)Basic Encoding Rules (ISO 8825-1, X.690)Component Object ModelAdapter used by STINA CommSrv in order to communicate withspecific remote equipment.Part of STINA communication server used for downloading ofdata.Common Format for Transient Data ExchangeDistributed Component Object ModelDynamic link libraryThe International Electro technical CommissionIntelligent electronic deviceInternet ProtocolInternational Organization for StandardizationInternational Telecommunication UnionInternational Telecommunication Union – TelecomstandardizationPart of STINA communication server that acts like the engine ofSTINA.Local Are NetworkLogical DeviceLogical NodeManufacturing Message SpecificationThe Open Systems Interconnection Reference ModelPresentation Protocol Data UnitAdapter used by STINA ProcSrv in order to process downloadeddata from specific remote equipment.Part of STINA communication server used for processing ofdownloaded data.Request for commentsRemote Terminal UnitSubstation configuration LanguageSpecific communication service mappingSession Protocol Data UnitDisturbance analysis system developed by Powel EnergyManagement ABTransport Control ProtocolTransport Protocol Data UnitTransport PacKeTITU-T Recommendation X.225, OSI session layer protocol (ISO8327)65

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 07X.680: ITU-T Recommendation X.680, International Standard 8824-1(ASN.1)X.690: ITU-T Recommendation X.690, International Standard 8825-1(BER)XML:Extensible Mark-up Language66

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 0714 ReferencesModbus[Jam06] Jamod, Understanding the Modbus protocol,http://jamod.sourceforge.net/kbase/protocol.html, 2006-10-02[Wik07] Wikipedia, Modbus, http://en.wikipedia.org/wiki/Modbus, 2007-02-28[Pla06] Plant Automation, Modbus/TCPhttp://www.plantautomation.com/content/news/article.asp?DocID=%7B2D631F2E-0C1D-11D5-A770-00D0B7694F32%7D&VNETCOOKIE=NO, 2006-10-12IEC 60870-5-103[Ipc06] IPComm, Protocols, IEC 60870-5-103,http://www.ipcomm.de/protocol/IEC103/en/sheet.html, 2006-11-01MMS[Sis95] SISCO, Overview and Introduction to the Manufacturing Message Specification(MMS), Sisco Inc 1995. http://www.sisconet.com/downloads/mmsovrlg.pdf[Kir07] Prof. Dr. H. Kirrmann, http://lamspeople.epfl.ch/kirrmann/Slides/AI_420_MMS.ppt,2007-02-23COMTRADE[CMT07a] Standards for wide area measurement systems,http://www3.imperial.ac.uk/portal/pls/portallive/docs/1/4859918.PDF, 2007-02-15[CMT07b] COMTRADE: a new standard for common data format for transient dataexchange,www.ece.msstate.edu/~schulz/classes/ece8613/jian.ppt, 2007-02-15ASN.1[Obj07] Objective systems, Listing of universal tags.http://www.obj-sys.com/asn1tutorial/node124.html, 2007-01-05[Der07] Luca Deri, A Layman's Guide to a Subset of ASN.1, BER, and DER.http://luca.ntop.org/Teaching/Appunti/asn1.html, 2007-02-01[Oss07a] OSS Nokalva, ASN.1 codig rules. http://www.oss.com/asn1/rules.html, 2007-02-01[Oss07b] OSS Nokalva, http://www.oss.com/news/sitenews.htmlSession Layer[Jav07b] Javvin network management and security, session layer,http://www.javvin.com/protocolISOsession.html, 2007-02-2067

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 07Presentation Layer[Jav07c] Javvin network management and security, presentation layer,http://www.javvin.com/protocolISOpresentation.html, 2007-02-20Application Layer - ACSE[Jav07d] Javvin network management and security, ACSE,http://www.javvin.com/protocolISOACSE.html, 2007-02-20OSI-model[Pcs07] PC Support Advisor, OSI 7 Layer Model Tutorial,http://www.pcsupportadvisor.com/OSI_7_layer_model_page1.htm2007-02-20[Rad07] RAD University, The Seven Layer model,http://www.raduniversity.com/networks/1994/osi/layers.htm2007-02-20STINA[Pow06] Powel, STINA Product brochure, 2006IEC 61850[Mac06] Ralph Mackiewicz , Member IEEE. Overview of IEC 61850 and Benefits, 2006[Sch03 ] H. Schuhert G. Wong. IEC 61850 -THE FUTURE GLOBAL STANDARD FORSEAMLESS AND VENDOR-INDEPENDENTCOMMUNICATION WITHIN SUBSTATIONS, 2003[Hog04] C. Hoga and G.Wong. IEC 61850: Open Communication in Practice in Substations,2004[Sch02] Karlheinz Schwarz, Comparison of IEC 60870-5-101/-103/-104, DNP3, and IEC60870-6-TASE.2 with IEC 61850, SCC 2002Standards[1] International standard IEC 60870-5-103 – Transmission protocols – Companion standardfor the informative interface of protection equipment, 1997[2] International Standard IEC 61850-7-1, Communication networks and systems insubstations – Basic communication structure for substation and feeder equipment – Principlesand models, 2003-07[3] International Standard IEC 61850-7-2, Communication networks and systems insubstations – Basic communication structure for substation and feeder equipment – AbstractCommunication Service Interface (ACSI), 2003-05[4] International Standard IEC 61850-8-1, Communication networks and systems insubstations – Specific Communication Service Mapping (SCSM) – Mappings to MMS (ISO9506-1 and ISO 9506-2) and to ISO/IEC 8802-3, 2004-0568

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 07[5] International Standard ISO 9506-2, Industrial automation systems – ManufacturingMessage Specification – Protocol specification, second edition 2003-07-01[6] Reguest for Comments, RFC905, ISO Transport Protocol Specification ISO DP 8073,1984-04[7] Request for Comments, RFC1006, ISO Transport Service on top of the TCP version: 3,1987-05International Telecommunication Union recommendations[ITU88] ITU-T Recommendation X.225, OSI session layer protocol (ISO 8327), 1988ABB REL670[Abb05] ABB, Innovation from ABB, Line distance protection IED REL, 2005[Abb06a] ABB, Innovation from ABB, Protection and Control for Transmission NetworksIED 670 Selection Guide, 2006[Abb06b] ABB, Line distance protection IED, REL 670, buyer’s guide, April 200669

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 0715 Appendix A - ASN.1 and BERAbstract Syntax Notation One (ASN.1) is a formal language used for specifying objects anddata types on an abstract level, independent from programming languages and computerplatforms. The notation is flexible and a variety of data types can be described by using it.Several different standardized encoding rules, e.g. BER, DER or XER, can be used to encodethe data types defined by ASN.1 notation into a concrete data representation (transfer syntax)BER, which was used in this thesis, describes how the ASN.1 types should be encoded as asequence of octets. All ASN.1 types, except the CHOICE and ANY type, have tags used foridentification. A tag consists of a tag class and a non-negative number as described by section15.2.15.1 TypesASN.1 defines a type as a set of values. Some types have a finite number of values, and othershave an infinite number. The ASN.1 assignment operator (::=) can be used to name types. Thenames can later be used to build up other types. There are four different kinds of ASN.1types: [Der07]15.1.1 Simple typeA simple type has no components, and works like a building block for other types. An Integeris a good example of a simple type. Simple types can be divided into string types and nonstringtypes. [Der07]15.1.2 Structured typeStructured types are types which consist of components. The components can be optional, andthey can also have default values. There are four different kinds of structured types in ASN.1:[Der07]SEQUENCEA SEQUENCE is an ordered collection of variables of different types.SEQUENCE OFA SEQUENCE OF is an ordered collection of variables of a specific type.SETA SET is an unordered collection of variables of different types.SET OFA SET OF is an unordered collection of zero or more objects of a specific type.70

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 0715.1.3 Tagged typeA tagged typed is derived from other types. Tagging can be used to distinguish types withinan application, or components type within a structured type. ASN.1 uses two types of tagging,EXPLICIT and IMPLICIT tagging. [Der07]Example:This example will explain why tagging is used by ASN.1.The ASN.1 syntax below is ambiguous.Invalid ::= SEQUENCE{number1number2Integer32 OPTIONAL,Integer32 OPTIONAL}The type named Invalid has two optional components of type Integer32 withno extra tagging. We can get the following types by removing the OPTIONALparts from it in different ways.SEQUENCE{number1SEQUENCE{number2Integer32}Integer32}Those types will be abstractly the same types, both is a SEQUENCE thatconsists of one component of type Integer32, it will thereby be impossible toknow if the OPTIONAL part number1 is missing, or if number2 is missing. Ifwe encode this type with one of the OPTIONAL parts removed, the receiverwill not be able to decode it correctly since he cannot know if he gets number1or number2. It is always the tag that matters, not the names of the variables. Thisproblem can be solved by redefining the type:Valid ::= SEQUENCE{number1number2[0] Integer32 OPTIONAL,[1] Integer32 OPTIONAL}If only the OPTIONAL part number2 is removed we get the following type:SEQUENCE{number1 [0] Integer32 }If number1 is removed we get this type:SEQUENCE{Number2 [1] Integer32 }It will now possible to see that number2 is missing from the first type, andnumber1 from the second, since the numbers have an extra tag which differs.71

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 07Implicit taggingThe keyword IMPLICIT is used to specify that a type is implicitly tagged. Implicitly taggedtypes are derived by changing the tag of the underlying type, and they are considered to be thesame as the underlying type. [Der07]Syntax: [class number] IMPLICITExplicit taggingThe keyword EXPLICIT is used to specify that a type shall be explicitly tagged. Explicitlytagged types are derived by adding an extra tag to the underlying type. If none of thekeywords IMPLICIT or EXPLICIT is present, then the default tagging type is used. Thedefault type is usually EXPLICIT tagging. An explicitly tagged type can be seen as astructured type with the underlying type as a component. [Der07]Syntax: [class number] EXPLICIT or [Number]15.1.4 Other typesOther types correspond to types that do not fit in any of the other categories. The CHOICEandthe ANY-type are included in this category. The CHOICE type corresponds to a union ofone or several alternatives. [Der07]72

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 0715.2 Tag classesAll ASN.1 types, except the ANY and the CHOICE type, have tags. A tag consists of twoparts, a class and a tag number. There are four different classes. [Der07]15.2.1 UniversalUniversal tags are used by types whose meaning is always the same. Table 15-1 shows anoverview of universal types.Universal Tag Number Description0 reserved for BER1 BOOLEAN2 INTEGER3 BIT STRING4 OCTET STRING5 NULL6 OBJECT IDENTIFIER7 ObjectDescriptor8 INSTANCE OF, EXTERNAL9 REAL10 ENUMERATED11 EMBEDDED PDV12 UTF8String13 RELATIVE-OID16 SEQUENCE, SEQUENCE OF17 SET, SET OF18 NumericString19 PrintableString20 TeletexString, T61String21 VideotexString22 IA5String23 UTCTime24 GeneralizedTime25 GraphicString26 VisibleString, ISO646String27 GeneralString28 UniversalString29 CHARACTER STRING30 BMPStringTable 15-1 – Universal types [Obj07]15.2.2 ApplicationTags of type Application is used by application specific types. [Der07] Implicit or explicittagging can be used.Syntax: [APPLICATION 2] denotes a tag of class APPLICATION with the tagnumber equals to two.73

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 0715.2.3 PrivateTags of type Private is used by types whose meaning is specific to a given enterprise. [Der07]Implicit or explicit tagging can be used.Syntax: [PRIVATE 2] denotes a tag of class PRIVATE with the tag number equal totwo.15.2.4 Context-specificTags of type Context-specific are used by types whose meaning is specific to a givenstructured type. [Der07] Either implicit or explicit tagging can be used.Syntax: [2] denotes a Context-specific tag with the tag number equals to two.15.3 ASN.1 Type ExampleASN.1 notation can as earlier be said to describe complex types, the ASN.1 notation belowdefines the type “Example” which is a SEQUENCE of other objects of different types.ExampleExample ::= SEQUENCE{object1 [0] IMPLICIT Type1 OPTIONAL,object2 [1] IMPLICIT Type1 OPTIONAL,object3 Type2}Type1 ::= SEQUENCE{boolean1 [0] IMPLICIT BOOLEAN DEFAULT TRUE,boolean2 [1] IMPLICIT BOOLEAN DEFAULT FALSE,integer INTEGER}Type2 ::= CHOICE{number1number2INTEGER,BOOLEAN}The syntax above defines the type “Example” as a sequence of two optional objects of typeType1 and one object of Type2. The Type1 type is defined as a sequence of two Booleans andone Integer, boolean1 has the default value true, and boolean2 has the default value falseType2 is defined as a choice between an INTEGER and a BOOLEAN. The Example typedoes not represent anything useful; its purpose is only to give an example of how types can bedefined.74

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 0715.4 Basic Encoding RulesThe Basic encoding rules define three methods for encoding of an ASN.1 values [Der07]: Primitive, definite-length encodingThis method is used by simple non-string types. Constructed, definite- length encodingThis method is used by structured types when the length of the value is known. Constructed, indefinite-length encodingThis method is used by constructed types when the length is unknown.Implicitly tagged types use the method for the underlying type, and explicitly tagged typesuses one of the methods used for encoding constructed types. A BER encoded ASN.1 typeconsists of three or four parts. The fourth part is only present if the indefinite-length encodingmethod is used [Der07].Identifier octetsThe Identifier octets correspond to the encoding of the tag used by the ASN.1 type.Length octetsThe length octets give defines the length of the contents octets, or indicates that the length isindefinite.Contents octetsIf the type is primitive, then the contents octets give a concrete representation of a specificvalue. If the encoded type is constructed, then the contents octets contain the BER encodingsof the components.End-of-contents octetsThe End-of-contents octets are only used by the constructed, indefinite-length encodingmethod, and they shall consist of two octets with the value 0x0000. [Der07]75

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 0715.5 Primitive, definite-length methodThe primitive, definite-length encoding method is used by simple types and implicitly taggedtypes derived from simple types. [Der07]15.5.1 Identifier octetsThe identifier octets are used for identification of types. BER uses two forms for the identifieroctets. One method is used for tag numbers between 0 and 30, and another method is used forlarger tag numbers (>=31). [Der07]CLASS BIT 8 BIT 7UNIVERSAL 0 0APPLICATION 0 1CONTEXT-SPECIFIC 1 0PRIVATE 1 1Table 15-2 – BER encoding of tag classes [Der07]Tag numbers (0

Using IEC 61850 for remote disturbance analysisRoland HamrénPowel Energy Management AB March 0715.5.3 Contents octetsThe contents octets give a concrete representation of the value of the primitive type. [Der07]15.6 Constructed, definite-length methodThis method is used by: Simple string types Types derived from simple string types Structured types Implicitly tagged structured types Explicitly tagged typesIdentifier octetsThe tag is encoded as described by the primitive, definite-length encoding method, except thatBit 6 of the first identifier octet is set to one to indicate that the encoding is constructed.[Der07]Length octetsThe same method as used by the primitive types.Contents octetsThe contents octets shall contain BER encodings of the components of the structured type.[Der07]15.7 Constructed, indefinite-length methodThis method is used for encode constructed ASN.1 types when we do not know the length ofthe type in advance. The method is almost the same as the method used for definite-lengthencoding of constructed types, only two parts is different. [Der07]Length octetsThe length octets shall consist of one octet containing the following value: 0x80This indicates that indefinite-length encoding is used. [Der07]End-of-contents octetsEnd-of-contents octets (0x00 00) shall mark were the encoding stops. [Der07]77