icore Internet Connected Objects for Reconfigurable Ecosystem

(1)

Date: 30/06/2013

Internet Connected Objects for Reconfigurable Ecosystem

Grant Agreement Nº 287708

D2.3 Architecture Reference Model

WP2 – Cognitive Management and C

Dissemination Level

Internal reviewers:

The research leading to these results has received funding from the European Community

Grant Agreement number: 287708

iCore

Internet Connected Objects for Reconfigurable Ecosystem

Grant Agreement Nº 287708

Management and Control Framework for IoT

Version: Due Date: Delivery Date: Nature: Dissemination Level: Lead partner: Authors: Internal reviewers: 2.0 M16 30 June 2013 Report PU Telecom Italia

Roberto Minerva (Editor) + see contributors table

TCS, VTT, SIE, ALUB, CRF, ATOS, AMBIENT

www.iot-icore.eu

The research leading to these results has received funding from the European Community's Seventh Framework Programme [FP7/2007

2013] under grant agreement n° 287708

Page 1 of 136

Internet Connected Objects for Reconfigurable Ecosystem

ramework for IoT

Roberto Minerva (Editor) + see contributors , AMBIENT

The research leading to these results has received funding from the 's Seventh Framework Programme

(2)

[FP7/2007-D2.3 Architecture Reference Model

Date:

30/06/2013 Grant Agreement number: 287708 Page 2 of 136

Abstract

The deliverable defines the iCore architecture in terms of its principles, guidelines and identified components. The architectural definition fits business and technological requirements as put forward by Stakeholders and considers the requisites stemming from a wide set of use cases. The document is structured as follows: Section 1 describes some high level requirements that have provided the general motivation of the iCore architecture definition. Section 2 describes the requirements of the architecture and provides initial general principles of it. Section 3 describes the functional architecture of iCore, its building blocks and the relationships between them. Section 4 discusses the supporting technologies that can be integrated in a consistent way in order to provide a sound technology architecture that supports the execution and the functioning of iCore systems. Finally section 5 emphasizes how the iCore definition meets the requirements put forwards in Section 2.

(3)

Date:

Executive Summary

The iCore Architecture defines a set of basic principles, building blocks, functional entities and guidelines for building iCore compliant systems. The definition of these architectural principles (Section 2) have been carried out in several ways: a) requirements of different stakeholders have been considered in order to determine a set of business related guidelines that have led to several technical requirements [2][3]; b) technical requirements stemming from a top down approach have been considered; and c) requirements derived from a bottom up approach (i.e., by the definition and specification of a set of Use cases) have been taken on board. This has led to a functional architecture (described in Sections 2 and 3) capable of representing Real World Objects and their virtualization within the iCore architecture as well as the support of application developers aiming at creating new compelling applications that exploit the iCore Architecture capabilities. Central to the design of iCore functional architecture definition there are a few basic principles:

• Identification and roles of stakeholders. Actually the iCore architecture currently already distinguishes seven actors in the functional architecture and the respective business roles. They are used in order to fully describe the functioning of an iCore system with respect to business, functional and operational needs.

• Virtualization and composition of Objects. Real World Objects can be represented as Virtual Objects, VOs, in iCore. They allow a representation of the real world objects in a functionally enriching environment. Simple Virtual Objects can be aggregated and merged in order to create new Virtual Composite Objects, called CVOs, that extend and generalize the real world object functionalities and features, often in a service execution context, according to service requirements.

• Segmentation and Aggregation of functions. Objects are framed in a set of levels, each level is aggregating functionalities offered by a certain type of iCore entities: the VO level collects all the functionalities provided by the Virtual Objects as well as the entities and the functionalities of the iCore system needed to support and to use the VOs. On top of the VO level, iCore frames the CVO related functionalities and how they can be related to each other and with entities of other levels (namely the VOs and the Service Enabling Functions). In the upper most level, the iCore architecture considers all the service enabling functions and their relations to applications and CVOs. At each level, the iCore architecture envisages an increasing number of functionalities and systematic entities used to support the architecture.

• Functional and Systematic view of objects. Objects and building blocks of iCore are designed in order to offer specific functions to be used to support services. Any single object will provide interfaces and functions that support the integration of the object into the system (systematic view). Each iCore component will support these two facets, functional and systematic, that will allow to support end user services and to properly manage the object within an iCore context.

• Cognition. Cognition is another cornerstone of the iCore architecture, within iCore it is structured as a cognitive cycle in which knowledge is derived from observing the external environment (i.e. real world events/data) which is continually evolving and decisions/actions are inferring its future behavior based on three criteria, namely: (i) the knowledge created, (ii) other goals and also (iii) policies, so as to optimize the performance.

Central to the iCore architectural definition is the concept of situation awareness: an iCore system will not be exclusively concerned with individual pieces of sensor data, but it has the ability to build on events (i.e. low level situations) that are detected and interpreted from real world sensor data, into a higher domain relevant representation. This representation should encapsulate and describe

(4)

Date:

30/06/2013 Grant Agreement number: 287708 Page 4 of 136 the current abstract state of affairs concerning the monitored environment, which is relevant to the application in question, i.e., the situational awareness.

Another major concern of the iCore Architecture is security. The iCore security framework is based on the concept that access to the VO/CVOs must be regulated through a sticky policy management approach, i.e., the policy applicable to a piece of data (e.g. originating from a VO) travels with the data and is enforceable at every point it is used. In iCore, the security framework combines the concept of sticky policies with the concept of VO/CVO, which are created and managed with their associated policies and access rights. Users will therefore be able to declare privacy statements that define when, how and to what extent their personal information (also accessed through a VO) can be disclosed. The application of sticky policies allows the VO/CVOs to be distributed across different domains in several operational scenarios while preserving the information accessible through them. The concept is that the VO/CVOs are encrypted and signed in one domain and not accessible by unauthorized users, even if they are distributed across untrusted networks and domains.

In order to implement an iCore system in with compliance to the functional architecture definition, there is the need to define a technology architecture, i.e., a combination of technology infrastructure products and components that support the functioning of an iCore system. The technology architecture of iCore is a collection of technology software components that provide the services used to support the specific set of functions defined according to the architectural guidelines. This includes IT infrastructure, middleware, networks, communications, processing, and standards. The technology architecture is derived by the needs and requirements exposed by several use cases (see Chapter 4).

