Showing posts with label mapping. Show all posts
Showing posts with label mapping. Show all posts

Saturday, June 6, 2026

Free ASN.1 Browser for IEC 61850-8-3 ASN.1 Module from RTI2 PoC

If you want to browse easily the ASN.1 message schema for the new project IEC 61850-8-3 (DSM) underway, check out this free browser: 


A preliminary asn.1 module for IEC 61850-8-3 (from PoC of RTI2) is available for download:

This is how it looks like:


and ...


The schema is very simple compared to MMS for IEC 61850-8-1.
Let us know if you have any question.

Thursday, June 4, 2026

Extended Video on IEC 61850-8-3 Available - Example Messages

 An extended version of the video on  

IEC 61850-8-3
Communication networks and systems for power utility automation –
Specific Communication Service Mapping (SCSM) –
Mapping to Direct Message Specification (DMS), JSON Encoding Rules, and WebSockets 

is available. I have added some five minutes ... total time is 23 minutes.

I have added mainly two examples of services for IEC 61850-8-1 (MMS) and IEC 61850-8-3 (DMS):


The figure above shows how a client can get the list of logical nodes from the server with MMS ... and with DMS:


Details can be watched in the video ... enjoy.

Saturday, May 16, 2026

IEC 61850 Series for Any Automation Domain using Electric Power (two Examples)

The standard series IEC 61850 is applicable for simple applications and huge systems. The standard is not restricted to a specific domain. Like electric power is everywhere. So could IEC 61850 be everywhere.

I have discussed this briefly in the context of a LinkedIn post.

Now it's time to discuss briefly two simple applications ... just looking at the two models ... without further explanations.

The German FNN Steuerbox

The Steuerbox is mainly providing schedules for the interface between the grid and the power user:


This model is defined for a special use-case: Steuern (remote control). No need for an engineering tool ... it is just a fixed model ...

The Netherlands RTI (Real-Time Interface) for power generation (> 1 MW)


... this is a fixed model with some details:

The RTI models and services are currently using IEC 61850-8-1 (MMS) communication (RTI 1). The RTI 2 will finally use the IEC 61850-8-3 (DMS) once it is specified. A Task Force has started to specify the new standard in May 2026.
The fixed models allow for a high level of interoperability. The central systems (representing the IEC 61850 clients) can communicate with and IED following these specifications. In the case of the FNN Steuerbox it has been proven that the client application could talk to all steuerboxes in the field without paying attention to which vendors device it is talking to.
REAL INTEROPPERABILITY !!

Wednesday, May 13, 2026

Why is there an Need for an Additional Service Mapping in IEC 61850 (IEC 61850-8-3)?

The two service mappings for IEC 61850 are IEC 61850-8-1 (MMS) and IEC 61850-8-2 (MMS/XML). The mapping IEC 61850-8-1 is in operation from the first days when IEC 61850 was implemented and used ... all over ... in millions of devices and thousands of systems. Ok ... perfect.

Why is there an need for an additional service mapping in IEC 61850 (IEC 61850-8-3)? 

Simply because of the complex and tricky mapping to MMS (Manufacturing Message Specification, ISO 9506). 

IEC 61850-8-3
Communication networks and systems for power utility automation –
Specific Communication Service Mapping (SCSM) –
Mapping to Direct Message Specification (DMS), JSON Encoding Rules, and WebSockets 

In order to explain details of the new approach to be used for the new work item proposal IEC 61850-8-3 I have produced a 17 minute video (updated version 2026-06-04, 23 minutes).

It is likely that this will become a major shift in the use of IEC 61850.

Enjoy!

Tuesday, March 24, 2026

The PAC World Magazine Reports From the 30 Year Anniversary of IEC 61850 in September 2025

The 30 year anniversary of IEC 61850 in September 2025 was a big success.

The report mentions me: "The presentations were bracketed by the first one from Karlheinz Schwarz about how all of this started in the past Millenium ..."

