Paris 2020
  B3‐302 
 
 
 
 
Data to Decisions: Future‐proof Integration of Substation Intelligence

    G. RAJAPPAN, P. JONES         D. EROL, V. GLINIEWICZ, Y. WU 
Doble Engineering Company           Vattenfall 
       USA                 Sweden 

SUMMARY 

Sensors,  communications,  and  analytics  technologies  are  advancing  rapidly.  These  technologies 
proffer  benefits  to  organizations  that  are  able  to  leverage  them.  In  addition  to  increased 
productivity, they serve as a recruiting tool for the technology‐savvy new generation of workers. 
But traditional substation architectures, with a preference for hardware over software, hardwired 
communication  networks  over  software‐configurable  architectures,  and  point‐to‐point  data 
integrations over a services‐centric approach, impede the adoption of such technologies.  
 
Vattenfall, a large European utility company, along with Doble Engineering, a USA‐based provider 
of  sensor,  data,  and  analytics  solutions,  undertook  a  project  to  develop  and  implement  an 
architecture for integrating substation data sources with Enterprise data consumers in a scalable, 
seamless,  and  secure  fashion.  A  key  prerequisite  for  this  architecture  was  that  it  should  be 
standards based; where industry standards didn’t exist or were still being developed, we adopted 
a  best  practice‐based  approach.  The  goal  was  to  ensure  repeatable  results  built  on  a  solid 
foundation  and  to  avoid  vendor  lock  resulting  from  the  purchase  of  proprietary  systems.  The 
standards  that  were  leveraged  in  this  effort  include  IEC  TC57  Reference  Architecture,  IEC 
Common Information Model, as described in the IEC 61970 and IEC 61968 series of standards, IEC 
61850,  RESTful  web  services,  ISO  55000  for  asset  management,  services‐oriented  architecture, 
and  Purdue  Model  for  Control  Hierarchy.  This  paper  discusses  the  challenges  and  the  lessons 
learned in this project. 
 
KEYWORDS 

Digital  Substations,  Common  Information  Model  (CIM),  IEC  TC57  Reference  Architecture, 
Substation  Engineering,  Condition  Based  Maintenance,  Asset  Management,  Asset  Health  Index 
(AHI), Analytics, Enterprise Service Bus (ESB). 

grajappan@doble.com 1
Introduction  

Emerging  asset  management  applications  are  data  and  analytics‐centric  and  aim  to  provide  full 
lifecycle management of assets. In order to enable this, all pertinent data need to be accurately 
maintained and available on demand to various applications, each of which may be focusing on a 
different  asset‐related  use  cases.  There  are  several  use  cases  that  pertain  to  substation  assets, 
such  as  condition‐based  asset  management,  protection  planning,  and  security 
monitoring/management.  The  applications  that  support  these  are  increasingly  incorporating 
sophisticated analytics, including machine‐learning algorithms, which require all available relevant 
data. There is the need for an architecture and infrastructure that supports this need. 
 
We  undertook  an  effort  to  develop  and  implement  a  standards‐based  architecture  that  would 
enable  current  day  as  well  as  future  analytic  applications.  Every  aspect  of  our  approach  was 
standards  or  best  practices  based  and  designed  with  the  mindset  of  scalability  and  incremental 
upgradability  to  enable  future  data  needs.  One  manifestation  of  this  is  the  preference  for 
software  over  hardware.  For  instance,  we  favored  a  software  gateway  for  substation  data 
collection. Another manifestation is the use of emerging and popular standards. We utilized IEC 
61850‐90‐2  and  REST/JSON  web  services‐based  interfaces  for  communication  of  data  from  the 
substations to the Enterprise, wherein we used an IEC Common Information Model (CIM) adapter 
to  convert  the  data  to  CIM‐friendly  semantics.  We  also  adopted  digital  substation  concepts, 
including IEC 61850 substation engineering process. We utilize this even for legacy protocols – in 
our case Modbus. In the following sections, we describe various aspects of our approach. 

Goals and Architectural Principles 
 
For this study, the following were the business use cases of interest: 
 
 Asset Management:  Perform maintenance based on the condition of the asset and not 
