Computer Standards & Interfaces 27 (2005) 679 – 695

www.elsevier.com/locate/csi

Understanding and using the IEC 61850: a case for meta-modelling

Tatjana Kostic*, Otto Preiss, Christian Frei
Corporate Research, ABB Switzerland Ltd., 5405 Daettwil, Switzerland
Received 12 July 2004; received in revised form 23 August 2004; accepted 3 September 2004
Available online 18 October 2004

Abstract

This paper argues for means to rigorously specify data models and communications services of industrial data
communications standards. It uses the example of the recently published IEC 61850 standard bCommunications networks
and systems in substationsQ. The latter applies mainly to electrical supply systems such as substations and decentralised power
resources (based on wind, photovoltaic, fuel cells, hydropower). However, the concepts of the IEC 61850 could be used in other
industrial areas, as well.
The paper shows how the complex standard can be modelled elegantly and precisely with a meta-modelling approach, in
which we utilise the UML for the model representation. The conceptual approach presented makes the inherent complexity of
the standard’s data model manageable for both humans and machines. That is, it facilitates human comprehension and machine
processability and thereby contributes to a better understanding of the standard as well as to a better utilisation of the standard
through functionality provided in today’s CASE tools. One important aspect is that it allows one to establish and maintain
consistency across the standard’s data and communications models.
D 2004 Elsevier B.V. All rights reserved.

Keywords: UML; Meta-modelling; Modelling tools; Formal model; IEC 61850; Communication networks and systems; Specification
consistency

1. Introduction order to do so, many domain-specific data communi-

cations standards (often called bprotocol standardsQ)
Industrial automation is largely based on distrib- are defined. This can be for domains such as
uted systems, which increasingly have to integrate manufacturing control, automotive control, or control
products and applications of different vendors. In of substations and equipment which are part of our
electric power systems.
In the past, protocol standards were rather simple.
* Corresponding author. Tel.: +41 58 586 8303; fax: +41 58 586
That is, they had a relatively small number of domain-
7365.
E-mail addresses: [email protected] (T. Kostic)8 specific data types defined and also a small number of
[email protected] (O. Preiss)8 [email protected] types of application communications services. Fur-
(C. Frei). thermore, the data types were comparably simple and
0920-5489/$ - see front matter D 2004 Elsevier B.V. All rights reserved.
doi:10.1016/j.csi.2004.09.008
680 T. Kostic et al. / Computer Standards & Interfaces 27 (2005) 679–695

close to what software programmers would call interpretation space. After all, we should not forget
primitive data types. The mapping of the application that it is the software engineers who are to
data items to underlying communications stacks was understand the standard so as to develop standard’s
also rather straightforward, not at last because the compliant software.
standards usually defined all or the required layers1 of The IEC 61850 standard [1], which deals with
a communications stack on their own. different aspects of communications in substations of
This simplicity, however, has turned into com- electrical power networks, is not an exception to the
plexity. The complexity has a number of reasons. (a) picture painted in the previous paragraph. Content-
Structurally much more complex pieces of informa- wise and related to the topic of a communications
tion shall be exchanged. (b) More elaborate com- protocol, the standard specifies three aspects, which
munications services are realised through the are relevant for the software to be developed by
adoption of communications techniques and service vendors of substation automation equipment: (1) a
models that were introduced in standard information comprehensive data model (the bwhatQ); (2) the
technology (IT). For example, this includes commu- communication services to access and exchange data
nications techniques based on confirmed and uncon- (the bhowQ); and (3) the substation configuration
firmed services, elaborate event models, security language (SCL), a formal way to describe how
services, transaction support, remote procedure calls, individual devices are configured; that is, what data
etc. (c) It is desirable that the communications and services they are supposed to be supporting. The
standards can make use of existing communications goal of the standard is to facilitate integration and
layers or profiles (such as Ethernet for physical and inter-operability of different devices when building
link layer, IP and TCP for network and transport new or refurbishing old substations with automation
layer, etc.). equipment.
However, these more complex pieces of infor- Albeit hugely complex, a notable contribution of
mation and more complex types of services are still the standard is its elaborate compilation of data items
constrained by the soft real-time nature of the that can be transferred among communicating sub-
industrial control applications. Thus, the mix of station equipment. We call this compilation the bdata
domain-specific requirements with the reuse of modelQ. It reflects the semantics of the application
standard IT approaches and technologies leads to domain (substation automation), as opposed to a
big, complex standards with many implicit and simple syntax. However, apart from the SCL, which
explicit dependencies among parts of such a stand- is specified as a W3C XML Schema, all the normative
ard. It is typically the case that such domain- specifications are natural language texts largely
specific protocol standards are defined by domain structured by means of tables. Some tables and
experts who, while experts in their domain, have elements of tables may have explicit references to
limited knowledge about IT-related methods and other tables and elements (see left side of Fig. 12), but
practices to rigorously specify data and other quite often there are no explicit links. In the latter
models. Consequently, the standards contain a lot case, the reader is assumed to understand the
of implicit domain knowledge, which is hardly substation automation domain, which would help
accessible to software engineers. This is for two him to consider implicit relationships when appro-
reasons: first, the domain-specific concepts and priate. One really has to be domain expert to under-
connotations of the vocabulary are not known and stand what was meant with, for instance, the attribute
leave a lot of room for interpretation and therefore A in the table T1 in one part of the standard, and what
also for the conceptual mapping to software con- is its relationship to the (same or not?) attribute A in
cepts; second, the lack of preciseness in the (natural the table T23 in another part of the standard. This
language) representation does not constrain the

