Service-orientation vs. Real-Time:Integrating Smart-Homes into the Smart-Grid

Yoseba K. Penya, , Cruz E. Borges, Aitor Pena, and Oihane Kamara EstebanEnergy Lab, DeustoTech, University of Deusto, Bilbao (Basque Country)Email: {yoseba.penya,cruz.borges,aitor.pena,oihane.esteban}@deusto.es

Abstract—Building automation has grown in parallel to energysmart grids without much interaction. However, at present, thesetwo worlds cannot remain separated any more, as long asintelligent buildings become another node of the grid. This papershows that this integration can be performed in practice as longas a harmonized knowledge/data model for the two worlds canbe defined. This paper describes how this harmonized model canbe achieved, how it can be implemented as part of a smart gridnode, and how it could work and be deployed in a case study.

I. INTRODUCTION

The first ideas around the concept of smart grid and itsadvanced applications can be traced in the seminal work ofFred Schweppe, his research starting back in the 60s towardsa dynamic national grid [1], [2]. The actual smart grid visionreceived a decisive shove in the beginning of the 90s when theUK liberalised its electric market by privatising the electricitysupply industry in England and Wales. This decision hasbeen subsequently adopted and implemented in many othercountries. In most cases, the restructuring involves separatingthe electricity generation and retail from the natural monopolyfunctions of transmission and distribution [3].

Since then, the research on the diverse aspects related tothe smart grid has been hectic. According to the last movesof the biggest European utilities (e.g. the PRIME allianceor the Open Meter project), the underlying communicationarchitecture, at least in this continent, is getting clearer: real-time communication all over the transport and distribution griddown to the secondary substation. This structure is alreadyunder development and will be soon deployed [4]. From thatpoint to the meter (i.e. the so-called last mile), includingeventual data concentrators, there is a relentless fight betweenpower-line communication (PLC) and ZigBee.

Still, independently from the physical and subsequent layerschosen, the winning paradigm at the client’s side (e.g. nextgeneration industrial automation [5] or smart buildings [6]) isservice orientation, especially since the advent of the DevicesProfile for Web Services (DPWS) and their standardisationby the OASIS [7]. Backed and developed by heavyweightssuch as ABB, SAP, Schneider Electric and Siemens (See theirjoint-effort EU-funded projects SOCRADESand IMC-AESOP).DPWS enables seamless integration of device-provided servicesvia a service-oriented architecture (SOA) [8].

Yet service orientation implies a get-set paradigm (say invoke-execute), whereas the most powerful real-time communicationprotocols (e.g. Data Distribution Service, DDS, an OMG

standard [9] middleware with highly parametrisable Quality ofService) rely on a publish-subscribe mechanism.

There have been hybridisation attempts (e.g. [10]) and DPWSdoes present the ability of handling events but this alternativewould request ignoring its natural way, conveying all the dataexchange through events.

The get-set paradigm is enough for managing and coordi-nating intelligent devices and to achieve all tasks included inthe smart building / home / industry vision [6] but it is notefficient to be integrated in the more exigent real-time smartgrid architecture (apart from the fact that DPWS demands, bydefinition, IP connection, which cannot be assured in all smartgrid scenarios and assets). Real-time is not about achievinga task in a quick fashion, but about achieving it quick in apreviously known maximum time (i.e. can guarantee a responsewithin a maximum latency).

Against this background, we will present an standard-based software architecture devised to integrate native DPWS-compliant devices, legacy, fieldbus-area-network-based or pro-prietary applications and communication protocols into thereal-time smart grid architecture. We will validate our approachby illustrating real-world examples of this integration.

II. CHALLENGES

There are three main challenges that have to be tackled inorder to achieve the integration of the diverse smart buildingscenario protocols into a real-time framework, as follows:

