Contract Delivery Date Actual Delivery Date Deliverable Type

(1)

Document Title Document Version

D1.1 Requirements Specification 1.2

Project Number Project Acronym Project Title

FP7-2011-7-287661 GAMBAS Generic Adaptive Middleware for Behavior-driven Autonomous Services

Contract Delivery Date Actual Delivery Date Deliverable Type Deliverable Access

M4 May 31st, 2012 R (Report) PU (Public)

Document Author or Reviewer Organization Work Package

Marcus Handte UDE WP1

Wolfgang Apolinarski UDE WP1

Umer Iqbal UDE WP1

Josiane Xavier Parreira NUIG WP1

Danh Le Phuoc NUIG WP1

Gerd Kortuem OU WP1

Wolfgang Barth SC WP1

Abstract

This document describes the requirements on the overall system to be developed by the GAMBAS project as well as the individual subsystems. The requirements described hereinafter have been gathered as part of an initial analysis of the targeted application prototypes. To simplify their realization, the requirements have been categorized into five different groups as follows:

 General Requirements (GE): high-level requirements on the overall integrated system,  Adaptive Data Acquisition Requirements (AA): requirements on data acquisition,

 Automated Privacy Preservation Requirements (PP): requirements on privacy preservation,  Data Representation and Query Processing Requirements (DQ): requirements on data

models and the associated query execution,

 Intent-aware User Interface Requirements (UI): requirements on the user interface.

(2)

0.2 UDE Added state of the art and gaps concerning privacy.

0.3 UDE Added state of the art and gaps concerning data acquisition.

0.4 UDE Created structure for remaining sections, updated abstract, reordered bibliography and, added introduction as well as document structure description.

0.5 UDE Added state of the art and gaps regarding overall project.

0.6 NUIG Added stated of the art and gaps concerning data representation and query processing. Proofread sections 1 to 4.

0.7 SC Added state of the art and gaps concerning sound and speech recognition.

0.8 OU Added state of the art and gaps concerning intent-aware user interfaces. 0.9 UDE Modified document to include references on Volere and the IEEE

template document.

1.0 UDE Added requirements exported from the Volere web tool provided by ETRA.

1.1 UDE Minor formatting improvements.

(3)

1 Introduction

With the advent of powerful Internet-connected objects such as smart phones, personal digital assistants and tablet computers, an ever increasing number of European citizens have constant access to the wealth of information stored on the millions of servers connected via the Internet. At the present time, the availability of such connected objects is causing a drastic paradigm shift in the way people deal with information. Instead of collecting – and printing – potentially relevant information in advance using a personal computer that is only available at particular locations, they now access more and more information on-demand and on-the-go.

Yet, despite this significant change in behavior, the technical means to access information have only changed marginally. In most cases, information is accessed via the web which requires users to memorize long URLs, click through sequences of web pages or browse through irrelevant search results. Alternatively, if they are frequently accessing the same service, they may install an app or application that provides more convenient access. However, such an installation requires advance planning and does not provide suitable support for services that are primarily useful in a particular environment. Moreover, even if they are using a local proxy, the utilization of a more complex service, for example, to book a train ticket, requires users to specify numerous inputs such as destination, time, etc. using miniaturized and often, inadequate peripherals. As a consequence, the state-of-the-art puts a natural limit on the complexity of the software and thus, on the level of support, that can be gained from existing services.

In contrast to this, ubiquitous computing envisions services which provide seamless and distraction-free support for simple and complex everyday tasks of their users. In order to realize this vision, the set of services that is available and the services themselves must adapt to the user’s situation, behavior and to varying user intents. Thereby, this adaptation must be performed autonomously in order to ensure that it does not conflict with the goal of providing a distraction-free user experience. This, in turn, requires services to gather a broad range of characteristics of the user's context at runtime. Examples for these characteristics include the user's location, activity, plans and goals.

Internet-connected objects such as smart mobile phones and personal digital assistants provide a promising basis for determining user context in an automated manner on a large scale. The reasons for this are manifold. First and foremost, many Internet-connected objects are self-contained and do not require additional infrastructure support, but existing cellular and wireless local area networks can provide the backbone for object-to-object interaction if needed. Secondly, though these objects are often resource-constrained, newer generations are designed to support more complex tasks such as displaying a high-resolution movie. As a consequence, the objects are often not utilized to their fullest capacity, leaving enough resources to perform context recognition. Thirdly, with a variety of on-board sensor, many Internet-connected objects have access to both physical and virtual data sources which allows multi-modal context recognition with high precision. Lastly, since the objects are often carried by and owned by a single user continuously, the object’s context is tightly correlated to the user's context and the recognition alone does not invade privacy.

(6)

detecting desired characteristics, they cover only a narrow set that can be detected by one object alone. Moreover, due to the resource-constrained nature of many Internet-connected objects, developers have usually concentrated on providing solutions for a concrete service.

The vision of ubiquitous computing, however, extends beyond the boundaries of a single service as it envisions seamless support for everyday tasks. As a consequence, achieving the overall vision of ubiquitous computing raises a number of novel research challenges which include:

- the development of concepts to support the automated recognition of a broad range of context information types to support a variety of application scenarios in a generic fashion, - the development of context recognition methods that are able to cope to the limited

resource availability and energy-constraints of resource-poor connected objects,

- the development of novel data acquisition and distribution protocols to share context information in order to increase the recognition accuracy without endangering privacy, - the definition of an interoperable data representation model for context information and

associated query models to support object to object communication,

- the design of a scalable data infrastructure to share and aggregate possibly frequently changing context information gathered by a large number of connected objects,

- the development of tools to reduce the required amount of manual configuration of policies and the mechanisms to validate them in order to protect the privacy of users,

- the design of new context-based human computer interaction techniques that are able to incorporate user goals and intents.

1.1 Objectives

