For the sake of completeness, we have developed the Drosera application, which allows simple and fast configuration of our 61850 protocol converters. This tool is addressed especially to integrators and device manufacturers and does not require any programming knowledge. The intuitive user interface provides access to configuration and mappings along with performing the operations necessary to establish reliable communication between JPEmbedded’s IEC 61850 gateway and other IEDs (Intelligent Electronic Devices).
Drosera allows users to add, edit and browse mappings between IEC 61850 data attributes and data points of supported protocols. The application currently supports the following standards: MQTT, IEC 60870-5-103, ModbusTCP, and ModbusRTU. User can upload the generated CID file directly to JPEmbedded’s gateway or export the mappings to CSV file.
Interesting? Watch the demo movie and see Drosera in action!
Drosera is made available free of charge to all customers. If you are interested to try it please send us a message via firstname.lastname@example.org.
The days when the domains such as IT, factory automation, electricity grid were placed on islands with no, or very limited connectivity are gone by. In today’s world information technologies are becoming an indispensable factor for almost every walk of life, and the key enabler of this process is exchange of information. Proliferation of Ethernet based standards for industrial automation, energy market and others(home automation, IoT), have created the possibility to integrate devices and subsystems theoretically belonging to different galaxies.
This article describes a solution for how to integrate Profinet devices into the smart grid with the use of IEC 61850, or vice versa, and how to plug intelligent electronic device (IED) into the Profinet network.
A detailed description of Profinet is out of the scope of this article, but in order to simplify the understanding of the solution put forward below, some basic information will be provided here. The two main types of Profinet devices are the Controller and IO Device. A Controller is responsible for identifying devices available in the subnet and establishing connections with them. Once the connection is established, Controller and IO device exchange data on periodic basis, with cycle time being a power of 2 (1, 2, 4, 8, 16, 32…512 milisec). Controller and IO device send the cyclic data to the other side independent of each other, which means that even when some frames are not received, outgoing data is sent to the peer, with the cycle time agreed during connection establishment. Information in Profinet networks is organized into modules. Modules could be input,output or input/output. Input always means the data sent from the IO device to the controller and output is the data sent from the controller to the IO device. In every cycle, data comprised by all configured modules is sent, so usually it must fit into the Ethernet MTU (1500 bytes).
Beside cyclic data Profinet also defines alarms which cold be transmitted by both sides to notify the peer of some anomalies and record data, which are read or written by the controller in a request / response manner. The size of record data is not limited by Ethernet MTU.
IEC 61850 is an international standard describing data models and communication services for power grid devices also known as IEDs (intelligent electronic device). Three most important protocols utilized by the IEC 61850 standard are Manufacturing Message Specification (MMS), Generic Object Oriented Substation Event (GOOSE), Sampled Values (SMV).
Control centers like SCADA systems communicate with IED using a client / server model with MMS protocol, and this is often referred to as vertical communication. IED devices installed within a substation can communicate with each other according to the publisher / subscriber scheme, using GOOSE or SMV multicast protocols which are specified by the standard. This is usually called horizontal communication.
The data model of IED is a hierarchical structure consisting of logical devices, logical nodes, data objects and data attributes. Data objects and data attributes can be grouped into the data-sets, which provides the basis for generation of reports, GOOSE or SMV messages. Values of the data model attributes could be modified either by IEC 61850 clients issuing MMS write requests to the server, or by the IED application running on the device in response to some events, such as a change of measured current or voltage, or a received GOOSE message from another IED in the system.
There are several ways (some very wired…) how to project the Profinet domain into the IEC 61850 data model, however it is important to meet requirements like: flexibility, performance, ease of deployment or customization. Since the size of Profinet input/output modules may vary from 1 to several bytes (64 or more) bytes, assuming that one module (input or output) would map to one IED attribute would be an oversimplification and thus a serious limiting factor.
The solution by JPEmbedded is simple, yet flexible and it allows to map any subset of cyclic data (both inputs and outputs) to IEC 61850 data model attributes and record data into the IEC 61850 files. As the output variables are updated by the Controller, values of IEC 61850 attributes are set, which might result in some actions like generation of sampled values, GOOSE messages or reports, depending on the configuration of the IED by the client(s).
The graphic below shows the gateway along with the devices it is talking to.
The details of the data mapping and implementation are described below.
As described above, Profinet cyclic data is comprised of a number of input or output modules which are configured at the IO device when connection is established. All input modules assemble the content of the frame sent in every cycle to the controller and all output modules of the IO device are updated with the data in the frame received from the controller. User can arbitrarily map the whole or a part of Profinet module to the value of attribute of the IED data model. Of course the mapping must be done with some basic awareness of data types, e.g. mapping of 1 byte to float32 attribute probably does not make sense. The rules of mapping of Profinet module data into the IED attributes are summarized in the table below.
Lets assume that data model of IEC 61850 server is mapped to input module X consisting of e.g. 16 bytes Ib0 … Ib15 and and output module Y consists of 16 bytes Ob0 to Ob15.
The details of the data mapping and implementation are described below.
In case of both input data and output data boolean attribute is mapped to one byte specified by the byte offset.
When mapping output data to IEC 61850 integer attribute, first integer value is created based on offset of the byte in the module data, length of the mapped values and endiannes. E.g. if offset is 8 and length is 4, depending on selected endiannes the integer value is created as:
ival = (Ob8 << 24) + (Ob9 << 16) + (Ob10 << 8) + Ob11
ival = (Ob11 << 24) + (Ob10 << 16) + (Ob9 << 8) + Ob8
Than the value is assigned by the gateway application to the attribute which reference is provided in the mapping.
In case of mapping of integer attributes to input data modules, first it is checked if attribute value fits into the number of byte specified by the mapping. If attribute value is too high, Profnet input data is not updated (e.g. mapping of value 25001 to two bytes) and status of the the Profinet input module is set to bad. Otherwise input data bytes are updated, according to the mapping parameters, e.g. if offset is 6, length 2 and value of mapped integer attribute 261 bytes 2 and 3 aew set for big endian as:
Ib2 = 1, Ib3 = 5
and for little endian:
Ib2 = 5, Ib3 = 1
Mapping of floats follows to same rules as mapping of integers described above with the assumption that length of mapped bytes (in both ways) must always be 4.
So assuming that 3 attributes
layout of input module X bytes will be showed on the picture below.
Bigger chunks of Profinet information are called data records. Usually their content is not updated very often (unlike cyclic data), but they could be several kilobytes in size. Mapping them to data model attributes doesn’t make sense, but IEC 61850 journal files seem to be good counterpart. Journal files could be read or written by an IEC 61850 client more or less the same way the record data is read or written by Profinet controller. Again, the user must be aware that some records are mandatory by the standard and they should contain specific, well defined content. So writing them with the IEC 61850 client shall not be allowed, in which case, they could be mapped to read-only journal files. With vendor specific record data, the IEC 61850 side of the gateway should be able to both read and write the content of the file (and associated data record). Each Profinet data record is addressed by the index which are mapped to the IEC 61850 journal file path.
The data model and features of IED are defined by SCL file called Configured IED Description (CID). SCL is an XML schema and its structure is defined by the standard. The definition of the file could be customized using a ‘Private’ element and this is how the data model attributes are mapped into Profinet input/output modules.
So the advantage for the end user is that the only configuration task is to prepare a CID file for the device (which must be done anyway) with private section, mapping Profinet to IEC 61850. Then the file will be uploaded to the gateway using a web browser, and the gateway is ready for action. Of course, PN modules mapped to the IEC 61850 data model must be configured on the device by the controller. The other option would be to define the structure of the Profinet IO device in the CID file so that the modules could be plugged into the slots during initialization of the device rather than during connection setup. There don’t seem to be any obvious advantages of this option, and it seems to be an additional overhead and yet another possibility for the user to do something wrong…
The example part of CID file mapping IEC 61850 data model to Profinet module X in slot 1, subslot 1 is shown below:
<Gway> <Fbus type="pn" addr="10.0.0.153:1883" /> <Signal> <Ref1 type="in" data="bool">GWay/XCBR1.Pos.stVal</Ref1> <Ref2 type="in" data="bool" size="1" offset="0">1/1</Ref2> </Signal> <Signal> <Ref1 type="in" data="int32">GWay/MMXUA.phsA.cVal.mag.i</Ref1> <Ref2 type="in" data="int32" size="4" offset="1">1/1</Ref2> </Signal> </Gway>
There are at least two real life scenarios in which JPEmbedded’s solution could be deployed in the field and both of them are described in detail below. Let us know which one seems better suited for your needs.
Lets start with the easier way, which is to plug device with nice housing (see the picture 1) and two Ethernet ports to your Profinet network. Along with the device JPEmbedded provides sample CID and GSDML files. All you have to do is customize the CID, by defining data model for you IED, and map the attributes of the model to inputs and outputs of the Profinet IO device side. The name of the Profinet IO device and its IP address could also be assigned via CID file. Then the device is ready to establish application relationship (AR) with the controller, at which point all the modules are plugged into the slots. The gateway features a two port Ethernet switch, which could be configured to optimize traffic on both sides of the gateway (e.g. multicast and broadcast traffic from one external port are not forwarded to the other external port). After connecting with IEC 61850 client(s), user should see changes of attribute values as a result of updates of Profinet IO device output modules.
The other option is to implement the gateway functionality in the customer device. This could be done using libraries provided by JPEmbedded. It requires a bit more effort but on the other hand it offers much more flexibility in terms of features, which could be implemented by gateway application. E.g. on the Profinet side, custom alarms might be triggered or application specific processing of the values of IED data model attributes, which is transferred to the controller as cyclic input data. The fulfillment of certain requirements by the customer hardware could be yet another reason to implement the software version of the gateway.
If you have any comments or questions we encourage you to reach out to us!
Internet of Things continues to be one of the key technology trends in the recent years. According to Gartner’s estimations, IoT network will grow from 8,7 billion in 2017 to over 20 billion connected things by 2020. Utilities representing the energy market understand the advantages offered by Internet of Things, and look towards integrating it with its Intelligent Electronic Devices (IEDs) deployed in substations and distribution networks. Well-thought integration of the IoT with existing smart-grids will extend benefits beyond distribution, automation and monitoring, making energy use more efficient and saving billions of Euros…
In this blog entry, I will showcase how to integrate IEC 61850 (an international standard for smart grids and substation automation) with an MQTT based IoT network. The idea and demo setup of the system have been presented by JPEmbedded at the IEC 61850 Global Conference in Berlin in October 2018.
JPEmbedded’s IoT to IEC 61850 demo setup consists of several NanoPi modules, acting as IoT devices installed on Distributed Energy Resources (e.g. on microturbines or, on photovoltaics). Each IoT device publishes some data which is sent to an MQTT broker running on a RaspberryPi device.
The MQTT broker is responsible for receiving all messages broadcasted by the IoT network, filtering them, determining who is subscribed to each message, and sending the message to these subscribed clients. Another responsibility of the broker is the authentication and authorization of clients. The broker can handle a large number of concurrently connected MQTT clients.
In our system, a JPEmbedded’s IEC 61850 gateway is configured as an MQTT client and subscribed to receive relevant data from the MQTT broker. The values received from the broker are mapped to the IEC 61850 data model. The control block configured on the gateway generates GOOSE frames each time any value is updated by the IoT network. According to our measurement, the delay between reception of an MQTT message and generation of a goose message by the gateway is lower than 0,8 milisecons.
Updates on the parameter in the data model are sent to the IEC 61850 client installed on a PC.
Communication between DER (including dispersed generation devices and dispersed storage devices) and IEC 61850 is already defined in IEC 61850-7-420:2009. It utilizes existing IEC logical nodes defined in part 4 of the standard where possible, but also defines DER-specific logical nodes where needed.
As far as the hardware is concerned, NanoPi and RaspberryPi are only two examples of the various platforms that can be used as a base for IoT devices. Similar systems can be made on any other, commercially available IoT device by integrating it with JPEmbedded’s IEC 61850 gateway. Finally, JPEmbedded’s gateway can be customized and convert not only MQTT, but also other data protocols like CoAP, Websocket, Node or XMPP.
If you would like to know more about our demo system or the IEC 61850 gateway itself, please contact us at email@example.com.