You are currently viewing a new version of our website. To view the old version click .
Energies
  • Review
  • Open Access

22 July 2013

Middleware Architectures for the Smart Grid: Survey and Challenges in the Foreseeable Future

,
,
and
Research Center on Software Technologies and Multimedia Systems for Sustainability (CITSEM—Centro de Investigación en Tecnologías Software y Sistemas Multimedia para la Sostenibilidad), Campus Sur UPM, Ctra Valencia, Km 7, 28031 Madrid, Spain
*
Author to whom correspondence should be addressed.

Abstract

The traditional power grid is just a one-way supplier that gets no feedback data about the energy delivered, what tariffs could be the most suitable ones for customers, the shifting daily needs of electricity in a facility, etc. Therefore, it is only natural that efforts are being invested in improving power grid behavior and turning it into a Smart Grid. However, to this end, several components have to be either upgraded or created from scratch. Among the new components required, middleware appears as a critical one, for it will abstract all the diversity of the used devices for power transmission (smart meters, embedded systems, etc.) and will provide the application layer with a homogeneous interface involving power production and consumption management data that were not able to be provided before. Additionally, middleware is expected to guarantee that updates to the current metering infrastructure (changes in service or hardware availability) or any added legacy measuring appliance will get acknowledged for any future request. Finally, semantic features are of major importance to tackle scalability and interoperability issues. A survey on the most prominent middleware architectures for Smart Grids is presented in this paper, along with an evaluation of their features and their strong points and weaknesses.

1. Introduction

For the last years, claims for a more efficient energy management have become only more frequent. Besides, governments are more willing than before to become more energy-independent and have a better saying on how energy is being used in each of their nations [1]. Finally, ecological and Earth-friendly concerns are on the rise too; a significant part of the energy that is produced is not properly used, thus putting a strain on the abundant albeit finite resources of the planet [2]. It is in this context where every suggestion to improve energy production and consumption is welcome [3]. However, in order to get relevant information about these two topics it is preferable to gather some data rather than jump to any conclusions. In order to accomplish this task, a system able to communicate through all the stages of power distribution must be implemented, and once enough data has been retrieved, it can be used to influence power generation decisions as well. The usual way to deliver the produced energy comprises several steps: to begin with, energy will be produced at power plants of varying nature (hydroelectric, coal, oil, gas, nuclear-fired, etc.) and once it has been produced in a specific facility it is distributed via the running power grid. Lastly, energy will reach the devices placed within the domain of the interested stakeholders.
As it can be inferred, this is a one-way process with little to no stakeholder involvement. The high voltage grid sends power to local-scaled power distribution systems without any smart decisions being taken. Users are able to provide feedback data about how the power is consumed, but only with time-consuming, attention-demanding procedures. There is a very low amount of decisions that can be made taking that consumption into account, being most of them improvised and linked to peak electrical demand. Therefore, power companies must handle the issue under a rather costly and clumsy procedure that requires profound studies about how to better deal with this question [4]. The proposal of the Smart Grid is supplying all these procedures with a certain amount of information for better decision making. In order to accomplish this task, communications have to be enabled throughout all the components of the power grid, thus enabling a two-way data interchange involving producers and consumers of energy. That is one of the cornerstones of the Smart Grid, because the interchange of information will provide the basis for smart power management, and it can be used to achieve the objectives it was conceived for, such as carbon emissions reduction [5] or a better distribution of low power electricity [6]. Plus, as long as a historical record is stored and can be accessed, other applications as power consumption forecast or consumption statistic can be obtained as well.

1.1. The Advantages of Middleware Architectures