GAMBAS is geared towards addressing the complete set of challenges listed in the previous section in order to provide a truly integrated solution, thereby closing a significant gap between today’s systems and the vision of ubiquitous computing. Towards this end, the primary result of the project is the realization of a Generic Adaptive Middleware, i.e. a set of application-independent services, to support the development and utilization of Behavior-driven Autonomous Services.

The GAMBAS middleware will enable the development of novel applications and Internet-based services that utilize context information in order to adapt to the behavior of the user autonomously. To do this, the middleware will provide the means to gather context in a generic, yet resource-efficient manner and it will support the privacy-preserving sharing of the acquired data. Thereby, it will apply interoperable data representations which support scalable processing of data gathered from a large number of Internet-connected objects. In order to make the resulting novel services accessible to the user, the middleware will also support intent-aware interaction by providing a constant stream of relevant recommendations for services.

(7)

privacy policies which ensures that the user’s privacy expectations are met to improve the user experience and to increase user acceptance.

In order to validate the project’s results in a realistic environment, the GAMBAS consortium will develop a prototype application that builds upon the concepts and mechanisms provided by the middleware and the associated tools. In particular, the GAMBAS prototype application will be developed for the public transportation domain since it is truly ubiquitous and it exhibits all challenges described previously. Furthermore, robust working solutions in this domain exhibit a high potential to achieve a significant impact.

Thus, in summary, the GAMBAS project has the following scientific and technical objectives:

1. Development of a generic adaptive middleware for behavior-driven autonomous services that encompasses:

a. Models and infrastructures to support the interoperable representation and scalable processing of context.

b. Frameworks and methods to support the generic yet resource-efficient multi-modal recognition of context.

c. Protocols and tools to derive, generalize, and enforce user-specific privacy-policies. d. Techniques and concepts to optimize the interaction with behavior-driven services. 2. Validation of the middleware and its components using lab tests and a prototype application

in the public transportation domain.

1.2 Purpose

As a requirements specification, this document describes the results of the requirement elicitation for the GAMBAS project performed as one of the activities of the first work package. Thereby, it acts as a main deliverable of the work package. Apart from that, this document provides the key starting point for the research and development activities of the GAMBAS project by identifying requirements for the work packages two to five. Naturally, these requirements may not be static but they may evolve to some extend over the course of a European research project, especially, when it lasts for several years.

Yet, having a clearly communicated and commonly shared understanding of the goals at the very beginning of the project is an invaluable tool for ensuring that the final results are satisfactory and achievable within time and budget. Furthermore, the specified requirements can also be used as a measurement tool to track the overall progress of the individual activities. Finally, the successful and joint execution of a complex process such as a requirement elicitation, whose results are documented in this specification, demonstrates the consent of the whole project consortium on the scope and goals of the individual project parts.

The intended audiences for this document are primarily the GAMBAS stake-holders as well as the GAMBAS research and development teams of the consortium. However, as a public document this requirements specification will be freely available for other interested parties as well.

1.3 Scope

(8)

taken during the individual revisions. The detailed requirements include the clear description of the project drivers, identification of the functional and non-functional requirements, and realization of the project constraints. Thus, this document may be used as a point of reference for evaluating and tracking the progress of the project in later phases. This document, however, is not intended to describe the implementation details such as user interface of the systems.

Moreover, this requirement specification document does not include use cases and application scenarios. These are described within a separate document developed simultaneously within the first work package of the project. However, the separation of use-case specification and requirements specification does not mean that they have been created in isolation. Naturally, important modifications to the use-cases are reflected appropriately in the requirement specification by updating the derived requirements. Furthermore, the requirements described in this document will provide a valuable input for the use case analysis in order to identify application prototypes that demonstrate the important aspects of the software infrastructure.

It must be noted that the requirement specification describes all requirements that have been gathered in WP1 at the beginning of the project. Thus, it may contain requirements that may not be implemented due to time or budget constraints later on. To ensure that the important requirements are covered by the later specifications and implementations, the consortium has jointly assigned priorities to the requirements. These priorities group the requirements into three classes: high, medium and low. If it is not possible to realize all requirements, the project consortium will relax or drop low priority requirements before medium priority requirements and medium priority requirements before high priority requirements. However, the project consortium has already committed to implement all high priority requirements and the majority of the medium priority requirements.

1.4 Methodology

Gathering the requirements from all stake-holders in a project is a key success factor. The requirements not only describe different aspects of a project but they also help to identify conflicting features in early stages. For such an important step – that identifies and affects the overall outcome of the project – it is worth investing considerable efforts and utilizing proper tools. Considering this, we have chosen the Volere methodology [VOLE12] for describing and managing requirements which we have extended with a consecutive prioritization phase. In the following, we discuss the rationale for using Volere and we describe the classification categories and the process.

1.4.1 Elicitation

The Volere methodology is not new to the project partners. It was first used by a number of the project partners in EMMA and PECES projects where it was used mainly because of its simplicity. It helped project partners to describe, formalize and track the project requirements in an explicit and unambiguous manner. Besides being a success in the EMMA and PECES projects, the Volere methodology was selected for the following three reasons:

1. The Volere methodology requires simple steps to identify and formalize the requirements in an unambiguous manner.

(9)

3. A number of the project partners have already experience with the Volere methodology. Hence, they did not experience an extra learning effort.

The consequent application of the Volere methodology is not only useful in the initial phases of the project for specifying requirements but it is also helpful in specifying a reference point for the later stages. During the use case analysis, for example, it can be used to ensure that different use cases cover different aspects of the requirements and that all important requirements are covered by them. During the implementation and management, it can be used to track and evaluate the progress of the individual work packages and the overall project. Besides being efficient and easy to use, the Volere methodology provides a mechanism for all partners to specify the requirements in a standard format. Thereby, specifying additional context of a requirement such as the rationale and the acceptance criteria for every requirement helps to build a common understanding of the overall system. Furthermore, defining priorities helps to clarify the focus of the project.