• Achieve the harmonisation of the data model: One ofthe most urgent request in the smart grid is to finish withthe existing protocol mess. For instance, in low-voltagemeters, ANSI C.12 rules in the USA whereas COSEM(Companion Specification for Energy Metering) is thestandard Europa-wide. Thus, it seems sound to unify andharmonise all standard protocols that might be used in thescenario we target at: IEC 61850[11], DLMS/COSEM[12]and CIM[13]. The harmonisation can be accomplishedsemantically, in case we want to later offer the possibilityof using the power of ontologies[11] (e.g. to performinference), or syntactically. In [14] they present a bridgefrom the IEC 61850 to DPWS but it still works under theget-set paradigm’s constraints.

• Provide abstraction upon the network protocol: Thereare many different fielbus area protocols, communicationprotocols and proprietary applications that have to beabstracted seamlessly. This enterprise is not new, since

978-1-4799-0224-8/13/$31.00 ©2013 IEEE 5755

it was already tackled in the late 90s connecting diversefieldbus protocols to an IP network through a three layeredgateway [15]. In that case, similar to outs, the bottomlayer included fieldbus protocols, the middle one the datamodel layer and the upper one provided the IP connection.By analogy, the right strategy seems to be mapping eachof the protocols to the data model layer obtained above.

• Guarantee a suitable connection to the real-time mid-dleware: DPWS offers agadg rigid get-set functionality(i.e. read or write a variable of a device) as in [16]),converting the operations on that variable on a so-calledinternal service. In this way, external services are theaggregation of a number of several internal ones; in theSOA jargon, the arrangement in sequence and organisationof them is called service orchestration. This third upperlayer will wrap the other two, connecting to the DDSnetwork as an OSGi real-time service. This strategy willallow to perform the aggregation and coordination ofservices both locally and remotely in a natural way.

III. SYSTEM ARCHITECTURE

Fig. 1. System Architecture.

Fig. 1 gives a glimpse of the whole system architecture. Weassume there are a number of devices at the bottom of thesystem connected to a field-area network or alone. They areremotely controlled by the corresponding head-end, which isconnected to a real-time Data Distribution Service (DDS) bus(a Message Oriented Middle-ware standard (MOM)) [17]. TheDDS bus, offers two communication types: publish/subscribeand service-oriented request/response. The applications on topof the DDS bus (such as Meter Data Management (MDMs),or Distribution Management System (DMS)) acquire the datathey need to work from and through this network (it canbe any eXtreme Transaction Processing Platform (XTPP)).Additionally, they offer their services to applications on top ofthe Enterprise Side Bus (ESB). All the data is stored on a DataInformation Grid (DIG), either in real-time or not, depending

on its nature. Some of the DIG is composed of distributed datacaches on the nodes (including the head-ends); alternativesto this end are e.g. Oracle’s Coherence or EHCache. Finally,BigData issues may be handled through Apache Hadoop. Thispaper focuses on the bottom part of the architecture, moreaccurately, from the real-time architecture to the devices.

On the top, we have the smart-grid communication network.The head-end is the intelligent node placed on the buildingthat exports a number of services to the upper layer. This head-end has a predefined data model obtained from harmonizingthe two main smart-grid standards’ data models: CIM andIEC 61850 [18]. The head-end is connected (physically orthrough wireless) to a number of field-area networks controllingseveral gadgets such as sensors or lights, and to intelligentelectric devices (IED, e.g. meters implementing either IEC60870 (high-voltage meters) or DLMS/COSEM (all meters)).Each of these variants implements different protocols (e.g.LonWorks, KNX, BACNet, or the aforementioned IEC 60870 orDLMS/COSEM). The head-end retrieves the information fromthe devices or the field-area networks because it has the requiredlibraries to conceptually speak to them (i.e. the head-endunderstands the protocols). Then, the head-end translates/mapsthe obtained information into the harmonized data model andthen exports the services with this information upwards. Thisinternal services are orchestrated and then exported as externalservices (eventually, they could be directly converted intoexternal services and exported).

IV. DATA MODEL HARMONISATION

In order to unify the 61850 and CIM models, it is necessaryto minutely analyse the use cases that will define the properbehaviour of the system. This procedure helps to identify theimportant functions and elements around which the innards ofthe system revolves.

