**Energy Storage Technology for Decentralised Energy Management: Future Prospects**

Bartek A. Glowacki and Emma S Hanley

Additional information is available at the end of the chapter

http://dx.doi.org/10.5772/63415

#### **Abstract**

The chapter provides a comparison of energy storage technologies in decentralised energy systems for energy management. The various costs, advantages and disadvan‐ tages of the storage technologies will be considered. System dynamics modelling will be used to analyse energy management within the decentralised renewable and storage systems. Additionally, the integration of hydrogen storage technology and the use of hydrogen as an energy carrier in a decentralised airport scenario will be highlighted and the arising advantages of a decentralised airport using novel electric planes powered by hydrogen are discussed.

**Keywords:** decentralised energy storage, energy management, transport, hydrogen, airbus

## **1. Introduction**

Successful management of future energy systems requires not efficient generation and use of energy but also the integration of storage technology to improve energy security, reduce fuel price volatility and allow further penetration of renewable energy by managing energy generation. There are many different types of storage technologies and approaches available with redox flow batteries (RFBs) and hydrogen storage being discussed in further detail including current and future techno-economic impacts of the storage technology. The use of storage technologies is of paramount importance for transitioning to a low-carbon, sustainable and resource efficient economy. The potential integration of energy storage technologies can be complementary within systems for optimal energy management and will also be considered within the study.

© 2016 The Author(s). Licensee InTech. This chapter is distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/by/3.0), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

The subject area of this chapter will focus on the energy management of decentralised energy systems using storage technologies. As a result of the transitioning energy sector towards a decarbonised system, a lot of change is occurring within the industry. The development and use of energy storage technologies are one such change that is occurring. Energy storage devices can manage the supply and demand mismatch of renewable energy within decentral‐ ised systems. The anticipated hydrogen economy will be of focus as one sustainable energy carrier for storage and therefore energy management. Both compressed and liquid hydrogen will be considered as hydrogen is important as it allows the storage of an energy carrier that can also be used as a cryogen when liquefied which will have implications for the supercon‐ ducting industry. This additional benefit of hydrogen for will be considered in further detail with the use of liquid hydrogen for a decentralised future innovative airport scenario high‐ lighted.

The preliminary chapter map is presented in **Figure 1**. The growth of renewable energy will be first discussed. Although the continued integration of renewable energy increases indige‐ nous energy generated and therefore reduces import dependence. It is important to note with increased intermittent energy generation introduced an increased amount of back-up fossil fuel energy or adequate amounts of storage capacity is required. Storage technology with focus on hydrogen and redox flow batteries will then be considered. Finally, the case for the decentralised hydrogen production, storage, liquefaction and use on electric airplanes will be presented.

**Figure 1.** Preliminary chapter map.

The key result will present decentralised hydrogen and redox flow batteries for storage that can be used for energy management. The study will provide a basis for reference when considering the current and future prospects of energy storage in decentralised energy systems that can aid with the management of renewable energy. Further advantages and disadvantages of the technologies will be considered also including additional benefits arising from storage focusing on the storage of hydrogen as an energy carrier for novel electrically powered, superconducting airplanes.

## **2. Renewable energy and energy storage**

## **2.1. Growth of renewable energy**

The subject area of this chapter will focus on the energy management of decentralised energy systems using storage technologies. As a result of the transitioning energy sector towards a decarbonised system, a lot of change is occurring within the industry. The development and use of energy storage technologies are one such change that is occurring. Energy storage devices can manage the supply and demand mismatch of renewable energy within decentral‐ ised systems. The anticipated hydrogen economy will be of focus as one sustainable energy carrier for storage and therefore energy management. Both compressed and liquid hydrogen will be considered as hydrogen is important as it allows the storage of an energy carrier that can also be used as a cryogen when liquefied which will have implications for the supercon‐ ducting industry. This additional benefit of hydrogen for will be considered in further detail with the use of liquid hydrogen for a decentralised future innovative airport scenario high‐

The preliminary chapter map is presented in **Figure 1**. The growth of renewable energy will be first discussed. Although the continued integration of renewable energy increases indige‐ nous energy generated and therefore reduces import dependence. It is important to note with increased intermittent energy generation introduced an increased amount of back-up fossil fuel energy or adequate amounts of storage capacity is required. Storage technology with focus on hydrogen and redox flow batteries will then be considered. Finally, the case for the decentralised hydrogen production, storage, liquefaction and use on electric airplanes will be

The key result will present decentralised hydrogen and redox flow batteries for storage that can be used for energy management. The study will provide a basis for reference when considering the current and future prospects of energy storage in decentralised energy systems that can aid with the management of renewable energy. Further advantages and disadvantages of the technologies will be considered also including additional benefits arising from storage

lighted.

184 Energy Management of Distributed Generation Systems

presented.

**Figure 1.** Preliminary chapter map.

The world is transitioning to a decarbonised economy, less than 300 years after the emergence of the industrial revolution. There is widespread acceptance for this transition due to acceler‐ ating climate change, increasing population and increasing demand for finite resources. A shift towards the use of novel, low carbon alternative fuels and technology is imminent. As from **Table 1**, it can be deduced an overall electricity demand is increasing; however, more of this electricity is being met by renewables. Additionally, renewable energy is also important for the heat and transport sectors and it is estimated that ~11% of energy consumption is from renewable energy sources and this is expected to rise to 15% by 2040 [1]. With the continued penetration of renewable energy storage technology can be a potential solution to manage curtailment within the system caused by supply and demand mismatch.


**Table 1.** Global electricity generation expressed as a percentage of total electricity generation [2].

#### **2.2. Energy storage**

Storage systems like pumped hydroelectric energy storage (PHES) have been in used since 1929 for energy management [3]. Although it is clear that energy storage is an established concept, storage technologies are currently not a widespread solution. Energy storage technologies have different characteristics including applications, suitable power capacities, energy storage capacities, efficiencies, costs and response time. A discussion on the integration of energy storage technologies to complement other storage technologies will be included. The main function of the discussion of storage systems is to identify their role in energy manage‐ ment of decentralised energy generation systems integrated with renewable technology. Furthermore, storage technology is important within energy systems as it can serve many different functions that will be further discussed in the case of hydrogen. There are a wide range of storage technology that are available today; however, many are not currently at the commercial stage or suffer from high economic costs. Currently, pumped hydroelectric energy storage represents 98.3% of total installed storage capacity for the grid (127 GW) and less than 10 MW of capacity is from redox flow batteries, **Figure 2** [4, 5]. The use of alternative energy storage technologies to pumped hydro-electric storage can allow the continued successful integration of renewable energy into the grid. Renewable energy allows countries to develop an indigenous energy supply as resources are available worldwide.

**Figure 2.** Non-pumped hydroelectric storage installed capacity accounting for 1% of worldwide storage capacity, with hydrogen and flow batteries included [4].

As the energy industry is undergoing a transition to a decarbonised energy system, energy storage is becoming a realistic option to aid this transition. Hydrogen storage and redox flow batteries are further discussed in the next section.

In an energy view depicted in **Figure 3**, the use of storage including hydrogen storage, pumped hydroelectric storage and stationary battery storage is considered. However, the use of the stored energy is considered only for electricity and meeting electric needs in a centralised manner. This chapter wants to provide an insight into the management of distributed energy systems that can focus more on the overall picture rather than just electricity. The use of renewable energy within the energy system has mainly focused on the electricity sector. Currently, in the European Union, 25.5% of electricity demand is met by renewables, 16.5% for heat and cooling and 5.4% for transport [6]. The focus for the use of renewable energy for transport will increase as a result of energy polices and energy security particularly in the transport sector. The source of final energy consumption is becoming more important, and the need for more complex energy systems that integrate the electricity, heat and transport sectors is required to ensure the optimal management and use of resources. Hydrogen is a flexible energy carrier as a result its potential use in the sectors as mentioned and alternatively as a storage and cryogenic medium.

**Figure 3.** Current energy systems highlighting the dependence on centralised energy generation.

## **3. Hydrogen and redox flow batteries storage technologies**

#### **3.1. Hydrogen storage for energy management**

ment of decentralised energy generation systems integrated with renewable technology. Furthermore, storage technology is important within energy systems as it can serve many different functions that will be further discussed in the case of hydrogen. There are a wide range of storage technology that are available today; however, many are not currently at the commercial stage or suffer from high economic costs. Currently, pumped hydroelectric energy storage represents 98.3% of total installed storage capacity for the grid (127 GW) and less than 10 MW of capacity is from redox flow batteries, **Figure 2** [4, 5]. The use of alternative energy storage technologies to pumped hydro-electric storage can allow the continued successful integration of renewable energy into the grid. Renewable energy allows countries to develop

**Figure 2.** Non-pumped hydroelectric storage installed capacity accounting for 1% of worldwide storage capacity, with

As the energy industry is undergoing a transition to a decarbonised energy system, energy storage is becoming a realistic option to aid this transition. Hydrogen storage and redox flow

In an energy view depicted in **Figure 3**, the use of storage including hydrogen storage, pumped hydroelectric storage and stationary battery storage is considered. However, the use of the stored energy is considered only for electricity and meeting electric needs in a centralised manner. This chapter wants to provide an insight into the management of distributed energy systems that can focus more on the overall picture rather than just electricity. The use of renewable energy within the energy system has mainly focused on the electricity sector. Currently, in the European Union, 25.5% of electricity demand is met by renewables, 16.5% for heat and cooling and 5.4% for transport [6]. The focus for the use of renewable energy for transport will increase as a result of energy polices and energy security particularly in the transport sector. The source of final energy consumption is becoming more important, and the need for more complex energy systems that integrate the electricity, heat and transport sectors is required to ensure the optimal management and use of resources. Hydrogen is a flexible

an indigenous energy supply as resources are available worldwide.

hydrogen and flow batteries included [4].

186 Energy Management of Distributed Generation Systems

batteries are further discussed in the next section.

Hydrogen is one sustainable alternative fuel and cryogen for future energy and resource requirements that can be stored in both gaseous and liquid form. Hydrogen's use as an energy carrier is well known; however, it has failed to successfully penetrate energy markets on a large scale. With focus on the transition from conventional energy generation methods and fuels, the 'hydrogen economy' can now emerge and be a key enabler to securing a sustainable, decarbonised energy future [7–9].

For hydrogen to be considered, a low-carbon fuel renewable electrolysis and zero-low carbon methods of hydrogen production using natural gas such as the microwave plasma processing of natural gas and thermal cracking of methane can be considered for a decentralised solution. The cost of hydrogen from wind electrolysis depends on the wind electricity generation price in a particular region, but it can typically vary from 3.58 to 5.86 \$/kg with other sources estimating higher costs of 6–7 \$/kg [10]. PV electrolysis is more expensive than wind electrol‐ ysis with expected current values of 28.19 \$/kg and future values of 6.18 \$/kg due to expected rapid cost decrease of PV energy [10, 11]. Among different processing methods, microwave plasma processing of natural gas is a 'low-emission' (zero CO2) production method. The technology has a high efficiency with an estimated hydrogen production cost of 1.5 \$/kg, noticeably lower than the renewable electrolysis process, and is dependent on natural gas prices. Alternatively, the steam methane reforming method of hydrogen production the most common way to produce hydrogen today integrated with carbon capture and storage can be considered [12]. Low-carbon hydrogen generation is anticipated due to the aforementioned increase in penetration of renewable energy and also for providing an additional low-carbon fuel for the transport sector. Therefore, suitable methods for bulk energy storage and on-board storage for hydrogen transport must be available [13]. Four different methods of hydrogen storage are currently being considered; high pressure compressed hydrogen, liquid hydrogen in insulated tanks, solid-state hydride storage and porous solid adsorption of molecular hydrogen [14, 15]. Storage of compressed hydrogen requires high pressures (200–700 bar) and liquid hydrogen requires low temperatures (20.39 K) [16]. Another possibility for storing hydrogen is by the formation of metal hydrides. High volumetric capacities can be reached with metal hydrides, but energy is required for heating for hydrogen release. Finally, adsorp‐ tion in porous material is an alternative hydrogen storage method that research has grown significantly.

