Knowage Brings FIWARE to the Paris Open Source Summit 2017

 Conference, Developers, events, Uncategorized  Comments Off on Knowage Brings FIWARE to the Paris Open Source Summit 2017
Dec 132017

Last week, the third edition of the Paris Open Source Summit took place in Paris, France. The event hereby replaced two pre-existing events: the Solutions Linux event and the Open World Forum. Paris Open Source is the first European Free and Open source event, aiming to exhibit the technological innovations, the reality and the economic dynamism of its solutions, as well as the societal impacts of this digital sector. The 2017 edition of the event focussed primarily on open innovation. 

Engineering, a FIWARE Foundation Platinum Member, and Knowage, the professional open source suite for modern business analytics over traditional sources and big data systems, both attended the Summit last week. In addition, Alessandro Portosa, Software Engineer and Technical Consultant at Knowage Labs, presented Knowage's contribution to FIWARE with regards to developing the new ecosystem for Smart Applications as part of the Collaborative EU Projects session on December 6th.

To watch Alessandro's entire presentation, be sure to head on over to Twitter

FIWARE In Mexico: A Reality

 Developers, events, FIWARE Mundus  Comments Off on FIWARE In Mexico: A Reality
Oct 172017
The FIWARE Community is getting more and more global everyday, but it is worth mentioning that Mexico is a pioneering region in the expansion of the initiative. Jose Gonzalez, from FIWARE Mundus, has recently visited the country to cooperate with FIWARE Mexico and SmartSDK in the reinforcement of FIWARE as a reference platform in the Mexican ecosystem.
  • Within the scope of the Research and Education Working Group coordinated by CUDI in the project FIWARE Mexico, a workshop was organized in the City of Guadalajara as part of the ANUIES-TIC event. This one-day activity helped to introduce FIWARE to several CIOs from Mexican universities and research centres, highlighting the benefits the open platform brings to experimentation, education and entrepreneurship. The workshop was complemented with a practical session on the use of the Orion Context Broker.
  • As part of the 2nd International Conference on Smart Data and Smart Cities hosted in the City of Puebla, Tecnologico de Monterrey organized a workshop aimed at developers, integrators and hardware and software vendors interested in generating innovative solutions using FIWARE. Upon completion of the training, participants were able to understand the potential of the FIWARE platform and gain theoretical and practical skills to develop cloud computing and Internet applications.
FIWARE Mexico addresses the challenge of enhancing FIWARE-driven collaboration between Europe and Mexico, based on the adoption, deployment and improvement of FIWARE in Mexico. This will be used as a framework to open up new horizons for future cooperation in the ICT domain. The process will cultivate the conditions to support the FIWARE activities in Mexico, help it to go beyond the FIWARE Lab, and generate an effective bootstrap of a cohesive and growing innovation FIWARE-driven ecosystem.
SmartSDK is a FIWARE initiative that provides ready-to-use bundles for the creation of Smart Services. All components adopted are based on FIWARE and add-ons are contributed to the FIWARE Community as Open Source. SmartSDK provides a set of reusable and cloud-native architecture patterns to simplify the development of Smart Services.
Guest post by Jose Gonzalez (Interinnov / FIWARE Mundus)

FIWARE Orion Data Source Now Available for Freeboard™

 Blog, Developers  Comments Off on FIWARE Orion Data Source Now Available for Freeboard™
Jul 132015
Freeboard & FIWARE

We are excited to announce that the FIWARE Orion data source is now available on Freeboard!

In a nutshell, Freeboard allows FIWARE developers to build real-time, interactive dashboards and visualizations in a matter of minutes using the intuitive drag & drop interface for data at Orion FIWARE. According to its own webpage, the advantages of using Freeboard include its simplicity (intuitive interface), its cost (you can get started for free), its production readiness and its open-source nature.

Among other functionalities, it offers the following features:

  • Flexible Data Sources
  • Development with Widgets (you can select from a list and add your own)
  • Drag & Drop Simplicity (you can change layouts easily)
  • Public or Private access
  • Freeboard duplication (duplicate any Freeboard and use it as a starting point for a new one –permission required)
  • You can share it instantly (every Freeboard has a unique URL that you can share via email, SMS and social networks)