There are two approaches when it comes to deal with theharmonisation between the Common Information Model (CIM),defined in IEC61970-301 and IEC61968-11, and IEC61850.The first technique proposes the construction of an unifiedUML model based on CIM, and extending it with conceptsreferent to 61850 [18]. The second approach has to do with themaintenance of independent semantic models and the definitionof the relationships between them through OWL ontologyassertions. Both means require the description of the IEC61850data model, which is not offered by the standard itself.

In 2010, in a report from EPRI to NIST [19], there isa detailed explanation on how to achieve the harmonisationbetween the Substation Configuration Language (SCL) andCIM, through a unified UML model. The CIM UML modelprovides a common semantic overview for the transmissionand distribution system interfaces and extends it to include theIEC61850 concepts.

EPRI defines several high-priority use cases driven bybusiness needs and then develops an unified model andinterface definition to support those use cases. The identifiedgeneral use-case is the Network Extension, adding anew part (new substation) to the existing network. The EPRI

5756

report identifies some harmonisation issues like the lack ofverb+ConductingEquipment+ concept in the SCL or the need toadd a persistent ID to SCL objects, resulting in the publicationof an unified UML.

As stated before, the second approach maintains an inde-pendent semantic data model defined in each standard. Theintegration of the semantic data models is managed by theexplicit definition of equality OWL axioms between classes ofIEC 61850 and CIM. Following this technique, there is a recentresearch [20] that has developed a tool for translating betweenconfiguration files written in CIM to Substation ConfigurationDescription (SCD), and vice versa.

V. NETWORK PROTOCOL ABSTRACTION

As mentioned before, the process of enabling interoperabilitybetween different protocols begins with the identification ofthe most important functions and elements of each one. Sinceour case of study focuses on building automation, we haveconducted a research on the devices and referenced protocolsthat may be found in an intelligent building. This research hasprovided us with an insight on the classification in which theprotocols could be divided, according to whether a data modelis specified or not.

A. Specific purpose communication protocols

Among the communication protocols for inside buildingcommunication, we find the ones for the communication withmeters. Some of them define an explicit data model, such asDLMS/COSEM (Europe-wide metering standard), specifyingdata structures and functionalities in the form of classes andservices along with the message exchange information, wheremessages are constructed with these data classes, while othersIEC60870 (standard adopted by the Spanish TransmissionSystem Operator for the management of high-voltage meters)only define the structure of the exchanged messages.

In the case of the DLMS/COSEM, the protocol defines adata model and communication protocols for data exchangewith metering equipment, classified in three areas:

• Modelling: Data model of the metering equipment aswell as rules for data identification.

• Messaging: Communication services and protocols formapping the elements of the data model to applicationprotocol data units.

• Transporting: Services and protocols for sendingmessages through the communication channel.

The data model of the DLMS/COSEM comprises severalinterface classes grouped by functionality: data storage, accesscontrol and management, and time-event bound control. Takingfor example the interface class Extended Register fromthe data storage group, which defines the way in which aconsumption reading is delivered by the protocol. This classis comprised of three fields:

• Logical name: Identifies the register object instance.• Value: Obtains the current process or statue value.• Scaler unit: Provides information on the unit and

the scaler of the value.

We have achieved the mapping to the IEC61850-CIM byidentifying the necessary fields of a specific interface class ofthe DLMS/COSEM with the equivalent ones in the unifiedprotocol. In this way, whenever there is a query or responsefrom one protocol to the other, the intelligence in charge ofachieving the interoperability is capable of converting andmapping the fields in the message of a specific protocol, tothe other.

B. General-purpose communication protocols

Zigbee is a low-power, low-rate short range wireless com-munication used in industrial control, home automation, healthcare, building automation, consumer electronics and other fields.This communication technology, could be classified inside thisgroup because it is valid to communicate with a variety of ainside building devices, defined in the previously mentionedapplication profiles. This technology is recently gaining a lotof popularity, due to its robustness, and the availability ofcheap ZigBee kits. ZigBee is suitable for large-scale, delaysensitive, and not excessively large amount of data applicationenvironments.

ZigBee also offers the ability of tunnelling widely usedstandards like DLMS/COSEM (metering) or BACnet (buildingautomation), enabling integration of existent deployed devicesand networks.