2
Note that the figure has mnemonic value only; that is, the reader
1
Layers in the sense of the seven-layer model of the ISO/IEC is not assumed to read the figure contents in detail but understand
7498 [9]. our high level objective: tables vs. UML.
 T. Kostic et al. / Computer Standards & Interfaces 27 (2005) 679–695 681

Fig. 1. Objective: Make the references defined in IEC 61850 tables (left) explicit and rigorous (right).

situation is problematic because we are talking about To circumvent the first point above, we propose an
more than 150 tables distributed over more than 600 original, formal data type model using four levels and
pages in five different documents. being expressed in UML [2]. This is the main topic of
In our opinion, there are three main categories of this paper. Our meta-model cannot eliminate the
problems within the standard, as it is defined now: coupling of data and communications (cf. point 2),
but it can at least localise it precisely. While we have
(1) During its definition, we suspect the lack of an addressed the third deficiency in our work, it is out of
explicit bdesignQ phase, which would have scope for this writing (and would deserve a paper on
introduced a solid conceptual foundation (pre- its own).
cisely defined concepts and concept relation- We have developed a formal UML model [3] in
ships, modelling terminology) on which the Rational Rose, which contains the full specification of
remaining parts of the standards could have both the data and the communications models. In the
built their precise models. rest of this paper, we will refer to this model as bthe
(2) Although it would be highly favourable and UML ModelQ. We believe that such a formal model
natural to clearly separate the application data already contributes to some of our goals:
model and communications concerns (e.g.,
related to efficiency), it is not fully achieved in ! It makes the standard accessible to software
the standard. Hence, the application data model is engineers, who are literate in UML. They need
bclutteredQ with concepts that relate to commu- not know much about the application domain.
nications—rather than application data issues. ! It allows for the leverage that CASE tool support
(3) While SCL is the only part of the standard can provide, not only in the support of consistency
normatively defined in a machine processable checking or for controlled extensions, but also in
way (W3C XML Schema), it does introduce its automatic natural language documentation or even
own concepts, which are partly inconsistent or code generation.
redundant to concepts specified in the other
normative parts of the standard. Consequently, a The rest of the paper is structured as follows. In
mapping is needed within the standard itself in Sections 2 and 3, we introduce the application domain
order to maintain consistency between the con- and the basic concepts of the standard, respectively.
figuration language concepts and concepts of the This should be enough to follow and appreciate the
data or service models of the core standard. main discussion and contribution of this paper—the
682 T. Kostic et al. / Computer Standards & Interfaces 27 (2005) 679–695

data type model—being presented in detail in Section ever, it implicitly documents the authors’ thinking,
4. Section 5 summarises the benefits of the more i.e., their conceptualisation of the relevant aspects
rigorous approach before Section 6 concludes the of the SA domain.
paper. ! Data modelling: a data model for SAS is defined. It
defines the syntax (naming scheme) and semantics
of the application level data that can be exchanged
2. The application domain in SA systems (Parts 7-2, 7-3 and 7-4).
! Communication service modelling: a communica-
Electric power networks (power grids) are respon- tions service model defines the different ways of
sible to transport energy from generation sites to accessing data of IEDs (Part 7-2).
end-consumers, such as individual households or ! Communications protocol stacks: the communica-
larger organisations. The nodes in such a network are tion services and data models are mapped to
called substations and take over the voltage trans- concrete data communications protocol stacks
formation and/or the routing of energy flow by (Parts 8 and 9).
means of the installed switchgear (e.g., transformers, ! SAS engineering and testing: a W3C XML based
circuit breakers). Substations are controlled by Substation Configuration Language (SCL, Part 6)
Substation Automation Systems (SAS), which are is defined to describe the substation and the
composed of all the electronic equipment that automation system topology, as well as the
continuously control, monitor, and protect the net- communications-relevant configuration data of
work and its high voltage equipment, so as to avoid IEDs. Part 10 describes the recommended con-
unplanned network outages. formance testing for IEC 61850 compliance.
An SAS can be classified as a distributed soft real-
time system and represents one possible type of data The most important contents of the standard, which
acquisition and process control system. It is usually is applicable to this paper, are found in its Parts 7-x.
composed of 20–100 Intelligent Electronic Devices However, we need to introduce some few basic
(IED) which are connected by a high-speed commu- concepts found in other parts of the standard.
nications network with possibly routers and gateways.
Any device that can run executable code and provides 3.1. The basic IEC 61850 concepts
a data communications interface would classify as an
IED (e.g., an intelligent sensor, an embedded device, a The standard implicitly introduced a terminology
programmable controller, a workstation PC, etc.). that we conceptualised and explain with the help of
While some real-time critical functions are executed Figs. 2 and 3. We will only briefly visit those
more or less autonomously on a single IED, other concepts that are relevant to the discussion in this
functions are realised in distributed manner over many paper. More details on the standard can be found in
IEDs. the standard’s documentation set, as well as in the
UML Model itself.
The functionality of a substation automation
3. The IEC 61850 standard system is described by a blogical systemQ that is
comprised of the set of functions that operate in the
The IEC 61850 set of documents [1] is divided into substation environment. This is seen on the left
10 parts (Parts 1–10), but content-wise, circles around branch of the conceptual model in Fig. 23. Functions
five major topics, where all but the functional model can be thought of as high-level system operations,
have a normative character: e.g., bopen a high voltage switch (called breaker) to

