ComfOnt: A Semantic Framework for Indoor Comfort and Energy Saving In Smart Homes

Abstract

This work introduces ComfOnt, a semantic framework developed within the context of ambient assisted living, context awareness, and ambient intelligence Italian research projects. ComfOnt leverages knowledge regarding Smart Home inhabitants and their particular needs, the devices deployed inside the domestic environment (appliances, sensors, and actuators), the amount of their energy consumption, and indoor comfort metrics to provide dwellers with customized services. Developed reusing widely adopted ontologies, ComfOnt aims at providing inhabitants with the possibility of having personalized indoor comfort in their living environments and at helping them in scheduling their daily activities requiring appliances; in fact, the proposed semantic framework enables the representation of appliances’ energy consumption and the energy profile of the Smart Home, thus assisting the dwellers in avoiding power cuts and fostering energy savings. ComfOnt serves as a knowledge base for a prototypical application (DECAM) dedicated to Smart Home inhabitants; the architecture and the functionalities of DECAM are here presented.

1. Introduction

In the last decades research regarding the Smart Home (SH) has widely increased. An SH is a residence equipped with various devices controllable via mobile devices with the aim of easing domestic activities, improving indoor comfort, enhancing safety, and fostering energy saving [1]. This type of residence must be able to adapt its services to meet inhabitants’ expectations, needs, and desires and relies on networks of sensors and actuators to deliver its services. In order to be able to adapt its services, an SH acquires data regarding indoor comfort, inhabitants’ activities, preferences and, if necessary, health statuses. Inside the SH, a set of distributed devices cooperates to collect, share and re-elaborate data to perform different tasks, thus enabling the Internet of Things (IoT) paradigm. All the pieces of information regarding sensors’ measurements, devices’ statuses, inhabitants’ activities and needs must be made available to all the devices (and the dwellers) to enable an IoT architecture [2] aimed at providing a more comfortable domestic environment. This goal can be achieved using ontologies, i.e., shared and explicit conceptualizations of the knowledge and of the relationships of the concepts composing a domain [3], which represent a promising approach for managing information deriving from different sources and for enhancing interoperability among devices. Moreover, ontologies can enable Semantic Web reasoning processes to discover new chunks of information—inferred from those modeled in the knowledge base—thus enriching the ontologies themselves with new inferred facts.

Although research in the fields of SH, ambient assisted living (AAL), ambient intelligence (AmI), context awareness (CA), and IoT leveraging semantic formalization of knowledge has acquired a growing importance in the last years, only a few works dedicated to the SH tackled the issue of modeling indoor comfort metrics. This work aims at contributing to the field of domain ontologies dedicated to the representation of knowledge necessary to customize services within an SH, including comfort metrics leveraging on already existing models. The proposed set of domain ontologies arises from the experiences of three Italian research projects funded by the Lombardy Region: i-Zeb, Future Homes for Future Communities (FHfFC), and CasAware. i-Zeb [4] is a project aimed at researching and investigating the use of innovative building materials and technological solutions to foster the implementation of Nearly Zero-Energy Buildings. FHfFC [5] focuses on deploying a semantic architecture to enable a set of assistive services aimed at improving inhabitants’ daily lives; the services are addressed to an ageing population and encompass a wide range of fields, such as indoor comfort, device interoperability, and domestic rehabilitation. CasAware [6,7] leverages ontological representation of domestic appliances and their energy consumption to foster energy saving behavior, help the dwellers to better schedule their operations with appliances, and avoid domestic power cuts.

The set of domain ontologies developed within these three projects—named ComfOnt—allows the formalization of some fundamental indoor comfort metrics, including Italian regulations and laws, and knowledge regarding sensors, actuators, and measurements; ComfOnt can be adopted to describe environmental conditions within the SH and to trigger comfort actuation after detecting an unsafe or uncomfortable situation, exploiting the results deriving from reasoning processes. Moreover, ComfOnt can foster the adoption of energy saving behaviors and support dwellers in scheduling domestic activities involving appliances. The ComfOnt knowledge base acts as the backbone of a prototypical decision support system (DSS) to help SH inhabitants in managing their indoor comfort and energy consumption.

The remainder of this work is organized as follows: Section 2 highlights some of the research devoted to formalizing and using ontologies to model indoor comfort conditions, sensors, actuators, and appliances in AAL, AmI, and CA contexts. Section 3 introduces the ComfOnt ontology, deepening the engineering methodology adopted and delving into the description of the model developed. Section 4 describes the architecture of a prototypical application using ComfOnt, the Domestic Environment Comfort and Appliances Manager (DECAM) and proposes some use cases focusing on different aspects to showcase DECAM’s functionalities. Finally, the Conclusions summarize the main outcomes of this paper and sketch the future directions of this research.

2. Related Work

Research on comfort has acquired a growing importance in the past years in the contexts of the SH and CA, AmI, and AAL systems. Along with these research fields, ontologies have been exploited as a means to provide a shareable and formal conceptualization of a variety of domains of knowledge that are related to the SH or its components. However, only a few works tackled the issue of providing a reusable model of indoor comfort metrics, focusing mostly on the description of concepts related to energy consumption and saving [8,9], device descriptions [10,11], human activities within the SH [12], and interoperability among various devices [13,14].