1.4.2 Prioritization

In order to prioritize requirements, the project consortium has introduced three different classes of priorities. These classes range from high over medium to low and the consortium has defined them as follows:

 High: Requirements in this class are either realizing a key innovation of the project or they are needed to realize a key innovation or the prototype application. These requirements are necessary to achieve the goals of the project or they are necessary to demonstrate the project’s success.

 Medium: Requirements in this class represent optimization criteria that shall be investigated once the high priority requirements have been realized. These requirements are important to increase the applicability of the concepts and implementations developed by the project.  Low: Requirements in this class are neither realizing a key innovation nor (strictly) necessary

for the prototype application. However, in a broader context – possibly beyond the scope of the project – they may be important.

As a consequence, for the success of the project, it is essential to realize the requirements with high priority. In order to ensure the broadest possible applicability of the developed concepts it is furthermore necessary to ensure a high level of achievement with respect to medium priority requirements. The requirements with low priority, however, are not of immediate relevance for the project. However, their realization may provide additional features or benefits for applications or users that should be considered after all requirements of the other two classes have been implemented successfully.

(10)

1.5 Tool

Aiming at defining an optimum and complete list of requirements, a web tool based on the Volere methodology was used. This web tool has facilitated the definition, the validation and the prioritization of the project requirements.

Figure 1 – Volere Tool

For security reasons, the access to the web tool has been restricted to authorized users. User accounts have been created for each of the partners participating in the requirements elicitation process.

1.5.1 Process

The overall process of Volere as supported by the web tool is depicted below. After an initial specification of requirements, the users can specify conflicts, dependencies and objections. After specifying them, they can iteratively revise the specification and identify additional issues until it is free of conflicts, dependencies and objections.

Figure 2 – Process

The result will constitute the final list of requirements. The following subsections briefly outline the individual steps.

Definition

Validation

Final

Requirements

Revision

Issues

(11)

1.5.2 Definition

In this first stage all the requirements needed to accomplish the project objectives must be defined. These will be refined in future stages. The most useful information and the main functionalities at this stage available at the home page are:

Figure 3 - Definition

 Create a new requirement: All the fields are required except for “Comments and supporting material” which is optional. The required fields are:

o Type: The scope of this appended by an automatically generated sequential number, this ID uniquely identifies each requirement.

o Description: A one sentence statement which describes the intention of the requirement.

o Type: The type of the requirement as defined by Volere. o Rationale: A justification of the requirement.

o Acceptance criteria: A measurement of the requirement for further verification that the solution matches the original requirement.

o Satisfaction: The grade of satisfaction for the customer if the requirement is successfully implemented.

 Help: An external link to Volere requirements specification template.  List of requirements: The list of requirements with some additional options.

o Filtering options: The list of requirements filtered by type and/or filtered by author. o Expand table: Show/hide some columns, displaying more or less information about

the requirement.

 Requirements management: Modification options for requirements. o View a requirement.

(12)

o Delete a requirement (only available for the author).

 Requirements tracing: After the first validation, a new service is made available for keeping track of all the requirements history.

1.5.3 Validation

After the initial definition of requirements, the validation process begins. All the requirements should be approved by all the users. At this stage, conflicts and dependencies between requirements must be detected. Furthermore, any objection must be pointed out:

 Dependency: Requirements that have some dependency on other requirements.

 Conflict: Requirements that cannot be implemented if another requirement is implemented or a conflict due to an insufficient definition of the requirement.

 Objection: A reason or argument offered in disagreement, opposition, refusal or disapproval of the requirement.

Figure 4 – Validation

1.5.4 Revision

All the dependencies, conflicts and objections encountered by the experts during the validation stage must be revised and solved. However, if the authors do not agree with the validator’s opinion, then they can make use of the “Reviser’s comments” option for pointing out their disagreement or clarifying the intention of the requirement. Note that only the authors of the requirements that have to be revised are able to add comments to the dependency, conflict or objection.

Figure 5 – Revision

(13)

facilitating the interaction and communication between the author and the validator. For security reasons, the checkboxes on the “Requirements revised” column are only enabled for the authors of the requirements who have also enabled the possibility of adding comments. Moreover, for the same reason, the checkboxes on the “Validator’s approvement” column are enabled only for the author of the validation.

The revision process consists of four steps:

 Firstly, the authors should identify which requirements have been objected to or are involved in any conflict or dependency.

 Secondly and after analyzing the validator’s opinion:

o _{The author may agree with the validator and proceed to modify or delete the} requirement.

o _{The author may disagree with the validator, therefore he/she should make} appropriate comments trying to clarify the requirement with a better explanation or justify the intention of the requirement.

 Thirdly, the author should mark the checkbox of the requirement as revised.

 Finally, the validator should be aware of the revised requirements and approve the actions taken by the author for resolving the dependency/conflict/objection.

1.6 Structure

For the purpose of structuring the requirement document, we follow an adapted version of the IEEE recommendations on requirements specifications [IEEE98] for this type of project. Since this requirement document is a public document, adhering to such a standard seems a reasonable approach. As a consequence, the specification does not only list the requirements on the functionality realized by the individual work packages but it also lists a set of general requirements to create a more complete picture. The general requirements will be realized by the integration of the work of the individual work packages as foreseen by the project.

The structure of the remaining parts of the document is as follows. Section 2 describes the general requirements. To put these requirements into context, the section outlines the related work and discusses the gap that is filled by and the innovations that are brought by the project. Sections 3 to 6 describe the requirements on the individual research and development activities. Similarly to the general section, they also describe the state of the art and the existing research gaps. Section 3 starts off with the requirements on adaptive data acquisition whose components are responsible for recognizing contextual information and user intents. Section 4 continues with a description of the requirements on the automated privacy preservation functionality that will be provided to protect the user’s privacy. Section 5 describes the data representation and query processing requirements that will ensure interoperability and scalability and Section 6 details the requirements on the intent-aware user interface that will enable users to interact with the artifacts of the project. After the description of the requirements, the requirement specification closes with a short summary in Section 7.