Carbon fibre-reinforced composite tanks for 350 bar and 700 bar compressed hydrogen are under development and are already used for hydrogen storage for stationary applications and hydrogen-powered vehicles. The cost of high-pressure compressed hydrogen gas tanks depends on the pressure needed and the amount of the carbon fibre that must be used for structural reinforcement for the storage tanks. Liquid hydrogen is an alternative hydrogen storage method. A hybrid liquid hydrogen storage and superconducting magnetic energy storage (SMES) system can provide a robust energy system for back-up power. Alternatively, it can be considered for storage at refuelling stations for transport [14]. Liquid hydrogen tanks can, in principle, store more hydrogen in a given volume than compressed gas tanks, since the density of liquid hydrogen is 70 kg/m3 compared to compressed hydrogen that has a density of 39 kg/m3 at 700 bar, **Figure 4** [13].

**Figure 4.** Increasing density of hydrogen with pressure for compressed hydrogen storage [13].

Liquid hydrogen is stored in cryogenic tanks at ~20 K at ambient pressure because of the low critical temperature of hydrogen (33 K) [17]. Key issues with liquid hydrogen tanks are hydrogen boil-off estimated at 1%/day [14], and the large amount of energy required for hydrogen liquefaction [14], as well as tank cost [13]. Liquid hydrogen storage has the largest energy requirement and for storage times longer than a week the boil-off rate is problematic. For compressed hydrogen, the storage cost is eventually limited by the compressor electricity cost. One option for compressed gas storage is to increase the operating pressure of the system. This increases the cost of the pressure vessel and compressor, but the reduction in tank size can result in an overall savings [18]. The hydrogen stored can be used in a wide range of energy management techniques discussed in the next section.

estimating higher costs of 6–7 \$/kg [10]. PV electrolysis is more expensive than wind electrol‐ ysis with expected current values of 28.19 \$/kg and future values of 6.18 \$/kg due to expected rapid cost decrease of PV energy [10, 11]. Among different processing methods, microwave plasma processing of natural gas is a 'low-emission' (zero CO2) production method. The technology has a high efficiency with an estimated hydrogen production cost of 1.5 \$/kg, noticeably lower than the renewable electrolysis process, and is dependent on natural gas prices. Alternatively, the steam methane reforming method of hydrogen production the most common way to produce hydrogen today integrated with carbon capture and storage can be considered [12]. Low-carbon hydrogen generation is anticipated due to the aforementioned increase in penetration of renewable energy and also for providing an additional low-carbon fuel for the transport sector. Therefore, suitable methods for bulk energy storage and on-board storage for hydrogen transport must be available [13]. Four different methods of hydrogen storage are currently being considered; high pressure compressed hydrogen, liquid hydrogen in insulated tanks, solid-state hydride storage and porous solid adsorption of molecular hydrogen [14, 15]. Storage of compressed hydrogen requires high pressures (200–700 bar) and liquid hydrogen requires low temperatures (20.39 K) [16]. Another possibility for storing hydrogen is by the formation of metal hydrides. High volumetric capacities can be reached with metal hydrides, but energy is required for heating for hydrogen release. Finally, adsorp‐ tion in porous material is an alternative hydrogen storage method that research has grown

Carbon fibre-reinforced composite tanks for 350 bar and 700 bar compressed hydrogen are under development and are already used for hydrogen storage for stationary applications and hydrogen-powered vehicles. The cost of high-pressure compressed hydrogen gas tanks depends on the pressure needed and the amount of the carbon fibre that must be used for structural reinforcement for the storage tanks. Liquid hydrogen is an alternative hydrogen storage method. A hybrid liquid hydrogen storage and superconducting magnetic energy storage (SMES) system can provide a robust energy system for back-up power. Alternatively, it can be considered for storage at refuelling stations for transport [14]. Liquid hydrogen tanks can, in principle, store more hydrogen in a given volume than compressed gas tanks, since the density of liquid hydrogen is 70 kg/m3 compared to compressed hydrogen that has a density

significantly.

of 39 kg/m3

at 700 bar, **Figure 4** [13].

188 Energy Management of Distributed Generation Systems

**Figure 4.** Increasing density of hydrogen with pressure for compressed hydrogen storage [13].

Hydrogen is envisioned to emerge in niche decentralised markets and can be used for energy management of renewable energy as well as the use in transport. In this sense, hydrogen could form the basis of a synergistically operating buffer mechanism facilitating the integration of intermittent renewable energy, reducing CO2 emissions as well as enhancing indigenous energy supply and increasing energy security. For the investigation of the hydrogen buffer operation if an unconstrained system using surplus renewable electricity during low demand hours for hydrogen generation and storage is considered the system may result in hydrogen not being produced if there is no excess wind. This would mean a lack of energy security within the system. Alternatively, the use of a hydrogen buffer system for energy management that constrains the wind energy for hydrogen production instead of demand to provide some security to the system could be alternatively considered, **Figure 5b** as a solution.

**Figure 5.** Comparison of (a) hydrogen storage for meeting demand when required leaving the system vulnerable to a lack of hydrogen energy available in storage, (b) hydrogen use as a buffer allowing excess hydrogen to be accessed if required.

System dynamics is a system modelling tool that uses various control factors and observes how the system and variables behave in response to time-based trends. In system dynamic models, there are main stock and flow quantities. Stocks represent the status of the system, the quantities that exist at any given moment (e.g. hydrogen storage). Rate variables show the speed of flow in or out of the stocks (e.g. hydrogen production and use), and they serve as the decision making variables in a system. From a system dynamics model, the cost of electricity calculated varies from 0.4 to 0.97 €/kW h when the system is ran with no energy buffer, **Figure 6**. Although with optimum cost for the high wind scenario, this system is vulnerable to a large increase in the price with low wind energy. With this operation, the hydrogen production and use are not managed. When there is extra wind in the system, hydrogen is produced; when there is a deficit of energy within the system, hydrogen is converted to electricity (**Figure 5b**). **Figure 5b** shows the operation of a hydrogen buffer with increased security in the system with the hydrogen storage acting as a buffer for the wind energy. The system is managed and constrained to ensure that hydrogen is available if there is now renewable energy available in the system. In the system that constrains, the use of hydrogen for peak times only the cost of electricity from hydrogen ranges from 0.74 to 0.85 €/kW h. The estimated cost of electricity from hydrogen ranges from 0.28 to 0.6 €/kW h in literature [19]. The results highlight the potential use of a hydrogen buffer storage system to manage decentralised renewable energy systems.

**Figure 6.** Energy versus time diagram for system operation without energy management of hydrogen storage as a buf‐ fer. Excess wind energy produces hydrogen for storage; however, not enough hydrogen is available to prevent the re‐ quirement of grid energy but reduces curtailment in the system.

#### **3.2. Redox flow batteries**

Redox flow batteries (RFBs) have promising storage characteristics and, as the power and energy capacity of the battery are independent of each other, the RFBs can be optimised to maximise the performance and minimise the cost [20, 21]. RFBs are rechargeable systems that have the storage medium in the form of electrolyte kept in tanks external to the active cell. The electrochemical reactions and the charging and discharging battery cycles are taking place in the battery stack as the electrolyte flows through the two membrane-separated chambers of the active cell, **Figure 7** [20, 21]. The energy is stored in the separated reactants (electrolytes), while the power is controlled by the stack, **Figure 7** [20, 21]. In general, RFBs share similar flow geometries and the main differences typically occur in the electrolyte that is used [21–23]. The RFBs can operate at low temperatures (from -10 to +45°C) as long as the electrolytes remain stable and their precipitation does not occur.

**Figure 7.** Schematic representation of a redox flow battery. The electrolyte is kept in outside tanks and pumped in the two membrane-separated chambers of the active cell.

## *3.2.1. Vanadium redox flow batteries*

decision making variables in a system. From a system dynamics model, the cost of electricity calculated varies from 0.4 to 0.97 €/kW h when the system is ran with no energy buffer, **Figure 6**. Although with optimum cost for the high wind scenario, this system is vulnerable to a large increase in the price with low wind energy. With this operation, the hydrogen production and use are not managed. When there is extra wind in the system, hydrogen is produced; when there is a deficit of energy within the system, hydrogen is converted to electricity (**Figure 5b**). **Figure 5b** shows the operation of a hydrogen buffer with increased security in the system with the hydrogen storage acting as a buffer for the wind energy. The system is managed and constrained to ensure that hydrogen is available if there is now renewable energy available in the system. In the system that constrains, the use of hydrogen for peak times only the cost of electricity from hydrogen ranges from 0.74 to 0.85 €/kW h. The estimated cost of electricity from hydrogen ranges from 0.28 to 0.6 €/kW h in literature [19]. The results highlight the potential use of a hydrogen buffer storage system to manage decentralised renewable energy

**Figure 6.** Energy versus time diagram for system operation without energy management of hydrogen storage as a buf‐ fer. Excess wind energy produces hydrogen for storage; however, not enough hydrogen is available to prevent the re‐

Redox flow batteries (RFBs) have promising storage characteristics and, as the power and energy capacity of the battery are independent of each other, the RFBs can be optimised to maximise the performance and minimise the cost [20, 21]. RFBs are rechargeable systems that have the storage medium in the form of electrolyte kept in tanks external to the active cell. The electrochemical reactions and the charging and discharging battery cycles are taking place in the battery stack as the electrolyte flows through the two membrane-separated chambers of the active cell, **Figure 7** [20, 21]. The energy is stored in the separated reactants (electrolytes), while the power is controlled by the stack, **Figure 7** [20, 21]. In general, RFBs share similar flow geometries and the main differences typically occur in the electrolyte that is used [21–23]. The RFBs can operate at low temperatures (from -10 to +45°C) as long as the electrolytes remain

quirement of grid energy but reduces curtailment in the system.

stable and their precipitation does not occur.

**3.2. Redox flow batteries**

systems.

190 Energy Management of Distributed Generation Systems

The vanadium redox flow batteries (VRFBs) have promising energy storage characteristics and can respond to unpredictable changes in wind speed. The VRFB has a high efficiency in the range of 65–80%, but it has a relatively low energy density and this represents one of the main disadvantages [24–26]. The theoretical energy density is 30–47 Wh/l, but the practical achiev‐ able energy density is lower at 15–25 Wh/l [26]. When storage capacity needs to be increased, the low energy density leads to large electrolyte volumes. The electrolyte is evenly split in VRFB between the positive and negative tanks. The reactions that occur within the cell during charging, and discharging cycles are shown in **Table 2**.


**Table 2.** The chemical reactions occurring at the negative and positive side of the VRFB and all-iron RFB.

There are several advantages of using VRFB for energy storage applications: long cycle life (>10,000 cycles), high reliability, deep discharge capability and high power density. Although the electrodes do not store energy, they are important for charging and discharging of the battery, influencing, together with the electrolyte and separation membrane, the life-time of the battery, the energy losses and, consequently, the overall efficiency. It is anticipated that efficiency improvements can be made with regard to the correct selection of electrodes, for example using carbon black or its activated composites [27]. Other advantages include the popularity of the battery with regard to research and also the many VRFB installations worldwide.

## *3.2.2. All-iron redox flow batteries*

The all-iron RFB like VRFB employs the use of a single chemical element (in this case iron) in several oxidation states on both sides of the active cell, **Table 2**, while the electrolyte is kept outside in the storage tanks. The positive electrode of the all-iron battery is the ferric/ferrous redox couple, and the negative electrode involves iron plating from Fe (II) [22]. An advantage of all-iron RFB is the readily available electrolyte with an estimated low cost of 0.23 \$/l [23]. In the traditional all-iron RFB, at the negative side, the ferrous ions are reduced during charge. Their plating as iron metal onto a graphite electrode of the stack occurs leading to a coupling between energy and power. On the positive side of the battery, ferrous ions are oxidised to ferric ions during charge remaining in the solution. Reactions are opposite on discharge. Cheap aqueous electrolytes, inexpensive separators and the widespread availability of iron (~230 billion metric tonnes of iron) give the all-iron RFB, the potential of reduced storage system cost, while the plating and, consequently, the coupling between the energy and power represents its main disadvantage [22, 23].

