We use proprietary and third party's cookies to improve your experience and our services, identifying your Internet Browsing preferences on our website; develop analytic activities and display advertising based on your preferences. If you keep browsing, you accept its use. You can get more information on our Cookie Policy
Cookies Policy
FI-WARE Internet of Things (IoT) Services Enablement - FIWARE Forge Wiki

FI-WARE Internet of Things (IoT) Services Enablement

From FIWARE Forge Wiki

Jump to: navigation, search

IMPORTANT NOTE: This page is deprecated. Please refer to the most updated description of the FI-WARE Internet of Things (IoT) Services Enablement Architecture


Overview

Contents

Contemporary society is demanding more services based on smart environments all the time. Smart grids, smart metering, home automation, eHealth, logistics, transportation, environmental monitoring are just a few examples of the new wave of services we will be widely using in the following years. These solutions will be driven by the Internet of Things (IoT) where the power of combining ubiquitous networking with embedded systems, RFID, sensors and actuators makes the physical world itself a relevant part of any information system. RFID has played a big role in establishing the concept of an Internet of Things – the term was first introduced by the MIT Auto-ID Center in 1999, the precursor to the current EPCglobal organisation, and at that time stood for the vision of a world where all physical objects are tagged with an RFID transponder with a globally unique ID. Based on this initial work, companies like WalMart in the US and Metro in Europe have built new relationships with their more than 5,000 suppliers to improve supply-chain operations. Technological improvements in RFID and the inclusion of sensing and other technologies have expanded the scope of the Internet of Things and are leading to many new opportunities in the way how communicating things can support new generation lifestyles. In the short-term, it is estimated that the number of M2M devices outnumber end users by at least one order of magnitude [Juniper 11] and some industrial projections indicate that the world market for technologies, products, applications and enabled smart services related to IoT will increase significantly to more than €290 billion by 2014 [Harbour 10]. The relevance of the IoT is not only recognized in the EU, as shown by the report [IoT Brussels 09], Japan, China and Korea already include IoT initiatives in their national R&D programs, and the U.S. National Intelligence Council has included the IoT among the six technologies with potential impacts on U.S. interests out to 2025. The important role of the Internet of Things is also highlighted by the fact that many international standard-developing organizations have established dedicated standardization initiatives on the topic: ETSI TC M2M, ITU-T USN, ISO/IEC WGSN, IETF, W3C, 3GPP.

  • Thing. Physical object, living organism, person or concept interesting from the perspective of an application.

To address the important challenges and opportunities the IoT represents, FI-WARE includes the Internet of Things Service Enablement as one of the chapters to be addressed within the Reference Architecture of the FI-WARE Platform. The IoT Service Enablement chapter comprises those Generic Enablers in FI-WARE enabling a large number of distributed and heterogeneous things and associated IoT resources to become available, searchable, accessible and usable by Future Internet Applications and Services.

Several key technologies must still be developed enabling the Internet of Things vision to become a reality. Current services and technologies for accessing real-world information are typically closed leading to vertically integrated solutions for niche applications. This approach leads to inefficient and expensive service infrastructures that lack interoperability and prevent the true IoT paradigm from being successfully developed. Obviously each vertical domain of business applications can have various types of peculiarities, nevertheless development of cross-domain horizontal solutions, including common functionalities, would lead to more efficient and cost effective solutions. Furthermore, in this way, an infrastructure deployed for use by a vertical solution, can be shared to provide completely different services, opening new business opportunities based on innovative business models. Following this direction the IoT Service Enablement in FI-WARE will provide a set of IoT-oriented Generic Enablers further classified into sub-chapters dealing with: IoT communications, heterogeneous resource management, data handling and process automation. This substrate of IoT-oriented Generic Enablers will provide important efficiency gains in many industries and usage areas, particularly when combined with other FI-WARE Generic Enablers.

The term IoT resource refers to the computational elements (i.e. software running on devices), enabling to gather information about things and act upon them. The number of devices is expected to outnumber the human population by orders of magnitude [Juniper 11], thus the development of efficient means for communication, management and interaction with them will be a necessity, coping with the need to support the co-existence of a variety of existing and emerging communication technologies. Actually, the IoT application environment is extremely heterogeneous, leading to different interaction patterns (push, pull, converge-cast, multicast, periodic, event-based, etc.) and different interaction constraints compared to the current Internet (in terms of reliability, timing, capabilities of devices, etc.) This heterogeneous application environment will thus also entail a pronounced heterogeneity of the underlying communication layers. The IoT Communication function in FI-WARE will allow unified communications regardless of the different network standards and will enable data transfer services agnostic to the underlying connection protocol.

  • Device. Hardware entity, component or system that either measures properties of a thing/group of things or influences the properties of a thing/group of things or both measures/influences. Sensors and actuators are devices.
  • IoT Gateway. A device hosting a number of features of one or several Generic Enablers of the IoT Service Enablement. It is usually located at proximity of the devices to be connected.
  • IoT Resource. Computational elements (software) that provide the technical means to perform sensing and/or actuation on the device. The resource is usually hosted on the device.

Together with communication protocols abstraction it will also address communication service capabilities, discontinuous connectivity, mobility, session management, traffic flow management as well as access security policy control.

Scenario 1. Dynamic association, roaming

Winter 2012 – 7:25 AM, starting the car, David's car device asks for activation regarding traffic and pollution applications. David chooses traffic application and the car device sends a signal to the closer gateway that the vehicle is active and in the traffic. The gateway, based on the planned route home-office defined in the car device, diffuses to the gateways network that a new actuator is alive and the expected time instant when it will roam from the first area (gateway 1) to the second area (gateway 2).

Being able to identify, discover and manage IoT resources is not an add-on but a basic need. However, the devices linked to these resources that have to be connected are per se very heterogeneous in terms of used technology, protocols, capabilities and interaction patterns. Currently, each technology (i.e. ZigBee, 6LoWPAN, etc.) provides some of these functions in different ways. FI-WARE will integrate heterogeneous identification, naming and addressing technologies using unequivocal identifiers. Scalable discovery and look-up will make IoT resources available to all type of applications considering important real-world aspects like location, time, availability, capabilities, quality, etc. It will also provide the necessary functionality to monitor dynamic links between IoT resources and things. Finally, FI-WARE will enable IoT resources to become citizens of the Internet by providing scalable global schemes for deployment, operation, maintenance and fully remote management of these resources, including abstract models for the resources, common resource management interfaces, status monitoring, and fault handling.

Scenario 2. Sensor measurement sharing

During the journey to David's office, the car device receives a short message from gateway 7 to activate weather data collection to draw snow storm progress on the city map. As David is driving, the car device launched a request to the profile database to validate David choices. Based on the latest information, from yesterday 10:00 AM, David has no objection to communicate weather information. Immediately, the car device begins to send temperature, windscreen activity, humidity level…

The IoT realization will imply managing a huge number of highly distributed IoT resources running on devices, which are continuously generating a large amount of data. Efficient data processing mechanisms executing near or adjacent to the resources and generating a smaller set of elaborated data may be necessary, preventing the flooding of the backend system and the storage of large amounts of raw data. In addition, data filtering and routing capabilities have to be placed along the communication path between resources and the backend systems, dynamically adapting the traffic of data to the real demand of application/services at any given moment. The development of new application and services will then rely on the capability to extract information from processed/filtered data applying new generation mining and analysis techniques. FI-WARE will include IoT-oriented Generic Enablers, which would implement the same or a subset of the interfaces defined for FI-WARE Data/Context Management Generic Enablers (Publish/Subscribe GE, Complex Event Processing GE) but would be better suited to run on distributed devices or device gateways and exploit P2P mechanisms. Furthermore, due to the specificity of data handling in de-centralized IoT environments, the IoT Generic Enablers will address data models for dedicated protocols, data models integration and manage relationships between micro databases hosted by IoT resources and other database services. The combination of Generic Enablers running both in distributed locations and centralized backend systems will allow a scalable, elastic and high performing management of the entire Internet of Things.

Scenario 3. Data aggregation

Tomorrow: David wants to go sooner to his office because the home clock screen advertises that weather forecast was too optimistic today and that bad weather will come during the night. The picture, based on 357 climate sensors, shows clearly that the snow storm will arrive around 7:30 AM. When he begins to cook his dinner, his home gateway informs the city eco-management application that a new consumption cycle is planned in this district. All cities till around 100 km from his home are sending information. The 357 sensors indicate clearly that air pressure is falling quickly and some mobile sensors in this area are providing real-time temperature indications. Night would be very cold and a snow storm is now forecast for tomorrow evening.