I am very thankful for the invitation by Dr. Fred Steinhauser (Omicron) to speak about the history ... 

Click HERE for the Report in the PACW.

Click HERE for more photos and a link to my "Millenium" presentation.

When browsing the Web, I see many more papers, reports, posts, ... on IEC 61850 for substations and for applications beyond substations.

More to come: With IEC 61850-8-3

Wednesday, March 18, 2026

New Work Item Proposal on IEC 61850-8-3 has been accepted by 95 % of the TC 57 National Committees

In December 2025 the NWIP (57/2866/NP - proposed project number: IEC 61850-8-3) was published for voting and comments:
https://blog.nettedautomation.com/2025/12/long-awaited-christmas-gift-for-smarter.html

Today we are happy that the NWIP has been approved by IEC - only one country disagreed in the voting process.

IEC 61850-8-3
Communication networks and systems for power utility automation –
Specific Communication Service Mapping (SCSM) –
Mapping to Direct Message Specification (DMS), JSON Encoding Rules, and WebSockets
 

The result of this work will very likely change the usability of IEC 61850 outside substations.

Stay tuned to follow the progress.

In order to explain details of the new approach to be used for the new work item proposal IEC 61850-8-3 I have produced a 17 minute video (2026-05-13).

Monday, March 16, 2026

IEC 61850: Work-around for MMS

Very interesting paper just published ... presenting a work-around for MMS ;-)

Integration Method for IEC 61850 into Legacy and Modern PLC Systems

I am a little bit surprised ... when I worked for Siemens (Karlsruhe) I published two papers in the year 1991 (35 years ago!) expecting that MMS could be implemented into a PLC:

Click HERE for the paper “Bridging MAP to Ethernet” [PDF, 720 KB, 1991]

Click HERE for the paper “Fieldbus standardization: Another way to go” [PDF, 720 KB, 1991].

Today we know that MMS could be integrated into PLCs ... 

Gateways work always - definitely.

The expected new work on IEC 61850-8-3 (another mapping than to MMS) would change the situation tremendously:

Communication networks and systems for power utility automation –
Specific Communication Service Mapping (SCSM) –
Mapping to Direct Message Specification (DMS),
JSON Encoding Rules, and WebSockets 

Click HERE for more information on the planned project.

Monday, December 15, 2025

Long Awaited Christmas Gift For Smart(er) Grids - IEC 61850-8-3 is on its Way

In order to explain details of the new approach to be used for the new work item proposal IEC 61850-8-3 I have produced a 17 minute video. (2026-05-13)

IEC TC 57 just published a long awaited and crucial new work item proposal: 

57/2866/NP - proposed project number: 61850-8-3

Communication networks and systems for power utility automation –
Specific Communication Service Mapping (SCSM) –
Mapping to Direct Message Specification (DMS),
JSON Encoding Rules, and WebSockets 

Closing date for voting on the NP: 2026-03-06

"IEC 61850-8-3 Ed.1 defines the direct mapping of the client/server services of the ACSI (Abstract Communication Service Interface) defined in IEC 61850-7-2. Direct mapping means that for every abstract client/server service of the ACSI a concrete message schema (for the request and the response) is defined in ASN.1 (Abstract Syntax Notation One). ...

The encoding of the messages according to IEC 61850-8-3 is using the ASN.1 JER (JSON Encoding Rule, ISO/IEC 8825-8:2021). The messages are exchanged through WebSocket (RFC 6455, The WebSocket Protocol). WebSocket is a communication protocol that enables a persistent, full-duplex communication channel over a single TCP connection, allowing both the client and server to send data to each other at any time. This differs from the standard HTTP request-response model, making it ideal for real-time applications."

Please contact your national IEC TC 57 committee for a copy of the NP.

The main differences between IEC 61850-8-1/8-2 and 8-3 are shown in the following table:


and here:


Enjoy!

Click HERE for additional information that discusses the need for a modern messaging solution ...

I look forward to continuing the editing work of this new part of IEC 61850. This closes the circle of my contribution to communication protocols: starting in the mid 1980s with MMS (base for IEC 61850-8-1/8-2) and now (40+ years later) involved in a modern approach using web technologies ... Wow ...

This NP is the result of a Proof of Concept (PoC) initiated and managed by the Netherlands Distribution System Operators (Netbeheer). I played a little role in the implementation of this PoC. The PoC demonstrated the great benefit that can be harvested from the solution!

It is very likely that this part IEC 61850-8-3 (once it is finished) will accelerate the application of IEC 61850 outside the substation domain. I have discussed IEC 61850 outside of substations for many years ... Let me know what you think.

I wish you a merry Christmas and the best for the year 2026.

Monday, February 26, 2024

Mapping of IEC 61850 Models and Information Exchange Services to JSON, HTTP, and MQTT

After I published two sketch videos on IEC 61850 information exchange services and the mapping to MMS, I discuss simple interface options for the last meters between a device that implements the role of IEC 61850 server, GOOSE publisher, and GOOSE subscriber, and the underlying huge world of a myriad of other controllers.

The standard series IEC 61850 and IEC 61400-25 (Wind Power Plants) provide a comprehensive set of standardized information or device models (Logical Nodes, Data Objects, Data Attributes, ...) for a wide range of use cases in the electric power domain (protection, automation, supervision, monitoring, control, ...) and for general applications beyond the electrical world. By the way, tell me where electricity is not a crucial resource in factories, buildings, petrochemical plants, homes, ... it is all over ... required 24/7. These series also comprise information exchange mechanisms like Reporting, Logging, Control, GOOSE, Sampled Values, ... mapped mainly to MMS in IEC 61850-8-1 ... other mappings like mappings to XML and XMPP in IEC 61850-8-2 or MMS, Web Services, IEC 60870-5-104, DNP3, OPC XML DA, ... in IEC 61400-25-4. The most crucial part of IEC 61850 and IEC 61400-25 is the System Configuration Language (SCL, IEC 61850-6).

Many applications use only a very small set of models (a few measurements, control signals, and status signals), a small set of information exchange services, and a simple subset of SCL. Critic comes from experts of various domains: Why do I need to have a complex and comprehensive IEC 61850 stack to implement a simple subset of these standard series? Is there another solution? The wind power plant people developing and maintaining IEC 61400-25 believing that five (5) mappings would help in this regard - really? So, the discussion is still going on. 

A very simple solution has been implemented in various projects: Notation of a subset of the information models and the payload of the messages in JSON. The exchange services could be mapped to various transport mechanisms like MQTT or HTTP ...

This approach would KEEP the models as they are - NO mapping required, just another notation (JSON instead of MMS named Variables etc.). Even SCL could be used.

Whenever there is a need to communicate from a device that plays the role of an IEC 61850 server, GOOSE publisher, GOOSE subscriber, to an underlying (likely simple) device (for the last meters) the decision usually is to use some other communication stacks from a set of 100+ solutions like CAN, Modbus, many fieldbusses, EEBUS, Sunspec, ... and private digital solutions, or even wires only ...

Any of these need to MAP from one standard to another standard, e.g., map MyIED/myMMXU1.Hz.mag.f (measurement of frequency) to register 2246 in one application and to 9817 in another ... hm, that is feasible BUT means a lot of configuration and documentation ... outside the definitions and tools provided by IEC 61850. 

A more reasonable approach would be to use JSON, e.g., to define a DataSet (semantically equivalent to IEC 61850 and MMS) and the report message payload as shown in the figure below:













Please check a couple of blog posts published a few years ago for more details and discussions:

https://blog.nettedautomation.com/2019/07/iec-61850-8-2-versus-iec-61850-8-1.html