In order to integrate all the different devices that will be providing communication data, a unifying layer is required. This layer will abstract not only all the complexity of the lower components of the Smart Grid used for smart metering and measuring, but also the structure of the power grid, thus keeping the user oblivious from its structure. It is because of this issue that a middleware layer has to be developed, thus integrating the very different components a Smart Grid is equipped with into one homogeneous-looking layer. As displayed in Figure 1a, if an online trade platform is set up and currency exchanges have to be performed, chances are that the platform will malfunction without a middleware layer. At first, there is no problem at the lower layers due to the fact that they are managing Protocol Data Units (PDUs) rather than the application content inside, and as long as the PDUs have acceptable fields in terms of existence and/or length, no issues will appear. However, when that content is accessed by the applications it is very likely that they will present interpretation problems (for example, if it was retrieved from a piece of equipment with a different processor or different byte storage methods). Nevertheless, if a middleware intermediate layer is used, data can be converted according to the needs of a particular application layer, thus solving any format-related issues, as depicted in Figure 1b.
Figure 1. (a) Dissonance between the understandable data format and the one received; (b) Communications system enhanced with a middleware layer.
Regarding the Smart Grid, a middleware layer is expected to take into account several features: security for data transfer between entities, semantic treatment of information, service orientation for better user attendance, services that provide an added value to the architecture (such as Quality of Service) and flexibility in order to deal with feedback from low capability devices. In the previous example of the online trade platform, the methods required to interchange currencies could be considered as part of the services that are provided to the end users, and these methods will be encased within the middleware architecture. A more detailed perspective can be obtained from Figure 2.
Figure 2. Inner view of expected middleware functionalities.
It is worth mentioning that low capability devices are referred to as devices with diminished features both in physical and in computing terms when compared to conventional equipment such as Personal Computers or laptops. Commonly, these are downsized devices that are lightweight and small enough to be placed in locations unreachable with more conventional equipment such as walls, corners or pillars. However, the cost of this portability is paid in other aspects, such as storage capabilities, since very little ROM or RAM memories can be mounted. Processing power is severely constrained too, with microcontrollers falling well below the standards of personal computing. In the context of the Smart Grid, low capability devices are used to collect data from the environment or the context they are placed upon. It is usual for them to be equipped with sensors and actuators for data collection and/or information notification. Depending on the sensors and actuators they are equipped with, low capability devices will be able to measure different variables. Examples of low capability devices are motes from a Wireless Sensor Network, like the ones presented in [7], or RFID tags, as in the GridStat middleware architecture, which is described in the next section.
The need to integrate several different pieces of hardware devoted to monitoring and evaluate the different facilities used for power generation and transmission has been reported and known for several years now; and actually, the term Smart Grid has been in use since at least 2005 [8]. In order to overcome the issues resulting from the need to interconnect several pieces of very different equipment to gather information from the Smart Grid, many different middleware architecture proposals have been put forward. In this context, middleware architectures are employed to gather the data from lower, more hardware-based levels and present it to higher levels, regardless of whether data are coming from one remote place or another, the device used for data collection, etc., Karnouskos [9], for example, talks about how different devices will be used to measure and share energy consumption data at the last mile of the power grid. He also suggests that middleware can be conceived as the “glue” for business-to-device and device-to-device connectivity. For others, like Li et al. [10], middleware architectures must be used for power grid communication, putting forward GridStat as an example. Gustavsson et al. [11] argue that middleware architectures are a critical element to adjust to the challenges that Smart Grid engineering requires. For example, middleware is used for the implementation of service oriented systems, and as a way of implementing functional and non-functional interoperability that is able to meet the wanted Quality of Service features.
Several authors have suggested the idea of providing a middleware architecture that is message-oriented (MOM or Message Oriented Middleware) with the available services accessed via either Web services or a technology that makes use of them. They go even as far as encouraging or designing solutions being able to provide Quality of Service when middleware is implemented. It is not uncommon for middleware architectures to use solutions that will guarantee interoperability among inner components of this layer. The ones that must be highlighted are:
  • Enterprise Serial Bus (ESB), a software architecture for interconnecting devices of very different capabilities using software packages named bundles used in middleware architectures as MDI [12], which is described in the following section;
  • AMQP [13], which stands for Advanced Message Queuing Protocol, and is used for communications procedures for entities involved in a message-oriented middleware;
  • RabbitMQ [14], an AMQP open source implementation that can be used under a publish/subscription paradigm.

1.2. The Advantages of Semantics in Middleware Architectures