based on a predefined time interval. This can help reduce maintenance cost and failure 
risk. 
 Operation: Better decision support for operations through access to the Asset Health 
Index. 
 IT: Avoids costs linked to complex integrations where standardized information sharing is 
not employed. 
 Data Security: Secure acquisition of data from the substation and provision to various 
analytics applications in the enterprise. 
 
Our  overall  approach  was  based  on  the  reference  architecture  recommended  by  IEC  Technical 
Committee 57 (TC57), and it covered information flow across various domains, from the Process > 
Field  >  Station  >  Operation  >  Enterprise.  As  the  information  flows  from  the  process  domain  to 
enterprise domain, appropriate standards are utilized, such as IEC 61850 closer to the process and 
CIM closer to the enterprise. This is shown in Figure 1.  
 
Our goal was to develop a modular and layered architecture utilizing a standards‐based approach 
–  in  particular,  the  successful  implementation  of  a  Service  Oriented  Architecture  (SOA) 
integration  solution  leveraging  industry  standards  (IEC  61850,  IEC  61970,  and  IEC61968)  and  a 
modern SOA Integration Platform, namely an Enterprise Service Bus (ESB), for supporting critical 
asset‐related use cases and asset health analytics. 
 

2
 Figure 1 – CENELEC Smart Grid Reference Architecture with IEC standards overlay.

In  order  to  achieve  the  business  use  cases  in  the  IEC  TC57  architecture  and  standards,  the 
following were the architectural guidelines incorporated: 
 
 Leverage Substation Engineering design process and artifacts, such as SCL files. 
 Interface structure definition based on IEC 61968‐100. 
 Interface payload derived from enterprise semantic model (ESM), which is based on IEC 
Common Information Model (CIM). 
 SOA Canonical services based on industry standard model, namely CIM. 
 Loosely coupled and layered architecture. Avoid tight coupling between solution 
components, including components from different layers. 
 Compatible with and according to Vattenfall’s IT zone model to ensure security. 
 
In the following sections, we will discuss the implementation details. 
 
Implementation Overview 
 
The  design  process  began  with  understanding  the  use  cases  and  constraints.  The  integration 
flows  were  then  defined,  and  service  names  /  functions  were  identified.  A  model  was  created 
using  the  IEC  CIM  as  the  starting  point  for  the  Enterprise  Semantic  Model  (ESM).  The  ESM  was 
extended  as  needed  to  enable  the  generation  of  canonical  service  interfaces  (WSDL/XSD)  and 
database definitions (DDL). The ESB services (adaptor and canonical) were then developed on the 
ESB  platform.    Any  problems  uncovered  during  testing  were  addressed  at  the  ESM  level  (if 
appropriate)  and  brought  forward  from  there.  The  DBs  were  implemented  in  a  similar  process 
and revised in a similar model‐driven manner. The SCL file was used to configure the Substation 
Gateway.  It was also used to “seed” the cross‐reference DB. 

Figure 2 is a detailed view of the test implementation. This figure shows multiple security zones: 
Zone 1 in the Station, Zone 2 in SCADA / Operations Technology (OT), and Zone 3 in the Enterprise. 
The  Zone  1  setup  consists  of  a  number  of  IEDs,  a  Service  PC  for  configuring  the  IEDs,  and  a 
substation data gateway. As shown in the figure, the substation gateway is a 61850 gateway that 
is  incorporated  within  a  Service  PC,  but  in  subsequent  implementations  this  has  been 
implemented as a separate component that supports IEC 61850 as well as legacy protocols. The 
substation gateway is described in detail later in this paper. 

3
 Figure 2 – Illustration of the test implementation.
 
The  Zone  2  ESB  has  a  number  of  adapters,  some  of  which  are  for  publishing  the  IEC  61850  and 
disturbance event data from the substation gateway, and others for publishing events from Zone 
2  data  sources  such  as  the  SCADA.  The  data  published  by  these  adapters are  consumed  by  ESB 
services in Zone 3 and forwarded appropriately with CIM semantics. The “Send Electric Network 
Event”  service  publishes  SCADA  events.  The  “Send  Disturbance  Event”  service  publishes  the 
disturbance  event  files  to  a  storage  – the  “Get  Disturbance  Event”  service can  then be used  by 
end‐user  applications  to  retrieve  this  data.  The  “Get  Measurement  Value”  and  “Send 
Measurement  Value”  services  are  used  to  provide  substation  measurement  data  to  end‐user 
applications. 
 