https://blog.nettedautomation.com/search?q=mqtt

https://blog.nettedautomation.com/2019/10/iec-61850-for-monitoring-data-private.html

Unfortunately the Beck IPC com.tom Web PLCs with support of IEC 61850, ... disappeared ...
Please let me know your opinion ...

Friday, February 23, 2024

Second Sketch (Video) on Some Basics: The Mapping of IEC 61850 to MMS

IEC 61850 is well accepted globally in the power utility domain. One key issue has always been discussed and criticized: The mapping of the information models (Logical Devices, Logical Nodes, Data Objects ... ) and information exchange services to MMS (Manufacturing Message Specification defined in the standards ISO 9506-1 and ISO 9506-2, developed in the 1980s).

This video (58 minutes) explains the concepts of the mapping to MMS ... ASN.1, ASN.1 BER ... MMS for GOOSE and Sampled Values !?

Click HERE to access the video.

I will continue to produce more sketches (videos) and make them available through Screencast.

I look forward to your feedback.

Enjoy.

Monday, July 20, 2020

IEC Just Published IEC 61850-80-5 Guideline for Mapping Information Between IEC 61850 and IEC 61158-6 (Modbus)

IEC TC 57 Just Published IEC 61850-80 -5 Guideline for Mapping Information Between IEC 61850 and IEC 61158-6 (Modbus)

(57/2250/CD, 166 pages) - closing date for comments: 2020-09-11

Excerpt from the introduction:

"This technical specification provides a guideline to exchanging information between IEC 61850 and IEC 61185-6 (Modbus TCP). Nowadays, industrial field such as distributed energy resource (wind and solar energy, etc.) and condition monitoring, has been exchanging the information from Modbus to IEC 61850 for an effective operation. Although many manufacturers already implemented the Modbus to IEC 61850 conversion device or system, these devices do not guarantee interoperability. Therefore, it requires the consistent and unified information exchange scheme between IEC 61850 and IEC 61158-6 (Modbus).
Modbus over serial line (Modbus RTU) is not part of IEC 61185-6, but is also considered in this technical specification."

Friday, October 4, 2019

IEC 61850 All Over At CIRED Conference 2019-06 in Madrid Spain

I was really surprised to browse through some of the 51 papers presented at the CIRED Conference 2019-06 in Madrid Spain that refer to IEC 61850 !!

Click HERE for the CIRED search engine. Enter "61850" and you will find the links to the 51 papers presented this year that mention IEC 61850 by some means or other.



Unfortunately I don't have time to study them all in detail ... hope to find some time soon.

While searching the web, I found another very interesting paper:

International Electronical Committee (IEC) 61850
Mapping with Constrained Application Protocol
(CoAP) in Smart Grids Based European
Telecommunications Standard Institute
Machine-to-Machine (M2M) Environment

Click HERE for accessing that paper. More to come ...

Wednesday, August 28, 2019

Why Is It So Easy To Map IEC 61850 Signals to JSON Objects?

IEC 61850 defines Device Models for the exchange of information between any two or more entities. The Models are structured as unique branches of a tree.That means:

Each path from the Device (Root) to 
any node or leave of the trees is unique

The signals are composed of an access reference (LDName/LNName.DOI. ...) and the value that corresponds with the path.

Example of two leaves:
LDName/Tran1STMP1.Tmp.mag.f = 23.5 (Temperature value)
LDName/Tran1STMP1.Tmp.units.SIUnit = °C (Temperature engineering units)

These are key-value pairs that could easily map to JSON Objects:

"LDName/Tran1STMP1.Tmp.mag.f " : "23.5"
"LDName/Tran1STMP1.Tmp.units.SIUnit" : °C

These JSON objects are

  • Light-weight
  • Language independent
  • Easy to process with Python, ...
  • Text based and human readable 
  • JSON Schemas could support automatic (syntax and semantic) checks
  • JSON is supported by many controllers
