Friday, May 19, 2017

Data And Communication Security for MMS is Speeding Up

IEC TC 57 is about to accelerate the publication of a new Standard on Security:
IEC 62351-4 ED1 (57/1860/CDV):
Power systems management and associated information exchange -
Data and communications security -
Part 4: Profiles including MMS
Closing date for voting: 2017-08-11

The current part 4 is just a TS (technical Specification). The need for a definitive solution for secure MMS communication is at hand.

"Scope
This second edition of this part of IEC 62351 substantially extents the scope of the first edition [KHS: TS only!]. While the first edition primarily provided some limited support for authentication during handshake for the Manufacturing Message Specification (MMS) based applications, this second edition provides support for extended integrity and authentication both for the handshake phase, and for the data transfer phase. In addition, it provides for shared key management and data transfer encryption and it provides security end-to-end (E2E) with zero or more intermediate entities. While the first edition only provides support for systems based on the MMS, i.e., systems using Open Systems Interworking (OSI) protocols, this second edition also provides support for application protocols using other protocol stacks, e.g., a TCP/IP protocol stack. This support is extended to protect application protocols using XML encoding [KHS: IEC 61850-8-2] and other protocols that have a handshake that can support the Diffie-Hellman key exchange. This extended security is referred to as E2E-security.
It is intended that this part of IEC 62351 be referenced as normative part of IEC TC 57 standards that have a need for using application protocols, e.g., MMS, in a secure manner.
It is anticipated that there are implementation, in particular Inter-Control Centre Communications Protocol (ICCP) implementations that are dependent on the first edition of this part of IEC 52315. The first edition specification of the A-security-profile is therefore included as separate sections. Implementations supporting this A-security-profile will interwork with implementation supporting the first edition of this part of IEC 62351.
Special diagnostic information is provided for exception conditions for E2E-security.
This part of IEC 62351 represents a set of mandatory and optional security specifications to
be implemented for protected application protocols."

By the way: The best security standard is useless if it is not implemented (and even worse when it is available but not used) in as many devices as possible! Talk to your management to get the resources (hardware, software, peopleware) to implement this new part - as soon as possible.

TSN: Fieldbus Standardization - Another Way to Go

Fieldbus standardization has a very long history - resulting in tens of solutions in ONE single standard series IEC 61158. This has been discussed several times on this blog.
The latest decisions in the industrial automation domain could change the direction to go: To get one or two or three ... solutions - based on TSN (Time-sensitive Networking).
It took more than 25 years to implement in principle what I have written in a paper on Fieldbus and Ethernet. When I worked for Siemens Industry in the early 90s, I recommended to use native Ethernet instead of fieldbusses … now we write 2017 – 26 years later:
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].

25 years of fieldbus wars are likely to end in the near future.
Even the Profibus International Users Group (PI) published the other day in the PI Profinews:
"TSN (Time-sensitive Networking) is a promising new IEEE technology for Ethernet that combines ... PI will expand PROFINET with the mechanisms of TSN in layer 2, retaining the application layer on the higher levels. This makes it possible to migrate the applications to the new technology simply and incrementally and to take advantage of the benefits of an open, globally standardized IT technology.”
Clicke HERE for the full announcement in the Profinews.

It's a pity that it took 25 years to understand that Ethernet is THE solution for the future.

TSN is just another link layer solution - what's about the upper layers? Huuch ... there is still the old fight of various groups that belief that their solution is the best!
PROFINET will keep their higher layers and add the option of OPC UA for higher automation levels to the cloud. So, they are recommending a compromise - which ends up in many higher layer solutions on TSN.

ABB, Bosch Rexroth, B&R, Cisco, GE, Kuka, NI, Schneider Electric, Belden/Hirschmann and Phoenix Contact are fighting for a SINGLE combination: TSN and OPC UA.

In the meantime we have - for more than 20 years - a SINGLE combination for the electric power (and energy) market: IEC 61850 with Ethernet and MMS (for client/server communication) supported by hundreds of vendors and users worldwide. AND: IEC 61850 has a huge basket of object models and a configuration language! What is being communicated through OPC UA TSN?

A finished solution (Ethernet/MMS some 25 years ago) is better than a perfect one that will never be accomplished - even not with TSN plus XX, YY, ZZ, ...!

