Integrating Smart-Homes Into the Smart-Grid Yoseba K
Total Page：16
File Type：pdf, Size：1020Kb
Service-orientation vs. Real-Time: Integrating Smart-Homes into the Smart-Grid Yoseba K. Penya, Senior Member, IEEE, Cruz E. Borges, Aitor Pena,% and Oihane Kamara Esteban Abstract—Building automation has grown in parallel to energy Yet service orientation implies a get-set paradigm (say invoke- smart grids without much interaction. However, at present, these execute), whereas the most po-erful real-time communication two worlds cannot remain separated any more, as long as protocols (e.g. Data (istribution Service, ((S, an OMG intelligent buildings become another node of the grid. This paper shows that this integration can be performed in practice as long standard 2334 middle-are with highly parametrisable Quality as a harmonized knowledge/data model for the two worlds can of Service) rely on a publish-subscribe mechanism. be defined. This paper describes how this harmonized model can There have been hybridisation attempts (e.g. 2354? and DPWS be achieved, how it can be implemented as part of a smart grid does present the ability o, handling events but this alternative node, and how it could work and be deployed in a case study. -ould request ignoring its natural -ay, conveying all the data exchange through events. I. I'TR&()CTI&' The get-set paradigm is enough for managing and coordi- nating intelligent devices and to achieve all tasks included in The first ideas around the concept of smart grid and its the smart building G home G industry vision 2E4 but it is not advanced applications can be traced in the seminal -ork of efficient to be integrated in the more exigent real-time smart Fred Schweppe, his research starting back in the 00s to-ards a grid architecture (apart ,rom the ,act that DPWS demands, by dynamic national grid 23], 25], 26], 27]. The actual smart grid definition, IP connection, which cannot be assured in all smart vision received a decisive shove in the beginning of the 90s grid scenarios and assets). Real-time is not about achieving when the UK liberalised its electric market by +rivatising the a task in a quick ,ashion, but about achieving it quick in a electricity supply industry in England and 9ales. This decision previously known maximum time (i.e. can guarantee a response has been subsequently adopted and implemented in many other within a maximum latency). countries. In most cases, the restructuring involves separating Against this background, we will present an standard- the electricity generation and retail from the natural monopoly based software architecture devised to integrate native DPWS- functions of transmission and distribution [5]. compliant devices, legacy, fieldbus-area-network-based or pro- Since then, the research on the diverse aspects related to prietary applications and communication protocols into the the smart grid has been hectic. According to the last moves real-time smart grid architecture. 9e will validate our approach of the biggest European utilities (e.g. the PRIM" alliance3 by illustrating real-world examples of this integration. or the Open Meter project5), the underlying communication architecture, at least in this continent, is getting clearer: real- time communication all over the transport and distribution grid II. CH$@@"'G"S down to the secondary substation. This structure is already There are three main challenges that have to be tackled in under development and -ill be soon deployed 20]. From that order to achieve the integration of the diverse smart building point to the meter (i.e. the so-called last mile), including scenario protocols into a real-time frame-ork, as follows: eventual data concentrators, there is a relentless *ght between Achieve the : One of • harmonisation of the data model power-line communication (PLC) and ZigBee. the most urgent request in the smart grid is to finish with Still, independently from the physical and subse: ent layers the existing protocol mess. /or instance, in low-voltage chosen, the winning paradigm at the client’s side (e.g. next meters, ANSI C.12 rules in the USA whereas C&SEM generation industrial automation 2D4 or smart buildings 2E4? is (Companion Specification for Energy Metering) is the service orientation, especially since the advent o, the Devices standard Europa-wide. Thus, it seems sound to nify and Profile for 9eb Services (DPWS) and their standardisation harmonise all standard protocols that might be sed in the by the &ASIS 28]. Backed and developed by heavyweights 6 scenario we target at: IEC 03E;1236], DLMS/COSEM2374 such as ABB, SAP, Schneider Electric and Siemens , DPWS and CIM[3;]. The harmonisation can be accomplished enables seamless integration of device-provided services via a semantically, in case we -ant to later of,er the +ossibility service-oriented architecture (SO$? [10]. of using the power of ontologies[364 (e.g. to perform The authors are with the Energy Lab, DeustoTech, University of Deusto, inference), or syntactically. In 2304 they present a bridge Bilbao (Basque Country). from the IEC 03E;1 to (PWS but it still -orks nder the Emails yoseba.penya,cruz.borges ,aitor.pena,oihane.esteban @deusto.es get-set paradigm’s constraints. 3 { } ---.prime-alliance.org Provide abstraction upon the network protocol: There 5---.openmeter.com • 6See their joint-effort ")-funded projects SOCRADES <---.socrades.eu) are many dif,erent *elb s area protocols, communication and IMC-AESOP <http://---.imc-aesop.eu). protocols and proprietary applications that have to be JOURN$@ &/ @$T"J CLASS FILES, KOL. 6, NO. 1, I$')ARY 511D 5 abstracted seamlessly. This enterprise is not ne-, since Information Grid (DIG), either in real-time or not, depending it -as already tackled in the late 90s connecting diverse on its nature. Some of the DIG is composed of distributed data fieldbus protocols to an IP network through a three layered caches on the nodes (including the head-ends)L alternatives gate-ay 23D]. In that case, similar to outs, the bottom to this end are e.g. Oracle’s Coherence or EHCache. Finally, layer included fieldb s +rotocols, the middle one the data BigData issues may be handled through Apache Hadoop. This model layer and the +per one provided the IP connection. paper focuses on the bottom part of the architecture, more By analogy, the right strategy seems to be mapping each accurately, from the real-time architecture to the devices. of the protocols to the data model layer obtained above. On the top, we have the smart-grid communication network. Guarantee a suitable • connection to the real-time mid- The head-end is the intelligent node placed on the building dleware: DPWS offers agadg rigid get-set functionality that exports a number of services to the upper layer. This head- (i.e. read or write a variable of a device) as in 23E]), end has a predefined data model obtained from harmonizing converting the operations on that variable on a so-called the two main smart-grid standards’ data models: CIM and internal service. In this -ay, eCternal services are the IEC 03E;1 251]. The head-end is connected (physically or aggregation of a number of several internal ones; in the through wireless) to a number of field-area networks controlling SO$ >argon, the arrangement in sequence and organisation several gadgets such as sensors or lights, and to intelligent of them is called service orchestration. This third upper electric devices (IED, e.g. meters implementing either IEC layer will wrap the other two, connecting to the DDS 01ED1 (high-voltage meters) or DLMS/COS"= <all meters)). network as an OSGi7 real-time service. This strategy will Each of these variants implements different protocols (e.g. allo- to perform the aggregation and coordination of LonWorks, KNX, #$CNet, or the aforementioned IEC 01ED1 or services both locally and remotely in a natural -ay. DLMS/COSEM). The head-end retrieves the information from the devices or the field-area networks because it has the required III. SYST"= $RCHIT"CT)R" libraries to conceptually speak to them (i.e. the head-end understands the protocols). Then, the head-end translates/maps the obtained information into the harmonized data model and then exports the services with this information +-ards. This internal services are orchestrated and then exported as external services (eventually, they could be directly converted into external services and eC+orted). IK. ($T$ =&("@ H$R=&'IS$TI&' In order to unify the 03E;1 and CIM models, it is necessary to minutely analyse the se cases that will define the proper behaviour of the system. This procedure helps to identify the important functions and elements around which the innards of the system revolves. There are two approaches when it comes to deal with the harmonisation between the Common Information =odel (CIM), defined in IEC61970-301 and IEC61968-11, and IEC61850. The first technique proposes the construction o, an unified Fig. 1. System Architecture. )=@ model based on CIM, and extending it -ith concepts referent to 03E;1 251]. The second approach has to do with the Fig. 3 gives a glimpse of the whole system architecture. 9e maintenance of independent semantic models and the definition assume there are a number of devices at the bottom of the of the relationships between them through &9@ ontology system connected to a field-area network or alone. They are assertions. Both means require the description o, the IEC61850 remotely controlled by the corresponding head-end, which is data model, which is not offered by the standard itself. connected to a real-time Data Distribution Service (DDS) bus In 2010, in a report from EPRI to NIST 253], there is (a Message Oriented Middle-ware standard <=&=?? 238]. The a detailed explanation on ho- to achieve the harmonisation DDS bus, offers two communication types: publish/subscribe between the Substation Configuration Language (SCL) and and service-oriented request/response.