Eventually, the merits and the value of the iCore architecture are evaluated with respect to different stakeholders (Chapter 5) that have actively participated to the elicitation of requirements. iCore is an open architecture and as such will allow to Service Providers to offer a broad portfolio of services, to marketplace providers to offer applications within a sort of app store. Even Knowledge Providers a new role enabled by the architecture, the architecture can expose and leverage their capabilities within an iCore system, in fact knowledge representation is a highly valuable feature that can be integrated in iCore systems in order to support applications and services in (either broadly or narrowly) specialized problem domains. The role of Platform Provider is also envisioned, i.e. a provider able to instantiate a proper iCore system (or several segmented systems) in order to support specific requirement of service providers. The merits of the iCore architecture are also evaluated with respect to possible integration and contribution to other architectures such as IOT-A, OGC Sensor Web Enablement and the ETSI’s M2M.

(5)

Date:

Contributors

First Name Last Name Affiliation Email

Gianmarco Baldini JRC, EC [email protected]

Thomas Bartzsch Innotec 21 [email protected]

Panagiotis Demestichas UPRC [email protected]

Corentin Dupont Create-Net [email protected]

Matti Etelapera VTT [email protected]

Darminder Ghataoura UniS [email protected]

Raffaele Giaffreda Create-Net [email protected]

Pasi Hyttinen VTT [email protected]

Dimitris Kelaidonis UPRC [email protected]

Maarten Los ATOS [email protected]

Stephane Menoret Thales [email protected] Roberto Minerva Telecom Italia [email protected] Cosmin-Septimiu Nechifor Siemens [email protected]

Gerard Nguengang Thales [email protected]

Toon Norp TNO [email protected]

Venkatesha Prasad TUDelft [email protected]

Daniele Presta CRF (Fiat Group) [email protected]

Abdur Rahim Create-Net [email protected]

Marc Roelands Alcatel-Lucent B [email protected]

Chayan Sarkar TUDelft [email protected]

Lucian Sasu Siemens [email protected]

Vera Stavroulaki UPRC [email protected]

Paul Tilanus TNO [email protected]

Filippo Visintainer CRF(Fiat Group) [email protected]

(6)

Date:

Table of Acronyms

Acronym Meaning

API Application Programming Interface CONOPS Concept Of Operations

CONUSE Concept Of Use

CVO Composite Virtual Object

DoW Description of Work

F, see also NF Functional

FI Future Internet

FP7 Seventh Framework Programme

GSM Global System for Mobile Communications ICT Information and Communications Technologies

IoT Internet of Things

IoT-A Internet of Things Architecture NF, see also F Non-Functional

RWO Real World Object

SA Situational Awareness

SL Service Level

SLA Service Level Agreement

Telco Tele-Conference

UMTS Universal Mobile Telecommunications System

VO Virtual Object

WP Work Package

w.r.t With Respect To

API Application Programming Interface CVO Composite Virtual Object

RWK Real World Knowledge

SK System Knowledge

OGC Open Geospatial Consortium

(7)

Date:

List of Figures

Figure 1 iCore specification ecosystem ... 15

Figure 2 Example of requirement chain ... 16

Figure 3 Traceability & justification table ... 16

Figure 4. An initial View on some iCore Principles and Entities ... 25

Figure 5: iCore Cube ... 26

Figure 6: iCore Cube Detailed ... 27

Figure 7: Segmentation of iCore Functionalities ... 28

Figure 8. The Concept of Template ... 29

Figure 9: A high Level Representation of the iCore Architecture ... 31

Figure 10: Semantic enrichments of VOs ... 32

Figure 11 Functional Architecture of the Service Level ... 34

Figure 12 Functional Architecture of the CVO Level ... 36

Figure 13 Functional Architecture of the VO Level... 39

Figure 14: iCore Functional Architecture ... 43

Figure 15: Relationships with WP6 Use Cases ... 44

Figure 16: VO Template provisioning in the VO Template Repository ... 46

Figure 17: Service Template provisioning in the Service Template Repository ... 46

Figure 18: VO Installation in the VO Registry ... 47

Figure 19: Service Request handling – part 1 ... 48

Figure 20: Service Request handling – part 2 ... 51

Figure 21: Graph data model of the VO Model ... 54

Figure 22: Virtual Object Graph Data Model part ... 55

Figure 23: ICT Object & non-ICT Object Graph Data Model part ... 55

Figure 24: VO Function Graph Data Model part ... 56

Figure 25: VO Template ... 56

Figure 26: VO Template and VO Installation, Registration and Deployment process ... 57

Figure 27: CVO Template ... 58

Figure 28: External Interfaces ... 60

Figure 29: Interfaces of components involved in VO design phase ... 61

Figure 30: Interfaces of components involved in VO installation phase... 61

Figure 31: Interfaces of components involved in VO execution phase ... 62

Figure 32: Interfaces of components involved in CVO design phase ... 62

Figure 33: Interfaces of components involved in CVO instantiation phase ... 62

Figure 34: Interfaces of components involved in CVO execution phase ... 63

Figure 35: Interfaces of components involved in Service and Knowledge design phase... 65

Figure 36: Interfaces of components involved in Service Request phase ... 65

Figure 37: Interfaces of components involved in Service execution phase ... 66

Figure 38: A high-level overview of the cognitive cycle and relation to iCore ... 68

Figure 39: Position of Situation Awareness in iCore ... 69

Figure 40: Access levels in iCore framework ... 76

Figure 41: Description of the cognitive capability with the access model ... 78

Figure 42: Distribution and access of VO in a distributed domain. ... 80

Figure 43: Functional and Technology Architectures ... 82

Figure 44: Technologies areas comprised in the iCore Technological Platform ... 83

Figure 45: The Urban Security communication stack ... 84

Figure 46: Possible Adaptation Mechanisms in iCore ... 85

Figure 47: Mapping of iCore Architecture Functions and needed Technologies for Ambient Assisted Living ... 87

(9)

Date:

Figure 48: iCore Technology Platform and Technologies for Ambient Assisted Living ... 90

Figure 49: Mapping the Smart Meeting Requirements to the iCore Technology Architecture ... 92

Figure 50: iCore Architecture and Technologies in the “Smart City” use case ... 94

Figure 51: iCore Technology Platform and Technologies in the “Smart City” use case ... 95

Figure 52: Technology use in iCore ... 97

Figure 53: Technology Architecture for the Logistic Use Case ... 98

Figure 54: Urban security use case overview ... 99

Figure 55: Urban security use case ICORE unique technical features overview ... 100

Figure 56: Urban security use case system deployment overview ... 102

Figure 57: Urban security use case and Sarah rescue ... 104

Figure 58: Urban security use case workflow between C4I and Sarah’s home ... 105

Figure 59: Functional architecture model generalisation from standards ... 107