To avoid this disadvantage, a slurry electrode containing electrically conductive carbonaceous particles can be made by flowing them in an electrolyte containing the dissolved iron species [22]. Such conductive particles can include carbon black and/or carbon allotropes with different surface areas and enhanced conductivity, carbon micro-flakes, nanofibres, nanotubes etc. Thus, iron is plated onto the carbon particles at the negative side while charging. The carbon particles can then carry the iron metal to be stored in the external tanks allowing for energy storage capacity and power decoupling, allowing the economic advantages of scaling inherent to RFB to be recovered [22]. The carbons and their properties influence the electronic conduc‐ tivity of the slurry electrodes that have to be greater than the ionic conductivity of the elec‐ trolyte. This allows for the iron deposition to occur only onto the slurry particles and not on the current collector leading to a better control of the current distribution [22]. The electrode surface area plays an important role in determining the all-iron (hybrid) RFB efficiency and lifetime. For slurry all-iron RFB, this role becomes secondary. Presently, the slurry all-iron RFBs are still in the development stage putting them at a disadvantage to the already com‐ mercialised VRFB. Typically, the energy density of the all-iron hybrid battery is 12.7 Wh/l with a specific energy 10.9 Wh/kg. Energy efficiency is 55% with operating temperature T0 = 40°C [22, 27].

#### *3.2.3. Energy storage integration*

There is much focus on the introduction of storage systems; however, the integration of different storage systems to complement the use should also be considered. For example, research was conducted on the integration of compressed hydrogen storage and VRFB. From system dynamics modelling, it was identified as a result of higher available wind energy for storage and the hydrogen system is able to provide more energy to the system due to its capability as a bulk energy storage medium. In contrast, the RFBs are capable of providing more energy to the system with reduced availability of wind energy for storage, as a result of higher efficiencies. Therefore, VRFBs or all-iron RFBs are more efficient energy storage at times when there are no high periods of curtailment.

The storage systems benefit from increased value regarding technical and economic factors when integrated with other complementary energy storage technology [28]. This is as a result of the capability of hydrogen for bulk energy storage and VRFB with higher efficiencies is complementary. Furthermore, the effect of the integrated systems depends on the level of excess wind sent to either the hydrogen or VRFB storage system. In independent systems, all the excess wind is sent to each individual storage technology; however, with an integrated approach, the excess wind must be split between the two storage systems.

Storage systems benefit from increased value regarding technical and economic factors when integrated with other complementary energy storage technology.

## **4. Decentralised hydrogen airport scenario**

## **4.1. Decentralised energy systems**

*3.2.2. All-iron redox flow batteries*

192 Energy Management of Distributed Generation Systems

represents its main disadvantage [22, 23].

[22, 27].

*3.2.3. Energy storage integration*

when there are no high periods of curtailment.

The all-iron RFB like VRFB employs the use of a single chemical element (in this case iron) in several oxidation states on both sides of the active cell, **Table 2**, while the electrolyte is kept outside in the storage tanks. The positive electrode of the all-iron battery is the ferric/ferrous redox couple, and the negative electrode involves iron plating from Fe (II) [22]. An advantage of all-iron RFB is the readily available electrolyte with an estimated low cost of 0.23 \$/l [23]. In the traditional all-iron RFB, at the negative side, the ferrous ions are reduced during charge. Their plating as iron metal onto a graphite electrode of the stack occurs leading to a coupling between energy and power. On the positive side of the battery, ferrous ions are oxidised to ferric ions during charge remaining in the solution. Reactions are opposite on discharge. Cheap aqueous electrolytes, inexpensive separators and the widespread availability of iron (~230 billion metric tonnes of iron) give the all-iron RFB, the potential of reduced storage system cost, while the plating and, consequently, the coupling between the energy and power

To avoid this disadvantage, a slurry electrode containing electrically conductive carbonaceous particles can be made by flowing them in an electrolyte containing the dissolved iron species [22]. Such conductive particles can include carbon black and/or carbon allotropes with different surface areas and enhanced conductivity, carbon micro-flakes, nanofibres, nanotubes etc. Thus, iron is plated onto the carbon particles at the negative side while charging. The carbon particles can then carry the iron metal to be stored in the external tanks allowing for energy storage capacity and power decoupling, allowing the economic advantages of scaling inherent to RFB to be recovered [22]. The carbons and their properties influence the electronic conduc‐ tivity of the slurry electrodes that have to be greater than the ionic conductivity of the elec‐ trolyte. This allows for the iron deposition to occur only onto the slurry particles and not on the current collector leading to a better control of the current distribution [22]. The electrode surface area plays an important role in determining the all-iron (hybrid) RFB efficiency and lifetime. For slurry all-iron RFB, this role becomes secondary. Presently, the slurry all-iron RFBs are still in the development stage putting them at a disadvantage to the already com‐ mercialised VRFB. Typically, the energy density of the all-iron hybrid battery is 12.7 Wh/l with a specific energy 10.9 Wh/kg. Energy efficiency is 55% with operating temperature T0 = 40°C

There is much focus on the introduction of storage systems; however, the integration of different storage systems to complement the use should also be considered. For example, research was conducted on the integration of compressed hydrogen storage and VRFB. From system dynamics modelling, it was identified as a result of higher available wind energy for storage and the hydrogen system is able to provide more energy to the system due to its capability as a bulk energy storage medium. In contrast, the RFBs are capable of providing more energy to the system with reduced availability of wind energy for storage, as a result of higher efficiencies. Therefore, VRFBs or all-iron RFBs are more efficient energy storage at times

Decentralised energy systems are gaining focus due to energy security and climate change considerations along with the high GHG emissions from centralised fossil fuel plants. Decen‐ tralised energy systems can potentially allow for the changes required in the energy sector [29– 36]. Advantages include their ability to operate with more than one source of energy and also their potential to be integrated with renewable energy and storage systems [33, 34]. Currently, the majority of energy systems consist of centralised power plants. Centralised energy generation benefits from high economies of scale, base load power capacity and reliability (if energy resources are available) [35]. However, it is clear a transition from these conventional fossil fuel power plants is required. Challenges of decentralised energy include technical challenges of operating the power plants and reliability of the overall system as if the power plant is relying on non-dispatchable generation, the capacity can be affected and require investments in back-up power [33].

Energy management is required for planning energy generation for consumption. Energy management is important for mitigating energy problems. It allows for the optimum operation of energy generation and storage systems to maximise efficiency. It is evident that within renewable decentralised systems, energy storage and energy management of these systems will play an important role. The complexity of the integration of the systems will require management to optimise the generation, storage and use of energy. Decentralised energy systems are envisioned for a hydrogen economy to emerge. Both compressed and liquid hydrogen energy systems can provide valuable green energy carrier if produced from zero/low carbon emission methods.

The next section will further highlight the different applications and importance of liquid hydrogen with a discussion on the decentralised use of liquid hydrogen in an airport scenario.

## **4.2. Hydrogen as a cryogen**

An additional application for liquid hydrogen (20 K) is as a cryogen for superconducting technologies. Interest has grown in finding a suitable low temperature cryogen as a result of predicted helium shortages and price increases. There is a predicted and well-documented incoming shortage of helium for superconducting applications [37–42],] and hydrogen as a cryogenic coolant has been envisaged as a viable and more economically justified cooling option for superconducting devices [37]. There are many novel engineering designs that can be made possible by using medium-temperature MgB2 superconducting wires, as developed originally in Cambridge [43] that include the following; a self-contained fully electric super‐ conducting ship, DC fault current limiters, high DC current homopolar motors, cheaper superconducting MgB2 magnets for fusion [41], SMES [41–43] and MRI systems. Development of liquid hydrogen indirectly cooled MgB2 superconducting high voltage DC cables especially for computer data centres present ideal candidates for early implementation [44]. Hydrogen's use as a coolant, as well as an energy carrier, will spin off new research and developments in superconducting materials and efficient energy use.

As the quantity of hydrogen liquefied is increased, less energy is wasted and the more efficient and cost-effective the process. The liquefaction process can occur by the Joule–Thomson expansion cycle. The hydrogen is compressed at ambient pressure and passed through a heat exchanger in which the temperature is reduced. As a result of hydrogen cooling on expansion, the temperature should be below the inversion temperature *T*inv = 200 K. A nitrogen precooling step is introduced, before the hydrogen is passed to the expansion valve. The energy required for the compressor and expansion valves reduces the overall efficiency of the process. As liquid hydrogen is a cryogen with a low boiling temperature of *T*boil = 20 K (under normal pressure), it must be stored in insulated cryogenic containers which are designed with double walls and an insulating space between the two walls to reduce heat transfer to the liquid. Heat transfer causes the liquid to evaporate and form gas a process called boil-off. Heat also arises from the ortho-para conversion of hydrogen. To minimise boil-off of the hydrogen for longer storage, an ortho-para conversion must be completed before liquefaction. The use of catalysts facilitates the ortho-para conversion of hydrogen [45].

Considering liquid hydrogen safety, direct cooling can only be handled by highly specialised organisations and companies, but indirect liquid hydrogen cooling, (iLH2), can be a viable option. In iLH2 installations, a helium gas exchanger can be used, transferring cooling power of the hydrogen bath at ~20 K to the desired cryomagnetic installation [45]. A pertinent example of indirect cooling by liquid nitrogen is given by McDonald et al. that designed a cooling system for a 15 T pulsed copper solenoid magnet to a desired temperature of 30 K in order to reduce the resistance of the Cu, thereby reducing the power requirements of the system [45]. The design as proposed cooled the magnet via a closed helium loop circulated through a heat exchanger filled with liquid hydrogen from a storage Dewar. It is clear hydrogen both compressed and liquefied will have important implications for different aspects of energy systems.

#### **4.3. Airport scenario**

As a further development of hydrogen storage, a decentralised vision of low-carbon airport systems will be analysed. Low-carbon systems integrated with hydrogen will be important as a result of the increasing threat of climate change, resource consumption and increasing energy demand. Storage systems alone will not be able to solve these problems, and innovative solutions integrated with storage systems are required such as that depicted in **Figure 8**.

predicted helium shortages and price increases. There is a predicted and well-documented incoming shortage of helium for superconducting applications [37–42],] and hydrogen as a cryogenic coolant has been envisaged as a viable and more economically justified cooling option for superconducting devices [37]. There are many novel engineering designs that can be made possible by using medium-temperature MgB2 superconducting wires, as developed originally in Cambridge [43] that include the following; a self-contained fully electric super‐ conducting ship, DC fault current limiters, high DC current homopolar motors, cheaper superconducting MgB2 magnets for fusion [41], SMES [41–43] and MRI systems. Development of liquid hydrogen indirectly cooled MgB2 superconducting high voltage DC cables especially for computer data centres present ideal candidates for early implementation [44]. Hydrogen's use as a coolant, as well as an energy carrier, will spin off new research and developments in

As the quantity of hydrogen liquefied is increased, less energy is wasted and the more efficient and cost-effective the process. The liquefaction process can occur by the Joule–Thomson expansion cycle. The hydrogen is compressed at ambient pressure and passed through a heat exchanger in which the temperature is reduced. As a result of hydrogen cooling on expansion, the temperature should be below the inversion temperature *T*inv = 200 K. A nitrogen precooling step is introduced, before the hydrogen is passed to the expansion valve. The energy required for the compressor and expansion valves reduces the overall efficiency of the process. As liquid hydrogen is a cryogen with a low boiling temperature of *T*boil = 20 K (under normal pressure), it must be stored in insulated cryogenic containers which are designed with double walls and an insulating space between the two walls to reduce heat transfer to the liquid. Heat transfer causes the liquid to evaporate and form gas a process called boil-off. Heat also arises from the ortho-para conversion of hydrogen. To minimise boil-off of the hydrogen for longer storage, an ortho-para conversion must be completed before liquefaction. The use of catalysts facilitates

Considering liquid hydrogen safety, direct cooling can only be handled by highly specialised organisations and companies, but indirect liquid hydrogen cooling, (iLH2), can be a viable option. In iLH2 installations, a helium gas exchanger can be used, transferring cooling power of the hydrogen bath at ~20 K to the desired cryomagnetic installation [45]. A pertinent example of indirect cooling by liquid nitrogen is given by McDonald et al. that designed a cooling system for a 15 T pulsed copper solenoid magnet to a desired temperature of 30 K in order to reduce the resistance of the Cu, thereby reducing the power requirements of the system [45]. The design as proposed cooled the magnet via a closed helium loop circulated through a heat exchanger filled with liquid hydrogen from a storage Dewar. It is clear hydrogen both compressed and liquefied will have important implications for different aspects of energy

As a further development of hydrogen storage, a decentralised vision of low-carbon airport systems will be analysed. Low-carbon systems integrated with hydrogen will be important as a result of the increasing threat of climate change, resource consumption and increasing energy

superconducting materials and efficient energy use.

194 Energy Management of Distributed Generation Systems

the ortho-para conversion of hydrogen [45].

systems.

**4.3. Airport scenario**

