http : //www.cigre.

org
21, rue dArtois, F-75008 PARIS

B5 216

CIGRE 2008

REACHING OUT SEAMLESS AND COST-EFFECTIVE AUTOMATION BEYOND

IEC 61850
J-Ph. TAVELLA, T. COSTE
EDF R&D
France

O. HUET*
EDF R&D
USA

J. HUGHES
EPRI
USA

SUMMARY
IEC 61850 standard is definitely a leap forward for more interoperable automation. Nevertheless, as
many other standards, the standard comes in a text format that early adopters have to browse through
and interpret for their own automation project. But other modern methods used mainly in the
communication and computer science domain have been used for many years to avoid the painful
work to find the information and to contain any risk of mis-interpretation of wording. The most
commonly tool that could serve this purpose is the Unified Modelling Language (UML). UML is a
graphical language that expresses design in a standard way embedding information, describing
behavior, and allowing design tools to interchange models.
EDF has developed the first UML model of IEC 61850 made available publicly to formalize the entire
data model and the communication services that are described in the model (parts 7-2, 7-3, 7-4). The
capture of this first model has identified some gaps and ambiguous interpretations in the standards that
have been submitted to IEC for improvement of the standard. A web version of the model is available
publicly to allow a widespread verification of the model itself and verify its implementation.
The new version of the model will include additional information needed for the interoperability of
devices that has not been standardized so far: the behavior of intelligent electronic devices. This
contribution of standardized behavior will complement the four building blocks identified in the
reference architecture of the Technical Committee 57: architecture, vocabulary, data modelling, and
communication codes. Work developed has focused so far on the communication services that define
how the data can be exchanged between equipment or software applications.
The application of having an entire model of data, services and behaviors are tremendous. Modern
tools that can handle UML can nowadays generate automatically code, produce a replica of the
automation to emulate equipment, or even produce the entire tests sequence needed to validate the
automation. This will allow quick mock-up for any automation device and efficient study and
validation of architecture design. This approach will reconcile the 3 standpoints needed for the
successful implementation of any new schemes between utilities, vendors and independent test
entities.
Olivier.huet@edf.fr

This article will present the lessons learned using the first public static model of IEC 61850 and the
first results of the development of a model of behavior of equipment that is compatible with IEC
61850.

KEYWORDS
UML, Tests - Profile, Modelling, IEC 61850, Automation - integration, SAS, configuration.

1. Introduction
Substations automation is widely based on distributed systems that have to integrate products and
equipment coming from different vendors. Integration of these distributed controls is a complex
process using at the same time a fine tuning of specific data derived from the power systems domain
and more sophisticated and generic application-layer communication services.
The assembly of numerous pieces of equipments in the same system requires more frequent and more
complex data exchanges involving frequent mapping of these specific data between equipment. At the
same time, the communication services involved are more and more sophisticated (data, dataset or file
exchanges, object controls, event management, configuration and security requirements, confirmed or
unconfirmed services, unicast, multicast or broadcast, emergency communication, .).
The recent IEC 61850 standard is a good example of a standard that address such complex
requirements.
2. UML for the Static Modelling of Data and Abstract Services of the IEC 61850
Edition 1 of the standard (edited as an international standard in 2003 and 2004) refers to about 90 main
data structures called LNs (logical nodes) each composed of 29 predefined types called CDCs
(common data classes). In addition, 62 abstract services are proposed to cover the substations
communication needs and this messaging system can be mapped to concrete data communications
protocol stacks (such as MMS). This simple facts illustrates how complex and difficult the IEC 61850
standard could be for a non-expert person.
To illustrate the difficulty to reach the desired information among the different parts of the standard,
let us take a simple circuit-breaker (identified as XCBR) :

From IEC 61850-7-4

From IEC 61850-7-3

From IEC 61850-7-3

Figure 1 : The XCBR Model is Scattered among Several Chapters

The XCBR logical Node (LN) and other LNs are defined in part 7-4 but their data objects are detailed
in another part referenced 7-3. As shown in Figure 1, the data Loc typed SPS as a CDC (Common
Data Class) is composed with internal data attributes such as q that is another structure defined with
named and typed attributes in part 7-3 again. This tabular presentation is completed with numerous
pages of text, the whole being a set of ten parts with hundreds of pages.