Gâteau et al. [15] proposed an IoT system for personal comfort management; in this work, comfort representation with ontologies was addressed relying to classes deriving from the DogOnt ontology [16] and Semantic Sensor Network (SSN) ontology [17]. A similar approach was adopted in [18], where an indoor environmental comfort system takes advantage of a context domain ontology that formalizes concepts for the description of sensors and actuators; comfort metrics are not explicitly modeled in this work, although contextual data are acquired and re-elaborated using semantic rules. Air quality is addressed in [19], where an ontology formalizing some of the knowledge of the standard ISO 7730:2005 is proposed. Some comfort-related concepts are modeled in BOnSAI [20], an ontology developed to foster the incorporation of AmI in smart buildings; though the semantic model is dedicated to describe devices’ functionalities, services, and hardware, it encompasses also some contextual concepts that represent comfort and users. Similarly, ThinkHome [21] is a semantic model developed to represent the whole SH ecosystem, thus including also some concepts related to comfort. Ploennings et al. [22] provided a semantic model for the representation of thermal comfort, within a semantic framework aimed at automatized approaches for modeling cyber-physical systems. In [23] the authors tackled the modeling of some indoor comfort metrics by reusing some reference models to enable customization of comfort in cruise cabins; the ontology is here adopted as a backbone for an IoT framework aimed at monitoring and enhancing the cruise experience.

Semantic Web technologies are exploited in a variety of works in the fields of AAL, AmI, CA, and IoT systems to different extents. Ontology modeling is adopted as a means to build a shareable vocabulary among the different actors operating in the SH, such as sensors, actuators, inhabitants. In [24] an ontology for context modeling is used to facilitate explicit context representation and to allow services to share contextual information, as well as inferring new pieces of information through reasoning processes. Abdulrazak et al. [25] presented a novel ontology to describe contexts in smart spaces; although the ontology does not provide concepts for comfort description, it encompasses several representations of the actors that operate within a smart environment, with a focus on beings—a concept including both physical and non-physical entities. Fensel et al. [26] referred to an ontology for developing an SH system software capable of managing energy within a domestic environment, by exploiting semantic data. Ontologies are also used in [27] to provide an energy management software system with a multitude of different parameters and facilities. Energy efficiency is a widely debated topic in IoT research: Kibria et al. [28] relied on ontologies to develop cross-domain applications aimed at simplifying the maintenance of an SH, including the management of energy consumption; the proposed approach relies on a domain ontology developed from scratch and allowing to represent some appliances and comfort conditions. Modeling energy profiles in an ontology allowed Brizzi et al. [29] to rely on a vocabulary for the description of energy consumption; the developed semantic models are exploited by a CA service framework capable of managing sensor data and events and of exploiting reasoned data about energy savings.

One of the most relevant topics in AAL, CA, and AmI applications is the user, i.e., the inhabitant. Ontologies allow formal representations of the inhabitants under different points of view. Casas et al. [30] proposed a user-modeling methodology based on personas, i.e., archetypical representations of real individuals that can help designers in being aware of the information that can impact on the design of an AAL or AmI system; this approach has proven to be useful also when it comes to modeling ontologies that take into account inhabitants [31]. To overcome the problem of a static definition of the users, Castillejo, et al. [32] introduced the concept of dynamic capabilities, which takes into account a user, his/her specific needs, and the characteristics of the context in which he/she operates. In this regard, the SH needs to encompass also dwellers’ data regarding their needs and health conditions, and ontologies can provide the means to formalize this non-static information. In [31,33], semantic representations of people’s health conditions are used to trigger environmental adaptations, so that the environment is able to meet its occupants’ needs. Following a different approach, Heckmann et al. [34] revisited the General User Model Ontology (GUMO) [35], taking into account Web 2.0, thus enriching it with tags and folksonomies provided by user-generated contents on the Web.

It is worth noticing that contextual information may carry uncertain and vague data; addressing this issue from an ontological point of view can lead to a more precise inference process. The possibility to semantically model uncertain and vague information has been widely addressed in literature [36], and many extensions of semantic modeling languages have been described (such as BayesOWL [37], which translates ontologies into Bayesian networks to capture partial, uncertain, and incomplete chunks of knowledge, and PR-OWL [38], an extension of the ontological language based on Multi-Entity Bayesian Networks combining the possibilities offered by semantic representation with the inferential power of Bayesian logic). In [39], the authors addressed the problem of uncertain and vague contextual information by relying on AMBI²ONT, an ontology that models the ambiguity of smart environments by adopting a semantic context management system able to process uncertain and vague data; the described model can provide a more detailed picture of the state of an environment while ascertaining the quality of data gathered by sensors.

ComfOnt focuses on providing a shareable and formal representation of indoor comfort metrics based on national (Italian) and international standards. Differing from the users’ modeling approaches depicted above, ComfOnt takes into account the inhabitant’s health condition (using a World Health Organization standard classification), which modifies over time and requires clinical personnel to periodically update it. ComfOnt and DECAM’s system are conceived to be least intrusive as possible, considering that the primary target of this application is elderlies (who may not be tech-savvy) and people characterized by different impairments (often associated with aging processes). In fact, according to several sources there exist barriers that can jeopardize the adoption of technological solutions in AAL, CA, and AmI fields, such as the user-friendliness of devices [40,41], the unfamiliarity with technological devices [41], and users’ concerns regarding social stigmatization; Balta-Ozkan et al. [42] highlighted how elderlies may struggle to adopt this technology in cases where the user-friendliness and simplicity of the devices are not evident. ComfOnt also encompasses the formalization of household appliances, energy consumption, and dwellers’ health conditions, as well as rules to actuate service customization within the SH. The presented ontology can thus be used as the backbone of a DSS to foster energy savings and to assist dwellers in scheduling the activities involving appliances in their homes.