The full potential of the IoT can only be unleashed when IoT resources and data are composed, aggregated and integrated into processes fulfilling specific business needs. For scalability, this has to happen in an automated and distributed manner. To do so, the IoT Sevice Enablement chapter in FI-WARE will provide several Generic Enablers targeted to support a de-centralized automation of micro-processes, managed over different elements at the edge of the network. These Generic Enablers will be capable to deal with lower granularity, locality of execution, quality of information aspects etc. They will extend other FI-WARE Generic Enablers dealing with orchestration and composition at a higher level, thus providing the secure, configurable and scalable end-to-end process automation required in future IoT Applications.

Summarizing the above, FI-WARE will build the relevant Generic Enablers for Internet of Things Service Enablement, in order for things to become citizens of the Internet – available, searchable, accessible, and usable – and for FI services to create value from real-world interaction enabled by the ubiquity of heterogeneous and resource-constrained devices.

FI-WARE has been conceived as an end-to-end open platform intended to be used in a broad range of IoT application scenarios and by different kinds of users which are the following:

  • FI-WARE IoT instance providers: they provide value added and/or managed services towards IoT customers from different usage areas. For example they could be system integrators or service companies offering turn-key FI-WARE instance installation projects to a government or an enterprise or operating FI-WARE instance as a managed service.
  • IoT application developers: they develop end customer applications utilizing APIs/SDKs. For example, home energy management applications for consumers or for utility companies.
  • IoT end customers: they utilize IoT services as part of their business processes. Alternatively, they can be individual consumers with no programming skills that need to capture and make sense of data and events
    • from the things through the associated devices by means of IoT resources as input to Internet applications and services
    • from the applications and services to drive things through the associated devices (actuators) by means of IoT resources


Image:GEs_of_the_IoT_Service_Enablement_platform_and_its_connections_to_other_technical_chapters.jpg


GEs of the IoT Service Enablement platform and its connections to other technical chapters

Generic Enablers

The deployment of the architecture of the IoT Service Enablement chapter is typically distributed across a large number of devices, several IoT Gateways and the IoT Backend. The Generic Enablers described in this chapter, shown in the previous figure, implement functionalities distributed across IoT resources hosted by devices, IoT Gateways and in the IoT backend.

The IoT Gateway and IoT Backend will interface with each other through an open standardized communication interface. In addition, the IoT gateway will provide a protocol adaptation and control service that will contribute to supporting heterogeneity in the physical world. The protocol adaptation service will handle communication with different devices, while the control service will contain intelligent control logic that will deal with differences between the various implementations of the Gateway and access technologies, as shown in the figure below.


IoT SE “stack” (above), instances of the stack in the backend, IoT gateway and various devices and the control/protocol adaptation service in the IoT gateway (below)


Management functionalities will be provided for the devices and IoT domain-specific support will be provided for the applications. In order to do so, the IoT Service Enablement adopts and integrates the following four technical sub-chapters, each integrating a set of related IoT Generic Enablers:

  • IoT Communications
  • IoT Resources Management
  • IoT Data Handling
  • IoT Process Automation

There are a number of relations between GE-s in the Interface to Networks and Devices (I2ND) and IoT Services Enablement. The Cloud Edge (CE) GE from I2ND is able to locally execute downloadable applications and could be a relevant container for IoT gateways. In particular, CE may host gateway functionality for connecting other devices as mobile. In concrete terms cloud edge will provide mostly virtual machine images in which containers can be executed. CE will provide direct interface to these virtual machines/containers and will support the interface and protocols to a number of devices such as RFID, BT, assuming drivers exist for the associated operating system and relevant protocols/interfaces. The Connected Device Interface (CDI) GE functionality from I2ND might be also acting as hosting capability for the IoT gateway and/or device functionality: it is to be understood if scenarios in which this might occur are required for FI-WARE and/or UA projects. The basic idea is twofold regarding user endpoints (phones, tablets, etc) functionalities:

  • have local sensor(s), in this sense they might act as gateways or proxies for these local sensors, exposing their functionality as an IoT gateway/proxy
  • have local radio interfaces (Bluetooth, ZigBee, WiFi etc) which allows them to access devices/IoT resources in their neighborhood and expose their functionality as an IoT gateway.

The S3C GE from the I2ND technical chapter is relevant in case for 3GPP-based IoT devices.

  • On one hand the S3C GE could be used for key exchange and validation of messages between IoT devices through 3GPP infrastructures
  • Additional point of interest is the caching module, which could be interfaced from our perspective with the IoT Data Handling generic enablers. Device or gateway databases can be handled together with the caching module of the S3C enabler. Yet additionally the network event management component might catch and distribute different events (aggregated events, events from several IoT devices etc) than what one single IoT device can see, this could be used as an additional input for or synchronized with our micro database or cloud hosting databases, especially for real time data.
  • The network connectivity management module could interact with IoT communication GE-s from the perspective of supporting intermittent connectivity and session management.

The following section elaborates on each of our subchapters, describing their target usage, the set of IoT Generic Enablers that compose them and the list of Critical product attributes were added-value is provided.

IoT Communications

Target usage

IoT communications will provide common and generic access to every kind of things regardless of any technological constraint on communications, typically integrating several protocols and manage discontinuity of connectivity for nomadic devices. It will allow Application Providers to gain homogeneous access to dedicated things and devices and to be able to manage Quality of Service in Communication with the devices.

Description of GEs

A communication abstraction layer will be specified in order to integrate different underlying protocols used by various devices and gateways,. This will be based on a uniform protocol view and will be generalised to cover common solutions and technologies in the underlying communication layers.

As a result of the investigation of the state-of-the-art of communication technologies, only a few approaches were found and most of them have not strived for the generalisation deemed necessary for IoT. These are networked RFID systems, wireless sensor networks and machine-to-machine (M2M) communications.

Networked RFID systems use two different communication stacks. The reader-to-tag communication is governed by RFID protocols, while the communication stack between reader and the business logic varies according to the reader’s specification. In the last few years readers have evolved providing better and more complex interfaces to edge and middleware software. Currently, the state-of-the-art readers are also capable of processing raw data, providing information via Secure Socket Layer or Web services. Standalone reader abstraction protocols such as the EPCglobal Reader Protocol (abandoned by EPCGlobal, even though ratified) or WinRFID [Prabhu 06] exist while many middleware solutions leverage on reader device-specific device abstraction drivers. The approaches regarding RFID are determined by relevance of the generalised service and communication interfaces.

The distributed sensor networks and in particular Wireless Sensor Network (WSN) platforms are increasingly used as enabling technologies to create underlying layers of IoT systems and the Real World Internet. These platforms usually implement at the communication layer protocols such as 6LoWPan or at the physical layer IEEE 802.15 based protocols. The current sensor nodes are mainly equipped with radio interface to enable communication between them. This interface is a low power, low range radio system covering physical layer and media access layer. Communication protocols such as 6LoWPAN enable sensor nodes to be directly accessible through the Internet, but some platforms do not support this protocol. The heterogeneous nature of WSNs requires a flexible and interoperable solution to enable seamless communication and interaction between high-level application and services and the underlying network, the platforms existing today are not able to provide these kinds of solutions. Beyond communication layer protocols in the WSN domain the ISO/IEC CD 29182-1 standard [SNRA] aims to specify a sensor network reference architecture which needs to be taken into account when defining the architecture of the IoT technical chapter and its interaction with the other technical chapters in FI-WARE. Sensor Network Reference Architecture [SNRA] is to define an overall framework that will facilitate description and understanding of the interrelation and interaction between the components of sensor network applications and services.

An area of investigation that is closer to IoT needs is machine-to-machine (M2M) communication. M2M interfaces have been originally envisaged to describe the communication between electronic devices used for special purposes, such as sensing, metering and control. Recognizing the importance of M2M technologies, the ETSI in 2009 launched the Machine-to-Machine (M2M) Technical Committee [ETSI-M2M]. The goals of the ETSI M2M committee include developing and maintaining of an end-to-end architecture for M2M, identifying the gaps in current standardization and filling these gaps, targeting sensor-network integration, naming, addressing, location, QoS, security, charging, management, application interfaces and hardware interfaces.

