A Prosumer-Oriented, Interoperable, Modular and Secure Smart Home Energy Management System Architecture

Abstract

As prices on renewable energy electricity generation and storage technologies decrease, previous standard home energy end-users are also becoming producers (prosumers). Together with the increase of Smart Home automation and the need to manage the energy-related interaction between home energy consumers and Smart Grid through different Demand Response approaches, home energy management becomes a complex and multi-faceted problem, calling for an extensible, interoperable and secure solution. This work proposes a modular architecture for building a Smart Home Energy Management System, integrable with existing Home Automation Systems, that considers the use of standard interfaces for data communication, the implementation of security measures for the integration of the different components, as well as the use of semantic web technologies to integrate knowledge and build on it. Our proposal is finally validated through implementation in one real smart home test-bed, evaluating the system from a functional standpoint to demonstrate its ability to support our goals.

1. Introduction

In the wake of increasingly present climate change effects, the scientific community proposes a “decarbonization” of our society, from transportation and industry to energy sectors. As society shifts from fossil fuel usage for transportation [1] and heating to electricity, our total electrical energy usage and dependence increases, imposing an excessive load on our already-ageing power distribution grid, leading to the development of different Demand Response (DR) strategies and mechanisms for the Smart Grid (SG). At the same time, electricity production is shifting towards renewable energy sources. These new energy sources, though, are not as controllable and predictable as traditional ones, in which production could be more easily matched to demand, increasing the need for effective DR.

Traditional demand-side management measures have taken the approach of reducing total energy consumption by increasing appliances’ energy efficiency and leveraging technology to reduce wastage. More recently, as more producer-consumers (Prosumers) join the grid; leveraging Distributed Energy Resources (DERs) both for local energy generation and storage [2,3] also come as interesting opportunities to help both: reduce global carbon emissions and make better use of the grid.

According to the International Energy Agency (IEA) [4], electricity wholesale prices in Spain, France, Germany and the United Kingdom, increased in 2021 from three to more than four times in respect to the 2016–2020 period. This steep increase in electricity prices, together with the cost reduction of renewable energy production technologies such as solar Photo-Voltaic (PV), as well as electrical energy accumulation through different battery technologies, have greatly promoted its application in residential installations, as a way to reduce the electricity bill.

In this present situation of increased electricity prices, reduced costs for the application of DERs in residential installation, the need for cooperation between energy consumers/prosumers and the grid and the variable nature of renewable energy production; new and innovative solutions are needed to deal with the complexity of our present and future energy system.

1.1. Smart Home Energy Management

The Internet of Things (IoT): the interconnection of everyday physical devices through Information and Communication Technology (ICT), presents itself as a great candidate to automate and manage the ever-increasing complexity of those places where us humans dwell, as well as helping to shape electricity demand, better match production and consumption and quickly react to variability, while reducing the electricity bill and keeping within user-defined comfort parameters (Figure 1).

Many advances have come forth in the last years regarding the Smart Home (SH). More specifically, in the field of home automation, where a plethora of devices and appliances are available: smart bulbs, refrigerators, washing machines, tumble dryers, electric vehicles (and chargers), Home Ventilation and Air Conditioning (HVAC) and the likes. Several different technologies have coalesced and started to settle among the general public, designed to integrate many of those devices under a single point of control: the Smart Hubs. Among the most known commercial cloud-based solutions for Smart Hubs are those from Google, Amazon and Apple; however, there is also a growing community of Do It Yourself (DIY) enthusiasts, that have opted for open and often self-hosted solutions such as Home Assistant [5], Domoticz [6] and OpenHab [7] to name but a few. These open solutions come as great frameworks for the rapid development of new ideas beyond home automation, allowing us to leverage already existing integrations of different devices and platforms.

The present picture of a modern prosumer-oriented SH is thus a complex ecosystem in which energy management has to comply with a broad range of concerns (Figure 2). The interaction with external agents, like the SG, Smart Hubs and other external services, places high interoperability expectations both in data modelling and communication interfaces, as well as in the privacy concerns of the home inhabitants [8,9].

To this end, new and innovative solutions must be brought forth, such as the use of semantic web technologies to bridge the gap among the many different services and domains of home energy management, standard interfaces to facilitate communications with other agents and security mechanisms to facilitate setting boundaries to information access.

1.2. Contribution of This Paper

This work proposes a Smart Home Energy Management Systems (SHEMSs) [10,11,12] architecture design capable of integrating the many different facets of energy management of a modern home, in an interoperable, standard-based and secure way so that consumers/prosumers and grid are benefited. To that end, we have leveraged the use of semantic technologies for their potential to store and extract knowledge from heterogeneous sources, providing a formal common ground [13] as well as existing ontologies that capture the represented concepts. Additionally, to be able to offer a solution that stands to be integrated by different vendors and parties, we propose the use of standard-based secure technologies for information exchange.

The rest of this document is structured as follows: in Section 2, we reflect on the previously existing work on this topic. In Section 3, we propose a secure architecture for modular SHEMS, integrable with existing Home Automation Systems (HASs), which is later showcased by implementation in a real scenario in Section 4. Finally, we discuss the results obtained in Section 5, providing conclusions and possible future lines of work in Section 6.

2. State of the Art and Related Work