! Functional modelling: a functional model of the

SA domain is conceived, but is mainly used to 3
The role annotations of associations are used to support the
derive the quality of service requirements on the reading of the conceptual diagram; for example, a Function is
communications system (standard’s Part 5). How- b+distributed overQ 1. . .n Physical Devices.
 T. Kostic et al. / Computer Standards & Interfaces 27 (2005) 679–695 683

Fig. 2. Conceptual model of the key terms used in the IEC 61850.

de-energise an overhead lineQ. Functions are con-

ceptually realised by (collaborations of) primitive,
atomic functional building blocks, the so-called
Logical Nodes (LN). The standard identifies some
90 predefined types of logical nodes in Part 7-4. The
physical configuration of an SAS is modelled as a
distributed system of interconnected devices, typi-
cally IEDs (right branch of Fig. 2). A certain SAS
function is considered distributed, if it is realised
through the deployment of its collaborating LNs to
two or more IEDs (see also Fig. 3, where Function
XYZ is realised by four LNs). LNs are logically
connected by the concept of a Logical Connection
(LC). In software architectural terms, an LC repre-
sents the connector between LNs; that is, it models a
communication association and thus abstracts the
protocol of interaction between two LNs [4]. The
abstract communications services are defined for
Fig. 3. An SA function is realised by a set of collaborating LNs LNs in Part 7-2 through the envisioned types of
distributed over IEDs. LCs.
684 T. Kostic et al. / Computer Standards & Interfaces 27 (2005) 679–695

The application data, which is exchanged over LCs ! LLN0, Logical Node Zero, for accessing data that
through the defined types of communications serv- is relevant for any Logical Device, as discussed
ices, is modeled and described by the concept of a later in Section 3.3.
Data Object (DO). Hence, it is the LNs that have
abstract communications services specified and that All other defined LNs are relevant to the SA
contain Data Objects, which they can make available application domain and its functionality. They are
as part of a data exchange. A Data Object defines the called Domain Logical Nodes and are divided into 12
structure and the semantics of the exchanged data groups. However, with the exception of the defined
items in the form of a well-specified, domain specific, LN naming scheme (i.e., the first letter in the four-
abstract data types. The standard defines about 30 letter LN acronym indicates the LN’s group, such as P
specific types of DOs. These predefined types are for Protection LNs), the LN grouping is used
generally called Common Data Classes (CDC) and informally only. In other words, it is a semantically
are described in Part 7-3. useful grouping, but there are no distinct properties
For easier understanding, Fig. 3 depicts an instance for the specific groups that would distinguish LN
diagram with a fictitious usage of the concepts as members as belonging to this or the other group.
shown in Fig. 2. Theoretically, the components of the
logical system have no predefined allocation to the 3.2.1. A concrete example
components of the physical system; that is, LNs may Almost all functions are realised by at least three
be distributed in any way and thus are not bound to LNs: one LN for the core functionality (bthe business
certain types of IEDs. Practically however, the logicQ), one for the process interface (i.e., the interface
performance-related requirements together with the to the substation high voltage equipment), and one for
limited physical resources (network band width, the HMI-related part. We show in Fig. 4 an example
processing power) constrain the number of feasible taken from Ref. [5], which realises three use cases.
mapping scenarios. The schematically depicted high voltage equipment
In summary, the IEC 61850 models described
above result in (a) a logical network, composed of
logically connected functional units and (b) a physical
network, composed of physically connected devices.

3.2. Logical nodes

The most prominent concept in the standard is that

of a Logical Node (LN). As mentioned earlier, it
conceptualises a standardised atomic functional build-
ing block from which applications are constructed.
Hence, each application function is conceptually
realised by, or composed of, a set of non-exclusive
LNs. The set is non-exclusive in the sense that the
same LN (class and instance) may be a part of the
realisation of different functions. LNs are the fulcrum
point for integrating the functional model with the
data model and the communications service model, as
will be discussed later in the context of Fig. 11.
There are two specific infrastructure LNs:

! LPHD, Physical Device Logical Node, for access-

ing data that is related to the physical condition
(the hardware) of an IED, and, Fig. 4. A simple protection and measurement example.
 T. Kostic et al. / Computer Standards & Interfaces 27 (2005) 679–695 685

