Started the Year 2016 successfully with the Omicron IEDScout 4.10

I hope you had a good start into the year 2016!

During the last days of 2015 and the first days of 2016 I have set up a new notebook and upgraded to Windows 10, Office 2013, ... and Omicron's IEDScout 4.10.

I had to test a control model with operate services. The version 3.0 was very confusing in getting me the information I was looking for. So I decided to upgrade immediately to version 4.10.

This was one of the best decisions of the "young" year 2016!

The version 4.10 is way easier and less confusing to be used for testing real products! The model shows exactly what is crucial for the tester:

This version is an IEC 61850 tool - not just a MMS browser with some flavor of IEC 61850.

Here is the link to the page for free downloading of the fully functional demo version:

https://www.omicronenergy.com/en/products/all/secondary-testing-calibration/iedscout/noc/1/#Description

If you are looking for a professional IEC 61850 Browser and testing tool: The IEDScout is exactly what should test and consider to purchase.

So, the second day of 2016 was already a successful day here in my office. More to come.

I look forward to helping you to get the right education and tools.

What if Remote Control Fails?

The year 2015 is almost over ... here in Karlsruhe (Germany) we are just 13 h and 13 min away from 2016. Have you looked back to the many lucky and bad situations you have experienced or you have seen during the year 2015?

I guess we all understand that we need more serious engineers that take care of the many processes and systems we need in our modern life. Our generation sees a lot of good solutions going away ... replaced by modern technologies. There is a need to use more communication systems to keep the lights on, the grass green and the sky blue.

Volkswagen has demonstrated that adaptive closed loop control can take the situation (in which a car is) into account and react in different directions - to the good of the company and share holders ... not to the good of the environment.

I have just seen what happens, when a control system does not take the situation into account: The locomotive at the end of a long multiple unit train did not stop pushing when the driver of the leading locomotive decided to stop. The wireless communication to carry the stop-command via a radio channel failed to reach the control system of the locomotive at the end of train.

Click HERE to see how the spinning wheel dug into the tracks ... for hours I guess. The control system did not check the speed which was zero for hours and did not automatically stop the wheels spinning. Obviously there was a use-case that was not taken into account: What to do when the stop command does not make it through to the locomotive at the end of the train?

At the door steps to 2016 I wish everybody reading this post a successful year 2016 ... helping to keep the power flowing.

Approved by IEC TC 57 -- IEC 61850-90-8: Object model for electric mobility

IEC TC 57 has approved the draft TR IEC 61850-90-8: Object model for electric mobility

All member countries have voted: Yes!

Congratulations to the IEC TC57 WG17

Check some details of the draft HERE.

The Year 2015 Comes to an End Soon

I wish every visitor of this blog a very nice rest of the year and the best for 2016 – health, peace, success, and a safe place to live and work ...and 24x7 electric power!

To anyone that is not feeling well I hope that you get well very soon. To those enjoying good health good conditions may you continue to do so.

May next year bring plenty of IEC 61850 work: in the standardization, during implementation, in applications, and in education.

Please let me know if you have anything you want me to publish here.

IEC 61850 and DNP3 linked together

IEEE approved: 1815.1-2015 - IEEE Standard for Exchanging Information between networks Implementing IEC 61850 and IEEE Std 1815(TM) (Distributed Network Protocol - DNP3)

The objective of this Standard is to document and make available requirements for exchanging data between IEEE Std™ 1815 and IEC 61850 protocols using a gateway. While a primary focus of this Standard is for the electric utility industry, other industries that deliver energy and water could also use this document if they also plan to use both IEEE Std 1815 and IEC 61850 in their systems...

Click HERE for more information.

Gateways between IEC 61850 and other protocols are provided by HMS:

Supporting: IEC60870-5-104 client/server and Modbus TCP client/server & RTU master/slave protocol stacks. Additional industrial automation standards like Profinet, Profibus, EtherNet/IP or metering protocols like M-Bus.

DNP3 is coming soon.

IEC 61850: THE crucial standard for Power Delivery System at EDF

PennWell Corporation reported earlier this year:
French utility giant EDF uses IEC 61850 for more than the standard's usual communication applications. Working with Schneider Electric, EDF has embraced a new approach for application modeling with IEC 61850 at its core.