Figure 60: Urban security use case overall functional architecture ... 109

Figure 61: Urban security use case sensors network functional architecture ... 110

Figure 62: Urban security use case sensors network gateway functional architecture ... 111

Figure 63: Urban security use case domain applications (C2 / C4I) functional architecture ... 113

Figure 64: Stakeholder roles and related benefits enabled by iCore architecture ... 116

Figure 65: Functional IoT-A alignment ... 127

Figure 66: The ETSI TC M2M Service Enablement Framework ... 128

Figure 67: Open Geospatial Consortium Sensor Web Enablement ... 130

Figure 68: OGC SWE (layered) architecture ... 130

(10)

Date:

List of Tables

Table 1 Requirements criteria ... 17

Table 2: Components Interfaces ... 67

Table 3: Mapping of Technical Requirements towards the iCore Architecture ... 121

Table 4: Conceptual mapping of IoT-A and iCore ... 126

Table 5: Two different mappings between iCore and ETSI TC M2M service enablement framework ... 128

(11)

Date:

1.

Introduction

The iCore Architecture is defined in order to differentiate its contribution in the field of the Internet of Things with respect to other on-going activities. The major differentiator of iCore is:

• Cognition, i.e., the capability of the iCore systems to derive knowledge from the usage context in order to help applications to reach their goal and the ability to intelligently behave and organize the system’s own resources.

In addition iCore combines into a unique architecture other two important features:

• Virtualization, i.e., the capability to virtualize real world objects and to represent them into a programmable framework

• Large scale IoT systems, the iCore architecture is trying to cope with large systems made out of many thousands of sensors and actuators.

• The iCore contribution is also based on an extensive set of requirements drawn by a constant interaction with stakeholders and experts in the field. This has led to a collection of requirements and desiderata that have driven the definition of the architecture (see Section 2). Consequently a top down approach has been adopted to define and frame some high level architectural principle inspiring the whole solution. On the other side, a set of Use Cases have been defined with a two-fold goal: to elicit new requirements adopting a bottom-up approach and to validate or challenge some of the basic iCore architectural assumptions. This is an on-going activity and it will be consolidated in future releases of the architecture. However, some results, especially in the area of the definition and organization of management and control aspects as well as in the definition of data and templates of the iCore architecture are visible and described in this deliverable.

1.1

Virtualization

A first differentiating objective of iCore is introducing Virtualization into the Internet of Things realm. In many ICT areas virtualization is already being widely used and it comes with a lot of disruption as well as new opportunities for creating services and application. In the Network Control area, for instance, the Network Function Virtualization Forum, sponsored by ETSI [1] is using virtualization for promoting higher levels of functional aggregation and organization of the network functions. In the Data Centre area, virtualization is used to support a whole new approach for the organization of software. This has enabled a new kind of offering: the XaaS (everything as a service) paradigm is heavily based on the virtualization techniques.

Introducing Virtualization in the Internet of Things context has many merits. For instance it could help to overcome the heterogeneity of many proprietary architectures and systems enabling the possibility to run several proprietary IoT applications into a single platform. Virtualization of sensors and actuators is also important because it allows representing real world objects into the network. This enables the possibility of programming in relation to real world objects in the iCore platform and to control, govern, or integrate the virtual instances in a programmable environment.

Virtualization is the first step towards the virtual continuum, i.e., the possibility to create a link between any physical object and its representation in the cloud. The virtualized object can extend the functionalities, the features and the capabilities offered by the real one. For instance a real world object, a car, can be virtualized in the cloud and its functions can be controlled and managed in the “internet”. The car functions can be extended by applications and services running in the cloud. But there is more: each real world object can be transformed from a product into a service. The virtualized car can be enriched with control functionalities (e.g., for a trip in the mountains, the driver

(12)

Date:

30/06/2013 Grant Agreement number: 287708 Page 12 of 136 can enable the four wheel drive capability for a couple of days by interacting with the car and paying for that functionality for the required time. Additional power can be bought by means of the virtualized representation of the car for a specific travel, and so on). The car is not anymore a product sold to a client, but a service that can enable and disable premium functionalities depending on the needs of users. This is an example of how virtualization can support a promising business model called Servitization.

But there is more: different objects could represent a single real object allowing for sharing of its functionalities in different virtual environments. The same physical sensor can be virtualized and confined into different contexts of usage. Valuable resources can be virtualized and shared in such a way to increase their usage and to help in limiting the wide deployment of similar sensors by different providers. On the other side valuable functions can be derived by virtualizing the real sensor capabilities: e.g., a camera can be used as a location device, a noise sensor can be used to determining the number of people present in a city street in the context of smart cities applications, and so forth. Virtualization allows deriving useful functions by many heterogeneous devices deployed in the real world. Composing and extracting these capabilities is supported by virtualization.

1.2

Large scale systems

Large scale systems, as those in the scope of iCore, have to be dealt with in a different manner than small scale and confined (wireless) sensor networks or small Internet of Things systems. They are complex by definition (comprising many objects that show a very unpredictable and dynamic behavior). Dealing with these systems in a traditional way (i.e., with humans involved in the management and configuration of the system) does not seem to be feasible.

For instance, the business perspectives offered by machine to machine (M2M) platforms are quite intriguing for Telecom Operators. However, the development and exploitation of these possibilities implies new approaches to the “normal” way of operating networks and systems. M2M systems will need to dynamically activate/deactivate SIMs and possibly the operation has to be done by the customer directly. This means to decentralize a number of management functions. The impact on the management systems and processes is huge. Operators have to retain the overall control on SIMs, but those are to be managed by several other actors in order to provide a meaningful set of applications and services.

Security and Monitoring applications in homes have similar issues. From a big provider point of view, there is the need to manage and control a large number of sensors determining their working status. The control has to be “individual” in the single home, but it has to be global from the provider perspective, i.e., the Provider should be able to activate/deactivate, and orchestrate several thousands (in perspective millions) of sensors, smart objects, and in general real world objects in quasi real time.

This will require rethinking of the way resources are managed today. The iCore architectural proposition is aiming at supporting solutions for this change of phase.

Internet of Things large systems will stress even more the issues because plenty of sensors and actuators will be considered (e.g., some forecasts point to a situation in which for each square meter there will be thousands of smart objects). These objects will be owned and operated by several actors and environments. On one side this will enrich the capabilities and opportunities related to dealing with these sensors, but on the other end it introduces a lot of difficulties to overcome issues of controlling and orchestrating resources pertaining to different administrative domains. Virtualization will also increase the number of available objects. Consequently the features of self-organization, autonomics and the like are highly desirable and needed in order to run these large

