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.
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.
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:
The IEC Technical Committee 57 has also generated companion standards:
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.
The source of this section is Wikipedia.
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
| Data unit | Name | Function |
|---|---|---|
| Start Frame | Start Character | Indicates start of Frame |
| Length Field (*2) | Total length of Frame | |
| Start Character (repeat) | Repeat provided for reliability | |
| Control Field | Indicates control functions like message direction | |
| Link Address (0,1 or 2) | Normally used as the device / station address | |
| Data Unit Identifier | Type Identifier | Defines the data type which contains specific format of information objects |
| Variable Structure Qualifier | Indicates whether type contains multiple information objects or not | |
| COT (1 or 2) | Indicates causes of data transmissions like spontaneous or cyclic | |
| ASDU Address (1 or 2) | Denotes separate segments and its address inside a device | |
| Information Object | Information Object Address (1 or 2 or 3) | Provides address of the information object element |
| Information Elements (n) | Contains details of the information element depending on the type | |
| Information Object-2 | ----- | |
| ----- | ----- | |
| Information Object-m | ||
| Stop Frame | Checksum | Used for Error checks |
| Stop Char | Indicates end of a frame |
The source of this section is Wikipedia.
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.
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
) |
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 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 relate to a smart grid application. The specification is described by four documents:
Currently the transport handler for IEC 62056 has no implementation and for this reason Odysseus cannot directly communicate with a smart meter gateway.
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:
jsonschema
{
"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
}
} |
Currently not supported.
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 simulate 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.
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.
This Odysseus feature uses jNetPcap.
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']
]
}
) |
TypeId (1 byte)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.In Odysseus, the IEC 60870-5-104 transport handler sends a tuple to the data handler with the following schema:
It is recommended to use the Tuple datahandler.