There is a broad and extensive bibliography related to the work on Home Energy Management Systems (HEMSs) architecture and strategies, semantic representation of SH and HEMS concepts, DR strategies from within the SH and interfacing with the SG. In this section, we will briefly cover some of the most relevant works from our proposal perspective, sorted in reverse chronological order and categorised into two families: existing architectures and ontological work related to the interoperability of the solution.

2.1. Architecture and Security

Machorro-Cano et al. present HEMS-IoT [14]; a machine learning-based HEMS for energy saving, ensuring comfort and security while reducing energy consumption. The proposed architecture consists of seven layers, from presentation to device, in which information security is considered between presentation, IoT services and management layers, contemplating both authentication and authorisation. It does not mention DR or DER management as part of the proposed HEMS, nor explores the possibility of its integration with existing HAS, although its management layer does apply a semantic approach to home management, utilising a self-developed ontology to represent the main domotic concepts. Overall it presents a monolithic structure that goes from device to presentation, where interoperability has not been approached.

Elshaafi et al. [15] explore an approach to decentralised automated DR and home energy management. The proposed architecture is implemented using a multi-agent system with three different levels: home, aggregator and distribution system operator (being the latter two SG-related). At the home level, they define only two agents: the device agent and the HEMS agent. Their combined objective is to reduce the energy bill while respecting user preferences and comfort. While device agents encapsulate the communications with the home devices, the HEMS agent is responsible for the grunt of the work: planning, optimising and communicating with SG agents. This architecture does not consider the existence of a previous HAS. The final solution is presented in the form of a home gateway device that will directly interact with smart devices, although it does consider DER management through the different device agents. It addresses interoperability by proposing the usage of standard communication interfaces (OSGi: Open Services Gateway initiative [16]) and REST interfaces) and the use of Web Ontology Language (OWL) for information modelling. Finally, the proposed architecture takes into consideration the privacy and security of home users by using XACML (eXtendible Access Control Markup Language [17]) as an attribute-based access control platform, controlling the visibility of home devices to the HEMS agent.

The MAS2TERING project [18] defines a multi-agent system consisting of the following agents: Distribution system operator agent, Aggregator agent, Central home energy management agent, Microgeneration agent, Appliance agent and Battery agent whose interactions aim at delivering demand-side management through the supply chain, from generation to consumer appliances. This architecture does not cover security aspects, nor the integration with existing HASs or home energy management.

Zhang et al. propose iHEMS [19], a publish-subscribe communications infrastructure, using Information-Centric Networking (specifically Content Centric Networking) as the communication backbone. It does not rely on securing the communication channels but on encrypting the data itself, using a secure-group communications scheme above the pub-sub layer. The architecture itself contemplates the different devices interconnected through the Information Centric Networking-based pub-sub substrate, as well as a Directory Service, which devices use to publicise their data and a Group Controller in charge of key management for encryption/decryption.

Digital Environment Home Energy Management System (DEHEMS) project [20] proposes a service-based architecture, consisting of a remote server where the knowledge base is deployed, which in turn is fed from a Data Collector located in the home, to which sensors, devices, appliances and display devices are connected using wireless interfaces.

Rosello-Busquet et al. [21] propose a home gateway for a HEMS system, to control the devices in a home network at the service level. Built over the OSGi framework, it uses DogOnt ontology as the base for its knowledge base data repository. The architecture is composed of six bundles: Knowledge Base, Interface, Network n, Networks Manager, Manager and Network Emulator.

ThinkHome by Reinisch et al. [22] describes a multi-agent system architecture with two main premises: ensuring energy efficiency at home and comfort optimisation. The control strategies realised by the multi-agent system are split into problem aspects which are directly mapped to the different agents of the framework: Control, Users, Global Goals, Context Inference, Auxiliary Data, Knowledge Base Interface and Building Automation System Interface.

After the bibliographical review performed in architecture and security, we can conclude that none of the reviewed works considers all the previously described concerns of a modern prosumer-oriented SH in their architecture. None addresses data model and communications interoperability simultaneously to enable successful interaction with other service providers, such as external device platforms, Smart Hubs and the SG. Finally, security was covered by some works, but mostly in the communications domain, not placing the focus on data privacy, which represents a major concern in the complex SH ecosystem.

2.2. Ontological Background

To model the information in SHEMSs, a wide range of topics had to be covered, which resulted in an extensive survey of the different existing related ontologies. The topics or areas covered include grid DR management, home DR management, DER management, energy metering and performance assessment, energy saving advice, (home) infrastructure, user preferences, weather and environmental and sensor data: to name but a few. It is needless to say that no single ontology covers all of the required areas and that they all differ in the level of detail with which the different concepts are captured.

To summarise the ontological state of the art,

Table 1. Ontology summary.

Ontology	Application Field
OSEIM [23,24]	Semantic reasoning for intelligent energy management.
SARGON [25]	Smart grid and building energy automation.
DABGEO * [26]	Integration of smart home energy-related ontologies.
EnergyUse [27]	Home energy saving advice.
MAS2TERING [18]	Supporting USEF implementation on smart grid.
SAREF4EE [28,29]	Interoperability of smart appliances.
DNAS [30]	Energy efficiency through occupant behaviour.
ProSGv3 [31]	Modelling prosumer-oriented smart grid.
MIRABEL [32]	Flexibility description for demand response.
BonSAI [33]	Modelling of service-oriented smart building.
ThinkHome [22,34]	Home energy assessment and device control.