3. ComfOnt Ontology

This section delves into the description of ComfOnt, starting with the engineering methodologies, the models already existing that were reused, and the possible alignments that can be produced from ComfOnt to other reference domain ontologies.

3.1. Ontology Engineering Methodology and Specification

ComfOnt was developed following the principles and guidelines described in the NeOn Methodology [43]. This ontology engineering methodology provides the means to identify and guide in the choice of both ontological and non-ontological resources that can be reused to develop new semantic models; the NeOn Methodology illustrates nine scenarios that may occur during the development of a new ontology, considering the reuse of existing resources, the adoption of ontology design patterns already known in literature and in practice, the identification of non-ontological resources (such as thesauri, classifications, schemes, etc.) that could be converted into semantic models, the merger of two or more resources. The NeOn Methodology is also useful to determine whether to include or exclude some concepts from the ontology to be developed.

The ontologies identified with this methodology and reused for the development of ComfOnt are the following:

• Semantic Sensor Network (SSN) [17]: This ontology was developed by the World Wide Web Consortium (W3C) and allows description of the sensors in terms of their capabilities, performed measurements, observations and deployments; its concepts are organized in ten modules and inherit some concepts and properties from the DOLCE+DnS Ultralite upper ontology [44]. SSN is a widely adopted ontology in CA, AmI, IoT, and AAL projects involving semantic representation and annotation of sensors, actuators, and their observations. A lightweight ontology part of SSN is Sensor, Observation, Sample and Actuator (SOSA), which consists of classes and properties to describe both sensors and actuators and the measurements they perform (observations) [45].
• Smart Appliance REFerence (SAREF) [46]: This ontology is the result of a European research project and was developed leveraging the knowledge of domain experts. It provides the concepts and relationships for the description of devices, their functions, and the commands to activate them. SAREF also encompasses concepts and properties to describe the energy profile of a device. This model aims at covering the domains of domestic devices (white and brown goods, HVAC systems, sensors) and encompasses the representation of some units of measurement. SAREF can be adopted in the description of IoT systems and some of its concepts and relationships converge with those modeled in SSN [47].
• International Classification of Functioning, Disability and Health (ICF) ontology: This World Health Organization classification allows formalization of the health condition of an individual using a worldwide standard model for the functional description of an individual; the ICF enables the description of the functioning of an individual and was originally developed to foster the cooperation among health stakeholders (physicians, caregivers, therapists, etc.). The classification is organized in four main components (body functions indicated with the letter b, body structures indicated with the letter s, activity and participation indicated with the letter d, and environmental factors, indicated with the letter e), each of which can be further deepened into domains to identify the kind of problem addressed. According to the number of digits following the component, it is possible to get a category (a code in the form of cXXX.q) whose length indicates the level of granularity in the description of the health issue, up to five digits. For each category, a qualifier (ranging from 0 being no impairment to 4 being complete impairment) specifies the magnitude of the disability described. The ICF has been formalized into an ontology [48].
• Friend of a Friend (FOAF) vocabulary [49]: This widely adopted vocabulary allows for the description of people’s personal data (name, surname, contacts, etc.).
• Time Ontology (2017 version) [50]: a W3C-endorsed ontology specifically developed to provide description of temporal concepts, which can be used to represent time intervals in order to properly model the durations of an appliance usage.

Also, following the NeOn Methodology, some European and national regulations have been found for indoor comfort management. These regulations can be partially formalized to describe comfort-related phenomena that may happen inside an indoor environment.

The regulations adopted for ComfOnt are the following:

• The Italian Decree 412 (1993) [51], setting the thresholds for indoor heating;
• The EN 12464-1 (2002) [52], indicating the minimum acceptable indoor illuminance values for indoor activities;
• The Italian National Plan of Prevention for the safeguard and promotion of health in confined spaces (2002) [53], providing indications on the air quality inside domestic environments.

The ontology needs also to take into account appliances’ energy consumption, therefore (following the approach described in [54]) to model these pieces of information, data regarding the average energy consumed (in watts) and the average amount of time of use for each appliance were gathered recurring to an online resource, the Energy Use Calculator [55]; this website provides information for each type of appliance (brown goods, e.g., irons, televisions, computers; and white goods, e.g., dishwashers, refrigerators, washing machines). Moreover, the dweller’s energy rate plan must also be modeled in order to know when it is more convenient to plan an intensive use of the appliances; ComfOnt relies on an example of an energy rate plan that is composed of three different tariffs: from Mondays to Fridays, in the interval between 08:00:00 and 19:00:00 the energy cost is 0.091 euro/kWh (T1); for the same days, in the interval between 19:00:01 and 07:59:59 the energy cost amounts to 0.083 euro/kWh (T2); during Saturdays and Sundays the energy cost is 0.081 euro/kWh (T3). The maximum electric meter load for a dweller’s domestic environment is estimated at 3.3 kWh.

The domains of knowledge discovered using the NeOn Methodology allow identification of four main modules in which ComfOnt can be ideally organized; the components of these modules are represented by the ontologies (or their parts) to be reused and they interact with each other. The following Figure 1 provides a schematic representation of the modular architecture of ComfOnt.