In spite of the advantages of middleware architectures in any distributed system—in a way, middleware architectures are de facto compulsory instead of advantageous in distributed systems, as the IT infrastructure of a Smart Grid may be—there are still challenges that must be tackled. Regular middleware architectures are fairly effective interconnecting devices of different nature, but in an environment such as a Smart Grid new challenges must be faced. As an example, dynamic elements that can disappear and reappear in very little time (smart meters or embedded systems encased in white goods that are turned off or on) can easily put a strain on the middleware architecture. These situations call for semantics usage. Generally speaking, and under the scope of information technologies, we consider that semantics can be regarded as the capability to apprehend the meaning and implications of a piece of content that will turn from raw data to processed information. Semantics will provide as a key value the ability to become aware of the meaning of the content at the application layer. What is more, if provided with the suitable equipment—as an inference engine—the application will be able to make choices without needing human intervention, therefore saving power and time for energy users.
By using ontologies, semantic annotations can also be provided. Ontologies describe devices offering data about the features of the device (identification, measuring capabilities, processor characteristics, battery lifetime, etc.) and its services (data required, updates, etc.) thus giving a specific idea of what can be done and with what devices, regardless of their differences in the devices hardware or in what need is solved by using a service. Semantic annotations, on the other hand, can be defined as representations of specific information that is organized according to syntax and hierarchical rules given by ontologies. Examples of ontologies that fit in well in the scope of the Smart Grid are Semantic Sensor Network (SSN) [15] or Standard Ontology for Ubiquitous and Pervasive Applications (SOUPA) [16]. Commonly, they provide tools to either model sensing devices, along with their capabilities—in the case of SSN—or design applications that feed on ubiquitous equipment—in the case of SOUPA. In any case, they are conceived for applications with a high number of devices that strongly resemble the metering and monitoring infrastructure that can be found in the Smart Grid. Ontologies can be generated using tools as Ontology Web Language (OWL). Thus, the data is transferred, processed and stored according to a format and a hierarchy defined by ontology, therefore standardizing the information mapping within a system to an extent.
Finally, another new feature is obtained as a consequence: context-awareness. Since the point of the Smart Grid is collecting information from usual power distribution and consumption centers, the middleware architecture used must be informed about what work conditions there are in the Smart Grid. The idea is that the middleware architecture will react differently depending on how the parameters that measure work conditions may vary during their lifetime, thus providing services in different manners (sources of renewable energy may generate different amounts of power depending on whether the day is sunny, cloudy, windy or not, etc.).
This paper is structured as follows: an introduction on why a middleware architecture, and more precisely, a semantic middleware architecture is desirable for a Smart Grid has already been offered. Section 2 deals with a proposed classification for middleware architectures linked to the Smart Grid, along with the ones that have been found after a thorough survey. Their features, performance, strengths and weaknesses are presented here as well. Section 3 describes the open issues that have been discovered after processing all the data previously obtained in Section 2. Section 4 deals with the conclusions and future works that will be carried out in the light of the survey and open issues. A brief section of acknowledgements and another listing the references will conclude this paper.

3. Taxonomy on Middleware Architectures for the Smart Grid

Considering all the different surveyed middleware architectures and the main characteristics they share, a taxonomy has been created so as to have a more holistic view of all the middleware architectures available. It is presented in Figure 11.
It must be remembered that usually, the idea of designing a middleware architecture trying to meet one particular purpose presents both advantages and disadvantages. Standalone layers tend to be more strongly defined in terms of scope and objectives, but may require an extra effort to adapt to other architectural components. Middleware layers encased as part of a wider architecture are already adapted, but their functionalities and purposes are sometimes blurry. Finally, middleware architectures using IEC standards take power industry developments into account, yet they may not be suitable enough when low capability devices are integrated in the Smart Grid.
Figure 11. Taxonomy on middleware architectures for Smart Grids.

4. Open Issues