This lets IEC 61850 look very good!

If you need your Profibus or Profinet data being communicated by IEC 61850, check HERE for Gateways.

Monday, May 15, 2017

IEC 61850-90-21 - New Project On Travelling Wave Fault Location System

IEC TC 57 just published a Proposal to develop an IEC Technical Report: IEC TR 61850-90-21: Communication networks and systems for power utility automation –
Part 90-21: Travelling wave fault location system

Scope:
1. Describe the principles of fault location based on travelling waves aided by communications.
2. Specify use cases for this method under the following application scenarios:
   a. Single-ended fault location
   b. Double-ended fault location through peer-to-peer communications
   c. Double-ended fault location with communications to a master station
   d. Wide area fault location applications
   e. Pulse radar-type echo (Japanese) method
   f. Substation integration with other fault location and disturbance recording functions
   g. Testing and calibration
3. Describe the information model for each use case.
4. Give guidance on its applications and its communication requirements.
5. Give guidance on how to achieve co-existence and interoperability with different fault location techniques.
More to come.

Updated IEC 61850 Roadmap - What is going on?

The following 40 (!!) documents are in the process of revision or definition:




































What else are you looking for? Several other documents have already been officially published.





IEC TC 57 Published IEC 61850 Roadmap and Schedule

IEC TC 57 just published a new IEC 61850 Roadmap and Schedule to give an update on the ongoing work (57/1882/INF).

The following 35 (!!) parts are in the process of revision respectively under preparation:

General Topics
5 / 7-1 / 7-2 7-3 / 7-4 8-1 / 9-2
62361-104-10
Communication
8-2
80-5
90-4, 90-12, 90-13
90-20
Modeling
7-410
7-420
7-5
7-510 7-520
90-6 / 90-9 / 90-14 90-15 / 90-21
90-10 / 90-18
90-19
7-6
7-7
Engineering
4
6
6-100
6-2
90-11
Testing
10-3

The years 2017/2018 will bring more stable documents than ever before! The major step forward is the use of a formal UML modelling tool (Enterprise Architect) to keep the consistency very high level.
Any question? Let us know.

IEC TC 88 Started Work on SCL for Wind Power Plants

WOW! IEC TC 88 has published a new work item proposal (88/621/NP) for the specification of extending the SCL (System Configuration Language):

Wind energy generation systems –
Part 25-7: Communications for monitoring and control of wind power plants –
Configuration description language for communication in wind automation systems
related to IEDs

The objective of the NWIP is to describe the adoption of the System Configuration description Language (SCL) defined in IEC 61850-6 to the wind domain

"This part would extend the IEC 61400-25 series with a file format for describing communication-related IED (Intelligent Electronic Device) configurations of a wind turbine, wind power plant controller, metrological mast etc. The extension of SCL to wind domain would simplify integration of wind power plant equipment as well as their integration to the electrical system. The adoption of SCL allows formalised tool based exchange of IED parameters, communication system configurations, switch yard (function) structures, as well as description of the relations between them.
The purpose of this format is to formally and efficiently exchange wind turbine and wind power plant IED capability descriptions, and system descriptions between IED engineering tools and the system
engineering tool(s) of different manufacturers in a compatible way. The file format is also intended for providing report configuration and alarms as well as HMI interface information from a wind power plant. This information can be used to engineer overlying SCADA systems for the site, for connected DSO, TSO or fleet operators maintenance and surveillance systems. Finally, the SCL is intended as a documentation of the configuration and topology of the delivered system."

WOW! Why a WOW? During the fist years of standardization of the series IEC 61400-25 the proposal of applying and extending the SCL (IEC 61850-6) did not find enough support to start working on the issue! Time is passing and more and more experts understand the advantage of SCL!

Good luck.

Friday, May 5, 2017

IEC TC 57 published Draft for Machine-Processable Models

IEC TC 57 has just published (57/1870/CD) the first draft improving the applicability of IEC 61850:

Communication networks and systems for power utility automation –
Part 7-7: Basic communication structure –
Machine-processable format of IEC 61850-related data models for tools

