Device Independent Specification of a PAC System

Abstract
This article shows the power of IEC61850 modeling for SAS specification. It describes
how IEC 61850 artifacts like SSD file and Functional Names are combined with non IEC
61850 specification items into a Template Library and how this library is related to the
different phases of the SAS project process. The overall goal is to enable utilities
mastering IEC 61850 in an elegant and simple way all over the SAS and Substation Life
cycle.

Why do we want to improve specification?

The migration towards renewable energies and smart grid technology requires
innovation and investment. Utilities are under pressure to decrease costs without
compromising the reliability of their services. It is proven that IEC 61850 helps to lower
the hardware and wiring costs of an SAS. On the other side there have been high
adoption costs for the new technology and whilst interoperability is achieved, the
solutions delivered by different suppliers are very inhomogeneous. Engineering, testing,
commissioning and maintenance costs did not come down as expected. Utilities are
facing a situation where they have to maintain an increasing number of IEC 61850 SAS
with different hardware and software versions and with different implementation
philosophies. Instead of hard wired protection schemes they have to deal with
proprietary IED configurations and communication configuration files which are not
really human readable. (XML). Utilities are losing grip on their intellectual assets. Will
they be able in the future to take active responsibility for their SA installations or will
they become completely dependent on the SAS suppliers? Being a software
communication protocol IEC 61850 is one of the reasons for this loss of intellectual
property, but at the same time it offers the means to overcome this problem. That is
what this article is about.

Birds view on the SAS Engineering Process

Utilities avoid to invent the wheel multiple times. They perform a concept and standard
development work independently of the ongoing substation automation projects.
(Concept and Standardization Phase). This phase includes very often also frame
agreements with IED suppliers. In this phase they develop a Design Concept
Specification which is effectively the policy and design manual for the utilities
requirements for any substation. They also create something like a System Design
Manual which provides detailed building blocks for an SA system- e.g. specific functions,
specific signals etc. Finally utilities may create IED specification documents used as base
for frame agreements with vendors.
Based on these documents the utility can issue a Specific Project Specification which
may reference or be associated with the Design Concept documents, includes IED

1
specifications and gives additional guidance on the specific project application.
Currently there is an interesting work ongoing at CIGRE Australia lead by Rodney
Hughes, about SAS documentation, where you can find also details about this process
(WG B5.39 DSAS Documentation).

Ongoing specification work….

Concept and Standard Design

Design Design Frame
Specification Manual Agreement

…applied to each SAS project

SAS SAS Commissioning

& Maintenance
Specification Design TEST

Figure 1. Bird view on SAS Process

The system design performed by the System Integrator has to meet the specifications
stated in the documents named above. During FAT the utility can validate the system
design and during SAT it can validate the final delivery. Then the system enters into the
maintenance phase. Let us now focus on the Concept and Standardization Phase and
how to build the Substation Specification for a particular SAS project.

There are two key factors for cost efficiency and reliability:
• Standardization
• A formalized and repeatable process (specification, design, testing( FAT SAT),
maintenance)

Trying to accomplish standardization, utilities are putting a lot of effort into specification
documents and frame agreements with vendors, but
How to successfully define and maintain standards if IEDs are under
constant evolution and if the standards are highly dependent on the
implementation philosophies of different vendors?

and

2
 How to implement a formalized process when different suppliers design
SA systems following different philosophies?

There are many different ways to define "Bottom Up " and "Top Down" process. Let us
for now assume the following definitions:

Bottom Up Engineering:
The specification is done exclusively as high level text documents. The System Integrator
starts the design by configuring the IEDs to meet the high level specification. In this
process he will have to make a lot of detailed design choices. Generally he also provides
the test plan for FAT and SAT.

Top Down Engineering

The specification is detailed. It contains not only a textual part, but also formal
specification files (System Specification Description-SSD, IED specification Descriptions-
ISD) with detailed object information. The textual part is consistent with the formal part.

Bottom Up

• Classic textual specification

• Design and test plan provided by System Integrator

Top Down

• Textual + formalized specification

• Design following specification
• Tool supported validation of deliveries (SAS and
Documentation) against the specification

Figure 2. Top Down versus Bottom Up

The System Integrator has not many choices left. The design follows the specification.
Being formalized, test plans can be derived from the specification. Design and deliveries
can be validated automatically against the specification. Surely utilities have to put more
effort into the Concept and Standard Design Phase. However the gain in control over
the delivery and the preservation of the utility specific know how is worth this effort.
SAS projects will become cheaper in execution. The quality of the deliveries will
improve. The SAS design will be harmonized and easier to maintain.

3
 Comparision

Top Down Bottom Up

+ High degree
of stan-
dardization

Reduced
supplier
dependency

Lower
- Huge initial
effort to
create
standards

More
responsibility
+ No additional
specification
effort of utility
required
Complexity of
solution
remains with
supplier
- Deliveries
hard to
control