Measurements  are  best  utilized  with  complete  context  of  what  they  pertain  to.  This  needs 
accurate  modeling  of  the  measurements,  at  the  core  of  which  is  the  asset‐equipment 

4
measurement  mapping.  We  implemented  a  reference  database  for  this.  We  provide  a  detailed 
description of this in the next section. 
 
We  implemented  a  number  of  end‐user  applications,  to  represent  what  we  anticipate  in 
production implementation. We used SoapUI, a testing tool for SOAP and REST APIs, as a proxy 
for  future  analytics  applications  that  have  standards‐based  interfaces.  We  used  an  off‐the‐shelf 
asset  analytics  application,  dobleARMS,  to  represent  readily  available  vendor  applications,  with 
interfaces that are generally not yet aligned with the standards vision pursued in our study. We 
also used a Real Time Data Historian with end‐user analytic capability. 
 
Data Modeling Considerations 
 
Since measurement data comes from multiple sources and may be consumed by applications for 
different use cases, it is essential to model the data correctly. There are three essential concepts: 
Measurement, Equipment and Asset.  
 
 Measurement represents the concept of what is being observed, not the value itself. For 
example, a substation may have temperature measurements and door open indications, a 
transformer  may  have  oil  temperature,  a  bay  may  contain  a  number  of  power  flow 
measurements and a breaker may contain a switch status measurement. 
 Asset  represents  a  physical  and  tangible  component,  such  as  a  circuit  breaker,  with  a 
specific serial number, a manufacturer. Assets age and depreciate and therefore need to 
be monitored and maintained.  
 Equipment  represents  a  function  or  role  in  the  power  system  and  is  realized  by  one  or 
several assets. Equipment is not tangible. Example of an equipment is the circuit breaker 
that can be seen in SCADA – it has a position in the grid and a function to execute.  
 
In the scope of our study, both the concepts of equipment and asset were used. In the Substation 
Configuration Description (SCD) document, measurements (signals) are associated to equipment, 
and not asset, as the SCD describes the station from a logical/functional point of view, and not an 
asset  point  of  view.  In  order  to  fully  capture  measurement  relationships,  we  created  additional 
bindings  to  explicitly  express  the  asset‐equipment  mappings  and  associate  measurements  with 
the  appropriate  entities.  We  create  these  bindings  based  on  metadata  such  as  the  substation 
configuration,  as  detailed  in  the  IEC  61850  SCD  files.  This  is  an  important  data  preconditioning 
step, for two reasons:  
 
1. The network role of a physical asset could change, and the data associated with it should 
reflect  it.  For  instance,  consider  a  power  transformer  that,  while  being  refurbished,  is 
replaced  by  a  spare.  This  power  transformer  network  role  is  fulfilled  by  two  different 
physical  assets  at  different  times.  The  measurements  pertaining  to  the  network  role 
needs to be associated with the correct physical asset. 
 
2. Some use cases take an equipment centric viewpoint, while others take an asset‐centric 
viewpoint.  For  instance,  use  cases  such  as  protection  planning  take  an  equipment  (i.e., 
network  role)‐centric  viewpoint,  and  use  cases  such  as  condition‐based  asset 
management  take  an  asset‐centric  viewpoint.  These  different  use  cases  should  have 
access to all pertinent data immaterial of their viewpoint. 
 
In order to associate measurement to asset, we used the fact that the asset management system 
used  by  Vattenfall,  Netbas,  holds  information  both  for  Equipment  and  Asset.  By  combining  the 
association  between  measurement  and  equipment  from  the  SCD  and  the  association  between 

5
equipment and asset from Netbas, we are able to link measurements to assets. As illustrated in 
Figure 3, Equipment is central for the association between measurement and asset as it is the link 
between the two domains. It is therefore crucial to have the highest data quality for equipment 
information,  as  missing  or  erroneous  data  for  this  field  will  lead  to  missing  or  erroneous 
association between measurement and asset. 
 