(circuit breaker Q0, current and voltage measurement operator on request. The use case is realised by
transformers T1 and T2) is the relevant part of a the collaboration of TCTR-MMTR-IARC-IHMI.
substation to energise the overhead line to city X. The
SAS equipment consists of two physical devices: 3.3. Communications service model
IED1 and IED2. IED1 is a device similar to a
programmable logic controller. It is connected to Fundamentally, the data communications model of
IED2, a PC, via a LAN-type physical connection. the IEC 61850 assumes a domain data type model
IED1 and IED2 host seven and two instances of (discussed in Chapter 4 and illustrated by LNs in the
Logical Nodes, respectively. The LNs XCBR, TCTR, above discussion), and a relatively independent
and TVTR realise proxies of the physical equipment communications service model that we briefly intro-
(thus, their dependency association to the respective duce here. While the data model defines the semantics
switchgear), the LN IHMI realises the visualisation, and syntax of all the data that can possibly be
and the other LNs realise the specific business logic. communicated within an SAS, the communication
The example use cases are as follows: services define how to obtain such defined data from
IEDs.
(1) Display of operational measurements: The Part 7-2 of the standard details the Abstract
operational values of the overhead line, actual Communications Service Interface (ACSI), which
current in Ampere and actual voltage in Volt, models a set of communications services that an
must be displayed for operators. This use case is IEC 61850 compliant IED has to support. In general,
realised through LN instances TCTR-MMXU- Part 7 (7-1. . .7-4) assumes client–server architecture
IHMI (for current), and TVTR-MMXU-IHMI for the SA communications infrastructure, where an
(for voltage). IED provides one or more (ACSI) servers (see Fig. 5).
(2) Over-current protection for the overhead line: If A client will therefore gain access to the defined data
the measured current exceeds an adjustable limit of LNs through the ACSI services supported by the
the corresponding circuit breaker (Q0) needs to ACSI server. Conceptually, an IED contains one or
be opened. This is realised by the collaboration more ACSI servers, each of which contains a number
of TCTR-PIOC-CSWI-XCBR, whereby POIC of Logical Devices, each of which contains a number
encapsulates the measurement detection logic of Logical Nodes, which themselves finally contain
and CSWI the control logic for the circuit the Data.
breaker activation. If the ACSI server were seen as a black-box
(3) Revenue metering: The line measurements must component, one could represent an IED with its ACSI
be used for metering purpose (e.g., to do billing servers and the supported services as in Fig. 6. Every
for city X). Metered values shall continuously be defined service group would map to a service inter-
stored in 1-min intervals, but displayed to the face with its defined set of services.

Fig. 5. A conceptual model of the client–server model defined in Part 7.

686 T. Kostic et al. / Computer Standards & Interfaces 27 (2005) 679–695

terminology which are still present in the final

versions of the document.
We introduce the following four levels (see Fig. 7):

– Meta-Meta Model: It deals with the very generic

issues that the standard implicitly assumes. For
instance, in many places the editors of the standard
want to express that the data at hand can be
composed of other data; that is, data can be
complex or primitive. Complex means that it is
composed of other data, i.e., supports levels of
nesting. Primitive means that no further decom-
position is possible.
Fig. 6. The communications services of an ASCI server hosted by
an IED.
– Meta Model: This level describes all the basic but
still abstract concepts and the relationships among
the concepts that were specifically introduced for
3.4. Summary the standard. For instance, it defines that any LN
has a number of data attributes, so called Data.
In Section 3, we presented only as much about LNs However, it does not say what the specific LNs are
as needed to understand their relevance with respect to and thus what the specific Data for these LNs are.
functions and (very briefly) with respect to the The meta-model can serve as a basis to enforce
communications services model. rules that are relevant for every instance of a meta-
Section 4 will now discuss LNs and their relevance model concept. In general, the definitions at this
in the data type model. level are not even application domain specific, but
could be used for any other application domain

4. Data type model

The data communications model of the IEC

61850 relies on a domain data type model that
defines the semantics and syntax of all the data that
can possibly be communicated within an SAS. The
data model suggested in the standard is not easy to
understand. This is partly due to the inconsistent
terminology and partly due to the fact that there seem
to be implicit underlying data models (let us call it
meta-models or conceptual ideas) that would rather
have been made explicit to improve the reader’s
understanding.
To make up for this deficiency, we present an
original approach to explaining the data model of the
IEC 61850. It employs four conceptual levels. A
fashionable term for this approach is Meta-modelling,
i.e., models of models, or models to create models. By
presenting it this way, we hope to not only improve
the accessibility of the introduced data model but also
to make explicit the causes of much confusion, which
stems from inconsistent definitions and use of Fig. 7. Levels of meta-models in IEC 61850.
 T. Kostic et al. / Computer Standards & Interfaces 27 (2005) 679–695 687

latter is again just an instance of a Complex Data

Type defined in the Meta-Meta Model.

4.1. The Meta-Meta Model

Implicit in the data modelling approach is the wish

to express the construction of data types in the OO or
abstract data type fashion. In essence, several parts of
the Meta Model rely on the composition/nesting of
data types. Because this is not made explicit and the
terms such as members, attributes, properties, or
classes are limited, the editors of the various parts of
the standard have tried to express their desire of
describing complex data types with, sometimes,
awkward name creations. For instance, a bLogical
Node Class Data ClassQ refers to the same modelling
desire as a bCommon Data Class Data AttributeQ,
namely to model complex data types as a composite
Fig. 8. Example of meta-modelling structure for the case of two of data attributes. Thus, instead of defining a meta-
PIOC LN instances.
model (or Meta-Meta Model as in Fig. 9), every Part
of the standard defines such a generic construct with
that tried to define data models for distributed its own invented terminology.
systems. Thus, the basic and implicit model for all data
– Domain Type Model: On this level the concepts of modelling activities is one similar to Fig. 9. The
the Meta Model are made concrete. That is, here Meta-Meta Model is very simple and represents an
we find the named list of defined, SA specific, application of Composite pattern to our problem. It
LNs, Data, etc. It is here where the rich set of expresses that a data type (bComponentQ) is either
domain specific data knowledge and normative complex (bCompositeQ) or primitive (bLeafQ). A
definitions are found. The domain type model must complex data type is built from other data types;
make clear what the semantically interesting that is, it is composed of several data attributes and
information is and how it is represented and thus supports nesting. The contained data attributes
organised. can be complex (further nesting) or primitive. For
– Data Instance Model: For a concrete instance of some complex data types, the standard specifies a
an IED, the data instance model shows how fixed number of nesting levels. The IEC 61850 data
many instances of what domain data type are model is built from a few primitive data types (the
present on a certain IED and how these instances so-called Basic Types, see later in the Meta Model)
are named. and consequently, every complex data type must at
the end bunfoldQ as a collection of primitive data
As in any meta-modelling structure, every entity types.
on a certain level is an instance of its corresponding
entity on the next higher level. For example,
consider Fig. 8: a Data Instance Model contains a
specific IED (called IED1_StationX) with two
instances (PIOC1 and PIOC2) of the defined
protection LN called PIOC (Domain Type Model),
which in turn is an instance of the concept of a
Logical Node (in the Meta Model); that is, it follows
all the rules and relationships defined for a LN. The Fig. 9. Meta-Meta Model of the IEC 61850 data model.
688 T. Kostic et al. / Computer Standards & Interfaces 27 (2005) 679–695

