The Power Grid Wrapper Feature is designed to support users with protocols and data types related to the power grid. It contains support with the protocols and data types listed on this site.

Prerequisites

To use the Power Grid Wrapper Feature, one has to install the j60870 Feature that is licensed under the GPLv3. The j60870 Feature contains the j60870 library that is originally developed by Stefan Feuerhahn (Frauenhofer ISE) and provided by openMUC under the GPLv3. It is modified by the University of Oldenburg. 

Protocols

IEC 60870-5-104

The protocol itself

The source of this section is Wikipedia.

IEC 60870 part 5 is one of the IEC 60870 set of standards which define systems used for telecontrol (supervisory control and data acquisition) in electrical engineering and power system automation applications. Part 5 provides a communication profile for sending basic telecontrol messages between two systems, which uses permanent directly connected data circuits between the systems. The IEC Technical Committee 57 (Working Group 03) have developed a protocol standard for telecontrol, teleprotection, and associated telecommunications for electric power systems. The result of this work is IEC 60870-5. Five documents specify the base IEC 60870-5:

• IEC 60870-5-1 Transmission Frame Formats
• IEC 60870-5-2 Data Link Transmission Services
• IEC 60870-5-3 General Structure of Application Data
• IEC 60870-5-4 Definition and Coding of Information Elements
• IEC 60870-5-5 Basic Application Functions
• IEC 60870-5-6 Guidelines for conformance testing for the IEC 60870-5 companion standards
• IEC TS 60870-5-7 Security extensions to IEC 60870-5-101 and IEC 60870-5-104 protocols (applying IEC 62351)

The IEC Technical Committee 57 has also generated companion standards:

• IEC 60870-5-101 Transmission Protocols - companion standards especially for basic telecontrol tasks
• IEC 60870-5-102 Transmission Protocols - Companion standard for the transmission of integrated totals in electric power systems (this standard is not widely used)
• IEC 60870-5-103 Transmission Protocols - Companion standard for the informative interface of protection equipment
• IEC 60870-5-104 Transmission Protocols - Network access for IEC 60870-5-101 using standard transport profiles
• IEC TS 60870-5-601 Transmission protocols - Conformance test cases for the IEC 60870-5-101 companion standard
• IEC TS 60870-5-604 Conformance test cases for the IEC 60870-5-104 companion standard

IEC 60870-5-101/102/103/104 are companion standards generated for basic telecontrol tasks, transmission of integrated totals, data exchange from protection equipment & network access of IEC101 respectively. IEC 60870-5-101 is a standard for power system monitoring, control & associated communications for telecontrol, teleprotection, and associated telecommunications for electric power systems. This is completely compatible with IEC 60870-5-1 to IEC 60870-5-5 standards and uses standard asynchronous serial tele-control channel interface between DTE and DCE. The standard is suitable for multiple configurations like point-to-point, star, mutidropped etc.

Features

The source of this section is Wikipedia.

• Supports unbalanced (only master initiated message) & balanced (can be master/slave initiated) modes of data transfer.
• Link address and ASDU(Application Service Data Unit) addresses are provided for classifying the end station and different segments under the same.
• Data is classified into different information objects and each information object is provided with a specific address.
• Facility to classify the data into high priority (class-1) and low priority (class-2) and transfer the same using separate mechanisms.
• Possibility of classifying the data into different groups (1-16) to get the data according to the group by issuing specific group interrogation commands from the master & obtaining data under all the groups by issuing a general interrogation.
• Cyclic & Spontaneous data updating schemes are provided.
• Facility for time synchronization
• Schemes for transfer of files-Example:IED's will store disturbance recorder file in the memory, When electrical disturbance is occurred in the field. This file can be retrieved through IEC103 protocol for fault analysis

Frame format

The source of this section is Wikipedia.

Character format of IEC 101 uses 1 start bit, 1 stop bit, 1 parity bit & 8 data bits. FT1.2 (defined in IEC 60870-5-1) is used for frame format of IEC 101 which is suitable for asynchronous communication with hamming distance of 4. This uses 3 types of frame formats - Frame with variable length ASDU, Frame with fixed length & single character. Single character is used for acknowledgments, fixed length frames are used for commands & variable lengths are used for sending data. The details of variable length frame is given below

