The pervasiveness in daily environments of objects equipped with sensors and actuators and characterized by the possibility of communicating over the Internet has steadily increased in recent years. In this scenario, smart home automations are becoming increasingly adopted. It is hence important to provide users with explainable tools to better control these automations and make them more useful for their needs. We present a novel mobile augmented reality solution to support users in creating and controlling automations through recommendations and a simulation tool. We also discuss the application of an augmented reality XAI framework to the presented solution in order to improve its transparency.
In automation-based environments it is possible to have several automations active at the same time
with a resulting behaviour different from the expected one. In this case, explainability strategies should
be put in place to identify potential problems, and help in finding possible solutions, involving users in
this process. A key point is how people can receive useful information and help in identifying possible
mismatches between desired and actual behaviour. A way to reduce the likelihood of errors in the
specification of automations is to allow users to simulate the conditions and events that can trigger an
automation and the effects that they will bring about. The detection of the problems and the fixing of
their cause can be quite problematic for end users especially because, as noted by [
2023 Copyright for this paper by its authors.
In particular, this paper presents two main contributions. The first is the introduction of the ARACS
(Augmented Reality Automation Creation and Simulation) platform [
The proposed platform is an Android application developed in Unity using ARFoundation1, a library that enables the development of multi-platform AR apps interfacing with the platform's native AR SDK such as ARCore, ARKit, and OpenXR. The application exploits the camera of the mobile phone to capture the user’s environment, and place visualization over the physical objects available in the current context which functionalities can be used to define automations. The main functionalities of the application are “Create automation” and “Explore environment”. The first allows users to personalise the environment with automation rules involving objects and services while moving about in their spaces.
The configuration of the automation (see Figure 1) is performed in a situated and dynamic way: at the start of the application, a visualisation is placed over the objects that can be used in the automations (Figure 1, Left). Selecting one of these visualisations, a panel describing the functionality that can be used as a trigger or action is shown (Figure 1, Centre-left). After the configuration, the visualisation over the object changes indicating its use in the current automation through a bright colour and a particle effect (Figure 1, Centre-right). Also, panels with recommendations for triggers and actions related to the inserted configuration are placed over the other objects (Figure 1, Right). The user can then continue the visit, moving to the next object she wants to use in the automation and configuring it, repeating this process until the automation is completed. Supporting information can be presented on request, for instance showing the partial automation configuration done at the current moment. The “Explore environment” functionality is used to make the relation between the automations and the real objects more transparent and perceivable. When using this functionality, natural language descriptions of the rules defined by the user are displayed over the corresponding objects.
The platform provides two types of intelligent support. The first is rule elements recommendations.
In the context of EUD for smart home configuration, recommendations should help users to define the
joint behaviours of the IoT devices and services. Hence, the system should present users with
1 https://unity.com/unity/features/arfoundation, last accessed 2023/05/21.
recommendations during the configuration of these behaviours, providing diverse options to complete
them. The adopted approach is to generate personalised recommendations starting from a dataset2 of
automation rules. The recommender system matches the user representation and what she is currently
defining (the recommendation context, represented using a binary vector where each trigger or action
functionality used in the rule is assigned a 1, and those not present a 0) with the automations in the
dataset, also leveraging the similarity between the natural language transcription of the context and the
textual parts of automations defined by other users. The textual similarity match is performed using a
large language model, BERT [
The second type, which is currently under development, is a rule simulation and debugger. The rule
simulation is an extension of the “Explore environment” functionality, to consider and visualise also
the state of the environment (the context). It will allow loading the current context or some predefined
context snapshots (for instance, summer morning, weekday night, dinner with friends), and visualising
the associated values over the various object in the environment. The users can modify these contextual
values (for instance, changing the time, or acting on the temperature) to check whether some automation
will or will not activate in the environment, providing them a “Why/Why not” [
In the following, the XAIR framework, its key factors, and the steps to assess them will be introduced. Then, an application of the framework to the ARACS platform will be analysed to determine how to present AR explanations in two use-case scenarios. 3.1.
We based the design of the augmented reality explanations on the XAIR design framework [15]. XAIR aims to support the design of effective XAI experiences for AR, addressing the key concepts needed to provide explanations of AI output. The framework is the result of an analysis of the literature, a largescale end-user survey, and workshop iterations with designers and experts in relevant fields. It is based on a definition of the problem space (“When”, “What”, and “How” to explain) and the assessment of the key factors needed to determine the answers to these questions.
The design space is structured as follows. On the “When” dimension, the two main aspects are the availability of the explanation (whether the explanation should be always ready or not) and the delivery (when to show it). Since the availability should always be ready to improve user experience, the decisions are about the delivery timing. An explanation can be automatically presented or shown when requested by the user, and both approaches can be valid depending on the use case. The second dimension is the “What”. It articulates in content and detail level. About the content, seven types of explainable content were identified: input/output details (such as data sources), why/why not (model features or logic that had let or not to an outcome), how (overviews of the algorithm or model provided 2 https://github.com/andrematt/trigger_action_rules, last accessed 2023/05/21. e.g. with a graph or text), certainly (e.g., the confidence score), example (for instance, similar inputs that lead to same output), what if (demonstrations of the effects of changing the input), and how to (explaining how to change the input to obtain an output), delivered possibly via local explanation. Concerning the detail, the priority is to provide explanations that expand users’ prior knowledge or fulfil their immediate needs, also considering the cognitive capability available and the possibility of presenting personalized and detailed information. About the “How” dimension, the identified levels are the modality (visual and audio emerge as the most suited) and the paradigm, where the larger design space concerns the visual modality. The design aspects to consider in the visual modality are the format (textual and graphical, eventually combined) and the pattern type (implicit, explicit). Implicit pattern refers to naturally blending the additional information with the referring object, for instance directly highlighting an anomaly with a circle or an arrow over it, while explicit refers for instance to an extended dialogue window.
The second part of the framework consists of the steps to assess the key factors concerning the defined dimensions. For the “When” dimension, the decision is about when to present the autotriggered explanation (by default, the explanation should be on-demand). The first necessary condition is that the user has enough cognitive capability and time to engage with the explanation. The second is that at least one of the conditions is true among 1) there is a mismatch between the user expectation and the received recommendation, hence, the user is surprised or confused; 2) the user is not familiar with the output of the system; and 3) the system is uncertain of the output. Concerning the “What”, the explanations should be contextualised considering the user goal (depending on what the user is doing, a type of explanation can be more useful than another), the system goal (for instance, a recommendation can be shown to calibrate the system to the user taste, to propose alternatives, to help manage errors, or to improve trust in the system), and the user profile (in particular the AI literacy). Regarding the detail level, by default explanations should be short and focused on the why aspect, with the possibility of providing more details upon user request. For the “How” part, the modality should normally be the same as the outcome of the AI process, but for specific situations (e.g., when the used channel is overloaded) an alternative one should be used. Concerning the paradigm of visual explanations, textual should be the main explanation format, and a simple graphic such as icons could provide additional information. More advanced graphics (such as heatmaps) could be used in detailed explanations. About the pattern, when possible the explanation should be implicit (blended with the real environment), while the explicit possibility represents the backup solution. 3.2.
The first scenario involves the rule recommendation functionality of the ARACS platform. The user wants to automate the morning air circulation in the living room. She configures the time the automation should activate, and then the living room window opening action. After these operations, the recommendation “if (condition) the humidity level of the room is more than 70%” is placed in a panel over the multipurpose sensor in the living room, indicating that the humidity check functionality can be used together with windows automatic opening and time checks. The user is surprised since she was thinking about temperature or weather-related recommendations, but not humidity.
Following the XAIR framework, the first dimension to assess is the “When”. Since the user is currently defining the automation, we can assume that she has enough cognitive capability and time to eventually engage with explanations. Then, an assessment is performed to establish whether there is enough uncertainty (in the user or in the system) for targeting the explanation. In this scenario, different possibly confusing situations can verify. For instance, the user can receive a suggestion whose main goal is different from her intended goal for that automation, e.g., security instead of energy saving, or concerning a service she had never used before. In this case, the condition for automatically presenting an explanation is true because she has never used the “humidity level” trigger. Indeed she's surprised because she was not even aware that the sensor had that feature. Concerning the “What” part, the first assessment is about the System goal, which is user intent discovery (suggesting a user with new automation possibilities that she may find useful and be unaware of). The main user goal is to resolve the surprise since she received an unexpected recommendation. The last assessment is about the user AI literacy, which we know from the user profile to be low. Hence, the framework’s suggested explanation types for the intersection of the various parameters are Input/Output and Why/Why-not explanations. Concerning the detail level, the interface can show the why as default (for instance, with a text explaining that humidity checks are often used to automate the air circulation), and the Input/Output can be shown as additional information. Concerning the “How”, the modality of the explanation is visual, using text as a default. The detailed explanation can show the information that impacted the decision to recommend this automation part (e.g., which part of the incomplete automation inserted by the user had more weight for proposing the recommendation, or which aspect of the user profile), or how the recommendation changes when some parameter is modified (for instance, the automation goal, or using a default user instead of the current one). The pattern can be explicit (text panels), with some implicit components, for instance highlighting with a bright colour the objects with positive impact for a specific recommendation. 3.3.
The second scenario concern using the environment simulator/rule debugger to better understand the smart environment behaviour and eventually help the user to solve logical errors in the configured automations. In this scenario, the user has configured the smart coffee maker to brew a coffee at the time she wakes up, at 6:30 AM. In the morning, she finds out that the machine is on, but no coffee has been brewed. To debug the situation, she loads the most similar environment predefined conditions, namely the “night weekday” preset. Once loaded, the augmented representations over the various object changes, indicating the simulated values. This scenario starts at 11 PM. She then modifies the “time” contextual value to “fast forward” the environment’s state near her wake-up time. Reaching 6:30 AM, she notices that the description of the coffee brewer automation is placed over the related machine, but the panel is opaque, indicating a rule not in execution. At the same time, a dotted red connection line appears between the visualization and another panel placed over the smart plug to which it is connected. The panel over the plug is instead bright, indicating a rule currently in execution, which function is to deactivate that plug at night time, between 12 AM and 7 AM, and it is hence preventing the coffee automation to start.
The definition of explanations with respect to the framework starts with the “When” aspect. In this scenario the user is actively using the simulator to better understand what causes or prevents the activation of automations and possibly clarify her confusion, hence explanations are automatically triggered. For the “What” part, the main system goal, in this case, is error management since the simulator aims to help users to better collaborate with the system and to calibrate their expectations of the system’s capability and functioning. From the intersection of the related table in the framework, the most suited explanation types are Input/Output, Why/Why-not, How, and Certainty. Concerning the detail level, priority should be given to a concise explanation of the why (in this case, making clear that the smart plug automation is preventing the coffee maker). Further details and explanation types can be provided on request, for instance, by giving concrete examples of contexts in which the specific automation can be activated. Concerning the “How” part, the modality is visual, using a mix of implicit (the red dotted line connecting the objects) and explicit (the opaque or bright panels with textual explanation) patterns.
In this paper, we introduce ARACS, an AR platform to define IoT automations with recommendation support. The platform provides users with dynamic suggestions on how to complete the automation they are editing based on the specific user, context, and textual representation of the context. The platform will include a simulator to allow users to load context snapshots and simulate the execution of the rules and the effects between them. We then introduce XAIR, a framework that aggregates the main XAI factors from the literature and allows for a systematic definition of the When, What, and How of an AI explanation. Finally, we discuss how the intelligence aspects in the ARACS platform (recommender system and automations simulator) could be made explainable by applying the XAIR framework.
For future work, we plan to refine the application's simulation part and introduce further features.
An example can be the automatic evolution of the context snapshots, for instance, based on predictions
from stored context data and knowledge of the environment [
This work has been supported by the PRIN 2017 “EMPATHY: Empowering People in Dealing with Internet of Things Ecosystems”, https://www.empathy-project.eu/.
[15] Xu, Xuhai, Anna Yu, Tanya R. Jonker, Kashyap Todi, Feiyu Lu, Xun Qian, João Marcelo Evangelista Belo et al. "XAIR: A Framework of Explainable AI in Augmented Reality." In Proceedings of the 2023 CHI Conference on Human Factors in Computing Systems, pp. 1-30. 2023. [16] Yusuf, Imam Nur Bani, Lingxiao Jiang, and David Lo. "Accurate generation of trigger-action programs with domain-adapted sequence-to-sequence learning." In Proceedings of the 30th IEEE/ACM International Conference on Program Comprehension, pp. 99-110. 2022. [17] Zhang, Lefan, Weijia He, Jesse Martinez, Noah Brackenbury, Shan Lu, and Blase Ur. "AutoTap: Synthesizing and repairing trigger-action programs using LTL properties." In 2019 IEEE/ACM 41st international conference on software engineering (ICSE), pp. 281-291. IEEE, 2019.