The following key M2M technology trends could be highlighted: dealing with an increased complexity of internetworking M2M networks, devices and data with enterprise applications, networks, devices and data; migration from M2M proprietary bus architectures to Internet-based open standards; evolving from centralized, decentralized and distributed computing architectures towards dynamic and hybrid architectures based on intelligence at the edge of the network. This is a shift in process control enabling, in some cases, autonomous or semi-autonomous control actions to emerge and/or be determined at the edge of the network independent of human or “server” authorisation. Distributed or even autonomous process control however poses challenges regarding management of software, firmware or execution rules as well as overall system reliability. In the M2M area beyond ETSI M2M a number of industry associations were formed which result in de facto interface protocols being specified, created and supported by a number of devices. One such example is the ONVIF forum [ONVIF] that specifies a global standard for the interface of IP-based physical security products. ONVIF is committed to the adoption of IP in the security market. The ONVIF specification will ensure interoperability between products regardless of manufacturer. Another such example is the OpenMeter consortium [OpenMeter] which specifies a set of open and public standards for AMI, supporting electricity, gas, water and heat metering. Another interesting consortium, the Open Geospatial Consortium, has described some relevant technical specifications, mostly well known as Sensor Web Enablement (SWE) services [OGC SWE] which are designed to enable discovery of sensor assets and capabilities, access to those resources and data retrieval, as well as subscription to alerts, and tasking of sensors to control observations. OGC SWE does not have architecture in a strict sense. It defines more collaboration scenarios for the interfaces or languages and protocols. It is important to emphasise that Sensor Markup Language (SensorML) is the central element of the OGC SWE and include definition of the information model or the protocol description and how the various services are accessed.

IoT communication Generic Enablers will utilize the above-mentioned technologies that support communications between distributed things and devices (e.g. gateway and middleware solutions) and will develop standard interfaces and interoperable solutions to coordinate the communication and interaction between things and high-level applications and services. They will also take into consideration the resource-constrained nature of devices and will adopt energy-aware and efficient mechanisms to provide communication solutions between devices, services and applications.

More specifically, the IoT Communication Generic Enablers will provide the necessary communication agents that can be integrated into the IoT Devices and the IoT Gateways, enabling communication with IoT resources from the IoT backend. -

The figure below shows the main Generic Enablers implementing IoT Communication functions. These Generic Enablers will provide altogether at least the following functions:

  • Communication protocols abstraction: a mechanism to enable unified communications between the IoT resources and the IoT backend
  • Communication service capabilities: identification of and communication to IoT resources (identification of an IoT resource includes the mapping of physical network addresses to the IoT resource identifier)
  • Managed connectivity: definition of the interfaces towards the networks for the management of the connectivity
  • Discontinuous connectivity: management of the IoT resources that are not always-on.
  • Mobility: support of the IoT mobility for the IoT resources that may physically move or may change the access network ( e.g.: fixed or mobile, IP or SMS,).
  • Session management: management of the communication sessions to support mechanisms to handle reliability associated to network connections
  • Traffic flow management: development of the mechanisms to deal with abnormal and occasional traffic conditions (e.g. overload traffic conditions)


Architecture of IoT Communications and its 4 GEs


The architecture supporting the IoT Communications functions relies on the existence of four Generic Enablers: Front-end, Naming, Connectivity Management, and Content Control.

The Front-end GE deals with the incoming/outgoing traffic from/to Devices and IoT Gateways. It comprises a number of Connection Protocol Adapters and a component dealing with the Communication Protocol Abstraction Definition. Each of the Connection Protocol Adapters is capable of handling one of the protocols that are accepted in FI-WARE, translating it into a unique internal language, which normalizes the different communication protocols within the platform. The definition of this “internal language” is contained in the Communication Protocol Abstraction Definition that provides a number of “templates” that can be used to translate the protocol (e.g. this translation can be achieved by creating an object, i.e. a “token”, specific for each incoming message type, containing all the data contained in the incoming message, that can be “injected” into the platform; likewise an outgoing token can be translated into a protocol message that will be sent by the platform to the specific Device or IoT Gateway).

The Front-end GE will rely on Security, Privacy & Trust Generic Enablers in order to perform the necessary management of security aspects. As an example, the Front-end GE relies on Security Generic Enablers to decrypt and encrypt the traffic incoming into and outgoing from Devices and IoT Gateways (e.g. managing of the asymmetric cryptography based on public and private keys). It also relies on Security Generic Enablers coping with management of access rights as it will be described later. Additionally, it relies on the IoT Data handling for storing and retrieving the templates from the Communication Protocol Abstraction Definition.

Moreover the Front-end GE exploits also the functions of the Name Resolution GE. This is a GE that can be shared between IoT Communication and IoT Resources Management. For the IoT Communication it translates the physical addresses received by the network into the addresses used internally within the platform and gives support to IoT Resources Management too for other address related functions.

The Connectivity Management GE deals with lower level layers of the communication from/to Devices, IoT Gateways and the Content Control block with higher level layers. It consists of components dealing with Session Management, Mobility Management and Discontinuous Connectivity Management. The Session Management controls the communication session between the IoT Services Enablement platform, the Devices and IoT Gateways. The Mobility Management deals with the Devices and IoT Gateways mobility, both the connection through different Access Networks and the physical mobility of the “things”. The Discontinuous Connectivity Management allows communicating between IoT Gateways and Devices that are not always on. It manages especially the traffic towards them that may need to be cached waiting for the Device or IoT Gateway to wake up.

The Content Control GE is composed by components dealing with Traffic Flow Management, Access Policy Control and Quality of Service Control. The Traffic Flow Management monitors the overload conditions of the IoT Services Enablement platform. In case the platform is under stress conditions it can command the Front-end GE to redirect or reject incoming messages without any further treatment but log the received messages (this component can affect only incoming traffic). The Access Policy Control and the Quality of Service Control components deal with the permissions to access the IoT Resources (the first one basing the control on the identities of the requestor, of the requested resource and of the requested operation, and the second one on a contractual agreement (Service Level Agreement – SLA) on a quality of service (QoS) applicable to the requestor or to the requested resource). Both controls can be performed either at IoT Communication level or at IoT Resource Management level. If applied within the IoT Communication they can prevent the IoT Resource Management to receive traffic that will be rejected, otherwise all the traffic can be passed to the IoT Resource Management applying these kinds of controls. In any case the Security, Privacy & Trust will provide relevant mechanisms for access rights since they are strictly related with privacy issues.

Critical product attributes

  • Common connectivity management and service interfaces to access, control and manage communications with and about physical things;
  • Interworking of things protocols including mobility management, disconnected operations, virtualization of resources, overlay management and security
  • Opened and easy to use APIs and tools for connecting heterogeneity of physical things


IoT Resources Management

Target usage

IoT Resources Management will propose unified service and operational support management functions enabling the different IoT applications and end users to discover, utilise and activate small or large groups of IoT resources and manage their properties. In doing so, the IoT Service Enablement will focus on global identification and information model schemes for IoT resources, providing a resolution infrastructure to link them with relevant things and developing a common remote management tool for configuring, operating and maintaining the IoT resources on a large scale and with minimum human intervention.

A particular challenge represents the handling of heterogeneous identification schemes that will unavoidably exist in an IoT infrastructure and the heterogeneous addressing schemes that will be used to access the devices. IoT resources can be identified by different identification schemes, e.g. RFID based identities such as EPC, UID etc. From the perspective of addressing schemes MAC or IP addresses or other device identifiers such as HIP may be deployed. Similar heterogeneity can be expected from the assignment of identifiers to the real world entities.

In order to find information and services associated to objects in the Internet of Things, it is necessary to have a resolution infrastructure available, which enables the unequivocal and universal identification of both things and IoT resources (and implicitly the device hosting them), and their mapping into network resources. The Name Resolution GE mentioned in the above section is related to this functionality, but positioned on a slightly different level. In IoT Resources Management the resolution is more about how to find an IoT resource of particular properties or an IoT resource associated to a particular thing. In IoT Communications it is about the way to find the physical device (address, port, protocol etc) that hosts this particular IoT resource.