Fig. 10. The Meta Model of the data model of IEC 61850.

4.2. The Meta Model In this section, we address a solution to the first
two points above, by proposing a Meta Model that
The complexity of the data type model of IEC (we believe) facilitates the understanding of the
61850 and, consequently, a difficulty in understanding overall data type system of the standard. The
it, stem from three sources: separation of communications and data models (point
3) cannot be eliminated, because this is normatively
(1) A meta-modelling approach was not introduced defined. We do, however, reflect this fact with the
in the IEC 61850 data model from the very corresponding constructs in the Meta Model.
beginning. Therefore, helper constructs such as The construction of the Meta Model relies on a
the CommonXXX types were created over time repeated application (or instantiation) of the Meta-
to provide a path to the domain types while still Meta Model. It introduces essentially three levels of
trying to keep the conceptual idea (Logical data refinement as depicted in Fig. 10.4
Nodes, Data, etc.) intact.
(2) Although the standard’s explanations of the – A Logical Node contains one or more Data. Each
data model (and the standard in general) Data is one of the defined Common Data Classes
employ the notion of object orientation and (CDC). The latter is the lead over to the Domain
particularly inheritance in several places, what
usually is meant is either a composite type or
subtype construct. 4
We have defined the Meta Model in the same UML model file,
(3) A separation of communications and data which contains the bnon-metaQ concepts with the same name. To
model concerns was not fully achieved (see avoid naming clashes, the meta-types have a name with the prefix
Section 4.3.2). bmQ.
 T. Kostic et al. / Computer Standards & Interfaces 27 (2005) 679–695 689

Fig. 11. A selection of the standardised domain-specific Logical Nodes shown as an excerpt of the UML model.

Type Model in that the CDCs stand for the set of In summary however, every Data of a Logical Node
normatively defined and commonly reused Data in is finally a composite of Basic Types (which, without
the Domain Type Model. doubt, follows tricky rules for its composition).
– A Data is composed of individual Data Attributes.
Each Data Attribute is unfortunately not just one of 4.3. The domain type model
any of the defined DATypes (standing for Data
Attribute Type), but one of the many FCDATypes The SA domain semantics is captured through (a)
(standing for Functionally Constrained Data the predefined set of Logical Nodes and their Data, (b)
Attribute Types5). They reflect the non-separation the set of predefined Common Data Classes and their
of communications and data model concerns, construction in terms of (c) the set of defined
introduced by definition of optionally up to two DATypes (which in our case subsumes all construc-
Trigger Options (TrgOp) and a mandatory Func- tions of FCDATypes). All this is covered in Parts 7-4,
tional Constraint (FC). 7-3, and 7-2 of the standard.
– The basic types to create FCDATypes are the
selected (primitive) Basic Types and complex 4.3.1. Logical nodes and common data classes
types created from them. They are all referred to The domain type model defines 89 types of
as DATypes6. The complex data types are either Logical Nodes (plus LLN0 and LPHD), which belong
those defined in Part 7-3 as Common Data to one of the 12 defined LN groups (LLN0 and LPHD
Attribute Types or those defined in Part 7-2 as belong to a 13th group). Fig. 11 shows some LN
Common ACSI Types. groups and the concrete Logical Nodes they contain.
In addition, dependencies on the functional require-
ments for Logical Nodes (Part 5 of the standard) are
explicitly shown.
5
This is one more example of an unfortunate naming: with Fig. 12 gives an example of the small LN GroupX
respect to what this type is used for, it should have been with one of its two LNs: XCBR. An LN is depicted
Functionally Constrained Data Attribute, or FCDataAttribute (i.e., with its named attributes such as, for instance,
without bTypeQ suffix).
6
With respect to what this type is used for, a more appropriate
MaxOpCap. These attributes are either optional
name would have been simply DataAttribute, instead of DAType (cardinality 0..1), or mandatory attributes (those found
(i.e., without the bTypeQ suffix). in the attribute compartments of the class boxes). The
690 T. Kostic et al. / Computer Standards & Interfaces 27 (2005) 679–695

Fig. 12. Domain LN GroupX with one of its LNs and their data.

