BUTLER Integrated System Architecture

This page describes the Integrated System Architecture of the BUTLER European project (FP7) presented in deliverable 3.2.

The purpose of this document is to present the consolidated architecture of the BUTLER system as the result of the project work on its second year. It also provides a high-level description of the initial pervasive BUTLER proof-of-concept. This deliverable extends and updates the information provided in Deliverable D3.1 – Architectures of BUTLER Platforms and Initial Proofs of Concept, providing a much more elaborated architecture proposal.

  • Latest version ID: 1.5
  • Tags: , , , , , , , , , ,
  • Latest update: October 23, 2014
  • Developed by: BUTLER project
  • Relations:
    • IoT-A Architectural Reference Model (more details)
      • Relation type: Reference relationship
      • Validation: The BUTLER Architecture is compliant with IoT-A Architectural Reference Model. IoT-A has had a major influence on BUTLER through its Architectural Reference Model (ARM)
      • Completeness of the relation: 100%
    • BUTLER Smart Office Trial (more details)
      • Relation type: Reference relationship
      • Validation: This field trial is built upon BUTLER architecture. A mapping has been of the trial deployments on the architecture model has been done in BUTLER Deliverable D5.2.
      • Completeness of the relation: 100%
      • BUTLER Smart Shopping Trial (more details)
        • Relation type: Reference relationship
        • Validation: This field trial is built upon BUTLER architecture
        • Completeness of the relation: 100%
        • BUTLER Smart Parking Trial (more details)
          • Relation type: Reference relationship
          • Validation: This field trial is built upon BUTLER architecture
          • Completeness of the relation: 100%
          • BUTLER Smart Health Trial (more details)
            • Relation type: Reference relationship
            • Validation: This field trial is built upon BUTLER architecture
            • Completeness of the relation: 100%
            • BUTLER Smart Transport Trial (more details)
              • Relation type: Reference relationship
              • Validation: This field trial is built upon BUTLER architecture
              • Completeness of the relation: 100%
              • sensiNact (aka. BUTLER Smart Gateway) (more details)
                • Relation type: Re-use relationship
                • Validation: The sensiNact Platform is a key component of the BUTLER Integrated System Architecture. This Library implements the model described in the BUTLER Architecture.
                • Completeness of the relation: 100%
                • BUTLER Device Data eXchange (DDX) (more details)
                  • Relation type: Reference relationship
                  • Validation:
                  • Completeness of the relation: %
                  • Gemalto - Trust Manager (more details)
                    • Relation type: Re-use relationship
                    • Validation: The TrustManager Smart Server is fully compliant with the BUTLER Architecture model and provide an implementation of the security services defined in the BUTLER Architecture.
                    • Completeness of the relation: 100%

                  Intellectual property rights (IPR)

                  @BUTLER

The full specification of the Architecture is available in BUTLER project deliverable 3.2. We reproduce here the introduction, executive summary and first section (high level architecture) of the document.

Introduction

Purpose of the document

The purpose of this document is to present the consolidated architecture of the BUTLER system as the result of the project work on its second year. It also provides a high-level description of the initial pervasive BUTLER proof-of-concept. This deliverable extends and updates the information provided in Deliverable D3.1 – Architectures of BUTLER Platforms and Initial Proofs of Concept, providing a much more elaborated architecture proposal.

Intended Audience

The report is firstly a working document for the project partners as it reflects the expertise of the project members, their assets and their wills and defines therefore path for future project activities. The document also targets members of other IoT related projects and more especially the one from the IERC and the FI-PPP clusters. The purpose is to inform these projects about BUTLER intentions so to encourage other projects to react to provide advices based on past work (this apply in particular for projects such as IoT-A or FI-WARE) or identify possible synergies (this apply for recent projects such as iCore).

Finally, the report and more especially its comprehensive state of the art section should provide a sound reference to any technical stakeholder wishing to increase it IoT related knowledge.

Document Structure