Less stan-
dardization
due to design
variations

maintenance Expensive to
costs maintain

Preservation
Loss of
of intellectual intellectual
assets property

Figure 3. Comparison "Top Down" and "Bottom Up"

Now let us have a closer look on how to create such a formalized and standardized
specification.

A View on IEC 61850 Modeling

One for ALL
IEC 61850 is a powerful collection of communication protocols for Substation
Automation Systems. It supports transmitting of bulk data, high speed events for
protection functions, synchronized transmission of waveform samples, file transfer and
finally also powerful online services for testing, commissioning and other purposes. In
terms of real time behavior these protocols are very different, but one thing they all
have in common: They are using the same standardized and semantically meaningful
data representation. On application level a protection start indication like

L01F301LD0.PHLPTOC1.Str.general[ST]

is a standardized notation which is used e.g. when sending data to the network control
center as well as when sending a trip from one relay to another. Having one
standardized data notation for all the different protocols is one big advantage of IEC
61850.
Functional Naming and Product Naming
IEC 61850 defines a data point unambiguously based on its
• context and
• semantic notation

4
The context identifies the source where the data originates from. IEC 61850 defines two
different types of contexts. The functional context is defined by the power system or
substation itself. The product context is defined by the secondary automation and
protection equipment. Figure 4 shows the position information of a circuit breaker using
the functional context (upper part) and the product context (lower part). Please observe
that the semantic notation (right part of the name) is the same for both
representations. This is a very important point when it comes to the task of mapping
control and automation functions to the physical process.

Figure 4. Function Naming versus Product Naming

Functional Naming and Product Naming are standardized. This implies that IEC 61850
defines a formal data model for the functional and product context and data definitions
for the semantic notations. ( Logical Nodes and Data Objects). The data definitions are
ruled by a sophisticated system of Data Types (Logical Node Types, Data Object Types
derived from Common Data Classes, Data Attribute Types and Enumerations).
In the past most of the IEC61850 systems were engineered following a bottom up
process. The bottom up process as well as the runtime data exchange make use of the
Product Naming. Mapping of data points to the process using IEC 61850 Functional
Naming was out of the scope of these projects. And so an enormous potential of cost
saving and standardization was missed!

Device Independent Specification

The part of the IEC61850 data model which defines the functional context allows the
description of
• Single Line
• Functions
• IEC 61850 Logical Nodes and Data Types

Using this part of the model a utility can create a device independent specification. Such
a file is called SSD file. SSD stands for System Specification Description. Sometimes
people say the SSD file is useless. This is the point of view of a System Integrator, who
feels free to deliver a design following his own philosophy or standards. For a utility the

5
use of an SSD file is a first and very important step towards standardization.
The SSD file defines utility specific names for all single line elements. Suppliers will have
to use these names. In a formalized process it will not be acceptable that supplier 1 uses
"Q0", supplier B in the next project uses "QA1" if the utility specifies "S" as name of the
Circuit Breaker in the SSD file.
The utility uses the SSD file to define and allocate automation and protection functions.
In conventional specification documents functions where described by free text. The
SSD file does not replace this kind of specification, rather it completes it by adding
formal elements. A Function in the SSD file contains one or more Logical Nodes and the
Logical Nodes define a set of the Data Objects belonging to this Function. When the
system integrator delivers the functional design in terms of an SCD file the utility can
check the design against the SSD file:

• Are all specified Functions implemented ?

• Is the allocation of the Function to the process as specified?
• Does the implemented Function provide all signals (Data Objects) as specified in
the SSD?
• Are the signals implemented as specified or are the implemented differently

Beyond the content of SSD files

Today many utilities use Excel based Signal Lists. If you have a closer look on these Excel
files you will find the same information that we have also in the SSD file and even more.
However Excel files are not standardized and they cannot be validated and compared
without proprietary macro programming. They are not interchangeable between
different tools without specific data mapping.
In addition to the content of the SSD file the Excel sheets contain very often data
instance information such as a user defined signal name and additional attributes like
NCC addresses or HMI texts. In most cases we also find routing information in these
files.
As long as the formal SSD file has no support for such data, Excel Signal Lists can and
even should be part of a formal specification. The important point is that they are
consistent with the SSD and created by the System Specification Tool in this way.
With this we state that a formal System Specification for an SAS project is a consistent
set of

• Textual Specification
• SSD File
• Signal List

It is the SSD file that gives the Single Line oriented structure to all these files. Voltage
Levels, Bays, Functions, Equipment etc. are defined in the SSD. The Textual Specification
uses the same structure and names as in the SSD. The same is valid for the values in the
Signal List.

6
 Textual Specification SSD File Data Points & Data Flow

Substation