IEC 101 Frame Format, Variable length

Types supported

The source of this section is Wikipedia.

• Single indication without / with 24 / with 56 bit timestamps.
• Double indication without / with 24 / with 56 bit timestamps.
• Step position information without / with 24 / with 56 bit timestamps.
• Measured value – normalized, scaled, short floating point without / with timestamps.
• Bitstring of 32 bit without / with timestamps.
• Integrated totals (counters) without / with timestamps.
• Packed events (start & tripping ) of protection equipments
• Single commands
• Double commands
• Regulating step command
• Set point commands of various data formats
• Bitstring commands
• Interrogation commands
• Clock synchronization & delay acquisition commands
• Test & reset commands

IEC 60870-5-104 (IEC 104) protocol is an extension of IEC 101 protocol with the changes in transport, network, link & physical layer services to suit the complete network access. The standard uses an open TCP/IP interface to network to have connectivity to the LAN (Local Area Network) and routers with different facility (ISDN, X.25, Frame relay etc.) can be used to connect to the WAN (Wide Area Network). Application layer of IEC 104 is preserved same as that of IEC 101 with some of the data types and facilities not used. There are two separate link layers defined in the standard, which is suitable for data transfer over Ethernet & serial line (PPP - Point-to-Point Protocol). The control field data of IEC104 contains various types of mechanisms for effective handling of network data synchronization.

The security of IEC 104, by design has been proven to be problematic, as many of the other SCADA protocols developed around the same time. Though the IEC technical committee (TC) 57 have published a security standard IEC 62351, which implements end-to-end encryption which would prevent such attacks as replay, man-in-the-middle and packet injection. Unfortunately due to the increase in complexity vendors are reluctant to roll this out on their networks.

IEC 60870-5-104 transport handler

In Odysseus, both protocol stacks, client and server, are implemented as transport handler. A "104 server" represents a field station and a "104" client a grid control system. Important is that both transport handler do also the work of protocol handlers. Therefore, they must always be combined with the "None" protocol handler. See the examples below for the usage of the transport handler.

#PARSER PQL
#RUNQUERY
input := ACCESS({
          transport = 'iec60870-5-104_client',
          wrapper = 'GENERICPUSH',
          source = '104server',
          datahandler = 'tuple',
          options = [['host', '192.168.1.38'], ['port', '2404']],      
          schema = [
            ['typeId', 'object'],
            ['isSequenceOfElements', 'boolean'],
            ['causeOfTransmission', 'object'],
            ['test', 'boolean'],
            ['negativeConfirm', 'boolean'],
            ['originatorAddress', 'integer'],
            ['commonAddress', 'integer'],
            ['sequenceLength', 'integer'],
            ['informationObjects', 'list'],
            ['areInfosPrivate', 'boolean']
          ]                
        }            
      )

#PARSER PQL
#RUNQUERY
out = SENDER({
          protocol = 'None',
          transport = 'iec60870-5-104_client',
          sink = '104server',
          wrapper = 'GenericPush',
          datahandler = 'tuple',
          options = [['host', '192.168.1.38'], ['port', '2404']]                
        },
        input
      )

#PARSER PQL
#RUNQUERY
input := ACCESS({
          transport = 'iec60870-5-104_server',
          wrapper = 'GENERICPUSH',
          source = '104client',
          datahandler = 'tuple',
          options = [['host', '192.168.1.38'], ['port', '2404']],      
          schema = [
            ['typeId', 'object'],
            ['isSequenceOfElements', 'boolean'],
            ['causeOfTransmission', 'object'],
            ['test', 'boolean'],
            ['negativeConfirm', 'boolean'],
            ['originatorAddress', 'integer'],
            ['commonAddress', 'integer'],
            ['sequenceLength', 'integer'],
            ['informationObjects', 'list'],
            ['areInfosPrivate', 'boolean']
          ]                
        }            
      )

#PARSER PQL
#RUNQUERY
out = SENDER({
          protocol = 'None',
          transport = 'iec60870-5-104_server',
          sink = '104client',
          wrapper = 'GenericPush',
          datahandler = 'tuple',
          options = [['host', '192.168.1.38'], ['port', '2404']]                
        },
        input
      )

