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 the problem that electrical utility industry faces in exchanging data. To solve this problem, it is necessary to have a data format that can be accessible and readable by ail electrical utilities invoived in the exchanging process. In addition, the greater challenge is to enable proprietary applications to translate or access data in a generic format, common and suitable for all the utilities concerned. ICCP - Infer-Control Center Communication Protocol and CIIWXML Common Information Mode&Extensible Markup Lunguage are strategies created to exchange data among the electrical utility systems. The goaI of this work is to evaluate and compare the ICCP and the ClMlXML functionalities. Also, the Importance of these technologies, their applicability, benefits and disadvantages are covered in this paper.
-
Index Terms - Common Information Model (CIM), Data Exchange, Energy Management System (EMS), Extensible Markup Language (XML), Inter-control Center Communications Protocol (ICCP), Manufacturing Message Specification (MMS), Power System Communication, Power System Modeling, Protocols, Tele-control Application Service Element (TASE)
I. INTRODUCTION
I
N the worldwide electrical utilities scenario, the major
utility organizations together with EPRI (Eleclric Power Research Institute) experts, and many SCADA (Supervisov Control und Data Acquisition) and E M S (Energy Management System) vendors in order to establish a reaI-time data exchange standard for transferring the information required to the interconnected electrical systems operation. In 1992, ICCP was submitted to IEC (International Electrotechnical Commission) consideration, and became known as TASE.2 (Tele-control Application Service Elernent2), specified in IEC 870-6. The CIWXML strategy emerges in 1998, when NERC (North American Electric Reliability Council) sponsored a number of meetings to define a common model for Power Systems (CSP - Common Power System Model). These meetings aimed at an operational model appropriated to data exchange among North American electrical utilities. As soon as CIM from EPRI (Electric Power Research Institute) was presented, it was selected as an excellent and vendorindependent option for operations modeling. As an abstract model, CIM neither is a modeling data base specification nor an information exchange format. In the meantime, XML became the leading technology for encrypting structured documents into new applications. XML is the preferred format for data exchange over the Web and other private networks. As a result, a data exchange standard based on CIWXML data definition was accepted and recommended by NERC. In 2002, CIM was approved as an international standard, specified in IEC 61970-301 CIM Base. Today, all the major Energy Management System (EMS) vendors approve this format, turning the open data exchange model into reality.
problem refers to the data exchange among their control center systems through an accessible and readable format, In addition, the greater challenge is to enable proprietary applications to translate or access data in a generic format, common and suitable for all the parties concerned, To manage this problem, different strategies are available. This paper will focus on two strategies: ICCP (Inter-Control Center Communications Protocol) and CUIIXML (Common 11. ICCP - TASE.2 (CONCEPTS AND FEATURES) Information Modei/Extemible Markup Language). Historically, electrical utilities relied on in-house or A. Introduction proprietary systems, and non-IS0 (International Standards The TASE.2 protocol (Tele-contrd Application Service Organization) standard protocols to achieve real-time data 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 data, accounting data, and operator messages. All these data (
[email protected]) 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 The object-oriented paradigm is used to describe not only (
[email protected].~r) 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, Departamento de Engenharia de Energia e Automagto ElCtrica (
[email protected])
0-7803-8775-91041$20.00 02004 IEEE
B. Architecture TASE.2 applies the existing standard protocols to all OS1
260
reference model layers. This makes its development easier, requiring only a sublayer to be built on the layer 7 Application. The protocols used are those described in the UCA standard profiles, version 2.0, with TASE.2 on the top of the stack. TASE.2 specifies the use of MMS (Manufacturing Message SpeciJcdon) for implementing the message services needed. MMS defines the nomenclature, catalogue, and variable addressing. In addition, it specifies message control and interpretation [ 161, [ 171. Also it makes use of ACSEs (Application Conirol Service Element) on the layer 7 to set logical connections among the parties. C. API
The Application Programing Interface (API) is not specified on TASE.2, according to the example on Fig. 1. In this case, each vendor/developer can freely choose the best 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 multivendor products [1].
r-zr-l~ 1new 1
*-
$
There are two basic types of methods related to these objects: operations and actions. An operation is started when a client sends a request to a server, and this server returns a response. An action is a fimction started by the server. For example, the data transfer to a client (through a report) resulting from the expiration of any temporizer or any other event on the server like as the change on the circuit breaker state [l]. The server object definitions are detailed on IEC 870-6-503 document, These objects are mandatory for TASE.2 implementation. Data Objects: All data and control elements - which are usually exchanged among control centers - are considered data objects, and may vary from simple data strucures to complex ones. The data object standard is defined on IEC-870-6-802 document. Fig. 2, illustrates TASE.2 Object Models.
T z z - q G qpq .
2 :
I
J
1
i
t e C ~ * S
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]
D. Client/Server Model TASE.2 is a clientkerver-based protocol. All the exchanges result from a control center (cZient) request to the data management control center (server). A control center can perform the role of both, client and server, depending on the case. As TASE.2 uses ACSE to set the logical connections (associations), it enables to create multiple connections between a client and distinct server control centers. Multiple connections can be used by a control center to provide connections with different quality of service (QoS) levels. Thus, a TASE.2 client can ask for a relationship with the QoS appropriated to the execution of a specific operation. Based on that, real-time data messages must be handled by higher priority connections than those non-critical data messages [ 11.
E. Object Models Server Qbiects: The TASE.2 services are provided by objects that can be considered classical objects containing attributes and methods, according to object-oriented methodologies.
conformance blocks as a method for grouping TASE.2 objects in order to build essential service types. There are 9 conformance blocks: Block 1 - Basic Services; Block 2 - Extended Data Set Condition Monitoring; Block 3 - Blocked Transfers; Block 4 - Infomation Message; Block 5 - Device Control; Block 6- Programs; Block 7 -Events; Block 8 -Accounts and Block 9 - Time Series. Any implementation that requires conformance with TASE.2 must support Block 1 completely. Implementers can also state that they support one OF more blocks if all the features defined for that (those) block(s) were fully supported. Conformance can be defined to each block in terms of server, client, or both [5]. G. Implementations As described on [XI, solution providers that want to integrate TASE.2 into their solutions should start working on their product specification, selecting the data classes and types
261
3
that are going to be shared by the system. From that point, the conformance blocks described on [5j have to be chosen; these blocks are responsible for defining the TASE.2 services that need to be supported. This will generate the TASE.2 service interface for the system, what results in the TASE.2 application definition when combined with object models contained in [6]. Solution providers need also to establish the protocol lower layers by evaluating the system needs and choosing an appropriate profile, according to [7]. The chosen profile, together with the application definition, will create the final design of the product, see Fig. 3 [8].
monitor data joins. Fail-safe schema where redundant TASE.2 servers are required to address availability needs. - How the local SCADA system will manage data, programs or devices in order to address requests received by a TASE.2 link. There are some other aspects that were not yet identified in the specifications - such as local implementations - and require the implementers attention, as for example [l]: - Client-Server relationship management; - Local implementation parameterizations and - Specific considerations related to the conformance blocks that will be implemented.
-
I. Notes
Fig. 3. Pmduct design compatible with TASE.2 [SI
TASE.2 specifications do not refer to the user interface for managing and maintaining TASE.2. This is considered a local implementation, so vendors can choose the most suitable interface for their products. The need of having a user interface can emerge from many areas, as for example: - Data management related to TASE.2 performance, e.g., connection srahts, latest error detected, transmission statistics, etc; TASE.2 object control to enable/disable selected attributes; Bilateral tables (BLTs) generation and edition for access control and - Datu Sets generation and edition. H. Local Implementation Needs TASE.2 was designed to ensure interoperability among
multi-vendor products that are in accordance with its specifications. These specifications cover only interoperability topic, not including other subjects. Other product needs for TASE.2 implementation are referred in the specification as Local Implementations. TASE.2 implementers can choose the best method to meet their needs; this way, they can make their products different from the others. The specification includes the following Local Implementations, but it is not limited to [I]: - An API, which will enable local applications to interact with TASE.2 to send or receive data, as previously mentioned (item C). A TASE.2 interface allows user to manage data joins. - Management hnctions that enables user to control and
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, because the extemal communication process is a highly vulnerable point [I]. Products available on the market usually offer the ICCPTTASE.2 implementation based on the following ways, each one with its benefits and disadvantages: - TASE.2 integrated into the solution (Native); - Toolkits for integrating TASE.2 into the user environment, normally using TASE.2 software running on a specific machine and - As a g u t w a y , in order to make TASE.2 available to those legacy systems that have communication limitations. 111. CIM - COMMON INFORMATIONMODEL
A. Introduction CIM is an object-oriented standard model developed for electrical utility organizations with the intention to facilitate the development and integration of the application systems used in electrical energy planning, management, operation and business. Most of EMS (Energy Management Systems) and DMS (Dispiburiun Management Systems) systems belong to the proprietary category, what brings some difficulties for thirdparties to maintain and develop new hnctionalities. Generally significant updates and changes are performed by the providers themselves or by some internal team, resulting in high maintenance costs. The Electric Power Research Institute (EPRI) Working Group on Control Center Application Znterfuces (CCAPI) has the purpose to publish a set of rules and procedures for 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. For convenience, CIM is separated into several submodels or packages, where packages are grouped on a single standard document, Fig. 4.
FeG¶-l F 1F l --., h..-l~:
--%.
-*
.*,
Wm$
[*
PowerSystemResuurces [3].
lr i r , Meas
/'
Pkrsnaai
H i
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 Scheduling, Financial and Reservation. IEC 6 1970-303 provides information related to the SCADA systems. This model describes measurements, power and current transformers, remote terminal unit, scan blocks, and communication circuits. It supports operation and control, telemetry, data acquisition and alarm status. Lastly, the IEC 61968 comprehends: Assets, Consumer, Core2, Distribution and Documentation. The package limit does not imply in the application limit. An application can use ClM entities from different packages. CIM is defined and maintained by a set of UML (Unified Modeling Language) Class Diagrams. An overview of the main CIM classes is shown on Fig. 5. Classes shown on Fig. 5 are the CIM comerstone, so they can support any application that requires the power flow modeling from generation to consumers [2], [3].
B. Measurement Model The CIM measurement model is also illustrated on Fig. 5. The measurement model can be used for representing a broad range of relationships among physical objects, their measurements, calculated values, and values assigned manually. All the object status information is stored in Measurement Value table. Thus, the MeasurementVulue table includes a heterogeneous group with different types of measurements (for example: MW, MVAr, temperature, voltage, frequency, and pressure) for a great number of equipments (for example: transformers, capacitors, generators, etc.). The Measurement Value table also contains real-time data and output from distinct applications (for example: state estimator, user 1 power flow, and user 2 power flow estimation). CIM enables measurements to be related with PowerSystemResources and Terminals. Non-electrical measurements, for example: temperature measurements and circuit breaker state must be associated to the
I TopdogcalNode
I
Fig. 5 Basic CIM class djagrams [3j
C. XML - extensible Markup Language
m L (Extensible hfarkupLanguage) is a markup language for describing an object class known as XML documents. It is stored on computers and describes partially the behavior of the programs that process such objects [ 151.
D. RDF and RDF Schema Developed by World Wide Web Consortium (W3C), RDF (Resource Description Framework) aims at a common model for describing information that can be read and understood by computer applications. RDF describes relationships between resources (in terms of properties name) and values using a simple model. RDF properties can be viewed as resource attributes. The RDF data models nor include any resource for declare these properties neither any resource for defining the relationships between these properties and other resources. This is the RDF Schema role. The Power System Community needs to describe many object attributes, for example: resistance, reactance, and MW flow. These property (attributes) definition and their corresponding semantic are defined on RDF as a RDF Schema. This Schema not only describes the equipment properties, but also defines the type of resources being described (transformer, generator, breaker, etc.). The RDF Schema was established by the CIM abstract model codification using the RDF Schema vocabulary. Since RDF model is quite generic to describe UML concepts, the conversion process is executed directly [4], [I 31, [14].
263
5
E.
crMixim
As the CIM RDF Schema (IEC 61970-501) was formally approved and set as a standard, the EMS information can be converted for exporting, in a XML document format. This document is referred as CIM/XML document. All "tag"labels (equipment descriptions) used on a CIMKML document are provided by the CIM RDF Schema, The resulting model of CIM/XML exchange document can be parsed; and the information can be imported to another system [3]. In the CIM/xML interoperability tests, [9], [IO], [l I], [123, organizations, such as ALSTON, ESCA and Siemens, provided power system data files - in CIMKML format - to be interchanged, stored, and validate through the SCADNEMS systems involved in the test process. Fig. 6 shows a fragment representing a transmission line span.
V. CONCLUSIONS This paper covered the main features of two intemational standards which purpose is to allow the data exchange among electrical utility organizations. As discussed here, both standards have their own benefits and disadvantages. To choose the most appropriated technology, electrical utilities have to consider the analysis illusfrated on Table I. In situations where response time is a critical factor, such as real-time data access, TASE.2fiCCP emerges as an excellent option. Nevertheless, if organizations are more concerned with application integration, non-complex operations, CIM/XML can be the most convenient choice. Both TASE.2 and CIWXML have been widely accepted by the electrical utility industry. VI. REFERENCES
4842.35~670
[5]
ccim: ACLineSegm~nt.MemberOf_Linp
rdf: resa~rce=~#_9D761E7EU49DAF58' /z
[6] [7]
Fig. 6. Representation of transmission line span using CIM/XML [SI
IV. ICCPmASE.2 OR CIM/XML
The Table I shows a comparative analysis beheen these two strategies. TABLE I COMPARATlVE ANALYSIS - ICCPTTASE.2 AND ClM/XML
[9]
[IO]
11I]
[I21
[13] [I41
P. Hirsch, R. Podmore and M. Robinson, User Guide for ClM XML File Importer and Exporter, EPRI Level 2 Report, August 2003. A. de Vos, S. E. Widergren and J. Zhu, XML for CIM Model Exchange, Power Industry Computer Applications, 2001. PICA 2001. Innovative Computing for Power - Electric Energy Meets the Market. 22nd IEEE Power Engineering Society International Conference, May 20-24,2001, pg.31- 37. EPRI TASE.2 Services and Protocol (version 3996-08), EPRI IEC 870-6-503, August 1996. EPRI TASE.2 Object Models (version 199608), EPRI IEC 870-6802, August 1996. EPRI TASE.2 Profiles (version 1996-ll), EPRI IEC 870-6-702, February 1997. EEE-SA Technical Report on Utility Communications Arcbitecture (UCA"') Version 2.0 - Part 1: Introductjon to UCAW Version 2.0, IEEE-SA TR 1550-1999, November IS, 1999. EPW Report on the Common Information Model (CIM) Extensible Markup Language (XML) Interoperability Test #1,The Power of the CIM to Exchange Power System Models, Product Number 1006161, Technical Progress,October 2001. EPRl Report on the Common Information Model (CIM) Extensible Markup Language (XML) Interoperability Test #2, The Power of the CIM Lo Exchange Power System Models, Product Number 1006216, Technical Progress, October 2001. 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. 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. W3C RDF Primer, W3C Recommendation, February 10, 2004. Available at: fittp://www.w3.org/TR/2004i~EC-rdf-primer-200302 1O/. W3C RDF Vocabulary Description Language 1.0: m F Schema, W3C Recommendation, February 10, 2004. Available at:
http://www.w3.orgl"TRi2004/REC-rdf-schema-2004021 O!. [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