This Technical Specification of IEC 61850 specifies a way to model the code components of IEC 61850 data model (e.g., the tables describing logical nodes, common data classes, structured data attributes, and enumerations) in an XML format that can be imported and interpreted by tools. The following main use cases shall be supported:

  • Generation of SCL data type templates for system specification or ICD files. One sub-use case is the generation of LNodeTypes for replacing GGIO.
  • Validation of SCL data type templates.
  • Definition of private extensions by following the rules of the standard.
  • Adapting rapidly the whole engineering chain as soon as a new version of IEC 61850 data model (an addendum, a corrigenda or a Tissue) affects the content of the standard.
  • Provide tool-neutral textual help to users of tools on the data model contents.
  • Supporting multi-language publication, i.e., enabling the expression of the data model in different languages, through a machine processable format.

The purpose of this proposal is limited to the publication of the XML format which should support the data model part of any IEC 61850 related standard. The publication of code components themselves will be part of the related IEC 61850 part.

Comments are expected by 2017-07-28.

This a major step forward. Especially because the "cleaned-up" models of all parts to be published as Edition 2.1 of the corresponding parts could be understood as the real Edition 2 of the parts that contain models!

Monday, May 1, 2017

Why Wikipedia Misleads People Looking for Help regarding IEC 61850

How do people understand and learn what the standard series IEC 61850 really offers to the protection, automation and supervision of energy systems and what this all means for their application (as vendor, user, consultant, ...)? Some up-to-date discussion you can find on this blog, e.g., by this posting:

Who can tell you what IEC 61850 really is?

Some people (managers and ...) just go to Wikipedia and believe that they get a reasonable overview about IEC 61850. After reading the German and English version, they have learned: That IEC 61850 is mainly a PROTOCOL standard!

German Version tells in the very first sentence:

"Die Norm IEC 61850 der International Electrotechnical Commission (IEC) beschreibt ein allgemeines Übertragungsprotokoll für die Schutz- und Leittechnik in elektrischen Schaltanlagen der Mittel- und Hochspannungstechnik (Stationsautomatisierung)."

English Version talks a lot about PROTOCOLS:

"IEC 61850 is a standard for vendor-agnostic engineering of the configuration of Intelligent Electronic Devices for electrical substation automation systems to be able to communicate with each other. ... The abstract data models defined in IEC 61850 can be mapped to a number of protocols. Current mappings in the standard are to MMS (Manufacturing Message Specification), GOOSE (Generic Object Oriented Substation Event), SMV (Sampled Measured Values),[clarification needed] and soon to Web Services. These protocols can run over TCP/IP networks or substation LANs using high speed switched Ethernet to obtain the necessary response times below four milliseconds for protective relaying."

After reading these two pages ... some managers believe that IEC 61850 is mainly dealing with protocols. Protocols are required to exchange information between devices.
IEC 61850 deals mainly with the description of signal flows between any point of a (power or energy) system that generates information (status, measurements, alarms, settings, ...) and those points that need to receive or consume this information.(protection, automation, SADA, control center, ... asset management, ...).
The signal flow could be completely described (and documented) as an SCL file of tens of Mega Bytes ... such files have almost nothing to do with protocols - but the tools that design and engineer systems like substations are key to the future systems. SCL is defined in one document (IEC 61850-6). This document has the biggest impact on how we manage power systems in the future.
In my understanding SCL is likely 2/3 of the importance of IEC 61850. Then there are the many crucial models - and finally we have protocols. Protocols are crucial when it comes to devices that have to send and receive signals - no discussion.

Unfortunately the managers (and everybody) that uses Wikipedia for understanding the impact of IEC 61850 are completely mislead! And likely may not understand how IEC 61850 impacts the system design and engineering based on SCL - aspects that are today usually not linked to any protocol.

If the resources for a project to implementing and using IEC 61850 is determined by the assumption that IEC 61850 is another PROTOCOL - then it is likely that the project will fail to get what IEC 61850 could provide.

This post was triggered by a discussion during an IEC 61850 Seminar and hands-on training recently. It is really frustrating for engineers to discuss the needed resources with managers that believe IEC 61850 is mainly a PROTOCOL.

Who can tell you what IEC 61850 really is?

Wednesday, April 26, 2017

NEW IEC 61850 Demo Package for Windows available