**Figure 8.** Future integrated hydrogen energy systems utilising added value of liquid hydrogen.

**Figure 8** highlights a more complex depiction of **Figure 3** with the use of hydrogen not only for storage and electricity generation but also as a fuel for the aviation industry. It should be noted the flexibility of hydrogen as an energy vector being capable of being used for passenger transport, aviation, thermal and cryogenic applications as well as bulk energy storage and electricity generation. With the increasing energy problems and aims to reduce carbon dioxide emissions and energy dependence, the use of hydrogen can now be seen as a viable solution. The support of necessary policy measures can allow the hydrogen economy to emerge in an attempt to mitigate fossil fuel use other energy problems as mentioned.

A centralised hydrogen vision can be considered with the use of low-carbon systems such as nuclear energy and steam methane reforming integrated with carbon capture and storage; however, from **Figure 8**, a decentralised vision can alternatively be considered as a potential solution. Airbus, a leading aircraft manufacturer, has received a patent for the design of a supersonic passenger plane operated on hydrogen, **Figure 9**. The plane has three different engine types, and the plane is fuelled by hydrogen and liquid oxygen. The fuel cell is to be held in the cargo hold with the liquid hydrogen tank and heat exchangers located in the tail. The fuel cell in the aircraft transforms chemical energy from the hydrogen into electricity through a chemical reaction with oxygen with waste of water, heat and oxygen-depleted air allowing reduced operation emissions. Such an aircraft can have implications for the aviation sector. Additionally, it is predicted that the water produced can be used to reduce the water required on-board that can reduce the weight and therefore fuel consumption of the aircraft.

**Figure 9.** Concept from Airbus for the hydrogen fuelled aircraft [44].

## **5. Conclusions**

The results of the investigation into the various energy storage technologies available for energy management of decentralised renewable energy systems highlight the large potential of hydrogen as a storage medium for energy management of decentralised energy systems but also further highlight one concept in which the further value of hydrogen is explored in with regard to an airport scenario. With large focus on the decarbonisation of electricity systems, the need for further opportunities for decarbonisation within the heat and transport sector is required. Decentralised hydrogen energy systems can be a solution to the aircraft industry requirement to lower emissions and reduce dependence on fossil fuels. Hydrogen and other storage technologies can allow a suitable energy carrier for managing the transition to a decarbonised energy system.

## **Author details**

Bartek A. Glowacki1,2,3\* and Emma S Hanley1

\*Address all correspondence to: bag10@cam.ac.uk

1 Department of Physics and Energy and Bernal Institute, University of Limerick, Castletroy, Limerick, Ireland

2 Department of Materials Science and Metallurgy, University of Cambridge, Cambridge, United Kingdom

3 Institute of Power Engineering, Warsaw, Poland

## **References**

**Figure 9.** Concept from Airbus for the hydrogen fuelled aircraft [44].

196 Energy Management of Distributed Generation Systems

The results of the investigation into the various energy storage technologies available for energy management of decentralised renewable energy systems highlight the large potential of hydrogen as a storage medium for energy management of decentralised energy systems but also further highlight one concept in which the further value of hydrogen is explored in with regard to an airport scenario. With large focus on the decarbonisation of electricity systems, the need for further opportunities for decarbonisation within the heat and transport sector is required. Decentralised hydrogen energy systems can be a solution to the aircraft industry requirement to lower emissions and reduce dependence on fossil fuels. Hydrogen and other storage technologies can allow a suitable energy carrier for managing the transition to a

1 Department of Physics and Energy and Bernal Institute, University of Limerick, Castletroy,

2 Department of Materials Science and Metallurgy, University of Cambridge, Cambridge,

**5. Conclusions**

decarbonised energy system.

Bartek A. Glowacki1,2,3\* and Emma S Hanley1

\*Address all correspondence to: bag10@cam.ac.uk

3 Institute of Power Engineering, Warsaw, Poland

**Author details**

Limerick, Ireland

United Kingdom


[26] Viswanathan V., Crawford A., Stephenson D., Kim S., Wank W., Li B., Coffey G., Thomsen E., Graff G., Balducci P., Kintner-Meyer M., Sprenkle V. Cost and performance model for redox flow batteries. Journal of Power Sources 2014; 247, 1040–1051.

[13] Satyapal S., Petrovic J., Read C., Thomas G., Ordaz G. The U.S. Department of energy's national hydrogen storage project: progress towards meeting hydrogen-powered

[14] Ross D.K. Hydrogen storage: the major technological barrier to the development of

[15] US Department of Energy, 2011, Fuel cells technologies program. http:// www1.eere.energy.gov/hydrogenandfuelcells/pdfs/fct\_h2\_storage.pdf (accessed

[16] Lozano-Castelló, D., Suárez-García,F., Linares-Solano, A., Cazorla-Amorós,D., Chapter 12 - Advances in Hydrogen Storage in Carbon Materials, In Renewable Hydrogen Technologies, edited by Luis M. Gandía, Gurutze Arzamendi and Pedro M. Diéguez, Elsevier, Amsterdam, 2013, pp 269-291, ISBN 9780444563521, http://dx.doi.org/10.1016/

[18] James B.D., 2012, Hydrogen storage cost analysis preliminary results.http:// www.hydrogen.energy.gov/pdfs/review12/st100\_james\_2012\_o.pdf(accessed

[19] Johansson T.B., Kelly H., Reddy A.K.N., 1993, Renewable energy: sources for fuels and electricity. http://www.iphe.net/docs/Events/Seville\_11-12/Workshop/Presentations/

[20] Weber A.Z., Mench M.M., Meyers J.P., Ross P.N., Gostick J.T., Liu Q. Redox flow batteries: a review. Journal of Applied Electrochemistry 2011; 41, 1137–1164.

[21] Chalamala B.R., Soundappan T., Fisher G.R., Anstey M.R., Viswanathan V.V., Perry M.L. Redox flow batteries: an engineering perspective. Proceedings of the IEEE 2014;

[22] Hawthorne K.L., Wainright J.S., Savinell R.F. Studies of iron-ligand complexes for an all-iron flow battery application. Journal of the Electrochemical Society 2014; 161,

[23] Petek T.J., Wainright J.S., Savinell R.F. Slurry electrode for an all-iron flow battery for low cost large-scale energy storage. Abstract for 2013 IChE Annual Meeting, Hilton San

[24] Solarenvi, Cell cube FB 10-100. http://www.solarenvi.cz/assets/Downloads/datasheets/

[25] Hung C.J., Liu C.H., Wang C.H., Chen W.H., Shen C.W., Liang H.C., Ko T.H. Effect of conductive carbon material content and structure in carbon fiber paper made from carbon felt on the performance of a proton exchange membrane fuel cell. Renewable

Session%203/3.1\_IPHE%20workshop\_Harrison.pdf (accessed 02/007/2015).

[17] Züttel A. Materials for hydrogen storage. Materials Today 2003; 6 (9) 24–33.

vehicle requirements. Catalysis Today 2007; 120 (3–4) 246–256.

hydrogen fuel cell cars. Vacuum 2006; 80 (10) 1084–1089.

06/07/2015).

06/07/2015).

102, 976–999.

A1662–A1671.

Energy 2015; 78, 364–373.

Francisco, Union Square, San Francisco, CA.

fv\_Cellstrom-Cellcube-FB-10-100.pdf (accessed 10/04/2014).

B978-0-444-56352-1.00012-X.

198 Energy Management of Distributed Generation Systems


**Energy Management Systems for Smart Homes**

[40] Patel A., Hopkins S.C., Giunchi G., Figini AA., Shi Y., Palka R., Cardwell D., Glowacki B.A. The use of an MgB2 hollow cylinder and pulse magnetized for magnetic levitation applications. IEEE Transactions Applied Superconductivity 2013; 23 (3).DOI: 10.1109/

[41] Sander M., Brighenti F., Gehring R., Jordan T., Klaeser M., Kraft D., Mueller R., Neumann H., Schneider T., Stern G. LIQHYSMES—Liquid H2 and SMES for renewable energy applications. International Journal of Hydrogen Energy 2014; 39 (23) 12007–

[42] Sander M., Gehring R., Neumann H., Jordan T. LIQHYSMES storage unit—Hybrid energy storage concept combining liquefied hydrogen with superconducting magnetic energy storage. International Journal of Hydrogen Energy 2012; 37 (19) 14300–14306.

[43] Makida Y., Shintomi T., Asami T., Suzuki G., Takao T., Hamajima T., Tsuda M., Miyagi D., Munakata K., Kajiwara M. Design study of the cooling scheme for SMES system in ASPCS by using liquid hydrogen. Physica C: Superconductivity 2013; 494 (15) 208–212.

[44] Airbus. Fuel Cells. http://www.airbus.com/innovation/future-by-airbus/future-energy

[45] Cheadle M.J., Wozniak M., Bromberg L., Glowacki B.A., Jiang X., Zeng R., Minervini J.V., Brisson J.G. DC Superconducting Cable Using MgB2 Wires IEEE Transactions on

[46] Chen J.Y.C. Spin Isomers of Molecular Hydrogen and Improved Sensitivity for NMR and MRI. https://www.organicdivision.org/ama/orig/Fellowship/2009\_2010\_Awar‐

[47] MacDonald K.T., Iarocci M., Kirk H.G., Mulholland, G.T., Titus P.H., Weggel R.J. Use of He gas cooled by liquid hydrogen with a 15-T pulsed copper solenoid magnet.

Applied Superconductivity 2013; 23.DOI: 10.1109/TASC.2013.2248313.

TASC.2012.2236143.

200 Energy Management of Distributed Generation Systems


dees/Essays/Chen.pdf (accessed 28/02/2016).

Technical/Economic Report August 15 2002; 1–5.

12017.

## **Securing the Home Energy Management Platform**

Søren Aagaard Mikkelsen and Rune Hylsberg Jacobsen

Additional information is available at the end of the chapter

http://dx.doi.org/10.5772/62923

#### **Abstract**

Energy management in households gets increasingly more attention in the struggle to integrate more sustainable energy sources. Especially in the electrical system, smart grid systems are envisioned to be part in the efforts towards a better utilisation of the energy production and distribution infrastructure. The Home Energy Management System (HEMS) is a critical infrastructure component in this endeavour. Its main goal is to enable energy services utilising smart devices in the households based on the interest of the residential consumers and external actors. With the role of being both an essential link in the communication infrastructure for balancing the electrical grid and a surveillance unit in private homes, security and privacy become essential to address. In this chapter, we identify and address potential threats Home Energy Man‐ agement Platform (HEMP) developers should consider in the progress of designing architecture, selecting hardware and building software. Our approach starts with a general view of the involved stakeholders and the HEMS. Given the system over‐ view, a threat model is constructed from the HEMP developer's point of view. Based on the threats that have been detected, possible mitigation strategies are proposed taking into account the state of the art of technology for securing platforms.

**Keywords:** smart grid, IoT, security, privacy, cloud, web service, service‐oriented ar‐ chitecture

## **1. Introduction**

A smart grid is a vision of a more intelligent electrical infrastructure. It is envisioned to provide a more reliable and effective electrical grid in the process of integrating more intermittent renewable energy sources, like wind power and solar power. This will demand for systems that

© 2016 The Author(s). Licensee InTech. This chapter is distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/by/3.0), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

will continuously monitor and manage end‐points of the grid, for example, an end‐point as the residential sector that consumes around 31% ofthe electricity worldwide [1]1 . These systems are known as Energy Management Systems (EMSs)2 . EMSs aim at utilising the grid capacity more efficiently in terms of instantaneous demand and generation. This includes flattening the peak demand by giving the demand‐side awareness about the time periods it is "smart" to con‐ sume energy [2].

Ensuring security and privacy are becoming important issues to address with the deployment of smart meters. Smart meters are devices that record the electric consumption and production and communicates this information automatically to the utility. Research has shown that information from smart meters can reveal personal habits and disclose details about the residents living there. Furthermore, the situation exacerbates if additional meters and actuators are installed on the most consuming devices for Direct Load Control (DLC) in the demand response paradigm. Therefore, security and privacy enhanced system architectures suggest, a Home Energy Management System (HEMS) that runs locally inside the residential home, among other things to resolve privacy issues.

**Figure 1.** The considered stack for a HEMS.