Maybe the most prominent example of such infrastructures is given by the so-called "Object Name Service" (ONS) in the EPCglobal Network. The ONS shares the same hierarchical design as the Internet Domain Name System (DNS), with queries being delegated from a global root server down to local instances of individual organizations. Because the ONS is allowed only to point to the manufacturer's EPCIS repository, the EPC Network includes EPC Discovery Services. These services allow applications to find third parties' EPCIS repositories across an object's individual supply chain, which can then provide detailed event information to others. It is likely that multiple discovery services will coexist in the future. However the EPC Network is just one example for a resolution infrastructure and mainly used in the retail and consumer products industries, while other resolution infrastructures have been proposed and are also being used, as for example the ucode and associated services originated in Japan.

Beyond identification, resource modelling is a key issue for lookup and discovery. Many state of the art proposals for modelling sensors and sensor networks have been evolved from particular application sectors, specific devices or wireless sensor network technologies.

The look-up and discovery of the IoT resources can be performed by searching in the resource descriptions. Ideas from Web search and concepts of semantic search can contribute to the development of efficient look-up and discovery mechanisms. UDDI [UDDI 04] and other methods for discovery of Web services can be extended to provide IoT resources look-up and discovery.

IoT resources management can consider current state-of-the-art in autonomic computing architectures fundamentally as a control loop, self-management research and self-awareness properties, in particular self-optimisation; -organisation; -configuration; adaptation/contextualisation; -healing; -protection.

IoT Service Enablement will rely on the current naming and resolution infrastructures defined in different projects (e.g. Bridge, SENSEI and IoT-A) by introducing scalable customizable information and resource modelling and discovery mechanisms with relations to the Usage Area projects scenarios. It will also develop mechanisms to provide (automated) associations between IoT resources and the things.

Description of GEs

The figure below shows the main Generic Enablers implementing IoT Resource Management functions. These Generic Enablers will provide altogether at least the following functions:

  • IoT resources identification: through an unequivocal identifier in order to address exiting known resources using a key or identifier (also known as look-up) for representing a common ground for resource management.
  • IoT resolution as a way where a device ID or a service ID is mapped to an address or locator that will allow the communication with the device or service.
  • IoT discovery for finding unknown resources/services based on a rough specification of the desired result by IoT applications. Based on unique identifiers, UIDs, an IoT resolution infrastructure will be able to resolve names and identities to addresses and locators used by communication services. IoT requires the development of resource discovery services to make things available and discoverable to applications.
  • IoT resource information model: unified information models to describe IoT resources will be proposed to enhance availability and accessibility for services and end-users. Many IoT applications will require not only a static description of resource capabilities but also dynamic descriptions based on their interaction with other resources and things, thus enabling a true federation of things.
  • IoT resolution infrastructure: intended to provide the necessary functionality for discovery, look-up and monitoring dynamic links of IoT resources with things, obtaining the hierarchical dependencies and context between the different elements, and next, applying semantic technologies be able to provide the associated values to one element of the network, directly through it or indirectly thought other container elements of its network.
  • IoT linking mechanism: sensors, actuators and personal mobile devices are used to interact with things. An efficient linking mechanism should consider availability and mobility aspects for both for the things and devices. In some cases the ability of IoT resources to interact with things relies on sensors and actuators physically attached to them. In other cases, particular real-world contexts that in particular translate to properties of the virtual entities can be derived from the collaborative interaction between several IoT resources.
  • IoT resources management: in the very dynamic scenario of IoT, IoT resources can evolve with varying degrees of autonomy integrating different technologies over different infrastructure providers. To guarantee an efficient and effective deployment of IoT, global schemes for operation and maintenance management should be developed.
    • Fully remote management enabling the initial configuration, activation, software update, de-activation, and re-activation of IoT resources will facilitate the IoT deployment.
    • Using abstract models as a framework for understanding significant relationships among the IoT of some environment. It enables the development of a specific reference model or a concrete architecture using consistent standards or specifications for supporting the environment. A reference model consists of a minimal set of unifying concepts, axioms and relationships within a particular problem domain, and is independent of specific standards, technologies, implementations, or other concrete details. A common configuration and settings could be easily applied to different groups of resources, including enterprise specific groups, and things type specific groups.
    • Common resource management, relying on open tools and standardized management interfaces, will ease the integration of connectivity modules as well as software management: firmware updates, operating systems, and application logic.

Remote status monitoring will track operational and connection status of resources into the IoT. Fault handling for IoT resources should consider integrated alarm events management and on-demand remote diagnostics to allow specific fault recovery from resources failures.


Image:Architecture_of_IoT_Resource_Management_and_its_2_GEs.jpg
Architecture of IoT Resource Management and its 2 GEs


The architecture supporting IoT Resources Management functions relies on the existence of two Generic Enablers: the Discovery and Resolution of Things GE and the Services and Resources Interaction GE.

The Discovery & Resolution of Things GE will provide functionalities for retrieving lists of services that expose resources related to particular things. This GE will be based on the following components:

  • A Thing Resolution component that will provide the functionality to discover the thing based on a general description discovery, if the thing is not clearly identified by the user.
  • A Thing and IoT Service Monitoring component that will dynamically maintain associations between Things, IoT resources, and exposed supervision and management services. This component is supported by Service and Resource Interaction GE to retrieve the thing to which resources are associated.
  • A Things Manager component that will manage things-related information, including the insertion, update, and deletion of things descriptions and the static association among them and resources. It supports the Service and Resource Interaction GE to manage how IoT resources can be observed and exposed by a given device and, for instance that devices running in sleep mode may no longer hosts all the resources.

The functionality provided by the Services and Resources Interaction GE is offered in two ways, synchronous and asynchronous, by means of the following functional components:

  • The IoT Resource Directory component is responsible for keeping all the information of the different devices registered in the IoT service enablement, like physical address, status, location, etc
  • The IoT Directory Handler component acts as interfaces between the system and IoT Resource information providers, throught IoT communication. It maintains and provides information regarding an identified IoT resource, allowing to update the description of a resource, to retrieve its description or to provide the address of a identified service. Furthermore it is in charge of the automatic resource registry in the IoT Services & Resource Directory. Through the interface with IoT Communication, this component provides access to the device communication and connectivity status and resources can be retrieved from devices.
  • The IoT Catalogue and Location component provides mechanisms in a distributed environment to discover which of the different instances of the entities can support the request a user might be interested in. For example, in an architecture where several Resource Description components exist, a client might be interested in a particular IoT Resource. The client should interrogate the CLB to know which particular existing Resource Description components contain the information requested.
  • The IoT Resource & Service Discovery will interact with IoT Process Automation to provide access to services associated to things, allowing web services to find these resources. This collaboration will manage mostly dynamic discovering new associations between IoT resources and associated services, supporting discovery qualifiers such as location, proximity and other context information. The Resource & Service Discovery will publish to Data/Context Management GE integrated context information about things and their associations (dynamic and static) with other things and resources based on information provided by IoT Data Handling. An interface between Resource & Service Discovery and Security, Privacy and Trust Generic Enablers will support checking access permission before publishing the context information and providing access to resources. A trusted authority will be accessed to verify that only resources provided by trustworthy entities are considered.

Critical product attributes

  • Uniform access to the things in the virtual world and transparent mapping to a real world access
  • Sophisticated "Resolution infrastructure" to discover, identify and access information about things through heterogeneous identification systems
  • Range of sophisticated look-up mechanism that enable finding the correct things in the millions of available with a large range of selection criteria like object types and type hierarchies, geographic areas of interest, properties of things, relationships between things, semantic tags


IoT Data handling

Target usage

IoT Data Handling will be essential for Application and Data Service Providers to collect large amount of IoT-related data, produced by a huge number of IoT resources almost in real-time.

IoT Data Handling GEs will be supported by secured and privacy policies in collecting and forwarding data to Application/Services.

The IoT Data Handling sub-chapter will comprise GEs able to handle efficient data representation formats (including semantic data) and execute near or adjacent to the IoT resources. They will be able to execute data processing functions aiming to generate a smaller set of elaborated data locally, preventing the flooding of the backend system and the storage by large amounts of raw data. These GEs can be placed along the communication path between resources and the backend systems, dynamically adapting the traffic of data to the real demand of application/services at any given moment. IoT Data Handling GEs will therefore include IoT-oriented Generic Enablers offering the same or a subset of the interfaces provided by the Publish/Subscribe Broker and Complex Event Processing GEs defined in the Data/Context Management chapter of FI-WARE. However, they may be implemented as complementary products tailored to execute in devices and IoT gateways with constrained computing (including storage) capabilities. They may also exploit P2P mechanisms to perform their functions in a distributed manner, involving multiple devices. As mentioned at the beginning of this chapter, the combination of Generic Enablers running both in distributed locations and centralized backend systems will allow a scalable, elastic and high performing management of the entire IoT.