On the other hand, Orion is one of the main enablers developed by FIWARE. It maintains and delivers context information (like sensor data collected by an Arduino, weather information gathered from a station, and so on), supporting standard OMA NGSI Publish-Subscribe APIs.

FIWARE always tries to help developers, service providers, enterprises and startups to develop products that satisfy their needs while still being open and innovative. This is why we were inspired to create an open source plugin for Bug Labs’ visual dashboard, Freeboard.  Making the plugin was fast and easy thanks to the documentation and help provided by the Bug Labs folks. In just a few days, the plugin was up and running!


Freeboard & FIWARE

Freeboard showing sensor data from Thinking Things connected to FIWARE Orion

Using this new Orion FIWARE datasource, anyone can create an incredible dashboard in a couple of minutes without writing a single line of code. The plugin has been really well received at FIWARE IoT hackathons.

We hope you try the new Orion FIWARE data source on Freeboard.

What makes a Smart App?

 Developers  Comments Off on What makes a Smart App?
Jul 012015
Smart Applications

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.

IoT Tutorial – Orion Context Broker & Arduino

 Developers  Comments Off on IoT Tutorial – Orion Context Broker & Arduino
Jun 102015
Orion Context Broker

By Telefónica  R&D Chile.

This tutorial will be divided into parts for easier reading and practical purposes.

1. Introduction to the technologies used

2. Hardware configuration

3. Arduino, software and communications

4. Orion Context Broker (FIWARE)

5. Action from a remote web

The idea of ​​this tutorial is to learn some theoretical concepts and quickly apply them in practice. Possibly, when you finish this tutorial, you will have imagined hundreds of alternatives based on the original concept to create a sensor-based solution connected to the Internet (basic principle of the Internet of Things).

Come on, let's get started!

Introduction to the technologies used

Before we start, it’s important to briefly review and understand some key concepts. If you are familiar with these concepts, you can proceed directly to the next section.

First of all, the Internet of Things corresponds to the third great wave in computer technology. The first wave was the development of computers in the 60s, then the use and exploitation of the Internet, with mass penetration starting in the eighties, and now the IoT. But what is the Internet of things?

To answer the question above, we must understand the concept of 'connected things' whereby electronic devices can send and receive information via the Internet. Examples including home thermostats, smart cars, entry controls and a thousand other devices. But the reader might be wondering why these devices should be connected to the Internet.

Primarily because the data obtained from these devices can later be combined with other data to obtain more advanced functionalities. Imagine you set your smartphone alarm to wake you up in the morning. It's winter so there is not much light when you wake up. At the sound of the alarm, soft lighting is activated, the toaster starts to warm your bread and the coffee begins to heat up. This may be a rather elementary example, but it helps us to understand that the more information we have and can interrelate, the more devices we can actually create to help improve our quality of life.

One interesting point to discuss is the use of standards. For the specific case we will review later in Orion Context Broker section, an adaptation based on the OMA (Open Mobile Alliance) NGSI (Next Generation Service Interface) specification is used. In simple terms, this means that the HTTP requests or actions to be used are those that are currently employed by browsers such as GET, POST, DELETE and PUT to interact with the Context Broker.

We have reached the end of part one of this tutorial, so let’s get started with the practical information.

Hardware configuration

This is now the practical part of tutorial, so let’s get started!

The components we will be using are:

• An Arduino Board (there are many alternatives, but a version with WiFi is essential)

• A breadboard

• LEDs

• Connecting cables

• A router or a cellular device that can deliver WiFi (tethering)

As a brief introduction to Arduino, it should be highlighted that this hardware is based on an Open-Source specification that, using a board with a microcontroller, allows interaction with numerous devices such as sensors, lights, switches, etc.

Arduino has its own interface development using the C ++ language and integrates a number of libraries to facilitate the 1implementation of prototypes. This does not mean that Arduino cannot be used in industrial or high-demand environments. However, in these scenarios cost issues usually lead to the use of ad-hoc components.