This chapter describes security and privacy issues for a HEMS in an SOA. It focuses on the Home Energy Management Platform (HEMP) provider [also in other contexts referred to as the Original Equipment Manufacturer (OEM)]. A HEMP provider is responsible for the platform, which the software developers and service providers can deploy their software and services on as seen in **Figure 1**. A HEMP provider creates the platform that facilitates security and privacy in several layers. Following a holistic approach, a threat modelling approach is used that considers the interdependencies between stakeholders of the system before identi‐ fying the threats the system faces. A risk assessment is made on the identified threats, and

<sup>1</sup> Percentage based on the average electricity consumption from residential domains in Spain, Norway and Denmark.

<sup>2</sup> EMSs can refer to not only systems that support the operation of the electrical grid on a transmission and distribution level but also systems that automatically control and monitor energy usage in buildings.

possible mitigation strategies are presented based on a review of the state of the art in hardware security. Based on the threat analysis, recommendations to create a secure HEMS are provided.

## **2. Background and related work**

will continuously monitor and manage end‐points of the grid, for example, an end‐point as the

efficiently in terms of instantaneous demand and generation. This includes flattening the peak demand by giving the demand‐side awareness about the time periods it is "smart" to con‐

Ensuring security and privacy are becoming important issues to address with the deployment of smart meters. Smart meters are devices that record the electric consumption and production and communicates this information automatically to the utility. Research has shown that information from smart meters can reveal personal habits and disclose details about the residents living there. Furthermore, the situation exacerbates if additional meters and actuators are installed on the most consuming devices for Direct Load Control (DLC) in the demand response paradigm. Therefore, security and privacy enhanced system architectures suggest, a Home Energy Management System (HEMS) that runs locally inside the residential home,

This chapter describes security and privacy issues for a HEMS in an SOA. It focuses on the Home Energy Management Platform (HEMP) provider [also in other contexts referred to as the Original Equipment Manufacturer (OEM)]. A HEMP provider is responsible for the platform, which the software developers and service providers can deploy their software and services on as seen in **Figure 1**. A HEMP provider creates the platform that facilitates security and privacy in several layers. Following a holistic approach, a threat modelling approach is used that considers the interdependencies between stakeholders of the system before identi‐ fying the threats the system faces. A risk assessment is made on the identified threats, and

Percentage based on the average electricity consumption from residential domains in Spain, Norway and Denmark.

but also systems that automatically control and monitor energy usage in buildings.

EMSs can refer to not only systems that support the operation of the electrical grid on a transmission and distribution level

. These systems are

. EMSs aim at utilising the grid capacity more

residential sector that consumes around 31% ofthe electricity worldwide [1]1

known as Energy Management Systems (EMSs)2

204 Energy Management of Distributed Generation Systems

among other things to resolve privacy issues.

**Figure 1.** The considered stack for a HEMS.

1

2

sume energy [2].

A preliminary review of the domain is presented before developing a threat model for the HEMP. The review includes a description of general threat modelling approaches together with commonly used diagrams to perform the analysis.

## **2.1. Threat modelling approaches**

Threat modelling is a systematic approach that supports the process of finding the appropriate technical solutions for enforcing security and privacy. It considers the potential threats with the greatest impact and addresses these first.

There are generally three approaches to threat modelling [3]:


When comparing the approaches, the system‐centric approach more tightly couples with the development process, whereas the asset‐centric approach and attacker‐centric approach can be considered more "detached" and are typically performed separate from the software development.

## *2.1.1. Diagrams for threat modelling*

The typical diagrams for revealing threats focus on describing the domain or the data flows within the considered system. The goals of these diagrams are to create a common view of the system and to make the communication paths visible. These diagrams provide an abstraction

<sup>3</sup> Is often called *software-centric*, but for the sake of generality we use the term *system-centric*.

of the system which allows system architects and software developers to create a common view of the system and define the system boundaries.

The Unified Modelling Language (UML) [4] is general‐purpose modelling language that specifies a set of diagrams for modelling systems. It provides a standardised way of modelling systems and provides two fundamental representations of a system: behavioural models and structural models. Behavioural models, such as use case diagrams, can be beneficial to identify stakeholders and describe a proposed functionality. Structural models, such as class diagrams, are useful for describing the domain which includes objects, attributions, operations and relationships.

Data Flow Diagrams (DFDs) have traditionally been used for threat modelling, since the threat problems tend to follow the data flow not the control flow [3]. It is used for describing how data enter and leave the system. The basic elements for modelling the system are shown in **Table 1**. The system is typically modelled with specific scope, where the external system that provides the system with data is modelled using the *external entity* element. The system of interest consists of a number of *processes* and *data stores* with *data flow* between them. To define the boundary between trust elements and non‐trusted elements, DFD also includes trust boundaries. Trust boundaries visualise where data flows intersect between the system and a malicious actor.


**Table 1.** The basic elements of a DFD.

By modelling the specific system with DFD elements, it is possible to map these elements to the STRIDE threats. For instance, an external entity for the system can generate a *spoofing* threat, that is, an external entity can pretend to be something or someone else than originally thought of. By enforcing an authentication mechanism, it is possible to mitigate the threat if the external entity was trying to *spoof* a person or a thing.

## **2.2. Home energy management software platforms**

As depicted in Figure 1, the HEMS consists of a software platform that provides the middle‐ ware for interoperable communication between devices and services. In the following, two open source EMSs are presented. Both use the OSGi (Open Service Gateway Initiative) architecture that specifies a modular and service‐based software platform implemented in Java.

## *2.2.1. OpenHAB*

of the system which allows system architects and software developers to create a common

The Unified Modelling Language (UML) [4] is general‐purpose modelling language that specifies a set of diagrams for modelling systems. It provides a standardised way of modelling systems and provides two fundamental representations of a system: behavioural models and structural models. Behavioural models, such as use case diagrams, can be beneficial to identify stakeholders and describe a proposed functionality. Structural models, such as class diagrams, are useful for describing the domain which includes objects, attributions, operations and

Data Flow Diagrams (DFDs) have traditionally been used for threat modelling, since the threat problems tend to follow the data flow not the control flow [3]. It is used for describing how data enter and leave the system. The basic elements for modelling the system are shown in **Table 1**. The system is typically modelled with specific scope, where the external system that provides the system with data is modelled using the *external entity* element. The system of interest consists of a number of *processes* and *data stores* with *data flow* between them. To define the boundary between trust elements and non‐trusted elements, DFD also includes trust boundaries. Trust boundaries visualise where data flows intersect between the system and a

External entity Outside scope A stakeholder delivering or receiving

Process Execution of system element Executable code or hardware function

By modelling the specific system with DFD elements, it is possible to map these elements to the STRIDE threats. For instance, an external entity for the system can generate a *spoofing* threat, that is, an external entity can pretend to be something or someone else than originally thought

to the system

RPC calls, system calls, HTTP

view of the system and define the system boundaries.

206 Energy Management of Distributed Generation Systems

**Element Model Description Examples**

elements

Data store Entity that stores data Files, memory, database

Data flow Communication between

**Table 1.** The basic elements of a DFD.

relationships.

malicious actor.

The openHAB project4 is an open software framework that focusses on enabling home automation by joining systems and technologies available in the smart home domain. It allows for automation rules and offers a single user interface for all such systems. The openHAB software is capable of running on any device that supports the Java Virtual Machine (JVM). The architecture consists of three main components: the OSGi framework, openHAB Core Components and openHAB Add‐ons. The OSGi framework and the openHAB Core Compo‐ nents represent the internal communication infrastructure and base libraries. The openHAB Add‐ons include a large set of protocol bindings that map between other home automation protocols to an abstract data model. It includes an "item" repository, where an item can be interpreted as an abstraction for a property a device can actuate. The openHAB framework provides mechanisms for securing the communication to the openHAB software platform, but does not have additional security features beside what the OSGi framework can provide.

#### *2.2.2. OGEMA*

Open Gateway Energy Management (OGEMA)5 is an open software framework for smart grid services. It represents a system that supports building automation control and energy man‐ agement for residential and industrial environments. The framework rests on a hardware‐ independent platform with a common execution environment for all deployable services. OGEMA uses the OSGi Java framework enabling a modular and dynamic software environ‐ ment. The OGEMA framework consists of the following entities:


<sup>4</sup> http://www.openhab.org/

<sup>5</sup> http://www.ogema.org/

The OGEMA architecture embeds three "modes" of security: standard infrastructure, a controlled environment and proof of security [5]. Furthermore, it isolates third‐party applica‐ tions which can be integrity checked using the public key of the service provider. This is similar to Android's permission handling [5]. Since OGEMA framework is restricted to security capability of the OSGi Java framework and the JVM, it is possible for a malicious component to freeze the platform by allocating too much memory or changing shared variables. A possible solution to this issue is the I‐JVM presented in [6].

## **2.3. Threat analysis of the smart grid domain**

Cyber‐Physical Systems (CPSs) and Internet of Things (IoTs) are two research domains that overlap and share similar challenges with the smart grid domain. In [7], they identify four key challenges in designing a secure IoT which include data management, identity management, trust management and privacy. Based on these challenges, they propose hardware‐based mitigation strategies that include Physical Unclonable Function (PUF) for data provenance, integrity and identity management. However, they present a non‐systematic approach where the stakeholders are not clearly identified. In reference [8], they consider threat modelling issues of CPSs. The authors provide a generic model of a CPS and present a case study with a road vehicle. In reference [9], researchers present a survey of security theories, analysis, simulation and application fields but without giving recommendations.

In reference [10], they present a structured method for identifying security threats in smart home scenarios. It is based on a context pattern for the elicitation of domain knowledge for the smart home domain. Using the context pattern for creating DFDs for the smart domain, they identify the entry points and vulnerabilities. This allows them to define the attack paths from entry point to the assets of the system. Their method is sound and structured but lacks possible threat mitigation strategies.

## **3. Threat modelling of a home energy management platform**

Security experts are encouraging designers to make explicit statements about the security assumptions, when designing and implementing systems. Defining the security assumptions is the first step in order to find the vulnerabilities of a system. With a description of the vulnerabilities, it is possible to assess the risks a given design exposes. Security technologies can then be enforced where the vulnerabilities need to be addressed.

## **3.1. Methodology**

A systematic approach is necessary to discover all the vulnerabilities of a system [10]. Our approach for designing a HEMP is shown in **Figure 2**, consisting of five steps. The methodology is based on the work presented in references [3, 10, 11], but adapted to our work.

**Figure 2.** The methodology for performing the threat modelling.

The OGEMA architecture embeds three "modes" of security: standard infrastructure, a controlled environment and proof of security [5]. Furthermore, it isolates third‐party applica‐ tions which can be integrity checked using the public key of the service provider. This is similar to Android's permission handling [5]. Since OGEMA framework is restricted to security capability of the OSGi Java framework and the JVM, it is possible for a malicious component to freeze the platform by allocating too much memory or changing shared variables. A possible

Cyber‐Physical Systems (CPSs) and Internet of Things (IoTs) are two research domains that overlap and share similar challenges with the smart grid domain. In [7], they identify four key challenges in designing a secure IoT which include data management, identity management, trust management and privacy. Based on these challenges, they propose hardware‐based mitigation strategies that include Physical Unclonable Function (PUF) for data provenance, integrity and identity management. However, they present a non‐systematic approach where the stakeholders are not clearly identified. In reference [8], they consider threat modelling issues of CPSs. The authors provide a generic model of a CPS and present a case study with a road vehicle. In reference [9], researchers present a survey of security theories, analysis,

In reference [10], they present a structured method for identifying security threats in smart home scenarios. It is based on a context pattern for the elicitation of domain knowledge for the smart home domain. Using the context pattern for creating DFDs for the smart domain, they identify the entry points and vulnerabilities. This allows them to define the attack paths from entry point to the assets of the system. Their method is sound and structured but lacks possible

Security experts are encouraging designers to make explicit statements about the security assumptions, when designing and implementing systems. Defining the security assumptions is the first step in order to find the vulnerabilities of a system. With a description of the vulnerabilities, it is possible to assess the risks a given design exposes. Security technologies

A systematic approach is necessary to discover all the vulnerabilities of a system [10]. Our approach for designing a HEMP is shown in **Figure 2**, consisting of five steps. The methodology

is based on the work presented in references [3, 10, 11], but adapted to our work.

simulation and application fields but without giving recommendations.

**3. Threat modelling of a home energy management platform**

can then be enforced where the vulnerabilities need to be addressed.

solution to this issue is the I‐JVM presented in [6].