Nevertheless, an effort has been made in the standard to better formalize concepts. Some UML closed
properties such as class (a set of data), class attribute (a piece of data), cardinality (mandatory/optional
information) or inheritance (attribute factoring) are present in the tables. In addition, the standard
proposes several UML-like diagrams in figures as in part 7-4 (LN Relationships) or in part 7-2 (Basic
conceptual class model of the ACSI).
3. One Standard but Several Models
In spite of this interesting effort, there is a mix of several modelling concepts in the standard. Some of
these concepts are meta-modelling relevant and only helpful for global understanding (e.g. the
description of the basic conceptual class model beginning with the SERVER level).
But the main part of the modelling concepts is related to static modelling, particularly all the dedicated
common data class and logical node class descriptions.
But no effort has been made to formalize the behaviour of the abstract communication services which
is precisely the scope of dynamic modelling.
3.1. The Static Model
The static model expresses an exhaustive description of all the CDCs and dedicated LNs in the model
(including the ACSI service prototypes) while dynamic modelling deals with behavioural description
(for the services as well as for the SAS itself including configuration).
Dynamic modelling (part 7-4)

Static modelling (part 7-4)

Figure 2 : Mix of Modelling Information : Dynamic & Static Modelling and Meta-modelling

Figure 2 illustrates the mix of representations for the circuit breaker logical node (LN XCBR). In
UML, a circuit breaker (XCBR) is represented by a class with typed attributes (e.g. Pos typed DPC).
Some common attributes are inherited either directly (from class Common LN) or not (from class
LOGICAL-NODE). This means that attributes such as Mod (from Common LN) or DataSet (from
LOGICAL-NODE) are automatically added to XCBR. In addition, dedicated ACSI services declared
in LOGICAL-NODE are inherited by XCBR. Such a description is an example of functional static
modelling.
Let us speak now about ACSI services. Almost all these services use a parameter typed
ObjectReference (but unfortunately object reference attribute has a different name according to the
class in the meta-modelling tree : LDName, for LOGICAL-DEVICE, LNName for LOGICAL-NODE,
DataName for DATA and DATName for DAType) 1 .
1

There is the same trouble with the object name (LNName for LOGICAL-NODE, etc.).

The standard explains :

- that the object name is only depending on the level in the conceptual model except for the
LOGICAL-NODE one where it refers to the instance of the object typed with a dedicated LN
(e.g XCBR1 allows to distinguish the first XCBR from the others in the same logical device);
- how the object reference is to be built with the current object name and the object reference of
the preceding level in the hierarchy.
This description is vital for the dispatching of the incoming messages inside a server to identify the
correct logical device, then inside this device, to request the good logical node and so on until reaching
the target data attribute.
The UML stereotypes enable to gather both the static view and the meta-model view in a single
representation.
XCBR

SERVER

part Loc : SPS [1..1]

part OpCnt : INS [1..1]
part Pos : DPC [1..1]
part BlkOpn : SPC [1..1]
part BlkCls : SPC [1..1]
1..*
+ LogicalDevice
part ChaMotEna : SPC [0..1]
part SumSwARs : BCR [0..1]
LOGICAL-DEVICE
part CBOpCap : INS [1..1]
part POWCap : INS [0..1]
//
Conceptual objets only
part MaxOpCap : INS [0..1]
Mod
<<stereotype>>
Beh
2..*
+ LogicalNode
LOGICAL-NODE
Health
<< LOGICAL-NODE >>
<<stereotype>>
NamPlt
LNName : ObjectName
LOGICAL-NODE
LOGICAL-NODE
Loc
LNRef : ObjectReference
EEHealth
part Data : DATA [1..*]
EEName
OpCntRs
1..*
Data
OpCnt
LOGICAL-NODE
OpTmh
<< DATA >>
DataSet
part DataSet : DATA-SET [0..*]
DATA
BufferedReportControlBlock
part BufferedReportControlBlock : BRCB [0..*]
part UnbufferedReportControlBlock : URCB [0..*]
UnbufferedReportControlBlock
part LogControlBlock : LCB [0..*]
LogControlBlock
part Log : LOG [0..*]
Log
part Control : CONTROL [0..1]
Control
GetLogicalNodeDirectory (in Request : GLNDReq, out Response+ : GLNDResp+, out Response- : GLNDResp- )
GetAllDataValues (in Request : GADVReq, out Response+ : GADVResp+, out Response- : GADVResp-)