When observing the structure, you can recognize some digital pins on the top and analogue pins at the bottom. Also, at the bottom, is the row of connectors to power a testing board or breadboard. The board also must have a connector to an electrical outlet and a USB mini connector, among other components, depending on the version of the board and if you use add-on 'shields' or not.

If we connect a LED to the board we can do so directly, connecting the LED to digital pin 13 and the GND as seen here. Although it should be noted that the digital pin 13 comes with a resistor, so it would be unnecessary in the image below. (In other pins resistors must be installed) .



Lastly, the same result can be obtained using a breadboard. This is a good idea if you want to add more LEDs or sensors to our Arduino board so you can add more functionalities. Remember that on a breadboard power runs horizontally in the outer points and vertically in the inner points. So the result is:



Take note: Specifically, the Intel Edison Arduino board requires 2 Micro USB cables and a power connection.

Hard to understand? I hope not. This concludes part two of our tutorial.

Arduino, software and communications

In this tutorial we will learn how to program the Arduino board so as to turn the LED we installed in part two on and off. Then, we’ll use an internet connection with the board’s WIFI.

As a prerequisite, we must have already configured the Arduino software as per our operating system. Also, we must keep the board’s USB connected to our computer to load the program to our board. Look here to see how to install the (Intel Edison) software.

You must select the version of the software that corresponds to your operating system.

Once the software is configured and installed we open our IDE and start the coding.

This is an example of the Arduino IDE.  This is specifically the IDE for Intel sets, although the concepts are the same.



In the second row menu (where the check icon is), you’ll find the commands to compile and upload our developments to the board.

Looking at the code, we have two functions. One is setup, where variables are normally initialized and the loop where the operations are executed as required.

In the File menu we have the option Examples – 01 Basic – Blink. This will display a new window with the code needed to test our LED:



Turns on an LED on for one second, then off for one second, repeatedly.

This example code is in the public domain.


// Pin 13 has an LED connected on most Arduino boards.

// give it a name:

int led = 13;


// the setup routine runs once when you press reset:

void setup() {

// initialize the digital pin as an output.

pinMode(led, OUTPUT);



// the loop routine runs over and over again forever:

void loop() {

digitalWrite(led, HIGH); // turn the LED on (HIGH is the voltage level)

delay(1000); // wait for a second

digitalWrite(led, LOW); // turn the LED off by making the voltage LOW

delay(1000); // wait for a second


The example that Arduino generates is quite simple. In line 10 a variable is set with the corresponding pin number on the board. Afterwards, the pin with the variable 'led' as an output is initialized. And, in the loop, the LED is turned on and off separated by a delay of one second. Before loading the code to the board, the IDE must be configured so it knows which board and what port we’re using:

Select Tools> Board> Intel Edison

Select Tools> Port> dev / ttyACM0

Now, if the board is properly plugged into the USB port, we can 'Upload' the code to the board (Ctrl + U) and we should see our LED turning on and off every second. Amazing! Right?

Now to use the WIFI, we need to work a little harder. Luckily, in the Arduino examples, we have a WIFI section with different alternatives when using networking solutions. Among them are Telnet servers and clients, Web servers and clients and even a Twitter client.

TIP: In our case, for purposes of simplicity, we can use a Web client since we will subsequently send requests to the Orion Context Broker using the HTTP protocol. Note that there are better solutions, but for educational purposes we’ll try to minimize the code as much as possible.

#include <SPI.h>

#include <WiFi.h>


  /*  Setup configuration              */


char ssid[] = "YourWifiSSID";                     //  Name of the network

char pass[] = "WifiPassword";                       // Network password

char server[] = "";                    // ORION IP address -> Create in /lab/

int status = WL_IDLE_STATUS;   // we predefine the status as On but not connected

int led = 13;                                     // We initialize a variable to assign the pin number to which the led will be connected


* Arduino Setup configuration

* (Execute only once)


void setup() {

  // Inititialization of the Arduino serial port


  while (!Serial) {

    ; // wait for serial port to connect. Needed for Leonardo only


  // Verify that the board has a WiFi shield

  if (WiFi.status() == WL_NO_SHIELD) {

    Serial.println("Wifi shield is not available");

    // Do not continue with setup, or in other words, stay here forever



The complete code is available in:

FIWARE and Orion Context Broker

As discussed earlier in this tutorial, the Orion Context Broker is a service that based on the OMA NGSI 9/10 standard and can handle sending and receiving contextual information. What does this mean? Primarily, to handle a large number of messages from entities and manage updates, queries, and also handle data subscriptions from the entities. Remember that according to the NGSI 9 and 10 standards, we handle entities as an abstraction of the physical nodes or devices used in IoT solutions.

In the example above, we made an update request to an entity already created. But first let's review how to work with Orion. A simple way to test the OCB service is to create an account in and create a virtual machine with Orion preconfigured in the Cloud section. Alternatively, access Orion’s GitHub site and download a virtual machine to run in our local environment

Another useful tool is a REST client, but we can use cURL if it seems simpler. RESTClient is a client for Firefox that is fairly easy to use.

The configuration aspects of the OCB are outside the scope of this tutorial, as it would require too much detail. Regarding the FIWARE Lab, it is important to note that FIWARE provides virtual machines in the Cloud for free to test FIWARE compontents. You only need to create an account to access the services. Only a quick caveat. As of today (19-03-2015) and temporarily, Spain has no resources available, but there are other regions where VMs can be created. 

When we have the necessary tools, the most basic way to interact with the OCB is:

1. Create an entity:

To do this you must take into consideration several factors.  Firstly, the call is sent as an HTTP POST request, for example, By this we mean that we are occupying version 1 of the API with the updateContext operation.

We also have to define several variables in the header of the request:

Accept: application/json

Content-Type: application/json


Regarding the token generation, the simplest way is to use python script created by Carlos Ralli on GitHub. A FIWARE account and running the '' script is required.

After setting the header of the request, configure the 'body' of the request using the following JSON code:


















Here is the structure of a "context Elements" which is a group of entities with certain attributes such as "type", "isPattern" and "id". "type" refers to a defined type and allows searching for entities by a particular type. "id" is an attribute that must be unique for each entity to execute searches based on this ID. "IsPattern" will be explained later in point No. 2.

You can also add a number of attributes to the entity in the "attributes" property, where each attribute is defined by  "name", "type" and  "value". Finally, "updateAction" defines whether we will perform an "APPEND" or and "UPDATE".

If all went well, we will receive a 200 OK response from the server and it will give us the details of the entity created:


  "contextResponses" : [


      "contextElement" : {

        "type" : "LED",

        "isPattern" : "false",

        "id" : "LED001",

        "attributes" : [


            "name" : "switch",

            "type" : "bool",

            "value" : ""




      "statusCode" : {

        "code" : "200",

        "reasonPhrase" : "OK"





2. Consult an entity:

To consult an entity, the standard operation is 'queryContext' which would be . We also apply the headers described in point No. 1 and use POST.

The JSON used in the body of the request would be as follows:










This is where you can use "isPattern" in "true" and work either the "type" field or "id" field with regular expressions if we want to execute a slightly more complex search. In the example above we are only looking for the same entity created through the "id".

There is also a simpler way to do the same query using the following request: GET where LED001 is the "id" of the entity to search for.

3. Update an entity:

This is identical to point No. 1 but changing the "updateAction" attribute from "APPEND" to "UPDATE".

Finally, integrating all that we reviewed, we will be able to generate an action from a simple Web page that can be deployed on a remote server and actually prove that the application’s LED is activated remotely using the OCB.

To do this we will use the LED001 recently created, by setting the 'switch' attribute from true to false and vice versa to check the action.

Our web would look like this:



For this, the html code, css and js are shared in:

Orion Context Broker: introduction to context management (I)

 Blog, Developers  Comments Off on Orion Context Broker: introduction to context management (I)
Feb 192015
Big Data

The following post has been written by Fermín Galán Márquez, part of the FIWARE technical team in Telefonica R+D. We would like to thank him for his collaboration and his willingness to participate.

Your application dwells in a universe of information. This information is what we call the context of that application.

More specifically, context information is represented by values assigned to attributes that characterize the entities relevant to your application. So, context is about entities and their attributes. For example, if your application is about weather measurement based on sensors deployed in the streets and parks of your city, the entities are the sensors themselves and the attributes are the different weather parameters a sensor may measure (such as temperature, humidity, luminance, atmospheric pressure, etc.) along with other operational parameters (such as the sensor location, battery level, etc.)

Let’s consider another example: a traffic and route planning application. That application may use two different kinds of entities. First, vehicles: cars, buses, trucks, etc., whose basic attributes are speed and location. The second kind of entities could be city places, such as streets, roads, junctions, etc., whose attributes may be location, traffic intensity (e.g. number of vehicles per minute), congestion level, etc.

Taking into account these two cases, we can see two of the main values of context management as design paradigm for applications. First, its simplicity. Everything is about entities and attributes. No complex modeling needed. No complex data relationships or complicated SQL statements to get your data. Modeling your application in terms of entities and attributes is generally easy, as these concepts naturally  arise from your application design. Second, its flexibility. Context is a rather generic concept, so it is suited for many applications, no matter whether the application is related to weather measurement, traffic or whatever other domain. As part of this flexibility, take into account that an entity doesn’t necessarily model things in the real world (such as sensors or cars). It can also model things in the virtual world, such as an “alarm” in a trouble ticket system (which doesn’t have any physical representation and only exists within the IT system which manages alarms).

FIWARE provides you with means to produce, gather, publish and consume context information at large scale. Context management as provided by FIWARE introduces two basic actors: context producers and context consumers. Context producers are the sources of context, the ones that create or update context information. A typical case of context producer is a sensor measuring some metrics. On the other side, context consumers are the sinks for context, the ones that receive context information and do something interesting with it. Of course, the particular actions to do depend on the application. For example, it could draw the temperature evolution over time in a chart or provide dress tips to users (“don’t forget your coat, it’s cold out there!”) depending on the weather context in the case of a weather application. Another example could be recommending alternative routes to a driver based on the overall traffic context of the city, in the case of a traffic application.

It is important to note that producer and consumer are independent roles. Although a given application may play both roles at the same time (for example, a smartphone application running in a smartphone that at the same time produces some context information measured by the phone and consumes context coming from other sources), context consumers don’t need to know about producers and vice versa. Some big applications have some parts playing the producer role and others playing the consumer role to provide a global service. For example, a weather application could have two parts: the first one runs in the sensors (context producers) and the second in the users’ smartphones (context consumers) to provide real-time weather information and recommendations.

In the next post, we will talk about Orion Context Broker, which is the piece of software within FIWARE that materializes context management. Orion Context Broker allows context producers and consumers interact in a decoupled way using different communication paradigms (synchronous or asynchronous), implementing some advanced features (such as geo-localization).

Generic Enablers & eHealth Applications – The Shock Index

 Blog  Comments Off on Generic Enablers & eHealth Applications – The Shock Index
Dec 122014

The following post has been written by the FI-STAR Team at their  blog. We would like to thank their collaboration. If you want to learn more about FIWARE eHealth uses, please read this post in our blog.

Professor Christoph Thuemmler, FISTAR’s Medical Director, presented the session : FIWARE – open architecture and tools from the Future Internet PPP  at the IoT and Platforms for Connected Smart Objects at Horizon 2020 ICT 30 2015 KTN in London.

Generic Enablers - Building blocks

“FIWARE's goal is to advance the global competitiveness of the EU economy by introducing an innovative infrastructure for cost-effective creation and delivery of services, providing high QoS and security guarantees. FIWARE is designed to meet the demands of key market stakeholders across many different sectors, e.g., healthcare, telecommunications, and environmental services.

FIWARE unites major European industrial actors.  FIWARE is an open architecture and a reference implementation of a novel service infrastructure, building upon generic and reusable building blocks developed in earlier research projects.” These are aptly named Generic Enablers and Prof Thuemmler used the metaphor of lego bricks to explain that they are the building blocks of new applications, all of them being available in the FIWARE catalogue.

Orion Context Broker

Prof Thuemmler also demonstrated one of the new applications for the health sector  – the Shock Index which is an early warning service for those with heart conditions.  It connects the patient via their smartphone to the Hospital services who are monitoring them and who can activate the appropriate health service. This application uses the Orion Context Broker, which is available from the FIWARE catalogue. Do you want to see how it works? You can take a look at this video!


Keep your scanners peeled with FIWARE

 Blog, Challenges  Comments Off on Keep your scanners peeled with FIWARE
Nov 272014

This post tells the use of FIWARE made by the developers of BotCar/Wadjet, winners of the mention as Best IoT Solution in the FIWARE Excellence Challenge (October 2014). Thanks to them for the collaboration!

I'm sure you remember The Knight Rider well, don't you? Many times along the TV series, Michael Knight said to KITT: "keep your scanners peeled"; and we all thought: "wow, how amazing it would be to talk to your car". Do you remember it? Well, this is what we can do with BotCar, an IoT platform that lets drivers talk to their cars and that was recently recognized as the Best IoT solution within the FIWARE Excellence Challenge celebrated last October in Las Palmas, where we competed under the Project name of Wadjet.

Nowadays a standard vehicle has among 60 and 70 sensors, such sensors are producing tons of data each time you drive. Your car is itching to share all these data with you in real time as KITT used to do, but it is simply not able to do it, it can't connect with you.

BotCar solves this for you, our solution gathers all the data produced by the car, processes them and gives back to you in real time the insights you need to save up to 20% of your fuel consumption, while letting you know, just in time, the meaning of the orange light which has just switched on again in the dashboard of your car and how to solve it, improving the safety of the passengers on board by giving the car the capability of sending an immediate alert to the emergency services in case of crash.

BotCar comprises a combination of a hardware device and a software solution developed with Node.js and Mongo.db. The hardware device is connected to the car through a plug & play solution and captures all the information from the sensors of the vehicle. As the device includes both a GSM and Bluethooth 4.0 modules, the information is sent to a server directly or via smart phone. Then the logs of data are processed in real time giving back to the user specific feedback via web service and mobile app.

As you can imagine, the architecture of BotCar fits quite well with the FIWARE Technology. On the one hand, we tackle a global need and we wish to change the world, so we need to be ready for a huge and rapid scalability. On the other hand, we face specific needs related to Big Data and to machine to machine automations based on physical sensors.

In such a context FIWARE is the perfect match, as it was designed fully focused in supporting the Internet of Things world as it was already proven in several Smart Cities across Europe. This IoT specialized approach is what makes the difference among FIWARE and other platform technologies, so, for a project like BotCar, purely IoT, FIWARE is the right choice; on the other hand, our Startup nature can leverage from the zero investment requirement of using FIWARE, which undoubtedly gives to FIWARE a singularity. Therefore we have chosen four FIWARE Generic Enablers to enhance our solution. Our selection comprises: the FIWARE Cloud GE, Object Storage GE, COSMO GE, and ORION Context Broker.

The FIWARE Cloud provides us a GUI to manage the services and resources deployed. We use the Object Storage GE to store all the logs generated in a given trip, these data is storaged in a raw manner, without any kind of processing. The Big Data needs are solved by the COSMO GE, it let us to anonymize all the data which lets us optimize data mining, providing aggregate added value to the users through benchmarking features, and to third parties like insurance companies, automotive industry, fleet transport companies, or Smart Cities. Finally, the ORION Context Broker GE gives us the capability of storing those logs specifically related to automations and alerting features like the last position in which the car was located to alert about steals or parking incidents.

So, remember, with FIWARE technologies you can say to all of your Things "keep your scanners peeled", to empower the users to interact with their Things is easier, cheaper and more scalable using FIWARE.