**2.3. Threat analysis of the smart grid domain**

208 Energy Management of Distributed Generation Systems

threat mitigation strategies.

**3.1. Methodology**

The following gives a description of the six steps in our method:

**Step 1. Define context and objectives—**The context represents the identification of the main stakeholders of the system, the general system architecture and the desired objectives. The purpose of this step is to create the scope of interest and focus on the analysis. Part of the context is the review of regulations with the smart grid area and to describe the considered use cases. This includes also defining the dependency between stakeholders. With the definition of the context and objectives, requirements can be elicited.

**Step 2. Define DFD—**Using the previously defined context, the flow of information is modelled through DFDs. Context elements are mapped to elements that present input/output, processes, data flow and data storage. In the modelling process, the context can be refined, for example, adding additional stakeholders or modifying the system architecture. Furthermore, it supports the process of modelling the domain knowledge to DFD elements. With the process of defining the context and modelling, the DFD represent the high‐level system description.

**Step 3. Identify assets and vulnerabilitiesbased on DFD elements—**Based on the DFD elements representing the HEMP, the system's assets and threats are identified. Assets represent valuable targets for an attacker and are therefore of interest for the attacker. Assets can be both physical and linked to a process. One approach to identify threats for the identified assets is the STRIDE‐per‐element or STRIDE‐per‐interaction approach [3].

**Step 4. Risk impact assessment based on attack trees—**With explicit threats, the risk impact assessment can be performed using attack trees. The step assesses how noticeable and with what likelihood a threat is. The outcome of this assessment can be either accepted or mitigated using a technical solution. An accepted risk represents a possible attack, but it is typically regarded as unlikely.

**Step 5. Selection of mitigation approach—**If a threat is unacceptable, a selection of a mitiga‐ tion solution must be considered. The solution can be based on possible software or hardware technologies that consider an attacker with the same power or more. Mitigation can require a different hardware or software solution. The risk assessment of the threat can help in deter‐ mining the threat mitigation should be placed in the hardware or software.

#### **3.2. Stakeholders, system architecture and objectives**

In **Figure 3**, the major stakeholders of the HEMS are presented. The residential consumer enables the deployment of HEMSs. Trust to the system, reduction of/control of electricity bills, addressing environmental concerns and better comfort (i.e., provision of technical solutions for better control of own energy use) are the main motivational factors for the residential consumers to adopt a smart grid solution [12]. Smart device vendors build sensors and actuators deployed in homes, for example, Wink,6 SmartThings7 or Vera8 represent an envi‐ sioned smart device vendor. Often these vendors can be categorised whether or not they provide a total home automation solution or have upgraded an existing product to be IoT‐ enabled. In the envisioned system, the Distribution System Operator (grid operator) is not directly interacting with the HEMS, instead it depends on the smart grid services developed by service providers and deployed by the service market responsible. Services utilise infor‐ mation retrieved from the residential homes and electric grid, to improve electricity usage for both the residential consumers and grid operator. For connecting the services and the smart devices, a communication service provider (CSP) is needed. The software platform providers create the software platform, where services can be executed.

**Figure 3.** Overview of the major stakeholders of the HEMS. It is inspired by [32].

The HEMS is considered to be placed in an SOA, where there exist home‐oriented and grid‐ oriented services. The services are implemented as web services based on the REpresentational

<sup>6</sup> http://www.wink.com/

<sup>7</sup> https://www.smartthings.com/

<sup>8</sup> http://getvera.com/

State Transfer (REST) architectural style. The system considers many‐to‐one mapping between the residential consumer and the DSO, that is, the home‐oriented services are executed for each residential consumer, whereas the grid‐oriented services utilise the output for optimising the operation for the DSO.

The rationale of the system architecture is that the home‐oriented services will optimise according to demands of individual homes, whereas the grid‐oriented services will support the operation of the electrical grid. Since grid‐oriented services can be highly valuable for the grid responsible (DSO), these will foster the development of the home‐oriented services. A fundamental requirement for the approach is that the services can be used as *building blocks* for delivering additional services. For a more detailed insight into the system, the reader is referred to references [13, 14].

The main characteristics of a service‐oriented system are [15]:


**3.2. Stakeholders, system architecture and objectives**

210 Energy Management of Distributed Generation Systems

actuators deployed in homes, for example, Wink,6

create the software platform, where services can be executed.

**Figure 3.** Overview of the major stakeholders of the HEMS. It is inspired by [32].

6

7

8

http://www.wink.com/

http://getvera.com/

https://www.smartthings.com/

The HEMS is considered to be placed in an SOA, where there exist home‐oriented and grid‐ oriented services. The services are implemented as web services based on the REpresentational

In **Figure 3**, the major stakeholders of the HEMS are presented. The residential consumer enables the deployment of HEMSs. Trust to the system, reduction of/control of electricity bills, addressing environmental concerns and better comfort (i.e., provision of technical solutions for better control of own energy use) are the main motivational factors for the residential consumers to adopt a smart grid solution [12]. Smart device vendors build sensors and

sioned smart device vendor. Often these vendors can be categorised whether or not they provide a total home automation solution or have upgraded an existing product to be IoT‐ enabled. In the envisioned system, the Distribution System Operator (grid operator) is not directly interacting with the HEMS, instead it depends on the smart grid services developed by service providers and deployed by the service market responsible. Services utilise infor‐ mation retrieved from the residential homes and electric grid, to improve electricity usage for both the residential consumers and grid operator. For connecting the services and the smart devices, a communication service provider (CSP) is needed. The software platform providers

SmartThings7

or Vera8

represent an envi‐


The domain model is depicted in **Figure 4** using a UML class diagram together with the main stakeholders. It is composed of classes (rectangular icons), packages (folder icons) and actors (stick figures). It considers the domain to consist of two major parts: a s*ervice market* and a *residential home*. Both parts include a number of elements (represented as classes) that represent the implementation by a stakeholder. At this stage, only elements that are relevant for an identified stakeholder are considered. The relationship between the elements indicates the

**Figure 4.** Domain model of the system.

multiplicity and type of association. Besides the basic UML arrows representing the associa‐ tions, two other arrows are drawn. The dependency between the stakeholders is modelled with an open arrow to visualise how stakeholder's business objectives are associated with other stakeholders. A closed arrow indicates the realisation of the element.

In the process of defining hardware recommendations for the HEMP developer, focus is set on the HEMP developer as depicted and highlighted in **Figure 3**. As seen in Figure 4, the HEMP developer has several dependencies—either directly or indirectly.

To this end, the objective of the HEMP developer for the HEMS is the following:

*The HEMP will provide a security and privacy enhanced platform for service developers to deploy on web service on, while being a trustworthy platform for the residential consumers, service providers and the grid responsible.*

## **3.3. Requirements**

To identify the security threats and vulnerabilities of the HEMP (see Section 3.5), the necessary requirements, which the platform must adhere to, have to be explicitly stated. An explicit set of requirements can guide the process of designing a platform which is resistant to possible attacks. Furthermore, it allows for a risk assessment of third‐party services installed on the device.

Requirements are usually understood as stating *what* a system is supposed to do—contrary to *how* it should do it [16]. It characterises the desired functional behaviour and performance, whereas non‐functional requirements aim at fulfilling a desired property. Non‐functional requirements are usually judged by the operator of the system and relate more to the system architecture, whereas functional requirements are testable.

In the following, both the functional and non‐functional requirements for the HEMP will be presented. The requirements are classified according to the direct stakeholders for the HEMP developer. The rationale is that the requirements and dependencies from the stakeholders will have an impact on the threats and thereby on the mitigation strategies that technical solutions can provide. The listed requirements are derived from use cases and requirements specified in references [14, 17–19].

#### *3.3.1. Software platform developer*

An essential feature of the HEMS is to provide an environment for executing services relevant for external actors in the smart grid. This includes services with real‐time dependencies or not. These services can be manufactured by different service providers and therefore depend on an *isolated execution environment*, if a single service should not crash the system. Moreover, software trends dictate a continuous development and maintenance process to follow an agile development life cycle and fix newly discovered vulnerabilities. Thus, doing updates to the services is vital for its sustainability. Finally, a software platform is responsible for delivering the "knobs" of the smart devices for services and external system to interact with in a secure way. The requirements are as follows:

**R1**. The HEMS shall support execution of real‐time dependent services, like services for controlling a residential battery according to external signals.

**R2**. The HEMS employ separation mechanisms to securely isolate services.

**R3**. The HEMS shall be able to upgrade existing services.

**R4**. The HEMS shall support remote software updates from the software framework devel‐ opers for managing services.

**R5**. The HEMS shall provide security measures appropriate for the protection of integrity and confidentiality of services.

These requirements relate to service providers which represent the main stakeholder of the software platform developer.

## *3.3.2. Smart device vendor*

multiplicity and type of association. Besides the basic UML arrows representing the associa‐ tions, two other arrows are drawn. The dependency between the stakeholders is modelled with an open arrow to visualise how stakeholder's business objectives are associated with other

In the process of defining hardware recommendations for the HEMP developer, focus is set on the HEMP developer as depicted and highlighted in **Figure 3**. As seen in Figure 4, the HEMP

*The HEMP will provide a security and privacy enhanced platform for service developers to deploy on web service on, while being a trustworthy platform for the residential*

To identify the security threats and vulnerabilities of the HEMP (see Section 3.5), the necessary requirements, which the platform must adhere to, have to be explicitly stated. An explicit set of requirements can guide the process of designing a platform which is resistant to possible attacks. Furthermore, it allows for a risk assessment of third‐party services installed on the

Requirements are usually understood as stating *what* a system is supposed to do—contrary to *how* it should do it [16]. It characterises the desired functional behaviour and performance, whereas non‐functional requirements aim at fulfilling a desired property. Non‐functional requirements are usually judged by the operator of the system and relate more to the system

In the following, both the functional and non‐functional requirements for the HEMP will be presented. The requirements are classified according to the direct stakeholders for the HEMP developer. The rationale is that the requirements and dependencies from the stakeholders will have an impact on the threats and thereby on the mitigation strategies that technical solutions can provide. The listed requirements are derived from use cases and requirements specified

An essential feature of the HEMS is to provide an environment for executing services relevant for external actors in the smart grid. This includes services with real‐time dependencies or not. These services can be manufactured by different service providers and therefore depend on an *isolated execution environment*, if a single service should not crash the system. Moreover, software trends dictate a continuous development and maintenance process to follow an agile development life cycle and fix newly discovered vulnerabilities. Thus, doing updates to the services is vital for its sustainability. Finally, a software platform is responsible for delivering the "knobs" of the smart devices for services and external system to interact with in a secure

stakeholders. A closed arrow indicates the realisation of the element.

212 Energy Management of Distributed Generation Systems

developer has several dependencies—either directly or indirectly.

*consumers, service providers and the grid responsible.*

architecture, whereas functional requirements are testable.

**3.3. Requirements**

in references [14, 17–19].

*3.3.1. Software platform developer*

way. The requirements are as follows:

device.

To this end, the objective of the HEMP developer for the HEMS is the following:

End devices in the smart grids often represent the load of the electrical system. Giving these devices the ability to communicate with other devices facilitates information to be dissemi‐ nated to all stakeholders. For the smart devices to be part of the smart grid, a communication infrastructure in the Home Area Network (HAN) that incorporates a heterogeneous set of communication protocols is essential [20, 21]. Furthermore, for smart devices to provide a secure communication path, it is necessary to enable end‐to‐end encryption. The smart device vendors' requirements are as follows:

**R1**. The HEMS shall support multiple communication protocols for the HAN.

**R2**. The HEMS shall provide smart device vendors with the ability to extend the set of communication drivers easily.

**R3**. The HEMS shall facilitate end‐to‐end encryption between smart devices and the services that utilise and control the smart devices.

Besides depending on the physical communication technology implemented on the HEMS, software drivers are also necessary to provide an interface for a service.

#### *3.3.3. Residential consumer*

The intelligent automation of the smart grid depends on the residential consumers. They will be an integral part that will ensure reliability of the electrical grid by modifying the way energy is used. A HEMS can support the behavioural change but requires the acceptance of the residential consumer. It is generally believed that a user‐centric approach is vital, where trust to the system remains one of the priorities [12]. The requirements for a residential consumer are:

**R1**. The HEMS must secure the confidentially and integrity of meter data.

**R2**. The HEMS should provide residential consumers the ability to install and uninstall services on demand.