* Grayed rows are imported in DABGEO.

categorises the most relevant surveyed works according to our specific use case. Later, in Section 3.4, the mapping of those ontologies to specific elements in our proposal will be presented.

Smart Energy Domain Ontology (SARGON) [25] extends SAREF (Smart Applications REFerence [35]) but, unlike SAREF4EE, focuses on the control and monitoring of distribution electrical grids, integrating it with building energy automation.

OSEIM and NewOSEIM [23,24] leverage semantic reasoning over an ontology presenting knowledge about the internal and external environment of a home, to achieve intelligent energy management.

DABGEO [26] is an ontology semantically equivalent to OEMA [36], a previous ontology by the same authors. It improves on the former by offering a modular ontology that can be imported into subsets, facilitating its adoption in custom use-case scenarios. As its predecessor, it links and extends concepts from other previous ontologies. The base of the ontology network is ThinkHome, to which SAREF4EE, EnergyUse and ProSGV3 have been added.

EnergyUse framework [27] for home energy-saving advice applications, enriches PowerONT [37] (the power consumption ontology) with other ontologies and maps it to JSON-LD.

MAS2TERING ontology [18,38], developed under the homonymous project, implements USEF (Universal Smart Energy Framework [39]) through multi-agent systems. The purpose of the ontology is the representation of the data of different SG domains and to provide interoperability between SG agents and stakeholders. It is based in Energy@Home [40] and CIM (International Electrotechnical Commission’s Common Information Model [41]).

The DNAS framework presents an ontology [30] to represent energy-related occupant behaviour to understand total energy consumption in buildings.

The MIRABEL [32,42] ontology for modelling flexibility in SG energy management, allows actors to express their energy flexibility for a specific device. It also represents energy profiles for devices, as well as production and storage devices.

BOnSAI [33,43] presents an ontology for incorporating Ambient Intelligence in Smart Buildings that can be used for energy management and monitoring. Includes concepts about functionality, QoS, hardware, users and context.

3. Proposal

The general or conceptual architecture of our proposal (Figure 3) is composed of multiple Energy Management Components (EMCs) responsible for a specific domain within home energy management, which interact with each other to pursue their goals, cooperating toward a common objective of increasing energy efficiency and reducing energy costs of the home.

3.1. Energy Management Components

The following list describes the different EMCs that govern home energy management, as well as some of the relationships between them:

• Home Automation System (HAS): in charge of communication back and forth with the Home Automation System, keeps it updated regarding energy budgets, production and accumulation status and current consumption. High-level information produced by other components, can be used by the HAS to provide home occupants with energy-related decision support tools and notifications. It also updates the KB with information from the HAS, such as devices inventory, appliance status and scheduling, presence and occupancy information as well as information coming from external sources, such as real-time weather information and forecasts. This information can be used to build and feed different DER and energy consumption forecast models and allow the HEMS to plan and adapt to changing conditions.
• Distributed Energy Resource (DER): is responsible for dealing with energy resources, both for energy production and accumulation. Its purpose is to: (a) to produce high-level information, such as production and storage forecasts needed by the Home Energy Controller (HEC) component (5) and (b) to operate the different DERs safely, trying to minimise energy costs for the home and (c) cooperating with HEC for DR strategies implementation.
• Home Energy Gateway (HEG): updates the status of the grid-tie, whether we are injecting or consuming power from the grid, as well as pricing information and contractual parameters (e.g., maximum usable power). It can also relay energy information back to the utility company, such as energy usage schedules and forecasts, appliance inventory and usage patterns and, in general, any information that the homeowner is willing to share that can help the utility company to offer a better deal to the client. It is also responsible for communicating DR strategies, such as flexibilities or acting as a relay for Packetized Energy Management (PEM) brokering with the grid (or micro-grids) and keeping track of total grid energy costs.
• Device: represents devices whose energy management can be dealt with directly by the HEC component (5). Examples of such devices would be big consumers, continuously-running appliances like HVAC or heating systems, swimming pool pumps, water heaters and electric vehicles, whose energy consumption schedule can impact to a great extent on home energy management and usually can be re-scheduled or curtailed under certain conditions with minimal to no impact for the home occupants. Usually, these devices will be the most critical ones in DR strategies such as flexibility management.
• Home Energy Controller (HEC): in charge of control and optimisation. It can make use of different strategies and techniques, from semantic reasoning to the use of traditional optimisation methods or artificial intelligence. Its purpose is to deal with and mediate between components, ensuring that the energy budget is optimised and providing useful high-level information to be shared with others, such as HAS (1) and HEG (3).

It is worth mentioning at this point that EMCs are not single or individual instances. Different device components could be designed for a washing machine and an electric vehicle charger. Conversely, components do not have to be implemented in a single final unit; for example the HEC could be split into different software modules in charge of energy brokering, total energy consumption forecasting and deciding different strategies for DR.

3.2. Knowledge Base

As depicted in Figure 3, we propose an architecture centred around the KB. Components are capable of realising their goals as well as interacting and cooperating by using the Knowledge Base (KB), where all the information of the system is stored.

