Contract Delivery Date Actual Delivery Date Deliverable Type

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.

In the past, these characteristics have contributed to the development of a number of context recognition systems for Internet-connected objects. The recognition methods applied by existing systems are usually fine-tuned for specific requirements in order to provide reasonably accurate results while requiring limited resources. Although, these methods are suitable for accurately In the past, these characteristics have contributed to the development of a number of context recognition systems for Internet-connected objects. The recognition methods applied by existing systems are usually fine-tuned for specific requirements in order to provide reasonably accurate results while requiring limited resources. Although, these methods are suitable for accurately

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.

The realization of the GAMBAS middleware requires the development and integration of a flexible context recognition framework that is able to capture the context of users (e.g. location, activity, plans, intents), an interoperable data model to represent context information, a scalable data processing infrastructure to query and aggregate context information and to integrate context into services, a suite of security protocols to enforce the user’s privacy when sharing context information and last but not least, a recommendation system to largely automate the discovery and selection of relevant services available to the user. In addition, it requires tools to simplify the configuration of The realization of the GAMBAS middleware requires the development and integration of a flexible context recognition framework that is able to capture the context of users (e.g. location, activity, plans, intents), an interoperable data model to represent context information, a scalable data processing infrastructure to query and aggregate context information and to integrate context into services, a suite of security protocols to enforce the user’s privacy when sharing context information and last but not least, a recommendation system to largely automate the discovery and selection of relevant services available to the user. In addition, it requires tools to simplify the configuration of

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.

Having a clearly communicated and commonly shared understanding of the goals throughout 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 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

Gathering the requirements from all stakeholders 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 Gathering the requirements from all stakeholders 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

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.

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

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.

No Issues

Final Requirements

Figure 2 – Process

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

the requirement.

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

Figure 5 – Revision

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

The approach taken to update the requirements specification is analogous to the initial approach of creating initial set of the requirements. Based on the Volere methodology described previously, the GAMBAS consortium implemented another set of iterations until a stable set of requirements was reached again using the inputs described below. Consequently, the starting point for the update was The approach taken to update the requirements specification is analogous to the initial approach of creating initial set of the requirements. Based on the Volere methodology described previously, the GAMBAS consortium implemented another set of iterations until a stable set of requirements was reached again using the inputs described below. Consequently, the starting point for the update was

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

In the following, we briefly outline the changes that have been made to the requirements during the compilation of the updated version of this document. For the sake of brevity we focus on the In the following, we briefly outline the changes that have been made to the requirements during the compilation of the updated version of this document. For the sake of brevity we focus on the

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

The extensions of the requirements specification are centered on the privacy framework, the query processing system and the intent-aware user interface with a clear focus on the latter. With respect to the privacy framework, two new requirements were introduced, i.e. PP_015 and PP_016. PP_015 puts an additional requirement on the interface between the privacy framework and the data processing system. PP_016 broadens the applicability of the privacy framework by not only supporting encryption but also enabling authentication between friends. With respect to the query processing system, one additional requirement has been introduced, namely DQ_021. This requirement extends the support for distributed queries from streaming to one-time queries – which – in retrospective – was an omission in the initial version of this document. Apart from these extensions that can be considered as clarifications, the remaining 8 new requirements target refinements of intent-aware user interface. The first set of these new requirements refine the actual user interface by requiring the visualization of different types of information such as the crowd level (UI_016), the travel information (UI_017), the own user profile (UI_018, UI_019), as well as the The extensions of the requirements specification are centered on the privacy framework, the query processing system and the intent-aware user interface with a clear focus on the latter. With respect to the privacy framework, two new requirements were introduced, i.e. PP_015 and PP_016. PP_015 puts an additional requirement on the interface between the privacy framework and the data processing system. PP_016 broadens the applicability of the privacy framework by not only supporting encryption but also enabling authentication between friends. With respect to the query processing system, one additional requirement has been introduced, namely DQ_021. This requirement extends the support for distributed queries from streaming to one-time queries – which – in retrospective – was an omission in the initial version of this document. Apart from these extensions that can be considered as clarifications, the remaining 8 new requirements target refinements of intent-aware user interface. The first set of these new requirements refine the actual user interface by requiring the visualization of different types of information such as the crowd level (UI_016), the travel information (UI_017), the own user profile (UI_018, UI_019), as well as the

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.

For the sake of brevity, the individual sections will only list a short form of the requirements that consists of the description, the type, the id as well as the priority. The complete version of the requirements can be found in the annex of the document.

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 dev ices. 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

Although it has not been realized so far, overall, the vision of ubiquitous computing as defined by Mark Weiser [WEIS91] is not new. Ever since its formulation in 1991, researchers and practitioners have focused on closing different research gaps. With respect to middleware issues, a significant amount of research has been performed in the area of enabling seamless device interaction as well as application adaptation. Furthermore, there have been considerable efforts in the area of enabling Although it has not been realized so far, overall, the vision of ubiquitous computing as defined by Mark Weiser [WEIS91] is not new. Ever since its formulation in 1991, researchers and practitioners have focused on closing different research gaps. With respect to middleware issues, a significant amount of research has been performed in the area of enabling seamless device interaction as well as application adaptation. Furthermore, there have been considerable efforts in the area of enabling

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.

 Interaction: Last but not least, the devices can also be classified based on their capability of supporting immediate interaction with a user. Here, we can distinguish devices that support user inputs, e.g. by means of graphical interfaces, and devices that are invisibly integrated other objects. This axis is particularly relevant since only devices that support the interaction  Interaction: Last but not least, the devices can also be classified based on their capability of supporting immediate interaction with a user. Here, we can distinguish devices that support user inputs, e.g. by means of graphical interfaces, and devices that are invisibly integrated other objects. This axis is particularly relevant since only devices that support the interaction

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