named attributes of an LN, in other words its Data, are Data. Fig. 13 depicts some out of the 29 Common
the named instances of CDCs (see the meta-model in Data Classes defined explicitly in the standard, as well
Fig. 10 and some defined types of CDCs in the as (again) 29 specialisations, which are only implicit
domain type model of Fig. 13). For every concrete LN in the standard, but explicitly specified in the UML
of the domain type model, the standard defines up to Model. Those specialisations are due to enumerations
41 Data instances, of which some are mandatory and (26) and to the btransientQ property for three CDCs.
some are optional. All together, there are about 500 The specialised CDCs are easy to recognise, since
defined Data. Note that it is only the name of a Data their names are longer than three characters.
and perhaps the context, i.e., the type of LN that Although the CDCs are divided into categories
determines its domain specific semantics. (StatusCtl, AnalogueInfo, etc.), it needs to be noted
In general, the defined CDCs and their construction that the relation of a specific Data name to CDC type
can be viewed as the underlying standardised generic is not unique! For instance, depending on the
type system. The type system is generic in the sense invocation context (i.e., the communication service
that it would not only be applicable to many power invoked on an instance name), the named Data bAmpQ
system applications, but also in the sense that it (current) could be an instance of CDC type Measured
provides the basic types for defining domain specific Value (bMVQ) or type Sampled Value (bSAVQ).

Fig. 13. A model excerpt with a selection of standardised domain-specific Common Data Classes.
 T. Kostic et al. / Computer Standards & Interfaces 27 (2005) 679–695 691

In general, a Data is composed of bData FCDATypes that are based on Common Data Attribute
AttributesQ (see again the meta-model in Fig. 10). Types. The UML Model contains more such diagrams,
However, these data attributes are complexly con- which define FCDATypes based on all the other
structed data types (the aforementioned FCDATypes, DATypes, namely, Common ACSI Types and Basic
that are discussed in Section 4.3.2 below). Fig. 14 Types (including enumerations). Note that the FCDA-
shows the specification of the Common Data Class Types are not explicitly (normatively) defined in the
SPS (single point status) in terms of its constituent, standard. The type naming convention that we used is
optional (like subEna, etc.) or mandatory data as follows: DAType_FC[_TrgOp1[_TrgOp2]]. A con-
attributes (such as stVal, q, t). The permissible types crete example from Fig. 15 is Vector_MX_dchg_dupd,
for these data attributes are the defined FCDATypes where DAType=Vector, FC=MX, TrgOp1=dchg and
(e.g., BOOLEAN_SV for subEna). TrgOp2=dupd.
The definition of FCDATypes in terms of TrgOp
4.3.2. FCDATypes and FC, in addition to DATypes, causes a tight
FCDATypes are based on the three DATypes (see coupling between communications and data type
again the meta-model in Fig. 10): Common Data models. Both TrgOp and FC represent a semantic hint
Attribute Type, Common ACSI Type and Basic Type. for some services (mentioned in Section 3.3). FC, in
Conceptually, an FDCAType could be seen as an addition, restricts DATypes with respect to services that
extension (or subtype) of one of the DATypes. The are applicable to it. In a general case, according to the
extension would then consist of defining a mandatory current specifications in the standard, it is impossible to
Functional Constraint (FC) and up to two optional use any of services directly, i.e., to say, for example,
Triggering Options (TrgOp). However, some FCs that all the services of Data apply to an FCDAType with
really constrain the bnormalQ functionality of a given FC. In other words, a FC must bcarryQ
DATypes, such as bdisablingQ some DATypes services. somewhat strange combinations of methods from
This prevents one from concretely defining FCDA- different services. This is the reason for representing
Types as extensions (subtypes) of DATypes—they each FC as an interface with appropriate combination
must be defined as composition. In OO terms, this of services, according to the specification in Part 7-3.
corresponds to the idiom busing delegation instead of The above discussion should be a sufficient
inheritanceQ. Fig. 15 gives a selection of those illustration on how awkward the FDCAType concept

Fig. 14. The SPS Common Data Class in more detail.

692 T. Kostic et al. / Computer Standards & Interfaces 27 (2005) 679–695

Fig. 15. A selection of FCDATypes based on Common Data Attribute Types (excerpt of the UML model).

is, and how tight is the coupling with communications the standard at the place of their definition (Part 7-2 or
services on the level of domain data types. 7-3), to be able to bformally nameQ an additional set of
types. In our opinion, it would be sufficient to
4.3.3. DATypes distinguish between Basic Types, which are primitive
An FCDAType is based on DATypes, Data Attribute (e.g., BOOLEAN, INT8, FLOAT32, ENUMER-
Types (see again the meta-model in Fig. 10). A DAType ATED), and the complex DATypes (see Fig. 16), along
may be one of the defined (primitive) Basic Types, or a the line of the Meta-Meta Model in Fig. 7.
complex type that is composed of Basic Types. Such The standard introduces ENUMERATED as an
complex types are defined as Common Data Attribute abstract type for enumerations, but it does not
Types in Part 7-3 or as Common ACSI Types in Part 7- normatively define concrete ENUMERATED types.
2. Basic Types are also defined in Part 7-2. These This results in ambiguous informal definitions (e.g.,
different sub-types of DAType have been introduced in enumerations that have no type names, or that have no

Fig. 16. A selection of Common Data Attribute Types.

 T. Kostic et al. / Computer Standards & Interfaces 27 (2005) 679–695 693

attribute values) throughout all the Parts 7-2, 7-3 and 7- stration of what can be done with a formal model and
4. As an attempt to reinforce the formality in type appropriate tools. By this, we hope to stir discussions
definitions, the UML Model defines the enumerations that would consider making the UML Model an
explicitly. For example, bUnitQ in Fig. 16 has the integral part of the standard or one of its next releases.
mandatory attribute bSIUnitQ and the optional attribute We think that further benefits arise in the development
bmultiplierQ. Their types are bSIUnitsQ and bMultiplierQ, and the maintenance of the standard as well as in the
respectively, and both are typed enumerations. use of it. In particular, we would like to stress the
following points, taken from Ref. [8]:

5. Benefits 5.1. CASE tool support

The deduction of the Meta Model (level 2) from The rigorous UML model, maintained with a CASE
the specifications in Parts 7-4, 7-3 and 7-2 of the IEC tool, inherently provides consistency with respect to
61850, and then the definition of the Domain Type the defined bvocabularyQ (concepts and concept
Model (level 3) in the UML Model revealed a number relationships). Based on this, tools may then provide
of inconsistencies in the current standard’s documen- a wealth of features such as pop-up menus to select
tation set. For instance, since 2002, when we started to available types, support propagation of changes, etc. It
model early drafts the IEC 61850 standard, we were is also easy to display for a specific type all the
able to identify many inconsistencies and problems. attributes (inherited or not), operations, associations
Over a hundred comments were sent to the IEC 61850 and their cardinalities. This facilitates checking of the
authors. Some of them were incorporated bas isQ in the logical correctness of the type definition. The possi-
standard, while others triggered discussions and bility to selectively display the model elements of
clarifications, and again others were not considered interest on a class diagram allows one to create
at all. complex diagrams, such as the full version of what is
We have used some parts of the UML Model to depicted in Fig. 14, while keeping their partial display
implement a prototype tool [6], which converts some manageable. CASE tools can usually provide comple-
parts of the IEC 61850 model into another electrical mentary views of the model on the same screen. For
utility related data model: CIM, standing for Common instance, UML diagrams, the model browser, and the
Information Model. CIM has recently been published model element documentation may appear simulta-
as one part of the IEC standard 61970 [7]. The neously. Consequently, it is easy to navigate between a
prototype tool development was realised by computer UML model element in the browser and its representa-
scientists, which had no previous domain knowledge, tion in a class diagram, while still having informal,
neither on substations, their devices and communica- textual annotations of the selected element. Providing
tions, nor about electrical networks in general the same level of checking and comfort for the informal
(covered by CIM). In that context, the Meta Model definitions based on text documents, even with an
and the Domain Type Model, both realised in the elaborate hyperlinking scheme, is almost impossible.
UML Model, proved extremely useful.
Another use of the UML Model has been to 5.2. Model maintenance and extensions
automatically generate text documentation of Part 7-4
of the IEC 61850, which is almost identical to the The formal model makes the model maintenance
format of the original MS Word documents. The big easier. It allows for consistent modifications from one
difference is, however, that in the automatically version of the standard to another. For instance, if a
generated version the table entries are absolutely type name is to be changed, it is done and potentially
consistent. For this purpose, we have used another documented at one place within the model. This
Rational tool, SoDA, to develop a highly customised supports impact analysis and regression testing of
template and to autogenerate the Part 7-4 bcloneQ planned modifications. Contrast this to the changes
directly from the UML Model. We have submitted the necessary at several places in at least three documents
resulting document to the IEC editors, as a demon- in the standard and the subsequent activities to assess
694 T. Kostic et al. / Computer Standards & Interfaces 27 (2005) 679–695