There are other communication protocols that come fromthe industrial and building automation world that do not definean explicit data model, such as KNX, LonWorks, and ModBus.Mapping the values obtained through these protocols to adata model is more complex, since these protocols define thecommunication layer, i.e. the format of frames and messagesfor the communication between devices, but do not provide acommon model in which to organize the different values thatcan be acquired and controlled.

For instance, KNX is a management system in the area ofelectrical installation for load switching, environmental controland security, for different types of buildings, whose objectiveis to ensure the monitoring and control of functions andprocesses such as lighting, window blinds, heating, ventilation,air-conditioning, load management, signalling, monitoring andalarms.

Communication within the KNX is done by means ofmessaging and the sending of a message takes place whenan event occurs. The transmitter device (sensor) checks theavailability of the bus and then sends the telegram. If thereare no collisions, once the transmission has ended, the sensorwaits for a message of acknowledgement. The frame that istransmitted through the bus contains specific information aboutthe event and has seven fields: six related to control issues inorder to achieve a reliable transmission, and a field with usefuldata about the commands to be executed.

Fig. 2 illustrates the mapping of FAN concepts into CIM.

VI. REAL-TIME MIDDLEWARE CONNECTION

The functionalities offered by each individual device areforwarded to the upper layers transparently, regardless of

5757

Fig. 2. CIM concepts for representing Field Area Networks

communication technologies involved. Moreover these servicescan be combined, offering aggregated services, which interactwith several devices (e.g. programmable thermostat, HeatVentilation and Air Conditioning, HVAC) to offer higher levelservices. Orchestration, that is, aggregated execution of servicesaccording to a logical rule, allow us to operate the buildingservices in a specific way, managing several services in acoordinated manner as if it was a single service. This processtakes place when a given event arises. This section describeshow the service orchestration is implemented. For that, it maybe necessary to describe some details of the XTPP platform.Some of the main guidelines behind this platform were firstdescribed in [17].

This XTPP platform makes use of OSGi as container,allowing us to use OSGi potential such as the its bundlingcapabilities. OSGi can advantageously used to aggregate bothweb services and non-web services. This fact is important as thisplatform cannot be necessarily linked or restricted to servicesimplemented as web services. Actually, web services can be alimitation if real time or quasi real time constraints are to besupported, as int this the case. Events are behind rule firing,and DDS is capable of real-time event management. ThereforeDDS is responsible for this event handling and publication.

