*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).

**Figure 5.** NGSI-LD Information Model.

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 prosumerrelated 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 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).

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

**Table 2.** Complementary ontologies.

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. 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.

**Table 3.** OWL and NGSI-LD mapping.


#### *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.

**Figure 6.** Context Provider information access sequence.

#### *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).

**Figure 7.** Context authorisation and access sequence.

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


can be based on attributes from the IdM identity, the actions are HTTP verbs and the resources are HTTP resources, represented as URLs.

5. *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.

**Figure 8.** Authentication sequence.

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.

**Figure 9.** Authorisation sequence.

**Figure 10.** Authorisation enforcement sequence.

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.

**Figure 11.** Orchestration asynchronous message passing.

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) 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.


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

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.

**Figure 12.** Test-bed's Home Assistant installation graphical interface.

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.

**Figure 13.** Aerial view of the test-bed location. Pool, PV panels, HVAC and heating units visible.

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 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).

**Figure 14.** Protegé view of PVSystem in DABGEO.

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

```
{
  "id": "urn:ngsi -ld:PVSystem: Device:0042",
  "type": "PVSystem",
  "deviceName": {
    "type": "Property",
    "value": "INGECON SUN STORAGE 1Play TL M"
  } ,
  "maxProducesEnergy": {
    "type": "Property",
    "value": 6,
    "unitCode": "KW"
  } ,
  "@context": [
    {
      "deviceName": "http://www.purl.org/oema/enaeq/deviceName",
      "maxProducesEnergy": "https://www.auto.tuwien.ac.at/downloads/
          thinkhome/ontology/EnergyResourceOntology.owl#"
    } ,
    "https://uri.etsi.org/ngsi -ld/v1/ngsi -ld-core - context.jsonld"
  ]
}
```
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.

```
{
  "id": "urn:ngsi -ld: Subscription:PoolController:0001",
  "description": "Pool system dev.ctr. subscription",
  "type": "Subscription",
  "entities": [{
    "type": "PoolController",
    "id": "urn:ngsi -ld: PoolController:ID :0001"
    }],
  "watchedAttributes": ["controllerDesiredStatus"] ,
  "notification": {
    "attributes": ["controllerDesiredStatus"] ,
    "format": "normalized",
    "endpoint": {
      "uri": "http://pool :1880/notifications",
      "accept": "application/ json"
    }
  }
}
```
**Listing 3.** Notification in NGSI-LD.

```
{
  "subscriptionId": "urn:ngsi -ld:Subscription:PoolController:0001",
  "data": [{
    "id": "urn:ngsi -ld: PoolController:ID:0001",
    "type": "PoolController",
    "controllerDesiredStatus": {
      "type": "Property",
      "value": "OFF",
        "observedAt": "2022-06-10T10:11:57.000Z"
      }
  }]
}
```
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.

**Figure 15.** Secure access of Energy Management Components to the Context Broker.

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:

**Figure 16.** Test-bed Energy Management Components and interactions.


nent also reacts to HEC's inputs (through orchestration mechanism) to temporarily stop/resume operation.


**Figure 17.** Alerting and notification through Home Assistant.

**Figure 18.** Node-RED development of the DER component for PV.

#### *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.

**Figure 19.** Power peaks prior to Smart Home Energy Management System.

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.

**Figure 20.** Power peaks with Smart Home Energy Management System.

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 Listings 2 and 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.

**Figure 21.** Grid energy import comparison.

#### **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.

**Author Contributions:** Conceptualisation, P.G.-G. and A.S.; methodology, J.A.M.; software, P.G.-G.; validation, A.S. and J.A.M.; formal analysis and investigation, P.G.-G.; data curation, P.G.-G.; writing original draft preparation, P.G.-G.; writing—review and editing, A.S. and J.A.M.; supervision, A.S.; project administration, A.S.; funding acquisition, A.S. All authors have read and agreed to the published version of the manuscript.

**Funding:** This work was supported by Grant PID2020-112675RB-C44 funded by MCIN/AEI/ 10.13039/501100011033.

**Data Availability Statement:** Not applicable.

**Conflicts of Interest:** The authors declare no conflict of interest. The funders had no role in the design of the study; in the collection, analyses, or interpretation of data; in the writing of the manuscript; or in the decision to publish the results.

#### **Abbreviations**

The following abbreviations are used in this manuscript:


#### **References**