Figure 3 – Equipment is central to link Measurement to Asset.

 
During our study, we noted some inconsistencies regarding equipment data, and it was proposed 
that  a  key  field  in  Netbas  is  harmonised  throughout  the  system  by  always  using  the  following 
nomenclature: 
 
Substation name + bay name – nominal voltage – object name 
 
This  created  a  unique  identifier  for  the  equipment‐asset  throughout  the  organization.  It  was 
determined  a  more  thorough  examination  of  nomenclature  and  equipment‐asset  identification 
will be required in order to make sure that this fits the bigger picture, when the whole asset life 
cycle is taken into consideration. 
 
Substation Data Collection 

Majority  of  equipment‐asset  data  originates  from  the  substation.  This  data  is  particularly 
challenging  because  it  originates  from  IEDs  and  other  sources  that  are  from  different  vendors, 
have  been  deployed  over  a  period  of  decades  and  consequently  have  diverse  data 
representations  and  protocols.  Translating  all  this  data  to  a  common  semantic  and  syntactic 
representation is a challenge. Furthermore, it was desired to have a consistent and automation‐
friendly substation engineering process for managing the data collection. 
 
In  order  to  provide  scalability  and  upgradability  for  future  use  cases,  we  decided  to  use  a 
software  gateway  in  the  substation.  The  substation  gateway  was  intended  to  support  the 
following use cases: 
 
1. IEC 61850 MMS reporting for real‐time data retrieval and MMS file transfer for COMTRADE 
file retrieval. 
2. IEC 61850 MMS Power Quality data. 
3. IEC 60870‐5‐104 and Modbus interfaces to support legacy devices for Asset Management. 
4. Future protocols and applications. 
 
For this phase of the investigation, we imposed the following exclusions:  
 
 The gateway is not meant for protection and control. 
 The gateway is not anticipated for use with high‐rate sources like PMU or MicroPMU. 

6
  In the case of Power Quality monitors, real‐time Sampled Value data is not in scope, only 
MMS data for Protection Planning and Asset Management applications. 
 
The exclusions enabled us to pursue a software‐based data gateway, which over time is able to 
accommodate higher rate sources as well, due to advancement in technology. The following were 
the functional requirements for the gateway: 
 
1. Translation from IEC 61850 MMS, IEC 60870‐5‐101, and Modbus to web services. 
2. Buffering to overcome any communication failures.  
3. This buffering can be extended with more extended storage to provide local access for 
data for HMI and limited trending. 
4. Web services server in the future to provide local access of data. 
 
In addition, the following non‐functional requirements needed to be met: 
 
1. Interface for configuration of the gateway. 
2. Security features such as logging and access control. 
 
In terms of the functional requirements, while (1) and (2), namely translation and buffering, are 
the core near‐term functionalities, (3) and (4) for local data storage and provision may come to be 
expected once the initial needs of enterprise data communication are satisfied. 
 
The non‐functional requirement of an interface for gateway configuration is important. Without 
some minimal configuration interface, it is inadvisable to deploy the gateway in production. Even 
simple  tasks such as  configuring the IP address  and network details  of the connected  IEDs may 
become  cumbersome  without  this.  The  non‐functional  security  requirements  are  important  as 
well,  with  organizational  or  regulatory  requirements  typically  prohibiting  the  deployment  of 
applications without some essential security features. For instance, access control that requires a 
username and a strong password to be entered prior to making any configuration change to the 
device, and recording in event logs of any configuration change that is made. 
 
We  accomplished  our  goals  by  developing  a  software  substation  data  gateway  that  used  IEC 
61850 substation engineering and data representation concepts throughout, even in the case of 
legacy  IEDs,  such  as  those  that  use  Modbus  protocol.  In  the  case  of  Modbus,  we  extended  the 
Substation  Configuration  Description  (SCD)  file  format  with  “Private”  elements  for  the  Modbus 
configuration. We based the SCD file extensions on the ideas in IEC 61850‐80‐5 draft. The Modbus 
SCD file extensions are added to the IED section of the SCD file. Modbus devices can be assigned 
to a specific logical device (LD). XML akin to Figure 4 is utilized for Modbus description in the SCD 
file. Note the following elements: 
 
 "ModbusCommunication"  contains  the  communication  specific  settings  of  a  Modbus 