According to its title and purpose, this report comprises two main sections: Section 4 is devoted to the architecture the BUTLER project has devised in order to meet its requirements and the scenarios supported by its proofs of concept; Section 5 focuses on the description of the BUTLER initial pervasive proof-of-concepts, describing each of the scenarios supported in said proof-of-concept.

The structure of Section 4 (BUTLER Architecture) is as follows:

  • Section 4.1. refreshes BUTLER architectural layout, describing its four layers: Communications, Data/Context Management, Services and System/Device Management.
  • Section 4.2. provides a high-level overview of BUTLER Architecture, introducing its more relevant functional components and the way they are mapped to the BUTLER architectural layering.
  • Section 4.3. introduces the BUTLER Information Model. It describes the main conceptual entities BUTLER handles. It is heavily influenced by the IoT-A Reference Model and contains extensions, inspired by FI-WARE, to explicitly handle context.
  • Section 4.4. shows the most relevant interactions and concepts provided by BUTLER. The purpose of this section is to teach any reader how the BUTLER architecture works in practice and how different functional components co-operate with each other to provide the described functionality. The following key concepts have been identified:
    • BUTLER Deployment Model: It describes how the different functional components described in the BUTLER Architecture can be deployed on entities playing the different roles BUTLER supports (SmartObject, SmartServer and SmartMobile)
    • BUTLER Service and Resource Model: This model offers a way to represent the capabilities provided by a SmartObject in terms of Resources and Services. SmartObject Services are exposed by SmartObjects and group a number of Resources.
    • BUTLER Security Services: This section described how security is implemented within BUTLER, by introducing an Authorization Server that handles the secure dialogue between Resource Consumers and Resource Providers.
    • BUTLER SmartObject Addressing: A comprehensive description on the mechanisms to address SmartObjects is provided.
    • BUTLER Localization Management: This section shows how the location of SmartObjects is handled.
    • BUTLER Data Discovery and Data Marketplace: This section introduces the mechanisms for Device Owners and Service Developers to define and discover data sources and virtual entities. It also describes how Device Owner creates Data Offerings (from SmartObjects) that can be purchased by Service Developers for its integration in BUTLER applications.
    • BUTLER Context Management: This section describes the general-purpose context management BUTLER has implemented. It relies on Complex Event Processing.
    • BUTLER User Profile Management: A description of how the BUTLER user’s profile is managed.
  • Section 4.4.8 specifies each of the functional components the BUTLER architecture is made of. It is structured according to the BUTLER architectural layering and follows a common schema (description, interaction with other functional components, and main operations provided).
  • Finally, Sections 4.6. and 4.7. show the dependencies between BUTLER requirements and scenarios and the functional components of the BUTLER architecture.

Suggested Previous Reading

This document can be read without any prior knowledge of BUTLER. However, to make the user get the most of it, the following BUTLER deliverables and external information should be read first:

Executive Summary

The main objective of BUTLER is to support the construction of pervasive applications that make use of heterogeneous devices (SmartObjects in BUTLER parlance), based on different protocols and standards. Said pervasive applications aim to improve daily user activities in different domains taking into account contextual information (user needs, preferences and location, status of the physical entities the user interacts with and so on).

The interworking between the different elements of the BUTLER architecture is, at first sight, really simple: users invoke applications that utilize user data, contextual information, location information and predicted behavior to achieve their purposes. As part of said purposes, applications also request actuators to execute an action. To enable applications implement their functionality, BUTLER takes the raw information generated by users and devices and shuffle it to create rich contextual information, to calculate precise location information, or to predict user behavior. Access to devices in order to actuate on them is also provided. This apparently simple approach poses many challenges on BUTLER. To name a few, BUTLER has to be able to gather information from the physical environment through devices supporting disparate communication technologies, application protocols and data models (nothing new for any IoT project). BUTLER has to be also able to provide efficient ways to declare and compute contextual and location information, as well as predict user behavior. BUTLER has to achieve all of this in a secure way so that only authorized parties access the devices that gather information from the physical environment or actuate on it. Other key security services, namely integrity and confidentiality, have also to be guaranteed when communicating with devices. Finally, some business models that BUTLER can support involve the supply of data mediated or inferred by BUTLER to third-parties wishing to use it to create new applications. Additional challenges have to be confronted with when taking into account the different deployment scenarios BUTLER supports. Indeed, the different functional components the BUTLER architecture comprises can be distributed across entities playing the different roles defined in BUTLER: SmartObjects (with the SmartObject Gateway companion to integrate different types of devices), SmartServers and SmartMobiles. It is obvious, for instance, that if a robust and comprehensive context generation functionality is wished, the involvement of one, or several, SmartServers is needed. However, basic or limited context generation processes can be implemented in a SmartObject Gateway without requiring the involvement of a SmartServer.