The information stored in the KB includes meta-information regarding different aspects, such as data typing and ontological links to the represented concepts. This “enriched” information is called context in our system.

The structure and semantic roots of context in our proposal and the mechanisms to interact with it, are further described in Section 3.5. The components responsible for its management are first described in Section 3.3. Finally, the KB is also used as a means for coordination and orchestration among EMCs in the system, leveraging its publish/subscribe nature and flexible data model. This is further described in Section 3.7.

3.3. Functional Architecture

The functional architecture of our proposed HEMS consists of three layers (Figure 4) and a transversal security layer, in which the different components are structured as follows:

• Control Layer: this is the core of the management system, where all the modules related to the HEC component coexist. This layer is responsible for the strategy and the scheduling. It will try to realise the global system objectives by working with the information provided by the remaining components. To both: accrue data from the Interaction Layer (3) and send back directives regarding scheduling and any operational parameters, any modules in this layer will use the Context Broker component, placed in the Context Management Layer (2). The orchestration of the system, by which the rest of the EMCs are controlled, is further described in Section 3.7.
• Context Management Layer: this layer acts as the information backbone of the system, providing several mechanisms and characteristics that enable the interoperability and modularity of the system. The main feature of this layer is that it is based on the European Telecommunications Standards Institute (ETSI) NGSI-LD (Next Generation Service Interfaces for Linked Data) [44] standard: evolution of NGSI, both of them used as the communications standard of the FIWARE [45] project. The CB is the component responsible for making all the information (context) of the KB accessible, as well as the provider of means to search, access and update that context. Its specific characteristics and details regarding the communication between components, the ontological foundation and the structure of the information model are described. This layer also holds the historic component, responsible for storing selected historical information (used for forecasting and data analysis) and making it available to EMCs. Both the CB and the historic component can be instantiated from the many already available implementations of FIWARE Generic Enablers, promoting re-usability.
• Interaction Layer: this layer comprises all the components responsible for interacting with the devices and entities related to the HEMS. It is the boundary layer of the SHEMS with the rest of the SH and the world, acting as an adaptor between the internal NGSI-LD interfaces and the different external interfaces. It is through this layer that information from devices, the grid, DERs and the HAS, reach the KB. It is also in this layer that the management of the system crystallises in specific commands sent to devices or communications with external services. Finally, all semantic adaptation between the SHEMS and the devices, services and external agents will take place in this layer.
• Security & Privacy: lastly this layer permeates the whole system. It is responsible for ensuring secure data access as well as privacy. It mediates the information exchange between the components and the KB, providing authentication and authorisation components for access control to the CB and other components in the architecture. The components that form the security and privacy layer and their operation are further described in Section 3.6.

3.4. Information Model

Semantic web technologies present a compelling solution to provide interoperability across vendors and providers of different services, platforms and devices. Under the semantic web, information has to be semantically annotated (linked) to ontological concepts. Information enriched with semantic tags is called context in NGSI-LD, the underlying technology on which the KB of this proposal is based.

According to NGSI-LD Information Model [44], context is structured in the form of entities. These entities have identity, type, properties and can be linked to one another through relationships. Entities are exchanged in the form of JSON-LD documents that follow a Core MetaModel. Bundled with those properties and relations, NGSI-LD introduces the use of special JSON-LD attributes (represented by the Cross-Domain Ontology) linking to semantic concepts from other Domain-Specific Ontologies, creating an “onion” model (Figure 5).

A wide range of existing ontologies are already available for us to use in our proposal, closely related to the domain of SHEMSs and covering DR and SG interfacing; the most relevant ones have already been introduced in Section 2.2 and summarised in Table 1.

In our proposal, we have selected DABGEO as the main ontology, as it covers all of the most relevant concepts related to home energy management: appliances and devices description and power consumption, grid-related information (from tariffs to prosumer-related concepts), electrical energy generation and accumulation, as well as user related information (user preferences, occupancy and other related concepts). Specific examples of the mapping of DABGEO concepts to NGSI-LD will be provided in Section 4.3.

As already indicated, no ontology covers all possible aspects and scenarios in the domain of SHEMSs.

Table 2. Complementary ontologies.

Ontology	HEC	HEG	HAS
DNAS [30]	X		X
BonSAI [33]	X	X	X
MIRABEL [32]		X
MAS2TERING [18]		X
SARGON [25]		X
OSEIM [23,24]	X		X

represents the subset of ontologies that can complement DABGEO in our proposal and the EMCs for whom they can be relevant (e.g., MAS2TERING could be applied in the HEG in DR scenarios where USEF is being implemented).

Finally, to the best of our knowledge, no previous mapping from NGSI-LD to the selected ontology has been previously proposed. The approach we have followed in this work has been to map OWL elements of DABGEO to NGSI-LD according to

Table 3. OWL and NGSI-LD mapping.

OWL	NGSI-LD
Individual	Entity
Class	Entity type
Object property	Relationship or nested property
Datatype property	Property

. In the case of OWL’s object properties linking to individuals, the representation as NGSI-LD nested properties can be considered if the following criteria are met: (1) linked individuals are exclusively related to a single entity, (2) their existence depends on it, (3) have low number of properties and/or relationships and (4) will not be used as search keys in the KB.