(14)

2 General Requirements

The main objective of GAMBAS is to develop an innovative and adaptive data acquisition and processing middleware to enable the privacy-preserving and automated use of behavior-driven services that are able to adapt autonomously to the context of their users. While there are more and more applications that can be considered to be context aware or even context adaptive, these applications are usually focused on a narrow field of application. As a simple example one might consider a location-aware notification service that notifies a user about messages with local relevance. In contrast to this, the middleware developed in GAMBAS is focusing on enabling the development of a more innovative set of services that not only adapt to the current context but also to the behavior by enabling the recognition and use of intents by a service. As an example for this consider that when the system can provide a close estimate of the future location of the user, it can provide the user not only content that has a local relevance but also messages that are relevant in the close future.

In order to achieve this ambitious goal, the description of work lists four main technological research and development areas, namely, adaptive data acquisition, automated privacy preservation, interoperable data representation and query processing as well as intent-aware user interfaces. Besides these research and development areas, the realization of a comprehensive system as targeted by GAMBAS will require additional support to enable a spontaneous service-oriented communication between different devices. To optimally leverage the project’s limited resources, the work in this area will be covered by an existing middleware that has been implemented by some of the project partners in a previous FP7 project, namely, the PECES (Pervasive Computing in Embedded Systems) project. Due to this, the following requirements analysis will omit the requirements on service-oriented communication as these will be met by the available software.

As a result of the comprehensive middleware approach taken by the GAMBAS project, not all requirements can be directly assigned to one of the four main technological research and development areas listed in the description of work. Instead, some requirements can only be realized by the appropriate combination of all parts of GAMBAS. We categorize them under the term general requirements, and separate them for the requirements in the individual research and work packages. The following section focuses on describing these general requirements. From a high level perspective, the general requirements consist of requirements that are either targeted towards all parts of the middleware or they are jointly realized by the integration of all parts as targeted by the project. In addition, they explicitly state requirements that are assumed to be fulfilled by legacy systems that will be integrated as part of the development of the prototype application. To put these requirements into the appropriate frame, in the following, we first outline the current state of the art before we describe the resulting gaps and innovations. Finally, we list the requirements as well as their priorities. In the subsequent sections, we will then detail the requirements on the individual technological research and development areas.

2.1 State of the Art

(15)

context management which is a basis for enabling context-adaptive applications. Lately, the availability of results in these areas has led to the development of a number of large scale sensing applications. In the following, we briefly review the state of the art in each of these fields but before we do this, we quickly review the available hardware technologies.

2.1.1 Hardware Technologies

As for any other software project, the execution environment for the GAMBAS middleware is defined by a subset of the existing hardware platforms. Due to the specific focus of GAMBAS on enabling adaptive data acquisition with Internet connected devices, in the following, we briefly discuss the available hardware technologies with respect to devices, communication and sensing. The focus thereby is not to provide a comprehensive list of available technologies, as this list would be hard to keep up to date over the course of a 3-year research project. Instead, we take a more high-level perspective that uses current technology as examples but, in principle, is independent from the concrete implementation. Based on the resulting discussion of device, communication and sensing technology, we then introduce a classification of device types that are relevant for GAMBAS. Thereby, it is noteworthy to mention that not all features of the GAMBAS middleware will be necessarily realized for all types of devices. However, GAMBAS will enable their integration.

2.1.1.1 Devices

Based on our present day perspective, we can assume that the devices forming the Internet of Things will be heterogeneous. For example, besides traditional personal computer systems, a significant number of devices will be either mobile or integrated. When analyzing the different types of devices, we can categorize them with respect to several orthogonal axes.

 Specialization: Naturally, we can classify devices on the degree of specialization. This degree may range from general purpose devices such as PCs or laptops to special purpose devices such as micro-controllers that are integrated into all kinds of objects. Although, in principle, the concepts developed by GAMBAS should be applicable to all kinds of objects, GAMBAS will not focus on the latter. The reason for this is that highly specialized devices are often closed systems that cannot be programmed easily. Intuitively, we can expect that many closed devices will open up in the future.

 Resources: Independent from the degree of specialization, we can classify devices on the available resources. On the one end of the spectrum, the set of devices forming the Internet of Things may encompass resource-rich devices such as mainframes or clusters of workstations. On the other end, they may contain resource-poor devices such as simple sensor nodes. In between there are devices such as laptops or devices with less resources such as mobile phones or tablets.

 Mobility: Another important axis is the degree of mobility. Here, we can distinguish stationary devices and mobile devices. In contrast to stationary devices, mobile devices are usually equipped with batteries and thus, their energy is a limited resource that needs to be managed appropriately. This is especially true, when using mobile devices for long-running tasks such as the continuous monitoring of the environment.

(16)

with a user can be configured manually by the user. Due to the invisible integration the remaining devices can solely be configured indirectly through other devices.

2.1.1.2 Communication

