Thursday, November 26, 2015

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:

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)

image

<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):

image

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

image

Two Log Entries (4 and 5):

image

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.

Tuesday, November 24, 2015

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. 

image

Click HERE for more details.

Monday, November 23, 2015

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.

Saturday, November 21, 2015

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.

Thursday, November 12, 2015

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.

Sunday, November 8, 2015

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

Saturday, November 7, 2015

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”.

Wednesday, November 4, 2015

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”:

image

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:

image

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

image

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