As it can has been learnt from the previous section, there is a plethora of middleware architectures, often with very different characteristics not easy to grasp. For a more holistic idea, the most notorious capabilities of the reviewed middleware architectures have been extracted. Firstly, the middleware architectures have been evaluated according to what they are capable of offering, considering a fixed set of parameters, as it has been displayed in Table 12.
Table 12. Main features of the surveyed middleware architectures.
Table 12. Main features of the surveyed middleware architectures.
Middleware architectureLow capability devicesSemanticsSecurityQoSService orientationTests
GridStatNoNoNo*YesLowYes
Service-oriented middleware for Smart GridNoNoYesYesHighYes
USN middlewareYesNoYesYesMediumNo ***
OHNetNoNoNoNoLowYes
MDINoNoNoNoHighYes (sim)
DPWS + IEC 61850NoYes **YesNo*HighNo ***
IAP-INMSNoYes **YesNoMediumYes
CoSGridYesNoNo*NoMediumYes
Self-organizing Smart Grid servicesNoNoNoNoHighNo ***
Secure decentralized data-centricNoNoYesNoMediumNo
SignalYesNoYesYesHighNo ***
* The authors claim the feature can be implemented within the middleware architecture; ** Without displaying ontologies or semantic annotations; *** Use cases are presented.
Additionally, Table 13 shows the main advantages and disadvantages that have been found in the previously surveyed middleware architectures for Smart Grids.
Table 13. Main advantages and disadvantages of middleware architectures for Smart Grids
Table 13. Main advantages and disadvantages of middleware architectures for Smart Grids
Middleware arch.AdvantagesDisadvantages
GridStatFlexible architecture for events and data collection. Publish-subscribe model suitable for the challenges of the project. QoS is provided. Tested in actual devices.CORBA usage and its suitable alternatives may be too computationally demanding for low capability devices and smart meters.
Service-oriented middleware for Smart GridService Oriented Architecture makes it service centric instead of device centric. QoS and QoE are provided. Tested by the involved researchers.No context-awareness for devices or services. Used deployment standards may be too demanding for low capability devices
OHNetConceived for interconnecting home and Smart Grid devices. Can interact with different protocols. APIs are used for the application layer.Interconnection with low capability devices is not mentioned. Bound to a very specific domain.
MDIArchitecture tested by developers.Weak focus on Smart Grid. Middleware presented only as a part of a wider architecture. Middleware as just a data integration layer.
DPWS + IEC 61850Service Oriented Architecture makes it service centric instead of device centric. Technologies used are widely accepted and adopted. Slim semantic features are present.DPWS client-server model does not completely match requirements of Smart Grids. DPWS may be too heavy for low capability devices.
IAP-INMSEvent based, real time features. Interoperability solutions (ESB) widely used and accepted. Architecture tested by developers. Slim semantic features are present.Semantically annotated services or ontologies are not mentioned. Low capability devices are not thoroughly considered.
CoSGridLightweight CORBA has been used for the middleware architecture. Security can be provided at higher levels.Middleware presented only as a thin part of a wider architecture. No test data.
Self-organizing Smart Grid servicesSelf-organizing characteristics. Semantic features are consideredMiddleware presented only as a thin part of a wider architecture. No test data.
Secure decentralized data-centricSelf-healing and self-configurability capabilities can be implemented. Security services are usedNot many specifications about middleware implementation.
SignalDistributed nature of the service. Quality of Service is provided.Web services may demand too many resources. Devices used are not so low-capable.
Given the analysis presented, there are several challenges that have been detected in the different middleware architectures that have been presented. The most relevant of them are:

4.1. Middleware as an Afterthought Rather than a Defined Component

Unlike most of the other hardware and software elements of a Smart Grid, the overall impression in many of the proposals is that middleware layer was not born in mind when the design of the different systems was being undertaken. It seems like, at first, systems were being implemented without taking the appropriate care of components integration in a majority of the cases. Once it was done so, the part where that integration was somewhat taking place was labeled as “middleware”, although not enough efforts have been made in this stage to make the integration more seamless, holistic or efficient. Also, it is significant that in most of the documentation reviewed, the middleware layer or architecture has not been given any particular name.

4.2. Low to Nonexistent Intelligence in Decision Making

A strong stress on making smart decisions based on semantic is definitely required. The tools that are common in other knowledge management areas of the Internet of Things, such as ontologies or semantic middleware, are dramatically absent here. It is a serious inconvenience, for smart decisions should be the backbone of the Smart Grid and there is a lot of potential in the ubiquity of it that gets wasted. Either existing ontologies that have proved their usefulness like SSN or SOUPA must be adapted to the Smart Grid or brand new ones must be created from scratch fully compliant with the requirements of it.

4.3. Middleware is Not Fulfilling Its Expected Functionalities

If middleware is the piece of software that is needed to abstract the complexity of lower layers and provide the higher ones with a homogeneous presentation, regardless of the technologies that may be used, then it is a long way until these tasks are fulfilled in this field. So-called middleware architectures are not hiding the elements that are required for communications and make them aware the user of this inner technology layers. Alas, not much information is offered as far as new device and/or new architectures integration is concerned. This behavior must be modified in order to have it fitting middleware architecture principles.

4.4. Interoperability Unforeseen Issues