further implications. A further argument for the UML 6. Conclusions and outlook
model is the ease for programmers to extend the
model with potential private, vendor specific exten- All of the abovementioned points show potential
sions while preserving the compliance with the benefits of having the IEC 61850 standard itself
standard and its base model. specified formally: (1) with a tool, (2) in a standard
modelling language, and (3) in an electronically
5.3. Code and documentation generation processable format. We have presented how an
informal btext-and-tableQ definition of the IEC 61850
UML models can be used for code generation, data communications standard can be formally mod-
which includes the direct use of inheritance relation- elled using meta-modelling approach and the UML.
ships defined in the model. CASE tools also usually Besides facilitating human comprehension, the bene-
support roundtrip engineering. Both features facilitate fits of such a formalisation are numerous and take
the developers’ tasks. Finally, the model documenta- advantage of the power of CASE tools. Such tools
tion and, if needed, the code documentation can be support easy navigation in the model, validation
automatically generated from the same model. For (typically, unknown classes will be identified imme-
instance, with the use of advanced documentation diately), and consistent maintenance (which is prob-
plug-ins, we were able to reproduce the text and table ably the hardest to meet with standards provided in
look of the standard from the UML model. Moreover, text-and-table form). Moreover, software code (at least
other representations can be produced automatically, the skeleton, including the profile of the methods) can
such as W3C XML (with some limitations obviously) be generated automatically, thereby reducing the effort
or RDF schemas for data serialisation. of developers and avoiding mistakes. Additionally, for
those not familiar with UML CASE tools, text
5.4. Formal data mappings or conversions to other documentation can be generated automatically too,
standards and be it in a stylish text-and-table format, if so
expected by domain experts.
The devices and applications, which implement the Our hope is that, similar to what has been done
IEC 61850 specification, are not restricted to the with CIM and its UML model, some of the future
substation automation domain. They have to inter- revisions of IEC 61850 will adopt this kind of
operate with systems and applications in the entire approach, i.e., to have a formal model included at
electric utility environment. In that sense, they do not least for the data specification part. This would
only communicate with each other within a substa- certainly facilitate the acceptance and speed up the
tion, but also with network control centres or even market penetration of compliant devices.
back-office applications. The UML model allows one
to specify mappings to other existing UML models in
a formal way. An example of such a mapping of the Acknowledgements
proposed UML Model for the IEC 61850 was our
mapping to CIM (Common Information Model). The authors would like to express their gratitude to
Details can be found in Ref. [6]. CIM specifies a the anonymous reviewers of this paper. Their feedback
data model as part of an IEC standard [7] for electrical was well to the point and improved the final result.
network control centres. Another mapping of the data
model is that to lower communication layers. For
instance, the UML model of the IEC 61850 should References
also facilitate a formal mapping to the Manufacturing
Messaging Specification (MMS [9]). MMS is indeed [1] IEC-TC57-WG10/11/12, Communications Networks and Sys-
one of defined application layer protocols defined in tems in Substations, International Electrotechnical Commission,
Geneva, International Standard IEC 61850-1..10, 2003.
the IEC 61850. Hence, the standard defines appro- [2] G. Booch, I. Jacobson, J. Rumbaugh, OMG Unified Modeling
priate communications mappings in Part 8-1, but Language Specification, Version 2.0, Object Management
again in text-and-table fashion. Group, Specification, 2003.
 T. Kostic et al. / Computer Standards & Interfaces 27 (2005) 679–695 695

[3] T. Kostic, O. Preiss, IEC 61850 UML Model, Rational Rose Otto Preiss holds a B.Sc. in Electrical
model file, IEC61850_May2004.mdl, v.6, ed. Daettwil: ABB Engineering (FH Aargau, Switzerland), an
Switzerland Corporate Research, May 2004 (contact the MSc in Computer Science (University of
authors). Colorado at Boulder), and the Dr. ès
[4] M. Shaw, R. DeLine, G. Zelesnik, Abstractions and Imple- Sciences degree from the Swiss Federal
mentations for Architectural Connections, Proceedings of the Institute of Technology in Lausanne
Third International Conference on Configurable Distributed (EPFL), Switzerland. He has worked for
Systems, 1996. more than 10 years in the area of distributed
[5] O. Preiss, A. Wegmann, Towards a composition model problem systems, mainly in the application domains
based on IEC61850, in: The Journal of Systems and Software, of data acquisition and process control for
vol. 65/3, Elsevier Science, 2003, pp. 227 – 236. power systems. Otto held different posi-
[6] T. Kostic, O. Preiss, C. Frei, Towards the formal integration tions in development, engineering, commissioning, and product
of two upcoming standards: IEC 61970 and IEC 61850, Proc. management. Before he joined ABB Corporate Research in May
of 2003 LESCOPE Conference, Montreal, May 7–9, 2003, 1998 he was heading ABB Power Automation’s R&D department
pp. 24 – 29. for product and system development of substation automation and
[7] IEC-TC57-WG13, Energy management system application protection systems. He is currently program manager of the Power
programming interface (EMS API)—Part 301: Common T&D Applications research program within ABB group.
Information Model (CIM) Base, International Electrotechnical
Commission, Geneva, International Standard IEC 61970-301, Christian Frei holds a diploma in Com-
2003. puter Science and the Dr. ès Sciences
[8] O. Preiss, T. Kostic, C. Frei, Data communications standards: a degree from the Swiss Federal Institute of
case for the UML, To be Presented at UML 2004 Conference, Technology in Lausanne (EPFL), Switzer-
Lisbon, Portugal, October 11–15, 2004. land. He received the 2000 ECCAI Artifi-
[9] ISO 9506-1 and ISO 9506-2: Industrial automation systems— cial Intelligence Dissertation Award for his
Manufacturing Message Specification; first edition, 2000-08-15. PhD. He then joined the start-up he
cofounded, Iconomic Systems S.A., where
Tatjana (Tanja) Kostic holds a diploma he was CTO and system architect. Late
and an MSc in Electrical Engineering from 2001, he joined ABB Corporate Research,
the University of Belgrade, Yugoslavia, and where he is currently working as a research
the Dr. ès Sc. Techn. degree from the Swiss scientist in the Software Solutions and Processes group. His
Federal Institute of Technology (EPFL), research interests include constraint satisfaction, abstraction and
Lausanne, Switzerland. After her post doc problem reformulation techniques, web services, peer-to-peer
year with Mitsubishi Electric, Amagasaki, computing, ontology languages, graph theory, and resource alloca-
Japan, she joined ABB Corporate Research tion problems in general. He is a member of the IEEE Computer
in Switzerland in June 1999, where she is Society, and the ACM.
currently working as a principal scientist in
the Utility Solutions group. Her research
interests include IT applications for power system operation and for
utility asset management, standardised utility domain models,
object-oriented analysis and design, and artificial intelligence. She
is a member of the IEEE PES and Computer societies, of the ACM,
a working member of the Cigré WG C2.01, and an IEC expert in
TC57 WG14.