BUTLER has not intended to reinvent the wheel. On the contrary, it has taken advantage of existing efforts, either within the framework of the research-related EU initiatives, such as IoT-A or FI-WARE; or supported by other industry standards body, such as OMA, OAuth, SAML 2.0 or OSGi. When they provide a valid solution for fulfilling BUTLER requirements, said efforts have been taken as input of the BUTLER architectural choices and even taken “as is”.

The BUTLER Architecture structures according to four layers. The Communications Layer deals with the communication infrastructure and the means that enable the communication between the entities playing the different roles (SmartObject, SmartMobile and SmartServer) defined in BUTLER. The Data / Context Management Layer is somehow the cornerstone of BUTLER as it has to cope with the task of gathering and processing information from data sources (mainly in SmartObjects) to make sense of it and thus computing contextual and precise location information or predict user behavior. The Services Layer is responsible for providing all the necessary means for the construction of pervasive BUTLER applications. Finally, the System / Device Management Layer provides the means for the management and monitoring of SmartObjects and of all the functional components the rest of layers are made of.

IoT-A has had a major influence on the BUTLER Information Model. One of the main findings of the IoT-A Domain Model is the explicit differentiation between the actual resources a device provides and the virtual entities that represent entities from the real world. Such a separation has been inherited by BUTLER, as it provides a clear and straightforward approach to the management of context. It seems obvious that contextual information is tied to an “entity” and therefore, as the IoT-A Domain Model introduces clearly such an abstraction, BUTLER has decided to follow it. However, the IoT-A Domain Model does not introduce an explicit context abstraction. Therefore, we have considered FI-WARE, as it does provide such an abstraction (inherited from OMA Next Generation Services Interface). That way, we have associated context to virtual entities and provided a set of functional components that enable a general-purpose context management functionality hosted by a SmartServer. Thus, BUTLER enables users to pick up the virtual entities they are interested in and to declare what the context associated to those entities means for them. Next, BUTLER is able to collect data from different data sources, usually associated to SmartObjects, mix data sources in real-time, generate contextual information and deliver to the BUTLER context-aware applications. Thus, BUTLER has focused not only in the delivery of contextual information. On the opposite, we have tried to analyze all the steps of the process, enabling the users of the contextual information to declare what context means for them. Finally, we have not used the IoT-A Functional Model as it is too abstract for the concrete realization of BUTLER (as it is not our purpose to deploy a fully-compliant IoT-A system). We have taken advantage of the discovery concepts it introduces, but have merged all the data discovery capabilities in a single functional component, including also an explicit feature dealing with the management and discovery of virtual entities (something missed in the IoT-A Functional Model and that makes much sense when supporting scenarios where the end-user query the system, find out which available entities exist and declare how the context associated to said entities looks like).

The key enabler of the integration of heterogeneous SmartObjects is the BUTLER SmartObject Gateway. It implements a Service and Resource Model integrated into a Service-Oriented Architecture (SOA) that allows representing different devices in a homogeneous way, allowing accessing their provided data and functionalities and building then BUTLER applications based on resources provided by various devices. Here Services are meaning a group of related resources a SmartObject exposes (not to be mistaken by an end-user application). A number of associated functional entities support this Service and Resource Model by enabling registration and discovery of SmartObjects and the services and resources they host. In this context, OSGi provides an implementation base to take advantage of SOA, particularly, at the gateway side which needs to manage multiple devices and different protocols.