Unlike other areas of network communications—wireless or not—or energy, where strong efforts are being made by institutions as CENELEC to standardize new applications that may involve the Smart Grid [35], middleware is a difficult area where to have an ultimate standard. This is like that because any particular system, with its particular components at the lower and higher layers, will have very different middleware needs, and the middleware solutions will be usually able to interoperate with each other under specific circumstances, instead of intending a single implementation. Research in middleware is bent not on having a universal common middleware for every imaginable solution, but on improving the existing interconnection solutions. Therefore, when several subsystems are integrated, the nature of the hardware diversity will have to be taken into account. Nevertheless, when hardware and application layers are identical or at least very similar to other systems where certain middleware and interoperability solutions were used, it is likely that the same concept will be employed for similar requirements as well.

5. Conclusions and Future Works

This paper has presented a survey on the most prominent solutions on middleware architectures for the Smart Grid, acknowledging middleware as a necessity for energy usage improvement and infrastructure management. Middleware architectures that have been found as matching the scope of this paper have been further analyzed, presenting their main characteristics, along with the way they work and both their strong points and improvable features. Furthermore, a taxonomy on how middleware architectures for Smart Grids can be classified has been put forward as well. Although middleware architectures presented in this paper have important advantages, there are still missing features that are becoming normal in middleware architectures used for other systems (regular network computing, etc.). Regarding the survey done and the extracted data, it is considered that the best, most-fitting middleware architecture for a Smart Grid should have the following characteristics:
  • It should be designed being aware of the possibility of low capability devices usage (Wireless Sensor Network motes or homebrew smart meters are likely to be used as part of the metering infrastructure of the Smart Grid).
  • Added value features (Quality of Service, security mechanisms, etc.) should be provided beyond interoperability and interconnectivity, as the latter should be taken for granted in any middleware architecture.
  • Semantics should be consistently and systematically applied, as this offers critical advantages in service and/or device discovery or resource availability and, so far, is either missing or not thoroughly implemented in the surveyed middleware architectures. Plus, it has to be considered that semantics have the potential to solve issues regarding interoperability and interconnectivity in a more efficient and seamless than what has been done until now. Therefore, adding semantic characteristics to middleware should become a cornerstone for future middleware developments.
  • Strong service-orientation. While focus on other aspects of the system—as devices or network topology—are of major importance, facilities present in the Smart Grid are thought to provide a benefit for human beings, so chances are that they will be retrieved as services.
  • Finally, the middleware architecture should be tested in actual devices, attempting to match as much as possible the environment where it is supposed to be deployed.

Acknowledgments

This survey on middleware architectures for the Smart Grid has been done as part of the work that is being undertaken for the I3RES (ICT-based Intelligent management of Integrated RES for the smart grid optimal operation) research project, a FP7 initiative (reference number: 318184) that aims to improve the inclusion of Renewable Energy Sources, along with developing a management tool of special usefulness for the distribution grid [36].

