Skip to content

OpenIoT Architecture

Jump to bottom
Nikos Kefalakis edited this page Dec 19, 2013 · 12 revisions

The OpenIoT architecture is comprised by seven main elements that belong to three different logical planes, as illustrated in the Figure below. These planes are the Utility/Application Plane, the Virtualized Plane and the Physical Plane which include the following modules:

[](Documentation/images/ArchitectureHighLevelWithColorLayers011113.jpg)

Utility/Application Plane

  • The Request Definition component enables on-the-fly specification of service requests to the OpenIoT platform by providing a Web 2.0 interface. It comprises a set of services for specifying and formulating such requests, while also submitting them to the Global Scheduler.

  • The Request Presentation component selects mashups from an appropriate library in order to facilitate a service presentation in a Web 2.0 interface. In order to visualize these services it communicates directly with the Service Delivery & Utility Manager so as to retrieve the relevant data.

  • The Configuration and Monitoring component enables the management and configuration of functionalities over the sensors and the (OpenIoT) services that are deployed within the OpenIoT platform. Moreover, it enables the user to monitor the health of the different deployed modules.

Virtualized Plane

  • The Scheduler processes all the requests for services from the Request Definition and ensures their proper access to the resources (e.g., data streams) that they require. This component undertakes the following tasks: it discovers the sensors and the associated data streams that can contribute to service setup; it manages a service and selects/enables the resources involved in service provision.

  • The Cloud Data Storage (Linked Stream Middleware Light, LSM-Light) enables the storage of data streams stemming from the sensor middleware thereby acting as a cloud database. The cloud infrastructure stores also the metadata required for the operation of the OpenIoT platform (functional data). The prototype implementation of the OpenIoT platform uses the LSM Middleware, which has been re-designed with push-pull data functionalities and cloud interfaces for enabling additional cloud-based streaming processing.

  • The Service Delivery & Utility Manager performs a dual role. On the one hand, it combines the data streams as indicated by service workflows within the OpenIoT system in order to deliver the requested service (with the help of the SPARQL query provided by the Scheduler) either to the Request presentation or a third-party application. To this end, this component makes use of the service description and resources identified and reserved by the Scheduler component. On the other hand, this component acts as a service metering facility, which keeps track of utility metrics for each individual service. This metering functionality will be accordingly used to drive functionalities such as accounting, billing, and utility-driven resource optimization. Such functionalities are essential in the scope of a utility (pay-as-you-go) computing paradigm, such as the one promoted by OpenIoT.

Physical Plane

  • The Sensor Middleware (Extended Global Sensor Network, X-GSN) collects, filters, combines, and semantically annotates data streams from virtual sensors or physical devices. It acts as a hub between the OpenIoT platform and the physical world. The Sensor Middleware is deployed on the basis of one or more distributed instances (nodes), which may belong to different administrative entities. The prototype implementation of the OpenIoT platform uses the GSN sensor middleware that has been extended and called X-GSN (Extended GSN).

The OpenIoT Architecture is an instantiation of the reference architecture of the European Research Cluster on the Internet of Things (IERC)

footer
Clone this wiki locally