2004 IEEElPES Transmission & Distribution Conference & Exposition: Latin America I

Electrical Utilities Control Center Data

Exchange with ICCP and CIWXML
C. A. S. da Cunha Jr., 0. Rein Jr., J. A. Jardini, Fellow, IEEE, and L. C. Magrini

Abstract - Nowadays different strategies are used to overcome utility organizations together with EPRI (Eleclric Power
the problem that electrical utility industry faces in exchanging Research Institute) experts, and many SCADA (Supervisov
data. To solve this problem, it is necessary to have a data format Control und Data Acquisition) and E M S (Energy Management
that can be accessible and readable by ail electrical utilities System) vendors in order to establish a reaI-time data exchange
invoived in the exchanging process. In addition, the greater
standard for transferring the information required to the
challenge is to enable proprietary applications to translate or
access data in a generic format, common and suitable for all the interconnected electrical systems operation.
utilities concerned. In 1992, ICCP was submitted to IEC (International
ICCP - Infer-Control Center Communication Protocol and Electrotechnical Commission) consideration, and became
CIIWXML - Common Information Mode&Extensible Markup known as TASE.2 (Tele-control Application Service Elernent-
Lunguage are strategies created to exchange data among the 2), specified in IEC 870-6.
electrical utility systems. The CIWXML strategy emerges in 1998, when NERC
The goaI of this work is to evaluate and compare the ICCP (North American Electric Reliability Council) sponsored a
and the ClMlXML functionalities. Also, the Importance of these
technologies, their applicability, benefits and disadvantages are number of meetings to define a common model for Power
covered in this paper. Systems (CSP - Common Power System Model). These
meetings aimed at an operational model appropriated to data
Index Terms - Common Information Model (CIM), Data exchange among North American electrical utilities. As soon
Exchange, Energy Management System (EMS), Extensible as CIM from EPRI (Electric Power Research Institute) was
Markup Language (XML), Inter-control Center presented, it was selected as an excellent and vendor-
Communications Protocol (ICCP), Manufacturing Message
Specification (MMS), Power System Communication, Power independent option for operations modeling. As an abstract
System Modeling, Protocols, Tele-control Application Service model, CIM neither is a modeling data base specification nor
Element (TASE) an information exchange format.
In the meantime, XML became the leading technology for
I. INTRODUCTION encrypting structured documents into new applications. XML
is the preferred format for data exchange over the Web and
I N the worldwide electrical utilities scenario, the major
problem refers to the data exchange among their control
center systems through an accessible and readable format, In
other private networks.
As a result, a data exchange standard based on CIWXML
addition, the greater challenge is to enable proprietary data definition was accepted and recommended by NERC. In
applications to translate or access data in a generic format, 2002, CIM was approved as an international standard,
common and suitable for all the parties concerned, specified in IEC 61970-301 CIM Base. Today, all the major
To manage this problem, different strategies are available. Energy Management System (EMS) vendors approve this
This paper will focus on two strategies: ICCP (Inter-Control format, turning the open data exchange model into reality.
Center Communications Protocol) and CUIIXML (Common
Information Modei/Extemible Markup Language). 11. ICCP - TASE.2 (CONCEPTS AND FEATURES)
Historically, electrical utilities relied on in-house or
A. Introduction
proprietary systems, and non-IS0 (International Standards
Organization) standard protocols to achieve real-time data The TASE.2 protocol (Tele-contrd Application Service
Elemenf), also known as ICCP (nter-conpol Center
exchange. The ICCP protocol was developed by North
American electrical generation, transmission and distribution Communications Protocot), allows a control center to
exchange data with other control centers, other organizations,
regional control centers, etc. This data exchange encompasses
C. A. S. da Cunha Jr. Escola Polittcnica da Universida.de de SHo Paulo,
real-time, monitoring and control data, including measurement
~

Departamento de Engenharia de Energia e Automacgo Eldtrica ~

