Connecting things
Connecting “objects” or “things” involves the need to overcome a set of problems arising in the different layers of the communication model. Using its data or acting upon them requires interaction with a heterogeneous environment of devices running different protocols (due to the lack of globally accepted standards), dispersed and accessible through multiple wireless technologies.
Devices have a lot of particularities so it is not feasible to provide a solution where one size fits all. They are resource constrained and can’t use full standard protocol stacks: they cannot transmit information too frequently due to battery drainage, they are not always reachable since they are connected through heterogeneous wireless networks, their communication protocols are too specific and lack integrated approach, and they use different data encoding languages, so it is tricky to find a global deployment.
Developers will face complex scenarios where merging the information is a real challenge. For this reason, approaching an IoT platform must enable intermediation and data gathering functions to deal with devices variety and it must be configurable and adaptable to market needs.
Solving the complexity with an IoT Platform
Each of the problems exposed when connecting “things” can be solved using the different components and tools of an IoT platform: from a connector (IoT Agent) solving the issues of heterogeneous environments where devices with different protocols approach to a common data format: NGSI; to several enablers whose purposes are improving the capacities of the stored information (security tools, advanced data store models, historical retrieval of information, linkage to third party applications…). And all these features are possible when a powerful central enabler, such as Orion Context Broker, is the heart of the architecture, to gather and publish context information at large scale.
A walk throughout some of these components and functionalities would comprise from data acquisition and command execution at device level to data usage from external applications.
General view of the IoT platform and its components
Components
IoT Agents
There must be an layer to mediate between devices and the core piece, Context Broker. This module, intended to be a gateway for devices willing to communicate with the rest of the components, is based on agents architecture due to the modularity required to integrate devices within the platform.
IoT Agents act as translators between the protocols that devices use to send or receive information, and a common language and data model across all the platform: FIWARE NGSI.
Currently, there is available:
Off-the-shelve IoT Agents. There are several IoT Agents available, supporting different device protocols: HTTP Ultralight, MQTT & OMA Lightweight M2M (LWM2M).
IoT Agent development framework. The framework is used when it is required to integrate proprietary device protocols. The framework comprises common tasks that simplify the development process, i.e. IoT Agents introduce certain security features, such as authentication of devices or authorization for the channel.
Context Broker
Context Broker has the ability of managing Context Information at large scale in order to be used by the applications or offer it to potential consumers. Managing this information is possible since Context Broker keeps virtual representations of the physical devices. Interaction with devices will happen by updating and modifying the virtual representations attached/corresponding to them.
From an architectural point of view, Context Broker acts as a blackboard in a typical blackboard architecture. It is the core and control piece of the platform, in charge of interacting with the other components and agglutinate data. Therefore, Context Broker plays a key role when developing a data/context scenario.
Functionalities offered by Context Broker can be exploited due to different operations compressed within NGSI APIs exposed.
Short Term Historic
Sometimes, third party applications query about explicit information that could be handled in a faster and simpler way than the one offered by a Big Data analytic tool (more focused in extract implicit, non trivial, information present in the data set). Common operations, such as calculating the minimum, maximum, mean, bias or deviation of a set of data can be performed using a time series database (called from now on Short Term Historic) accurate for these scenarios, without an intermediate step of processing the whole set of data in order to obtain the desired information (and many other information) as insights.
CEP (Complex Event Processing)
Complex Event Processing is intended to analyse and react to events, generating immediate response and triggering actions due to changing conditions. It makes possible instant response or reaction to situations (conditions based on a series of events occurring within a time window) instead of to singular isolated events as other standard reactive apps do. For instance, actions launched through the CEP enabler could be SMS delivery, mail notifications, etc.
Security in the platform
Enables the identity management and access control policies: the platform supports an scheme of identity management, authentication and authorization based on three main elements: IdM, PEP, and PAP/PDP. These three elements exist inside the following enablers of the architecture:
The Identity Manager (IdM) carries the information about users, roles and profiles. It also sends and validates tokens, as well as authentication mechanisms.
A Policy Enforcement Point, or PEP, is meant to catch the request from a certain component, and force the requirements specified in terms of identification and authorization for that specific component, before start using it. PEP proxy is in charge of orchestrating all the communications between the IdM element and the PDP element.
For management and assessment of policies, the Access Control enabler chooses the requests after selecting the allowed or banned actions for each role vs. component.
Getting started
The faster alternative to start working with the IoT Agents and Context Broker, is using the FIWARE Lab global instance, or deploy your IoT Bundle, available here:
http://catalogue.fiware.org/bundles
For more flexibility, you can deploy your enablers yourself wherever you want.
IoT Agents (IDAS): http://catalogue.fiware.org/enablers/backend-device-management-idas
Context Broker (Orion): http://catalogue.fiware.org/enablers/configuration-manager-orion-context-broker
Annex: Other Advanced Components for deployment
Business Intelligence
The platform also gives a chance for data analysis tools to interact with the information provided: Business Intelligence features, where data is analysed to be transformed into meaningful and reliable information, is useful to represent information gathered through datasets, and typically, data visualization tools are one of the BI targets in order to provide smart representations of data stored in different data sources.
Big Data
Following the same approach, in order to process huge amounts of data, Big Data tools add efficiency and efficacy to the IoT platform, allowing the creation of clusters that will be provided with any kind of data without previous adaptation, and providing computing services for the data in order to seek for implicit information. Since this enabler is required to store and also analyse information through complex operations, efficiency and efficacy are computing capabilities necessary to fulfil: efficiency in the processing strategy due to the large amount of incoming data; and efficacy when looking for implicit information, or insights.
Open Data (CKAN)
Publishing and consuming open data is a cornerstone for the development of applications and the creation of an innovation ecosystem. Apart from context information data, other datasets and files of various formats can be published so possibilities and flexibility are countless. CKAN is the Open Data enabler component for publication, management and consumption of open data, through static and dynamic datasets.
Context Adapters
Third party applications where the data type or format is not suitable with the outcoming data from Context Broker require the usage of an intermediate element able to act like a connector or linker. Context Adapters are tools to map between Context Broker information format, and the information format that the external application expects to receive. It is necessary to catch each of the attributes with their values and in order to push them to the third party application using a payload accepted at arrival.