References

  1. FitzPatrick, G.J.; Wollman, D.A. NIST Interoperability Framework and Action Plans. In Proceedings of 2010 IEEE Power and Energy Society General Meeting, Minneapolis, MN, USA, 25–29 July 2010; pp. 1–4.
  2. Kuri, B.; Li, F. Valuing Emissions from Electricity towards a Low Carbon Economy. In Proceedings of 2005 IEEE Power Engineering Society General Meeting, San Francisco, CA, USA, 12–16 June 2005; pp. 53–59.
  3. Tan, Y.K.; Huynh, T.P.; Wang, Z.Z. Smart personal sensor network control for energy saving in DC Grid powered LED lighting system. IEEE Trans. Smart Grid 2012, 4, 1–8. [Google Scholar]
  4. Hyndman, R.J.; Shu, F. Density forecasting for long-term peak electricity demand. IEEE Trans. Power Syst. 2010, 25, 1142–1153. [Google Scholar] [CrossRef]
  5. Miceli, R. Energy management and Smart Grids. Energies 2013, 2262–2290. [Google Scholar] [CrossRef]
  6. Sendin, A.; Berganza, I.; Arzuaga, A.; Osorio, X.; Urrutia, I.; Angueira, P. Enhanced operation of electricity distribution grids through smart metering PLC network monitoring, analysis and grid conditioning. Energies 2013, 6, 539–556. [Google Scholar] [CrossRef]
  7. Ali, N.A.; Drieberg, M.; Sebastian, P. Deployment of MICAz Mote for Wireless Sensor Network Applications. In Proceedings of IEEE International Conference on Computer Applications and Industrial Electronics (ICCAIE), Penang, Malaysia, 4–7 December 2011; pp. 303–308.
  8. Amin, S.M.; Wollenberg, B.F. Toward a smart grid: Power delivery for the 21st century. IEEE Power Energy Mag. 2005, 3, 34–41. [Google Scholar] [CrossRef]
  9. Karnouskos, S. The Cooperative Internet of Things Enabled Smart Grid. In Proceedings of the 14th IEEE International Symposium on Consumer Electronics, Braunschweig, Germany, 10 June 2010; pp. 07–10.
  10. Li, F.X.; Qiao, W.; Sun, H.B.; Wan, H.; Wang, J.H.; Xia, Y.; Xu, Z.; Zhang, P. Smart Transmission Grid: Vision and framework. IEEE Trans. Smart Grid 2010, 1, 168–177. [Google Scholar] [CrossRef]
  11. Gustavsson, R.; Hussain, S.; Nordstrom, L. Engineering of Trustworthy Smart Grids Implementing Service Level Agreements. In Proceedings of 16th International Conference on Intelligent System Application to Power Systems (ISAP), Hersonissos, Greece, 25–28 September 2011; pp. 1–6.
  12. Zhao, L.; Wang, Z.Y.; Tournier, J.C.; Peterson, W.; Li, W.P.; Wang, L. A Unified Solution for Advanced Metering Infrastructure Integration with a Distribution Management System. In Proceedings of First IEEE International Conference on Smart Grid Communications (SmartGridComm), Gaithersburg, MD, USA, 4–6 October 2010; pp. 566–571.
  13. Appel, S.; Sachs, K.; Buchmann, A. Towards benchmarking of AMQP. In Proceedings of the Fourth ACM International Conference on Distributed Event-Based Systems, Cambridge, UK, 12–15 July 2010; pp. 99–100.
  14. Esswein, S.; Goasguen, S.; Post, C.; Hallstrom, J.; White, D.; Eidson, G. Towards Ontology-Based Data Quality Inference in Large-Scale Sensor Networks. In Proceedings of 2012 12th IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing (CCGrid), Ottawa, Canada, 13–16 May 2012; pp. 898–903.
  15. Ganz, F.; Barnaghi, P.; Carrez, F.; Moessner, K. Context-Aware Management for Sensor Networks. In Proceedings of the 5th International Conference on Communication System Software and Middleware, Verona, Italy, 1–3 July 2011; pp. 1–6.
  16. Söldner, G.; Kapitza, R.; Meier, R. Providing Context-Aware Adaptations Based on a Semantic Model. In Distributed Applications and Interoperable Systems, Proceedings of 11th IFIP WG 6.1 International Conference, DAIS 2011, Reykjavik, Iceland, 6–9 June 2011; Felber, P., Rouvoy, R., Eds.; Springer: Berlin, Germany, 2011; pp. 57–70. [Google Scholar]
  17. Liu, N.; Chen, B. Application of Data Interface in Power System Dispatching Based on IEC 61970 Standard. In Proceedings of 4th International Conference on Electric Utility Deregulation and Restructuring and Power Technologies (DRPT), Weihai, China, 6–9 July 2011; pp. 1048–1051.
  18. Cauchon, L.; Bouffard, A.; Dolan, D.; Peloquin, M.; Michaud, C. Real-Time IEC 61970 Based System for Bulk Power System Restoration at Hydro-Québec: RECRÉ-TR. In Proceedings of IEEE 3rd International Conference on Communication Software and Networks (ICCSN), Xi’an, China, 27–29 May 2011; pp. 100–104.
  19. Gjermundrod, H.; Gjermundrod, H.; Bakken, D.E.; Hauser, C.H.; Bose, A. GridStat: A flexible QoS-managed data dissemination framework for the Power Grid. IEEE Trans. Power Deliv. 2009, 24, 136–143. [Google Scholar] [CrossRef]
  20. Liang, Z.; Rodrigues, J.J.P.C. Service-oriented middleware for smart grid: Principle, infrastructure, and application. IEEE Commun. Mag. 2013, 51, 84–89. [Google Scholar] [CrossRef]
  21. Liang, Z.; Rodrigues, J.J.P.C.; Oliveira, L.M. QoE-driven power scheduling in smart grid: Architecture, strategy, and methodology. IEEE Commun. Mag. 2012, 50, 136–141. [Google Scholar] [CrossRef]
  22. Yu, R.; Zhang, Y.; Gjessing, S.; Yuen, C.; Xie, S.L.; Guizani, M. Cognitive radio based hierarchical communications infrastructure for smart grid. IEEE Netw. 2011, 25, 6–14. [Google Scholar] [CrossRef]
  23. Zaballos, A.; Vallejo, A.; Selga, J.M. Heterogeneous communication architecture for the smart grid. IEEE Netw. 2011, 25, 30–37. [Google Scholar] [CrossRef]
  24. Kim, M.; Lee, J.W.; Lee, Y.J.; Ryou, J.C. Cosmos: A middleware for integrated data processing over heterogeneous sensor networks. ETRI J. 2008, 30, 696–706. [Google Scholar] [CrossRef]
  25. Kim, J.S.; Kim, S.J. An Object-Based Middleware for Home Network Supporting the Interoperability among Heterogeneous Devices. In Proceedings of IEEE International Conference on Consumer Electronics (ICCE), Las Vegas, NV, USA, 9–12 January 2011; pp. 585–586.
  26. Sucic, S.; Bony, B.; Guise, L. Standards-Compliant Event-Driven SOA for Semantic-Enabled Smart Grid Automation: Evaluating IEC 61850 and DPWS Integration. In Proceedings of IEEE International Conference on Industrial Technology (ICIT), Athens, Greece, 19–21 March 2012; pp. 403–408.
  27. Ferrari, P.; Flammini, A.; Rinaldi, S.; Prytz, G. Mixing Real Time Ethernet traffic on the IEC 61850 Process Bus. In Proceedings of 9th IEEE International Workshop on Factory Communication Systems (WFCS), Lemgo, German, 21–24 May 2012; pp. 153–156.
  28. Samaras, I.K.; Hassapis, G.D.; Gialelis, J.V. A modified DPWS protocol stack for 6LoWPAN-based wireless sensor networks. IEEE Trans. Ind. Inform. 2013, 9, 209–217. [Google Scholar] [CrossRef]
  29. Garcia, A.P.; Oliver, J.; Gosch, D. An Intelligent Agent-Based Distributed Architecture for Smart-Grid Integrated Network Management. In Proceedings of IEEE 35th Conference on Local Computer Networks (LCN), Denver, CO, USA, 10–14 October 2010; pp. 1013–1018.
  30. Villa, D.; Martin, C.; Villanueva, F.J.; Moya, F.; Lopez, J.C. A dynamically reconfigurable architecture for smart grids. IEEE Trans. Consum. Electron. 2011, 57, 411–419. [Google Scholar] [CrossRef]
  31. Awad, A.; German, R. Self-Organizing Smart Grid Services. In Proceedings of 6th International Conference on Next Generation Mobile Applications, Services and Technologies (NGMAST), Paris, France, 12–14 September 2012; pp. 205–210.
  32. Kim, Y.J.; Thottan, M.; Kolesnikov, V.; Lee, W. A secure decentralized data-centric information infrastructure for smart grid. IEEE Commun. Mag. 2010, 48, 58–65. [Google Scholar] [CrossRef]
  33. Hwang, J.; Aravamudham, P. Middleware services for P2P computing in wireless grid networks. IEEE Internet Comput. 2004, 8, 40–46. [Google Scholar] [CrossRef]
  34. Foster, I.; Kesselman, C. The Globus project: A status report. Future Gener. Comp. Syst. 1999, 15, 607–621. [Google Scholar] [CrossRef]
  35. Omar, N.; Daowd, M.; Hegazy, O.; Mulder, G.; Timmermans, J.-M.; Coosemans, T.; van den Bossche, P.; van Mierlo, J. Standardization work for BEV and HEV applications: critical appraisal of recent traction battery documents. Energies 2012, 5, 138–156. [Google Scholar] [CrossRef]
  36. ICT-Based Intelligent Management of Integrated RES for the Smart Grid Optimal Operation. http://cordis.europa.eu/search/index.cfm?fuseaction=proj.document&PJ_RCN=13456678 (accessed on 22 July 2013).

Article Metrics

Citations

Article Access Statistics

Multiple requests from the same IP address are counted as one view.