The controller of our PV inverter from Fronius has an http/JSON interface. The following request (lines 1-3) returns many common inverter data (line 21ff):



Lesson learned: Controller in inverter could easily provide an http/JSON interface.

The Device Model is a virtual model that could be configured using the SCL (System Configuration Language, IEC 61850-6). The Device Model is implemented in an IED and could be accessed to get the self-description, read, write, send/receive reports, publish/subscribe, ...

An IEC 61850 Server hosted by an IED could easily map the model to JSON objects that may be communicated with MQTT, HTTP, ...

The mapping to JSON is quite easy. It could be implemented by a simple automatic process that parses the model (SCL/XML), searches for the paths and concatenates the names from the root to the leaves to get the reference! AND: the mapping preserves the semantic - the meaning represented by the path name.

The mappings of IEC 61850 Models to IEC 60870-5-104, DNP3 or Modbus would result in messages that have lost the semantic of the signals. These solutions have mainly numbers as reference - these numbers have no meaning in the communication.

Thursday, October 8, 2015

IEC 61400-25-41 Project Finally Approved

Document 88/567/RVN
Wind turbines - Part 25-41: Communications for monitoring and control of wind power plants - Mapping to communication profile based on IEC 62541 (OPC UA)

This New Work Proposal was finally accepted due to a late appointment of two additional exerts from two additional countries.
Project title: IEC 61400-25-41 TS Ed.1 (Technical Specification)

The focus is intended to be strictly on IEC 61400-25. It will replace the obsolete OPC-XML-DA mapping. No impact on the work on IEC 61850 web technology (Project IEC 61850-8-2) is intended by this NP.

Click HERE for an overview on the IEC 61400-25 series.

Monday, September 21, 2015

Status of IEC 61400-25 Communications for Wind Turbines

The IEC TC 88 JWG 25 has published several draft documents for the second edition of IEC 61400-25:

  • Part 25-1: Communications for monitoring and control of wind power plants -Overall description of principles and models
  • Part 25-2: Communications for monitoring and control of wind power plants -Information models
  • Part 25-3: Communications for monitoring and control of wind power plants -Information exchange models
  • Part 25-4: Communications for monitoring and control of wind power plants -Mapping to communication profile
  • Part 25-5: Communications for monitoring and control of wind power plants -Conformance testing
  • Part 25-6: Communications for monitoring and control of wind power plants -Logical node classes and data classes for condition monitoring

Here are the latest news on IEC 61400-25:

1. New Convenor

Dr Nicholas Etherden from Vattenfall, Sweden is the new Convenor of IEC TC 88 JWG 25 (following Anders Johnsson, Vattenfall).

2. Status of Edition 2 of the different parts

IEC 61400-25-1 CDV in November 2015.

88/539/FDIS
IEC 61400-25-2 Ed.2: Wind turbines - Part 25-2: Communications for monitoring and control of wind power plants - Information models
Approved

88/540/FDIS
IEC 61400-25-3 Ed.2: Wind turbines - Part 25-3: Communications for monitoring and control of wind power plants - Information exchange models
Approved

88/536/CDV
IEC 61400-25-4 Ed.2: Wind turbines - Part 25-4: Communications for monitoring and control of wind power plants - Mapping to communication profile
Approved

IEC 61400-25-5 CDV End of 2015.

IEC 61400-25-6 CDV End of 2015.

88/549/NP(Mai 2015)
Wind turbines - Part 25-41: Communications for monitoring and control of wind power plants - Mapping to communication profile based on IEC 62541 (OPC UA) (proposed IEC TS 61400-25-41)
Rejected
2015-10-09: The NP was finally accepted due to a late appointment of two additional exerts from two additional countries.
Project title: IEC 61400-25-41 TS Ed.1

The standard series IEC 61400-25 offers five different Mappings. The Mapping according to IEC 61850-8-1 (MMS) is the most important mapping when it comes to implementations and applications.