GetLogicalNodeDirectory
GetAllDataValues

Figure 3 : Example of a Stereotype that extends the Functional Model

Figure 3 is an example of stereotype LOGICAL-NODE that holds a meta-model (attribute Data with
its tree of classes DATA) and also a functional model (class LOGICAL-NODE with attributes and
operations to be inherited by dedicated LNs such as XCBR). Of course, the same approach can be
used for lower levels (DATA and DataAttribute).
The advantage here is that Data is not forgotten (for completion purpose) and also not inherited by
dedicated LNs (as it is not helpful functionally).

In addition to these stereotypes designed to capture the meta-model, some other stereotypes have been
added in the EDF model to collect functional information that is difficult to insert in usual UML class
model. As an example, the T and M/O column headings in LN tables are stereotyped as illustrated in
Figure 4 bellow :

//
Automatic tap changer controller
Common LN

ATCC

//

ATCC

ATCC

part Loc : SPS [1..1]

<<C(.Condition=C.)>>part TapChg : BSC [0..1]

<<C(.Condition=C.)>>part TapPos : ISC [0..1]
part ParOp : DPC [1..1]
part LTCBlk : SPC [0..1]
<<T>>part LTCDragRs : SPC [0..1]
part Vred1 : SPC [0..1]
part Vred2 : SPC [0..1]

TapChg and TapPos are stereotyped C :

at least, one of the two controls TapChg and TapPos shall be used

//

LTCDragRs is stereotyped T

ATCC

ATCC

ATCC

ATCC

part CtlV : MV [1..1]

part LodA : MV [0..1]
part CircA : MV [0..1]
part PhAng : MV [0..1]

part HiCtlV : MV [0..1]

part loCtlV : MV [0..1]
part HiDmdA : MV [0..1]

part Auto : SPS [0..1]

part HiTapPos : INS [0..1]
part LoTapPos : INS [0..1]

part BndCtr : ASG [0..1]

part BndWid : ASG [0..1]
part CtlDITmms : ING [0..1]
part LDCR : ASG [0..1]
part LDCX : ASG [0..1]
part BlkLV : ASG [0..1]
part BlkRV : ASG [0..1]
part RnbkRV : ASG [0..1]
part LimLodA : ASG [0..1]
part LDC : SPG [0..1]
part TmDIChr : SPG [0..1]
part LDCZ : ASG [0..1]
part VRedVal : ASG [0..1]
part TapBlkR : ING [0..1]
part TapBlkL : ING [0..1]

Figure 4 : T and C Functional Stereotypes for LNs

For an easier reading of the functional model, LNs are colour coded depending on their attributes
category (e.g. orange for the category controls). UML provides a concise representation of classes
(with listed attributes prefixed by the UML keyword part) with their multiplicity on-line ([1..1] for the
mandatory attributes and [0..1] for all the others).
As EDF intends to share this static modelling experience, our static model is completely free and
available on demand on HTML or XMI2.1 format. Figure 5 shows the main package structure of the
free model.

Figure 5 : Main Packages of the EDF Free Static Model (Edition 1) : Parts 7-2 & 7-3

3.2. The Dynamic Model

As stated earlier, the dynamic model contains object names and references. Whichever ACSI service is
used, object names and references are used to address the inner class as shown by Figure 6.
The Operate.req signal is sent by a client to a server and then distributed internally to composed
classes (a logical device and then a logical node). Then the Operate.resp signal is returned from the
leaf class to the client.

//

In XCBR1 from MyLD2 in MyServer, MyClient controls the controllable data ctlVal by setting this attribute to off.
It is a normal operation (no-test). CtlModels is assumed to be normal-with-normal-security.
Note that some signal parameters are not valued.

<<actor>>

<<subject >>

MyClient : SERVER

MyServer : SERVER

MyServer.LogicalDevice[2]

MyServer.LogicalDevice [2].LogicalNode[1].Control

// Ready

Operate.req(OReq(."MyLD2/XCBR1.Pos.ctlVal[CO]",BOOLEAN(.off.),EntryTime,no-test,Check.))
Operate.req(OReq(."MyLD2/XCBR1.Pos.ctlVal[CO]",BOOLEAN(.off.),EntryTime,no-test,Check.))
Operate.req(OReq(."MyLD2/XCBR1.Pos.ctlVal[CO]",BOOLEAN(.off.),EntryTime,no-test,Check.))

