Target Scenario: Ambient Assisted Living

Remote monitoring: Remote monitoring services and health related interventions are strongly personalized to specific individuals’ requirements, preferences, abilities and motivations, which can radically differ among the older persons, and even dynamically evolve over time for the same person depending on changing user needs and context-dependent conditions.

Establishment of rule: A caregiver (or even an older adult) can set up a rule that better monitors what the older adults do during the night, or whether their expected physical and/or cognitive exercises are performed during the day.

A rule can switch on a light for a specific interval of time so that the bedroom-bathroom path can be better illuminated when motion is detected during the night. Another example is a rule that changes the light’s colour according to the current user’s emotional status since lights can play an important role in the older adult’s mood.

Remote analysis: In addition, in such contexts, caregivers can benefit from a rule monitoring tool that allows them to understand which kind of rules have been triggered in a specific period, to better understand the automations that have more frequently executed during the older adults’ daily life. For instance, high use of reminders can be interpreted as a sign that the older adult is increasingly relying on external support to remind the various activities to carry out, which might need further investigation in some cases.

Target Scenario: Smart Home

Customized automation: Great variety of activities occur in the domestic environment and people’s interactions with the devices and objects available in the household. This emphasizes on the need to support the easy customization and personalization by end users. An example of customized automation is creating a rule that notifies parents when children are back home from school and activates the external surveillance system in the house.

Another rule could check gas leaks in the kitchen, and in such case, an alarm can be directed to alert inhabitants currently at home (as well as other people that can provide help), and at the same time activates the automatic opening of the kitchen’s windows. In this case, a rule monitoring tool can be useful to better understand the kinds of automations that the family members are most interested in, i.e. whether they regard controlling the equipment at home, or whether they involve triggers more related to inhabitants’ safety (e.g. presence of smoke or gas) or health (heart rate, time spent in the bathroom).

Learn more about TAREME Platform

Show less

There is also a Monitoring module which aims to provide support for analysing the use of the personalization platform, by showing relevant information to users interested in it (e.g. in Ambient Assisted Living scenarios they can be caregivers or platform managers). For gathering the relevant information, the Monitoring module receives data from the Rule Manager concerning the rules, their state and when they have been executed. This module is a key added value because it allows relevant stakeholders to focus on the personalization that has actually been put in place by users, thereby of actual interest for them. Applications can be integrated with the platform in order to: receive actions (which were included in relevant rules) indicating requests of modifications to make, and/or send events generated by the application itself (in this case the application acts as a Context Delegate, by sending the information associated with the occurred event(s) to the Context Server).

Show less

“User id” specifies the name of the user who is currently using the Tailoring Environment. This information is important to correctly associate the rules created through the Tailoring Environment with the correct user;

“Context Manager URL” specifies the URL of the specific instance of the Context Server used. This information is essential to identify the triggers that the Tailoring Environment has to show, which depend on the considered context;

“Rule Manager URL” specifies the URL of the Rule Manager. This information is key to understand the URL to which to send the verified rules for their execution.

“Application Set” specifies the name of the application(s) considered. This information is important to identify the actions that can be executed.

The Tailoring Environment also supports the explicit distinction between events and conditions when specifying the trigger. This distinction was introduced considering previous user studies, which have shown that EUD environments sometimes confuse end users concerning the difference between these two concepts. Thus, by introducing the explicit distinction, one can better stimulate users in thinking about their difference. In addition, the top part of the central panel of the Tailoring Environment provides feedback in natural language of the created rule, to express the specified behavior in a more immediately understandable manner.

Moreover, it is possible to define rules that are triggered if an event does not occur in a specific interval of time (e.g. When the medicine has not been taken between 10 a.m. and 11 a.m.), which were found useful in some scenarios. This has been supported thanks to the introduction of the NOT operator associated with an event in the proposed tool, differently from other solutions that do not support it (e.g. IFTTT). Another useful feature of the rule language used is the possibility to define rules that are triggered when a specific ordered sequence of events occurs (e.g. “If the user enters inside a room and then he exits”; or “When the temperature becomes more than 20 degrees and then the humidity level becomes more than 50%”), or when an event occurs a specified number of times (event iteration), e.g. “If the user goes to the bathroom 5 times during the night”.