Existing communication technologies can be broadly classified into wired and wireless. Due to the success of mobile devices, the latter ones have become main stream over the last couple of years. At the present time, there are several technologies that are widely available and frequently integrated into mobile devices. They cover the complete spectrum from low to high speeds and low to high range. At the same time, they exhibit vastly different energy profiles.

 Near field communication is a set of standards to enable radio communication between devices by bringing them in close proximity. NFC is based on existing standards on radio frequency identification (RFID). In contrast to other technologies in that family, it enables bi-directional communication between two devices. However, it offers only low transmission speeds and it is only applicable to very close range communication (i.e. few centimeters). At the present time, it is mostly used for mobile payment systems or in order to bootstrap connections with other communication technologies.

 ZigBee is a relatively new standard for short ranges communication. ZigBee is specifically designed for low power devices with low data rate and short range communication capabilities. The IEEE standard 802.15.4 defines the physical and the MAC layer for ZigBee. The devices in a ZigBee setup can be categorized into ZigBee coordinators, ZigBee routers and ZigBee devices. The ZigBee coordinator is the central entity that keeps record of the devices in the network as well of the other ZigBee coordinators. The ZigBee router is responsible for routing messages and associating devices with each other. Devices that are not ZigBee coordinators or ZigBee routers are classified as ZigBee devices.

 Bluetooth is another popular short range communication standard. Bluetooth modules are commonly available for standard computers and various peripherals. These modules support low bandwidth and short range communication. Depending on the communication range and energy consumption, Bluetooth devices are divided into three classes. Class 1 Bluetooth devices consume around 100 mW and support approximately 100m. Class 2 Bluetooth devices consumes up to 2.5 mW and support communication range of approximately 10 meters. Class 3 consumes the minimal power (1 mW) but also provide the shortest communication range (approximately 1 meter).

 Wi-Fi is probably the most popular communication standard for connecting various devices such as laptops or mobile phones wirelessly. Wi-Fi certification is given to the devices with wireless capabilities that implement 802.11 standards. There exist several 802.11 standards that include 802.11a, 802.11b, 802.11g, and 802.11n. Wi-Fi supported routers cover approximately 100 meters in outdoors. Since the clients in the Wi-Fi network do not require wire, the network can be easily extended. Wi-Fi enabled devices can easily move in a limited area but they have relatively short range. A possible shortcoming of Wi-Fi certified devices is that they have comparatively higher energy requirements.

(17)

consumes more power. However in terms of speed and service capabilities, it is a significant improvement over GSM.

For stationary devices, wired communication technologies are still an important alternative to wireless technology. Many stationary general purpose devices such as servers are usually connected with Ethernet.

 Ethernet is based on IEEE 802.3 specification and is a very popular LAN technology. The specification defines standard for physical layer as well as data link layer of the OSI model. Starting with 10Mbps, it has evolved to support 100Mbps (fast Ethernet) and later 1000Mbps (Gigabit Ethernet) speed. Currently the fastest speed standard supported by Ethernet is 10 Gbps although we can assume that there will be further progress on connection speeds.

2.1.1.3 Sensing

Besides device and communication technologies, the third hardware pillar of GAMBAS is sensing technology. Over the last couple of years, device manufacturer have started to integrate various sensors into different types of devices. At the present time, current mobile devices such as smart phones and tablets exhibit the following combination of sensors:

 Accelerometer: Accelerometers are used to measure the acceleration that a device experiences. In most cases they are able to differentiate acceleration along three axes. Usually, they are used to adapt the screen orientation of the device according to the way the user is holding it. However, researchers have also used accelerometers for various other tasks such as classifying the mode of locomotion or detecting potholes.

 Gyroscope: More recently, device manufacturers started to add gyroscopes to the set of standard sensors that are available on mobile phones. Gyroscopes are used to measure the orientation of a device. Advanced applications include inertial navigation systems, for example. However, at the present time, they are mostly used to support gaming.

 Microphone: As a natural consequence of their function, all mobile phones are equipped with microphones that allow them to record and transmit voice during a call. However, in addition to that, most devices nowadays exhibit multiple microphones (e.g. to enable automatic noise reduction) that can also be used to capture and analyze ambient sound.  Proximity: In order to activate and deactivate the screen automatically during a call, many

mobile phones are equipped with proximity sensors that can measure the distance between the phone and another object (typically in front of the screen) in a course-grained scale (e.g. far or close).

 GPS: To support location-based services and to support user navigation, many mobile devices are equipped with GPS receivers. Although they cannot be used reliably in indoor environments, outdoors they provide reliable localization with 5 to 10 meter accuracy.  Camera: Similar to microphones, nowadays, most mobile phones and tablets are equipped

with cameras which can be used to record videos as well as still images. Besides from simply taking pictures or recording videos, they can also be used to recognize visual tags (e.g. QR-Tags) and they can be used for different types of context recognition applications (e.g. to automatically detect gas station prices).

(18)

special maps that model the signal propagation in a certain area. Using these maps, a course-grained but energy-efficient localization can be supported.

Besides mobile devices, researchers have also developed a number of sensing platforms such as Berkeley Mica2 or UCLA iBadge, etc. – mostly in the area of wireless sensor networks. Typically, these platforms can be extended with different types of sensors but most of them contain at least the following combination of sensors.

 Light: Light sensors typically measure the light level received at a particular point of the device. In many cases light sensors are directly built into the sensor node or they can be added by attaching a sensor board.

 Temperature: Temperature sensors typically measure the ambient temperature of the sensor node. In many cases the sensors are not calibrated and the raw values need to be converted programmatically to the usual Celsius or Fahrenheit scale.

 Pressure: Pressure sensors typically measure the barometric pressure and thus, they can be used to compute the altitude.

 Humidity: Humidity sensors typically measure the humidity using capacitive measurements. In many cases they are bundled with temperature sensors.

In addition to mobile devices and sensor nodes, there are numerous application specific sensors. Due to their great variety, it is not possible to provide a comprehensive list here. To name some examples that may be relevant in the context of GAMBAS, using the OBD unit of a modern car, it is possible to capture various engine related values. These include, for example, the current fuel consumption or the current state of the catalytic converter.

2.1.1.4 Classes