ComfOnt was developed using the Protégé ontology editor [56] (version 5.2) and adopting the W3C-endorsed languages Resource Description Framework (RDF) [57,58] with the Semantic Web Rule Language (SWRL) [59] for rules.

3.2. The ComfOnt Ontology

The following paragraphs delve into the description of ComfOnt’s modules, highlighting the most relevant ontology design patterns (ODPs) [60] adopted.

3.2.1. Inhabitants’ Module

Each dweller is identified by his/her own personal data, such as name, surname, address, tax identification number (to avoid issues related to homonymy), date of birth, age (expressed in years), phone number(s) and email address; all of these features are described recurring to FOAF.

Following an ODP described in [31,33], each dweller is assigned to his/her health condition, which is detailed recurring to the ICF ontology. Figure 2 provides a graphical representation of a 68-year-old dweller and his health condition, which is characterized by a severe impairment in light sensitivity (b21020) and a moderate impairment in sustaining attention (b1400).

Each dweller is also linked to the energy rate plan he/she is currently adopting for his/her house. The description of the plan is simple and reuses the Time Ontology to describe temporal intervals corresponding to the three different tariffs. Each day of the week (from Monday to Friday) is split in three time:ProperInterval individuals: two intervals in which T2 is active (the first interval characterized by the property time:hasBeginning for a time:Instant positioned in time:inXSDDateTimeStamp YYYY-MM-DDT00:00:01Z, and by the property time:hasEnd for a time:Instant positioned in YYYY-MM-DDT07:59:59Z; the second interval characterized by the property time:hasBeginning for a time:Instant positioned in YYYY-MM-DDT19:00:01Z, and a property time:hasEnd for a time:Instant positioned in YYYY-MM-DDT23:59:59Z) and one for T1 (characterized by time:hasBeginning for a time:Instant positioned in YYYY-MM-DDT08:00:00Z, and time:hasEnd for a time:Instant positioned in YYYY-MM-DDT19:00:00Z). Weekend days, characterized by the same tariff T3 for their entire duration, are described as two one-day-long intervals.

3.2.2. Devices and Domestic Environment Modules

The modeling of a device relies on SAREF and SOSA. The two ontologies have many classes and properties describing the same concepts and relationships (for instance, the pairs sosa:Actuator and saref:Actuator, sosa:Sensor and saref:Sensor describe the same concepts) and, therefore, the models are partially overlapping.

The adoption of these two ontologies enables on the one hand the description of appliances, sensors, and actuators and, on the other hand, it provides the means to describe the measurements performed by sensors. Since SAREF encompasses some individuals representing common units of measurement (such as lux, degree Celsius, kilowatt hour, etc.) the description of the measurements involves both datatype and object properties.

To describe the average energy consumption of an appliance, ComfOnt relies on both SAREF and ad hoc developed properties. The average energy consumes and the average daily time of usage for some domestic appliances were estimated recurring to an online resource; the following

Table 1. A table summarizing the list of appliances modeled within ComfOnt; for each appliance, the average time of usage (expressed in hours) and the average electric energy consume (expressed in watts) are reported.

Appliance	Average Time (in hours)	Average Watt Consume	kWh/day
Electric oven	1	2400	2.4
Dishwasher	1	1800	1.8
Electric stove top	1.5	1500	2.25
Refrigerator	24	180	4.32
Microwave	0.5	1200	0.6
Freezer	24	40	0.96
Vacuum	0.25	1400	0.35
Iron	1	1100	1.1
Washing machine	1	500	0.5

summarizes the list of appliances modeled in the Devices module of ComfOnt.

Each appliance is associated with its saref:Profile, which enables the representation of energy consumption, and with an average time of use, which is defined by a time:ProperInterval that can be characterized by the properties time:hasBeginning and time:hasEnd, and is also defined by a time:hasTemporalDuration property, adopted to express the time:TemporalDuration of the interval. Figure 3 provides an example of a household appliance modeling.

In order to represent the domestic environment in which devices are deployed and dwellers live, ComfOnt relies on a simple representation of the rooms of the house; in its prototype version, ComfOnt only encompasses four classes and four individuals for the representation of the kitchen, the living room, the bedroom, and the balcony.

3.2.3. Comfort Module

With regard to the description of the comfort metrics and the dweller’s individual preferences, ComfOnt relies on a domain ontology developed from scratch and that partially overlaps with some of SAREF’s concepts. This simple ontology, whose prefix is comf:, allows the formalization of comfort metrics (i.e., the physical magnitudes) within the class comf:ComfortMetrics (≡saref:Property). ComfOnt enables the modeling of four comfort metrics that can be measured by sensors and customized by dwellers: indoor illuminance, indoor CO₂ concentration (for which the unit of measurement comf:ppm has been created), indoor temperature, and humidity rate. However, following the same ODP, other relevant comfort metrics (such as acoustic comfort metrics) can be added, as well, in order to enhance the description of the inhabitants’ environment.

Each of these comfort metrics is represented as a concept in the ontology and dweller-based specific values for each metric can be specified. For each dweller it is possible to describe an individual belonging to the class comf:CustomizedComfort_Settings, which is further detailed by some individuals belonging to the class comf:Specification (and its detailed subclasses, such as comf:IndoorIlluminance_Specs), as exemplified in the following excerpt in Manchester OWL syntax [61]:

Individual: comf:Karlo_CS 

 Types: 

   comf:CustomizedComfortSetting 

 Facts: 

  comf:specifiesIlluminanceValues comf:Karlo_Illuminance_Specs 

 

