To support the design process of context acquisition systems it is useful to assess what steps are usually accomplished in this process. In particular it is important to identify at which point decisions are taken. Furthermore it is important to recognise how these decisions influence the process further. These observations lead to a description of the
design space. Based on this knowledge it becomes possible to create tools that provide advice and support in this process.
5.3.1 Design Steps and Decisions
The following steps reflect on the design process of a context acquisition device as done in a number of projects and also reported by other researchers. The steps outlined can also be regarded as method to build context acquisition systems. In Table 11 the method is summarised.
5.3.1.1 Method
The method outlined here provides a general overview on the central steps and design decisions made when designing context acquisition systems. Depending on domains further intermediate steps may be introduced or steps may be omitted because of pre- specified constraints.
Step 1. Identifying contexts that matter; checking whether or not context matters at all.
In a first step the usage of the application or the artefact that should become context- aware is analyzed. If it can be concluded from the following questions that the situation does not matter it is probably not worthwhile to use context.
A method for designing context acquisition systems Step Action
1 Identifying contexts that matter.
2 Determine variables that distinguish contexts selected.
3 Finding appropriate Sensors to cover all variables at minimum cost.
3a (optional) Building and assessing a prototypical sensing device. 4 Selecting recognition and abstraction technologies. 5 Specification of a context acquisition system.
6 Build applications.
• Is the application or artefact used in changing situations?
• Vary the expectations of the user towards the application or artefact with the situation?
• Is the human computer interaction pattern different in various situations? • Does the user’s interaction with the real world environment offer information
that is valuable to the application?
If it can be concluded that context may provide additional information all situations that matter are identified. For these situations the conditions of the informational, physical and social environment are identified. Real world situations that should be treated the same by the application, are grouped into one context that is named.
Step 2. Determine variables that distinguish contexts selected.
By considering possible real world situations that fall under a context variables that discriminate the context are identified. Such variables may be of informational, physical and social nature (e.g. time of day, location, number of messages, temperature, number of people in the vicinity, relationship with people near by, interaction with the device, etc.). For the minimal set of variables that make it possible to discriminate the selected context the values (e.g. ranges, sets) for variables are specified.
Step 3. Finding appropriate Sensors to cover all variables at minimum cost.
For the variables identified in step 2 possible sensors are identified. When considering sensors the following points are taken into account:
• accuracy of the sensor in relation to the variable
• the cost to provide the information (see for a cost assessment below)
The resulting selection of sensors should be done in a way that the sensors cover all variables with sufficient accuracy at a minimal cost. The selection of sensors at this stage is often done based on the experience of the developer or based on datasheets and lab environment tests of sensors.
Given the knowledge about the sensors to use and the side conditions for the context acquisitions system the physical layout can be specified.
Variant: Step 3a. Building and assessing a prototypical sensing device.
On common approach is also to create after step 3 a physical sensing device using the actual sensors and providing the raw data for analysis. This intermediate step has to be taken when there is little knowledge about the sensors in question or the contexts to recognise.
Based on the decision on sensors a prototypical sensing device, e.g. sensors attached to a board in a similar form factor as the actual device and connected to data storage on a standard computer is created. Here it is especially interesting to experiment with the positions of the sensors on the device. Then the sensing device is used in the situations that should be detected and data is recorded. In a next step the recorded data is analyzed (e.g. statistics, clustering) to identify whether the raw data differs significantly for the different situations or not. If the data differs not significantly different sensors have to be selected or even different contexts have to be identified or in some case it may turn out that it is not feasible to recognise the contexts at all.
Step 4. Selecting recognition and abstraction technologies.
Based on knowledge or on data recordings available a set of cues is identified that provides a reduction of the amount of data but does not decrease the knowledge about the context. Features and algorithms are chosen in a way that all variables can be calculated from the data that is obtained from the sensors selected.
In an optimal case algorithms are found that do not reduce the knowledge about the situation with regard to the variables of interest. In this step also side conditions, especially with regards to processing and bandwidth are taken into account.
Step 5. Specification of a context acquisition system
After all components, the physical design and the algorithms are assessed the overall architecture of the system is determined. In particular the question is a single sensing device used (e.g. often in mobile systems) or is a distributed collection of sensing devices used (common in embedded settings) has to be addressed. This also includes decisions on the distribution with respect to sensors as well as processing. This is mainly to determine the overall architecture of the system. A decision could be that the sensing device is integrated in the environment and the contexts recognised are communicated to a mobile device. Communication issues and how the sensing system is connected to potential context consumers (in a distributed setting) have to be defined, too. In this step also the decision how context is provided to the context consumer such a particular application is made, typically by specifying an API.
Step 6. Build applications.
When context information is available the final step is to build applications on top of the context-aware artefact and environments that make use of context.
5.3.1.2 Cost Function
When selecting sensors and algorithms the cost is a major issue. Cost in these terms depends much on the type of artefact or application (e.g. mobile, stationary) that is to be build, the anticipated usage scenarios, and the potential user group. The issues that are taken into account reflect the requirements discussed earlier in section 3.4. Specifically the restrictions on the overall design resulting from the sensors is a major point, as well as power consumption, robustness, reliability, social acceptance, and additional monetary cost.
A cost function is highly dependent on the side conditions that are given for a specific system. Depending on the issues that are important for a specific realization these cost factors have to be weighted according to their importance in the problem domain. However, for most sensors and algorithms it is possible to describe their relative cost in certain areas such as size, weight, and power consumption.
The knowledge accumulated in the building blocks, libraries, and in the method is also used to follow the orthogonal path of providing a rapid prototyping platform.