Based on the previous discussion of device, communication and sensing technologies, we can identify four broad classes of devices that are forming the hardware platform for services developed with the GAMBAS middleware. Intuitively, based on the capabilities of the device the support provided by the middleware will differ.

 Back-end computer system (BCS): Back-end systems usually consist of one (or more) general purpose computer that is connected to the Internet via a wired and often high-speed connection. Usually, they exhibit high storage and processing capacities and they are shared by multiple users remotely _– i.e. through the Internet. Consequently, to most of their users, they do not expose a physical interface that would enable interaction. Instead, they are accessed through web-browsers or via custom applications that are performing some form of remote call (e.g. RPC, RMI, etc.). In GAMBAS such systems will be used to perform data storage, aggregation and processing.

(19)

high. In GAMBAS such systems will be used to perform similar tasks as back-end systems (although on a smaller scale) and they may also be used as a sensing platform.

 Constrained computer system (CCS): Constrained computer systems include mobile devices such as smart phones and tablets. Furthermore, they include stationary devices such as set top boxes or industrial PCs. When compared with traditional computer systems, they exhibit a significantly lower amount of computing resources with less capable processor architectures (e.g. ARM instead of X64) and less amount of memory (e.g. MB instead of GB). In many cases, they are equipped with a multitude of build-in sensors (e.g. mobile phone) or they can be attached to application specific sensors (e.g. industrial PC). Consequently, they provide the primary basis for data acquisition in GAMBAS and they will also be an important data storage that can be accessed remotely.

 Embedded computer system (ECS): Embedded computer systems include highly specialized micro-controllers or ASICs that are built into existing products such as a dishwasher or a car. Furthermore, they include less specialized sensor platforms that may be programmable such as a SunSPOT or a Mica2 node. Usually, these systems are not directly connected to the Internet. Instead, they can be connected through some gateway device that mediates the interaction. Although, such embedded devices outnumber the other classes at the moment, the GAMBAS project does not focus on the use of these devices as a primary processing platform. The reason for this is that usually, these devices cannot provide their function without additional computing infrastructure. Furthermore, in many cases they are not equipped with easily accessible interfaces or they do not provide sufficient computing resources to implement additional services. However, due to their ubiquity, the GAMBAS middleware will enable their use as data sources when combined with a more capable device such as a constrained computer system or a traditional computer system.

2.1.2 Communication Middleware

Regarding device interaction, researchers and practitioners have developed a number of communication middleware systems to enable the seamless and trustworthy cooperation of a heterogeneous set of possibly resource-poor connected objects. Examples for past and present research projects in this area are the 3PC [3PC11], GAIA [ROMA02] and AURA [GARL02] projects or the PECES FP7 [PECE11] project, to name a few. Traditionally, the resulting systems either focused on enabling the interaction of devices at a specific geographic location (i.e. the so-called smart spaces) or they focused on enabling the interaction of devices that are in close proximity (i.e. the so-called smart peer groups). More recently, systems such as the PECES middleware integrate and extend these two concepts by enabling the interaction within a smart space that is formed by devices in close proximity and beyond smart spaces by enabling device interaction across the internet in a peer-to-peer fashion. Since the resulting concepts provide a higher degree of flexibility, the GAMBAS middleware will use PECES as its underlying communication middleware.

(20)

preserving way, which usually provides an important basis for adaptation that is independent from the concrete abstraction that performs the adaptation. Consequently, from a high level perspective, the goal of GAMBAS is a more fundamental one that will enable the use of such abstractions at a later point in the development process.

2.1.3 Context Management

The importance of context information for the realization of ubiquitous computing has been recognized very early after the formulation of the vision [SCHI94]. Over the course of several years, researchers have developed a number of middleware systems to acquire and leverage context information, e.g. [HOHL99], [SALB99], [BARD05]. Traditionally, these systems have either focused on the scalability issues that arise from providing context-awareness in an application-independent way using a federated distributed system [HOHL99] or they focused on the actual distributed acquisition and usage when developing applications with a limited scale such as a room or a house [SALB99], [BARD05]. In addition to that, specialized context management systems have been integrated into all kinds of middleware systems for smart environments such as GAIA [ROMA02] and AURA [GARL02], to name a few. Similar to [SALB99] and [BARD05], these systems focused on a rather restricted execution environment.

Besides that, the active research in the area of sensor networks and cooperating objects has spawned a number of initiatives to acquire context information from a heterogeneous set of networked sensors that is deployed in an environment. Recent projects at the European level include for example the PLANET FP7 project [PLAN11] which works on concepts to deploy and operate large scale sensor networks to capture environmental information. However, usually these systems focus on low level networking aspects of various sensors or they solve high level data management aspects resulting from the large number of sensors. Thereby, these systems do not have to consider the resulting privacy implications when moving from environmental context – such as temperature or animal population – to personal context – such as human location, activity and plans.

2.1.4 Sensing Applications

In the recent past, the advances with respect to middleware, device and sensing technologies has led to the development of a number of large scale sensing applications that are often summarized as participatory sensing [BURK06] or people-centric sensing [CAMP06] applications. Similar to the goals of GAMBAS, these applications leverage the personal internet connected objects of users to capture relevant sensor information. The type of information typically depends heavily on the application area. To give some examples, DietSense [REDD07] tries to collect diet related information about the user through photos and sound samples. PEIR [MUN09] provides an estimate of the environmental impact of a user trip by determining the mode of locomotion. BikeNet [EISE09] captures the biking experience by means of measuring the location, speed and providing an estimate over the used calories. Haze Watch [CARR10] captures pollution information by attaching external sensors to a mobile phone.

(21)

trustworthy central server, however, the GAMBAS middleware aims at providing a configurable sharing that enables users to protect their privacy, if that is desired, which allows users to balance the potential loss of privacy with the potential gaining in service quality. Furthermore, instead of merely aggregating and visualizing the information the project itself aims at enabling the behavior driven adaptation of services.

2.2 Gaps and Innovations