device (like IP address, TCP port, and the Modbus slave address). 
 "ModbusService" section that specifies the modbus services to be used. 
 "ModbusMapping"  section  defines  data  points  (specifies  data  types,  addresses,  and 
names for references in the IEC 61850 data model). 
 The  mapping  to  the  IEC  61850  data  model  is  done  elsewhere  in  the  SCD  file  in  the  LN 
elements. 
 

7
 Figure 4 – Example of Modbus extensions in the SCD file.
The substation data gateway, once configured in this manner using an extended SCD file, uses IEC 
61850 client and Modbus Master components to retrieve the data from the IEDs (south side) and 
convert  it  into  an  intermediate  data  representation  (IEC  61850  Gateway  Data  model).  This 
architecture is shown in Figure 5. 
 

Figure 5 – Substation data gateway architecture. 

In this figure: 
 
 Data received from the IEDs is stored in FCData data objects. 
 FCData objects represent functional constraint data objects (FCDO) data of IEC 61850. 
 There is an FCData object for all data objects of the client‐side IEC 61850 data model. 
 FCData  structures  are  owned  by  the  Modbus  master  or  IEC  61850  client  and  are  shared 
with the Gateway/Mapper. 

8
 
The  data  from  station  IEDs,  IEC  61850‐based  or  legacy,  are  collected  by  a  substation  gateway, 
which then forwards the data using a IEC 61850‐based model to the ESB, wherein it is converted 
to a IEC CIM‐based data objects and provided to analytic applications. 
 
Enterprise Data Environment 

There are some essential elements for effective asset health analytics: 
 
 Leverage  all  the  asset  related‐data  that  is  available  within  the  organization.  Doing  so 
provides a more complete and accurate picture of the asset fleet and their significance to 
the  organization.  Having  a  good  data  management,  and  in  particular  measurement 
management, since bulk of the most useful asset data are measured, is essential for this.  
 Develop a conceptual design and implementation roadmap for a fully‐fledged asset health 
solution, including the automation of asset health triggers and subsequent actions such as 
work  order  requests.  These  additional  parts  of  the  asset  health  solution  can  then  be 
implemented incrementally according to a roadmap / masterplan. 
 Start  from  organizational  objectives,  and  design  analytics  platforms/programs  that 
contribute to the organizational objectives. 
 Develop  strategic  and  tactical  plans  for  asset  management.  The  analytics 
platforms/programs should enable implementation of these plans. For instance: 
o The  organization  should  have a  strategy for asset  replacement  and renewal, and 
the analytics should enable this decision by providing accurate metrics. 
o If analytics produces an alert or if the analytic score crosses a preset threshold on 
an  asset, the  plan  should  specify  how one  should respond to  these  events. If  an 
organization  is  trying  to  figure  out  a  course  of  action  after  the  event,  it  may 
already be too late. 
o Determine critical assets and ensure that good data is available about these critical 
assets, which is essential for accurate analytic assessment. In some cases, where 
good  data  does  not  exist,  the  organization  may  rectify  the  situation  through 
measures  such  as  more  thorough  or  frequent  inspections/testing,  and  targeted 
addition of sensors and monitors. 
o Ensure  that  all  the  Subject  Matter  Experts  (SMEs)  understand  and  accurately 
interpret  what  the  analytic  system  is  telling  them,  and  ensure  that  other 
organizational  stakeholders,  such  as  the  decision‐makers  for  asset  replacement, 
understand the type of analytic input that would drive their decision. 
 
The  enterprise  data  environment  created  in  this  study  enables  complete  asset  visibility 
throughout  the  asset  lifecycle,  by  providing  on‐demand  access  to  high  quality  data.  The  ESB 
provides  richly  linked  data  to  subscribing  applications  using  IEC  61968‐100  based  CIM 
serializations  and  appropriate  CIM‐based  payloads.  For  asset  management  applications,  IEC 
61968‐4 based payloads are used.  
 