For designing wind farms and photovoltaic (PV) systems, EDF employs this approach as early as the requirements-gathering level. The approach echoes one encouraged by Schneider Electric for using IEC 61850, an ambition the company translated into software engineering tools.

With its new approach to engineering smart substation automation systems, EDF places information flow at the center of project engineering. …

Any person or machine at EDF can read and understand that common language. The language enables information exchange among devices, people, departments, organizations, generations of stakeholders and the components and people involved in projects and systems.

… EDF's approach, based completely on the IEC 61850 standard, allows the capture of unambiguous requirements in a formal way.

Click HERE to read the full article.

More to come.

LAT (Lab Acceptance Tests): Open Systems in Automation – Quo Vadis?

Open Systems in Automation are more than a hype. Since the early 80s we have seen a lot of activities to define Open Systems for Automation. The first major project was the MAP project initialized by General Motors: Manufacturing Automation Protocols. One of the crucial standards developed in this context was MMS: Manufacturing Message Specification (ISO 9506).

When people were struggling with the implementation of 7-Layer or 3-Layer solutions including MMS some other groups believed that Fieldbusses would be the better approach. The standardization of fieldbusses come up with tens (or even tons) of different solutions under one IEC standard series: IEC 61158 with 50+ solutions.

How to build Open Systems in Automation based on this many solution? There are too many islands of very specific open systems based on special fieldbus solutions. This was one of the real reasons why people developed OPC to bridge the gap between these many islands. OPC has helped to share information between islands.

There was another issue that causes increasingly headaches: the System Configuration and Engineering. How to solve this challenge? The next wave was to standardize incompatible “integration” support solutions: FDT (Field Device Tool), EDD (Electronic Device Description) or FDI (Field Device Integration). So: What now?

Endress+Hauser has started recently a very interesting approach:

Open Integration Partner program for practical testing of multi-vendor automation topologies

The focus is on Hart, Profibus, Foundation Fieldbus, Ethernet/IP, and Profinet, as well as on FDT, EDD or FDI.

What are they proposing: “Open Integration validates the interplay of all products in a reference topology by mutual integration tests.” in a permanent lab environment.

Click HERE for a brief description in English.
Click HERE for a brief description in German.

That means: To run a comprehensive permanent “LAT” (Lab Acceptance Tests). This is something prior to “FAT” (Factory Acceptance Tests) and “SAT” (Site Acceptance Tests). Vendors involved are: Endress+Hauser, Auma Riester, Hima Paul Hildebrandt, Honeywell Process Solutions, Mitsubishi Electric, Pepperl+Fuchs, Rockwell Automation, R. Stahl und Schneider Electric.

What about “Open Systems” and IEC 61850? The power industry has understood that Interoperation Tests are very crucial to improve the standards and products. Several IOPs (Interoperability tests) – or better “LAT” (Lab Acceptance tests) – have been conducted. The last one in October 2015 in Brussels.

I hope that some companies and organizations in the Power Industry will also implement such permanently available “LAT” (Lab Acceptance Tests) that would offer 24x7 support services to the power industry.

The challenges in the power industry are lower than in the industrial automation: Because we have (luckily) a single standard series that comprises:

1. Device communication (real-time and SCADA protocols)
2. Device Information Models (e.g. MMXU for electrical measurements)
3. System Configuration Language (SCL) for engineering of Systems, Models, Device, Communication … and their Configuration

In case you would be interested to join such an effort related to IEC 61850, IEC 61400-25, and IEC 60870-5-104, let us know:

Contact us if you have something to contribute.

Vorträge des Workshops "Common Information Model (CIM) in der Praxis"

Die DKE hat am 14. Oktober 2015 einen Workshop zum Thema "CIM in der Praxis" durchgeführt. Die Beiträge (alle in Deutsch) stehen jetzt zum Download bereit:

• Einleitung und Übersicht (Dr. Heiko Englert, Siemens)
• Herausforderungen im Alltag des Netzbetriebes I (Jörg Brand, Westnetz)
• Herausforderungen im Alltag des Netzbetriebes II (Stephan Siegler, Amprion)
• Lösungen aus CIM-Sicht: ein Überblick der konkreten Anwendungen (Dr. Tatjana Kostic, ABB)
• Was ist CIM? (Rainer Rüdiger, Siemens)
• CIM-Modellierungsbeispiel (Henriette Zöller, Siemens)
• Normung und Lifecycle von CIM (Dr. Mathias Uslar, OFFIS)
• Positionierung von CIM im Vergleich zu IEC 61850 (Thomas Rudolph, Schneider Electric)
• Tiefer in die Materie – die CIM-User Group (Rainer Rüdiger, Siemens)
• Der Weg zu CIM: Datenmodellierung Leittechnik, (Dr. Mathias Uslar, OFFIS)

Viel Spaß beim Studieren.

IEC 61850 DLL Demo with Looging and Log-File

The DLL Demo based on SystemCorp’s IEC 61850 Stack/API can very easily be configured with the corresponding CID-File for the Server to log data attributes listed in a DataSet. The log entries are stored in an XML file.

All you need to do is: Add the following 3 lines in the configuration file (after line 52):

Directory: /Resources_localhost (/Resources_2machines)
File: /VHPServer_localhost.icd (/VHPServer_2machines.icd)

<LogControl datSet="BHKW_ST1" intgPd="0" logEna="true" logName="DLLDemo" name="DLLTestLog">
    <TrgOps dchg="true"/>
</LogControl>

Restart the Serer and you have a log that is filled with events coming through the DataSet "BHKW_ST1".

Model as seen by an IEC 61850 Client (Browser):

The file format (DLLDemo.Xml) is vendor-specific:

Two Log Entries (4 and 5):

Note: The time stamp “t” is “000…0” because the Server application program is not providing it to the Stack … this could be done by extending the C# application source code that comes with the Demo package … if you are familiar with C# programming.

The services QueryLogByTime and QueryLogAfter will be available in the future.

The Log Model is available in the SystemCorp Library. It means, e.g., it is available in devices like the HMS SG line. The log file may grow very fast … be careful not to consume all memory resources. In the future the file will represent a circular buffer so that it will never overflow (by overwriting the oldest entries – as defined in IEC 61850-7-2).