IoT Data handling will include GEs dealing with intelligent analysis and mining within massive amounts of data generated by devices and IoT Resources, including both data generated in real-time and historical data. These intelligent analysis/mining will, to a large extent, utilize the BigData Analysis GEs defined in the Data/Context Management chapter and will be based in IoT-specific or application domain (Usage Area) determined logic.


Architecture of IoT Data Handling and its 4 GEs

Description of GEs

Sheth et al. in [Sheth 08] defined a semantic of sensor Web within Space, Time, and Theme attributes to describe the IoT resources in their respective domain. Barnaghi et al in [Barnaghi 10] use the concepts from the semantic sensor Web and provide a platform for sensor data description and publication using linked-data technologies. In a related work, Wang et al [Wang 09] describe a model for annotation and reasoning over sensor data and discuss possible scenarios for interpretation of this data using linked-data concepts. The SENSEI project also demonstrates the core functions for storing, querying and managing distributed IoT resource description data [SENSEI 10]. A general survey on the IoT that describes its different aspects, components and layers as well as data integrity issues is also provided in [Atzori 10].

IoT Service Enablement will extend the current IoT description models and will create an integrated and interoperable solution for IoT data handling. It will also provide solutions for processing of the resources information about real world and IoT knowledge.


It is expected that things will produce large amount of data in different contexts, depending of energy consumption constraints, privacy rules or nomadic unforeseen turn of events. The IoT Data Handling GEs will provide functions to be able to manage three types of data:

  • instantaneous real-time data, which are not relevant to store but could be useful for dedicated applications at a specific time
  • locally stored data for privacy and security concerns or due to unreliable and unstable hazardous connectivity across networks, sometimes derived from energy or motion constraints
  • globally stored data, which will be stored and provided by any provider for access to elementary or historical data.

For privacy and security concerns, access and storage rights should be defined at the closer level of data production, to devices or to IoT resources. As an example, the Data Access Policy GE is not included in the Security, Privacy, Trust technical chapter which is a more centralized chapter. Data Access Policy GE is a dedicated additional component to the Security, Privacy and Trust since it comprises functionality inside the device/IoT gateway supported by Security, Privacy and Trust which does not have components running at this level of data production, close to the devices or IoT resources.

As IoT would target highly heterogeneous discontinuously connected devices (sensors, actuators or personal mobile terminals) IoT Data Handling would also deal with the different data-models related to the different technologies and protocols in order to provide an homogeneous access to all relevant data for Future Internet applications. IoT Communications would rely on this capability to retrieve the technology and protocol-related data models, providing on its end the homogeneous access to the devices, in other words, hiding the heterogeneity of the devices from the Future Internet applications.

The data models will be identified through different Usage Area requirements and based on previous work already described above. Thus, a common data model will be provided at device, gateway and IoT Backend level to support semantic integration of Future Internet Applications and Services. This data model will be consistent with the general data model defined in FI-WARE as described in the Data/Context Management chapter.

Some data could be stored locally in micro-database for devices or IoT resources with energy constraints in order to limit the number of synchronization or relationships with global storage system. This micro-database is also part of nomadic devices or gateways expected to overcome connectivity problems or emphasize local reactivity.

Access rights features will be manageable by IoT Resources management regarding both Applications policy rules and devices and IoT Resources rules. These rules could be associated to a device or IoT resource profile to enhance privacy management and to provide human and context based changes.

Each device or IoT Resource could change its policy rules, for privacy reasons, especially to provide anonymous or personal data. Security, privacy and Trust Generic Enablers will support IoT Data Handling to define what kind of anonymous mechanisms could be put in place to protect privacy and provide relevant information for applications.

Data flow processing will be supported in order to direct the relevant data from its sources to their respective destinations. It has to be scalable, elastic and high performing distributed across devices, IoT Resources and Gateways. Devices, linked to IoT Resources and gateways, will be able to manage local data and process data based on pattern-condition-action based on IoT-tailored Complex Event Processing Generic Enablers running in the devices.

IoT Data Handling will also implement mechanisms to deliver data in P2P mode between devices and things and to support a more efficient communication of data between IoT resources and applications. IoT-oriented Publish/Subscribe Broker GEs supporting this feature will interwork with centralized Publish/Subscribe Broker GEs both supporting the interfaces defined in the Data/Context Management chapter. This way, it will be feasible to create a reliable network of Publish/Subscribe Brokers that propagates subscription service conditions down to IoT resources.

A proper utilization of GEs both in centralized servers and in devices closer to IoT resources will make it feasible to satisfy the challenging requirements of scale and real-time response linked to IoT Data Handling.

Critical product attributes

  • Flexible data handling including support for various data models, data transformations, data mediations and semantic integrations
  • Distributed data management including local storage and processing as well as mechanisms to easily handle the massive amount of IoT data, online stream processing with real-time support and offline processing of collected information based on manageable security rules
  • Global definition, real-time access and/or storage of distributed IoT events


IoT Process Automation

Target usage

IoT Process Automation will propose to Application/Services Providers generic capabilities enabling to use subscription and rules templates that will ease programming of automatic processes involving IoT resources. They will allow to setup high-level conditions that may i.e. trigger new actions in a process.

The distributed nature of the IoT architecture, including mobility of things, requires new forms of business integration and process automation with several levels of collaboration, for example, between devices, gateways and/or components at application level. This may involve, among other aspects, the need to execute part of the process on distributed nodes (e.g., IoT gateways) near or adjacent to IoT resources.

A necessary step for improving IoT processes in large scale solutions is the ability to combine data generated by IoT with business processes that are responsible for scheduling and control. For IoT scenarios, it is necessary to devise a reasonable and complete modelling construct meaning that the process interactions, which may include asynchrony and concurrency, are correct with respect to runtime input-output pairs and that all possible intra- and inter-process interactions are captured adequately by the modelling construct.

Based on semantic capabilities as well as distributed or P2P mechanisms, IoT Process Automation GEs will complement the capabilities and extend the scope of Backend Service Compositions and Front-end Mashup GEs defined in the Applications/Service delivery chapter in FI-WARE. They will allow that the intelligence in Applications/Services dealing with the Future IoT will be based not only on centralized but also on local as well as on distributed processing and decisions executed near or adjacent to IoT resources. These local and distributed processing and decisions will improve reactivity in lots of processes and require new approach for Business Process modelling

Description of GEs

Process automation is dealing with low level processes describing the interactions of the IoT resources hosted by devices and IoT gateways (micro business rules), providing modelling constructs to describe these interactions, templates to capture the events occurring at this level of interaction and knowledge accumulation from the observation of interaction patterns occurring between the devices and IoT gateways. More specifically, the following features were identified:

  • IoT knowledge management: increasing the intelligence of IoT Services capabilities over a long period of time, including
    • handler of application domain ontologies,
    • knowledge base collector
    • a design reasoner to execute classification of assertions and other semantic queries, target a collaborative framework between micro business rules processing engines
  • Support to IoT-aware Business Process Management: enabling the programming of Business Processes where part of the process is able to run near or adjacent to IoT resources and gateways. This may imply defining means supporting important IoT characteristics directly into business processes notations.


Architecture of IoT Process Automation and its 3 GEs


The Process Automation sub-chapter is organized in 3 GEs, which are the Template Handler GE, the Semantic GE and the Exposure GE.

Data events could be produced and stored locally and depending on local rules could trigger Usage Area processes or applications.

  • The functionality of the Template Handler GE is to provide the means to define templates that IoT-oriented GEs running in proximity to IoT resources could take into use. The following components would be considered as part of this GE:
    • The IoT resource tasking component that will allow services to perform request operations from things to the devices
    • The BPM template handler that will provide means to create and to maintain templates for the definition of low level business processes, which devices should execute among themselves without the need to be always connected to the IoT backend. This component will also interact with the Knowledge Base Collector/Accessor in order to detect interaction patterns and, as a result, to define new templates for the future interactions. As an example, a certain pattern of intrusion might be detected at the level of the Knowledge Base Collector/Accessor. This would results in a recommendation from the BPM Template Handler to define/apply a new low level business process to avoid this new detected and learned intrusion.
    • The data event subscription/processing template handler that will provide means to create and maintain templates for the definition of low level subscription queries or complex event processing rules to be submitted to IoT-oriented Publish/Subscribe and Complex Event Processing GEs, respectively.
  • The Semantic GE implements functionality through the following components:
    • The knowledge base collector that will collect long-term knowledge from the IoT resources, relying on the functionality provided by IoT Data Handling GEs and trigger (or propose triggering)applications or business processes in real-time.
    • The ontology component that will enable various Usage Areas to deploy their respective domain ontologies on the IoT subsystem.
  • The Exposure GE includes:
    • The Template Exposer that will expose the structure and functionality (template) being provided with atemplate handler.
    • The process exposer that will expose the characteristics and operational capabilities of the IoT Resources and Things.
    • The semantic exposer that will expose interfaces towards the ontology handler and towards/from the knowledge base collector