## **3.4. Data flow diagram of the home energy management platform**

The main purpose of DFDs is to identify the key *data flows* in the system. Modelling the data flows, contrary to the *control flows*, reveals how information is exchanged throughout the system. A DFD model explains who takes part in a process for delivering the information, the information needed to complete a process and what information is stored.

**Figure 5** provides an overview of the internal data flows on a HEMS and the HEMS interactions with the external entities based on reference [14]. Besides the DFD symbols presented in **Table 1**, the DFD is annotated with dotted lines indicating the trust boundaries. These are quantified three trust levels from the HEMP provider's point of view. Furthermore, it contains dotted arrows between processes, to indicate how a process affects another process's runtime. These are useful for expressing hardware‐related issues.

**Figure 5.** DFD of the HEMS.

As seen in Figure 5, seven processes are included in the model. This includes two services: third‐party HEM service and a Meter Data Management (MDM) service. The MDM service is explicitly included to show the data flow of meter data and storage of the smart device configurations. The third‐party HEM service presents any high‐level service useful for smart grid operations. The service manager and software framework manager relate to the contin‐ uous maintenance of the software on the HEMS. Lastly, there is a system manager and device manager for the physical interaction with the HEMS.

## **3.5. Threat analysis**

A threat model is a depiction of a system's attack surface. An attack surface has numerous threats towards a set of assets within the system. The purpose of mitigation techniques is to protect the assets from a possible attacker. The envisioned attacker can be assigned capabilities, such as being able to have physical access to the system or only have access through the network. Other attackers include social engineers which through "social" interaction can gain unauthorised privileges to the system. This could be attackers using phishing emails to exploit vulnerable code in installed software.

The threats for the HEMP provider are a combination of the indirect threats that the software platform provider faces and the external entities that have physical access to the HEMS. In the following, we classify the considered attacker, identify the assets of the HEMS and elicit a subset of vulnerabilities.

## *3.5.1. Assets of the HEMS*

**3.4. Data flow diagram of the home energy management platform**

214 Energy Management of Distributed Generation Systems

These are useful for expressing hardware‐related issues.

manager for the physical interaction with the HEMS.

**Figure 5.** DFD of the HEMS.

**3.5. Threat analysis**

information needed to complete a process and what information is stored.

The main purpose of DFDs is to identify the key *data flows* in the system. Modelling the data flows, contrary to the *control flows*, reveals how information is exchanged throughout the system. A DFD model explains who takes part in a process for delivering the information, the

**Figure 5** provides an overview of the internal data flows on a HEMS and the HEMS interactions with the external entities based on reference [14]. Besides the DFD symbols presented in **Table 1**, the DFD is annotated with dotted lines indicating the trust boundaries. These are quantified three trust levels from the HEMP provider's point of view. Furthermore, it contains dotted arrows between processes, to indicate how a process affects another process's runtime.

As seen in Figure 5, seven processes are included in the model. This includes two services: third‐party HEM service and a Meter Data Management (MDM) service. The MDM service is explicitly included to show the data flow of meter data and storage of the smart device configurations. The third‐party HEM service presents any high‐level service useful for smart grid operations. The service manager and software framework manager relate to the contin‐ uous maintenance of the software on the HEMS. Lastly, there is a system manager and device

A threat model is a depiction of a system's attack surface. An attack surface has numerous threats towards a set of assets within the system. The purpose of mitigation techniques is to Assets represent valuable targets for an attacker, and therefore naturally represent the system susceptibility for threats. In the following, the key assets are identified with a description of the reason for its inclusion:

**Services:** These represent both value‐added services for the residential consumer, but also account for the foundation of service market generation. A compromised service can lead to cyber attacks on homely property. Furthermore, it can also lead to violation of the intellectual property for the service provider, thus undermining a service market. The services are dependent on the software platform provider to secure the services, where it assumes the underlying software stack (e.g., virtual machine, Operating System (OS), etc.) will not be compromised. The services can contain a range of sensible information regarding the residen‐ tial consumer, for example, granular meter data, personal identifiable information, crypto‐ graphic key sets and so on.

**Service manager:** This process is responsible for presenting, installing, updating and unin‐ stalling services on the HEMS. It is in direct contact with the residential consumer and service market provider. An attack on the service market manager can lead to undermining the service ecosystem with services unable to be update if a critical software patch needs to be installed. It depends on the given privileges from the software platform. It contains the audit of installed services and cryptographic keys to allow for a secure connection to the smart market provider.

**System manager:** This manager administrates the OS stack including middleware software (JVM, Python interpreter), system libraries and kernel (network interface, memory manage‐ ment, I/O interface, etc.), and therefore performs privileged operations. The entire software framework stack depends on its implementation. Therefore, it is assumed that it is configured and maintained reliably.

## *3.5.2. Identifying vulnerabilities*

Vulnerabilities represent an attacker's entry points to the system. It is therefore crucial to identify these entry points in order to mitigate possible attacks. Here the vulnerabilities are presented using the STRIDE‐per‐interaction approach between the service and service manager. Other interactions identified in the DFD are omitted for brevity.

#### *3.5.2.1. Services/service manager*

**T1. Spoofing**: The HEMS contacts the service market provider for exploring, installing, updating the services on Smart Market provider. If the attacker is able to insert spoofed IP packets or DNS packets when the service manager sends requests to the original Service Market site, the service manager can be sent to a site with malicious services.

**T2. Tampering**: An attacker can inject code for replacing integrity check of installed services. This will lead to malicious services being installed, which were not verified by the *service market controller*.

**T3. Repudiation:** Someone9 rejects installation of a service in order to deny possible payment for energy bill.

**T4. Information disclosure**: An attacker is able to see the intellectual property of a service.

**T5. Denial of service:** If an attacker can block any communication with the service manager, the service manager cannot update installed services.

**T6. Elevation of privileges:** The HEMS supports third‐party services to be installed through the *service market provider*. If the *service market provider* is able to install a service that is able to access outside the boundary of its privileges, an attacker can access the meter data, smart device configurations.

#### *3.5.3. Attack trees*

Attack trees are useful for visualising the escalation of attacks (see **Figure 6**). The attack tree shows the root cause of an attack and what an attack subsequently after would allow an attacker to do. What would seem to be a minor attack on the system can propagate through the system, leaving assets exposed for an attacker.

In the following, the threats towards the process with the lowest trust boundary is focussed on for brevity; the "*Third‐party HEM service*" (where the MDM service is a special case). The threats **T1**, **T2**, **T4**, **T5** and **T6** can be collected from the root threat "*Install of malicious service*". The root of the attack tree is set to this threat. It is presented with the problematic state as root. Each edge in the attack tree is labelled with "{noticeable/likelihood}" measure, to indicate if the attack is believed to be noticeable and the likelihood of such an approach (**Figure 6**).

## **4. Mitigation strategies**

Often the time spend on judging the level of the risk should be compared to the time for addressing the threat. When addressing the threat, it is possible to mitigate the risk by redesigning of system architecture, implementing a mitigation feature or simply ignoring it. In the following, the chapter will review for hardware security and privacy mechanisms that mitigate the "*install of malicious service*" attack.

<sup>9</sup> The term "someone" instead of attacker is used deliberately, since it can represent the user of the system as well.

## **4.1. Security and privacy technologies**

*3.5.2.1. Services/service manager*

216 Energy Management of Distributed Generation Systems

**T3. Repudiation:** Someone9

the service manager cannot update installed services.

the system, leaving assets exposed for an attacker.

mitigate the "*install of malicious service*" attack.

*controller*.

for energy bill.

configurations.

*3.5.3. Attack trees*

**4. Mitigation strategies**

9

**T1. Spoofing**: The HEMS contacts the service market provider for exploring, installing, updating the services on Smart Market provider. If the attacker is able to insert spoofed IP packets or DNS packets when the service manager sends requests to the original Service

**T2. Tampering**: An attacker can inject code for replacing integrity check of installed services. This will lead to malicious services being installed, which were not verified by the *service market*

**T4. Information disclosure**: An attacker is able to see the intellectual property of a service. **T5. Denial of service:** If an attacker can block any communication with the service manager,

**T6. Elevation of privileges:** The HEMS supports third‐party services to be installed through the *service market provider*. If the *service market provider* is able to install a service that is able to access outside the boundary of its privileges, an attacker can access the meter data, smart device

Attack trees are useful for visualising the escalation of attacks (see **Figure 6**). The attack tree shows the root cause of an attack and what an attack subsequently after would allow an attacker to do. What would seem to be a minor attack on the system can propagate through

In the following, the threats towards the process with the lowest trust boundary is focussed on for brevity; the "*Third‐party HEM service*" (where the MDM service is a special case). The threats **T1**, **T2**, **T4**, **T5** and **T6** can be collected from the root threat "*Install of malicious service*". The root of the attack tree is set to this threat. It is presented with the problematic state as root. Each edge in the attack tree is labelled with "{noticeable/likelihood}" measure, to indicate if the attack is believed to be noticeable and the likelihood of such an approach (**Figure 6**).

Often the time spend on judging the level of the risk should be compared to the time for addressing the threat. When addressing the threat, it is possible to mitigate the risk by redesigning of system architecture, implementing a mitigation feature or simply ignoring it. In the following, the chapter will review for hardware security and privacy mechanisms that

The term "someone" instead of attacker is used deliberately, since it can represent the user of the system as well.

rejects installation of a service in order to deny possible payment

Market site, the service manager can be sent to a site with malicious services.

The process of developing a secure hardware platform has recently intensified. Previously, computer security primarily focussed on creating secure software architectures and protocols with the assumption that the lower‐layer applications (e.g., the OS) would be secure. However, flaws in an OS implementation can likely lead to additional vulnerability of the application on top of it. Therefore, researchers have proposed systems for running trusted code on an untrusted OS, but there exists still pitfalls, for example, Iago attacks [22]. In the following, the concept of a Trusted Execution Environment (TEE) will be reviewed as well as technologies that use this concept.

## *4.1.1. Trusted execution environments*

In its essence, a TEE is an environment that you can *choose* to rely upon to perform sensitive tasks. The goal of TEE is to provide an isolated execution environment, secure storage, remote attestation, secure provisioning and a trusted path [23]. In hardware, it usually defines a distinguished part of the hardware architecture which is encrypted and integrity protected. It isolates an area of the processor, memory and peripherals for performing privileged opera‐ tions. Next to the TEE, a Rich Execution Environment (REE) is considered outside the Trusted Computing Base (TCB), where both an untrusted OS and untrusted third‐party services can be executed. Despite its realisation in AMD Secure Execution Environment, ARM's TrustZone technology [24], and Intel's SafeGuard Extensions (SGX) [25], it is not widely used by service

**Figure 6.** Attacks based on threats towards "Third‐party HEM service".

developers. In the following, we will examine the hardware security technologies for mitigat‐ ing the identified risk in Section 3.4.

#### *4.1.1.1. ARM TrustZone technology*

The security extensions embedded in the specification of ARMv6 and later are called the TrustZone technology [24]. It provides two operational worlds: a *normal world* and *secure world*. This allows for different execution privileges for applications. For instance, an applica‐ tion responsible for handling confidential data can be executed in the secure world, without a normal application being aware about; even with vulnerabilities in the normal world's OS. The two worlds are executed through two virtual processors with hardware access controls to switch between the two worlds. The hardware access switch defines the active components in the hardware when switched. Traditionally, ARM TrustZone has primarily been used for Digital Rights Management (DRM) or banking applications, but are not restricted to those types of applications.

#### *4.1.1.2. Intel SGX*

Intel's SGX extension is a set of instructions and mechanisms for managing the memory access to the Intel Architecture processors [25]. The main principle relies upon the concept of a protected memory container, also referred to as an *enclave*. The enclave can be created through application code, where sensitive data are explicitly marked. When the application is executed, a sensitive part of the application's memory space is encapsulated within an enclave. This enclave ensures that the confidentially and integrity of that memory space are sustained even with the presence of privileged malware (i.e., super‐user capabilities). Furthermore, to ensure the integrity of the application inside the enclave, Intel SGX supports CPU‐based attestation and sealing. An audited process monitors the built process of the enclave and assesses the identity of the hardware from where the enclave should be executed. Before the application is executed of the CPU, the identity of the hardware is verified through the sealing identity. It contains a digital signature (known as report) of the enclave's initial state. The enclave is then capable of receiving a report of the state, verifying its correctness. To verify that the correct software has been instantiated on the platform to remote system, it can perform an attestation with the SGX‐supported processor (known as quote). This can prove to a remote system that application has been sent to a genuine SGX implementation. The reader is referred to [26] for a thorough description of the Intel SGX technology.

