Contract Delivery Date Actual Delivery Date Deliverable Type

(1)

Document Title Document Version D1.1 Requirements Specification (Update) 1.7

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

(None) May 31st_{, 2013} _{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

Stefan Foell OU WP1

Abstract

This document describes the updated 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 and they have been updated before the start of the second iteration of the implementation. 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. 1.2 NUIG Internal review.

1.3 UDE Reworked introduction for updated version.

1.4 UDE Updated requirements based on Volere web tool export. 1.5 UDE Added section to motivate and describe the changes.

(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.

(7)

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.

(8)

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. In addition, this updated version includes modifications, removals and additions of requirements made during the integration of the first iteration in response to the recommendations issued by the project’s reviewers.

This document acts as a main deliverable of the first work package. Apart from that, this document provides the key reference 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. And in fact, this document already contains the second version of the requirements that have been updated during the integration of the work in the previously mentioned RTD work packages.

(9)

The intended audiences for this document are primarily the GAMBAS stakeholders 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

This requirement specification document describes the final requirements that have been gathered, discussed and reviewed as part of a joint activity of the whole GAMBAS consortium. It includes changes made to the requirements during the integration of the work done in WP2-WP5.

For the sake of brevity, it does not describe the intermediate versions of requirements or the steps that have been taken during the individual revisions. However, it includes a brief list of changes that have been made to the original version of the document and the associated requirements as part of the update during the integration.

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 and that have been updated during the integration of the initial code prototypes before the beginning of the second iteration. 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

(10)

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.

2. The Volere methodology provides an easy process to track and evaluate the progress of the project.

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.

(11)

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.

In order give all stake-holders and interested parties an insight into the prioritization process, the consortium has not only assigned categories to each requirement but it has decided to include the main rationale for this classification in this document. Besides from being informative, this can be helpful in later stages of the project where unforeseeable issues may require the introduction of new requirements or changes to existing requirements.

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

Definition Validation

Final Requirements

Revision Issues

(12)

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

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

(13)

 Requirements management: Modification options for requirements.

o View a requirement.

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

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.

(14)

The checkboxes in “Requirements revised” column and “Validator’s approvement” column help the users to check the status of the revision and together with the possibility of adding comments 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 Update

Based on the feedback provided by the GAMBAS project reviewers, the GAMBAS consortium has implemented an update to this document together with the initial release of the integrated system. In the following, we briefly describe the rationale for the timing, the approach taken during the update process, the inputs considered during the update process as well as the resulting modifications.

1.6.1 Timing

As a first step towards following the project reviewer’s recommendations, the GAMBAS consortium identified a suitable point in time to update the requirements specification. Intuitively, there was a tension between trying to include as much feedback as possible and providing a stable set of requirements that can be implemented successfully during the second iteration of the project. Based on this tension, the GAMBAS consortium jointly decided to go for the latest possible point in time that could ensure that the requirements can still be considered – thereby enabling the maximum amount of feedback permissible during the highly parallel middleware and application development - which is denoted by the beginning of the second iteration of the GAMBAS middleware implementation, i.e. M14. Thus, given this decision, it is possible to guarantee that all requirements described in the updated version of this document can also be considered during the second design of the middleware components which maximizes their chances of being implemented successfully.

1.6.2 Approach

(15)

the set of stable requirements generated for the initial version of the document as well as the additional knowledge gathered during the first year of the project. The final outcome is another stable set of requirements that defines the starting point for the second iteration of the middleware implementation.

1.6.3 Inputs

Based on the timing and the approach taken for the compilation of the updated requirements described in this document, the GAMBAS consortium was able to consider three primary sources of inputs during the revision of the requirements:

 Middleware developers: In the time between the creation of the initial and the updated version of this document, the GAMBAS middleware developers have designed, implemented and tested their individual components. Thereby, they have designed not only their core functionality but also defined interfaces to the software components of other middleware developers. Furthermore, they have begun to develop the application-oriented interfaces of the middleware and they have written tests to demonstrate their components. Last but not least, they have started to work on the integration of the first middleware prototype which completed together with the delivery of this document. Consequently, given this work the middleware developers share a much deeper understanding of not only their own middleware components but also the components of the other developers enabling them to see beyond their islands and looking at the GAMBAS middleware more from an integrated perspective. Naturally, this new perspective has led to the modification and clarification of some requirements related to the middleware components which are now incorporated in this version of the document.

 Application developers: In addition to integrating the first version of the middleware, the GAMBAS consortium also defined the functionality of their prototype application as part of the development of the Evaluation Plan for the application. This resulted in deep communication and discussions among the application developers and the middleware developers in order to ensure that the applications can use and demonstrate the middleware functionality and that the middleware functionality would support the application implementation. Consequently, this discussion resulted in a clearer and revised picture of the requirements of the application developers that has been incorporated into the updated version by means of new, removed and replaced requirements.

 Operators and stakeholders: Similar to application developers, the creation of the evaluation plan also intensified the discussion among the middleware and application developers with the operators of the solutions. Moreover the GAMBAS consortium organized two workshops during the first year of the project, one of which focused explicitly of furthering the interaction with industry (in this case the telecommunication engineers of the Valencia region). The resulting discussions with the engineers and other stake holders have led to an introduction of several new requirements – many of which are related to the intent aware user interface which has undergone a significant amount of changes from the first version of the document to the updated version. These changes were necessary in order to clarify the scope of the intent-aware user interface.

1.6.4 Changes

(16)

requirements that changed and omit the requirements that left unchanged during the update of the requirements specification document. The complete set of resulting requirements are described hereinafter in the following sections.

In summary, the update to the requirements specification document led to the modification of 6 existing requirements and introduced 11 additional requirements. From the 11 new requirements, 7 have been categorized as having a high priority. The remaining requirements are considered to exhibit a medium priority. Consequently, the GAMBAS consortium is targeting to implement all of them as part of the work in the work packages 2 to 6. In the following, we first discuss the modifications and then quickly describe the extensions.

1.6.4.1 Modifications

The modifications to requirements affect all components of the GAMBAS middleware. Starting with requirement AA_025 whose description has been modified to replace the term “co-use” with user profile due to an improved understanding of how co-use will be captured and used in the application prototype. Similarly, the description and rationale of PP_008 has been modified to clarify that access control on contextual information will be done on a per application basis _– which was a refinement resulting from the ongoing integration efforts that clarified the interaction between the data storage and the privacy framework. Analogous to this, the description of GE_014 has been modified to reflect the fact that bus related information will be retrieved from an existing transport system that will not only provide static but also dynamic data. Thus, it is not possible to simply wrap the data access but it is necessary to provide an interface that enable dynamic conversions. This need for a more dynamic interface was discovered during the discussions with the application developers and stakeholders after the completion of the first version of this document. In addition, the requirements DQ_004 and DQ_006 were modified with respect to their description and rationale. For DQ_004, the vague term “format” was replaced with a more precise variant demanding support for different spatial models. For DQ_006, the adaptation requirement was modified to cover system as opposed to network parameters. Both changes were motivated by the improved understanding of the actual requirements that was gathered during the implementation of the data storages and query processor. Last but not least, the requirement UI_015 was modified with respect to the requirement type which was changed to usability and humanity requirements. This was a simple correction of the original misclassification of this requirement.

1.6.4.2 Extensions

(17)

profiles of friends (UI_020). The second set of requirements refine the interaction with the user interface by demanding automatic updates (UI_021) and speech inputs (UI_022). Finally, UI_023 considers a completely new aspect – namely the deletion of private data stored by the middleware through the user interface _– which is a new aspect that has been identified during the implementation and integration of the first middleware prototype.

1.7 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.

(18)

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

(19)

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.

(20)

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.

(21)

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).

(22)

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.

(23)

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.

(24)

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.

(25)

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

(26)

ID GE_001

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

Type Operational requirements

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

(27)

Priority High

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.

(28)

ID GE_007

Description The GAMBAS framework enables providing adaptive and customized information to users.

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.

(29)

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.

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

1.6

Update

1.7

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