Operate.resp(OResp+(."MyLD2/XCBR1.Pos.ctlVal[CO]",BOOLEAN(.off.),EntryTime,no-test.))
Operate.resp(OResp+(."MyLD2/XCBR1.Pos.ctlVal[CO]",BOOLEAN(.off.),EntryTime,no-test.))

Operate.resp(OResp+(."MyLD2/XCBR1.Pos.ctlVal[CO]",BOOLEAN(.off.),EntryTime,no-test.))

Figure 6 : Sequence Diagram for operate.req and operate.resp Signal Propagation

Once the static model was extended to the main ACSI use cases (input sequence diagrams), a dynamic
model was developed to get a real size model of the IEC61850 standard. This dynamic modelling is
built using a set of additional UML features extending all the static model description.
Figure 7 shows the result of a simulation of the dynamic model. The output sequence diagrams are
automatically generated by the UML tool.

Figure 7 : Output Sequence Diagram Generated by a simulation of the Dynamic Model

In the figure, the Operate.req signal is sent from the client to the server as a consequence of an
external stimuli (coming from the environment). As a behavioural signature, the diagram then
represents the signal propagation and the reference to additional UML operations such as
FindxxByName.
As an example, FindLDByName is able to link to the correct logical device among the list of its
logical device classes.
4. Modelling Effort Benefits

The first objective that EDF had in the development of a static model was to get a better and deeper
understanding of the standard. A secondary benefit of this activity was to identify technical issues in
the existing standard that need to be addressed to solve some errors and ambiguities. These items have
been brought to the attention of the Utility Communication Association (UCA) group that gather users
of the IEC 61850 and will be brought to the proper IEC working group for a further evolution of the
standard.
The dynamic modelling has helped to identify some lack of details to understand the ACSI behaviour
without ambiguity, especially with the question of return codes (exceptions that may be thrown when
some operation pre-conditions are not satisfied). The intent of the model is to be widely shared among
users and to get revision to have a more robust model able to complete efficiently the paper version of
the standard. Other potential evolutions (new UML operations) could be imagined to implement
dedicated control algorithms (e.g. an algorithm for instantaneous overcurrent protection).
To get more flexible model, we intend to implement a configuration phase (at the beginning of the
model execution) to instanciate servers, logical devices, logical nodes and optional attributes directly
from a file whose content respects the SCL format.
At the opposite, an SAS instanciation is possible directly through the UML model (thanks to the object
diagram) since it offers the minimum of information required for a system configuration tool. In other
words, people in charge of SAS instanciation (the architect as mentioned in [5]) could be derived from
the existing model and could replace any configuration tool with just a dedicated graphical interface
plugged on it.
5. Conclusion
The application of having an entire model of data, services and behaviors are tremendous. IEC 61850
is a case for UML and modern tools can nowadays handle wide UML models, generate automatically
code, produce a replica of the automation to emulate equipment, or even produce the entire tests
sequence needed to validate the automation.
Global modelling including meta-modelling and functional modelling with both a static view and a
dynamic one is used at EDF for complete SAS specifications. The application of such method will
enable to replace hard-copy specification of automation by providing a model in an electronic format
for procurement between utilities and its main suppliers.
Packaged with specific rules to apply the method, this global modeling allows quick mock-up for any
automation device, efficient study and validation of architecture design. Functional extensions and
maintenance are also easier with a significant reduction of the cycle of development of equipment.
This approach will reconcile the 3 standpoints needed for the successful implementation of any new
schemes between utilities, vendors and independent test entities.

BIBLIOGRAPHY
[1]

61850-7-2 : Basic communication structure for substation and feeder equipement Abstract
communication service interface (ACSI)
[2] 61850-7-3 : Basic communication structure for substation and feeder equipement Common
data classes
[3] 61850-7-4 : Basic communication structure for substation and feeder equipement Compatible
logical node classes and data classes
[4]
http://tissue.iec61850.com : Collecting, logging, presenting, and solving technical issues
(Tissues)
[5]
L. Hossenlopp, T. Coste, E. Lambert, System configuration including harmonization with
IEC 61970/IEC 61968, CIGRE 2006