Critical product attributes

  • Templates, methodology, modeling tools and support for the orchestrated execution of IoT business processes synchronized with application level business processes using IoT information and triggered by distributed real-time events
  • Knowledge generation from long-term events observation at the low level of devices and IoT resources

Question Marks

Security issues

Issue 1

Anonymous mechanisms for Data Handling, especially to define what kind of data could be stored for medium and long time following privacy rules defined by „Security, trust, Privacy” technical chapter and provided as requirements by usage area projects

Issue 2

Access security policy control for the management of privacy and security aspects of the IoT resources

Issue 3

IoT Security & Protection schemes for the security, privacy, identity and access management challenges of the IoT process automation function. It provides policies for design or runtime configuration, policy enforcement mechanisms and access authentication scheme from/towards IoT resources and elementary applications hosted by things. Configurable role-management and multi-tenant scenarios are supported as well.

IoT Data as a Service

While IoT focuses on delivery of data to and from the devices and the application layer, often data needs to be stored and later accessed by applications and / or by the IoT Services for its proper operation and management of IoT resources. This storage should not follow only structured approach but has to support consistency during time-to-time synchronization or sporadic events and provide "Data as a Service" depending on the place, the type and access rights to the relevant events and data demanded by applications. This topic should be addressed in a coordinated fashion together with functionality inside Data and Context Management.

Once data or events are collected and stored, the use of analytics tools could require lots of computational resources. IoT-oriented Analytics relying on the global BigData Analysis GE defined within the Data/Context Management chapter will be applied to historical data with potential additional real-time data. It needs further clarification how the results get applied to IoT and which GEs are influenced.


Terms and definitions

This section comprises a summary of terms and definitions introduced during the previous sections. It intends to establish a vocabulary that will be help to carry out discussions internally and with third parties (e.g., Usage Area projects in the EU FP7 Future Internet PPP)

The following figure describes the relationships between the concepts defined in this section.


Concepts defined within the IoT Service Enablement technical chapter


  • Thing. One instance of a physical object, living organism, person or concept interesting to a person or an application from the perspective of a FI-WARE instance, one particular usage area or to several usage areas. Examples of physical objects are: building, table, bridge (classes), the Kreml, the tennis table from John’s garden, the Tower bridge (instances). Examples of living organisms are: frog, tree, person (classes), the green frog from the garden, the oak tree in front of this building, Dr. Green.
  • Class of thing. Defines the type of a thing in the style of object-oriented programming: a construct that is used as a blueprint to create instances, defining constituent members which enable class instances to have state and behavior. An example of class of thing is “person”, whereas an instance of a thing is “Dr. Green”, with all the static/dynamically changing properties of this particular person.
  • Group of things. A physical/logical group of things. Examples are all office buildings from Munich, all bridges above the Thames, all screws from a drawer, the planes of Lufthansa currently above Germany, all cars inside a traffic jam driven by a female driver, the trees from the Amazonian forest, the squids from the Mediterranean see the mushrooms from Alice’s garden, all the fish from the aquarium of John., the soccer team of Manchester, the colleagues from OrangeLabs currently working abroad (from the perspective of France), all patients above 60 years of age of Dr. Green, the traffic jams from Budapest, the wheat crop in France in the year 2011, the Research and Development Department of the company Telefónica.
  • Device. Hardware entity, component or system that may be in a relationship with a thing or a group of things called association. A device has the means either to measure properties of a thing/group of things and convert it to an analog or digital signal that can be read by a program or user or to potentially influence the properties of a thing/group of things or both to measure/influence. In case when it can only measure the properties, then we call it a sensor. In case when it can potentially influence the properties of a thing, we call it an actuator. Sensors and actuators may be elementary or composed from a set of elementary sensors/actuators. The simplest elementary sensor is a piece of hardware measuring a simple quantity, such as speed of the wind, and displaying it in a mechanical fashion. Sensors may be the combination of software and hardware components, such as a vehicle on-board unit, that consists of simple sensors measuring various quantities such as the speed of the car, fuel consumption etc and a wireless module transmitting the measurement result to an application platform. The simplest elementary actuator is a light switch. We have emphasized potentially because as a result of the light switch being switched on it is not sure that the effect will be that light bulb goes on: only an associated sensor will be able to determine whether it went on or not. Other examples of devices are smart meters, mobile POS devices. More sophisticated devices may have a unique identifier, embedded computing capabilities and local data storage utilities, as well as embedded communication capabilities over short and/or long distances to communicate with IoT backend. Simple devices may not have all these capabilities and they can for instance only disclose the measurement results via mechanical means. In this latter case the further disclosure of the measurement result towards IoT backend requires another kind of device, called IoT Gateway.
  • Association. It is a physical/logical relationship between a device and a thing or a device and a group of things or a group of devices and a group of things from the perspective of a FI-WARE instance, an application within a usage area project or other stakeholder. A device is associated with a thing if it can sense or (potentially) influence at least one property of the thing, property capturing an aspect of the thing interesting to a person or an application from the perspective of a FI-WARE instance, one particular usage area or to several usage areas. Devices are associated with things in fully dynamic or mainly static or fully static manner. The association may have several different embodiments: physical attachment, physical embedding, physical neighborhood, logical relation etc. Physical attachment means that the device is physically attached to the thing in order to monitor and interact with it, enabling the thing to be connected to the Internet. An example is the on-board device installed inside the vehicle to allow sending sensor data from the car to the FI-WARE instances. Physical embedding means that the device is deeply built inside the thing or almost part of the thing. An example of physical embedding is the GPS sensor inside a mobile phone. Physical neighborhood means that the device is in the physical neighborhood of the thing, but not in physical contact with it. An example of physical neighborhood is the association of the mobile phone of a subscriber who is caught in a traffic jam with the traffic jam itself: the mobile phone is the device, the traffic jam is the thing and the association means that the mobile phone is in the physical neighborhood of the area inside which the traffic jam is constrained (e.g. within 100 m from the region where the average speed of cars is below 5 km/h). Logical association means that there is a relationship between the device and the thing which is neither fully physical in the sense of attachment or embedding, nor fully physical proximity related. An example of logical association is between the car and the garage door opener of the garage where the car usually parks during the night.
  • IoT gateway. A device that additionally to or instead of sensing/actuating provides inter-networking and protocol conversion functionalities between devices and IoT backend potentially in any combination of these hosts a number of features of one or several Generic Enablers of the IoT Service Enablement. It is usually located at proximity of the devices to be connected. An example of an IoT gateway is a home gateway that may represent an aggregation point for all the sensors/actuators inside a smart home. The IoT gateway will support all the IoT backend features, taking into consideration the local constraints of devices such as the available computing, power, storage and energy consumption. The level of functional split between the IoT backend and the IoT gateway will also depend on the available resources on the IoT gateway, the cost and quality of connectivity and the desired level for the distribution of intelligence and service abstraction.
  • IoT resource. Computational elements (software) that provide the technical means to perform sensing and/or actuation on the device. There may be one-to-one or one-to-many relationship between a device and its IoT resource. Actuation capabilities exposed by the IoT resource may comprise configuration of the management/application features of the device, such as connectivity, access control, information, while sensing may comprise the gathering of faults, performance metrics, accounting/administration data from the device, as well as application data about the properties of the thing with which the device is associated. The resource is usually hosted on the device.
  • Management service. It is the feature of the IoT resource providing programmatic access to readable and/or writable data belonging to the functioning of the device, comprising a subset of the FCAPS categories, that is, configuration management, fault management, accounting /access management/administration, performance management/provisioning and security management. The extent of the subset depends on the usage area. Example of configuration management data is the IP endpoint of the IoT backend instance to which the device communicates. Example of fault management is an error given as a result of the overheating of the device because of extensive exposure to the sun. Example of accounting/administration is setting the link quota for applications using data from a certain sensor. Example of security management is the provisioning of a list of device ID-s of peer devices with which the device may directly communicate.
  • Application service. It is the feature of the IoT resource providing programmatic access to readable or writable data in connection with the thing which is associated with the device hosting the resource. The application service exchanges application data with another device (including IoT gateway) and/or the IoT backend. Measured sensory data are example of application data flowing from devices to sensors. Setting the steering angle of a security camera or sending a “start wetting” command to the irrigation system are examples of application data flowing from the application towards the sensor.
  • Event. An event can be defined as an activity that happens, occurs in a device, gateway, IoT backend or is created by a software component inside the IoT service enablement. The digital representation of this activity in a device, IoT resource, IoT gateway or IoT backend instance, or more generally, in a FI-WARE instance, is also called an event. Events may be simple and complex. A simple event is an event that is not an abstraction or composition of other events. An example of a simple event is that “smart meter X got broken”. A complex event is an abstraction of other events called member events. For example a stock market crash or a cellular network blackout is an abstraction denoting many thousand of member events. In many cases a complex event references the set of its members, the implication being that the event contains a reference. For example, the cellular network blackout may be caused by a power failure of the air conditioning in the operator’s data center. In other cases such a reference may not exist. For example there is no accepted agreement as to which events are members of a stock market crash complex event. Complex events may be created of simple events or other complex events by an IoT resource or the IoT backend instance.
  • IoT Backend. Provides management functionalities for the devices and IoT domain-specific support for the applications. Integrant component of FI-WARE instances.
  • IoT application. An application that uses the application programming interface of the IoT service enablement component. May have parts running on one/set of devices, one/set of IoT gateways and one/set of IoT backends.
  • Virtual thing. It is the digital representation of a thing inside the IoT service enablement component. Consists of a set of properties which are interesting to a person or an application from the perspective of a FI-WARE instance, one particular usage area or to several usage areas. Classes of things have the same set of properties, only the value of the properties change from instance to instance.