Security Services are architected around an Authorization Server. Its main task is to authorize a consumer to access a resource (what is exposed by a SmartObject). To do so, the Authorization Server registers resources and delivers necessary access tokens and security material to secure the exchange of messages. OAuth 2.0 is used for this dialogue, but specific formats for the access tokens and procedures for the derivation of security material are introduced. The Authorization Server implements a basic authentication protocol based on login/password paradigm. In case stronger authentication is desired BUTLER architecture allows the introduction of an Authentication Server that supports SAML v2.0.

Localization Management is a key component of any generic IoT-based infrastructure as it enables various types of context-aware applications. The BUTLER solution lies on a Localization Manager that continuously receives raw ranging data (e.g. RSSI, ToA, AoA, etc.) from SmartObjects and in real-time processes these data to estimate the position of unknown SmartObjects by using a specific localization algorithm implemented in a centralized manner in the SmartServer. The Localization Manager uses the common functional components to access information from the SmartObjects and additional functional components to expose the precise localization information it generates.

It has been mentioned previously that the FI-WARE abstractions has been taken as inputs for modeling the context. However, it has not been only helpful with regard to modeling. Another decisive influence of FI-WARE and their sections devoted to data management is Complex Event Management (CEP). FI-WARE introduces a CEP Generic Enabler but although it describes the enabler interfaces, it does not provide too detailed information about its usage in real scenarios. BUTLER introduces a Complex Event Processing engine as a functional component supporting scenarios where data coming from SmartObjects is distributed towards BUTLER applications enabling a rich set of data offerings that is made available to application developers. It is also used to build other functional components, notably those focused on generic generation of contextual information, user behavior prediction, and management of simple events.

To sum up, BUTLER provides a rich set of functional components supporting BUTLER requirements and use cases. Although the set of functionalities is really large, a number of key functionalities have been identified and described in this document. Apart from the aforementioned functionalities (BUTLER Information Model, BUTLER Service and Resource Model, Deployment Models, Security Services, Localization Management, and Context Management), the following ones will be also analyzed: User Profile Management, SmartObject Addressing, and Data Discovery and Data Marketplace).

BUTLER Architecture

BUTLER Architectural Layering

BUTLER was not conceived with a pre-established architecture in mind. Instead, it defined four architectural layers trying to cover all the functionalities needed to fulfill the requirements on a context-aware IoT architecture targeting several vertical domains. At the same time, BUTLER does not aim to reinvent the wheel and, once identified the architectural components it will require to implement the functionalities described in use cases and user stories by means of already defined architectures. Thus, those of FI-WARE or IoT-A will be taken as basis for the definition of the BUTLER functional components. Other frameworks or standardization efforts will be used whenever necessary.

At the same time, it is needed to acknowledge that BUTLER systems are deployed into three different entities: BUTLER SmartObject, BUTLER SmartServer and BUTLER SmartMobile (modeling the devices and gateways, the server and the clients, respectively; see section 4.4.1).