There is a possibility to convert the XML coded Log file into another XML based file: COMFEDE („Common Format for Event Data Exchange") published by IEEE.

Click HERE for Information on COMFEDE (DE).
Click HERE for Information on COMFEDE (EN).

Click HERE if you are interested to download the DLL Demo.

HMS offers also Gateways from Profibus and EtherNet/IP to IEC 61850 an IEC 60870-5-104

The Anybus SG-gateway family is designed for use with Smart Grid applications such as, control of electrical equipment, metering applications and with the bridging of Industrial Networks with the Power Grid.

The Anybus SG-gateways were originally developed under the HMS's Labs Initiative, known as "Labline". Now that the gateways have been finalized they are currently under the transition of moving under the "Anybus" brand name. The product remains unchanged - just labels and product color and web interface are in the process of update. Until Jan 2016 they are available as the "Labline" brand.

The SG-gateways support IEC61850 client/server, IEC60870-5-104 client/server and Modbus TCP client/server & RTU master/slave protocol stacks. Additional industrial automation standards like Profinet, Profibus, EtherNet/IP or metering protocols like M-Bus are also available in some models. 

Click HERE for more details.

ENTSO-E publishes November 2015 news on IEC 61850

ENTSO-E seems to be quite happy with:

1. the level of interoperability many different vendors’ subsystems to be applied within the TSO system management architecture.
2. the status of the standardization within IEC TC 57 WG 10, WG 17 and WG 18.

ENTSO-E just published a brief report on the

IOP 2015, organized by UCA International User Group (Iug) in Brussels, Hotel Crowne Plaza, 26.9-2.10

IEC TC57 WG10(-17-18) meetings, hosted by and at ENTSO-E premises, Brussels , 5.-9.10.

Click HERE to read the summary on the two events.

Question & Answer: What is the IEC 61850 EntryTime?

EntryTime is, e.g., used for IEC 61850 Log Entries to identify when a log entry has been stored.

Here is a Log Entry (encoded as an XML document):

<JournalEntry Entry="26" Day="11647" ms="19228670" Order="0">
  <Variable Tag="ServerIEDExample/CSWI0$ST$Pos$stVal">
    <BitString>00</BitString>
  </Variable>
  <Variable Tag="ServerIEDExample/CSWI0$ST$Pos$stVal|ReasonCode">
    <BitString>08</BitString>
  </Variable>
  <Variable Tag="ServerIEDExample/CSWI0$ST$Pos$q">
    <BitString>0000</BitString>
  </Variable>

The IEC 61850 EntryTime is mapped to MMS TimeOfDay:

The MMS TimeOfDay epoch began at 0 hours on 1 January 1984 (MJD 40 587). Times measured are designated in this standard as MMS TimeOfDay milli-seconds GMT and TimeOfDay days GMT, and represent offsets from the epoch.

How to translate the above time to date and time?

Day translates:
http://www.convertunits.com/dates/from/Jan+1,+1984/to/Nov+21,+2015

Date difference from Jan 1, 1984 to Nov 21, 2015
The total number of days between Sunday, January 1st, 1984 and Saturday, November 21st, 2015 is 11,647 days.

Milli-second translates:
https://www.unitjuggler.com/convert-time-from-ms-to-day.html?val=19228670

~=  5 hr. 20 min. 28 sec. 670 ms

Saturday, 21st November 2015 05:20:28:670

It is that easy.

By the way, the above log is generated by the SystemCorp Stack/API by simply adding three (3) lines in an CID File (in this case for the Smart Grid Gateway of HMS supporting Modbus, M-Bus, Profibus, Profinet, EtherNet/IP…):

<LogControl datSet="GooseDS" intgPd="0" logEna="true" logName="ServerIED" name="TestLog">
    <TrgOps dchg="true"/>
</LogControl>

Stay tuned for more features.

Coordinated Universal Time (UTC) to retain “leap second”

For some time experts discuss the need of “leap seconds” that require very smart time management services to follow the number of leap seconds added from time to time. Leap seconds are added periodically to adjust to irregularities in the earth’s rotation in relation to Coordinated Universal Time (UTC), the current reference for measuring time, in order to remain close to mean solar time (UT1). A leap second was added most recently on 30 June 2015 at 23:59:60 UTC.

Do you know how many leap seconds have been added since UTC became a standard? Hm, your IEC 61850, IEC 60870-5-104, DNP3 devices and SCADA systems need to know it. Otherwise the time synchronization is more or less useless. 26 leap seconds have been added … and nobody knows when the next will be added.

Several experts have requested to get rid of the leap seconds … ITU decided to study the issue in more detail and come back to discuss the issue in 2013.

Click HERE for a report from ITU.

Click HERE for background information.

Question & Answer: Are “valKind” and “valImport” related?

The configuration of systems and IEDs with IEC 61850 tools (system tools, IED tools, protocol stacks) is a challenge for people involved in power system protection, monitoring, and automation.

I guess that you have some experience with the many rules and the underlying philosophy that are crucial for the correct operation of interconnected IEDs.

Quite often it is obvious how to apply a given rule in the configuration language (IEC 61850-6 SCL). First of all: You have to take into account the standard document AND the green tissues!

Example on the relation between “valKind” and “valImport”. Tissue 804 introduces the new attribute “valImport” in an SCL document:

http://tissue.iec61850.com/tissue/804

The need for that “valImport” attribute is discussed at the bottom of the tissue 804. The solution is well defined.

The two attributes can be applied for data attributes configured in an SCL file. There are two different categories of data attributes:

1. Models of “process” related information, e.g., scale factor of an Integer modeled measurement.

2. Models of “communication service” related information, e.g., Trigger options or integrity period of a report control block.

If in a SCL document (SCD) the process related values (e.g., scale) SHALL be fixed, these values must be set and declared as fixed. It is not allowed by an IED tool nor online to change these (fixed) values: Here are the corresponding attribute settings (valKind=RO AND valImport=false).

We have to be careful with rules (not defined in the standards) like the following:

If valKind=Set THEN valImport=true (if I can overwrite a value with a service, it makes sense to allow to configure a value at tool level; it may be useful for communication service related information of a control block, but not for process related information).

Be careful with the combinations of these two attributes … they are independent of each other. And: Not all tools may understand the philosophy below.

Viertes IEC-61850-Seminar in Deutsch – Karlsruhe (02.12.-04.12.2015)

Sie haben jetzt wieder die Möglichkeit, ein dreitägiges (deutschsprachiges!) Intensivseminar mit Theorie und viel Praxis in Karlsruhe zu einem

***unschlagbar günstigen Preis*** von NUR 790,- Euro (netto) zu buchen!

02.-04. Dezember 2015 (Karlsruhe)
11.-13. Januar 2016 (Karlsruhe)
07.-09. März 2016 (Karlsruhe)

Die NettedAutomation GmbH hat seit 2003 weltweit über 200 Seminare (mit nahezu 4.000 Teilnehmern) für IEC 61850 und IEC 60870-5-104 durchgeführt.

Das Interesse an Seminaren und Trainingskursen im deutschsprachigen Raum ist so groß, dass NettedAutomation im Dezember 2015 den vierten Trainingskurs in Deutsch anbietet.

Am ersten Tag wird ein Überblick über das Normungsumfeld und die einzelnen Normen gegeben. Im Mittelpunkt stehen dabei die grundlegenden Eigenschaften und Bedeutung der Normenreihe IEC 61850 für Engineering, Datenmodellierung, Datenmodelle, Kommunikationsmöglichkeiten, Sicherheitslösungen sowie deren internationale Umsetzung und Akzeptanz.

Am zweiten und dritten Tag werden Details behandelt und mit praktischen Übungen an realen Geräten begleitet. Ein Teil der eingesetzten Lösungen und Werkzeuge können auch nach dem Training weiter verwendet werden. Es wird vor allem die Frage behandelt: Was bedeutet der Einsatz dieser Normen für Hersteller von Geräten und Systemen, für die Systemintegratoren und für die Anwender?

Anmeldeunterlagen:
http://www.nettedautomation.com/download/Sem/ka15/Public-Seminars_Netted_R0-4_2015-08-17_DE.pdf

Proxy and Gateway Approach of IEC 61850

A Proxy Server in the sense of IEC 61850 exposes the very same information models of many IEDs through a Server that uses the same Logical Device/Logical Node names (references) as in the IEDs that are “mirrored” or “proxied”.

There is no difference in the meaning and syntax between the models in the various IED Servers and the Proxy Server.

The general gateway approach is quite different. I a gateway we are free to manage information like:

1. Translate data from legacy protocols such as IEC 60870-5-103, IEC 60870-5-104, IEEE 1815 (DNP3), IEC 61158-6 (Modbus), etc. into IEC 61850 data model
2. Add data local to the IED hosting the Proxy/Gateway
3. Rename logical devices coming from IED level into logical device server
4. Rearrange/Rename logical nodes coming from IED level into logical device of the Proxy/Gateway server
5. Merge of two or more information objects coming from two or more different logical nodes at IED level into one logical node of the Proxy/Gateway server
6. Split of information objects coming from one logical node at IED level into two or more logical nodes of the Proxy/Gateway server where each logical node contains a subset of the information objects of the original logical node
7. Transform a generic information object (e.g. GGIO, GAPC, etc.) at IED level into a semantically defined information object of the Proxy/Gateway server
8. Convert a specific information object (e.g. MMTN) at IED level into another semantically defined information object (e.g. MMXU) of the Proxy/Gateway server
9. Adapt the scale, information encoding and dead band configuration between the IED data object and the data object in the Proxy/Gateway server
10. Logical (e.g. and, or, if/else, grouping of indications, etc.) and arithmetic (e.g. multiplication, division, addition, subtraction, etc.) transformations between one or more data objects at IED level and one or more data objects of the Proxy/Gateway server

Real IEDs may have gateway and proxy functions.

Click HERE for very simple and easy to use proxies and/or gateways for IEC 61850, IEC 60870-5-104, Modbus, Profibus, Profinet, … offered by HMS. These can be understood as Micro-RTU …

Substation to Control Center Communication: IEC 61850-90-2 TR Approved

The draft Technical Report for Substation to Control Center Communication has been approved by 100 %:

IEC 61850-90-2 TR:
Communication networks and systems for power utility automation - Part 90-2: Using IEC 61850 for the communication between substations and control centres

The final Technical Report will be published in December 2015. It provides a comprehensive overview of the different aspects that need to be considered while using IEC 61850 for information exchange between substations and control or maintenance centres or other system level applications. In particular, this technical report:

• defines use cases and communication requirements that require an information exchange between substations and control or maintenance centres
• describes the usage of the configuration language of IEC 61850‑6
• gives guidelines for the selection of communication services and architectures compatible with IEC 61850
• describes the engineering workflow
• introduces the use of a Proxy/Gateway concept
• describes the links regarding the Specific Communication Service Mapping (SCSM)

The wait for the application of IEC 61850 for information exchange between substations and control centers is over – starting in 2016, there is no excuse any more.

The scope of the TR is quite limited: Substation (only!) to control centers. The future energy delivery system (in which power is one aspect only) will build a hierarchy of aggregated information systems. There will be several layers of information management systems. This is required because of the use of IEC 61850 from power distribution all the way up to the transmission system operator. Information needs to be aggregated because of the sheer unlimited amount of information generated and consumed in the system.

It is likely that the TR 90-2 will be used for other vertical information flows between aggregation points and higher level systems. A subset of the TR 90-2 may be used for information exchange between a control center and a wind power plant.

The restricted scope in the TR 61850-90-2 is just toner on paper – like in almost all IEC 61850 parts. A server in the sense of IEC 61850 can expose any data from any application. IEC 61850 relies on ISO 9506 (MMS – Manufacturing Message Specification). As the name says: MMS (and IEC 61850) can be used for manufacturing and many other domains.

The main scope of IEC 61850 is constrained by the title: “… for power utility automation”. From a technical point of view we could leave only “… automation”:

“Communication networks and systems for automation” – BUT this would never be accepted by the IEC officials. Automation as such is not the scope of IEC TC 57.

MMS is not restricted to “Manufacturing” and IEC 61850 is not restricted to “power utility automation”.

German Standardization Roadmap Industrie 4.0 (Version 2)

Several groups within Germany have written a 70+ page Standardization Roadmap Industrie 4.0 (Version 2, Oct 2015). The document lists a lot of topics relevant for standardization related to the future industrial automation. It contains a lot of issues that “should” or “must” be considered in the standardization of the future.

I was a bit surprised that the industrial automation world seems to lack of many basic standards that would support interoperability and inter-workability. Guess the authors have understood that the myriad of fieldbusses seems not to solve the needs for the future automation process – fieldbusses lead to many islands that can not talk together.

The power world has decided already some 20 years ago to build the foundation of interoperable systems based on a well defined huge “dictionary” of semantic terms (the hundreds of logical nodes for almost all power domains).

With IEC 61850 we change from “bits” to “well defined terms and messages”:

All the messages exchanged could be based on a well standardized semantic, like the temperature supervision model “STMP”: Trip =  “STMP1.Trip.stVal” or the current temperature = “STMP1.Tmp.mag.i”.

The various layers are shown in the following figure:

These values can be reported by a DataSet and a GOOSE message (in real-time … in some 3 to 5 msec):

The smart grid efforts within IEC are tremendously supported by IEC TC 57 … especially with the standards series IEC 61850. This series is part of the “IEC smart grid standards roadmap”.

This roadmap has really attracted the Industrie 4.0 supporters! They write in their roadmap:

“Empfehlung, eine Normenlandkarte (standardisation map) für Industrie 4.0/Smart manufacturing elektronisch zu beschreiben. Die Normenlandkarte wird ein im Vergleich zum Smart Grid Mapping Tool (http://smartgridstandardsmap.com) äquivalentes elektronisches Werkzeug darstellen.”

They recommend to “copy” the “IEC smart grid standards roadmap” and name it “IEC Industry 4.0 / Smart Manufacturing Roadmap).

Click HERE to see the IEC smart grid standards roadmap.

Click HERE to access the Standardization Roadmap Industrie 4.0 (Version 2, Oct 2015, German only).

I hope that they will “copy” more than just a roadmap … refer to IEC 61850 some time down the road.

By the way: HMS is bridging the semantic-less fieldbusses to the semantic defined in IEC 61850 …

http://www.hms-networks.com/about/labs/smart-grid/labline-sg