Assistive technologies need to constantly adapt and react to user needs. To this end, ambient intelligence techniques could be adopted. One approach consists of defining suitable rules to trigger actions or suggestions to the users. In this paper, ATML (Ambient intelligence Trigger Markup Language), a novel suitable language, is presented and described. ATML is aimed at defining and describing actions and rules in the field of ambient intelligence and context-awareness. To show how useful ATML is, we briefly introduce its current implementation in BackHome, an EU project concerning physical and social autonomy of people with disabilities.
Today’s appliances have successfully become integrated to such an extent that we use them without consciously thinking about them. Computing devices have transitioned in this past half a century from big mainframes to small chips that can be embedded in a variety of places ranging from communication appliances (e.g. mobile phones) to simple applications (e.g. weather sensors). In this setting, various industries have silently distribute computing devices all around us, often without us even noticing, both in public spaces and in our more private surroundings with small amounts of intelligence providing them autonomy to perform small-scale decisions to modify the environment.
The advances in the miniaturization of electronics allow purchasing sensors,
actuators and processing units at very affordable prices [
These elements are to be coordinated by intelligent systems that integrate the
available resources to provide an intelligent environment. This confluence of topics has led
to the introduction of the area of Ambient Intelligence (AmI) that is defined as a digital
environment that proactively, but sensibly, supports people in their daily lives [
Networks, sensors, human-computer interfaces, pervasive computing and artificial intelligence are all relevant but none of them conceptually fully cover AmI. It is, though, AmI which brings all these together to provide flexible and intelligent services to users acting in their environments. Indeed, AmI relies in the application of artificial intelligence techniques to provide added value services to the end-users.
Ambient Assisted Living (AAL) fosters the provision of these intelligent
environments for the independent or more autonomous living of people with disabilities, via the
seamless integration of info-communication technologies in homes and residences [
Among other application fields, let us recall here the importance that AmI takes on personalized assistance of people with disabilities and the improvement of AT to their impairments and needs. In particular, AmI helps monitoring the context features and behaviour and facilitates the control on environmental appliances (e.g. lights, windows). Those systems combine all the above features with the understanding of situations in which to perform actions pro-actively, such as triggering emergency alarms (e.g. fire, gas leak).
In order to adapt the AT and to react properly to the different situations that a user
may need, several AmI techniques should be developed. One approach can be the use of
rules which should trigger actions, or suggestions to the user, in order to react properly
to the situation. To fulfill the need to express these rules we present, in this paper,
a suitable language called ATML (Ambient intelligence Trigger Markup Language).
Based on RuleML [
As a practical demonstration of the usefulness of ATML, we present its current implementation in BackHome1, an EU project concerning physical and social autonomy of people with disabilities, by using mainly Brain-Neural Computer Interfaces (BNCIs) and integrating other assistive technologies as well.
The paper is organized as follows: Section 2 briefly introduces AmI. Section 3 discusses the representation of rules and actions in the field of AmI. Section 4 presents the proposed language and its fundamentals. Section 5 illustrates the benefits of ATML in BackHome through an example of usage. Section 6 ends the paper with conclusions. 2
According to Augusto and McCullagh [
According to [
Several artefacts and items in a house can be enriched with sensors to gather information about their use and in some cases even to act independently without human intervention. Some examples of such devices are white goods (e.g., oven and fridge), household items (e.g., taps, bed and sofa) and temperature handling devices (e.g., air conditioning and radiators). Applying AmI in this scenario may: (a) increase safety (e.g., by monitoring lifestyle patterns or the latest activities and providing assistance when a possibly harmful situation is developing) and/or (b) improve comfort (e.g., by adjusting temperature automatically).
In addition, AmI allows the home itself to take decisions regarding its state and
interactions with its residents. There are several physical smart homes that have been
designed with this theme in mind. For instance, the MavHome project treats an
environment as an intelligent agent, which perceives it using sensors and acts on the
environment using powerline controllers [
Being implemented in real-world environments, AmI involves problems such as
incompleteness and uncertainty of the information available about the user and the
environment. In fact, we generally deal with information that might be in some way correct, in
somewhere incorrect, and in some part missing. Thus, an elaborated reasoning process
that deals with those information drawbacks might be performed to successfully define
an accurate knowledge representation. To this end, AmI relies on the context as a model
of the current situation of the user and its immediate environment [
In order to use context effectively, we must understand what context is and how it can be used. A precise notion of context is essential in an intelligent environment, even more in assistive applications since an understanding of how context can be used helps application designers to determine the context-aware behaviours necessary to support in their applications. Nevertheless, the context is not a static but a dynamic concept composed of entities like people, devices, locations or even computing applications which, in their turn, are characterized by attributes. Once these concepts are properly integrated into the design, the system is entitled to take the necessary actions according to different combinations of these entities using different techniques such as rules or analysis of this information provided by the context.
The process of understanding the context is not explicit and thus not trivial; it
depends on previous knowledge. Experience provides means to classify and highlight
specific situations and to relate them with the received stimuli of the sensory system. It
is supposed that same situations are promoted by the same stimulus, and those
implications resultant from those situations serve as an extension on the recall of experience
[
Current implementations of AmI in the field of SmartHome and ATs are focused on
providing modifiable assistance according to the user context, the so-called
personalized assistance. The more frequent implementations are based on machine learning
algorithms and intelligence systems. Nevertheless, this is not the only possible approach:
there exist systems based on the use of rule based engines that determine the actions
to be triggered by the system. Some examples can be find at the literature, for instance
Acampora and Loia [
On the other side, the platform DOAPAmI [
As we have already commented in the previous section, some applications use rules engines to define the actions to be triggered in several situations. Although, these rules can be defined in several ways, frequently are platform dependent and not based on standards. In order to establish a platform-independent and flexible definition of these rules, and to specify conditions and actions to be triggered (hereinafter, triggers), we propose to use a human readable XML-based language called AmI Triggering Markup Language (ATML). This approach allows exporting the rules definitions to any AmI system and reaching the same status on the configuration of the intelligence.
ATML is compliant with the RuleML. In fact, most of ATML definition relies on the RuleML definitions. RuleML is an initiative part of the research community’s effort to develop the Semantic Web. RuleML is, at its heart, an XML syntax for rule knowledge representation that is interoperable among major commercial rule systems. RuleML is based on a fundamental rule knowledge representation, declarative logic programs, which expressively extend ordinary logic programs with features for prioritized conflict handling and procedural attachments to perform actions and queries.
Let us consider an example of trigger definition: <Trigger> <name>Activate Managed Ambience</name> <Properties> <occurrence>Continuous</occurrence> <enabled>true</enabled> </Properties> <Implies>
. . .
</Implies> </Trigger>
As you can see, a trigger in ATML is firstly described by its name, in order to distinguish it from the overall set of triggers. This is very helpful for both user and designers to perform the import/export operations as rules can be easily identifiable. After assigning the name, the set of properties has to be defined. Properties incorporate different attributes helping to understand how to interact with the rule. As an example, let us consider an occurrence property that provides the time frame in which the rule needs to be evaluated. In the code of the example reported above, we can also find the enabled property that indicates to the system if that rule is active and we have to check and react, if needed.
After these two sections the rules define the implications of the action. That section includes two main sub-sections: head and body: <Implies> <head> <TriggerAction> <op> <rel>open</rel> </op> <who>trigger</who> <device>CUR_DD_001</device> </TriggerAction> </head> <body> <And> <Atom> <op> <rel>greater than</rel> </op> <var>TEMP_ENV_001</var> <value>28</value> </Atom> <Atom> <op><rel>lower or equal than</rel></op> <var>TEMP_HVAC_001</var> <value>23</value> </Atom> </And> </body> </Implies>
Head is used to define the actions (TriggerAction) to be executed whenever the condition of the rule is met. Every TriggerAction is defined by a single action to be performed when a given condition (defined in the body section) is met. To define a TriggerAction, three different tags are necessary: – op, which indicates the command to be performed on the target, in the example the op indicates that the value of the variable T EMP ENV 001 must be greater than 28; – who, describing which system performs the operation (in the example the trigger engine defined by the identifier trigger); – device, which defines the targeted appliance (in the example, the device with identifier CUR DD 001). – body, which expresses the condition of the rule by means of comparison and logic operation. The rule defined in the example contains two conditions, the first one related with the value of the variable T EMP ENV 001 and the second one with the value of T EMP HVAC 001.
A single comparison operation, called atom, includes an operand, namely equal, not equal, greater than, lower than and contains. To concatenate and combine different atoms, the three classical logic operands (and, or, and not) are allowed. It is remarkable to say that logic operations are allowed to be nested, that is, a logic operation may contain inner logic operands. 5
ATML is currently used in the BackHome project. The project BackHome, an
European initiative funded by the FP7 program, is willing to play a role in empowering the
end-users to become more autonomous and independent in their activities of daily life
by means of a novel concept in ATs. BackHome is about boosting physical and
social autonomy of people with disabilities taking a broad approach and is aimed at
supporting the transition from institutional care to home, post rehabilitation and discharge
[
Suitable AmI features are provided in BackHome. In particular, the sensor-based TMHSS is aimed at acquiring contextual information through data coming from sources of different nature: BNCI system that allows monitoring ElectroEncephalo-Gram (EEG), ElectroOculoGram (EOG), and ElectroMyoGram (EMG); wearable, physiological, and biometric sensors, such as ElectroCardioGram (ECG), heart-rate sensor, respirationrate sensor, Galvanic Skin Response (GSR) sensor, EMG switches, and inertial sensors (e.g., accelerometer, gyrocompass, and magnetometer); environmental sensors (e.g., temperature and humidity sensors); SmartHome devices (e.g., wheelchairs, lights, TVs, doors, windows and shutters); devices that allow interaction activities (e.g., a desktop PC); as well as devices to perform rehabilitation tasks (e.g., a robot).
As part of the design of BackHome, it was mandatory to devise a knowledge representation of the context which needs to be captured, and stored, from the sources presented in the previous list. The outcome of the context formalization is depicted in Figure 1 in which the different values of the environment together with parameters of the user (e.g. fatigue) are presented. This definition of the context incorporates different categories taken into account when evaluating the context: 1. Time Variables: representing the current moment taking place. 2. Environmental Variables: these variables refer to those measures that give direct information of the context such as luminosity or motion. 3. User Variables: providing information about physiological measurements (e.g. fatigue and spasticity). 4. Device Variables: these are the variables referred to the status of the devices controlled by the AmI-enabled system.
BackHome takes advantage of AmI to provide advanced assistance through two
main assistive services based on AmI: Personalized Adaptation and Proactive
Performance. The Personalized Adaptation is an approach based on the user’s preferences and
habits. This method learns the habits from the user applying machine learning
techniques in order to infer the behavioral patterns of the system. Currently, it includes
the proposals of the BrainAble [
In the current implementation of the BackHome project, some proactive context-trigger actions have been designed and developed. Context-Trigger actions are clear examples of the proactive nature of AmI: whenever a rule condition is met the corresponding action is triggered.
These rules, expressed in ATML, are configurable by the end-user with a dedicated interface (see Figure 2), which facilitates the creation of the rules which are stored in a separated file. As such, the rules can be defined as portable across different AmIenabled systems. As an example, let us consider the next piece of code that presents a rule expressed in ATML:
As discussed in Section 4, first, the name is defined and then the required properties (e.g., occurrence and enabled). The rule itself is defined under the tag Implies and is divided in two sections, head and body. The head contains the different actions (called TriggerAction) to be made once the condition of the body is met. Each TriggerAction defines who executes the action, on which device it is performed, and under the tag op/rel the command to execute is specified. In this case, the trigger will execute open on the device CUR DD 001, and PowerOn on HVAC DD 001. The condition of the trigger is defined in the body section, where different logic operands called Atom are linked by logic operations, And, Or and Neg. The Atom contains the variable, the value, and like with the actions, under the tag op/rel the operand to them.
As a result, the rule of the example opens the curtains and turns on the air conditioning when the condition of evaluating the environment is met. The specific condition evaluated for this rule is based on the measure of the environmental temperature, the target temperature of the HVAC and the presence of someone in the surroundings. 6
The latest progress in three domains, i.e., microelectronics, communication and networking technologies, as well as intelligent agents and user interfaces has given rise to the idea of ambient intelligence. It provides added value services by combining the features of the different appliances creating smart environments. This paper presents a novel markup language called Ambient intelligence Triggering MarkUp Language (ATML). This new language, based on RuleML, is aimed at describing in a flexible and scalable way all the possible situations where an AmI system can react to fit the needs and preferences of the users in different situations. In order to validate the design of the ATML and the robustness of the concept it was incorporated to the BackHome project, an European-funded FP7 project, aimed at creating assisting environments for people with severe impairments. It is an ongoing project where the services and devices to be included are growing and changing with the evolution of the project and it will be a real test of ATML. Also, the users tests (technicians or not) will be a valuable input that will help to improve the definition and will be presented in the next steps of the project.
The research leading to these results has received funding from the European Communitys, Seventh Framework Programme FP7/2007-2013, BackHome project grant agreement n. 288566. 25. Streitz, N.: From human computer interaction to human?environment interaction: Ambient intelligence and the disappearing computer. In: C. Stephanidis, M. Pieper (eds.) Universal Access in Ambient Intelligence Environments, Lecture Notes in Computer Science, vol. 4397, pp. 3–13. Springer Berlin Heidelberg (2007) 26. Vargiu, E., Ferna´ndez, J.M., Miralles, F.: Context-aware based quality of life telemonitoring. In: Distributed Systems and Applications of Information Filtering and Retrieval. DART 2012: Revised and Invited Papers. C. Lai, A. Giuliani and G. Semeraro (eds.) (inpress) 27. Vargiu, E., Ferna´ndez, J.M., Torrellas, S., Dauwalder, S., Sola`, M., Miralles, F.: A sensorbased telemonitoring and home support system to improve quality of life through bnci. In: 12th European AAATE Conference (2013) 28. Vargiu, E., Miralles, F., Martin, S., Markey, D.: BackHome: Assisting and telemonitoring people with disabilities. In: RAatE 2012 - Recent Advances in Assistive Technology & Engineering (2012) 29. Weiser, M.: Some computer science issues in ubiquitous computing. Commun. ACM 36(7), 75–84 (1993) 30. Youngblood, G.M., Cook, D.J., Holder, L.B.: A learning architecture for automating the intelligent environment. In: Proceedings of the 17th conference on Innovative applications of artificial intelligence - Volume 3, IAAI’05, pp. 1576–1581. AAAI Press (2005) 31. Zadeh, L.A.: Fuzzy sets. Information and control 8(3), 338–353 (1965)