3.5. Context Management

In NGSI-LD, context (entities) can be created, updated, retrieved and deleted through REST API exchanging JSON-LD (JSON for Linking Data [46]) documents. This API also provides mechanisms to subscribe to changes in context, forming a publish/subscribe information management system. The CB is the single central point of the architecture where all information can be accessed.

The CB offers advanced mechanisms to search context information available in the system, offering different filters and query mechanisms to retrieve information. Some of those filters can also be used with the subscription mechanism, allowing components to receive updates on tailored sets of information of their interest.

Finally, the CB can also act as a relay and directory for other providers of information previously registered: in this way, EMCs can act as Context Providers (CPs), responsible for sub-sets of the KB, capable of answering queries from the CB and other peer components (Figure 6). This mechanism is relevant in cases where information is calculated upon request or cases where information changes constantly but is requested with low frequency.

3.6. Security and Privacy

To provide secure and private access to context information, our proposal introduces the use of DCapBAC (Distributed Capability-Based Access Control) [47], a derivation of the Attribute-Based Access Control (ABAC) scheme in which the authorisation checking against the policy base and the enforcement of the actual policy are decoupled (Figure 7).

In the following list, the security components of the architecture are described:

• Identity Management (IdM) component: provides the authentication service to the architecture. It stores identity information together with attributes that will be later used by the authorisation component. In our architecture, we propose the use of standard interfaces, such as OAuth 2 [48] and OpenID Connect [49].
• Capability Manager (CM) component: acts as the authorisation facade for components, granting or denying access to the requested resource. It receives requests from components and interacts with the IdM and the PDP to perform its task.
• Policy Decision Point (PDP) component: validates requests using identity information against the set of XACML (eXtendible Access Control Markup Language [17]) policies stored in the system. Those policies are managed via the next component in the list: the PAP.
• Policy Administration Point (PAP) component: offers a single administration point to manage the policies for the system. Policies are stored in XACML, defined as conditions that a subject must meet to act on a resource. In this case, the conditions can be based on attributes from the IdM identity, the actions are HTTP verbs and the resources are HTTP resources, represented as URLs.
• Policy Enforcement Point (PEP) component: act as a transparent reverse HTTPS proxy, which enforces the verdict issued by the PDP, without the need for further XACML policy evaluation.

The process by which EMCs access information begins with the authentication process (Figure 8) represents a simplified version of a typical OpenID interaction for authentication of an EMC against the IdM. As a result of this interaction, the component obtains an Identity Token (IdT) which will be used in the next phase.

Authorisation in DCapBAC begins with a request to get access to a resource, accompanied by the IdT previously obtained. This request follows the classical XACML structure and interface (Figure 9), in which the EMC’s request is matched in the PDP against XACML policies to verify whether the request can be granted or not. The difference is that instead of immediately accessing the resource after a positive verdict, this interaction will result in the issuing of a Capability Token (CT).

The final phase (Figure 10), is the actual access to the context information. In this case, the CB is protected by a transparent PEP. This component will only grant requests that are valid according to the attached CT. Access can take place several times with the same CT for as long as it is valid, effectively reducing the authorisation delay of each request, as there is no further validation against XACML policies on each access.

Communications between EMCs, security components and CB take place via REST API calls and are secured with standard web technologies, using HTTPS protocol and SSL certificates.

3.7. System Orchestration

EMCs not only share information through the KB but also communicate with each other in an asynchronous message-passing manner, using the publish/subscribe functionality defined in NGSI-LD. We have implemented a mechanism inspired by FogFlow [50,51] task orchestration, in which tasks receive input from other tasks and the orchestrator by using intermediary entities in the KB. Those entities hold input/output information for their tasks.

In our proposal, EMCs subscribe to specific entities by which the HEC sends and updates the desired outcome, schedule or management commands that the EMC requires as input for its operation (Figure 11). That same mechanism is used by the HEC to receive output from the rest of the EMCs.

This orchestration mechanism is also secured with the proposed security and privacy components, covered in Section 3.6. This way, XACML policies can be put in place to ensure that only the expected EMC will be able to access its input message entities and update its output ones.

4. Validation

To validate our proposed architecture, an implementation use case is being conducted for the SHEMS of a single home. This home has an already existing HAS installation, electricity production and storage facilities and some high-consumption devices.

Regarding the specific algorithms and methods used in the EMCs implemented, we have purposely omitted implementation details. The two main reasons behind this decision are: (a) the implementation of some of the EMCs is still under development, being bound to change in the near future as new approaches and algorithms are being tested and (b) this proposal’s concern is the architecture by which different implementations of the EMCs can cooperate in an interoperable and secure way thus fully describing the algorithms and optimisations would only lead to possible confusion by the reader and an over-extended work.

Never the less, in this section we will offer some implementation details regarding EMCs, as well as specific results that support our goal of improving energy efficiency in our test-bed scenario, together with the specific objectives that guide our SHEMS and the core architecture components selected for our demo, as well as examples of communication between EMCs.

4.1. Test-Bed Description