([email protected]) data, accounting data, and operator messages. All these data
0. Rein Jr. - Escola Politbcnica da Universidade de Siio Paulo, exchanges occur over WANs (Wide Area N e m o r h ) [ 5 ] .
Departamento de Engenharia de Energia e AutomaCHo Eletrica -
([email protected].~r) The object-oriented paradigm is used to describe not only
J. A. Jardini - Escola P o l i t h i c a da Universidade de Silo Paulo, many control center elements - which will be viewed
Departamento de Engenharia de Energia e AutomaCBo ElCtrica - externally - but also their behavior.
[email protected])
L. C, Magrini - Escola Politkcnica da Univenidade de S b Paulo, B. Architecture
Departamento de Engenharia de Energia e Automagto ElCtrica -
([email protected]) TASE.2 applies the existing standard protocols to all OS1

0-7803-8775-91041$20.00 02004 IEEE 260

reference model layers. This makes its development easier, There are two basic types of methods related to these
requiring only a sublayer to be built on the layer 7 - objects: operations and actions. An operation is started when a
Application. The protocols used are those described in the client sends a request to a server, and this server returns a
UCA standard profiles, version 2.0, with TASE.2 on the top response. An action is a fimction started by the server. For
of the stack. example, the data transfer to a client (through a report)
TASE.2 specifies the use of MMS (Manufacturing resulting from the expiration of any temporizer or any other
Message SpeciJcdon) for implementing the message services event on the server like as the change on the circuit breaker
needed. MMS defines the nomenclature, catalogue, and state [l].
variable addressing. In addition, it specifies message control The server object definitions are detailed on IEC 870-6-503
and interpretation [ 161, [ 171. document, These objects are mandatory for TASE.2
Also it makes use of ACSEs (Application Conirol Service implementation.
Element) on the layer 7 to set logical connections among the Data Objects: All data and control elements - which are
parties. usually exchanged among control centers - are considered
data objects, and may vary from simple data strucures to
C. API
complex ones.
The Application Programing Interface (API) is not The data object standard is defined on IEC-870-6-802
specified on TASE.2, according to the example on Fig. 1. In document.
this case, each vendor/developer can freely choose the best Fig. 2, illustrates TASE.2 Object Models.
way to implement hidher API. This will be considered a local
implementation from TASE.2 point of view. The protocol
services must be implemented in accordance with the
specification, thus ensuring interoperability among multi-
vendor products [1].

r-zr-l-
~ 1new
1 *- $ T z z - q G qpq
. 2 :

I J
1 t e C ~ * S
i
k W

Fig. 2. TASE.2 Object Models 111

F. Conformance Bloch
The IEC 870-6-503 document describes the server
Fig. 1. API TASE.2 [I] conformance blocks as a method for grouping TASE.2 objects
in order to build essential service types. There are 9
D. Client/Server Model conformance blocks:
TASE.2 is a clientkerver-based protocol. All the exchanges Block 1 - Basic Services;
result from a control center (cZient) request to the data Block 2 - Extended Data Set Condition Monitoring;
management control center (server). A control center can Block 3 - Blocked Transfers;
perform the role of both, client and server, depending on the Block 4 - Infomation Message;
case. Block 5 - Device Control;
As TASE.2 uses ACSE to set the logical connections Block 6- Programs;
(associations), it enables to create multiple connections Block 7 -Events;
between a client and distinct server control centers. Multiple Block 8 -Accounts and
connections can be used by a control center to provide Block 9 - Time Series.
connections with different quality of service (QoS) levels. Any implementation that requires conformance with
Thus, a TASE.2 client can ask for a relationship with the QoS TASE.2 must support Block 1 completely. Implementers can
appropriated to the execution of a specific operation. Based also state that they support one OF more blocks if all the
on that, real-time data messages must be handled by higher features defined for that (those) block(s) were fully supported.
priority connections than those non-critical data messages [ 11. Conformance can be defined to each block in terms of server,
E. Object Models client, or both [5].
Server Qbiects: The TASE.2 services are provided by G. Implementations
objects that can be considered classical objects containing As described on [XI, solution providers that want to
attributes and methods, according to object-oriented integrate TASE.2 into their solutions should start working on
methodologies. their product specification, selecting the data classes and types

261
 3

that are going to be shared by the system. From that point, the monitor data joins.
conformance blocks described on [5j have to be chosen; these - Fail-safe schema where redundant TASE.2 servers are
blocks are responsible for defining the TASE.2 services that required to address availability needs.
need to be supported. This will generate the TASE.2 service - How the local SCADA system will manage data,
interface for the system, what results in the TASE.2 programs or devices in order to address requests received
application definition when combined with object models by a TASE.2 link.
contained in [6]. There are some other aspects that were not yet identified in
Solution providers need also to establish the protocol lower the specifications - such as local implementations - and require
layers by evaluating the system needs and choosing an the implementers attention, as for example [l]:
appropriate profile, according to [7]. The chosen profile, - Client-Server relationship management;
together with the application definition, will create the final - Local implementation parameterizations and
design of the product, see Fig. 3 [8]. - Specific considerations related to the conformance blocks
that will be implemented.
I. Notes
TASE.2 users must focus on the integration of the ICCP
process into the SCADNEMS system or on its independent
operation. Legacy systems have a natural tendency toward the
second option.
Regarding the process integration into the SCADA system,
the access to SCADA database can be performed directly. It is
easier to implement TASE.2 hnctionalities if client or server
can access the SCADA database and the Operating System
directly. Functions like program activation, database
monitoring to create reports, and others, are simplified by the
access. Nevertheless, security becomes a very important topic,
Fig. 3. Pmduct design compatible with TASE.2 [SI because the extemal communication process is a highly
vulnerable point [I].
TASE.2 specifications do not refer to the user interface for Products available on the market usually offer the
managing and maintaining TASE.2. This is considered a local ICCPTTASE.2 implementation based on the following ways,
implementation, so vendors can choose the most suitable each one with its benefits and disadvantages:
interface for their products. The need of having a user - TASE.2 integrated into the solution (Native);
interface can emerge from many areas, as for example: - Toolkits for integrating TASE.2 into the user
- Data management related to TASE.2 performance, e.g., environment, normally using TASE.2 software running on
connection srahts, latest error detected, transmission a specific machine and
statistics, etc; - As a g u t w a y , in order to make TASE.2 available to those
- TASE.2 object control to enable/disable selected legacy systems that have communication limitations.
attributes;
- Bilateral tables (BLTs) generation and edition for access 111. CIM - COMMON
INFORMATIONMODEL
control and
- Datu Sets generation and edition. A. Introduction
H. Local Implementation Needs CIM is an object-oriented standard model developed for
electrical utility organizations with the intention to facilitate
TASE.2 was designed to ensure interoperability among
the development and integration of the application systems
multi-vendor products that are in accordance with its
used in electrical energy planning, management, operation and
specifications. These specifications cover only interoperability
business.
topic, not including other subjects. Other product needs for Most of EMS (Energy Management Systems) and DMS
TASE.2 implementation are referred in the specification as
(Dispiburiun Management Systems) systems belong to the
Local Implementations. TASE.2 implementers can choose the
proprietary category, what brings some difficulties for third-
best method to meet their needs; this way, they can make their parties to maintain and develop new hnctionalities. Generally
products different from the others.
significant updates and changes are performed by the
The specification includes the following Local providers themselves or by some internal team, resulting in
Implementations, but it is not limited to [I]: high maintenance costs.
- An API, which will enable local applications to interact The Electric Power Research Institute (EPRI) Working
with TASE.2 to send or receive data, as previously
Group on Control Center Application Znterfuces (CCAPI) has
mentioned (item C).
-
the purpose to publish a set of rules and procedures for
A TASE.2 interface allows user to manage data joins.
- Management hnctions that enables user to control and application interfaces, supporting tools development, and also
for promoting the use of open software on EMS and DMS.

262
ClM is the foundation for CCAPI architecture. PowerSystemResuurces [3].
For convenience, CIM is separated into several submodels
or packages, where packages are grouped on a single standard
document, Fig. 4.

1F
F
FeG¶-l l
--.,
lr i r ,
--%.

-* h..-l~:
.*,
Wm$
[* /'
Meas
H
i
Pkrsnaai

Fig. 4. CIM Submodels [Z] CcnnectMtyNcde

IEC 61970-301 comprises the following packages: Core,

Domain, Generation, LoadModel, Meas, Outage, Protecfion,
Topobgy and Wires. IEC 61970-302 includes: Energy
I
TopdogcalNode

Scheduling, Financial and Reservation. IEC 6 1970-303

provides information related to the SCADA systems. This I
model describes measurements, power and current
transformers, remote terminal unit, scan blocks, and
communication circuits. It supports operation and control, Fig. 5 Basic CIM class djagrams [3j
telemetry, data acquisition and alarm status. Lastly, the IEC C. XML - extensible Markup Language
61968 comprehends: Assets, Consumer, Core2, Distribution
m L (Extensible hfarkupLanguage) is a markup language
and Documentation. The package limit does not imply in the
application limit. An application can use ClM entities from for describing an object class known as XML documents. It is
different packages. stored on computers and describes partially the behavior of the
programs that process such objects [ 151.
CIM is defined and maintained by a set of UML (Unified
Modeling Language) Class Diagrams. An overview of the D. RDF and RDF Schema
main CIM classes is shown on Fig. 5. Developed by World Wide Web Consortium (W3C), RDF
Classes shown on Fig. 5 are the CIM comerstone, so they (Resource Description Framework) aims at a common model
can support any application that requires the power flow for describing information that can be read and understood by
modeling from generation to consumers [2], [3]. computer applications.
B. Measurement Model RDF describes relationships between resources (in terms of
The CIM measurement model is also illustrated on Fig. 5. properties name) and values using a simple model. RDF
The measurement model can be used for representing a broad properties can be viewed as resource attributes.
The RDF data models nor include any resource for declare
range of relationships among physical objects, their
measurements, calculated values, and values assigned these properties neither any resource for defining the
manually. All the object status information is stored in relationships between these properties and other resources.
Measurement Value table. Thus, the MeasurementVulue table This is the RDF Schema role.
includes a heterogeneous group with different types of The Power System Community needs to describe many
measurements (for example: MW, MVAr, temperature, object attributes, for example: resistance, reactance, and MW
voltage, frequency, and pressure) for a great number of flow. These property (attributes) definition and their
equipments (for example: transformers, capacitors, generators, corresponding semantic are defined on RDF as a RDF
etc.). The Measurement Value table also contains real-time Schema. This Schema not only describes the equipment
data and output from distinct applications (for example: state properties, but also defines the type of resources being
estimator, user 1 power flow, and user 2 power flow described (transformer, generator, breaker, etc.).
estimation). CIM enables measurements to be related with The RDF Schema was established by the CIM abstract
PowerSystemResources and Terminals. Non-electrical model codification using the RDF Schema vocabulary. Since
measurements, for example: temperature measurements and RDF model is quite generic to describe UML concepts, the
circuit breaker state must be associated to the conversion process is executed directly [4], [I 31, [14].

263
 5

E. crMixim V. CONCLUSIONS
As the CIM RDF Schema (IEC 61970-501) was formally This paper covered the main features of two intemational
approved and set as a standard, the EMS information can be standards which purpose is to allow the data exchange among
converted for exporting, in a XML document format. This electrical utility organizations. As discussed here, both
document is referred as CIM/XML document. All "tag"labels standards have their own benefits and disadvantages.
(equipment descriptions) used on a CIMKML document are To choose the most appropriated technology, electrical
provided by the CIM RDF Schema, The resulting model of utilities have to consider the analysis illusfrated on Table I.
CIM/XML exchange document can be parsed; and the In situations where response time is a critical factor, such
information can be imported to another system [3]. as real-time data access, TASE.2fiCCP emerges as an
In the CIM/xML interoperability tests, [9], [IO], [l I], [123, excellent option. Nevertheless, if organizations are more
organizations, such as ALSTON, ESCA and Siemens, concerned with application integration, non-complex
provided power system data files - in CIMKML format - to be operations, CIM/XML can be the most convenient choice.
interchanged, stored, and validate through the SCADNEMS Both TASE.2 and CIWXML have been widely accepted
systems involved in the test process. Fig. 6 shows a fragment by the electrical utility industry.
representing a transmission line span.
VI. REFERENCES
<cim:ACLineSegment rdf: ID=",F7E37067D912A938'>
<cim:Conductor.r>0.9522004cim: C o n d u c t o r n
[I] T. Saxton, D. Ambrose, F. Kendall and D. Becker, ICCP User Guide,
a i m : Conductor. gOch>3898,19842S</cim: Conduct or. gOch> EPRI, TR-Final Draft, October 8,1996.
< c i m : C o n d u c t o r . x ~ l 6 . 6 6 ~ S D D 4 ~Conductor.s>
im: [2] T. Saxton and D.Becker, Common Information Model (CIM): CIM
<c1m:Ccnductor.xOr47.6lOOOO~cim:Conductor.xOr IO Version, EPRI, Final Report, November 2001.
<cim:ConductingEquipment.BaseVoltage [3] P. Hirsch, R. Podmore and M. Robinson, User Guide for ClM XML
rdf: resource='#_BlF6DF75308~943A",b File Importer and Exporter, EPRI Level 2 Report, August 2003.
<cim:Flaming.name>l<cim: Naming.nama> [43 A. de Vos, S. E. Widergren and J. Zhu, XML for CIM Model
a i m : Conductor.bch~3O5.894259~/cim:Conductor.bchs Exchange, Power Industry Computer Applications, 2001. PICA 2001.
~cim:Conductor.~~6.3~OOOc/cim:Conduct~r.~~ Innovative Computing for Power - Electric Energy Meets the Market.
<cim:Conductor.bOch>- 22nd IEEE Power Engineering Society International Conference, May
29236.489096</cim: conductor.both> 20-24,2001, pg.31- 37.
c i m : Conductor.gch>4842.35~670</cim: Conductor,gch> [5] EPRI TASE.2 Services and Protocol (version 3996-08), EPRI IEC
ccim: ACLineSegm~nt.MemberOf_Linp 870-6-503, August 1996.
/z
rdf: resa~rce=~#_9D761E7EU49DAF58' [6] EPRI TASE.2 Object Models (version 199608), EPRI IEC 870-6-
</cim: ACLineSegment> 802, August 1996.
[7] EPRI TASE.2 Profiles (version 1996-ll), EPRI IEC 870-6-702,
Fig. 6. Representation of transmission line span using CIM/XML February 1997.
[SI EEE-SA Technical Report on Utility Communications Arcbitecture
(UCA"') Version 2.0 - Part 1: Introductjon to UCAW Version 2.0,
IV. ICCPmASE.2 OR CIM/XML IEEE-SA TR 1550-1999, November IS, 1999.
[9] EPW Report on the Common Information Model (CIM) Extensible
The Table I shows a comparative analysis beheen these Markup Language (XML) Interoperability Test #1,The Power of the
two strategies. CIM to Exchange Power System Models, Product Number 1006161,
Technical Progress,October 2001.
[IO] EPRl Report on the Common Information Model (CIM) Extensible
TABLE I Markup Language (XML) Interoperability Test #2, The Power of the
COMPARATlVE ANALYSIS - ICCPTTASE.2 AND ClM/XML CIM Lo Exchange Power System Models, Product Number 1006216,
Technical Progress, October 2001.
11I] EPRI Report on the Common Information Model (CIM) Extensible
Markup Language (XML) Interoperability Test #3, The Power of the
CIM to Exchange Power System Models, Product Number 1006217,
Final Report, December 2001.
[I21 EPRI Report on the Common Information Model (CIM) Extensible
Markup Language (XML) fnteroperability Test #4, The Power of the
CIM to Exchange Power System Models, Product Number 107351,
Final Report, December 2002.
[13] W3C RDF Primer, W3C Recommendation, February 10, 2004.
Available at: fittp://www.w3.org/TR/2004i~EC-rdf-primer-200302
1O/.
[I41 W3C RDF Vocabulary Description Language 1.0: m F Schema,
W3C Recommendation, February 10, 2004. Available at:
O!.
http://www.w3.orgl"TRi2004/REC-rdf-schema-2004021
[I51 W3C Extensible Markup Language (XML) 1.0 (Third Edition),
W3C Recommendation, February 4, 2004. Available at:
hnp:l/www.u.3.org~~~~~~C-xml-200~0~~/.
I161 Industrial Automation Systems - Manufacturing Message
Specification (MMS) Part 1: Service definition, tSO/IEC 9506-1,
1990.
[17] Industrial Automation Systems - Manufacturing Message
Specification (MMS) Part 2: Protocol Specification, ISOilEC 9506-2,
I990

264
 VII. BLOGRAPHIES

Carlos Augusto Siqueira da Cunha Jr. was born

in August 3, 1960. Received his BSc. in Computer
Science from Universidade Estadual de Campinas
(UNICAMP),Slo Paulo, Brazil, in 1982. Presently
he is a MSc. (E.E.) student in Escola Politkcnica da
Universidade de S i 0 Paulo (EPUSP), Slo Paulo,
Brazil.
He has been working on IT industry since 1980.
He worked as Perjbrmunce Anulyzer at Banco Itah,
and also at Banco de Comercio e Indhtria de SZo
Paulo (extinct Comind). In 1985, at Philips do Brad, he started to work with
database as Datu Base Administrator. In 1991, he entered in Consulting
Services business, rendering services to companies like: Monsanto, Unibanco,
EDS, Petrobris, Banco Geral do Cnmercio, Telecon, Stefanini, IBM, Point
Systems, Bradesco, and also to Saint Gobain Group (Etemit, E t e r b d and
SAMA). Since 1995 he has been working as Project Manager at CONSIST.

Osvaldo Rein Jr. was born in March 20, 1967. He

received his BSc. in Data Processing from
Faculdade de Tecnologia de SHo Paulo, Brazil, in
1989. Nowadays, he is a MSc. (E.E) student in
Escola PoIitCcnica da Universidade de S b Paulo,
3razit.
He has been working on IT industry since 1988.
During many years, he worked from technical
supporr to basic software; and his main area of work
i s Computer Networks. Today he is working on
Infnrmation Security as Project Manager at CONSIST.

Jos6 Antonio Jardini was bom in March 27, 1941.

Received his BSc. in Electrical Engineering, MSc.
and Phd in 1963, 1970 and 1973 respectively, all
from Escola Polidcnica da USP (EPUSP), SHo
Paulo, Brazil. He became a professor, associated
professor in 1991, and a titular professor in 1999 a\t
at EPUSP Departamento de Engenharia de Energia
e Automa~LoElttricas (PEA).
From 1964 to 1991, he worked at Themag
Engenharia Ltda. on power systems, transmission line and automation
projects. Today he is a professor at Escola Politknica da USP, Departamento
de Engenharia de Energia e Automq5o El&ricas, where he teaches
Automation applied to the Generation, Transmission, and Distribution of
Electric Energy. He was CIGRE SC38 representative in Brazil. He is a
CIGRE member, IEEE Fellow Member, and IAS/IEEE Distinguished
Lecturer.

Luiz Carlos Magrini was born in May 3,1954. He

received his BSc. in Electrical Engineering, MSc.
and PHd in 1977, 1995 and 1999 respectively, all
from Escola Politecnica da Universidade de Ssio
Paulo, Brazil.
He worked for 17 years at Themag Engenharia
Ltda. Nowadays, in addiction to his academic
duties he atso works os a Project
Researcher/Coordinatoator at GAGTD - Grupo de
Automa@o da Geraqio, TransmisGo e DistribdgBo
de Eneaia E16trica - from Escola Polidcnica da
Universidade de S o Paulo, Brazil-

265