Jump to content
  • OpenIOT

       (0 reviews)

    Tim Kannegieter


    OpenIoT is a collective effort of eight partners, including CSIRO, in the European Union FP7 project. OpenIoT is an open source mature middleware platform that brings sensor networks, analytics and cloud computing together. It allows data sources such as smart devices, sensors and actuators to be discovered and aggregated in the cloud without having to hard-code the names and locations of the sensors. It also offers utility-based (pay-as-you-go) IoT services.

    A conceptual diagram of Open IoT is shown below.

    Diagram courtesy of Prem Prakash Jayaraman, Swinburne University of Technology


    OpenIoT is the result of a collaborative research effort using semantic technologies by a range of research organisations including CSIRO. The software is open source, using LGPL license 3.0, so any customer can build on top of that platform.

    OpenIoT provides a cloud-based middleware infrastructure in order to deliver on-demand access to IoT services over multiple infrastructure providers. This is what is called horizontal integration of IoT silos in order to benefit a multitude of applicational services that were not originally designed for such use.

    OpenIoT allows internet connected objects to be deployed and registered. They can be dynamically discovered by location or by a sensor type. Then there is an ID integrated development environment which could offer users service mashups and composition of services.

    The architecture of OpenIoT consists of three layers.


    The lower layer of OpenIoT is physical, where the sensor networks are deployed, which can use deploy any protocol. The upper layer is the utility application layer, where users can specify the workflow, and then this workflow goes into the scheduler and scheduler discovers the data that the workflow needs. Once the data is discovered, the activity metrics are generated to present to the user what is the cost of that service, how much such a service could cost, and then once the user okays it, the scheduler runs the workflow and then comes up with a visualisation of the workflow in the request presentation. In the middle are service tools like configuration management and monitoring tools.

    The application level is built on top of the in-built sensor and semantic data management, and provides simple tools where users can design their own interface to discover sensors, see the data that the sensor produces, compose queries on the data in the database (for example, on the last hour of data collected), and then visualise that data in a graph using the request presentation tools. The user interface does not require coding, but uses a number of buttons to allow users to design their interface.

    The application tools in the utility-app plane are supported by OpenIoT’s semantic data management, where all the data is linked. This layer defines the relationship between the sensors and the data: who created and owns the data. It also includes controls for levels at which the data can be shared with other users and services. There are also supporting services including the scheduler, which takes care of executing any sort of real-time queries and real-time requirements from the users.

    The underlying system in the physical plane is called the sensor management system, which uses a component called X-GSN. X-GSN is similar to the Apache Storm or Spark systems, but was developed earlier. X-GSN is sensor agnostic, and is used to write ‘wrappers’ that allow integration of any sensor into OpenIoT.

    The data from all inputs (mobile devices, sensors, enterprise systems, etc) comes into X-GSN. X-GSN annotates the data with the required metadata. Before data can come into the system, each sensor needs to be registered with the IoT database system here, using the SSN ontology description language. Once registered this system can push data into the centralised Cloud or the data can also be distributed. X-GSN takes care of all the streaming data and allows it to be queried and aggregated before it is transferred into OpenIoT. A diagram of the registration process for sensors is shown below.


    Diagram courtesy of Prem Prakash Jayaraman, Swinburne University of Technology

    OpenIoT also provides a tool called Schematic which allows users to register sensors using the SSN ontology, so that they can then be registered in OpenIoT.


    The capabilities of OpenIoT are summarised in the diagram below.


    Diagram courtesy of Prem Prakash Jayaraman, Swinburne University of Technology

    OpenIoT and other open source technologies

    OpenIoT is used in IoT design to integrate the heterogenous inputs from discovered sensors and store them in the cloud. To do this, it makes use of the semantic sensor networks (SSN) ontology.

    X-GSN, which is used to provide the wrappers for the sensors and filter the data, is also open source, as is the SPARQL query browser which allows sophisticated queries to be executed on the stored data.


    OpenIoT uses a single token-based centralised authentication system based on Apache Shiro.  Every component must be authorised and authenticated before it can push data into the system or get data out of the system.

    Challenges of developing an open IoT architecture

    For an open architecture approach to IoT, a key challenge was overcoming the problem that many existing and developing IoT systems are silos. For example, a smart home solution from a particular provider might only work with devices from the same provider, which locks consumers into outfitting their home with proprietary devices from one source.

    Integrating the large number of devices, vendors, gateways, wireless networks, standards, and backend servers with multiple systems and enterprise applications, is a complex task, as shown in the diagram below.


    Diagram courtesy of Prem Prakash Jayaraman, Swinburne University of Technology

    Other challenges faced were the necessity for international collaboration and partnership, finding the value-add in business models, the cost of sensors and actuators and computer-generated context and situation awareness.

    Specific challenges to be overcome were to:

    ·       integrate all sensors regardless of make and model

    ·       discover sensors and data

    ·       automatic data integration

    ·       preserve privacy

    ·       provide timely access to data

    ·       resolve data ownership issues (Who owns the data? Who decides who uses it?)

    ·       provide utility-based data access (returns to data owners for profits made from their data).

    Why is openness important?

    The importance of openness can be demonstrated by exploring the automation of a simple scenario. A parent (John) is picking up a child (Hanna) from school. If the parent is driving and running late, and the process of organising another appropriately known, authorised and available parent (Alice) to pick up the child is to be automated, the systems of the parents’ cars, all parties’ phones and potentially the school’s information system need to be able to communicate. These could potentially all come from different manufacturers, which means sharing data across many silos. This is illustrated in the diagram below.


    Diagram courtesy of Prem Prakash Jayaraman, Swinburne University of Technology


    The information on this page has been sourced primarily from the following:

    Further reading


    User Feedback

    Join the conversation

    You can post now and register later. If you have an account, sign in now to post with your account.
    Note: Your post will require moderator approval before it will be visible.

    • Add a review...

      ×   Pasted as rich text.   Restore formatting

        Only 75 emoji are allowed.

      ×   Your link has been automatically embedded.   Display as a link instead

      ×   Your previous content has been restored.   Clear editor

      ×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...