The test-bed (

Table 4. Test-bed summary.

Element	Description
Home automation system	Home Assistant, running in a Raspberry Pi 4, 4 GB RAM
Photo voltaic array	14 panels, 480 W rated
Inverter	Ingecon Sun Storage 1Play
Battery	32 cells in series, LiFePo4 chemistry, 280 Ah rated capacity
Battery management system	Batrium WatchMon-CORE, 2 Batrium CellMate K9 and ShuntMon 500 A
Grid power meter	Carlo Gavazzi EM112
Grid tariff	5.4 KW peak input, with constant pricing. PV surplus feed-in possible with constant price rebate
Appliance controller * (Coffee machine)	TP-Link HS110 Smart Plug (with inbuilt power meter), controlled by Home Assistant
Pool controller	Node-RED based, running in a Raspberry Pi zero. Power-meter integrated via Modbus.

* An espresso machine (ECM Synchronika), with 1.6 kW peak power consumption is connected to this smart plug.

) consists of a two-story house at ground level, located in Murcia, in the south-east of Spain, with a patio and an underground garage. A small swimming pool is located on the patio, whose filtration and chlorination systems can be controlled by the SHEMS.

The existing HAS is based on the Home Assistant software (Figure 12), running on a Raspberry Pi 4 and is already capable of controlling HVAC, central heating (underfloor heating), window blinds and some lights, smart TVs and the tumble-dryer among other appliances. Different sensors are integrated into the HAS, monitoring temperature and humidity in different rooms. It also provides weather information via external web services, as well as home occupancy status through presence detection of different inhabitants at home.

On the roof, an array of PV panels (Figure 13), connected to an inverter, provides up to 6 kW of electric power. An accumulation system is currently in development, with 28 kWh of planned storage capacity, protected by a Battery Management System (BMS) and directly controlled by the inverter.

The PV and storage systems provide real-time information on production, consumption and State Of Charge (SOC) through their controllers. Moreover, some high-consumption appliances have dedicated power meters for a more granular energy consumption composition breakdown; such is the case of the pool filtration system and the espresso machine.

Finally, a grid tie provides energy. The contract with the electricity company establishes a constant price tariff with 5.4 kW peak power. It also allows grid feed-in from the PV installation, with a rebate proportional to the injected energy. To monitor import/export energy, a grid-tie power meter has also been installed and integrated.

4.2. Tasks

The general objective of the test-bed SHEMS is to achieve the most efficient and cost-effective operation of the system and to do so it takes the following tasks:

• To manage battery accumulation parameters (maximum SOC and Depth Of Discharge (DOD), charging and discharging regimes and the likes), schedule and manage battery charging and manage stored energy usage.
• To schedule and manage the central heating system, as well as HVAC.
• To schedule and manage swimming pool filtration and chlorination system.
• To react to inhabitants’ actions that offset the expected energy profiles.
• To inform the user about energy consumption patterns and energy management status, raise alerts and provide energy-related suggestions to improve efficiency and reduce consumption.

To fulfil its tasks, the SHEMS will use and generate information from its different EMCs, such as grid-tie parameters (maximum usable power, current and planned energy pricing and grid inject rebate depending on tariff), current and forecast energy consumption, production and storage, schedules of operation of different devices and even occupancy and weather information.

4.3. Knowledge Base and Security Components

For the KB and security components, we have selected some Generic Enablers from the FIWARE project: the CB implementation of choice is the Orion-LD [52] broker and on the IdM, Keyrock Identity Management Generic Enabler is being used. For the DCapBAC components, we have selected the open-source implementation of the PAP-PDP, PEP and CM provided by IoTCrawler project [53,54].

Information in the KB is structured in entities (Listing 1), according to NGSI-LD’s Core MetaModel, and linked to DABGEO [26] ontology (Figure 14).

Listing 1. JSON-LD representation of the photo-voltaic inverter.

Orchestration is performed via asynchronous message passing and requires the subscription of the EMCs to the input entities of their domain. One such example is the control of the swimming pool filtration and chlorination system (Listing 2). In case of exceeding the power constraints of the system (e.g., if the energy imported from the grid is close to, or exceeding, the maximum power defined by the energy provider contract), the HEC will issue a modification to the entity representing the controllerDesiredStatus of the filtration and chlorination system, asking the device controller to stop the system as a result of energy constraints. That modification will trigger the appropriate subscription to send a notification to the swimming pool device EMC (Listing 3) and it will stop operation until the HEC clears that status.

Listing 2. Subscription in NGSI-LD.

Listing 3. Notification in NGSI-LD.

Security in the system begins with the definition of different identities for the different EMCs, that will be used to interact with the DCapBAC authorisation components. A set of XACML policies is set in place, governing which EMC can act over the different entities stored in the KB. In NGSI-LD, the different HTTP verbs are mapped to the create, retrieve, update and delete functionalities, offering good granularity on the different actions that can be taken on entities. The entities affected by the policy can be defined in terms of identifier (literal or pattern) and different query filters based on entity type or other properties.

When an EMC wants to interact with information in the KB, it first needs to authenticate with the IdM, obtaining an IdT (Figure 15). It then obtains a CT from the CM for the action to be performed and the information associated in the KB. Finally, it will perform that interaction against the PEP, attaching the CT in the request, which will grant (or deny) its access. The security process is explained in detail in Section 2.1.

