The SHMUC Repository
 

(Smart Home @ Massey Use Cases)

People have many ideas about how a smart home should react to particular behaviours from its inhabitant, but there seems to have been relatively little attempt to organise this in a systematic way. This website presents a set of Use Cases that enumerate six types of situation that a smart home with a particular focus on elder care might have to deal with.

Use Cases

Use Cases are a tool that is used in software engineering to help system designers explore the possible behaviour of an application. That's quite difficult because, although it's (comparatively) easy to design and implement individual system functions, it's much more difficult to set them up so that, in many different situations, and for many different users, they operate as a coherent unit. As designers, we tend to focus on a single general case,  and ignore special cases, and situations in which things go wrong, and users who don't have a good idea of how to use the system.

So to draw us away from our built-in technological focus, we set up realistic scenarios that correspond to the situations that real users might find themselves in, and write little stories about how users who found themselves in those situations would use the system. We personalise the participants (they're called actors, in the jargon of Use Cases) by giving them names (Debbie and Mary feature strongly in the Use Cases in this site), and try to describe the situations and write the stories without jargon, and without making any assumptions about the structure of the system. The goal is to get realistic human behaviour to drive the system design, rather than allow system design to drive human behaviour. Together, the scenario, the story, and the reflection about the implications this has for an application are called a Use Case - an exploration of how the system will be used in some specific case.  

The SHMUC Repository

The use cases present a small number of the types of abnormal behaviour that could be detected by a smart home. They identify the behaviour that causes the problem, some possible means for collecting smart home data (sensor readings in our case), and discuss the reasoning chain that leads to particular activities by the smart home, principally warning a carer. These cases have been selected to identify some of the context awareness and behaviour recognition that an intelligent smart home needs. We have identified some use cases and suggest that many in the smart home research community could identify others. We aim to stimulate discussion of the desired behaviours of a monitoring smart home, and to set up a canonical resource that other researchers can draw upon.

There are two other motivations for use cases in smart homes. One is that they can assist in the design process, and particularly in the choice of appropriate methodologies.

In the later use cases described in this paper, some of the requirements will be better met by logic-based algorithms, and others by probabilistic machine learning algorithms. Use cases allow researchers to make the choice from a principled standpoint.

The other motivation is that they can be used to benchmark different implementations: by testing any implementation on the use cases, informed evaluation of different systems can be made relatively quickly and easily.

 

Discussion

The limited set of use cases presented in this website explore a subset of required behaviours of a smart home. The list is not intended to be exhaustive, but to demonstrate, by example, that use cases can be a useful tool for uncovering those requirements. Although use cases aim at implementation-independence, they can clarify implementation choices - for example, choices between probabilistic methods, and techniques based on symbolic logic and reasoning.

These use cases are expected to inspire ideas for solving the following questions:

  1. what types of abnormal behaviour may occur in a smart home system?
  2. how does the system reason about inhabitants behaviour?
  3. how does it react to abnormal behaviour?
  4. what information should be involved in detection of abnormality?

We have discussed some of the common types of abnormality, and the use cases have clarified them. While the psychological definition of novelty that we reported earlier includes some types of abnormality that we have not used, some of those relate to biological injury; they are implicit in some of the use cases that we have presented. We believe that this classification can be used to ensure that all types of possible abnormality are defined in our use cases.

The discussion has identified some of the many ways that smart homes can reason about unusual behaviour. With regard to variation in duration and start time of an activity (i.e., the temporal properties of the data) we can use statistical properties based on prior observation, for example during a training phase. However, it is important that contextual data is used as well as information about the particular behaviour, and distinguishing the important factors is a very difficult problem in machine learning, which can lead to the curse of dimensionality since many unrelated factors may need to be considered. We suggest that it would be appropriate to combine statistical machine learning methods and logic, e.g., inductive logic programming [19]. For example, given a set of examples about going out, it can learn some rules with context awareness: Mary usually goes out around 1500 to 1530 at the weekend if she is not sick and it is not raining. Obviously, this allows learnt rules to be applied in detecting abnormality more accurately than the current studies that support abnormal start time detection. However, performance is one of the biggest challenges of this technique, which means that it is still a research focus for us.

For detecting abnormality in behaviour patterns, there are also many different approaches such as Hara et al. [13] with Markov models, and Jakkula and Cook [20] with temporal logic, etc. The above scenarios on abnormal presentation of behavioural patterns show that abnormality in patterns depends not only on the order of actions (and their temporal relation, which we have not presented use cases about here), but also on many other factors. We have followed the line of NAF (negation as failure i.e., unidentifiable patterns are abnormal). The system needs feedback to learn about failed cases that are in fact normal.

In addition, abnormal behaviour patterns are difficult to detect as they are unpredictable: an activity can be performed in many different ways, not all of them abnormal. For example, we have many ways to make a cup of tea, e.g., with or without milk, sugar, etc., or the actions of an activity can be performed in many different orders, e.g., milk before or after hot water, etc. As a result, current studies that detect abnormal patterns using NAF approach are limited, as they depend on complete coverage in the training data, which is at best unlikely to be available. A system that can generalise from examples may provide a way to deal with the limited training set.

It may be worth studying AI planning methods in conjunction with the ability to recognise goals. Once the system knows that the inhabitant is making a cup of tea, it can check to see how well the activities that are performed match a valid plan to achieve this goal.

The use cases presented here only express functional requirements. This is a limitation; non-functional aspects should be included when evaluating and comparing systems, such as their total cost of ownership. While it might be easier with a logic-based system to address many of the requirements discussed, such a system would require comprehensive and expensive initial setup work. On the other hand, logic-based systems might be easier to maintain as they offer users reflection and introspection facilities such as explanations (such as derivation logs) and configuration options (such as customising thresholds). A different non-functional aspect is scalability, as the ready availability of cheap sensors increases the amount of available sensor data dramatically.

We have presented a small number of case studies that describe some of the scenarios in which a smart home could (and should) work. These are a subset of the use cases that we have created for exploring behaviour recognition and the detection of novel behaviour based on temporal and spatial ordering and contextual data. By presenting them we hope to encourage other researchers in smart homes to consider use cases, so that researchers agree on the requirements, whether they focus on sensor development, psychology and sociology, or computer science. We do not expect that everybody will agree with our interpretation and expectation of the correct behaviour in all cases, and welcome feedback and discussion.