#### *4.1.1.3. TrustLite and TyTAN*

TrustLite [27] is a security architecture for resource constrained embedded systems that generally have to be cost effective in terms of development and production costs. The archi‐ tecture allows for software isolation with execution‐aware memory protection. The memory protection enforces a strict access control on memory by considering the program counter. Furthermore, it includes a secure exception engine that protects tasks from unauthorised exception handling. It has a secure loader that enables update of the security policy as well as prevents memory leakages after resetting the platform. However, TrustLite is static in terms of loading software components and their isolation, since this is required at boot time. TyTAN [28] leverages the TrustLite architecture for providing dynamically loading software compo‐ nents together with an integrated real‐time system.

## *4.1.1.4. Haven*

developers. In the following, we will examine the hardware security technologies for mitigat‐

The security extensions embedded in the specification of ARMv6 and later are called the TrustZone technology [24]. It provides two operational worlds: a *normal world* and *secure world*. This allows for different execution privileges for applications. For instance, an applica‐ tion responsible for handling confidential data can be executed in the secure world, without a normal application being aware about; even with vulnerabilities in the normal world's OS. The two worlds are executed through two virtual processors with hardware access controls to switch between the two worlds. The hardware access switch defines the active components in the hardware when switched. Traditionally, ARM TrustZone has primarily been used for Digital Rights Management (DRM) or banking applications, but are not restricted to those

Intel's SGX extension is a set of instructions and mechanisms for managing the memory access to the Intel Architecture processors [25]. The main principle relies upon the concept of a protected memory container, also referred to as an *enclave*. The enclave can be created through application code, where sensitive data are explicitly marked. When the application is executed, a sensitive part of the application's memory space is encapsulated within an enclave. This enclave ensures that the confidentially and integrity of that memory space are sustained even with the presence of privileged malware (i.e., super‐user capabilities). Furthermore, to ensure the integrity of the application inside the enclave, Intel SGX supports CPU‐based attestation and sealing. An audited process monitors the built process of the enclave and assesses the identity of the hardware from where the enclave should be executed. Before the application is executed of the CPU, the identity of the hardware is verified through the sealing identity. It contains a digital signature (known as report) of the enclave's initial state. The enclave is then capable of receiving a report of the state, verifying its correctness. To verify that the correct software has been instantiated on the platform to remote system, it can perform an attestation with the SGX‐supported processor (known as quote). This can prove to a remote system that application has been sent to a genuine SGX implementation. The reader is referred to [26] for

TrustLite [27] is a security architecture for resource constrained embedded systems that generally have to be cost effective in terms of development and production costs. The archi‐ tecture allows for software isolation with execution‐aware memory protection. The memory protection enforces a strict access control on memory by considering the program counter. Furthermore, it includes a secure exception engine that protects tasks from unauthorised exception handling. It has a secure loader that enables update of the security policy as well as prevents memory leakages after resetting the platform. However, TrustLite is static in terms

ing the identified risk in Section 3.4.

218 Energy Management of Distributed Generation Systems

*4.1.1.1. ARM TrustZone technology*

types of applications.

a thorough description of the Intel SGX technology.

*4.1.1.3. TrustLite and TyTAN*

*4.1.1.2. Intel SGX*

The objective of Haven security architecture [29] is to protect the confidentiality and integrity of a user's unmodified application in the cloud from an untrusted cloud provider. It is assumed that the processor is implemented correctly, but otherwise it is assumed that the adversary can access everything else, including memory and I/O devices. On software level, it is assumed that the adversary has full access to the entire software stack, including the OS, hypervisor, Basic Input/Output System (BIOS), device firmware and so on.

The inventors of Haven solve the confidentiality and integrity problem by using an *inverse sandboxing* technique also known as a *shielded execution*. Their solution is called Haven, and it leverages the Intel SGX and Microsoft's Drawbridge project [30]. Intel SGX allows application developers to protect their data from unauthorised access or modification by software that have highest privilege levels (e.g., a super‐user).

The deployment process of the Haven application is similar to the deployment of a regular cloud application, with the additional step of verifying that the process was correctly per‐ formed (the attestation from the Intel CPU). It is assumed that the cloud provider provides an Infrastructure as a Service (IaaS), that delivers the storage, hardware and networking compo‐ nents on a virtualisation platform (e.g., KVM, Xen, etc.).

## **4.2. Recommendations and conclusion**

Recommendations for a HEMP provider are given based on the vulnerabilities discovered from the threat model and the review of hardware security technologies based on TEE. Some of these recommendations reflect the challenges the security community and the hardware manufacturers are facing today, thus implementation details are still unexplored. Therefore, this chapter limits the thoroughness of recommendations to a problem description and possible approaches that need to be adapted for the HEMS. The problem description is linked to the identified requirements and threats, where the approaches are linked to the hardware technology review. The list of recommendations is as follows:

**• The HEMP should support isolation of services in terms of data and resources**: At the service layer envisioned for the HEMS, software frameworks for energy management already provide isolation of services (e.g., OSGi‐based software frameworks). However, as services become mission critical in relation to energy management, the computational resources must also be isolated. Furthermore, as services need different privileges for accessing data, the HEMS should provide a data isolation mechanism. An application isolation mechanism based on the TyTAN security architecture [28] could comply with such demands. Furthermore, it allows the use of real‐time‐dependent intelligent automation services and allows for securely installing additional communication drivers (see **R1, R2, R6, R7 R9, R10, R11**).


Constructing a HEMP, which is both secure and ensures the privacy of considered data assets, is challenging. But in order to do so, an important property for enforcing security is to *build it in* the system and not *onto* the system. This chapter contributes with a threat modelling of HEMS based on the requirement and design phases of the Microsoft Security Development Lifecycle. A domain model is constructed using UML, and the requirements are elicited from use cases for HEMS under research. A DFD models an abstract HEMS platform based on a combination of the architecture of OGEMA framework and reference architecture of a mobile platform [32]. Based on a threat analysis of the DFD, an attack tree is constructed with the focus on a malicious service attacker. Given the threats, mitigation strategies are reviewed for giving recommendations for HEMP manufacturers in the future smart grid.

## **Acknowledgements**

The research leading to these results has received funding from the EU Seventh Framework Programme (FP7/2007–2013) under grant agreement no. 317761 (SmartHG).

## **Author details**

Søren Aagaard Mikkelsen and Rune Hylsberg Jacobsen\*

\*Address all correspondence to: rhj@eng.au.dk

Department of Engineering, Aarhus University, Denmark

## **References**

services and allows for securely installing additional communication drivers (see **R1, R2,**

**• The HEMP could provide an inverse sandboxing mechanism, if the deployment of a service is sensitive for access or modification by highest privileged users:** Acting as a platform for intelligent automation services to be deployed on, the service provider might have contractual agreement with the residential consumer about their electricity consump‐ tion. For achieving this, the service providers must ensure the integrity and confidentially of the intelligent automation services. This can be achieved, for example, by using the inverse

sandboxing mechanism that the Haven [91] security architecture provides (see **R5**).

**• The HEMP should place the device authentication process and the update process in a trusted environments and vulnerable data in a secure data storage (e.g., containing private keys)** Authentication becomes a larger problem in the smart grid because of the necessity of self-organisation. A possible solution is presented in [31] which is based on TEE (see **R3,**

Constructing a HEMP, which is both secure and ensures the privacy of considered data assets, is challenging. But in order to do so, an important property for enforcing security is to *build it in* the system and not *onto* the system. This chapter contributes with a threat modelling of HEMS based on the requirement and design phases of the Microsoft Security Development Lifecycle. A domain model is constructed using UML, and the requirements are elicited from use cases for HEMS under research. A DFD models an abstract HEMS platform based on a combination of the architecture of OGEMA framework and reference architecture of a mobile platform [32]. Based on a threat analysis of the DFD, an attack tree is constructed with the focus on a malicious service attacker. Given the threats, mitigation strategies are reviewed for giving

The research leading to these results has received funding from the EU Seventh Framework

recommendations for HEMP manufacturers in the future smart grid.

Programme (FP7/2007–2013) under grant agreement no. 317761 (SmartHG).

Søren Aagaard Mikkelsen and Rune Hylsberg Jacobsen\*

Department of Engineering, Aarhus University, Denmark

\*Address all correspondence to: rhj@eng.au.dk

**R6, R7 R9, R10, R11**).

220 Energy Management of Distributed Generation Systems

**R4, R7, R8**).

**Acknowledgements**

**Author details**


[27] P. Koeberl, S. Schulz, A.–R. Sadeghi, and V. Varadharajan, "TrustLite: A Security Architecture for Tiny Embedded Devices," *Proc. Ninth Eur. Conf. Comput. Syst. – EuroSys '*14, vol. 0, pp. 1–14, 2014.

[14] S. A. Mikkelsen and R. H. Jacobsen, "Consumer‐Centric and Service‐Oriented Archi‐ tecture for the Envisioned Energy Internet," in *2015 Euromicro Conference on Digital*

[15] Microsoft – Developer Network, "Chapter 1: Security Fundamentals for Web Services." [Online]. Available from: https://msdn.microsoft.com/en‐us/library/ff648318.aspx

[16] E. S. K. Yu, "Towards Modelling and Reasoning Support for Early‐Phase Requirements Engineering," in *Proceedings of ISRE '97: 3rd IEEE International Symposium on Require‐*

[17] Home Gateway Initiative (HGI), "*Use Cases and Architecture for a Home Energy Manage‐*

[18] Energy@home, "*Use cases V 3.0*," 2015 [Online]. Available: http://tinyurl.com/hfctt9e

[19] U.S. National Institute of Standards and Technology, *Guidelines for smart grid cyberse‐*

[20] C. Greer, D. A. Wollman, D. E. Prochaska, P. A. Boynton, J. A. Mazer, C. T. Nguyen, G. J. FitzPatrick, T. L. Nelson, G. H. Koepke, A. R. Hefner Jr, V. Y. Pillitteri, T. L. Brewer, N. T. Golmie, D. H. Su, A. C. Eustis, D. G. Holmberg, and S. T. Bushby, "*NIST Framework and Roadmap for Smart Grid Interoperability Standards*, Release 3.0," Nist Spec. Publ., vol.

[21] M. Pichler, A. Veichtlbauer, and D. Engel, "*Evaluation of OSGi-based architectures for customer energy management systems*," 2015 IEEE Int. Conf. Ind. Technol., vol. 0, pp. 2455–

[22] S. Checkoway and H. Shacham, "Iago attacks," in *Proceedings of the eighteenth interna‐ tional conference on Architectural support for programming languages and operating systems*

[23] A. Vasudevan, E. Owusu, Z. Zhou, J. Newsome, and J. M. McCune, "Trustworthy Execution on Mobile Devices: What Security Properties Can My Mobile Platform Give Me?," *Lect. Notes Comput. Sci. (including Subser. Lect. Notes Artif. Intell. Lect. Notes*

[24] ARM Security Technology, "Building a Secure System using TrustZone Technology." [Online]. Available from: http://infocenter.arm.com/help/topic/com.arm.doc.prd29‐ genc‐009492c/PRD29‐GENC‐009492C\_trustzone\_security\_whitepaper.pdf [Accessed:

[25] Intel, *Software guard extensions programming reference*, 2013. [Online]. Available from: https://software.intel.com/sites/default/files/329298‐001.pdf [Accessed: 27‐Jan‐2016].

[26] V. Costan and S. Devadas, *Intel SGX explained*, 2016. [Online]. Available from: http://

*ment Service*", 2011 [Online].Available: http://tinyurl.com/hposzxd .

*System Design*, 2015, pp. 301–305.

*ments Engineering*, 1997, pp. 226–235.

*curity.* Gaithersburg, MD, 2014.

0, Gaithersburg, pp. 1–90, Oct. 2014

*‐ ASPLOS '13*, 2013, vol. 41, no. 1, p. 253.

*Bioinformatics)*, vol. 7344 LNCS, pp. 159–178, 2012.

2460, Mar. 2015.

28‐Jan‐2016].

ia.cr/2016/086.

[Accessed: 25‐Jan‐2016].

222 Energy Management of Distributed Generation Systems


**Economical Optimization of Operational Cost for Micro-Grids**