The main purpose of the new demonstration and evaluation package is to provide a free of charge simple and easy to use IEC 61850 Client/Subscriber Tool (running on Windows PCs) that can be used to communicate with a Server/Publisher implemented on the platforms:

Beck IPC DK151 Development Kit for SC145 (DK61)
Beck IPC com.tom / IXXAT SG-gateways (WEB-PLC)
SystemCorp Smart Grid Controllers
Windows PC

Several other uses cases are possible:

The demonstration uses a single generic SCL model (and a derived JSON file [JavaScript Object Notation] that can (beyond the main purpose) be used on the above platforms to automatically configure (tree structured graphical applications) for Clients, Server/Publisher, and Client/Subscriber roles as shown on the next slides.

The specification of additional models (.icd and .json) could be provided for a fee. 
Contact NettedAutomation if you are looking for other models, please.
Click HERE for further details and instructions to download the new package including the documentation.
Click HERE for documentation only.
The package is used in our training courses.

Sunday, April 23, 2017

Final Call for IEC 61850 Training Courses in May 2017 in Karlsruhe (Germany)

The following two training courses are just one (two) weeks away:

02.-05. May 2017, Karlsruhe/Germany:


Click HERE for details - and register as soon as possible.

09.-12. Mai 2017, Karlsruhe/Deutschland
HIER klicken - für Details zum Training in Deutsch

Thursday, April 20, 2017

Dubai (UAE): NEW IEC 61850 Seminar for Protection, Control, and Generation

You are invited to register for one of the world leading IEC 61850 Seminars for Protection, Control, and Generation to be conducted by

FMTP, Al-Ojaimi, and NettedAutomation 
in Dubai (UAE) at the Sheraton Dubai Mall of the Emirates
11-13 July 2017

With the focus on protection and control in HV/MV substations, power generation (PV, Wind, DER, Hydro), distribution systems using Client/Server, GOOSE, SV, SCADA and SCL Language covering:
  • IEC 61850 / IEC 61400-25 Introduction (Edition 1, 2, and 2.1) and experience after more than 10 years in operation. Where are we today?
  • Return of experience, applications and practical demonstrations:
  • Protection and Control in Substation Automation
  • Engineering and Configuration
  • Maintenance
  • Monitoring and SCADA system
  • Specification of the IEC 61850 protection and control system.
  • Through the practical demonstrations, you will learn:
  • To handle IEC 61850 relay protections from different vendors and their software tools; to be able to efficiently manage flexibility in engineering and interoperability.
  • To use the state of the art IEC 61850 testing tools and equipment to efficiently detect the technical problems and work-out their solutions.
  • To understand SCL files, setup clients and servers for MMS communication to SCADA and RTU Systems
  • All the presentations are supported by practical examples or demonstrations.
Who should attend?
  • Protection and Electrical Engineers (protection, control, engineering, SCADA, asset managers)
  • System integrators
  • Product managers of vendors
  • R&D engineers
  • Maintenance personnel
  • Experts responsible for network infrastructure
Click HERE for program and registration information.
Click HERE for other training opportunities.

Monday, April 17, 2017

What is a Function in IEC 61850?

The term "Function" is used in a variety of flavors throughout the standard series IEC 61850. If you ask five experts, you may get six answers.
IEC TC 57 has proposed (57/1863/DC) to develop a new Technical report IEC 61850-6-100: "SCL Function Modelling for Substation Automation"
A "function" is more or less a synonym for operation or action ... as described in Wikipedia:
"A function model or functional model in systems engineering and software engineering is a structured representation of the functions (activities, actions, processes, operations) within the modeled system or subject area."
In my seminars I compare IEC 61850 with Logistics:



IEC 61850 defines simple and more and more complex functions. A schedule according to IEC 61850-90-10 defines a set of quite complex (or comprehensive) functions. In most cases the functions defined by IEC 61850 are just functional components that are used as bricks to build a comprehensive application function.
The brick-concept of IEEE 1550 (UCA 2.0) indicated the use of the standard models: the Bricks (which are now the Logical Nodes in IEC 61850).
IEC 61850-7-2 Services define functions (called services) that provide information logistics, e.g., for accessing the device information model, allow exchange of any value made available by a device based on events for real-time and non-real-time applications, or services for controlling a controllable item like a circuit breaker or a fan.
Functions may be composed using the standard IEC 61499 (Function blocks) as described in the following papers:
V. Vyatkin, G. Zhabelova, N. Higgins, K. Schwarz, and N.-K. C. Nair, Towards intelligent smart grid devices with IEC 61850 interoperability and IEC 61499 open control architecture, IEEE Conference on Transmission and Distribution, New Orleans, April, 2010
 N. Higgins, V. Vyatkin, N. Nair and K. Schwarz, “Intelligent Decentralised Power Distribution Automation with IEC 61850, IEC 61499 and Holonic Control“,IEEE Transactions on Systems, Machine and Cybernetics, Part C, 40(3), 2010,
J. Xu, C.-W.Yang, V. Vyatkin, S. Berber, Towards Implementation of IEC61850 GOOSE Messaging in IEC61499 Environment, IEEE Conference on Industrial Informatics (INDIN’13), Bochum, July 29-31, 2013
Click HERE for more papers.
More to come ... stay tuned to this blog!

Thursday, April 13, 2017

HMS Smart Grid Gateways Are Now IXXAT SG Gateways

The HMS Smart Grid Gateways (supporting a wide range of standards like IEC 60870-5-104, IEC 61850, Modbus TCp/IP, ...) are now marketed by HMS under the HMS brand IXXAT Energy SG Gateways.
IXXAT SG-gateways... 

  • enable easy remote control and management of electrical systems
  • allow to log and display application data and energy consumption
  • provide IEC61850 client/server (publisher/subscriber) and IEC60870-5-104 client/server support
  • have in-built Modbus TCP client and Modbus RTU Master interfaces
  • provide connectivity for I/O, M-Bus, PROFIBUS, PROFINET and EtherNet/IP based devices

Click HERE for more details [EN]
Click HERE for more details [DE]

Friday, April 7, 2017

FDIS for IEC 62351-7 published - Network and System Management (NSM) data object models

IEC TC 57 has just published the 232 page FDIS (57/1857/FDIS) of the part IEC 62351-7 for final vote:

Power systems management and associated information exchange –
Data and communications security –
Part 7: Network and System Management (NSM) data object models

The vote closes 2017-05-12.

"This part of IEC 62351 defines network and system management (NSM) data object models
that are specific to power system operations. These NSM data objects will be used to monitor
the health of networks and systems, to detect possible security intrusions, and to manage the
performance and reliability of the information infrastructure. The goal is to define a set of
abstract objects that will allow the remote monitoring of the health and condition of IEDs
(Intelligent Electronic Devices), RTUs (Remote Terminal Units), DERs (Distributed Energy
Resources) systems and other systems that are important to power system operations. ...
The NSM objects provide monitoring data for IEC protocols used for power systems
(IEC 61850, IEC 60870-5-104) and device specific environmental and security status. As a
derivative of IEC 60870-5-104, IEEE 1815 DNP3 is also included in the list of monitored
protocols. The NSM data objects use the naming conventions developed for IEC 61850,
expanded to address NSM issues. For the sake of generality these data objects, and the data
types of which they are comprised, are defined as abstract models of data objects."

The document comprises many useful information objects related to devices and communication security issues like:

Intrusion detection systems (IDS) 
Passive observation techniques
Active security monitoring architecture with NSM data objects

End-to-end security
End-to-end security concepts
Role of NSM in end-to-end security

NSM requirements
Detecting unauthorized access
Detecting resource exhaustion as a denial of service (DoS) attack
Detecting invalid buffer access DoS attacks
Detecting tampered/malformed PDUs
Detecting physical access disruption
Detecting invalid network access
Detecting coordinated attacks

Saturday, April 1, 2017

IEC SC 65C Published 5,000+ Pages of New Fieldbus Editions (IEC 61158)

IEC SC 65C (subcommittee 65C: Industrial networks, of IEC technical committee 65: Industrial-process measurement, control and automation) has published 5,000+ pages with the following documents available for PUBLIC comments (http://www.iec.ch/comment):
  1. 65C/864A/CDV (77 pages)
    IEC 61158-1 ED2: Industrial communication networks - Fieldbus specifications - Part 1: Overview and guidance for the IEC 61158 and IEC 61784 series
  2. 65C/865A/CDV (219 pages)
    IEC 61158-3-X ED4: Industrial communication networks - Fieldbus specifications - Part 3 - X: Data-link layer service definition - Type X elements
  3. 65C/866A/CDV (1,445 pages)
    IEC 61158-4-X ED4: Industrial communication networks - Fieldbus specifications - Part 4 - X: Data-link layer protocol specification - Type x elements
  4. 65C/867A/CDV (1,721 pages)
    IEC 61158-5-X ED4: Industrial communication networks - Fieldbus specifications - Part 5-X: Application layer service definition - Type X elements
  5. 65C/868A/CDV (2,205 pages)
    IEC 61158-6-X ED4: Industrial communication networks - Fieldbus specifications - Part 6-X: Application layer protocol specification - Type X elements
  6. 65C/869/CDV
    IEC 61918 ED4: Industrial communication networks - Installation of communication networks in industrial premises 
There are many other documents that are part of this standard series.
Take your time to comment on these documents.

What's about interoperability? Read what part 1 says in clause 4.2:

"Most of the fieldbus types specified in the IEC 61158 series include a range of selectable and configurable options within their detailed specifications. In general, only certain restricted combinations of options will interwork or interoperate correctly."

It seems like an April fool' s joke - BUT, NO, IT IS REALLY TRUE.

Thursday, March 23, 2017

ASCII Text, XML, SCL, Models, and Errors All Over

IEC 61850 makes use of ASCII text, XML, SCL, and comprehensive Information Models. At any level you may find errors. How to figure out, e.g., if a DataSet member references a FCDA that is not available in any Logical Node model?

I run through the following inconsistency:
There is a DOType "SPG_0" defined that contains a fc="SP"(bottom).
The DO "SetPt19" uses this DOType with fc="SP" (above)
The marked DataSet member FCDA refers to DO "SetPt19" with fc="ST".



This reference is not correct - there is no DO "SetPt19" with fc="ST" !! How does a stack react when it has to parse such a wrong model? Hmm!

It took me some time to figure out what the issue was when I loaded the file onto a HMS Gateway with WEB-PLC:



In the meantime I have checked the wrong file with six (well known) IEC 61850 tools - NONE of them complained about this inconsistency.
The SystemCorp stack complained, because it was not able to find the referenced object to implement the model! WOW!

This example confirms what I always tell people in my courses: Develop your own simple tools for finding errors in the "ASCII Text" - it is just a simple search you need ... I am not saying that the many tools on the market are useless!! No way! But many simple checks could be done with simple tools. Even tool developer may not have a clue what kind of checks would be helpful.
In this case it would have been quite easy to check (ASCII search and comparison) all members of all DataSets and check in the Logical Node models if there is a DataObject that matches with the reference in the DataSet. Such a ASCII text search would have resulted in something like: Did not find an fc="ST" for the object "SetPt19".

It is that easy! Believe me.

My experiences with this and many other issues are one of the core topics in my courses.
Click HERE for courses in German in Karlsruhe/Germany.

Wednesday, March 22, 2017

GridEx: The Smart Tool to Test Your IEC 61850 Network

FMTP (From Minus to Plus, Sweden) has gained a lot of positive feedback from experts using the GridEx Tool around the globe. GridEx built-in intelligence based on 30 years combined field experience in Protection Control with IEC 61850.

The new Test Tool looks very ruggedized:




The standalone tool provides many very crucial functions for simplifying the test and operation of automation systems based on IEC 61850. Here is one example function:

Click HERE for more details on the GridEx.

CD published: Conformance Test Cases for the IEC 62351-5

IEC TC 57 just published a 110 page crucial document on security testing (57/1852/CD):

IEC TS 62351 - Data and communications security -
Part 100-1: Conformance test cases for the IEC 62351-5 and its companion standards for secure data exchange communication interfaces

Comments are welcome by 2017-06-09

The scope is to specify common available procedures and definitions for conformance and/or interoperability testing of the IEC/TS 62351-5 (Security for IEC 60870-5 and derivatives), the IEC/TS 60870-5-7 and also their recommendations over the IEC 62351-3 for profiles including TCP/IP. These are the security extensions for IEC 60870-5 and derivatives to enable unambiguous and standardised evaluation of IEC/TS 62351-5 and its companion standards protocol implementations.