Individual: comf:Karlo_Illuminance_Specs 

 Types: 

   comf:IndoorIlluminanceSpecs 

 Facts: 

  comf:MAX_IlluminanceValue "750"^^xsd:int, 

  comf:MIN_IlluminanceValue "350"^^xsd:int. 

These comfort specifications are intended for a person with vision-related impairments, such as the inhabitant described in Figure 2; since Basil Karlo suffers from hyposensitivity to light, he can benefit from a domestic environment with a higher level of illuminance; therefore, his minimum indoor illuminance is set to 350 lux and can reach a maximum of 750 lux. In a similar way, and recurring to modeling time intervals, it is possible to represent customized comfort values for indoor temperature (with a minimum and a maximum temperature for both spring–summer and fall–winter seasons), humidity rate, and CO₂ concentration.

It is worth noticing that in any case comfort ranges for each metric must be set according to national and European laws and regulations regarding heating [51], indoor illuminance [52], and air quality in domestic environments [53]. ComfOnt resorts to restrictions on the values of the datatype properties defining a customized comfort setting to allow a reasoner to automatically classify a customized indoor comfort setting as within the legally acceptable ranges or not; for instance, a customized comfort specification with a maximum indoor CO₂ concentration of 2351 ppm (when [53] sets the tolerance limit to 1000 ppm for indoor domestic environments) falls under the comf:UnacceptableIndoorCO2Specs, since this class is defined as:

Class: comf:Unacceptable_CO2_CS 

 EquivalentTo: 

  comf:CustomizedComfortSettings and comf:MAX_CO2Conc_level only xsd:decimal[> 1000.0]. 

Considering that ComfOnt (and the DECAM application discussed in Sect. 4) deals with inhabitants that may be characterized by disabilities or may need specific comfort metrics to overcome limitations connected with their health conditions, the proposed ontology relies on existing ODPs to model comfort metrics; ComfOnt’s aim does not involve the calculation of the best indoor temperature, CO₂ concentration, humidity rate, or illuminance according to an individual’s characterization. In fact, ComfOnt’s indoor comfort metrics description is limited to what regulations have set as minimum and maximum thresholds for indoor temperature, CO₂ concentration, and illuminance; as the setting of specific indoor comfort values can impact the health of the inhabitants (especially those characterized by visual, heart-related, and respiratory impairments), this task is up to the caregiver and clinical personnel, who can better advise on this matter with the aim of safeguarding the inhabitant’s health.

3.2.4. Sets of Rules

ComfOnt is completed with sets of rules modeled with SWRL to trigger personalized comfort actuation. With regard to the dweller modeled in Figure 1, the following SWRL rule suggests he activate the lamp whenever he is in a room with an inadequate indoor illuminance (due to a lack of natural light):

Person(?d), isInHealthCondition(?d, ?hc), HealthCondition (?hc), isDescribedBy (?hc, ?des), HC_Descriptor(?des), involvesICFCode (?des, b2102), Quality_of_vision (b2102), hasQualifier (?des, ?q), greaterThanOrEqual (?q, 2), isLocatedInRoom (?p, ?r), Room(?r), Lighting device (?light), isLocatedIn (?light, ?r), IndoorIlluminanceSpecs (?ill), MIN_IlluminanceValue (?ill, ?x), ExternalIlluminance (?exill), hasMeasurementValue(?exill, ?m), lessThan (?m, ?x) -> setsLighting (?light, ?ill) 

This rule takes into account both the dweller’s health condition and customized comfort settings that have been modeled to help him to overcome his impairments.

Similarly, the following rule suggests turning the air-conditioning system on when the indoor temperature exceeds an inhabitant’s tolerance (defined in his/her customized comfort settings):

Person(?d), isLocatedInRoom (?p, ?r), Room(?r), Thermometer(?t), isLocatedIn (?t, ?r), measures (?t, ?temp), IndoorTemperatureMeasurement(?temp), hasSimpleResult (?temp, ?x), greaterThan (?x, ?y), IndoorTemperatureSpecs (?costumTemp), preferredSummerTemperature (?costumTemp, ?y) AirConditioningSystem(?ac) -> setsIndoorTemperature (?ac, ?y) 

Rules can also be used to model the time intervals during which appliances are being used and to calculate the total amount of energy that is being consumed by them. As seen in Section 3.2.2, the average time of use for each appliance has been modeled as a duration (expressed in hours) and as a time interval, which starts and ends in two different time instants. Therefore, two appliances being used at the same time means their durations are—at least partially—overlapping. For the duration of the overlap, the two appliances are accounted for consuming the amount of energy specified by the com_dev:averageConsume_kWh datatype property.

The total amount of energy being consumed in a specific time interval is obtained by summing the com_dev:averageConsume_kWh of all the appliances that are running in the same instant (the state of an appliance can be modeled recurring to saref:On_off_state and its subclasses). The following SWRL rule summarizes the situation described above, recurring also to a relationship modeled in the Time Ontology and to SWRL built-ins:

Device(?d1), Device(?d2), averageTimeUse(?d1, ?use1), averageTimeUse(?d2, ?use2), hasBeginning(?use1, ?b1), hasEnd(?use1, ?e1), averageConsume_kWh(?d1, ?x), hasBeginning(?use2, ?b2), hasEnd(?use2, ?e2), averageConsume_kWh(?d2, ?y), lessThanOrEqual(?b1, ?b2), greaterThanOrEqual(?e1, ?e2), GeneralSituation(?sit), involvesAppl(?sit, ?d), add(?tot, ?x, ?y) -> interval_during(?use2, ?use1), totalAverageConsume_kWh(?sit, ?tot). 