(13)

Date:

30/06/2013 Grant Agreement number: 287708 Page 13 of 136 systems. The iCore proposition is to put together virtualization (for smoothing the different properties of a heterogeneous environment and resources) and self-organization in order to create an intelligent environment of large size, capable to self-govern a great deal of issues (at the time of configuration in real-time as well as during operation).

1.3

Cognition

Virtualization and autonomics are not sufficient in order to cope with the issues posed by future IoT applications. They are unavoidable steps towards systems that have to be intelligent and cope with varying situation in a smart way. An iCore system needs to intelligently organize and orchestrate dynamic resources, but even more importantly, it should be able to extract knowledge from each situation being coped with and to learn how to improve the support to applications. This comprises the capabilities to recognize patterns and to derive knowledge from them. The iCore system will be also capable of exploiting knowledge bases of specific vertical domains (e.g., logistics) introducing learning capabilities that can increase the comprehension of related phenomena. iCore applications can be developed and built on top of these cognitive capabilities. Cognition can be extended at two different levels:

Internally to the iCore system: In this case the system will use cognition in order to govern and dynamically find optimal solutions for the usage of resources of the iCore system (at the single application level as well at a global system level)

At the level of functionalities offered to applications: iCore systems should be able to encompass and use knowledge bases introduced by experts in specific fields and to enlarge the level of knowledge of a problem domain by means of (artificial) reasoning. In this case the iCore system will provide rich and valuable functionalities that applications can use in order to focus on their business goal. For instance, an iCore system could support the geopositioning functionality. In an iCore system this functionality does not only mean that a person or an object will be pinpointed by using location based mechanisms (e.g., GPS positioning). The concept needs to be extended in such a way that cameras, or other information can substitute or integrate the location information. For instance a person entering in an underground parking lot could be located by means of the security cameras or by presence sensors as well as by Bluetooth probes or even by means of activities that s/he is carrying out (e.g., punching a park ticket). From the application point of view the function is a location based one, at the level of iCore it is a much more complex one involving reasoning on and predicting where the person or the object is heading, organizing available resources in order to track it and to drive the location information. Prediction has a lot of value in this case and implies also that the iCore system is able to determine patterns of behavior of people or objects within specific spaces and environment. Collection of data and reasoning about these data set is an integral part of the cognitive capabilities of the iCore architecture.

1.4

Organization of this document

This document aims at giving a general description of the iCore reference architecture and to point to the relevant documentation produced by the project. The description is at a global level and more detailed discussions and explanations are to be found in other iCore deliverables.

The second chapter is focused on the analysis of business requirements as carried out in other documents and a set of architectural principles and guidelines that can be fruitfully applied in order to fulfill the desiderata. As said, the iCore requirements stem from a deep analysis carried out contacting experts and stakeholders in the field of IoT applications. In some respect the chapter could be seen as a top down description of the iCore architecture.

Chapter three is about the use cases being defined by iCore in order to challenge the architecture and to refine and consolidate it. It is the main part of the functional architecture definition. The

(14)

Date:

30/06/2013 Grant Agreement number: 287708 Page 14 of 136 chapter presents the use cases and then it describes the iCore Functional Architecture, the data and the templates that are part of it and the interfaces that can be used in order to exploit the architecture. In this section two other important features of the iCore architecture are presented: the cognitive support of iCore and how iCore deals with and offers security features.

Chapter four is about the technological platforms underlying and supporting the iCore functional architecture. It describes how current and future technologies can be integrated so that an iCore compliant architecture can be developed and deployed.

Chapter five summarizes how the iCore Architecture can fulfill the requirements set forth by experts and stakeholder and the advantages that iCore can offer. In addition there is a section dealing with possible contributions and relationships between iCore and relevant standards in the area of IoT.

(15)

Date:

2.

Requirements Analysis and Design Principles

In this section, we first detail the process followed for the requirement elicitation for the whole project in section 2.1. This includes the link between the use cases and the various requirement sets of the work packages. The general business requirements for the iCore architecture are derived from a number of sources, from documents developed for the architecture definition [2][3], from a business analysis conducted by WP1 [6] and from the bottom up approach advocated by the use cases developed by WP6 [9]. Furthermore many external inputs, e.g., the Stakeholder group, have been considered especially by exchange of information with experts of this sector.

2.1

Requirements engineering process

The engineering process used to elicit the various requirement sets of iCore is described in Figure 1. Firstly, the WP6 is identifying “Use Cases”, which are stories on how to use an iCore platform. These use cases are translated into “User requirements”, still within WP6. These user requirements are expressing the features that should be expected from an iCore Platform. At this stage the iCore platform is treated as a “black box”: there is no internals exposed. From this first level of analysis, the architecture is derived, distributing the features into big components (which are presented in this deliverable). The level of granularity is still coarse. The user requirements are further developed into “Software requirements”, within WP3, 4 and 5. Those software requirements are detailing each feature of the user requirements, and each feature belongs to a component, as described in the architecture of WP2. At a last stage, WP3, 4 and 5 performing the detailed design, in which the technology and detailed architecture allowing to fulfil the requirements is chosen. In this diagram, the green boxes are representing a set of requirements (a set of requirement is also called a “specification”). The blue boxes are representing other kind of documentation (respectively use cases and detailed design items).

Figure 1 iCore specification ecosystem

The process is explained in Figure 2 with an example: firstly a use case, « If Sara falls, then call the doctor », is given. This use case is derived into a user requirement: «The iCore platform shall provide the way to retrieve the velocity of an object ». At this stage, the subject of the requirement is always “The iCore platform” since we don’t detail the internals of the platform. The requirement is again

UC1 User Requirements Software Reqs Detailed Design WP6 WP4 WP5 WP3 WP6 Covers Covers Covers Impl. details Architecture WP2 UC4 UC3 UC2 Software Reqs Software Reqs Detailed Design Detailed Design Req set Other doc Impl. details Impl. details Legend: Translates to

First level design & block view

(16)

Date:

30/06/2013 Grant Agreement number: 287708 Page 16 of 136 developed into a software requirement: « The VO information model shall contain the velocity of a RWO in geocentric reference using ISO 6709 format ». This is an implementable requirement, speaking about a component (“The VO information model”) and a format, but still no technology is given. The last step indicates the technology used for the implementation (a java library) : « Velocities will be formatted and computed using the "GeoTools" java library ».

Figure 2 Example of requirement chain