The added benefit of DCapBAC is that further requests will not need to perform the authentication and authorisation phases again and that the access control performed by the PEP doesn’t need to interact with the PDP, thus reducing the latency of the enforcement.

4.4. Energy Management Components

The EMCs of our test-bed (Figure 16) are at different development stages. We have used Node-RED [55] as the development tool of choice for its quick turnaround and simplicity. The enumeration that follows this text summarises the details and implementation status of each of the components:

• HAS: it communicates with the Home Assistant instance of the test-bed. It draws information from it regarding weather forecasts, sensor data and home occupation and updates it on the KB for other EMCs to use. It also receives messages from the HEC, to notify users about different conditions. The interaction between the HAS component and Home Assistant takes place via REST API, leveraging Home Assistant’s user notification mechanisms (Figure 17).
• HVAC and Heating devices: these devices were already integrated into Home Assistant, utilising custom ESP8266 devices and the ESPHome [56] integration in Home Assistant. These devices offer another REST API to interact with, which we have leveraged due to its simplicity and to avoid using Home Assistant as an intermediary to interact with them. Currently, their components only send status updates to the KB and support stopping temporarily the operation upon request from the HEC (via the orchestration mechanism) to avoid overloading the grid input. In the future, operation scheduling for the heating system could be implemented and integrated into the energy management strategy, as well as operation forecasting for the HVAC to predict when users want to use it.
• Espresso machine device: this device is controlled via a smart plug (see Table 4), allowing users to remotely turn the machine on or off. This device is (also) integrated into Home Assistant [57]. This time we have opted to implement its component interacting with Home Assistant’s REST API, instead of interacting directly with the smart plug. The reason behind this decision is merely to save effort by re-using Home Assistant’s API. In the current implementation, it only updates real-time energy consumption and status (on/off) in the KB, but in the future, we expect to be able to better integrate it into the SHEMS by implementing other features such as operation forecasting and scheduling.
• Pool device: the pool filtration EMC has been directly built into its controller (which is also based on Node-RED). It updates operation status and real-time power consumption in the KB. It also requests an operation schedule to the HEC for the number of hours of filtration that it deems appropriate, based on weather forecasts retrieved from the KB (which are updated by the HAS component). This component also reacts to HEC’s inputs (through orchestration mechanism) to temporarily stop/resume operation.
• PV and battery DER: the component responsible for the PV array and battery interacts with the inverter via Modbus-TCP (Figure 18). The current implementation of the controller updates in the KB, real-time production and SOC of the batteries. Once the battery is finally installed, we plan on developing the mechanism to receive from the HEC messages to update its maximum SOC and DOD to optimise battery usage.
• HEG: this component updates in the KB the real-time power input/output as measured in the grid tie power meter, to which it is connected via Modbus. It also updates the maximum power that the grid-tie can deliver as well as the maximum it can be fed from the PV installation. This component also retrieves the hourly prices of electricity, both consumed from the grid and fed-in, from ESIOS [58] via REST API, according to the Spanish PVPC tariff, although the current test-bed electricity contract is a constant-price one.
• HEC: the current implementation of this component is capable of generating schedules for electricity consumption upon request, trying to maximise PV-generated electricity usage. It currently does so by using forecast cloud coverage information (coming from the HAS component) as well as expected sunset and sundown times. It also reacts to notifications regarding high-consumption devices and takes decisions based on the current energy budget (PV, battery and grid) to signal viable devices to temporarily stop operation. Finally, it also notifies users through the HAS component (Figure 17) when: (a) the grid energy import reaches 80%, (b) when high-consumption devices are active and the home is not occupied and (c) when contingency mechanisms (such as temporarily stopping operation of a device) have been implemented.

4.5. Results

Among the various sub-systems of the test bed, we have decided to show results obtained in the filtration and electrolysis chlorination system of the pool, as they present a good balance between simplicity, interaction with other EMCs and improvement in energy cost reduction.

Prior to the SHEMS implementation, this sub-system was controlled with an electric plug-in timer switch. Its programming had to be manually configured several times a year, to adapt to the differences in temperature as well as sun incidence. Figure 19 shows the peak power demand and production, on an hourly basis, for an average spring/summer work day.

From it, we can deduce the pool filtration and chlorination system schedule, in which we can notice two gaps (6 a.m. to 9 a.m. and 2 p.m. to 5 p.m.). Those gaps correspond to specific periods of the day in which users are specially energy-active at home on a common replacedweek dayweek day: the time of breakfast and lunch. At those times, users utilise high consumption devices such as the espresso machine, the electric stove or the microwave, that have shown in the past the possibility of triggering the grid input power breaker when used in conjunction with the pool filtration system. Thus a conservative approach was taken, avoiding those time ranges. It is worth noticing that, although the second gap coincides with a high PV production period, cloud coverage has occasionally produced dips in production, leading to power breaker trips.

Figure 20 represents the same variables of the previous example and similar conditions (average spring/summer work day in our test-bed home), but this time the pool has a device controller integrated into the SHEMS. The implementation of the pool’s EMC decides filtration and chlorination time based on local weather information and forecasts (updated in the KB by the HAS module) and asks for a schedule from the HEC, which provides it based on energy cost, resulting in an allocation during PV production.