IEC 60870-5-104 protocol handler

This is a simplified version that does not implement the handshake etc. It just converts a byte array into an ASDU. This protocol handler is useful for interpret Pcap files that contain IEC 60870-5-104 messages. For an example, see Pcap file transport handler.

IEC 62056 (DLMS/COSEM) IN PROGRESS

The protocol itself

IEC 62056 is a canonical and widespread specification for smart metering and is specified by the DLMS User Association. Thus it is used to coordinate the communication between Smart Meters and Smart Meter Gateways or other servers in between. It comprises the Device Language Message Specification (DLMS) and the Companion Specification for Energy Metering (COSEM). COSEM defines an interface-model that is used to describe any kind of smart meter or smart meter gateway. DLMS extends this definition with abstract services that can are used to coordinate the transmission of smart meter data between clients and server. The term smart meter relates to a device that measures the energy consumption and production of a household and transmits this information to a smart meter gateway. A smart meter gateway is the interconnection between arbitrary many smart meters and a server that may relates to a smart grid application. The specification is described by four documents:

• Blue Book describes the interface-model COSEM
• Green Book discusses protocols for the transport layer that can be used for DLMS/COSEM
• Yellow Book describes a test suite for testing DLMS/COSEM
• White Book contains all definitions and acronyms of the specification

IEC 62056 transport handler

Currently the transport handler for IEC 62056 has no implementation and for this reason Odysseus cannot directly communicate with a smart meter gateway.

IEC 62056 protocol handler

To process COSEM data with Odysseus, you can use the IEC 62056 protocol handler. The protocol handler offers different configurations for ACCESS-Operator and SENDER-Operator:

• ACCESS-Operator has to specify the type format of the COSEM data and a mapping to the logical name of the smart metering device name
  • type can either be XML or JSON
  • smgwDeviceName relates to the data field that specifies the logical name of the smart meter gateway. It has to map to an entry of the given schema
• SENDER-Operator has to specify a predefined json schema, because the IEC 62056 protocol handler transforms a tuple to a JSON string

• • jsonschema

    RAWDATA

    {  
       "query_id":"ID",
       "result":{  
          "logical_name":"sm_041",
          "value":1.182,
          "unit":30,
          "scaler":-3,
          "status":"000",
          "capture_time":0,
          "timeinterval_start":1503576773868,
          "timeinterval_end":-9223372036854775807,
          "minlstart":-1,
          "maxlstart":-1,
          "lend":-1,
          "latency":-1
       }
    }

XML

Currently not supported.

JSON

Read raw COSEM data from a file.

#PARSER PQL
#RUNQUERY
fileInput := ACCESS({
            source='file',
            wrapper='GenericPull',
            transport='File',
            protocol='DLMS/COSEM',
            datahandler='Tuple',
            options=[
              ['filename', '${WORKSPACEPROJECT}/EXAMPLE_5.json'],
              ['type', 'json'],
              ['smgwDeviceName', 'smgw_logical_name']
            ],
   		 schema=[
		    ['smgw_logical_name','String'], ['logical_name', 'String'], ['unit', 'Integer'],
		    ['status', 'String'], ['scaler', 'Integer'],['capture_time', 'long'], ['value','Double']]                                                                                                                                                                                                                                                     
          }                                                                                                                                                                                                                                 
        )

Write raw COSEM data to a file.

#PARSER PQL
#RUNQUERY
out = SENDER({
		    sink='out',
            wrapper='GenericPush',
            transport='File',
            protocol='DLMS/COSEM',
            datahandler='Tuple',
            options=[
              ['filename', '${WORKSPACEPROJECT}/out.data'],
              ['queryID', 'ID'],
              ['jsonschema', 'RawData']
            ]},
              fileInput                                                                                                                                                                                                                       
        )

To simulated a push-based processing of COSEM data, you can combine the IEC 62056 protocol handler with the Kafka Feature

