The following post is a collaboration by Benedikt Herudek, consultant at Accenture. We would like to thank him for his collaboration and willingness to participate.
FIWARE applications are all about creating smart services and that requires being aware of the context. As one might expect, FIWARE doesn’t have a patent on that idea but hooks in to a wider trend in digitalization and IoT: nowadays, we have so much and so much potentially useful data available via the Internet and sensors that we could benefit from separate units of software to handle it, which are referred to as Context Brokers. Following Gartner’s Context Brokers for Smarter Business Decisions, published on the 21st of January 2015:
The underlying concept of a context broker is to have a separate software facility that gathers, prepares and serves context data so that a decision maker —a person or an application system— can have the benefit of this data without having to do all of the work of obtaining and managing the context data as part of the application itself. It is essentially a design pattern for sourcing context data more efficiently and effectively, offloading work from the decision-making application. A widely used Context Broker coming as an apache license is mosquitto.
FIWARE uses that concept (described to some extent in this blog post) and adopts it mainly (for the moment) for Smart Cities and Internet of Things. FIWARE applications are therefore supposed to be smart, in the sense of context aware applications. One could say, FIWARE does mainly two things with this idea. First, it tries to establish a standard protocol accepted all over Europe and thereby scales a market. Second, FIWARE does context management in a smart way. FIWARE context management is modelled along the design of the SNMP simple network management protocol reusing a standard called ‘NGSI’. The original NGSI standard has been created by the OMA standardization organization. However, this original definition is “abstract” and not directly usable, thus FIWARE has bound it to a “concrete” API definition based on RESTful design principles.
In that design, there is a context of so-called ‘Entities’; i.e. relevant things to your application. ‘Values’ are the attributes of these entities, which change over time. A context could represent the reality in your own house or in a large city with entities like, for example, shops or buses.
The FIWARE Context Broker will allow your application to be unaware about how these context values are rendered: for instance, the temperature in a street could be rendered because users placed it on Twitter or rather because the city council decides to add sensors to buses. The FIWARE Orion Context Broker should hide this for you. The context model is extendable, so one can add features such as a value to rate certain buildings. FIWARE is built on REST (stateless) APIs, which are easy to use for developers. Payloads will use JSON or XML. If you need to know what the status of an entity is, you only need to read the value of an entity. If you want to trigger an action and the device allows so, all you need to do is changing the value of an attribute. You can do this with simple PUT and GET calls. The Context Broker connects to IoT agents, which connects to the devices.
Find here a visualization of the Orion Conext Broker from a 3rd party, not supported by FIWARE itself.
The Orion Context Broker shields you as a developer of Smart City applications from a complex setup of an agent – brokerage architecture. Compare it to the (business activity) monitoring solution of a production system for a large client. The Technical Architecture Team will have to deploy agents monitoring the systems, which will connect to the main system; for example, a console where you can see the status of an order or the memory consumption of a system. The infrastructure needs to be setup and maintained by a team of experts. As an end user, you don’t mind about how it works as long as your central instance allows you to interact with the deployed agents and the connected systems. In the world of Smart Cities and FIWARE, cities subscribing to the FIWARE standard would deliver the setup for you and you, as a developer, only connect to the front end, the Orion Context Broker.
The Orion Context Broker runs on top of the IoT Broker. This is a module introduced to handle the complexity of a large setup with 1000s of Devices and IoT agents connecting to them. Imagine you have an application with sensors in agriculture over large patches of lands over an entire country. Or maybe you have a city with many sensors and complex requests like, e.g.: ‘Give me all cars in the street, their location and whatever else you know!’. Here, you might get several thousands of responses back. In that case, you will need a unit which handles and aggregates data for you and a unit to discover sensors in the street. A rule of thumb apparently says: with more than 1000 sensors, you should add an IoT broker to your application.
The IoT Broker will connect to the IoT agents in the field and manage them. The IoT Agents are pieces of software connecting to sensors from devices in the field. They translate IoT protocols like CoAP or MQTT into the Open Mobile Alliance NGSI standard that FIWARE will use. A showcase was done in Santander, Spain as the Context Broker and the IoT standard is developed by Telefonica research center.
From ‘aware’ to ‘Smart’
Once you have all this data in your application, you will use other enablers to do smart things. FIWARE delivers a suite of generic enablers, which allow you to implement different functionalities.
FIWARE is also framed in the Open Data movement. This Open Data movement is pioneered by the (co-)founder of the world wide web Tim Berner Lee and connected to terms like semantic web, linked data, which has as one of its goals to make the web machine readable, where current HTML pages are targeted at human users to consume.
FIWARE uses the open-source Open Data framework ckan to offer a platform and marketplace for Open Data. Thanks to it, free data can be published, enforcing terms & conditions and using data with a fee. The scenarios here are either cities publishing data for free or companies publishing enriched data for a fee. Ckan datastore delivers search & discover functionalities to find published information.
One way of enriching data is to build FIWARE mashups on top of your dataset and visualize them this way. Such data mashups can be sold to newspapers to embed the information revealed in their online presence.
If gathering sensor data from the Internet of Things is a core concept, a Big Data analytics cannot be far. FIWARE hence offers a generic enabler to analyze Big Data. FIWARE uses hadoop under the FIWARE codename cosmos as it’s a big data platform. Apache Hadoop’s MapReduce and HDFS components were inspired by Google papers on their MapReduce and Google File System.
A typical use case of Big Data analytics would be that sensor data flows in via the Orion Context Broker to a FIWARE instance; for example, temperatures in the field. The Orion Context Broker itself only holds the last value of an entity. To have the historical view on temperature, one will connect the Orion Context Broker via a FIWARE component called Cygnus with hadoop, where the data will be stored and can be analyzed. Cygnus uses the subscription/notification feature of the Context Broker, detailing which entities one wants to be notified when an update occurs on any of those entities attributes. Cygnus is based on apache flume and will allow to persist data from the Context Broker not only to hadoop but also mysql or ckan. Licenses are currently open-source, at some point these components might be feedback to the apache foundation to the hadoop ecosystem.
Telefonica delivers other add ons to hadoop called ‘Tidoop’ intended to allow using generic non HDFS data located at CKAN or Mango DB.
FIWARE offers Mashup technologies to create parts of front ends. This Mashup technology is useful for dashboards and maps, which are useful to be embedded, for example, in webpages to blend in a real time data camera from an open-source. A ‘Widget’ is a building block to build a ‘Mashup’. Widgets are connected to each other via ‘Wires’. Backends can be accessed directly by widgets via so-called operators. After you build such a mashup and have created a useful visualization, the mashup can be published back to the FIWARE catalogue to reuse and to sell it on the internal store. FIWARE also offers 3D and Augmented Reality visualization frameworks based on HTML5, WebGL, XML3D and XLOW.
FIWARE integrates the Kurento Mediaserver in its platform. Kurento is based on WebRTC, which is a World Wide Web Consortium standard with open-source delivered from Google. It allows, for example, to create browser communication easily. You should be able to create something like Skype easily. Kurento is implementing this standard. Kurento is an open-source platform making it possible to create a rich WebRTC and multimedia applications. For example, you will use so-called media elements, which are used for example to record videostreams. One will need one video to receive and one media element to record the stream and one will need to connect them properly. Kurento also allows to integrate augmented reality elements in videostreams and can thereby be useful for a Smart City context, e.g. by adding virtual objects like arrows to walk through a street. Thanks to these technologies, it is also possible to detect building of large groups in a city, this could be useful, for example, to direct police to large crowds assembling during concerts or sport events. Kurento is closely integrated with the OpenCV libraries, mainly aimed at real-time computer vision and is used for interactive art, to mines inspection, stitching maps on the web or through advanced robotics and backed by Intel.
As an open platform, you can use any GUI framework like javascript or php frameworks as a base and use the described generic enabler for user interaction.