The four architectural layers considered in BUTLER are the following ones:

  • Communications Layer: It handles the end-to-end holistic communication infrastructure –based on standards as much as possible– that will enable connecting SmartObjects (e.g., sensors, actuators), client devices –SmartMobiles– (e.g., smart phones, smart terminals) and service execution platforms (e.g., gateways –SmartObject Gateways–, application servers –SmartServers–).
  • Data/Context Management Layer: It will specify data models, interfaces and procedures for data collection from context data sources (e.g., SmartObjects, information systems) and for processing that data in order to provide context information.
  • System/Device Management Layer: It comprises the necessary components for management and maintenance of SmartObjects, Services and any other system-wide entity, such as configuration, software management, performance management, or diagnostics.
  • Services Layer: It will specify necessary models, components and interfaces for description, discovery, binding, deployment and provisioning of context-aware services.
  • butler arch layering

    The interworking between the different layers can be seen in the figure below: users invoke applications that use the Services Layer to access user data, contextual and location information, and user predicted behavior to achieve their purposes. As part of said purposes, applications also request actuators to execute actions. The Data / Context Management Layer is responsible for providing said information to the Services Layer, by taking the raw information generated by users and devices and processing. Access to devices in order to actuate on them is also provided. All this raw information is raised through the Communications Layer. Finally, the System / Device Management Layer interworks with the rest of layers to handle the management and monitoring of SmartObjects and of all the functional components the rest of layers are made of.

    butler arch layering1

    High-Level Architecture

    BUTLER has not intended to develop a totally new architecture. Instead it has tried to build on existing standards and industry initiatives and therefore to focus on some close EU initiatives, such as IoT-A or FI-WARE.

    IoT-A has had a major influence on BUTLER through its Architectural Reference Model (ARM). It is made of several submodels. The foundation of them is the Domain Model, which introduces the main abstractions of the ARM. One of the main findings of the IoT-A Domain Model is the explicit differentiation between the actual resources a device provides and the entities in the real world. Said entities are represented by means of so-called virtual entities. Such a separation has been inherited by BUTLER, as it provides a clear and straightforward approach to the management of context (see section 4.3. for a discussion on how the IoT-A Domain Model is adapted into the BUTLER Information Model). From an architectural point of view the ARM includes a Functional Model that does not constitute an architectural proposal in itself, but a framework for the modeling of IoT architectures. The IoT-A Functional Model introduces two main entities: the IoT Service Resolution and the Virtual Entity Resolution. The former is a discovery service registering IoT Services (what is exposed by devices). The latter is another discovery service that registers the relationships between the entity attributes and the services that feed such attributes. No explicit entity discovery service is introduced, as the discovery and lookup operations provided by the Virtual Entity Resolution always need to include the type of attribute the user is looking for.

    IoTA

    BUTLER has introduced a simplified discovery infrastructure, the Data Discovery functional component that allows users to look for data sources (from SmartObjects) and also for virtual entities, by means of a geolocalized interface. The main rationale behind this decision is the need to explicitly handle context. The IoT-A Domain Model does not introduce an explicit context abstraction (although it is possible to argue that the attributes associated to a virtual entity are actually the context attributes). In this point, FI-WARE is introduced as it does provide a context abstraction. Following what OMA Next Generation Services Interface (NGSI) standardized, we have associated context to virtual entities and provided a set of functional components that enable general-purpose context management functionalities. Thus, BUTLER enables users to pick up the virtual entities they are interested in and to declare what the context associated to those entities means for them. Next, BUTLER is able to collect data from different data sources, usually associated to SmartObjects, mix data sources in real-time, generate contextual information and deliver to the BUTLER context-aware applications.

    BUTLER implements also a Service and Resource Model that allows representing different devices in a homogeneous way, allowing accessing their provided data and functionalities and building then BUTLER Applications based on resources provided by various devices. In BUTLER, Services are meaning a group of related resources a given SmartObject exposes (not to be mistaken by an end-user application). A number of associated functional entities support this Service and Resource Model by enabling registration and discovery of SmartObjects and the services and resources they host.

    BUTLER archi

    The Communications Layer deals with the communication infrastructure and the means that enable the communication between the entities playing the different roles defined in BUTLER (SmartObject, SmartMobile and SmartServer). It also implements BUTLER Security Services. The Data / Context Management Layer supports the task of gathering and processing information from data sources (mainly in SmartObjects) to make sense of it and thus computing contextual and precise location information or predict user behavior. The Services Layer is responsible for providing all the necessary means for the construction of pervasive BUTLER applications. Finally, the System / Device Management Layer supports the management and monitoring of SmartObjects and of all the functional components the rest of layers are made of. End-user applications do not belong to the BUTLER Architecture, but play the role of clients of the BUTLER functionality. They can be deployed in SmartMobiles or in application servers providing a classic web front-end to end-users.

    The Communications Layer is responsible for enabling the secure connection and the interoperability of the SmartObjects, SmartMobiles and SmartServers (based on IP connectivity). Physical objects use heterogeneous standards, protocols and. These objects shall be able to communicate between each other and with other systems. To this purpose, an IoT Protocol Adapter functional group ensures the interoperability across different communication technologies, hiding the different protocols and standards used by individual objects. The Communications Layer also provides the capabilities for discovering BUTLER SmartObjects. A Device Directory functional component is responsible for storing data and information about the SmartObjects. Since the communication of SmartObjects is usually not reliable, a Network Monitoring functional component is used to continuously check the current status of the network and evaluate the related performances. Moreover, the Communications Layer provides a functional component to manage the connectivity of users’ SmartObjects (which can use different technologies such as 3GPP, Wi-Fi, Ethernet) to the remote or local BUTLER servers. Similar to BUTLER SmartObjects, some functionalities for the maintenance of directories of BUTLER user SmartObjects and BUTLER SmartServers are provided. For security purposes, services for authentication and authorization are also. The authentication and authorization functionalities ensure that only identified and authorized SmartObjects (and SmartObjects) can join the BUTLER network in order to ensure a secure access control and that access to the resources provided by SmartObjects is secured as well.

    The Data / Context Management Layer is responsible for all data- or context-related functionalities, including collection and capturing of different types of data, persistent storage, processing of data as events, either simple or complex, and the definition of context associated to entities. This layer specification includes several functional components and the required data models used by them: context, which represents highly dynamic data, or more static that can be profile/user or device related. A particular type of user data is about the behavior of the user that can be inferred by sensor and contextual information. Both Simple and Complex Event Processing functionalities are provided. Location and User Profile data are also part of this layer and two specific functional components are defined here in order to manage these data. By considering the complexity of user events, context and profile data (like location and movements, preferences, actions, etc.) a specific functional model for Behavior Capturing can produce higher level behavior understanding of the user, in terms of current or expected activities and situations. A generic functionality is represented by Persistent Storage which gives the possibility to applications to store data. Contextual information related to entities is provided by a Context / Behavior Information Provider, which relies on Complex Event Processing to achieve its purposes. Specific functional entities are also modeled to enable the management and acquisition of data sources by users: Data Management and Marketplace Portal, which enables services to discover virtual entities, and Context Management Portal, to manage the context associated to each of said entities

    The Services Layer is responsible for the description, discovery, binding, deployment, and provisioning of BUTLER services. It is also responsible for making said services available to the applications created by service developers. The Services Layer provides also the generic enabler for Data Discovery, which supports the functionalities associated to the discovery and purchase of data sources and to the discovery of entities representing physical entities and the association of context declarations to each of said entities. Finally, an Application Repository and a number of built-in services and applications are also provided as part of the Services Layer.

    Finally, the System / Device Management Layer provides the means for the monitoring and management of SmartObjects, Services, Data Sources, Context definitions and Entities. The functional components it is made of play also a role in the rest of architectural layers

Service level

The Architecture described in Deliverable 3.2 is the final architecture of the project.

THIS DOCUMENT IS PROVIDED "AS IS" WITH NO WARRANTIES WHATSOEVER, INCLUDING ANY WARRANTY OF MERCHANTABILITY, NONINFRINGEMENT, FITNESS FOR ANY PARTICULAR PURPOSE, OR ANY WARRANTY OTHERWISE ARISING OUT OF ANY PROPOSAL, SPECIFICATION OR SAMPLE. Any liability, including liability for infringement of any proprietary rights, relating to use of information in this document is disclaimed. No license, express or implied, by estoppels or otherwise, to any intellectual property rights are granted herein. The members of the project BUTLER do not accept any liability for actions or omissions of BUTLER members or third parties and disclaims any obligation to enforce the use of this document. This document is subject to change without notice.

Technology Readiness Level

2 - technology concept formulated

Reuse Readiness Levels

4 - Reuse is possible; the software might be reused by most users with some effort, cost, and risk.

Security

The BUTLER Architecture include the description of the BUTLER Security Services in section 4.4.3 of the deliverable.