Building upon the existing work, the GAMBAS middleware specifically targets the acquisition of personal context information. Consequently, it shares similar goals with several of the existing large scale sensing applications. However, in contrast to existing applications, GAMBAS also aims at ensuring the user’s privacy. Towards this end, the acquisition is performed primarily with personal Internet-connected objects. This empowers the user to limit the sharing of the acquired context. In order not to overwhelm the user, the GAMBAS middleware will contain a framework to automate the sharing in a privacy-preserving manner. Furthermore, in order to directly use the acquired context on the connected object, the middleware will provide concepts to implement intent-aware user interfaces, which will allow the user to have full control over the use of the GAMBAS software as well as having a fine granular system to enable and disable features as needed. Finally, in order to use the shared context effectively in enterprise business processes, the middleware will make use of an interoperable data representation with the associated processing infrastructure that supports a large number of sensors. This will provide the basis for efficient object to object interactions and thus, it will enable the _{development of novel services that adapt to the user’s behavior.}

2.3 Requirements

The general requirements can be grouped logically into four groups. In the following, we briefly describe these groups and show the resulting requirements that have been gathered jointly by the GAMBAS consortium. In order to keep this section easy to read, the requirements listed in the following are restricted to showing only the unique identifier, the requirement type, the requirement description as well as the requirement priority. A complete description including rationales and acceptance criteria can be found in the annex of this specification.

2.3.1 Platform-related Requirements

The first group of general requirements denotes a common agreement of the GAMBAS consortium on the hardware and software platform that is used as the basis for the project implementation. The requirements in this group are partially motivated by the fact that GAMBAS is building upon the results of the PECES project and partially by the current market of mobile devices in which a majority of personal mobile devices is equipped with different variants of the Android operating system.

ID GE_005

Description The GAMBAS framework running on mobile devices should be implemented

in Java or provide Java interfaces.

Type Mandated constraints

Priority High

ID GE_001

Description The GAMBAS framework should be able to support different devices.

(22)

Priority High

2.3.2 Application-related Requirements

The second group of general requirements denotes a high-level agreement of the GAMBAS consortium on the target scenarios that are realized by the prototype application used to validate the middleware. Obviously, a more detailed analysis of the requirements is contained within the use case specification that is developed by the project consortium in parallel to this specification.

ID GE_013

Description The GAMBAS framework enables the acquisition of travel- and

environment-related data.

Type The scope of the product

Priority High

ID GE_016

Description The GAMBAS framework enables providing environmental quality data for a

geolocated point in the city.

Priority High

ID GE_004

Description The GAMBAS framework provides crowd-levels for each bus journey.

Priority High

2.3.3 Prerequisite-related Requirements

The third group of general requirements defines the assumptions on the existing infrastructure and data that must be provided in order to successfully realize the targeted prototype application. Due to the fact that the GAMBAS middleware targets mobility as a primary application scenario there are several requirements on systems and the availability of (primarily static) data that are necessary to demonstrate the middleware. Without this infrastructure or the associated data, the capabilities of the middleware will be impacted negatively.

ID GE_018

Description Personal devices should have internet access to retrieve data from social networks and collaboration tools.

Type Relevant facts and assumptions

Priority High

ID GE_017

Description The application services are able to record and predict crowd-levels.

(23)

ID GE_014

Description The application services are able to compute possible end-to-end bus routes.

Priority High

ID GE_015

Description The application services are able to aggregate and share crowd levels from busses.

Priority High

ID GE_019

Description The application services are able to aggregate and share environmental information.

Priority High

2.3.4 Middleware-related Requirements

Finally, the fourth group of requirements defines the high-level requirements on the middleware realized by the GAMBAS consortium during the course of the project. Intuitively, these requirements are refined later on and broken down as multiple requirements that are realized separately within the different research and development work packages that have been planned by the consortium.

ID GE_010

Description The GAMBAS framework enables the optimization of services based on

usage behavior.

Type The purpose of the product

Priority High

ID GE_011

Description The GAMBAS framework enables proactive service offerings based on the

current user context.

Priority High

ID GE_012

Description The GAMBAS framework enables users to protect their privacy by controlling the sharing of acquired data.

Priority High

ID GE_007

Description The GAMBAS framework enables providing adaptive and customized

(24)

Priority High

ID GE_009

Description The GAMBAS framework enables the development of composed services.

Priority High

ID GE_008

Description The GAMBAS framework simplifies the development of services that acquire

data from different devices.

(25)

3 Adaptive Data Acquisition Requirements

Data acquisition is an essential part of any context recognition system. For such systems, data acquisition normally involves acquiring raw data from different types of sensors namely, accelerometers, microphones, Wi-Fi or GPS, gyroscope, proximity sensors etc. These sensors could be embedded into a single device and could be distributed in the environment. The data acquisition system acquires data from these sensors and pre-processes them before forwarding to more complex recognition tasks. Existing data acquisition systems differ depending on the available resources (memory, battery, etc.) and also on the target application requirements. An efficient data acquisition system should be generic enough to be executable in different settings (different hardware and different application requirements) with little or no tuning. In the following, we briefly review the state of the art for context data acquisition systems mainly focusing personal mobile devices like smart mobile phones, PDAs, etc. Thereafter, we identify the gaps in the existing solutions and from these gaps we derive a list of requirements for the GAMBAS middleware.

3.1 State of the Art

(26)

(Gaussian mixture models). The system is aimed at helping social scientist to understand the correlation of user emotions with the places, groups and their activities. [CHEN12] is a collaborative context recognition system for smart mobile phones. The system execution is a two stage process consisting of stages namely, grouping stage and context recognition stage. In the grouping stage devices are clustered based on their proximity. Once devices are clustered they scan the environment and send the raw data for subsequent context recognition to a backend server. In the context recognition stage, the system uses coupled hidden Markov model to model activity and location sequences. The system is aimed at advertisement systems where advertisements are shown based on mutual context and interest of user groups.