Voltage Level
Älüo üocnüo ncc3e¨firv bht iopem nxbg zzu xfvzox Älüo
üocnüo ncc3e¨firv bht iopem nxbg zzu xfvzox Älüo üocnüo Bay(Type)
ncc3e¨firv bht iopem nxbg zzu xfvzox Älüo üocnüo ncc3e¨firv
bht iopem nxbg zzu xfvzox Älüo üocnüo ncc3e¨firv bht iopem
nxbg zzu xfvzox Älüo üocnüo ncc3e¨firv bht iopem nxbg zzu
xfvzox Function

LNode
LNode
LNode

Textual Function Detailed Signal

Description of allocation in and Signal flow
Function Single Line and information for
Logical Nodes Function

Figure 5. Consistency between specification documents

Looking at the Functional Name of the circuit breaker position signal in Figure 4 we can
state:
• There is no dependency on any implementation or vendor specific data.
• The entire signal name is composed of elements where the utility is in control of
• The entire name follows IEC61850 standard and has a semantic meaning

As long as we describe all signals and signal attributes in terms of Functional Naming we
remain totally IED independent. If we describe the information exchange as signal flow
between Functions we can define our control and protection function without using
IEDs.
The example in Figure 6 shows a bus bar protection application where the protection
functions for the line feeder bays send a blocking signal to the incoming transformer
feeder protection. The picture shows the 3 sending functions and the receiving Function
in an IED independent way.

Figure 6. Device independent Signal flow

7
This representation can be used to describe the data flow part of control and protection
applications. It allows to express the essential domain specific logic and information
exchange, without mixing IED specific details like internal routing, function matrix,
GOOSE subscription over GGIO etc...

Device Dependent Specification

When utilities develop frame agreements with IED vendors they have a clear idea how
to use the IEDs. The allocation of functions to the IEDs can be defined as well as the
mapping of Logical Nodes and the Data Types which provide the needed Signals.
Communication configuration can be described in terms of Datasets and Control Blocks.
All this information can be expressed with SCL. The utility creates an ISD File. The ISD file
is the formal specification of IEDs or IED Types that the utility imposes to the IED vendor
as part of the frame agreement.
By associating the ISD Files with the specification documents a device dependent
specification can be created.

SSD File ISD File

Substation IED (Type)

Voltage Level Logical devie

Bay(Type) LN
LN
Function
LN

LNode Data Set

LNode Control Block
LNode

Compatible
Data Types

Figure 7. ISD File matching the formal specification

Template Libraries
We have seen how a formal specification looks like. Now we are going to look at how
these documents are related to the process and how we can organize them in libraries
in order to have an efficient and reliable workflow when it comes to create a project
specific Substation Specification Figure 5 and Figure 7 apply to a SAS Project

8
Specification. It only requires a small change to transform them into a representation
usable for the Concept and Standardization Design. In the SSD file, use "Bay Type"
instead of "Bay" and in the ISD File use "IED Type" instead of "IED". By doing so we get
building blocks for a Template Library. This Template Library is one of the results of the
Concept and Standardization Design Phase.

Template Library
Text Bay & Data Points &
Blocks Function Data Flow
Types

System
Specification
Tool

Textual SSD Project

Specifcation File Signal List

Figure 8. Usage of the Template Library to create an SAS Project Specification

Figure 8 is showing how to create a consistent SAS project specification from a data
flow point of view. The Template Library can be IED independent. In this case we have a
Specification Template Library. If we bind ISD/ICD Files consistently into this library, we
get a library with nearly complete engineering information. This kind of library we call
Engineering Template Library. Details on how to build such a library and how to use it
for engineering are beyond the scope of this article. Please feel free to contact the
author if you are interested in this subject.

User Interface Metaphor for System Specification Tool

Another interesting question remains: What is an appropriate user interface metaphor
to perform this specification work? The System Specification Tool shall allow to create
an IEC 61850 specification without requiring deep IEC 61850 knowledge. The project
engineer shall be enabled to work with objects of his original domain:
e.g.:
• Bays
• Primary Equipment
• Protection Functions

There is one artifact that combines all of these domain items in one representation: It is

9
the Single Line Diagram. So let the System Specification Tool allow the user to draw the
Single Line and to allocate control and protection functions. Based on this input the
System Specification Tool shall gather the proper elements from the Template Library
and build the specification files.

User draws Single Line and

allocates Functions

System Specification Tool

SST creates Specification

from Template Library

Textual SSD Project

Specifcation File Signal List

Figure 9. User interface metaphor for System Specification Tool

Conclusion and Outlook

We have shown the power of IEC 61850 modeling to create a device independent,
standardized and formalized SAS specification. The method is supported by tools and
has been proven in several projects. Ongoing work is dealing with Engineering
Templates. This work is targeting to allow automated communication configuration
based on the Engineering Template Library.

Author:
Jörg Reuter
HELINKS LLC
jr@helinks.com

10