Monday, June 26, 2017

Update on OPC UA IEC 61850 Companion Specification

The OPC UA IEC 61850 Companion Specification of the OPC Foundation is focusing on gateways that are intended to be used to transfer information fully and accurately through gateways between devices that implement IEC 61850 or OPC UA respectively.
While IEC 61850 is focusing on electricity generation, transmission, distribution, distributed energy resources (DER), and consumption, OPC UA is dealing with non-electrical industrial process activities. It is clear that users require integration of the electrical aspects of a plant with non-electrical aspects.
The information models defined in IEC 61850 were focused during the late 90s on protection and automation of electric power systems. In the meantime the models provide a huge number logical nodes (e.g., STMP = Supervision of temperature with measurement, alarms and trips, or FPID = PID loop control) applicable in most non-electrical applications domains. The communication services (Reporting, Logging, GOOSE, Control, Setting Group Control, ...) are generic for any application domain.
OPC UA’s modelling capabilities is understood to make it possible to transfer data between different systems without losing the semantics of data. Thus the drafted companion specification document describes how IEC 61850 data can exchanged using OPC UA data modelling and services.
Click HERE for more information.
IEC TC 88 PT 25 is currently working on a technical specification: 
Wind turbines - IEC 61400-25-41: Communications for monitoring and control of wind power plants - Mapping to communication profile based on IEC 62541 (OPC UA)
Microsoft has provided an Open-Source OPC UA stack to OPC Foundation! 
The new OPC Foundation .NET reference stack, based on the new .NET Standard Library technology, was developed and optimized by Microsoft to serve as the complete platform-independent infrastructure, from the embedded world to the cloud. This new version is enabled on the following supported platforms: Various Linux distributions, iOS, Android, Windows 7, Windows 8, Windows 8.1, Windows 10, Windows Phone, HoloLens and the Azure cloud.
Click HERE for the press news from the OPC Foundation.
Click HERE for accessing the open source reference stack at Gidhub.
Brief comparison of IEC 61850 and OPC UA:
Standard? Yes for both in IEC.
Available since? IEC 61850 for some 15 years; OPC UA for a few years.
SCADA support? Yes for both.
Real-time support? Yes in IEC 61850; OPC UA is intended to run on TSN (IEEE 802).
Security? Yes for both (IEC 61850 refers to IEC 62351).
Semantic? IEC 61850 has huge, still growing list of models; OPC UA has not yet semantics.
Configuration Language? IEC 61850 has SCL (System Configuration Language); OPC UA has no.
Conformance testing? Yes for both.
Support: By many big and small companies.
Open Source Stack? Yes for IEC 61850 (; yes for OPC UA (from Microsoft, see above).

Wednesday, June 14, 2017

How to Model Thousands of Measurement Signals?

The standard series IEC 61850 was originally developed for high voltage substation automation and protection ... with well defined logical nodes and data objects representing the most crucial signals like status (CSWI.stVal), 3-phase electrical measurements (MMXU.V.phsA ...), temperature supervision (STMP.Tmp, STMP.Alm, ...) and many other signals.
Several applications require huge number of values, e.g.,
  1. Logs (hundreds of status changes over a long period)
  2. Power Quality measurements (hundreds of values of min, max, ...)
  3. Temperature (hundreds or thousands of raw measured or processed values)
The corresponding logical nodes and communication service models would end-up in a lot of overhead in the modelling or in the communication.
I have discussed the first two bullets already inside the standardization groups ... more details may be discussed in a future blog post.
Today, I will discuss the third issue: huge amount of temperature values.
First of all, there are two models for temperature: TTMP (Transducer for a single sensor value) and STMP (Supervision of a single temperature value) with the following excerpt of details:

TTMP.TmpSv.instMag and TTMP.TmpSv.q are the two mandatory data attributes.

STMP.Tmp.mag.f, STMP.Tmp.mag.q, STMP.Tmp.mag.t (Tmp is optional)
STMP.Alm.stVal, STMP.Alm.q, STMP.Alm.t (Alm is optional)
STMP.Trip.stVal, STMP.Trip.q, STMP.Trip.t (Trip is optional)
Second, If you want to communicate just hundreds of temperature values, I would model this application as follows (SIUnits and sample rate ... may be modeled as well):
[Sure, I am aware that multiple instances of TmpSv are not yet standardized ... I would not care a lot at the moment ... it will come anyway. If not, define an extended Data Object TmpSamp with multiplicity 0..*]
TmpSv1.instMag and TmpSv1.q
TmpSv2.instMag and TmpSv2.q
TmpSv3.instMag and TmpSv3.q
TmpSv100.instMag and TmpSv100.q
Unbuffered Report CB="UnbTTMP1
Data Set="DsTTMP1" 
trigger option: integrity period 
period: 1 h or ...
TmpSv1.instMag and TmpSv1.q
TmpSv2.instMag and TmpSv2.q
TmpSv3.instMag and TmpSv3.q
TmpSv100.instMag and TmpSv100.q
Unbuffered Report CB="UnbTTMP2
Data Set="DsTTMP2" 
trigger option: integrity period 
period: 1 h or ...
TmpSv1.instMag and TmpSv1.q
TmpSv2.instMag and TmpSv2.q
TmpSv3.instMag and TmpSv3.q
TmpSv100.instMag and TmpSv100.q
Unbuffered Report CB="UnbTTMP3
Data Set="DsTTMP3" 
trigger option: integrity period 
period: 1 h or ...
Third, If you want to use hundreds of temperature values AND alarms AND trips etc. then STMP would be the right choice. The above modeling approach would be the same.
In addition to the data sets for the measured values, you may also configure data sets for the quality "q", and configure report control blocks with trigger option "data change". You may also add the quality into the other FCDAs ... depending on how crucial the quality is for the client application.

Tuesday, June 13, 2017

Are Blackouts Knocking at the Doors of Substations?

Dear experts interested in secure power delivery systems,
You may have been informed yesterday about one of the latest developments in destroying the power delivery infrastructure: Industroyer.
What is Industroyer? It is "A new threat for industrial control systems" according to Anton Cherepanov (ESET):
"Win32/Industroyer is a sophisticated piece of malware designed to disrupt
the working processes of industrial control systems (ICS), specifically
industrial control systems used in electrical substations.
Those behind the Win32/Industroyer malware have a deep knowledge
and understanding of industrial control systems and, specifically, the
industrial protocols used in electric power systems. Moreover, it seems very
unlikely anyone could write and test such malware without access to the
specialized equipment used in the specific, targeted industrial environment.
Support for four different industrial control protocols, specified in the
standards listed below, has been implemented by the malware authors:
• IEC 60870-5-101 (aka IEC 101)
• IEC 60870-5-104 (aka IEC 104)
• IEC 61850
• OLE for Process Control Data Access (OPC DA)
In addition to all that, the malware authors also wrote a tool that
implements a denial-of-service (DoS) attack against a particular family of
protection relays, ..."

Click HERE for a comprehensive report [pdf].

The Conclusion of the report closes with this statement:

"The commonly-used industrial control protocols used in this malware
were designed decades ago without taking security into consideration.
Therefore, any intrusion into an industrial network with systems using
these protocols should be considered as “game over”."

The protocols used are not the crucial issue! The protocols like IEC 61850 could be protected by the accompanying standard series IEC 62351 (Power systems management and associated information exchange - Data and communications security).
One crucial show stopper is: "Stingy is cool" mentality!!
Securing the systems could be implemented - with far higher costs during development, engineering, configuration, OPERATION, and maintenance.
As long as we all do not accept that the electric power (and other) infrastructures will require a lot more resources to keep the level of today's availability, quality, and security, we will experience more disrupted infrastructures.
Building an infrastructure, operating, and maintaining it are different aspects. The maintenance of our infrastructures will consume definitely more resources than we believe today.
I was shocked to read, that some "friends" believe that the reports about the "Industroyer" are just fake news.
Whatever you believe, one thing is really true: Many systems and devices in the automation domain (substations, ...) are not protected! Believe me!

Saturday, June 10, 2017

CIM-Workshop am 19. Oktober 2017 in Frankfurt

Die DKE lädt zum CIM (Common Information Model)-Workshop 2017 ein!

Ort: Frankfurt/Main
Datum: 19. Oktober 2017

Mit vielen spannenden Themen, u.a.
  • Eine Kurzeinführung in CIM 
  • Viele Anwendungsbeispiele 
  • Vorstellung des Themas CIM in Verteilnetze, Niederspannung 
  • „Life Hack“ – Wir bauen einen Kundenanschluss… 
  • Rolle von CIM in verschiedenen Projekten 
  • Referenzmodelle und CIM 
  • Podiumsdiskussion mit den Themen CIM Blick in die Zukunft, Blockchain, … 
Hier für weitere Informationen klicken.
Introduction to CIM

Thursday, June 8, 2017

What is your Annual Cybersecurity Incident Bill?

"Although the majority of industrial organizations believe they are well-prepared for cybersecurity incidents, this confidence may be not well-founded: every second ICS company experienced between one and five incidents last year, according to a survey conducted by Kaspersky Lab. On average, ineffective cybersecurity costs industrial organizations up to $497K per year."

Click HERE to read more details.

Many ICS (Industrial Control Systems) are also used in power system applications. So, what is the situation there? Likely similar to the industrial domain.

Wednesday, May 31, 2017

Just published: IEC TR 61850-90-17

IEC TC 57 has published a new part of IEC 61850 in May 2017:

IEC TR 61850-90-17
Part 90-17: Using IEC 61850 to transmit power quality data

This part of IEC 61850 defines how to exchange power quality data between instruments whose functions include measuring, recording and possibly monitoring power quality phenomena in power supply systems, and clients using them in a way that is compliant to the concepts of IEC 61850.

Click HERE for a preview of the new document.

Note that the Tissue Database can be used for posting technical issues with IEC 61850-90-17. The first tissue has been registered:

Click HERE for the first tissue on part 90-17.

Thursday, May 25, 2017

WWW - Water, Wine, and Watt-hours

When it comes to get prepared for a blackout, what do you need to survive? The "World Wide Web" (WWW) will likely not work anymore.

What's about "Water, Wine, and Watt-hours"? The new WWW.

It is still a challenge to store Watt-hours - a battery of, let's say 20 kWh would dry out within short time. It would not help in winter to survive. I would like to harvest the sun in summer, convert the electric kWh into hydrogen kWh or methane gas kWh and store it locally or somewhere outside the city.

In wintertime we could use it for heating and generate electricity.

I look forward to purchasing a system that could generate hydrogen or methane gas and store it. It may be round the corner - who knows.

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.

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

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
90-4, 90-12, 90-13
7-510 7-520
90-6 / 90-9 / 90-14 90-15 / 90-21
90-10 / 90-18

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.