Thursday, June 11, 2015

XMPP - IEC 61850-8-2 Defines Additional Communication Mapping

IEC TC 57 has published a first draft for an additional mapping of IEC 61850 information models and communication messages.

IEC 61850-8-2 (57/1583/CD):
Communication networks and systems for power utility automation - Part 8-2: Specific Communication Service Mapping (SCSM) – Mapping to Extensible Messaging Presence Protocol (XMPP)

Closing date for comments is 2015-09-11

The new mapping defines (relies on) the following definitions:

Service mapping (unchanged)
The abstract (client-server) services of IEC 61850-7-2 are mapped to MMS as defined in the existing IEC 61850-8-1 Ed2.

Message Encoding (new concrete encoding)
The encoding of the messages uses ASN.1 XER (XML encoding rule) – in addition to ASN.1 BER according to IEC 61850-8-1 Ed2. The encoding defines an XML schema – contained in the draft.

Model mapping (unchanged)
As in IEC 61850-8-1 Ed2. This applies to the flattening of the object identification and adding Functional Constraint (FC=ST or MX) in the path name and using “$” for “.”:

Bay5_MMXU1$MX$Hz$mag$i

Underlying Transport (new T-Profile)
The transport (exchange) of the XER encoded messages uses a new approach: using XMPP.

This new transport mechanism and encoding will be used between all kinds of utility Distributed Energy Resource devices and related power management systems, over any communication infrastructure including public networks.

The coming IEC 61850-8-2 can be understood as an (encoding and transport) extension of the existing IEC 61850-8-1.

It is very crucial that most parts of implementations and tools can be re-used! Re-Use is one of the basic approaches used in IEC 61850! Don’t start always from scratch – use what is available and add something.

So, to read the frequency of Bay5 is almost the same .. using the reference
“Bay5_MMXU1$MX$Hz$mag$i”
encoded in ASN.1 BER (IEC 61850-8-1) and in ASN.1 XER (IEC 61850-8-2).

See also example of encoding.

A second document explains the needs and background for an additional mapping:

IEC 61850-80-3 TR (57/1584/DTR):
Communication networks and systems for power utility automation -
Part 80-3: Mapping to Web protocols – Requirements and technical choices

It describes the requirements and the technical principles for a new specific communication service mapping (SCSM) based on Web Protocols.
For more information about the candidate technologies which have been analyzed but not selected as well as about the selection process used for choosing the technology, national committees are invited to consult document 57/1585/INF which is circulated in parallel:

Accompanying document to 57/1584/DTR, Proposed IEC TR 61850-80-3

It mainly describes the technical solutions which have been investigated but finally not selected for the SCSM of the IEC 61850 based on Web Protocols.

  1. IEC 61400-25-4 Annex A (Web services)
  2. DPWS (Devices Profile for Web Services)
  3. REST (Representational State Transfer)
  4. XML messaging over Websocket
  5. ACSI XML Messaging
  6. OPC UA

The finally chosen solution  “MMS XER payload over XMPP as transport” was recognized after several years of work as the preferred solution – especially from a fast time-to-market point of view.

What does XMPP provide?

XMPP (RFC 6120) is a middleware messaging and presence protocol supporting decentralized architectures and provides:

  • Registering resources in publicly reachable servers
  • Resolving resources based on names
  • Security (authentication, integrity, confidentiality) for the communication with the XMPP server

This fits well to the information models defined in IEC 61850.

Monday, May 11, 2015

IEC 61850 meets Fieldbus: Bridge between Profinet and IEC 61850

Industrial automation systems highly rely on many different fieldbusses – one of the crucial Ethernet-based fieldbusses is the Profinet IO (defined in IEC 61158). IEC 61850 is THE standard for information modeling, information models, system and device configuration, soft-realtime communication (GOOSE and SV), and SCADA communication (event reporting, control, exchange self-descrition online from device, logging, statistical and historical statistical information, alarms, ….recording).