Whenever the total amount of energy being consumed in a specific time interval exceeds the maximum electric meter load (which is set to 3.3 kWh), the individual representing this situation (i.e., the total amount of energy being consumed and the list of appliances whose state is saref:OnState) is classified as com_dev:PowerCutRisk. In order to get the values of the end instants, the DECAM application using ComfOnt (described in the following Section 4) performs the end time calculation.

3.3. ComfOnt Possible Mappings with Other Relevant Ontologies in the Domains of Interest

Using the NeOn Methodology, it was possible to identify previously developed ontologies that have been reused to develop ComfOnt. The ComfOnt ontology can therefore rely on solid, widely adopted and evaluated existing semantic models. However, there exist several domain ontologies dedicated to the representation of knowledge in the fields covered by ComfOnt and conceptual heterogeneity [62], which can be defined as the set of differences standing between two ontologies that describe the same domain of interest, and which is one of the problems to overcome in order to achieve a complete mapping between ComfOnt and other models.

In the field of smart appliances and energy consumption of devices, ComfOnt relies on the mappings that already exist for the SAREF and SSN ontologies. In particular, exploiting SAREF allows ComfOnt to rely also on SAREF’s extension SAREF4ENER, a semantic model focusing on demand–response scenarios for indoor device energy management [63]. ComfOnt can also be mapped with other ontologies describing the energy consumption within domestic environments, such as Monergy [64] and the Foundation for Intelligent Physical Agents (FIPA) [65] model; these ontologies rely on a conceptual hierarchy similar to SAREF and, therefore, can be matched with ComfOnt’s description of the devices.

The adoption of ICF as the ontology for the description of the dweller’s health conditions allows completion of the person’s description with the International Classification of Diseases (ICD) [66], thus fostering the description of people characterized by specific health-related problems; the tenth version of the ICD has also been formalized in an Unified Medical Language System (UMLS) ontology [67].

As described in Section 3.2, with regard to the description of the indoor environments composing the dweller’s house, ComfOnt relies on a simplistic description of the spaces. This simple model can potentially be matched with many of the ontologies that were developed with the specific aim of providing a formalization of the house and its features. In this field, SmartENV [68], a network of ontologies for the conceptualization of smart environments; DogOnt [16], a model able to provide the means to represent how a domestic environment is composed (including architectural elements and pieces of furniture); and DomoML-env [69], an ontology for the description of the interactions between humans and the house, are some examples of ontologies that can be aligned with ComfOnt.

4. Domestic Environment Comfort and Appliances Manager Prototype Application and Use Cases

In this section the architecture of an application called DECAM, i.e., Domestic Environment Comfort and Appliances Manager, its functionalities, and its relationship with ComfOnt are presented. DECAM is developed to help inhabitants to manage indoor comfort metrics and household appliances via a graphical user interface (GUI) designed and implemented to let the users interact with the whole system while hiding the most complex aspects, such as the underlying ontology, from the end users. ComfOnt is hosted on a semantic repository, a triplestore that can be used to retrieve and modify RDF and OWL triples via the SPARQL [70] query language.

The remainder of this Section showcases the functionalities of DECAM, as well as the role of ComfOnt in plausible use cases involving the target users, i.e., persons characterized by impairments and elderlies.

4.1. Application Architecture

DECAM is developed exploiting the Java programming language Standard Edition (SE) and JavaFX libraries for cross-platform user interface, to let the users interact with the system via a simple interface. This program is implemented to access the semantic repository, retrieve the information, and update ComfOnt if needed. DECAM is designed to be a standalone application, able to be easily installed and implemented on different houses, however it needs an implementation phase in which the operator installs and deploys all the software and hardware equipment in place. The target house must be equipped with a set of smart nodes such as sensors and actuators to enable the exchange of data and information between the physical environment and DECAM framework. These smart nodes are the microcontroller-enabled devices, namely sensors and actuators to detect, measure, and transmit the data about a specific environmental condition, as well as triggering the physical environment.

The following is the list of sensors deployed in the target house:

• AM2320 Digital Temperature and Humidity Sensor,
• TSL2561 Digital Luminosity/Lux/Light Sensor,
• 3709 Adafruit SGP30 Air Quality Sensor Breakout for VOC and eCO2.

The process of exchanging the data takes place exploiting embedded ZigBee-based IoT gateways mounted on the Raspberry Pi device as a central computing device. ZigBee is a low-power wireless network protocol based on the IEEE 802.15.4 standard.

In order to help the inhabitants in managing and conserving electric power in a more efficient way and managing indoor comfort, the ability to access, manipulate, and exchange information over the semantically modeled data is essential. ComfOnt is hosted on an instance of the Stardog triplestore [71], a semantic repository that enables semantic reasoning with OWL, is capable of managing rules in the SWRL format, and can export inferred data in various formats.

DECAM must be able to access the semantic repository and retrieve the information regarding the domestic appliances, the power they need to consume, the time they need to operate, and the current status of the appliance, leveraging the information modeled into the knowledge base.