There also exist a small number of rapid prototyping tools for expeditious development of context recognition applications. Commonly known tools include [SALB99] [BANN08] [THIA09]. [SALB99] is targeted at context recognition with pre-deployed sensors and provides a uniform abstraction for applications to access and use context information by hiding the actual context sensing and its interpretations from the applications. [BANN08] is targeted towards activity recognition for wearable systems. This toolkit provides functionalities to develop distributed context recognition systems as well as reusable components, parametrizable algorithms, filters and classifiers. [THIA09] is a data gathering and processing open source platform targeted towards mobile phones with varying hardware capabilities. It consists of a minimal core that can be extended by plug-ins.

The systems mentioned above are generally used for dealing with heterogeneous sensing sources and providing flexibility for application developers to customize application in a certain way. However, there exist a number of finely tuned data acquisition and context recognition systems that can only be used in a narrow set of situations. Examples include [BAO10], [MILU07], [LANE08], [LANE09], [EISEN07]. These and many alike systems are manually fine-tuned for particular applications and therefore are able to detect only the fixed set of characteristics. As a result, these systems cannot be adapted to dynamic environments which a user might experience in a daily routine. They use built-in sensors in mobile phones to recognize the required context. For instance, [MILU07] uses microphones and accelerometers to determine user context which is then injected into social networking websites. [LANE08] uses accelerometers and microphones to detect road conditions. [THIA09] uses location sensors to identify road traffic congestions. Sound Sense [LANE09] uses a microphone to identify different types of sounds in the surrounding. [BAO10] is a system aimed at video recording of social events in a distributed manner using mobile phones. The phones are grouped based on the social activity in which their users are involved. On detection of a social activity the phone at the appropriate location is chosen to record the events. At the end of the social event all recordings from different phones are combined into one video by a backend server to create a lengthy video highlighting important event of the social gathering.

(27)

execution of unwanted sensors. [ROY11] is aimed at computing multiple contexts from multiple sensing sources. The authors have proposed a theoretical model that shows the inaccuracy of estimating multiple contexts from multiple sensing sources. The work also presents a heuristic algorithm for searching the set of sensors to recognize the required multiple contexts.

3.2 Gaps and Innovations

Designing a context data acquisition system is usually driven by the target applications and operating environments. Therefore such systems are optimized with considerations to their requirements. The above mentioned systems are similarly aimed at optimizing a particular characteristic which could be efficient utilization of available resources or highly accurate recognition of a particular context or development of context recognition applications. Looking at the description of these systems reveals a need for a generic yet efficient system that in essence should be a complete framework which on one hand shall allow efficient usage of available resource and on other hand should allow rapid development of specialized recognition applications with high accuracy. The data acquisition framework in GAMBAS middleware is aimed at bridging these gaps and thus will be providing a complete solution that meets all aforementioned objectives. Specifically, the data acquisition framework in GAMBAS middleware will be adopting a component-based approach allowing multimodal context data acquisition. The framework will provide an extensive components toolkit for rapid development of new context recognition tasks. Using component based solution; the data acquisition framework shall be applying resource efficient techniques (memory, energy, etc.) with little impact on the recognition accuracy. Moreover the data acquisition framework will be executable in distributed settings to enhance the quality of desired context and will help in providing relevant services to different groups of users (depending on their location, interests, etc.) .

3.2.1 Activity and Intent Recognition

The activity recognition components in the data acquisition framework will focus on computing various user activities or user contexts. Major focus will be on the location based activities, e.g. shopping in a supermarket, waiting for the bus at the stop, travelling in a bus (standing or sitting), sightseeing in a new city etc. The data acquisition framework will use a variety of means (motion sensor, Wi-Fi, GPS, on-line calendars) to recognize these and similar activities. Similarly the data acquisition framework will provide necessary components to estimate user’s intents. By user’s intents we mean user’s possible location or activity in the future e.g. knowing that a user is travelling on a bus to his destination, it might be useful or interesting to notify him about the possibility of meeting a friend if he is willing to change his route or prompt him of new shopping facilities near the destination. The intent recognition components will compute such user intents based on user’s activity patterns or interests.

3.2.2 Sound and Speech Recognition

(28)

imbedded in the GAMBAS Middleware and the development tool to enable the development of new applications using voice control and speech recognition.

3.3 Requirements

The requirements on the adaptive data acquisition performed in GAMBAS can be grouped logically into three groups. In the following, we briefly describe these groups and show the resulting requirements that have been gathered jointly by the GAMBAS consortium. In order to keep this section easy to read, the requirements listed in the following are restricted to showing only the unique identifier, the requirement type, the requirement description as well as the requirement priority. A complete description including rationales and acceptance criteria can be found in the annex of this specification.

3.3.1 Framework-related Requirements

The first group of requirements contains requirements on the functionality that shall be provided by the data acquisition framework itself. Due to their relevance, most of the requirements in this category have been identified as high priority requirements and only two requirements have been identified as medium priority requirements since they actually represent optimization goals that will be investigated during the project.

ID AA_001

Description The data acquisition framework shall allow multimodal data acquisition.

Type Functional and data requirements

Priority High

ID AA_002

Description The data acquisition framework shall be extensible.

Priority High

ID AA_003

Description The data acquisition framework shall allow automated acquisition of context data.

Priority High

ID AA_012

Description The data acquisition framework shall allow optimization of context recognition components by allowing configurable parameters.

Priority High

ID AA_004

Description The data acquisition framework shall be lightweight.

Type Performance requirements

Contract Delivery Date Actual Delivery Date Deliverable Type

Table of Contents

1

Introduction

1.1

Objectives

1.2

Purpose

1.3

Scope

1.4

Methodology

1.5

Tool

Definition

Validation

Final

Requirements

Revision

1.6

Structure

2

General Requirements

2.1

State of the Art

2.2

Gaps and Innovations

2.3

Requirements

3

Adaptive Data Acquisition Requirements

3.1

State of the Art

3.2

Gaps and Innovations

3.3

Requirements