Information exchange between (1) power system protection and automation in power transmission, distribution, and power generation (central and distributed) and (2) industrial automation systems is one of the crucial needs for energy efficiency and smart(er) grids.

A new bridge between the two domains is now offered by HMS (gateway SG-40): bridging Profinet to IEC 61850.

HMS – a Swedish based company with 370 employees worldwide – has delivered products integrated in millions of devices around the world.

Key features of the SG-40 Profinet Gateway are:

  • Web based programming with predefined function blocks
  • Optional IEC61131-3 compliant CODESYS softPLC programming 
  • PROFINET IO slave
  • Additional industrial Ethernet networks supported with Anybus technology
  • Modbus TCP client
  • Modbus RTU master
  • IEC61850 client/server
  • IEC60870-5-104 server
  • OpenVPN client
  • Integrated firewall

The family of the smart grid supporting devices offered by HMS comprises the following the device types (for many different applications):

image

Click HERE for more information you can find at the HMS website.

The SG-40 supports a variety of mappings between several protocols:

1. IEC 61850 device information mapped to Profinet IO to expose IEC 61850 information to the industrial automation world:

image

2. Profinet IO information mapped to IEC 61850 device information to expose fieldbus information to the power delivery automation IEC 61850:

image

3. Many other mappings are supported (to/from Modbus, IEC 60870-5-104, DNP3, …).

All signals can be mapped in both directions.

The SG-10, SG-11, and SG-40 devices are using a Web-Browser for a very simple graphical programming tool. No other tools – except Web-Browser – are needed.

A 15 minute video explains the basic concepts of the gateways SG-10, SG-11 and SG-40. These devices provide a highly standardized and easy approach of bridging signals between multiple standard information exchange systems.

The configuration of the devices is very simple … no tool other than a web browser is needed to configure the input and output signals coming from (going to) the devices connected to various communication systems.

The devices can play one or all roles of IEC 61850 (Server, Client, Publisher, or Subscriber) in parallel. This allows to “collect”, e.g., many signals from a substation as a client and expose them into a Profinet network; or “collect” signals from the Profinet slaves and master and map them to an IEC 61850 Server.

This allows a very short time-to-market integration of the information of power related information into the industrial automation and vice versa.

One key-point is: The standard series IEC 61850 is the ONLY standard that offers a very comprehensive information model for all crucial power delivery system needs!

Monday, August 4, 2014

MMS & ASN.1 & XER & XMPP selected as the second SCSM of IEC 61850

The second SCSM for the ACSI Client-Server information exchange service models will be the mapping of the ACSI service models to MMS ASN.1 XER and XMPP. IEC TC 57 just released the 122 page document 57/1497/DC:

Draft IEC 61850-80-3 TR, Communication networks and systems for power utility automation – Part 80-
3: Mapping to web protocols – Requirement analysis and technology assessment

The document mainly lists the crucial needs and why the mapping to “MMS ASN.1 XER and XMPP” has been chosen to be published as IEC 61850-8-2 soon.

Chapter 7 presents the future SCSM 8-2, including an overview of the main selected technology: XMPP.

The following goals have been particularly considered for the definition of this SCSM:

  • Identify a single profile supporting all the services required by the domains and defined today in ACSI.
  • Cover the full life cycle of a IEC 61850 system, in collaboration with the System Management work in WG10 (from configuration, through conformance testing, down to maintenance). For this purpose, the present document may recommend some changes in other parts of IEC 61850 like part 6, part 10, etc.
  • Deploy cyber-security to ensure a secure environment (in conjunction with IEC TC 57 WG 15 work).
  • Propose rules for cohabitation with other mappings such as IEC 61850-8-1 and IEC 61850-9-2, and possibly recommend communication profiles depending on specific application context (pole-top equipment, inside DER, connection of DER, …).