One  of  the  applications  is  a  data  lake  that  brings  together  the  substation  data  with  other 
enterprise data, both structured and unstructured. This one repository of all relevant enterprise 
data makes it easy for applications to have their data needs met from a single system, rather than 
have  to  interface  with  multiple  system.  The  data  lake  is  a  fount  for  a  new  breed  of  ad  hoc 
applications. For instance, we anticipate the use of machine learning approaches to characterize 
the  salient  properties  of  this  data.  Widgets  such  as  one  to  calculate  the  financial  risk  of  assets, 
drawing from disparate pieces of information such as the asset age, condition, criticality ratings 
associated with its location, purchase price, and insurance information, can then be put together 

9
by a data analyst, and iteratively perfected. This is radically different from the current approach of 
having  to  put  together  a  large  project,  which  could  potentially  run  for  years  and  in  the  end 
produce unsatisfactory results. 
 
Conclusions

We have been working on this R&D project since 2017, and we have developed and demonstrated 
critical  pieces  of  the  concept  in  a  laboratory  environment.  We  are  currently  in  the  process  of 
making  further  improvements  based  on  the  findings  from  the  laboratory  demonstration  and 
performing  further  pilot  testing,  including  in  live  substation  environment.  In  this  paper,  we 
described the standards‐based approach we took to achieve the objectives. 

In  this  project,  a  working  prototype  for  a  substation  gateway  based  on  the  61850‐9‐2  technical 
guidelines  was  developed.  Additionally,  the  SCL  file  used  for  substation  configuration  was 
extended  to  incorporate  the  condition  monitoring  use  case  and  used  in  order  to  configure  the 
substation gateway prototype. We were able to demonstrate that the concepts highlighted in the 
TC57  reference  architecture  are  compatible  with  current  61850  substation  engineering  process. 
For instance, the substation engineering process could be extended to support legacy protocols 
as  well  and  therefore  support  a  real‐world  environment  where  non‐61850  devices  need  to  be 
supported as well. 

Our  study  demonstrated  that  it  is  possible  to  provide  data  consumers  (applications  or  analytic 
solutions)  with  measurement  value  and  event  information  from  Vattenfall  primary  stations  in  a 
standardized manner. By implementing canonical, application agnostic services, a loosely coupled 
SOA  is  implemented  that  enables  the  reuse  of  services  and  information  flows.  This  in  turn, 
enables multiple applications to consume the information. 
 
Our study showed that a service oriented architecture together with the IEC 61850 and IEC CIM 
standards allows for reuse of information integration flows. This greatly improves robustness in 
the  solution,  while  providing  flexibility  and  isolates  the  system  components  against  changes  in 
other  components,  as  opposed  to  the  traditional  hardwired  point‐to‐point  ("Spaghetti") 
integrations.  It  also  provides  fewer  flows  and  components  to  monitor  and  administer,  thereby 
improving security. This is a prerequisite if Vattenfall wants to move towards the capability of a 
more agile development approach of "Smart" applications at the enterprise level. 

BIBLIOGRAPHY 

[1]    International Electrotechnical Commission (IEC), “Smart Grid Standards Map,”       
         http://smartgridstandardsmap.com/. 
[2]  G. Robinson, J. Horstman, M. J. Mousavi, and G. Rajappan “Data Analytics for the Smart Grid” 
(Book  Chapter  in  Smart  Grids:  Advanced  Technologies  and  Solutions,  Second  Edition, 
December 2017). 
[3]  H.  Vardhan,  R.  Ramlachan,  W.  Szela,  and  E.  Gdowik  “Deploying  digital  substations: 
Experience with a digital substation pilot in North America” (2018 71st Annual Conference for 
Protective Relay Engineers (CPRE), March 2018). 
[4]  S. Fuloria and R. Anderson “Towards a security architecture for substations” (2011 2nd IEEE 
PES  International  Conference  and  Exhibition  on  Innovative  Smart  Grid  Technologies, 
December 2011). 
[5]  IEC TC57, IEC 61968‐4:2019, “Application integration at electric utilities ‐ System interfaces for 
distribution management ‐ Part 4: Interfaces for records and asset management”. 

10