The objective of this requirement elicitation process is to obtain a set of specifications (3 software requirements sets and the architecture) which together form the reference specification for the iCore platform. This set of documents shall be sufficient for the implementation of an iCore platform. In Figure 2, the blue arrows are materialized by “traceability tables”, for which an example is given in Figure 3. This is a two-way table, in which the link between a use case and a user requirement should be made visible. The same table is produced to show the link between user requirements and software requirements. All use cases should be covered by at least one user requirement.

Conversely, all user requirements should be covering at least one use case. Optionally, this table can be completed by a “justification table” (visible on the right), in which a rational is given for each link.

Figure 3 Traceability & justification table The phrasing to use in the requirements is the following:

• User requirements: « The iCore platform shall provide <this feature> »

• Software requirements: « <This iCore component> shall provide <this detailed feature> » UC-1.1 « If Sara falls, then call the doctor »

WP6 Ambient Living Use case:

UR-F-1.1 «The iCore platform shall provide the way to retrieve the velocity of an object »

WP6 User Requirements:

SR-VO-F-1.1 « The VO information model shall contain the velocity of a RWO in geocentric reference using ISO 6709 format »

WP3 Software Requirements:

« Velocities will be formatted and computed using the "GeoTools" java library »

WP3 Detailed Design:

UC-1.1 UC-1.2 UC-1.3 UC-1.4 UC-1.5 UC-1.6 Justification

UR-F-1.1a X

Representing vertical velocity is necessary to

track Sara’s falling UR-F-1.1b X Etc. UR-F-1.2 X UR-F-1.3 X X UR-F-1.4 X UR-F-1.5a X UR-F-1.5b X X UR-F-1.6 X UR-F-1.7 X UR-F-1.8 X Use Case U se r R e q u ir e m e n ts

(17)

Date:

30/06/2013 Grant Agreement number: 287708 Page 17 of 136 The “iCore components” are defined in the D2.3 architecture deliverable (this document). Each set of requirement (User requirement or Software requirement) may contain both functional and non-functional requirements. A non-functional requirement is feature oriented, for example «The iCore platform shall provide the way to store the position of an object », whereas a non-functional requirement is quality and performance oriented, for example «The iCore platform shall support at least 100 users at the same time».

Finally, the requirements of iCore should conform to the quality criteria detailed in the Table 1:

Criteria Explanation

Unitary

(Cohesive) The requirement addresses one and only one thing.

Complete The requirement is fully stated in one place with no missing information.

Consistent

The requirement does not contradict any other requirement and is fully consistent with all authoritative external documentation.

Atomic (Non-Conjugated)

The requirement is atomic, i.e., it does not contain conjunctions (otherwise, make two requirements).

Traceable

The requirement meets all or part of a business need as stated by stakeholders and authoritatively documented.

Current The requirement must not be made obsolete by the passage of time. Feasible The requirement can be implemented within the constraints of the project.

Unambiguous

The requirement expresses objective facts, not subjective opinions. It is subject to one and only one interpretation.

Specify

Importance The requirement must specify a level of importance (i.e. priority).

Verifiable

The implementation of the requirement can be determined through basic possible methods: inspection, demonstration, test.

Table 1 Requirements criteria

2.2

Business Requirements

Some general business requirements are clearly put forward.

There is a clear need to have solutions that do not depend from a particular technology or protocols, the concept of platform (and iCore is an architecture that leads to the definition and implementation of platforms) is particularly appreciated. As a platform, iCore needs to support some features: interoperability, openness to several actors, and support to large scale solutions (i.e., systems comprising a large number of sensors and actuators).

Interoperability has to be supported at least from three perspectives:

• a device view, i.e., the iCore architecture shall support a multitude of heterogeneous devices and protocols;

• a knowledge view, i.e., the iCore architecture shall support the definition of knowledge models that describe several aspects of the real world. This knowledge can be declined to describe and determine the knowledge needed to represent and solve challenges in specific

(18)

Date:

30/06/2013 Grant Agreement number: 287708 Page 18 of 136 problem domains as well as the issues related to the iCore system seen as a complex system itself (i.e., self-organization). Different Knowledge sets need to be interoperable and usable in order to solve complex and integrated problems;

• an application view, i.e., the iCore architecture shall support the interoperability needs of different applications that can reside on different application domains, managed by different actors and developed in different contexts with several technologies.

Interoperability is a requirement that can be fulfilled by virtualization. In fact Virtualization of entities and systems is a major architectural principle of the architecture itself.

Openness to several actors has a broad meaning: the iCore architecture should allow the implementation of iCore platforms and solution by different actors (e.g., service providers, telecom operators, communities, or even government agencies). Each instance of the iCore architecture should provide open interfaces (that the single provider can decide to “close or block” according to its own business model). These interfaces can be used in order to introduce new components or mechanisms in the iCore platform, or for controlling and governing the architectural components, or used in order to develop applications that use iCore mechanisms for the advantage of final users. In addition open interfaces have to be provided in order to allow the creation of new mechanisms and applications for orchestrating, improving, personalize the self-organization capabilities of iCore systems. Finally another open interface has to be provided in order to allow the introduction of knowledge about specific problem domains. These interfaces can be made available to experts in order to populate the knowledge base or to applications themselves that will try to derive new knowledge at run time.

Some of these capabilities can be seen under a general requirement of enrichment of the platform, i.e., the possibility to add value by means of new functions, new data or new cognitive capabilities to an iCore system.

