This article describes one of the possible approaches to implementation of gateway converting regular Ethernet based GOOSE messages to routable (R) version of this protocol. GOOSE which stands for Generic Object Oriented Substation Event, is one of the protocols introduced by the IEC61850 standard released in 2004. Its primary purpose is to notify peers about different protection events generate at intelligent electronic device (IED) e.g. protection relay. In the first edition of the standard it was specified as a protocol implemented directly on top of the link layer – Ethernet. There are two types of actors in GOOSE communications:
As a solution for horizontal, peer-to-peer communication, GOOSE over Ethernet, seemed to be a good choice, especially considering the requirement of low latency for this type of traffic. Sending out multi-cast Ethernet frames on event driven or periodic basis, involves very low overhead and satisfies timing requirement of low delay between the time at which an event occurred and generation of the message with the information about it.
One obvious limitation of this approach is that such communication is limited to the local network (LAN) and with the introduction of DER and evolution of the grid towards distributed architecture, there was a need for routable version of GOOSE protocol. This implicated the question of the (cyber) security of the very sensitive information which is sent by IED belonging to the critical infrastructure.
In the following sections I describe the solution which does not require major updates to the existing equipment installed in the field, offers great deal of flexibility and is relatively simple to deploy.
AES – Advanced Encryption Standard
AES-CBC – AES cipher block chaining
AES-GMC – AES Galois counter mode
APDU – application protocol data unit
APPID – application identifier
CRL – certificate revocation list
DER – distributed energy resource
DUT – device under test
GDOI – group domain of interpretation
GOOSE – generic object oriented substation event,
HMAC – hash based message authentication code
IED – intelligent electronic device
IKE – internet key exchange
ISAKMP – internet security association and key management protocol
IP – internet protocol
KDC – key distribution center
OCSP – online certificate status protocol
RBAC – role based access control
R-GOOSE – routable GOOSE
SMV – sampled values
UDP – user datagram protocol
There are several options for transition from layer 2 (L2) GOOSE to R-GOOSE, however one of the simplest for implementation is to use gateway which on one hand is a subscriber of the ‘traditional’ L2 GOOSE messages published by the IEDs connected to the local network, but on the other hand publishes received messages as an UDP/IP multi-cast traffic. The whole idea is depicted in the picture below.
The main tasks of the gateway are:
For easier understanding of the whole process the picture below shows how the stack of L2 GOOSE maps to the protocols of the routable side.
The frame encoding details for L2 and UDP GOOSE messages are specified in IEC61850-9.1 and IEC62351-9 respectively.
Gateway itself can act as an IEC61850 server that subscribes to a multiple types of L2 GOOSE published by different IEDs within the local network. For each subscribed GOOSE, as a bare minimum, there should be defined destination UDP multicast address to which GOOSE will be sent.
Depending on the need of specific applications it is also possible to updated some parameters of the published R-GOOSE like application ID number, goose ID string or customize the delay between re-send messages.
As for the configuration of the gateway, it could be done statically via xml file, in which case once the xml config file is uploaded to the gateway, subscribers and publishers are initialized and could be either enabled or disabled by the IEC61850 client application, but the parameters of the subscriber (L2) side or publisher (routable) side, do not change until the new configuration is uploaded and instance of the gateway is restarted.
If required, it is also possible to modify during run time some parameters of the gateway:
It depends on the requirements of the specific application and the customer using the gateway.
While the overall idea might seem very simple (and actually it is), as the saying goes, the devil is int he details. Putting together all the puzzles, requires deployment of the right technology, tools and skills, especially if the goal is to have a flexible, scalable and salable product. In the following paragraphs I’ll scratch the surface a bit and briefly touch on the issues related to cybersecurity and performance, however this is by no means an exhaustive coverage of the matter.
Since GOOSE messages published as UDP/IP multicast, potentially will be sent over wide area networks it is extremely important to protect the information against unauthorized access and modification. Considering the fact that GOOSE message could contain some sensitive information about the state of the critical infrastructure, this is good enough reason not to cut corners when it comes to cybersecurity. An obvious approach is to implement well know encryption standards like AES-CBC or AES-GMC. The details of how GOOSE data units (APDU) are encrypted are outside the scope of this article and could be found in IEC62351-9. AES is a symmetric encryption standard which provides sufficient level of security, it is not difficult to implement in software and thus is very popular and widely available. Some hardware platforms offer build-in (hardware) acceleration of the AES implementation which significantly increases the speed of encryption/decryption operation. Since this is symmetrical algorithm, both sender and receiver of the message must share the key, and secure distribution of the encryption keys is a non trivial task. Also the overhead related to crystallographic operations must be considered, when designing and implementing the gateway which shall serve several GOOSE ‘mapping paths’. Both distribution of encryption keys and issues related to performance are described below.
The simplest way for distributing encryption/decryption keys among IEDs is to configure them statically on the device. It does not take a rocket scientist to figure out that there are many more cons of this approach than pros. However, one obvious advantage of this method is that it is simple to implement and thus could be used for prototyping and demonstration purposes.
For real life application however, a secure and automated way of key distribution must be used. The task is not trivial because of the nature of the GOOSE communication, involving multicast groups with potentially many nodes publishing or subscribing, which means that keys must be updated for all group participants in a coordinated way. The other challenge is that the crystallographic material must be delivered in a secure way, meaning that only authorized members of the group might receive it, and even if others intercept the communication, it should be impossible for them to determine the keys or temper with them. All these issues are solved by group domain of interpretation (GDOI) protocol which is based on IKE/ISAKMP. In short, each group member establishes secure communication channel with key distribution center (KDC), over which encryption/decryption keys for given group are provided. Normally KCD would periodically update the keys by sending to all active group members encrypted multicast PUSH messages. The details of the whole process are described in IEC62351-9 specification and number of RFCs: 6407, 8263.
Garibaldi tool is an implementation of KDC which handles routable GOOSE and routable sampled value. The product features a web page interface which makes it easy to configure and operate. It is scalable in terms of number of GOOSE / sampled value streams it can handle and implements role based access control (RBAC).
Another area which must be addressed when implementing any solution involving Cybersecurity is handling of certificates. Currently certificates serve different purposes like
In the context of GDOI, certificates are used when exchanging session encryption keys between the KDC and group members to authenticate each side and generating message signatures.
The most popular form of digital certificate is X.509, which contains, among others, details of the entity for which certificate was issued, public key and information about certificate issuer. Certificates are issued for specific time frame, and must be replaced once that time expires or if they are revoked by the issuer, e.g. if the private key is compromised. The challenge for the distributed system is to configure certificates of the nodes and manage their updates when necessary (expiry or revocation). Handling of revoked certificates could be implemented with certificate revocation lists (CRL) or Online Certificate Status Protocol (OCSP). There is no silver bullet here, each approach has its advantages and selection of the right one depends on the requirements of the specific application.
Since GOOSE (and sampled value) is used for delivery of time sensitive data, implementation of L2-GOOSE / R-GOOSE must take into account additional latency introduced by:
Usually the customer asking about GOOSE performance, expects that the delay of GOOSE generation is below 4 milisec. Unfortunately not many of them realize what it does exactly mean and how to measure such delay. For the sake of demonstration of performance of some IEC61850 solution (module or communication) configuration consisting of
could be used. The idea is to send GOOSE messages from the laptop to IEC 61850 device under test (DUT) and setup sample ‘loopback’ application which would receive GOOSE sent by the laptop and immediately trigger generation of its ‘response’ GOOSE, e.g. by updating value of some attribute. After GOOSE sent by DUT is received by the laptop, Wireshark can provide delay between GOOSE sent by the laptop and the response which is coarse and very conservative measure of generation of GOOSE by DUT in response to some event.
For L2 GOOSE / R-GOOSE gateway situation is a bit more complicated because the assumption is that it has to encrypt the message, so there must be another GOOSE subscriber which decrypts the message. For the worst case scenario let’s assume that decryption of the GOOSE message is performed by another gateway device (DUT2) and decrypted message is distributed locally as a L2 GOOSE. Sequence diagram below shows two variants of end to end L2 / R GOOSE conversion, with and without encryption.
You have to be aware that there is also a nondeterministic factor related to the transition of R-GOOSE over IP network, related to the very nature of this communication. For the sake of simplicity, let’s assume that all the devices from the above picture are physically connected to singe switch. The assumption is justified since the goal is to assess the impact of introduction of two gateways (DUT1 / DUT2) which convert between L2 / R GOOSE and implement encryption/decryption.
The tests configuration used for the evaluation was like this:
The table below shows the latency statistics for different scenarios:
The above measurement should give a rough idea about the overhead introduced by encryption and decryption operations. We have to remember that the test was executed on raspberry-Pi 3+ device which does not offer any hardware acceleration for cryptography. However for different architectures there are some options (e.g. AES-NI extension for x86, or ARMv8) offering significant performance improvement which should result in lower processing time.
I wanted to present my take on the issue of deployment of GOOSE protocol with distributed systems. Definitely it is not the only solution possible, and probably depending on the requirements of the specific use case or business cases it might not be the best one. Also the article only covers the issue of protocol conversion and cybersecurity of communication. There are number of other features which could be implemented on gateway used by the power system:
However I hope this is a good starting point, at least for the conversation about the matter, so any feedback is much appreciated. If you are interested in trying evaluation kit feel free to contact me via LinkedIn or email (email@example.com)
Creating, modifying CID and ICD files doesn’t have to be difficult at all! The Hedera application by JPEmbedded allows for the intuitive and smooth generation and modification of SCL format files. Thanks to it, the entire configuration process of an Intelligent Electronic Device (IED) is much simplified. Hedera has been designed to be used by manufacturers of substation automation devices to create an ICD file for their products and by integrators to prepare CID file describing the configuration of each device operating in the IEC61850 network.
Hedera allows to edit, add, delete and configure data model elements such as logical nodes, data sets, buffered and unbuffered reports, or GOOSE messages according to the IEC61850 standard. Thanks to the built-in type library, it is also possible to create a data model from scratch, starting with the mandatory elements and extending it with any logical nodes. The application features data model validation. Messages displayed on the screen guide user when editing the file and inform about the compliance of the file with the standard. Thanks to that, even engineers less familiar with the standard can create and edit files for their IEDs. Furthermore, the tool allows users to upload finished CID files directly to the device.
Additionally, to support customers that use our protocol gateways (i.e. Apis and Papilio), we have integrated Hedera with Drosera (a protocol mapping tool by JPEmbedded). Thanks to this, all operations related to the preparation of the CID file and protocol conversion mappings to IEC61850 can be performed simultaneously, without the need to install additional tools.
If you have any questions or are you interested in the Hedera application, please contact us at firstname.lastname@example.org.
DNP3 and IEC61850 are two competing standards which allow to communicate intelligent electronic devices within substations. At least that was the idea when they started to be specified more than 20 years ago. IEC61850 is more complicated both in terms of functionality it covers as well as for implementation. This could be one of the reasons why DNP3 the beginning gained more popularity especially in the US. However, in the recent years IEC61850 started to catch up and it is getting more and more popular. With a large base of legacy devices already installed and working in the field, the deployment of IEC61850 and related protocols like GOOSE or sampled values may require integration of the two communication standards. There are different ways to approach this task:
Last option (3) is the least invasive one, from the point of view of the manufacturer of the device (IED) which must be integrated with the new standard. Using the gateways offered by JPEmbedded, any device implementing DNP3 protocols could be easily hooked up into the IEC61850 network. It basically boils down to mapping of information provided by the DNP3 device into the data model of IEC61850 server. In DNP3 standard data (states, binary and analog values) are grouped into the arrays of points of specific types:
Each value could be addressed by group number (e.g. 10 for binary outputs) and 0 based index of the point within the specific group. There is also additional parameter called variation, which specifies the data format (e.g. unsigned 16 bit integer, signed 32 bit integer, 32 bit float, 64 bit double precision float) in which the value shall be provided by DNP3 master.
Data model of IEC61850 IED server is a hierarchical structure consisting of logical devices, logical nodes, data objects and attributes. Attributes could be of complex types (structures consisting of other attributes) or basic types like, boolean, integer, enumerated or float values.
So translating between DNP3 and IEC 61850 is about projecting the point, addressed as
grp. num/pt. index
to IEC61850 basic attribute which is specified by its reference in the form:
The table below contains examples of DNP3 to IEC61850 mappings
Each time value of some DNP3 point is changed, the corresponding IEC61850 attribute shall be updated. Information about the change of DNP3 point value could be obtained as a result of continuous polling the values of points which are mapped to the attributes. Other option would be take advantage of DNP3 unsolicited messages, which are generated by the outstation each time the value of the attribute belonging to the specific group (for which unsolicited messages are enabled) has changed.
On the IEC61850 side update of the attribute value might result in generation of MMS report, GOOSE message or sampled value message.
In the other direction IEC61850 control commands could be mapped to mapped to the DNP3 points from group 12 (binary control) or 41 (analog control).
Translating between the two protocols could be quickly and easily done using the Drosera application provided by JPEmbedded. With Drosera app, in 3 simple steps user can configure gateway to do DNP3 / IEC61850 translation:
Once APIS gateway is programmed with correct configuration it will automatically update IEC61850 data model attributes with the values obtained from DNP3 side. Generation of GOOSE and MMS reports is also possible if they are defined by CID file and enabled by the IEC61850 client application connected to the APIS.
If you would like to learn more about our solution or evaluate it, please let us know: email@example.com
We have it! The new, refreshed version of Drosera application for easier and faster configuration of JPEmbedded protocol converters.
Version 2.1. is expanding the scope of functionality by adding support for communication between all available protocols supported by our devices. We have also improved the management of signal mappings such as adding or editing more than one signal mappings at a time with using simple regular expressions.
Using the application has become even simpler and more intuitive thanks to the refreshed interface and a new manual that guides the user step by step through the principles of operation of the available functionalities. In order to prevent possible errors and facilitate their recognition, we have improved the validation of the input data and detailed the error messages to make them understandable for the recipient.
Invariably, the application is free for all our clients. If you are interested to try it please send us a message via firstname.lastname@example.org.
Are you curious? See the movie shortcut of the newest Drosera version in action!
In September, JPEmbedded participated in the IEC 61850 Interoperability Event (IOP) organized by UCAIug in Charlotte. This was a great opportunity to meet several other IEC 61850 vendors and verify if our products can communicate with each other. Being a provider of communication solutions for IED (and virtually any industry domain) the most fundamental feature is to be able to ‘talk’ to other devices in the network. Without this, any other qualities of the product really do- not matter.
At IOP each participant could choose from 20+ other companies and 40+ different equipment or software tools and verify selected functionality in a very friendly atmosphere, where it was ‘OK’ to fail, since the main goal was to improve quality.
JPEmbedded took advantage of this event to verify features related to cybersecurity which seems to be a hot topic nowadays:
Of course we identified some flaws in our implementations (they are already fixed ), but as long as software is created by humans we should still expect some imperfections, and the next possibility to spot them will be at IOP in 2021.
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 email@example.com.
Electricity Exchange is an Irish Utility which has taken a high-tech approach to harness the capacity of unused back-up generators found in hospitals and factories around the country. Its so-called Virtual Power Plant provides reserve power to the national grid. The company has secured back-up generators and designed the state-of-the-art smart grid automation solution. Thus, in the event of a sudden power scarcity that cannot be handled by regular power stations, Electricity Exchange is able to provide the capacity to the national grid to supply up to 150 000 houses.
Electricity Exchange selected secure-ICCP/TASE.2 library by JPEmbedded as a basis of the company’s communications with Ireland’s Transmission System Operator, EirGrid. Inter-Control Center Communications Protocol (ICCP) also known as TASE.2 is one of the standards that defines communication between control centers, utilities and power pools. The standard supports the exchange of real-time data using secured channel.
JPEmbedded’s libraries and some other solutions available on the market were extensively tested before taking a decision favorable to the Poland based supplier.
Reliable communication between our system and EirGrid is crucial for our business. The solution provided by JPEmbedded’s matches all our needs, including data transfer safety, portability, and last but not least, ease of integration with EirGrid’s systems. – says Dr. Paddy Finn, CEO of Electricity Exchange.
JPEmbedded’s Secure-ICCP/TASE.2 library provides a secure connection to the EirGrid, TSO for the provision of real-time power generation data, in addition, to control states and set points that manage the operation of Electricity Exchange’s power generation assets. – adds Dr. Finn.
Electricity Exchange is a smart grid operator and a leading provider of Demand Response Technologies and Services in Ireland. Electricity Exchange developed technology that enables commercial and industrial electricity consumers to generate revenue by supporting the national power grid. The Company operates a Virtual Power Station that pays businesses for making themselves available to support Ireland’s electricity grid when required. Electricity Exchange was founded by Dr Paddy Finn, a finalist in the EY Entrepreneur of the Year 2018 competition, with his business partner Duncan O’Toole. The company is backed by Bord Na Móna, an Irish semi-state company.
JPEmbedded is a tech company offering state of the art products for secure and reliable communication in smart grids. Software solutions include off-the-shelf communication software libraries IEC 61850, IEC 60870-5-10X, and ICCP/TASE.2. The company offers also hardware protocol converters that enable interoperability and allows customers, device manufacturers to connect their devices to the grid effortlessly.
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 firstname.lastname@example.org.
The IEC 61850 Europe is the place to connect with more IEC 61850 experts and the implementation leaders than you’ll find at any other smart grid conference in the world. The event is organized by Phoenix Forums and takes place annually in varying cities all across Europe. The last being in Amsterdam was held in September 2017. We took part in the 3-day event presenting our communication libraries IEC 61850, ICCP TASE.2 and IEC 60870-5-104. A few weeks of work on the preparation of the demonstration set-up, marketing materials and the presentation slideshow. Two sleepless nights, and stress, whether our parcels and equipment would ever arrive in one piece. Happily, all our electronic stuff arrived in Amsterdam safe and sound.
How was the conference itself? It was just perfect! Three days of interesting presentations, case studies (e.g. ‘IEC 61850 engineering process in offshore wind farms’ by Saeed Nemati Yarafi). Hot discussions regarding security standards (e.g. ‘Cyber security for digital substation’ by Cedric Harispuru). Meeting loads of interesting people, establishing both personal and business contacts… Let them flourish over the coming months! If you are working with IEC 61850 standard, this conference is definitely a must for you.
However, if you still have any doubts, I’m listing below the 6 reasons to attend IEC 61850 Europe Conference.
No matter how experienced you are with IEC61850, there’s always something new you can learn. The educational aspect of a first day’s workshop is indisputable. Fundamentals of IEC 61850 workshop (in 2017 it was carried out by Mr. Christoph Brunner, Convenor of IEC TC57 WG10) providing a comprehensive and in-depth insight into the building blocks, key applications, and optimal operations of the standard within the substation environment.
It doesn’t matter if you run a company or manage a single smart grid project only. Participating in such a conference will awaken the creativity within you so as new ideas will appear themselves. IEC 61850 experts continuously exploring on how to apply the standard on the new fields for example by using IEC 61850 in the controling of street lights. Don’t miss the opportunity to be one of the first to hear and implement new ideas and trends that can impact smart grid future!
The current 2nd version of the standard was published in 2012. The IEC 61850 Europe Conference presents and discusses the planned changes to the standard (which are likely to be included in versions 2.1 and 3 of the standard). You can also talk about changes with the members of the Power systems management and information exchange group, the majority of which can be found during this event.
Conference provides a great opportunity to network. Breaking between the presentations and the network reception gives you the opportunity to make new contacts with like-minded colleagues from across the global IEC 61850 ecosystem (i.e. utilities, device manufacturers, certification bodies).
Additionally to the conference, around 20 exhibitors present their products and services. Surrounded by the companies like DNL, TUV Sud, FMTP, Relyum, SAE IT-systems, JPEmbedded presented its IEC 61850 and ICCP/TASE.2 communication stacks for the energy market. For the solution suppliers (such as ourselves), one-to-one private demonstration is also a great opportunity to understand customer’s needs and discuss how to deliver a customized IEC 61850 software solution which fits to the specific use case.
People bring real-life situations that are covered during roundtable discussions. You can ask experts to brainstorm and solve your problem (even if the answer always start with “IT depends…” :)) or you can just help the others face their own challenges. There is no doubt that in both cases at the end of the Conference you will be more experienced than on the first day!