In addition to retrieving the information—as mentioned in Section 3.2—the application needs to calculate the time efficiently to detect the overlapping time between the concurrent appliances running at the same time and the ending time of each appliance according to its duration modeled in the ontology. Although SWRL foresees a set of temporal built-ins, the majority of the of reasoners do not process most of them. Moreover, SWRL temporal operators work at very low level and there are no standard high-level mechanisms to reason with temporal information in a smooth and coherent manner [72].

Therefore, the system relies on the application to perform the time-related calculations. However, OWL is based on the open-world assumption (OWA) and one of the consequences of the adoption of OWA is the impossibility for description logic (DL)-based reasoners to infer new pieces of information due to the incompleteness of the information modeled in a semantic model [73]. Moreover, due to the monotonic nature of description logic (DL) reasoning, the modification of asserted information is a task that DL-based reasoners cannot perform [73]. To overcome these limitations, DECAM is implemented to support the users in power consumption management while overcoming the technological barriers effectively; this can be done by adopting SPARQL query language, which allows the system to modify the asserted triples and to insert new triples

The application also encompasses a simple GUI illustrating different domestic appliances within any average house (Figure 4). This application is designed to be simple and intuitive to be used by diverse groups of people including the elderly and people afflicted by disabilities.

Any time the dweller wants to turn on an appliance, he/she can reveal his/her intention to the application by clicking on the proper button (i.e., an icon representing the appliance). Once the user taps on any appliance, the application generates a proper SPARQL SELECT query to retrieve information about that specific appliance from the semantic repository. The information fetched from the knowledge base includes the appliances, their average power consumption, their average time of use, and the energy rates. Whenever an inhabitant wants to start an appliance, the application performs the steps illustrated in Figure 5.

When the activation of an appliance is safe, i.e., it does not result in the risk of power cut, the average time of use (which is represented as a time:TemporalDuration in ComfOnt) is converted and summed to the time instant in which the dweller wants the appliance to be turned on, so that it is possible to calculate the instant in which the appliance will be turned off; the time required for the appliance to finish its task is then fetched and displayed to the user via the application. Whether the activation of an appliance may result in a power cut or not is a piece of information that can be retrieved by leveraging the SWRL rule illustrated in Section 3.2.3, as every appliance whose activation may generate an exceeding of the power threshold is classified as an instance of the class com_dev:PowerCutRisk.

In case of power cut risk, DECAM’s GUI warns the dweller by showing a pop-up indicating the risk at hand and the appliance whose activation may cause the issue. If activating a new device would cause it to exceed the current capacity threshold, the application warns the user of the risk of a power cut and suggests that he/she reschedule the activation of the device to a proposed time. Since the application keeps track of all the running devices and their durations within the house, it is able to suggest to the user a time when it is safe to turn on the device without any risk of a power cut. The proposed time is calculated in real time within the application to be the first minute after one (or more) of the running appliances has finished its operations; this appliance would then liberate the amount of power it was using during its activation, and if the total amount of energy available becomes enough for another appliance to be activated—without exceeding the capacity threshold—then the application can safely activate it.

Therefore, the application needs to calculate the ending time of an appliance using the starting time received from the application—the moment the user clicks the appliance to be activated—and the duration time retrieved from the semantic repository. DECAM then inserts the starting and ending time stamps into the ComfOnt knowledge base by generating a proper SPARQL INSERT query. DECAM also interacts with ComfOnt to modify the status of the devices (i.e., determining whether an appliance belongs to saref:On_state or saref:Off_state).

In a similar way, DECAM accesses the triplestore to retrieve the dweller’s health condition and his/her customized comfort settings, in order to activate the devices with those features that can actuate personalized indoor comfort.

4.2. Use Cases

The following use cases showcase the functionalities of DECAM, thus exploiting ComfOnt as its knowledge base. It is worth noticing that although the system’s features were specifically designed for elderlies and dwellers characterized by frailties, the functionalities could be adopted also by a variety of dwellers, i.e., not necessarily inhabitants characterized by impairments.

4.2.1. Preventing Power Cuts Due to Overload

John is a 71-year-old man who lives on his own; he can perform many of the daily activities by himself and thus can live independently. Due to his impairment (characterized by ICF code b1140.1 as Short-term memory, with a “mild” qualifier), sometimes he leaves some appliances turned on and forgets about them; this behavior sometimes results in generating a power cut due to overloading.

John is currently cooking and DECAM enlists the following appliances as running: a refrigerator, the electric stove top, the washing machine, and the dish-washer; the average energy consumes (according to Table 1) amount to 1730 W. He needs to turn on the electric oven to complete his recipe, but he is unsure whether or not the activation of this appliance may result in a power cut. Using DECAM John turns the oven on and the interface warns him that by completing this action the total amount of energy would exceed the 3300 W of his meter load (as illustrated in Figure 6). John can therefore turn the electric stove off in order to be able to turn the oven on.

Using DECAM’s GUI, whenever John wants to turn an appliance on he can see which appliances are already running and their average energy consumes; he can also see how much energy another appliance would require and understand whether or not turning another appliance on would result in a power cut.

4.2.2. Regulating Indoor Comfort According to the Dweller’s Needs

Basil, a 68-year-old man living independently in his home, suffers from hyposensitivity to light (characterized by ICF code b21020.3 as Light sensitivity, with a “severe” qualifier); his condition requires him to have an amount of light higher than the minimum foreseen by regulations to perform activities, especially those requiring precision, such as cutting vegetables, reading, etc.