Web services can be seen analysed more in detail as anexample. In the case of web services, WS-BPEL (Web ServicesBusiness Process Execution Language, available in [21] canbe used to model the behaviour. In this case WSDL (WebService Description language) can be used to define specificoperations, and the sequence operation by WS-BPEL. Thelogic of the process is defined as rules. This is possible asRDF/OWL-DL and several reasoners are part of the platformas described also in [17]. One of the problems that may ariseis that the system will produce too many events what will be

difficult to handle. Therefore, a ESP/CEP engine is in chargeof filtering those events that should fire a rule and produce aservice orchestration. In the case of non web services, or in thecombination of web and non-web services, the OSGi servicemodel can be directly used to implement the orchestration. Therole of DDS, ESP/CEP, OWL-DL, and reasoners, is similarthat in the case of web services. Finally, in both cases, web andnon-web, results from the execution of the service orchestrationcan be published using a publishing server (e.g. http server).

VII. PROOF OF CONCEPT: REAL-TIME METER READING

In order to illustrate the integration of a smart-home intothe smartgrid we propose the following scenario: publishingthe active power measurements of an IEC 60870 meter inthe real-time platform. To this end, we only need a PC (anembedded device would also suffice) connected to the DDSnetwork, together with a telephone connection to communicatewith the meter and another intelligent node that will subscribeto that information.

The IEC 60870 is a high-voltage meter management standardthat is only widely-used in Spain (established by law). Thisprotocol allows remote reading and manipulation of the HV-meter but is not interoperable with other more wide-establishedprotocols (e.g. DLMS/COSEM). Therefore, the managementmust be achieved by means of proprietary, legacy applicationsthat implement the protocol. Specifically, the Spanish standardfor meter management is an implementation of the IEC 60870-5-102[22], detailing the communication protocol betweenregisters or accumulators and meters. It presents three layers,namely physical, link, and application (taking the OSI Modelas reference).

• Physical layer: The IEC 60870 offers three ways to accessthe meters, one direct and the other two remote (via GSMmodem or TCP/IP, depending on the device model and itsfeatures). We focus here on the remote GSM alternative;thus, the physical connection has been achieved throughAT-HAYES commands.

• Link layer: This layer establishes the communication ses-sion among the meter and the external querier, assigning anunique session id that lasts until this communicationends. The data in this layer is exchanged in frames. TheIEC 60870 lists their type and order, usually grouping themin question-answer pairs, except for the session-openand session-close frames that receive a fixed lengthframe with Op.Code 0x10 (ack) in case the operationwas successful.

• Application layer: Non-password protected operationsinclude inquiring the meter and vendor id, reading currentdate and time, official work-schedule dates (holidays andvacations), contracted power or consumed active andreactive power (accumulated and stored since the lastreading). Password-protected cover all meter configurationoperations that could lead to any deceitful or defectivedata retrieval (e.g. changing date and time, modifyingcontracted power or holidays).

5758

In [23] we presented and service-oriented approach toachieve the meter reading. Nevertheless, those architectures donot allow to integrate the meter reading process into a real-time architecture. As aforementioned in section II, there arethree problems to solve to achieve this integration: data modelharmonisation, network protocol abstraction and connectionto the real-time middleware. The first step has been alreadyperformed by the EPRI with the harmonisation of the CIM andIEC 61850 protocols; moreover, this data-model is commonfor all home-automation integration scenarios.

Regarding the network protocol abstraction, IEC 60870 is anspecific purpose communication protocol. Thus, it is enoughto map its concepts into the harmonised CIM-IEC 61850data model. More accurately, in this scenario it is enoughto map the answer of the meter upon request (a series ofOp.Code 0x139 frames) into the corresponding CIM classesas depicted in Fig. 3, since this will be the information thatwill be handled to the real-time middle-ware.

In this way, the information obtained from theOp.Code 0x139 frames is recast into a MeterReadingmessage (the actual format and schema can be found in [24]).This message defines for instance the identity of the meteror meters, the reading values (as IntervalBlocks forthe periodic reads or single Readings for the rest), andtheir respective qualities and time-stamps (as well as otherimportant information specified within the ReadingTypeclass, such as interval length of the measure, type, unit, etc.).

Fig. 3. Mapping of the IEC60870 metering data into CIM classes.

According to the CIM specification [24], a meter ishandled as an end device and, therefore, it is representedusing the CIM MeterAsset class, which is a subclass ofEndDeviceAsset. CIM also defines the message interfaceof an special profile, namely the MeterReadings profile,that contains all the functions to be used with a meter; we

have completed it with the CIMTool, adding all necessaryclasses. This profile foresees several forms to retrieve loadconsumption values from a meter: periodic reads, manual, on-request, historical meter data access; we have selected the on-request modality as the equivalent for the IEC 60870 absoluteintegrated consumption retrieving service (Op.Code 0x189).Fig. 3 shows the mapping of the Op.Code 0x189 frame intoCIM classes. Please note that there are some fields with internalinformation inherent to the IEC 60870 IEC 60870 that do notneed to be mapped.

Finally, we must tackle the third challenge: connecting tothe real-time architecture. With this purpose in mind, we havetested the communication between the PC that publishes theinformation of the meter and another intelligent node. OurDDS architecture is based on the RTI DDS distribution. Thissecond node is subscribed to the consumption information ofthe meter (published by the node attached), using the standardpublish/subscribe paradigm DDS offers. DDS is messageoriented with reliable and ordered delivery and specifies anumber of attributes in order to better handle its delivery:topic, source, scope, Quality of service parameters and thebody itself. The topic provides an insight of the content of themessage in order to improve the communication. The maximumlength of a packet is 64 KBits but a message can be dividedin several packages (we have successfully sent up to 1 Mbytemessages).

Our approach to publish CIM-IEC 61850 information thoughDDS consists of inserting the CIM XML MeterReadingsmessage in the body field of the DDS message, as illustratesin Fig. 4. Then, we inject the message in DDS using the usualpublish mechanism. We have performed tests during severaldays publishing consumption data with different frequencies(one second, fifteen seconds, thirty seconds, one minute, fiveminutes and fifteen minutes) and in all the tests the subscriberreceived the data in 44 ms; we have also tested the samepublishing scheme in a network with ten other simultaneoussimilar nodes and the performance does not get affected sincethe messages we deliver are still to small ( RTI provides detailedinformation on bandwidth, scalability and other aspects in itswebsite.) Therefore, we can assume that any intelligent nodeinterested in the data published by the meter would get it 44ms in order to build an OSGi service based on this and otherinformations.

VIII. CONCLUSIONS

The revolution pushed by the smartgrids has already reacheda point in which adjacent areas must be integrated in orderto achieve an optimal global working way. As a result, otherareas in which automation was the main character and energyused to be a second fiddle, such as building automation, cannotremain attached to the classic old schemes. In the case ofbuilding automation, a closer integration with smart grids isrequired since, for instance, smart homes play a key role inthe smartgrid vision such as demand management or demandresponse.

5759

Fig. 4. DDS message with CIM payload.

There are still a number of problems to be solved. SOA(especially web-services) is the communication architecturethat has been used so far to integrate building automationwithin other systems but the smartgrid cannot relay in non real-time technologies and the request-response paradigm classicallyoffered in SOA poses an obstacle very difficult to avoid. Inthis paper we have described an alternative based on an OMGstandard, DDS, a real-time message-oriented communicationmiddleware based on the publish-subscribe paradigm.

Yet building automation has traditionally presented a verywide range of communication protocols that With the objectiveof providing useful information to applications running withinthe smartgrid, we have used the standard smartgrid data-model (obtained from the harmonisation of the two mainsmartgrid protocols: CIM and IEC 61850), addressing a multi-layer architecture in which first we map the correspondingbuilding automation communication protocol into CIM-IEC61850, and then, we publish the resulting CIM-IEC 61850XML information embedded in a DDS message. As a proof ofconcept, we have designed an scenario in which we publishin DDS the information of an IEC 60870 meter. Future worksinclude testing a bigger scenario including several field-areanetworks and offering their services to the smartgrid as OSGiservices.

REFERENCES

[1] F. Schweppe, “Power systems ’2000’: Hierarchical control strategies,”IEEE Spectrum, pp. 42–47, july 1988.

[2] F. Schweppe, B. Daryanian, and R. Tabors, “Algorithms for a spot priceresponding residential load controller,” Power Systems, IEEE Transactionson, vol. 4, no. 2, pp. 507 –516, may 1989.

[3] Y. Penya, Optimal algorithms for energy markets: Allocation andScheduling of Demand in Deregulated Energy Markets. Verlag Dr.Mueller, 2008.

[4] Y. Penya, J. Garbajosa, M. Ortega, and E. Gonzalez, “Energos: Integralsmart grid management,” in Industrial Informatics (INDIN), 2011 9thIEEE International Conference on, july 2011, pp. 727 –732.

[5] G. Candido, F. Jammes, J. de Oliveira, and A. Colombo, “SOA atdevice level in the industrial domain: Assessment of OPC UA andDPWS specifications,” in Industrial Informatics (INDIN), 2010 8th IEEEInternational Conference on, july 2010, pp. 598 –603.

[6] A. Sleman and R. Moeller, “Integration of wireless sensor networkservices into other home and industrial networks; using device profile forweb services (DPWS),” in Information and Communication Technologies:From Theory to Applications, 2008. ICTTA 2008. 3rd InternationalConference on, april 2008, pp. 1 –5.

[7] G. Candido, F. Jammes, J. Barata, and A. Colombo, “Generic managementservices for DPWS-enabled devices,” in Industrial Electronics, 2009.IECON ’09. 35th Annual Conference of IEEE, nov. 2009, pp. 3931–3936.

[8] A. Cannata, M. Gerosa, and M. Taisch, “Socrades: A frameworkfor developing intelligent systems in manufacturing,” in IndustrialEngineering and Engineering Management, 2008. IEEM 2008. IEEEInternational Conference on, dec. 2008, pp. 1904 –1908.

[9] X. Lu, T. Yang, Z. Liao, X. Li, Y. Wang, W. Liu, and H. Wang, “Anovel QoS-enabled real-time publish-subscribe service,” in Parallel andDistributed Processing with Applications, 2008. ISPA ’08. InternationalSymposium on, dec. 2008, pp. 19 –26.

[10] H. Bohn, A. Bobek, and F. Golatowski, “SIRENA - Service Infrastructurefor Real-time Embedded Networked Devices: A service oriented frame-work for different domains,” in Networking, International Conferenceon Systems and International Conference on Mobile Communicationsand Learning Technologies, 2006. ICN/ICONS/MCL 2006. InternationalConference on, april 2006, p. 43.

[11] J. Nieves, M. de Mues, A. Espinoza, and D. Rodriguez-Alvarez,“Harmonization of semantic data models of electric data standards,” inIndustrial Informatics (INDIN), 2011 9th IEEE International Conferenceon, july 2011, pp. 733 –738.

[12] International Standard IEC 62056-62 Electricity metering - Dataexchange for meter reading, tariff and load control. Part 62: Interfaceclasses, 2nd ed., IEC, 2006.

[13] IEC 61968 Application integration at electric utilities - System interfacesfor distribution management. Part 11: Common Information Model (CIM),1st ed., IEC, 2010.

[14] J. Schmutzler, S. Groning, and C. Wietfeld, “Management of distributedenergy resources in IEC 61850 using web services on devices,” inSmart Grid Communications (SmartGridComm), 2011 IEEE InternationalConference on, oct. 2011, pp. 315 –320.

[15] M. Lobashov and P. Palensky, “Bringing energy-related services to reality,”in In Proceedings of the 2001 IEWT Internationale Energiewirtschaftsta-gung TU Wien, february 2001, pp. 97–99.

[16] J. Lima, V. Gomes, J. Martins, and C. Lima, “A standard-based softwareinfrastructure to support power system protection in distributed energysystems,” in Technological Innovation for Value Creation, ser. IFIPAdvances in Information and Communication Technology, L. Camarinha-Matos, E. Shahamatnia, and G. Nunes, Eds. Springer Boston, 2012,vol. 372, pp. 355–362.

[17] M. Ortega, A. Alvarez, A. Espinoza, and J. Garbajosa, “Towards adistributed intelligence ict architecture for the smart grid,” in IEEE 9thInternational Conference on Industrial Informatics (INDIN 2011), IEEE.Caparico, Lisbon; Portugal: IEEE, July/2011 2011.

[18] J. C. Nieves, M. Ortega, A. Espinoza, and D. Rodriguez-Alvarez,“Harmonization of semantic data models of electric data standards,” inIEEE 9th International Conference on Industrial Informatics (INDIN2011), IEEE. Caparica, Portugal: IEEE, Jun/2011 2011.

[19] Harmonizing the International Electrotechnical Commission CommonInformation Model (CIM) and 61850, EPRI, 2010.

[20] R. Santodomingo, J. A. Rodriguez-Mondejar, and M. A. Sanz-Bobi,“Using semantic web resources to translate existing files between cimand iec 61850,” IEEE Transactions on Power Systems, 2012.

[21] Web Services Business Process Execution Language, 2nd ed.,http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html, OASIS,2007.

[22] Y. K. Penya, O. Kamara-Esteban, and A. Pena, “IEC60870 meter SOAmanagement,” 2011.

[23] Y. K. Penya, A. Pena, and O. Kamara-Esteban, “Semantic integration ofIEC 60870 into CIM,” 2011.

[24] IEC 61968-9 Application integration at electric utilities - Systeminterfaces for distribution management. Part 9: Interfaces for meterreading and control, 1st ed., IEC, 2009.

5760

Powered by TCPDF (www.tcpdf.org)