Smart environments powered by the Internet of Things aim at improving our daily lives by automatically tuning ambient parameters (e.g. temperature, interior light) and by achieving energy savings through self-managing cyber-physical systems. Commercial solutions, however, only permit setting simple target goals on those parameters and do not consider mediating con icting goals among di erent users and/or system administrators, and feature limited compatibility across di erent IoT verticals. In this article, we propose a declarative framework to represent smart environments, user-set goals and customisable mediation policies to reconcile contrasting goals encompassing multiple IoT systems. An open-source Prolog prototype of the framework is showcased over two lifelike motivating examples.
The Internet of Things (IoT) is continuously growing and becoming an
integrated part of our daily lives with a plethora of new di erent applications (e.g.
smart-environments, wearables, home appliances) [
Especially for those applications that include human goals in the
self-management loop of smart environments, the problem of reconciling contrasting goals
among di erent users emerges clearly [
Additionally, despite being deployable out-of-the-box by their nal users, existing commercial solutions show inherent limitations, mainly due to their proprietary nature. These limitations prevent them to be extended and from work across IoT verticals enabled by di erent vendors. They also make it di cult to develop policies to mediate between users and administrator objectives, i.e. set local and global goals. Factually, two di erent types of con ict can arise: User-user { Di erent users can set di erent goals on their desired state of the environment (e.g. on target temperature), User-admin { The System Administrator can set global objectives that must be met (e.g. on maximum energy consumption, on law constraints), which may con ict with the user-set goals.
Even after reconciling the previous types of con icts into one target state satisfying all set (user and/or global) goals, a nal con guration of the actuators involved must also be determined. Indeed, given a nal target state, we need to (a) determine the correct con guration for each actuator acting on that state, and (b) mediate between any con icting con gurations that a single actuator possibly receives.
In this article, we propose1 a declarative methodology to specify customisable
mediation policies for reconciling contrasting goals and actuator settings in smart
environments. The methodology can solve contrasting goals by reasoning on the
available IoT infrastructure and on (possibly contrasting) goals set by the users
and by system administrators. The novel contribution mainly consists of:
(1) a declarative framework to specify mediation policies for reconciling
contrasting (user and/or global) goals and actuator settings in smart environments,
(2) a Prolog prototype implementation of (1), Solomon, provisioned as a REST
service by relying on Logic Programming-as-a-Service (LPaaS ), recently
proposed by Calegari et al. [
Solomon tames the e ects of the aforementioned types of con ict by allowing to exibly specify ad-hoc mediation policies for distinct zones of a smartenvironment and possible con icting settings of target actuators. Such policies can resolve con icts (i ) among users' goals, (ii ) among users' and system administrator's goals, and (iii) on actuators con guration. Last, but not least, the declarative nature of Solomon makes it easy to write, maintain and extend arbitrary mediation policies encompassing multiple IoT verticals.
The rest of this article is organised as follows. After illustrating two
motivating examples (Sect. 2), we present our methodology for goal mediation and its
prototype (Sect. 3), showcasing them over the rst motivating example. The full
1 A work-in-progress and preliminary version of this study was presented in [
In this section, we illustrate two scenarios from smart environments to better highlight the need for reasoning solutions capable of mediating among contrasting goals and encompassing di erent IoT verticals. Both scenarios consider two main stakeholders: User { a human or digital agent that can set goals on the ambient around them, aiming at creating the most comfortable environment for them to live in, System Administrator { a human or digital agent that can de ne con ict resolution policies, and set global goals on the environment (e.g. on energy savings). Smart Home { Consider a shared room in a student apartment, equipped with three lights { the main light, a bed light and a corner light { and an A/C system. In this case, depending on the time of day and the activity that is taking place (e.g. studying, watching a lm, reading a book), di erent lighting con gurations could be required. Con icts might arise as, for instance, Alice may want to watch a movie while Bob is still studying in the same room. Moreover, Alice might prefer to stay in a cool room (20 C) while Bob prefers a warmer ambient (26 C). Natural questions raised by the above scenario are: { Is it possible to nd a con guration of the three lights which allows Alice and
Bob to comfortably carry on their di erent activities? { Is it possible to nd a con guration of the A/C system which mediates among the preferences of Bob and Alice on the environment temperature? Smart Building { Consider now the smart building oor sketched in Fig. 1, consisting of a West and an East wings. The West wing is exposed to light most of the day while the East wing is less illuminated.
In each wing, there are 5 rooms (4 single and one shared), the single rooms in pairs share the air conditioning system and the relative temperature sensor. Also, each room has a large light and a Fig. 1. An example of Smart Building desk light and a brightness sensor. The shared rooms have two large lights and their air conditioning system as well as a temperature sensor and a brightness sensor. Besides, the rst single room in the East wing ha a small heater.
Each user has been assigned a single room and has full access to shared rooms. Furthermore, targeting sustainability, company policies require that the temperature in the environment stays within 18 C and 22 C in autumn and winter, and between 24 C and 28 C in spring and summer. Also in these settings, some questions arise such as: Q1 How to describe the available Smart Building so that it is possible to apply ad-hoc policies for the West and East wings? Q2 How to specify policies to manage temperature and brightness in the di erent rooms of the building, handling con icts so as to ensure the comfort of its inhabitants and to meet sustainability policies? Q3 After nding a target state for a speci c room, how to determine suitable settings of the available (shared and non-shared) actuators to reach it? All questions raised above highlight the need for novel models and methodologies to exibly manage smart environments, such as the one we propose in this article. In the next section, we will detail our proposal by relying on the Smart Home example. The Smart Building example will be used instead in Sect. 4 to assess the methodology over a larger scale scenario. 3
In this section, we illustrate Solomon, a declarative framework featuring autonomic goal mediation in smart environments, in presence of multiple users. Solomon is prototyped and open-sourced2 in Prolog, using LPaaS . Hereinafter, we give an overview of the architecture we foresee for Solomon to be deployed (Sect. 3.1), and we detail the model (Sect. 3.2) and methodology (Sect. 3.3) underlying our framework. 3.1
2 Open-sourced and freely available at: https://github.com/di-unipi-socc/Solomon goals and solve user-admin con icts, and to determine actuator con gurations useful to reach a target state for the smart environment, after goal mediation. Note that Solomon is provisioned as a service, enabled by an LPaaS engine, which allows (i ) to easily integrate it with other pieces of software such as user interfaces (UIs) or mobile applications and (ii ) to deploy it either to Cloud or Edge servers, depending on the usage context. 3.2
Smart Environment. To model smart environments, we rst build up a dictionary of all types of environmental parameters we can monitor (via sensors) and/or act upon (via actuators). We call property types the elements in such a dictionary, assuming they are declared as in propertyType(TypeId). where TypeId is a literal value denoting the unique property type identi er. Given a propertyType we can then de ne actuators and sensors that sense or operate on that.
Actuators are declared as in actuator(ActuatorId, TypeId). where ActuatorId is the unique actuator identi er and TypeId the associated property type.
Analogously, sensors are declared as in: where SensorId is the unique sensor identi er and TypeId is the associated property type. Environmental values monitored by each sensor are denoted by sensor(SensorId, TypeId). sensorValue(SensorId, Value). where SensorId identi es the sensor and Value is the last value it read. Example. Based on the above, the shared room of the Smart Home example of Sect. 2 can be declared as in propertyType(light). propertyType(temp). sensor(brightness, light). sensorValue(brightness, 20). sensor(temperature, temp). sensorValue(temperature, 22). actuator(smallLight, light). actuator(mainLight, light). actuator(cornerLight, light). actuator(ac, temp). where two sensors measure two di erent property types (i.e. temperature and brightness), having three lamps that can act on brightness and the AC system capable of changing the temperature. Please note that the current temperature settles at 22 C and the brightness at 20 out of 255.
System administrators can divide smart environments into di erent zones, which allow distinguishing which global policy to apply to speci c sets of sensors and actuators: zone(ZoneId, MediationPolicy). where ZoneId is the unique zone identi er and MediationPolicy is the unique identi er of the global management policy the zone is subject to. A zone groups one or more property instances, de ning a set of actuators and a set of sensors that operate on a speci c property type. A property instance is declared as in propertyInstance(ZId, PIId, TypeId, Actuators, Sensors). where ZId identi es the zone to which the instance belongs, PIId is the property instance identi er, TypeId is the propertyType of PIId, Actuators is a list of actuators that operate on the property and Sensors is a list of sensors that monitor it within the zone. All actuators and sensors in a given property instance must have the same property type. The identi er of a property instance is unique only within the zone, allowing for distinct zones to have instances with the same identi er.
Example. The property instances of the Smart Home example can be described by declaring a single livingroom zone and, for instance, four property instances as in zone(livingroom, _). propertyInstance(livingroom, studyingLight, light, [cornerLight, mainLight], [brightness]). propertyInstance(livingroom, movieLight, light, [cornerLight, smallLight], [brightness]). propertyInstance(livingroom, readingLight, light, [smallLight], [brightness]). propertyInstance(livingroom, roomTemp, temp, [ac], [temperature]).
It is worth noting that the rst three property instances all refer to the light property, grouping the brightness sensor with the lamps needed to realise different settings on such property, e.g. for studying (cornerLight and mainLight), watching a movie (cornerLight and smallLight), or reading a book (smallLight only). The last property instance refers instead to the temp property, grouping to the temperature sensor and the A/C system (i.e. ac).
Users and Goals. A user is declared as in user(UserId, AllowedZones). where UserId is the unique user identi er and AllowedZones is the list of the zones on which the user can set goals. User goals are declared as in set(UId, ZId, PIId, Value). where UId is the user identi er, ZId identi es a zone, PIId is one of the property instances of the zone, and Value is the goal expressed by the user on the property instance.
Example. Still following the Smart Home scenario, Alice and Bob, and their goals on brightness and temperature are represented as per user(alice, [livingroom]). set(alice, livingroom, movieLight, 20). set(alice, livingroom, roomTemp, 20).
user(bob, [livingroom]). set(bob, livingroom, studyingLight, 80).
set(bob, livingroom, roomTemp, 26).
Alice aims at setting the movieLight property instance to 20 out of 255 and the roomTemp to 20 C. Bob, on the contrary, wants to set the studyingLight property instance to 80 out of 255, and the roomTemp to 26 C. 3.3
The model described up to now denotes the inputs that Solomon receives from the smart environment it manages as well as from its users. Fig. 3 lists the core code of Solomon, which works in three main steps that constitute the top-down methodology of the proposed framework to determine a target state for a smart environment. Those steps are as follows: 1. it collects all user requests 3 that are currently submitted to the system (getRequests/2, line 2) and extracts only those that are valid, 2. it mediates requests referring to the same property instance by applying the mediation policies speci ed by the system administrator, so to determine a target state for each property instance (mediateRequests/2, line 3) by solving all user-user and user-admin con icts, 3. it nally determines actions (i.e. settings) for individual IoT actuators so to achieve the target state, by also resolving possible con icting actions found for a single actuator (associateActions/2, line 4). 1 react(Requests, MediatedRequests, Actions) :2 getRequests(Requests, ValidRequests), 3 mediateRequests(ValidRequests, MediatedRequests), validMediation(MediatedRequests), 4 associateActions(MediatedRequests, Actions), validActions(Actions). 5 getRequests(Requests, ValidRequests) :6 findall((ZId, PIId, Value, UId), set(UId, ZId, PIId, Value), Requests), 7 findall( (ZId, PIId, Value, UId), 8 ( member((ZId, PIId, Value, UId), Requests), user(UId, Zones), member(ZId ,Zones), 9 validRequest(ZId, PIId, Value) ), ValidRequests). 10 validMediation(Reqs) :11 sort(Reqs, OrderedReqs), 12 \+( ( member((Z,PI,V1), OrderedReqs), member((Z,PI,V2), OrderedReqs), dif(V1,V2) ) ), 13 \+( ( member((Z,PI,V), OrderedReqs), \+( validRequest(Z,PI,V) ) ) ). 14 validActions(Actions) :15 sort(Actions, OrderedActions), 16 \+( ( member((A,V1), OrderedActions), member((A,V2), OrderedActions), dif(V1,V2) ) ), 17 \+( ( member((A,V), OrderedActions), \+( validValue(A,V) ) ) ).
Overall, the react/3 predicate (line 1) returns three lists: the list of all Requests, the list of MediatedRequests containing the target states for each property instance and the list of Actions to perform to reach a nal target state. It is worth noting that, while the framework leaves complete exibility to the system administrators in de ning their own mediation policies, it also checks that inputs and outputs of each phase are well-formed (through predicates validMediation/1, line 3, and validActions/1, line 4). This guides the system administrators in their task of writing (formally) valid mediation policies. 3 findall(Template, Goal, Result) nds all successful solutions of Goal and collects the corresponding instantiations of Template in the list Result. If Goal has no solutions then Result is instantiated to the empty list.
Collecting Requests. First, Solomon collects all the requests through getRequests/2 (line 2, lines 5{9), which determines two lists of tuples (ZId, PIId, Value, UId), where each tuple corresponds to a set(UId, ZId, PIId, Value) with arguments rearranged for easier handling in later stages. The rst list Requests contains all current requests from users (line 6). The second one, ValidRequests, only contains valid requests (line 7{9), i.e. by default4, requests for which the zone and the property instance exist, and the zone is among those the user associated with the request can set goals on.
Example. In the Smart Home scenario, querying ?- getRequests(Requests, ValidRequests). returns the following: Requests = ValidRequests, ValidRequests = [(livingroom, movieLight, 20, alice), (livingroom, studyingLight, 80, bob), (livingroom, roomTemp, 20, alice), (livingroom, roomTemp, 26, bob)]. collecting all requests from Alice and Bob.
Mediating Requests. Valid requests are then passed to the mediateRequest/3 predicate (line 3) which can be exibly and freely speci ed by the system administrator. The objective of this phase is to mediate between the possible con icting goals of the users by determining one target value for each property instance. The mediateRequests/2 predicate outputs a list, MediatedRequests, of such values for each property instance, in the form of triples (ZoneId, PropertyInstanceId, Value). Then, the validMediation/1 predicate (lines 3, 10{13) checks that the list contains no duplicates (line 12) and that all requests are still valid after mediation (line 13).
Example. In our Smart Home scenario, a possible mediateRequests/2 that simply averages user requests for a same property instance is as follows: mediateRequests(Requests, Mediated) :groupPerPI(Requests, NewRequests), mediateRequest(NewRequests, Mediated). mediateRequest([],[]). mediateRequest([(Z,PI,Rs)|Reqs], [Mediated|OtherMedReqs]) :mediatePI(Z,PI,Rs,Mediated), mediateRequest(Reqs, OtherMedReqs). mediatePI(Z, PI, Ls, (Z, PI, Avg)) :
findall(V, member((V,_),Ls), Values), avg(Values,Avg).
Input Requests are rst grouped per property instance by groupPerPI/2, which returns a list of triples (Z,PI,Rs) where Z and PI identify a property instance and Rs is the list of requests that target it. By recursively scanning such list, mediateRequest/2 exploits mediatePI/4 to average all requests grouped for each property instance.
By querying mediateRequests/4, we obtain 4 System administrators can easily extend the concept of valid request by including further checks based on domain-speci c knowledge, e.g. on the range of allowed values for a given property. This can be done by extending the validRequest/3 predicate exploited by getRequests/2 (line 9).
Mediated = [(livingroom,movieLight,20), (livingroom,roomTemp,23), (livingroom,studyingLight,80)]. which represents a target state where movieLight and studyingLight are set to 20 and 80 respectively, and roomTemp to 23 C, i.e. the average of Bob and Alice's goals.
Determining Actions. After obtaining a target state for each property instance, Solomon generates a list of actions for available actuators to reach such a target. An action is a pair (AId, Value) where AId is the identi er of an actuator and Value is the value it needs to be set to. The associatedActions/2 predicate (line 4) inputs a list of mediated requests and returns a list of actions, according to System Administrator policies.
The validActions/1 predicate (lines 4, 14{17) checks whether there are no duplicate settings (line 16) and that obtained values are valid according to System Administrator policies (line 17), which can check if the con guration for an actuator can factually be implemented, using validValue/2.
Example. A simple policy that computes the setting for each actuator by dividing the target value of a propertyInstance by the number of its actuators, is speci ed as in associateActions(Requests, ExecutableActions) :actionsFor(Requests, Actions), setActuators(Actions, ExecutableActions). actionsFor([],[]). actionsFor([(Z, PI, V)|Reqs], Actions) :propertyInstance(Z, PI, _, Actuators, _), selectActionsForPI(Z, PI, V, Actuators, _, Actions1), actionsFor(Reqs, Actions2), append(Actions1, Actions2, Actions). selectActionsForPI(_, _, V, Actuators, _, Actions) :
length(Actuators, L),triggerAll(V, L, Actuators, Actions). triggerAll(_, _, [], []). triggerAll(V, L, [A|Actuators], [(A,VNew)|Actions]) :
VNew is V/L, triggerAll(V, L, Actuators, Actions). setActuators(Actions, ExecutableActions) :
setActuatorsWithMax(Actions, 0, 100, ExecutableActions).
First, for each input requests, a triple (Zone, PropertyInstance, TargetValue), actionsFor/2 gets the list of actuators of that speci c propertyInstance. Then, it selectActionsForPI/6 computes the list of actions to be performed by dividing the target value for each propertyInstance by the number of its actuators. Note that when an actuator belongs to more than one propertyInstances, setActuators/2 selects the highest value available cutting that value with a lower bound of 0 and an upper bound of 100.
By querying associateActions/2 in the Smart Home scenario, given the target state of the previous example, we obtain: ?- associateActions(Mediated, Actions).
Actions = [(ac, 23), (cornerLight, 40), (mainLight, 40), (smallLight, 10)] Note that the ac actuator is set to 23 C, i.e. the value of the target state. As for movieLight and studyingLight, being composed of several actuators, a further mediation happens. The target value of 20 for movieLight is split across cornerLight and smallLight, setting each to 10. Analogously, the target value of 80 for the studyingLight is split across mainLight and cornerLight, setting each to 40. The con ict on cornerLight, being in both property instances, is solved by picking the maximum between 10 and 40, viz. 40. 4
In this section, we exploit Solomon to answer the questions raised about the Smart Building scenario of Sect. 2. The answer to Q1 is obtained by specifying di erent zone(ZoneId, MediationPolicy) facts for the rooms in the smart building (Fig. 1), as in zone(room_E_1, east). zone(room_E_3, east). zone(commonRoom_E, east).
zone(room_W_1, west). zone(room_E_2, east). zone(room_W_3, west). zone(room_E_4, east).
zone(commonRoom_W, west).
zone(room_W_2, west). zone(room_W_4, west).
The east and west literals identify two di erent mediation policies, speci ed by System Administrator , to be applied to the property instances grouped under the zone. Such grouping can be obtained by specifying suitable propertyInstance(ZId, PIId, TypeId, Actuators, Sensors) facts as, for instance, in propertyInstance(room_E_1,roomTemp,temp,[acOdd_E,heater],[tempOdd_E]). propertyInstance(room_E_1,roomLight,light,[biglightRoom_E_1,smalllightRoom_E_1], [lightRoom_E_1]). propertyInstance(room_E_3,roomTemp,temp,[acOdd_E],[tempOdd_E]). propertyInstance(room_E_3,roomLight,light,[biglightRoom_E_3,smalllightRoom_E_3],[lightRoom_E_3]). that describes the sensors and actuators available in the Room 1 and Room 3 of the East wing. Note that the two rooms share the acOdd E actuator for the A/C system and that Room 1 contains the heater actuator that is not available in Room 3.
Based on the knowledge representation above, we can now answer Q2 by suitable implementations of mediateRequests/2. Indeed, the System Administrator can easily declare mediation policies to solve user-user and user-admin con icts in a context-aware manner. Such behaviour can be obtained through predicate mediatePI/4 (which is used by mediateRequests/2 as illustrated in Sect. 3) : mediatePI(Z, PI, Ls, (Z, PI, Avg)) :findall(V, member((V,_),Ls), Values), avg(Values,AvgTmp), zone(Z, MediationPolicy), propertyInstance(Z, PI, Prop, _, [Sensor]), sensorValue(Sensor, SensedValue), findValue(Policy, Prop, SensedValue, AvgTmp, Avg).
First mediatePI/4 averages all user requests for a speci c propertyInstance so to mediate possible user-user con icts. Then, it exploit findValue/4 to mediate between the obtained average with the global policy enforce by the System Administrator . Such mediation is based on the MediationPolicy of the wing (i.e. east, west), on the property type Prop (i.e. light, temp) on the value obtained by the sensor of that instance (i.e. SensedValue) and on the computed average value AvgTmp.
Fig. 4 lists the code of predicate findValue/4. The rst clause of findValue/4 (lines 1{4), manages the temperature in both wings in the same way. After determining the current season (line 2), it enforces that the target value is within the season-dependent ranges speci ed for sustainability purposes (line 3{4), viz. 18{22 C in Winter and Autumn and 28{24 C in Summer and Spring. The second and the third clauses of findValue/4 (lines 5{6 and 7{9) manage instead the environmental brightness, depending on the wing of the room, on the current brightness and the weather. This process determines a mediated target state that reconciles all user-user and user-admin con icts on each property instance, which fully answers Q2.
Finally, the answer to Q3 is achieved through the implementation of the associateActions/2 predicate. In our Smart Building, the policy we chose to adopt consists of dividing the workload equally between the various actuators, with the only exception of the heater that only accepts two values, viz. 0 or 100. The code is similar to the one proposed in the previous section for the Smart Home, in which the selectActionsForPI/6 is adapted to the new policy and in case of multiple requests to the same actuator, now the maximum value is chosen. selectActionsForPI(_, _, V, Actuators, _, Actions):
length(Actuators, L),triggerAll(V, L, Actuators, Actions). triggerAll(_, _, [], []). triggerAll(V, L, [A|Actuators], [(A,VNew)|Actions]):dif(A, heater),
VNew is V/L, triggerAll(V, L, Actuators, Actions). triggerAll(V, L, [heater|Actuators], [(heater,100)|Actions]):
V > 0, triggerAll(V, L, Actuators, Actions). triggerAll(V, L, [heater|Actuators], [(heater,0)|Actions]):
V =< 0, triggerAll(V, L, Actuators, Actions). setActuators(Actions, ExecutableActions) :
setActuatorsWithMin(Actions, -inf,inf, ExecutableActions).
First selectActionsForPI/6 computes the number L of actuators of the propertyInstance, then triggerAll/4 is called which distributes the workload to the actuators with the exception of the heater. Finally, setActuators choose the maximum in case of multiple sets for a speci c actuator (with no lower or upper bound). With this process we can determine the correct con guration for each actuator acting on that state, and mediate between any con icting con gurations that a single actuator possibly receives, answering to Q3.
We conclude this section by describing a use case for the scenario above exploiting the policies described. Suppose that it is a sunny day in winter, with the brightness value sensed in the West common room at 160 out of 255, and user u1 sets the brightness of her room to 0 and the temperature to 18 C. On the contrary, user 3 sets the temperature at 28 . Assume that the two rooms share the A/C system but not the lighting system. Meanwhile, user u4 sets the temperature and brightness of room2, which she is not authorised to handle. Finally, users u2 and u8 are both in the commonRoom E with the same goal for the light but di erent goals for the temperature (respectively 23 C and 18 C). season(winter). user(u1, [room_E_1,commonRoom_E,commonRoom_W]). user(u3, [room_E_3,commonRoom_E,commonRoom_W]). user(u8, [room_W_4,commonRoom_E,commonRoom_W]). set(u1, room_E_1, roomLight, 0). set(u1, room_E_1, roomTemp, 18). set(u3, room_E_3, roomTemp, 28). set(u4, room_E_2, roomLight, 0). set(u4, room_E_2, roomTemp, 18). sensorValue(lightCommonRoom_W, 160). user(u2, [room_E_2,commonRoom_E,commonRoom_W]). user(u4, [room_E_4,commonRoom_E,commonRoom_W]). set(u2, commonRoom_W, commonRoomLight, 255). set(u2, commonRoom_W, commonRoomTemp, 23). set(u8, commonRoom_W, commonRoomLight, 255). set(u8, commonRoom_W, commonRoomTemp, 18).
For each room the result of the mediation phase with the application of global policies described before is: [(room_E_1,roomLight,100), (room_E_1,roomTemp,18), (room_E_3,roomTemp,22), (commonRoom_W,commonRoomLight,255), (commonRoom_W,commonRoomTemp,20.5)] where roomLight of room E 1 is bounded on 100 because it is the minimum bound for the light in the East wing, while the roomTemp is within the bounds. Meanwhile, roomTemp of room E 3 is bounded to 22 the maximum temperature allowed in winter. Instead in commonRoom W the temperature is the average of the two requests because it is within the boundaries and also the light because we are in the West wing and it is sunny (brightness > 100) so the maximum bound is 255, the goal of both users. Finally, the goals of user u4 are ignored because is not authorised to interact with room E 2. Then, the actions to be carried out, given the states computed, will be: [(acCommonRoom_W, 20.5), (biglightCommonRoom_W_1, 127.5),(biglightCommonRoom_W_2, 127.5), (acOdd_E, 22), (heater, 100), (biglightRoom_E_1, 50), (smalllightRoom_E_1, 50)] where the temperature of commonRoom W is managed only by acCommonRoom W and the light is implemented by two main light which equally divide the goal. Meanwhile, acOdd E is the air conditioning system shared by room 1 and 3 and is setted to the maximum of the two goals (18 and 22) and also in room E 1 the heater is working. Finally, the small and big light work together to implement the goal.
In this section, we discuss some closely related work on the self-management of
smart environments. Most of these works fall within three main categories, viz.
goal-oriented [
First, [
Second, hierarchical solutions for goal mediation have been proposed by [
Third, and last, fuzzy logic [
This article proposed a declarative framework { and its Prolog prototype Solomon{ to specify policies for mediating contrasting (user and/or global) goals and actuator settings in smart environments. The prototype is provisioned as a service through LPaaS , and it can resolve user-user and user-admin con icts into a target state for the smart environment with actuator settings.
The wide variety of smart environments and the desiderata of their users and system administrators calls for new frameworks to easily develop and continuously adapt domain-speci c mediation policies. This work moves some rst steps towards this direction, aiming at contributing a novel declarative approach, enabled by LPaaS , to the eld of goal-driven management of smart environments. As showcased in our example, thanks to its declarative nature, Solomon features a suitable level of abstraction and exibility to accommodate di erent needs of smart environments, making it easy to express, maintain and update mediation policies as per the ever-changing needs of IoT scenarios.
In our future work, we intend to: { New Policies and Data. Implement other mediation policies (e.g. based on fuzzy logic, learning or heuristics), by also proposing a set of building blocks that System Administrators can use to compose their own policies, and by enabling users' geolocalisation to predict movements and preferences. { Answer Set Programming. Extend Solomon's API to support Answer Set
Programming (ASP) as in [