Learn more about the Panel of the Tailoring Environment

Show less

More specifically, the description of the types that such contextual entities can assume, and the hierarchical structure in which they are organised are represented in a context meta-model specified in an XSD format. When the Context Server is compiled, this XSD file is automatically translated into a set of Java classes, and various instances of Java objects are created to define the state of the elements composing the current context (e.g. the various instances of users, environment and technologies). In order to update such Java objects, the Context Server provides just one RESTful service to receive the data from the various Context Delegates which, using this REST service will be able to update the various attributes of the context. The input parameters of this service aimed to update the information received from the Context Delegates are: i) the id of the corresponding context dimension; ii) the xPath value indicating where the context attribute to update is located within the context model structure; iii) the new value gathered from the sensor.

For example, the trigger representing the event “user has fallen” is defined in the context model as an attribute of the “User” dimension called “layingDown”, and it assumes a Boolean value: this trigger is defined under the following hierarchy: “user -> physical -> laying down”. To update the layingDown attribute, the context delegate sends three parameters to the REST service: the user id, the xPath of the attribute to update (in this case “user / physical / @ layingDown”) and the current value of the attribute (in this case “true”). The advantage of this single-service solution is in terms of platform evolvability. Indeed, when there is the need of updating the context meta-model (because of a new context element type, or an existing context element type has been changed, or removed), it is sufficient to modify the XSD definition of the context metamodel, since the REST service above mentioned can still be used without requiring any further changes.

This is because: i) the JAVA classes that are expected to manage the values of the attributes of the updated context are automatically generated when compiling the Context Server; ii) the above-mentioned RESTful service will still be able to support changing the values received for the newly generated context element(s). For instance, suppose that there is the need to introduce a new attribute providing information about user movements (i.e. “isMoving”), and this attribute needs to be added under the “user/physical” xPath hierarchy (namely: “user / physical / @isMoving”). In this case, while the XSD describing the structure of the context needs to be modified, there is no need to create a new, ad-hoc service to receive and update values of this newly introduced attribute, because the RESTful service described before can still be used to change the value of the concerned “isMoving” attribute.

This is realised through the JAVA reflection mechanism (namely: the capability of an executing Java program to examine upon itself, i.e. obtain the names of all the fields or methods of a JAVA class), which makes it possible to automatically derive, within a Java program, the name of the method to call (by using the information included in the parameters mentioned above), and consequently update it. This type of solution is modular and evolvable because it can easily manage the flexible introduction of various sets of sensors and applications, according to the specific needs to address, in a dynamic manner.

Show less

The information about triggered rules can represent valuable data to understand what is currently and actually going on in one or more end-user sites, to identify the personalization aspects which users are focusing on most, the types of routines they have put in place and the frequency with which such automations occur.

Indeed, users of the Tailoring Environment could create/add several rules in their repositories over time. Thus, some rules may appear in the repository, but they are not currently exploited because the users did not want to have them active at the time. In general, the information about the triggered or active rules provides data that have been of actual interest for their users. The monitoring tool can also provide more detailed information, such as how many times a specific rule has been triggered.

This value is highly dependent on the purpose of each particular rule. In the following, we will better detail the information provided by the Monitoring Tool, which displays various types of structured information. Therefore, to facilitate its description, the project team schematized its layout as structured into four main parts. The content of such four parts are further detailed in the following four sections.

Learn more about the layout of the Monitoring Tool and the platform configuration

Show less

Despite some promising results derived from usability studies involving EUD tools, it became soon clear that even providing users with usable EUD tools, without proper support, they may easily define rules triggering actions that are in conflict, or not resulting in the intended behaviour. Therefore, the developed solution supports end-user debugging the simulation of the context in which trigger-action rules are expected to be executed. In particular, the platform supports functionalities not only for simulating rules but also for ‘debugging’ them by providing conflict resolution support as well as interactive explanations.

Considering the increasing availability of humanoid robots in various domains of everyday life the platform enables those who are not programming experts to personalize robot behaviour according to contextual information detected by both the robot and the available IoT objects and sensors available in a specific context, and in this way to link the robot behaviour to what happens around it.

Learn more about the TAREME platform

Show less