The requirement about the capability to deal with large scale system derives from the fact that many stakeholder of the project (e.g., telecom operators, large service providers) have the need to focus not on a single class of applications, but on several ones. The focus is not even at the local level (e.g., managing a small set of local wireless sensors networks, but at a global one (national, international and even worldwide). Already now systems related to the management of Machine to Machine SIMs require the capability to deal with millions of systems, and in addition a clear requirement is also the ability to demand the activation/deactivation of functions to the customer according to his specific business related needs. Self-organization, cognitive capabilities and virtualization of resources come at hand for fulfilling this requirement.

Dealing with plenty of information extracted by potentially millions of sensors exacerbates two requirements of IoT systems: security and privacy. Sensors can be used in very sensitive environments and the security and privacy of applications, data and knowledge models must be guaranteed to Platform Providers (responsible for the leaking of information) and to Service Providers that build applications and services on top of the platform. In addition the treatment of data that often will have a personal valence needs to be ensured according to the privacy framework established in Europe for this purpose. And this is a daunting effort.

Finally the large scale dimension of the iCore approach and the openness yield to the need to support the capability (also offered to final users) to introduce new resources in an iCore system. For this reason, iCore architecture needs to define discovery and registration functions for tracking available and allocated resources and for managing them accordingly to the specific policies established within iCore systems.

(19)

Date:

2.3

General high Level Requirements from D2.1. and 2.2.

In this section, we provide the main requirements categories already defined in the iCore deliverables D2.1 and D2.2.

Beyond what already described in [2] and [3], in this section we also indicate the architecture implications.

We distinguish between Functional requirement Categories and Non-Functional requirements categories.

The following functional requirements categories are identified:

1. Data acquisition and categorization. Data acquisition relates to fulfilling all those actions needed to instantiate the iCore system (i.e. need for formal iCore entity descriptions to enable acquiring information about their status, ownership, purpose etc.). Data categorization must be possible in a very flexible way according to the structure envisaged for formal descriptions of iCore entities. 2. Situation Awareness. The iCore framework shall provide the capability to describe the contexts

and to react to changes in the context. Situation awareness includes the concept of proximity among data and services and the capability to formalize proximity areas and assess membership levels of objects within a proximity area (i.e. geographically close, same owner, granted access, connected, same domain).

3. Semantic searching. The iCore framework shall provide the capability for controlled searching and access to data and services. The “controlled” term is related to the access control function. The semantic searching capability shall be distributed and interoperable across different domains.

4. Autonomic and cognitive service lifecycle management. The iCore framework should be able to adapt to changes in an autonomic way. This autonomic function is based on a continuously executed cognitive cycle (i.e. monitors, analyses, decide, actuate) continuously improving the outcome of service actuations and the weight of influence from sensing / participating objects (e.g. energy use optimization).

5. Directory Services. Maintain and log service usage history, useful compositions of objects, rating of iCore objects.

The following non-functional requirements categories are identified:

6. Performance and scalability. iCore shall provide means and functions to support scalability and support the validation of performance requirements and their matching to systems constraints. 7. Interoperability. iCore shall be interoperable for data and functions among different domains. 8. Security & Privacy: Availability. iCore shall provide the capabilities to support service continuity. 9. Security & Privacy: Confidentiality/Data protection and Privacy. iCore shall provide capabilities

to regulate access to data and services. This category includes also Data protection and Privacy requirements. This also means anonymization or pseudonymization on the one hand and using the minimum set of data needed for the use case in the other hand.

10. Security & Privacy: Integrity. iCore shall provide the capability to guarantee the logical correctness of the processes and the consistency of the data structures and occurrence of the stored data.

11. Security & Privacy: Authentication/Authorization. iCore should provide the means to establish the validity of a transmission, message, or originator, or a means of verifying an individual's authorization to receive specific categories of information.

12. Security & Privacy: Non-repudiation. iCore shall provide functions for the proof of delivery and the recipient is provided with proof of the sender's identity, so neither can later deny having processed the data.

(20)

Date:

2.4

Business Use Cases

In this section the following steps are taken:

• Taking inventory of use cases

• Derivation of a limited number of “generalized sub-use cases” from the use cases

• Derivation of high level user requirements from the generalized sub-use cases

• Derivation of functional architectural requirements for the iCore architecture

This section talks about how iCore could be used in a business setting. The term business should be

understood in broad terms, not necessarily in the financial sense. For example, a public authority may provide IoT Services to a public university in exchange for research results.

We would like to address this from two main angles

• The use of sensor data by third parties

• The provision of services based on the platform. Use of sensor data

Assume an organization wants to build an application and has a choice between two options: 1. Deploy, operate and maintain the required sensors and the Sensor and Actuator Network

(SAN).

2. Buy the sensor data from an organization that already operates and maintains a SAN with the required sensors and a suitable availability.

Option 1 is costly and Option 2 would be a good business case provided an agreement can be made regarding, among others, safety, security, and (open) interfaces. Also for the owner of the

operational SAN an agreement would be attractive if the costs of opening up the sensors to another organization are lower than the revenues from the sensor data and provided the agreement would also address security from the SAN owner perspective.

The second option can best be illustrated with a number of cases, the majority of them derived from the actual iCore WP6 use cases.

Case 1. Consider two cameras a few kilometers apart with a view on a highway section and deployed

by the road management authority. The road management authority uses the cameras for traffic flow observation and counting the number of cars in the section to set an appropriate speed limit. The same cameras, augmented with license plate recognition can be used to identify speeding vehicles by the police department.

Case 2. Given the scenario of Case 2, the same cameras can be used by the general public to check if

it is time to go to the office or better to continue working from home while waiting for the traffic jam to dissolve.

Case3. Consider a Smart Home equipped with many sensors, such as cameras, smoke detectors, burglar alarms, CO2 detectors. The dwellers of this smart home also turn out to be elderly people. A health care service could offer a monitoring system, coupling the sensors to the iCore platform and somehow commercialize or provide this service to the authorities.

Case4. Consider case X. The residents of the smart home is in this case are well to do people.

Insurers or security companies can use the iCore platform, couple the sensors and provide a monitoring service or offer discounts on the insurance premium.

(21)

Date:

Case5. Transport operators can also deploy many sensors in their warehouses, their transported goods and in their distribution centers. They can use the iCore platform for intelligent monitoring of the transported goods.

3.1.1.2 Service Provision

Case6. Consider a service provider wants to leverage the iCore platform by providing applications on top of it. It could sell the complete package to third parties, either as a service or on premise.

Case7. Consider a service provider that runs and maintains an iCore installation, without being concerned with the applications that run on it. Third parties will pay the provider for the maintenance while providing the applications and sensor / actuator devices themselves. Use Cases Requirements

In WP6 a number of use cases is studied. For a complete description we would like to refer to [5] and [7]

• Smart Home – Ambient Assisted Living

The output streams of medical sensors are analyzed and exceptional combinations of values are reported for further action.

• Smart Business – Monitoring in the logistic chain

The sensors in containers with perishable food give warnings that allow for optimized transport and minimizing food waste.

• Smart Meeting – Organizing a business meeting.

This use case is not about selling sensor data to other parties, but rather to combine the cognitive capabilities and the virtual sensor and actuator objects of the iCore Platform with the purpose to make life easier for the meeting organizer and participants.

The use cases are a, often complex, composition of a number of generalized sub-use cases. The following generalized sub-use cases have been identified.

• Sell/Buy generalized use case

Party S is an owner of a sensor network, and prepared to Sell sensor data to recover part of the costs of operating and maintaining the sensor network. Party B is reluctant to install and operate his own sensor network and prefers to Buy sensor data.

• Data Enrichment generalized use case

Party E offers services (such as anomaly detection, recognition services, storage) to Enrich streams of sensor data. Party A has access to sensor data streams and needs for an application to Apply the enrichment service. Party A prefers to buy the data enrichment service (Software as a Service, SaaS) over building the enrichment functions himself.

• Non-commercial generalized use cases

The Sell/Buy generalized use case and the Data Enrichment generalized use case occur in non-commercial settings. When the selling and buying parties are applications within the same organization, the non-commercial user requirements remain, but now from a sound software engineering point of view.

• Device manufacturers generalized use case

Party D produces Devices (sensors and/or actuators) and wants to innovate these devices without cannibalizing his own products. Furthermore, D wants to compete with other device suppliers without customers objecting to change of supplier due to high change costs.

(22)

Date:

30/06/2013 Grant Agreement number: 287708 Page 22 of 136 Party M has multiple customers that bring devices from different device manufacturers into his environment; per device manufacturer there might even be multiple generations of devices. M wants to interact with all devices in a uniform way.

• Mobile sensors generalized use cases

Party U uses sensors1 that are by nature mobile (cars, mobile phones). Every time U uses his application the appropriate set of sensors needs to be established.

• Service Provider Use Cases

In the case of Smart Meeting, an application is sold that is based on the iCore platform, and delivered as a turnkey solution on the customer’s site. In this case, the software and the platform would be sold as a bundle.

Alternatively, the application could be offered in a SaaS setting, the iCore platform potentially serving multiple applications.

• Other generalized use cases?

A service provider could offer the iCore platform to third parties so they can write and run their applications. The third party is also responsible for providing and connecting the sensors.

From the Sell/Buy generalized use case we can derive a number of user requirements:

• Commercial user requirements

For S the costs of opening up the sensor data to B and other interested parties should be lower than the revenues from selling the sensor data.

For B the business case of buying the sensor data should be better than the case of installing and operating a sensor network. And B wants to avoid a lock-in by S – if in the future the sensor data can be bought from other parties at a better price the switching costs should not be prohibitive.

For both, flexibility in billing arrangements, from a lump sum for access to all sensors of S for an agreed period to an amount per single sensor reading, is required. Usage information is needed to set the right type of financial arrangement for each sensor or group of sensors.

• Security and safety requirements

For S the integrity of the sensors and the network of S should not be violated. Furthermore, only B should get access to the sensor data bought. And B should only get access to the sensor data bought, and not to data from other sensors operated by S. Note that access to sensor readings and assess to other sensor data (such as the last calibration date or geo location) might be different.

For B the access to the sensor data of S should not create a hole in the security system of B, allowing malware to enter the network of B.

• Operational requirements

For S the normal operations of the sensor network should not be hampered by opening up the sensor network to B, and possibly other parties. For instance, replacement of old (types of) sensors by new ones, potentially with more functionality and higher accuracy, should remain possible.

1_{Mobile sensors should be distinguished from (smart) tags. Tags (bar code, RFID, smart tag) are attached to products and}

are being sensed by a sensor. Mobile sensors, such as a GPS sensor, themselves sense their environment and produce and communicate their sensor values. In particular for smart tags, e.g. logging temperature over time until being read, might be confused with sensors.

(23)

Date:

30/06/2013 Grant Agreement number: 287708 Page 23 of 136 For B it is essential to get all relevant (API) documentation of the functions offered by the sensors of S. Furthermore, an SLA per type of sensor is required. B also needs means to establish the current set of deployed sensors, since sensors might be temporarily out of order (for instance due to

maintenance).

From the Data Enrichment generalized use case we can derive a number of user requirements:

• Commercial user requirement

For E/A it should be possible to sell/buy SaaS for well-defined input streams. The enriched data stream should be considered a ‘higher level sensor’.

For A SaaS provider lock-in should be avoided.

• Security and safety requirements

For A it should be possible to transfer the access rights to the input streams to E or E should be able to provide the enrichment services including access to the required input stream(s) of sensor data. From the Device manufacturers generalized use case we can derive a number of user requirements:

Different sensor and actuator hardware with the same functionality should have, as much as possible the same interface.

From the Mobile sensors generalized use case we can derive a number of user requirements:

Party U should be able to establish the current set of relevant deployed sensors, even if the sensors are mobile.

From the Service Provider use case we can derive a number of user requirements:

The iCore platform should be able to be deployed as a service.

The iCore platform must have the possibility to deployed as a complete package.

From the user requirements that originate from the generalized use cases, the following high level functional architectural requirements can be derived.

a. Virtualization

The hardware and embedded software of the sensor or actuator should be encapsulated by a virtual counterpart and this virtual counterpart should offer a well-documented interface to the IoT.

b. Enrichment

The architecture should provide means to combine and enrich the data from one or more sensors into ‘higher level sensors’.

c. Discovery

The architecture should provide means to discover the relevant set of ordinary and higher level sensors, given certain ‘relevance criteria’. The discovery mechanism should take into account that

• the party doing the discovery (buyer) might have a different frame of reference than the party offering the sensor data (seller);

(24)

Date:

• the sensors can be mobile. d. Security

The architecture should offer a fine-grained security mechanism, allowing authorised access to just the sensor data sold/bought in a party setting (i.e. distributed and multi-domain).

e. Platform multi-tenancy. The architecture should allow the running of multiple

compartmentalized vertical application stacks. It is recognized that the same could be achieved at a higher level by running different instances in different virtual machines. Still, there must be a mechanism to associate the sensors and actuators to the correct instance.

2.5

High Level Architectural Principles

The iCore architecture is designed in order to support virtualization and enriching the IoT environment with cognitive capability. The iCore virtualization architecture is based upon the concept of Virtual Object (VO). It is a representation of real world objects capable of providing ICT related functionality. A Virtual Object (VO) is a semantically and functionally enriched representation of a real world object. Semantic enrichment means that the object is described in its state, location, functionality, potential uses or features/functionalities. Semantic enrichment may be the outcome of learning and knowledge generation. The precise definition of a VO is given below.

Definition: A VO is the virtual (abstract) representation of an ICT object that is associated with a non ICT object. Indeed, the act of ‘installation’ brings the ICT object in a specific real-world context, which in iCore modeled as an association to one (or more) non-ICT objects. VOs indeed help in accessing the real world objects and helps interfacing them (after abstraction) to the external world.

Virtual Objects can be seen as providing a very basic set of functionalities representing the actual functions of a Real World Object. Actually the iCore architecture introduces three more basic principles for dealing and transforming Virtual Objects into more usable and service bound entities, they are:

Aggregation: The functionalities of a group of virtual objects can be collected, represented,

coordinated and controlled by other virtualized entities. In addition these functionalities can be mashed up, i.e., the functionalities of different Virtual Objects can be integrated in order to make them generic and available in more applicable ways to applications or to create new functionalities made possible by the integration of the functions of the single Virtual Objects.

Abstraction: The functionalities of a Virtual object can be generalized and abstracted in order

to make them applicable to a large set of situations and requirements.

Functional Enrichment: A virtualized entity trying to mimic and represent the functions

offered by a real world object, this entity can be further extended by adding new functionalities that are made available in the virtual environment. These functions can be of cognitive nature allowing in this way to add intelligence and other properties to a virtualized entity or aggregation of them.

With this in mind, another basic component of the iCore architecture can be introduced now; it is called Composite Virtual Object (CVO), i.e., a virtual aggregation of different Virtual Objects that can be functionally extended by introducing new functionalities and logic with respect to the functional requirement of applications or the systematic needs of the iCore environment. In a more formal way: Definition: A Composite Virtual Object (CVO) is a mash-up of VOs that renders services in accordance with user/stakeholder perspectives and application requirements.

Here we note that a CVO may indeed has only one VO but still it could be a CVO if it has built some more cognitive functionalities which are not possible/available in the included VO.

(25)

Date: 30/06/2013

Though a VO becomes existent immediate

need to be served. In order to understand a service request (user/stakeholder or application), a set of rules needs to be defined to form an appropriate CVO. In iCore terminology, the Service Logic accomplishes this task. It analyses various service requests and map them dynamically to a CVO. Definition: Service logic is the logic reflecting what a particular service (application) does according to the iCore Service Model at various implementat

In general, service logic is the cognitive task capability built in (SL) which helps in breaking the requested services into functions and scheduling them in the proper order to with the help of CVOs and VOs.

Another important goal of the iCore architecture is to allow applications to access to a well structured and rich set of service functions to be used in order to ease the application design ensuring at the same time the fulfillment

In order to support this requirement, the iCore architecture is adopting a new concept called

servitization principle.

Definition: Servitization is the capability of creating a link between a (physical) product and a set of services and enriched functionalities that extend, complement, and add value to the product itself. Servitization is a means to create a continuum between a product and a set of remote functionalities that augment the capabilities and the properties of the p

functions either in the physical or virtualized environment. That is, the architecture is structured in such a way to identify very early a set of generic services (i.e., a set of widely reusable and accessible functionalities and capability stemming from the functions offered by VOs and CVOs or generically by the iCore entities). Another way to consider this principle is the possibility to build a set of services around CVOs or even VOs. Figure

Figure 4. An initial View on some iCore Principles and Entities

The advantage of iCore with respect to other Internet of Things related activities is strongly related to the “cognitive enrichment” of virtualized entities, but is also lies on the application of several

principles like, abstraction, aggregation and extension of functionalities that a virtualized environment usually allows. In addition the servitization principle h

striving towards the definition of widely reusable functions that can be organized into consolidated services that applications can use in order to achieve their goals.

Grant Agreement number: 287708

Though a VO becomes existent immediately after installation, a CVO is formed only when a service need to be served. In order to understand a service request (user/stakeholder or application), a set of rules needs to be defined to form an appropriate CVO. In iCore terminology, the Service Logic accomplishes this task. It analyses various service requests and map them dynamically to a CVO.

is the logic reflecting what a particular service (application) does according to the iCore Service Model at various implementation stages of the service in the iCore system.

In general, service logic is the cognitive task capability built in (SL) which helps in breaking the requested services into functions and scheduling them in the proper order to with the help of CVOs Another important goal of the iCore architecture is to allow applications to access to a well structured and rich set of service functions to be used in order to ease the application design

fulfillment of strict functional goals of the applications.

In order to support this requirement, the iCore architecture is adopting a new concept called is the capability of creating a link between a (physical) product and a set of vices and enriched functionalities that extend, complement, and add value to the product itself. Servitization is a means to create a continuum between a product and a set of remote functionalities that augment the capabilities and the properties of the product and relate it to other products and functions either in the physical or virtualized environment. That is, the architecture is structured in such a way to identify very early a set of generic services (i.e., a set of widely reusable and accessible

nctionalities and capability stemming from the functions offered by VOs and CVOs or generically by the iCore entities). Another way to consider this principle is the possibility to build a set of services

Figure 4 represents these concepts.

. An initial View on some iCore Principles and Entities

The advantage of iCore with respect to other Internet of Things related activities is strongly related to ognitive enrichment” of virtualized entities, but is also lies on the application of several

principles like, abstraction, aggregation and extension of functionalities that a virtualized environment usually allows. In addition the servitization principle helps the iCore architecture in striving towards the definition of widely reusable functions that can be organized into consolidated services that applications can use in order to achieve their goals.

Page 25 of 136 ly after installation, a CVO is formed only when a service need to be served. In order to understand a service request (user/stakeholder or application), a set of rules needs to be defined to form an appropriate CVO. In iCore terminology, the Service Logic (SL) accomplishes this task. It analyses various service requests and map them dynamically to a CVO.

is the logic reflecting what a particular service (application) does according to ion stages of the service in the iCore system.

In general, service logic is the cognitive task capability built in (SL) which helps in breaking the requested services into functions and scheduling them in the proper order to with the help of CVOs Another important goal of the iCore architecture is to allow applications to access to a well-s

icore Internet Connected Objects for Reconfigurable Ecosystem

Internet Connected Objects for Reconfigurable Ecosystem

Dissemination Level

iCore

Version: Due Date: Delivery Date: Nature: Dissemination Level: Lead partner: Authors: Internal reviewers: 2.0 M16 30 June 2013 Report PU Telecom Italia

TCS, VTT, SIE, ALUB, CRF, ATOS, AMBIENT

Roberto Minerva (Editor) + see contributors , AMBIENT

Abstract

Contributors

First Name Last Name Affiliation Email

Table of Acronyms

Acronym Meaning

Table of Contents

1. Introduction ... 11

3. The iCore Functional Architecture ... 31

4. The iCore Technology Architecture ... 81

6. Conclusions and steps forward ... 132

List of Figures

List of Tables

Introduction

Virtualization

Large scale systems

Cognition

Organization of this document

Requirements Analysis and Design Principles

UC-1.1 UC-1.2 UC-1.3 UC-1.4 UC-1.5 UC-1.6 Justification

Criteria Explanation

Atomic (Non-Conjugated)

Unambiguous

Business Requirements

General high Level Requirements from D2.1. and 2.2.

Business Use Cases

High Level Architectural Principles