#PARSER PQL
#RUNQUERY
kafka := ACCESS({
            source='kafka',
            wrapper='GenericPush',
            transport='Kafka',
            protocol='DLMS/COSEM',
            datahandler='Tuple',
            options=[
              ['topic', 'topic_name'],
              ['messagetype', 'string'],
              ['bootstrap.servers', 'localhost'],
              ['type', 'json'],
              ['smgwDeviceName', 'smgw_logical_name']
            ],
   		 schema=[
		    ['smgw_logical_name','String'], ['logical_name', 'String'], ['unit', 'Integer'],
		    ['status', 'String'], ['scaler', 'Integer'],['capture_time', 'long'], ['value','Double']]                                                                                                                                                                                                                                                    
          }                                                                                                                                                                                                                                
        )

It is recommended to only use the TupleDataHandler for processing COSEM data.

Pcap

The protocol itself

The source of this section is Wikipedia.

In the field of computer network administration, pcap (packet capture) consists of an application programming interface (API) for capturing network traffic. Unix-like systems implement pcap in the libpcap library; Windows uses a port of libpcap known as WinPcap.
Monitoring software may use libpcap and/or WinPcap to capture packets travelling over a network and, in newer versions, to transmit packets on a network at the link layer, as well as to get a list of network interfaces for possible use with libpcap or WinPcap.
The pcap API is written in C, so other languages such as Java, .NET languages, and scripting languages generally use a wrapper; no such wrappers are provided by libpcap or WinPcap itself. C++ programs may link directly to the C API or use an object-oriented wrapper.

Used library

This Odysseus feature uses jNetPcap.

PCap file transport handler

In Odysseus, a file transport handler is implemented to read Pcap files. Writing Pcap files is currently not supported! See the examples below for the usage of the transport handler in combination with the IEC 60870-5-104 protocol handler

#PARSER PQL
#RUNQUERY
input := ACCESS({
              transport = 'pcapfile',
              protocol = 'iec60870-5-104',
              wrapper = 'GENERICPUSH',
              source = 'Pcap',
              datahandler = 'tuple',
              options = [['file', somepcapfile.pcap]],
              schema = [
                ['typeId', 'object'],
                ['isSequenceOfElements', 'boolean'],
                ['causeOfTransmission', 'object'],
                ['test', 'boolean'],
                ['negativeConfirm', 'boolean'],
                ['originatorAddress', 'integer'],
                ['commonAddress', 'integer'],
                ['sequenceLength', 'integer'],
                ['informationObjects', 'list'],
                ['areInfosPrivate', 'boolean']
              ] 
            } 

          )

Data types

• Application Service Data Unit (ASDU)
  • The ASDU is the payload of the application protocol data unit (APDU). Its structure is defined in IEC 60870-5-104. The ASDU consists of the Data Unit Identifier and a number of Information Objects. The Data Unit Identifier contains:
• TypeId (1 byte)
• Variable Structure Qualifier (1 byte) - specifies how many Information Objects and Information Element sets are part of the ASDU.
• Cause of Transmission (COT, 1 or 2 bytes) 
  • The first byte codes the actual CauseOfTransmission, a bit indicating whether the message was sent for test purposes only and a bit indicating whether a confirmation message is positive or negative. The optional second byte of the Cause of Transmission field is the Originator Address. It is the address of the originating controlling station so that responses can be routed back to it.
• Common Address of ASDU (1 or 2 bytes) 
  •  the address of the target station or the broadcast address. If the field length of the common address is 1 byte then the addresses 1 to 254 are used to address a particular station (station address) and 255 is used for broadcast addressing. If the field length of the common address is 2 bytes then the addresses 1 to 65534 are used to address a particular station and 65535 is used for broadcast addressing. Broadcast addressing is only allowed for certain TypeIDs.
• A list of Information Objects containing the actual actual data in the form of Information Elements.

In Odysseus, the IEC 60870-5-104 transport handler sends a tuple to the data handler with the following schema:

• typeId: Object
• isSequenceOfElements: Boolean
• causeOfTransmission: Object
• test: Boolean
• negativeConfirm: Boolean
• originatorAddress: Integer
• commonAddress: Integer
• sequenceLength: Integer
• informationObjects: List
• areInfosPrivate: Boolean

It is recommended to use the Tuple datahandler.