This schedule would have incurred an increased risk of power breaker trips in the previous scenario, but the SHEMS-integrated pool controller receives commands from the HEC to temporarily stop operation when there is the risk of exceeding maximum grid power constraints, therefore, avoiding the need to schedule out of PV production hours. The HEC sends control commands to the pool filtration system to stop/resume operation, based on the power status of the whole system, as described in the previous Section 4.4. The orchestration of the control commands has also been showcased in Section 4.3 and the messages exchanged in Listing 2 and Listing 3.

Finally, Figure 21 compares the total accumulated energy imported from the grid on an hourly basis for the two previous examples, showing that the conservative strategy followed by the timer implementation could be associated with less efficient use of the PV system by allocating filtration time outside of production hours, in turn producing an increase in grid energy import, compared to the SHEMS control.

5. Discussion

We want to open up the discussion by stating that the results shown in the previous subsection cannot be taken as proof that our test-bed SHEMS succeeds at obtaining better energy efficiency than the previous scenario, nor of the degree to which such benefit could be obtained. They have only been offered to support our claim that the system is capable of successfully integrating the many different actors present in the energy management of a Smart Home to take action depending on information coming from diverse sources.

With our demonstration, we show that we have integrated an existing Home Automation System (Home Assistant), making all of its information available to the rest of the SHEMS and leveraged it as a convenient way to reach users through notifications.

We have created a HEG proof of concept implementation, capable of integrating electricity pricing in our SHEMS, establishing good footing for the integration of future DR implementations. This HEG can act as an intermediary between the SHEMS and the grid (or micro-grids), opening the possibility of securely and privately sharing selected information from the system with the grid, which could be beneficial in DR and Demand Flexibility scenarios.

We have integrated DERs in the form of a PV installation and its attached accumulation battery system, as well as different high consumption devices, with different levels of functionality, using different communication technologies and integrated their information for other components of the SHEMS to use.

Finally, we have showcased an example of a simple energy management implementation capable of scheduling consumption for PV energy optimisation and reacting to high electricity demand by notifying users and disabling non-critical high-consumption devices.

This architecture brings to the field a framework for modular SHEMSs where different EMCs can be built by different parties and where DR, Home Automation, DER, devices and users, have been considered. As an added benefit, the core elements of the architecture can be readily deployed from COTS components, many of them coming from the FIWARE project, such as the security stack as well as the Context Broker.

In our proposal, all the information in the system can be accessed securely and privately way by any of the EMCs of the system. Moreover, this information is accessed using standard communication protocols specifically designed for interoperability. On top of that, information is formatted and structured following Semantic Web principles, leveraging existing ontologies representing all the necessary concepts, achieving data interoperability. Lastly, using the NGSI-LD communications standard, we implemented an orchestration mechanism for energy management, leveraging NGSI-LD’s publish/subscribe functionality. These four aspects are the main contribution of our work.

6. Conclusions and Future Work

In this work, a modular, interoperable and secure architecture for building SHEMSs has been proposed, presenting a set of EMCs for the management of the energy of a smart home. The presented architecture also considers prosumer interactions with the grid, local generation and accumulation optimisation, the management of high-consumption devices and the integration with existing HASs, while considering data security and privacy through access-control mechanisms.

The proposal is based on the NGSI-LD standard, which is used both as a semantic KB and asynchronous message passing for orchestration. Using this standard opens the possibility of re-utilising existing implementations of different FIWARE components in our architecture, such as the Context Broker, used for the KB, as well as some security components, like IdM and PEP. Lastly, existing implementations of other projects that lay within the FIWARE ecosystem have also been re-utilised, such as the DCapBAC components from project IoTCrawler.

The ontological foundation of the information model has been established from a selection of existing ontologies, analysed in Section 2.2, from which DABGEO has been selected as the base ontology, together with an array of complementary ontologies for specific use cases.

The proposal has been validated through the presentation of a test-bed scenario consisting of a single prosumer home governed by an existing HAS, which has been integrated into the SHEMS. The central components for the architecture, in charge of context management and security, have been instantiated from existing implementations. Examples of the representation of information and orchestration of different tasks between components have been showcased.

Finally, results in the form of a SHEMS capable of scheduling high-consumption devices for better PV utilisation and reacting to high energy consumption by notifying users and disabling non-critical loads, have demonstrated the feasibility of the solution, successfully being able to schedule the pool chlorination system based on PV production while integrating information coming from the HAS to react to changes in consumption by the home users. This has been possible thanks to the capacity of the system to integrate diverse information sources and its ability to provide secure mechanisms to access information within the different components instantiated.

This work opens the door to future proposals on multi-faceted SHEMSs in which to optimise complex systems controlling accumulation and generation, DR strategies communicating with the SG and, at the same time, leveraging the existing HASs installation to retrieve information from it and even interact with it.

It also opens the door for the development and deployment of specific EMCs that can be readily plugged into any SHEMS following our architecture proposal. One such example could be that of specific HEG implementations by different energy providers that would allow communication between homes and the SG to implement elaborated DR strategies.

Finally, it presents the possibility of creating specific SHEMS frameworks and implementations, ready to be deployed and integrated with other existing solutions in a single-click fashion, that would allow the easy deployment of a SHEMS by layman users, which in turn, would become a pivotal factor for the widespread deployment of advanced DR strategies.