References

[Harbour 10]

Harbour Research, Machine-to-Machine & Smart System Forecast, 2010-2014, http://www.harborresearch.com/HarborContent/m2msmartsystems.html

[IoT Brussels 09]

Internet of Things — An action plan for Europe Brussels, 18.6.2009 COM(2009), http://www.google.com/url?sa=t&source=web&cd=1&ved=0CBcQFjAA&url=http%3A%2F%2Fwww.kowi.de%2FPortaldata%2F2%2FResources%2Ffp7%2Fcom-2009-278.pdf&ei=mtT5TeOJJYumvgOjyZSyAw&usg=AFQjCNEb1JOgZj0ZbKTsxVpniUMr4W2wzQ

[Juniper 11]

Juniper Networks, Machine-to-machine (M2M) – The Rise of the Machines, 2011, http://www.google.com/url?sa=t&source=web&cd=6&ved=0CEQQFjAF&url=http%3A%2F%2Fwww.juniper.net%2Fus%2Fen%2Flocal%2Fpdf%2Fwhitepapers%2F2000416-en.pdf&ei=TtX5TdbLH4_uuAOJ_eyPAw&usg=AFQjCNGg3FIyQ79SA5DJJXfC_rREKWt7gw

[Prabhu 06]

B. S. Prabhu, X. Su, H. Ramamurthy, C-C. Chu and R. Gadh (2006) “Winrfid, a middleware for the enablement of Radio Frequency Identification (RFID) based Applications”, Mobile, Wireless and Sensor Networks: Technology, Applications and Future Directions (Wiley, 2006).

[IEEE802.15.4]

I. C. Society (2006) "Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks (WPANs)". IEEE Std 802.15.4-2006 (Revision of IEEE Std 802.15.4-2003), 2006.

[6LoWPan]

IETF 6lowpan Working Group: http://www.ietf.org/html.charters/6lowpan-charter.html

[Abangar 10]

H. Abangar et al (2010) “A service oriented middleware network architecture for wireless sensor networks”, Future Network & Mobile Summit 2010

[Hadim 06]

S. Hadim and N. Mohamed (2006) “Middleware Challenges and Approaches for Wireless Sensor Networks”. IEEE Distributed Systems Online, vol. 7, no. 3, 2006.

[Heinzelman 04]

W.B Heinzelman, A.L. Murphy, H.S. Carvalho and M.A. Perillo (2004) "Middleware to support sensor network applications". IEEE Network, vol.18, no.1, pp. 6-14, 2004.

[ETSI-M2M]

ETSI. (2010) "Machine to Machine Communications". http://www.etsi.org/Website/Technologies/M2M.aspx

[Thiesse 09]

F. Thiesse, C.Flörkemeier, M. Harrison, F. Michahelles and C. Roduner (2009) "Technology, Standards, and Real-World Deployments of the EPC Networks". IEEE Internet Computing 13 (2), pp. 36-42, 2009.

[ANSI 06]

Data format standard for radiation detectors used for homeland security, http://physics.nist.gov/Divisions/Div846/Gp4/ANSIN4242/xml.html

[CCSI 09]

Common CBRN Sensor Interface (CCSI) (2009) www.jpeocbd.osd.mil

[ISOX73]

IEEE (2004) "ISO/IEEE11073 (X73), Health informatics - Point-of-care medical device communication". Retrieved from http://www.iso.org

[ZigbeeAll]

ZigBee Alliance (2010). http:// www.zigbee.org

IEEE1451

Lee, K. (2000) "IEEE 1451: A standarad in support of smart transducer networking". In Proceedings of the 17th IEEE Instrumentation and Measurement Technology Conference, 2000. IMTC 2000, pp. 525-528. Home page:http://ieee1451.nist.gov/

[OGC 09]

OGC OWS-6 Geoprocessing Workflow Architecture Engineering Report, http://www.google.com/url?sa=t&source=web&cd=2&ved=0CCIQFjAB&url=http%3A%2F%2Fportal.opengeospatial.org%2Ffiles%2F%3Fartifact_id%3D34968&ei=9DLaTZvmBYGFtgeC3KjpDg&usg=AFQjCNHo-ajNYtMmgH1bHNBEisKL69qD9w

[Botts 08]

Botts, M., Percivall, G., Reed, C., & Davidson, J. (2008). "OGC® Sensor Web Enablement: Overview and High Level Architecture". In F. Fiedrich & B. Van De Walle (Eds.), GeoSensor Networks (Vol. 4540, p. 175-190). Springer. Retrieved fromhttp://portal.opengeospatial.org/files/?artifact_id=25562

[SensorML]

SensorML, Sensor Model Language (SensorML), The Open Geospatial Consortium, http://www.opengeospatial.org/standards/sensorml/

[Russomanno 05]

D. J. Russomanno, C. Kothari, and O. Thomas (2005) “Sensor ontologies: from shallow to deep models," in Proceedings of the Thirty-Seventh Southeastern Symposium on System Theory, pp. 107-112, 2005.

[Kim 08]

J. H. Kim, K. Kwon, H., K. D.-H., H.-Y., S. J. Lee (2008), “Building a service-oriented ontology for wireless sensor networks," in Proceedings of the Seventh IEEE/ACIS International Conference on Computer and Information Science, pp. 649-654, 2008.

[Barnaghi 09]

P. M. Barnaghi, S. Meissner, M. Presser, and K. Moessner (2009) “Sense and Extensible: Semantic Data Modelling for Sensor Networks”, In Proc. Of the ICT-Mobile Summit, June 2009.

[W3CSSN-XG 10]

http://www.w3.org/2005/Incubator/ssn/wiki/

[Anyanwu 03]

K. Anyanwu, A. P. Sheth, (2003) “p-Queries: Enabling Querying for Semantic Associations on theSemantic Web”, In Proceedings of WWW 2003 Conference, pp. 690–699, 2003.

[Ding 04]

L. Ding, T Finin, A Joshi, R Pan, R S Cost, Y Peng, P Reddivari, V Doshi and J Sachs, Swoogle: a search and metadata engine for the semantic web. CIKM ’04, pp. 652–659, 2004.

[Wang 08]

