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.
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