Check with your national IEC TC 57 mirror committee for a copy of the above mentioned document.

Congratulation for the tremendous success of the web service mapping team!!! Great work!

That means: IEC 61850 will be the preferred solution in substations and many applications outside!!

Wednesday, May 22, 2013

Semantic Models of IEC 61850 raise Interest in OPC UA Domain

One of the first true international standards in the domain of automation that defines rich semantic models is IEC 61850: LogicalNodes containing DataObjects containing DataAttribues … etc.

Example:

image

IEC 61850 models of all almost all application domains have been converted to UML (Enterprise Architect). The interest in the many crucial semantic models of IEC 61850 is growing all over!

From the UML representation of the IEC 61850 based class-models it is now possible to generate OPC UA Address Spaces!

UMLbaT—UML based Transformation

UMLbaT is an extension, a so-called Add-In, for Sparx Enterprise Architect. The Add-In is an advancement of existing CIMbaT (CIM based Transformation). With CIMbaT it is possible to generate OPC UA Address Spaces from CIM based class-models. Now, with UMLbaT, it's also possible to create OPC UA Address Spaces from IEC 61850 based class-models.

Visit the UMLbaT website (OFFIS Oldenburg) to get more details on the transformation.

Usually the various fieldbus consortia define fieldbus-specific “models” … not allowing interoperability at semantic level between different fieldbusses. IEC 61850 semantic models could now be accessed by MMS (as defined in IEC 61850-8-1) and OPC UA. The mapping of IEC 61850-7-2 ACSI to OPC is under discussion and may be published as IEC 61850-8-2.

In the mid 90s we had already a document IEC 61850-8-2 (SCSM: Mapping to Profibus FMS). See also discussion on further mappings in IEC 61400-25-4.

Let me know what you think about the transformation. Thanks.

Thursday, April 4, 2013

IEC 61850 as a kind of template for Modbus based SunSpec Standard

The standard IEC 61850 has influenced other groups defining domain specific standards like IETF EMAN (Energy Management) and SunSpec Alliance. I have reported on the IETF EMAN group in March 2012. The SunSpec Alliance is new to me. So I browsed a bit their website and figured out that they have “copied” parts of the IEC 61850 information models, remodeled them and mapped them to Modbus registers.

Example: The electrical measurements from logical node MMXU (right) have been used by SunSpec (smdx_00101.xml) to some extent:

clip_image001

Unfortunately the names are slightly different! “PPV.phsAB” in IEC 61850 and “PPVphAB” in sunspec … I would have expected that the names (that carry the semantic) are the same! This would make the mapping between the two worlds much simpler --> reducing the costs …

clip_image003

Path could map to the following Modbus address (as an element inside the value … using the SystemCorp IEC 61850 stack/API):

clip_image005

The mapping of the IEC 61850 model to Modbus could be easily specified in the corresponding SCL file as Private Elements!! This could even be done automatically if the models (the names and semantic) in both standards would be equivalent!! Then a gateway device could offer both protocols (IEC 61850 and Modbus) running at the same time using a SINGLE specification file!

IMHO this is putting some soft pressure on IEC 61850 community! Why? Because why are the vendors implementing SunSpec not using IEC 61850 (the mother of SunSpec … to some extend)? One reason seems to be that it is not easy (and not for free) to get the models for PV applications. Another issue is that the implementations of IEC 61850 stacks/APIs are in some cases too expensive for these vendors.

Fortunately there is a solution available that provides a full set of services and support of any model specified in SCL notation: The SystemCorp Stack/API. There is a free of charge IEC 61850 DLL (for server and clients) available that runs for six months … enough time to evaluate the solution.

With the approach shown above we have implemented a device that is configured by SCL and that runs an IEC 61850 server AND an IEC 60870-5-104 slave at the same time (running on Beck IPC com.tom)!

Please come by at the booth 45/1 in Hall 13 at the Hannover Messe next week.