M. Wang, J. Cao, J. Li, and S. k. Dasi, (2008), "Middleware for Wireless Sensor Networks: A Survey," Journal of Computer Science and Technology, vol. 23, no. 3, pp. 305-326, May 2008.

[UDDI 04]

OASIS Open (2004) "UDDI Version 3.0.2". http://www.uddi.org/pubs/uddi_v3.htm

[Jianjun 07]

Y. Jianjun, G. Shengmin, S. Hao, Z. Hui and X. Ke (2007) “A kernel based structure matching for web services search”. In Proceedings of the 16th international Conference on World Wide Web (WWW '07), pp. 1249-1250, 2007.

[Willmott 05]

S. Willmott, H. Ronsdorf, K. H. Krempels (2005) “Publish and Search versus Registries for Semantic Web Service Discovery”. In Proceedings of the 2005 IEEE/WIC/ACM international Conference on Web intelligence, pp. 491-494, 2005.

[Platzer 09]

C. Platzer, F. Rosenberg and S. Dustdar (2009) “Web service clustering using multidimensional angles as proximity measures”, ACM Trans. Internet Technol. 9, 3, pp. 1 26, 2009.

[Toch 07]

E. Toch, A. Gal, I. Reinhartz-Berger, D. Dori (2007), “A semantic approach to approximate service retrieval”, ACM Trans. Internet Technol. 8, 1, 2007.

[Ma 08]

J. Ma, Y. Zhang, J. He, (2008) “Efficiently finding web services using a clustering semantic approach”, In Proceedings of the 2008 international Workshop on Context Enabled Source and Service Selection, integration and Adaptation: Organized with the 17th international World Wide Web Conference (WWW 2008), pp. 1-8, 2008.

[Elahi 09]

B. M. Elahi, K. Römer, B. Ostermaier, M. Fahrmair and W. Kellerer (2009) “Sensor ranking: A primitive for efficient content-based sensor search”, In Proceedings of the 2009 international Conference on information Processing in Sensor Networks, pp. 217-228, 2009.

[Ostermaier 08]

B. Ostermaier, B. M. Elahi, K. Römer, M. Fahrmair and W. Kellerer (2008) “Dyser: towards a real-time search engine for the web of things”, In Proceedings of the 6th ACM Conference on Embedded Network Sensor Systems, pp. 429-430, 2008.

[Autonomic]

Jeffrey O. Kephart and David M. Chess (2003) "Autonomic Manifesto", IBM Thomas J, Watson Research Center. Retrieved of http://www.research.ibm.com/autonomic/manifesto

[IBM 03]

International Business Machines Corp (2003) “An Architectural Blueprint for Autonomic Computing”, April 2003.

[Kephart 03]

Kephart, J. O., & Chess, D. M. (2003). "The vision of autonomic computing". Computer, 36(1), 41-50. IEEE Computer Society Press. Retrieved from http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=1160055

[Fehskens 89]

A. Fehskens (1989) “Monitoring Systems” 1st IFIP Integrated Network Management Symposium, Boston, May 1989

[Strassner 04]

J. Strassner (2004), “Autonomic Networking – Theory and Practice”, IEEE Tutorial, Dec 2004.

[Raz 00]

D. Raz and Y. Shavitt (2000) “Active Networks for Efficient Distributed Network Management”, IEEE Communications Magazine, Vol. 38, No. 3, pp. 138-143, 2000.

[Gu 05]

T. Gu, X. Wang, H. Pung, and D. Zhang (2005) "A service-oriented middleware for building context-aware services," Journal of Network and Computer Applications, no. 28, pp. 1-18, 2005.

[Sheth 08]

A. Sheth, C. Henson and S. Sahoo (2008) “Semantic sensor web", Internet Computing, IEEE, vol. 12, no. 4, pp. 78-83, July-Aug. 2008.

[Barnaghi 10]

P. Barnaghi, M. Presser, K. Moessner (2010) "Publishing Linked Sensor Data"', In Proc. of the 3rd Int. Workshop on Semantic Sensor Networks (SSN), Nov. 2010.

[Wang 09]

W. Wang and P. M. Barnaghi (2009) "Semantic Annotation and Reasoning for Sensor Data". In Proc. of the 4th European Conference on Smart Sensing and Context (EuroSSC2009), LNSC, Springer, Sep. 2009.

[SENSEI 10]

Sensei Consortium (2010) "Sensei Project, the Sensei Real World Internet Architecture", in http://www.sensei-project.eu/, white paper.

[Atzori 10]

L. Atzori, A. Iera, G. Morabito (2010), “The Internet of Things: A survey”, Computer Networks, vol 54, issue 15, pp. 2787-2805, 2010.

[Palmer 03]

N. Palmer (2003) “BPM 2003 Market Milestone Report”. A Delphi Group White Paper, 2003.

[Curtis 92]

W. Curtis, M. I. Kellner, and J. Over (1992) “Process modelling”. Commun. ACM, 35(9):75-90, 1992. ISSN0001-0782.

[Scheer 01]

A.W. Scheer (2001) “ARIS - Modellierungsmethoden, Metamodelle, Anwendungen”. Springer, 2001. ISBN 3-540-41601-3.

[Gschwind 08]

T. Gschwind, J. Koehler, and J. Wong (2008) “Applying patterns during business process modelling”. Business Process Management, volume 5240 of Lecture Notes in Computer Science, pages 4-19. Springer, 2008. ISBN 978-3-540-85757-0.

[Koehler 07]

J. Koehler and J. Vanhatalo (2007). “Process anti-patterns: How to avoid the common traps of business process modeling, part 1 and 2”. IBM WebSphere Developer Technical Journal, issue 10.2, February 2007.

[Preist 04]

C. Preist (2004) “A Conceptual Architecture for Semantic Web Services”. In Proceedings of the 3rd International Semantic Web Conference (ISWC), 2004.

[Toma 05]

I. Toma, K. Iqbal, M. Moran, D. Roman, T. Strang, and D. Fensel (2005) “An Evaluation of Discovery approaches in Grid and Web services Environments”. In Proceedings of NODe/GSEM, 2005.

[Meyer 06]

H. Meyer and M. Weske (2006) “Automated service composition using heuristic search”. In Proceedings of the Fourth International Conference on Business Process Management (BPM 2006), pp. 81-96, 2006.

[Born 08a]

M. Born, A. Filipowska, M. Kaczmarek, and I. Markovic. (2008) “Business functions ontology and its application in semantic business process modelling”. In Proceedings of the 19th Australasian Conference on Information Systems, Christchurch, New Zealand, Dec 2008.

[Weske 07]

M. Weske (2007). “Business Process Management: Concepts, Languages, Architectures”. Springer, 2007. ISBN 978-3-540-73521-2.

[List 06]

B. List and B. Korherr (2006) “An evaluation of conceptual business process modelling languages”. In proceedings of the 2006 ACM symposium on Applied computing (SAC'06), pages 1532_1539, New York, NY, USA, 2006. ACM. ISBN 1-59593-108-2.

[Hadar 06]

Hadar, I., & Soffer, P. (2006), "Variations in conceptual modeling: classification and ontological analysis". Journal of the Association for Information Systems, 7(8), 568-592. Retrieved fromhttp://ais.bepress.com/cgi/viewcontent.cgi?article=1270&context=jais

[Spiess 08]

P. Spiess, D. Khoa Nguyen and I. Weber and I. Markovic and M. Beigl (2008) ”Modelling, Simulation, and Performance Analysis of Business Processes Involving Ubiquitous Systems". Conference on Advanced Information Systems Engineering (CAiSE), 2008.

[BPMN]

Object Management Group (2011) “Business Process Model and Notation (BPMN) Version 2.0” OMG Standard, January 2011 retrieved at http://www.omg.org/spec/BPMN/2.0/ (accessed May 25, 2011).

[OGC SWE]

Open Geospatial Consotium, "Sensor Web Enablement", retrieved at http://www.opengeospatial.org/ogc/markets-technologies/swe (accessed November 14, 2011).


[OpenMeter]

OpenMeter website, retrieved at http://www.openmeter.com/?q=node/8 (accessed November 14, 2011).

[ONVIF]

ONVIF website, retrieved at http://www.onvif.org/ (accessed November 14, 2011).

[SNRA]

ISO/IEC Sensor Network Reference Architecture, draft, retrieved at http://hes-standards.org/doc/SC25_WG1_N1478.pdf (accessed November 14, 2011).

Personal tools
Create a book