When Basil decides to read in his living room, the system detects his presence within the room and automatically sets on the minimum illuminance to 350 lux (as described in Section 3.2.2); Basil can therefore select the amount of illuminance (up to 750 lux, which is his customized maximum value) according to his needs and to the activities he wants to perform, as shown in Figure 7.

Using DECAM, Basil can also save a specific illuminance setting and assign it a name, so that for the next iterations of the same activity he can set the indoor illuminance by just tapping the proper option. For instance, if Basil selects 688 lux as a comfortable amount of illuminance for reading, he can save this value and assign it the name Reading, so that the system will automatically deploy the setting whenever Basil taps on it.

4.2.3. Fostering Energy Saving Behaviors

Sarah, a 73-year-old woman who lives independently and practices gardening as hobby, is characterized by frailty; her condition encompasses a mild impairment related to memory functions (described with the ICF code b144.1) and a mild impairment in the activity related to carrying out the daily routine (described with the ICF Activity and participation code d230 as Carrying out daily routine, with a performance qualifier of 1). Although she is quite independent, sometimes she struggles in handling many appliances and this behavior sometimes results in leaving appliances turned on even when they are not necessary.

For instance, during the summer Sarah loves to take care of her plants on the balcony; she goes outside but she often forgets to turn the air-conditioning system off. Using DECAM, when Sarah’s presence is detected on the balcony and her absence from the rooms of the house is ascertained (i.e., presence sensors cannot detect Sarah within any of the rooms of the house) for more than 15 minutes and the air-conditioning system is left turned on, Sarah receives an alert via DECAM’s GUI indicating that the air-conditioning system has been turned off in order to save energy. Sarah can also decide whether to reactivate the air-conditioning system as soon as she reenters the house.

The same functionality works when Sarah forgets to turn off the light in one of the rooms she has left for more than 15 minutes. Clearly, this functionality does not work when kitchen appliances are on (the electric oven, refrigerator, freezer, microwave oven, and electric stove can run even if the user is located in a room different from the kitchen).

5. Conclusions and Further Works

This work introduces ComfOnt, a semantic knowledge base developed leveraging on widely adopted ontologies and aimed at representing some features of the Smart Home ecosystem, such as indoor comfort, devices (household appliances, sensors, and actuators), and energy consumption. In addition, ComfOnt allows the representation of the dwellers’ health conditions—reusing a standard classification—to foster the actuation of customized indoor comfort settings, enabled to help older inhabitants and/or inhabitants with impairments to live independently. The ontology is designed to allow the possibility of easily added new indoor comfort metrics to be taken into account for the description of specific environments. ComfOnt is adopted by a Java-developed prototypical application, the Domestic Environment Comfort and Appliances Manager (DECAM), which is designed to provide the dwellers with an intuitive GUI. The DECAM application also overcomes some of the limitations characterizing semantic reasoning in DL and enables the modification of parts of ComfOnt, while allowing the end users to manage their energy consumption and actuate comfort according to their desires. Thus, the novelty of ComfOnt relies on the possibility of a simple and effective modeling of comfort metrics within an SH (relying on widely adopted ontologies, like SAREF). Comfort metrics are then associated with the inhabitants, whose characterizations are based on their health conditions (also expressed recurring to a standard classification, ICF).

Future works foresee a set of activities aimed at enhancing the representation of domestic devices and their functionalities; as it is described, ComfOnt provides a generic description of household appliances, their energy consumption and times of use. However, ComfOnt needs to provide the possibility of modeling appliances’ specific programs, with a specific energy consumption for each of them; for instance, an electric oven may have more than one program, and to each of these programs a specific duration and energy consumption can be described. Moreover, monitoring the electric power consumption of some domestic appliances, such as the washing machine and dishwasher, has proved the fact that there are massive differences in electricity demands in different cycles of the same program. Modeling appliances’ temporal patterns (which can be modeled also taking advantage of the uncertain modeling techniques described in Section 2) in order to represent the differences in the energy demands of different devices requires DECAM to rely on an architecture that allows gathering data on real-time electric consumption of appliances. This can be done by implementing the invasive or noninvasive current sensing techniques [74,75]. DECAM foresees the implementation of a noninvasive energy meter on domestic appliances exploiting the Arduino microcontrollers equipped with the current transformer (CT), for measuring the current and converting it to voltage, and the Wi-Fi module, for serial to Wi-Fi data transmission. The process of exchanging the data over IoT gateways takes place the same way as the comfort sensors (explained in Section 4.1).

To complete the description of the inhabitants and better help them in managing energy consumption inside the SH, a future development regards the possibility of including a description of the activities dwellers can perform in their domestic environment; to this purpose, the works of Ni [12] and Knox [76] constitute a solid starting point. The possibility of describing activities can enable the recognition of users’ behaviors inside the house and trigger the automatic actuation of preferred indoor comfort metrics.

Moreover, in order to connect DECAM to real devices within an experimental context, ComfOnt must also provide the means for the semantic annotation of measurements performed by sensors; in this regard, there exist several approaches in literature that can be adopted [77,78,79].

With regard to its functionalities, DECAM’s money-saving functionality will be improved. This feature is considered a weekly organizer function, offering the inhabitants the possibility to suggest the best time slots in which each appliance can be used while producing a money saving (due to a more convenient cost of the energy).

Finally, the application’s design, its usability and acceptance by target users, i.e., inhabitants aged 65+ years old, will be tested in the following months using standard questionnaires such as the system usability scale (SUS) [80] and technology acceptance model (TAM) [81].