FiWare

Assessing FIWARE GEs Quality

 APIs, Developers, Experimentation, GEs, NGSI  Comments Off on Assessing FIWARE GEs Quality
Sep 202016
 
Blue technology background with a bright piece.

FIWARE is rapidly moving from experimental to production environments in which the platform must scale in reliable and real workload conditions. This fact implies that all FIWARE GEris must work at an adequate quality, reliability and at performance level appropriate for these conditions. A dedicated activity has been launched in the framework of the initiative to analyze and assess the level of quality of each GE, providing diverse kind of reports and an assessment dashboard.

The quality is evaluated from different points of view:

  • Curation of GEs documentation (documentation testing), both inspecting the code and the accompanying documentation (installation manuals, user guidelines, and similar). The goal of this assessment is to support FIWARE users with high-quality support for installation, configuration and operation of FIWARE technology, thereby improving the FIWARE user experience in general.
  • Verification of the GE specification (functional testing), developing the appropriate test cases to assess if the GEs implementation corresponds to what is defined in the specification.
  • Assessment of performance, stability and scalability of GEs in operational environments, like under excessive workload (stress testing). Test scenarios are defined and executed such that limits of a GE under test are identified, and can be compared with reference levels. The goal of this assessment is to favor the applicability of FIWARE in purely commercial scenarios.

overallfunctionalThe testing of the documentation and verification has been done for all GE not deprecated in FIWARE Catalogue (28 in total). Three phases are required to complete the QA functional test process. The first phase verifies for each GE the completeness of documentation, the consistency of artefacts and the soundness of information.  The usability of documentation, by example, in case of installation manual is checked installing step by step the GE. In the second phase specific method calls verify the single APIs and the response correctness of each GEs. The last phase consists of functional verifications based on reference architectures integrating some GEs. As result a live dashboard collects and maintains the assessment information and GE owners are punctually requested to correct the encountered deficiencies. The 90% of the high priority GEs has passed successfully the documentation and verification tests. The medium and low priority GEs are above 70% of success but they are working on solving the issues

post-ges-2On the other hand, the stress testing has been performed only for those GEs most critical in terms of performance in the overall architecture. An iterative process and operative methodology have been put in place, obtaining after each iteration, a complete report with the measures obtained after stress test and analysis of the data. The reports are sent to the GE owners for considering improvements about performance and stability for next release. Three iterations will be achieved before end of September this year: one took place in February testing 9 GEs (Orion, Proton, Aeron, IDAS, Kurento, Wilma, KeyRock, Cepheus, Bosun); the second one in May testing new versions of these GEs; and final one due by September testing again a new updated version of these GEs plus two more identified (AuthZForce and Cygnus) and more frequent combination of GEs.

Once the first iteration of stress testing was conducted, a quality assurance expert was consulted for carrying out an independent assessment of the followed process and executed tests to produce an assessment of the achieved work. The main conclusions of his assessment were:

  • Important performance borders were identified
  • Robustness of use within bounds was shown
  • Documentation needs to be improved

According to this assessment, FIWARE GEs are fit for being released in a commercial operational environment with some adjustments. A new external independent assessment is currently being requested after second iteration.

http://i2.wp.com/sigspl.org/wp-content/uploads/2015/11/spl_cert.pngpost-ges-3As part of the overall testing process and based on the obtained results in the three aspects (documentation, verification and stress) above mentioned, an overall label of quality is granted to each GE. This global label represents the degree of quality of the GE by adopting the energy labelling system[1] used by EU for devices. Specific labels for each analyzed category (usability, reliability, efficiency, scalability, performance and stability) are also granted. Thus, in the Catalogue each GE will be labelled with a global label expanded by clicking of detailed labels map.

Now, after two phases in the process some overall conclusions can be stated. There exists a significant heterogeneity in the GEs quality, having more mature GEs and ready for market than others. There is still room for improvement in documentation and support for most of the GEs, which is currently in progress thanks to this activity. It can be also stated significant improvements in performance from first iteration to the second one, due to the following of recommendations in first iteration testing report by the GE responsible, which is also a demonstration of the value this activity can bring to FIWARE.

In near future, the main focus will be to enlarge number and type of tests and to automate the tests as much as possible, but in the meantime a set of guidelines have been created in order to be able to replicate all the conducted tests by anyone. All the tests and code are already public in FIWARE software repository and all the reports available through the FIWARE wiki.

For further information:

  • GitHub repository containing all docs (guidelines) and scripts (to run the tests) about non functional testing task (stress tests)
     
  • All the reports, up to date, in Docman, under Quality Assurance folder.
     
  • The FIWARE Quality Assurance chapter in our wiki.

[1] Figure under Common Creatives Share-Alike license by sigspl.org

FIWARE in Campus Party Mexico 2015

 Blog, events, Hackathons  Comments Off on FIWARE in Campus Party Mexico 2015
Jul 312015
 
logo-campus-party_cuadrada

Guadalajara (Jalisco, Mexico), the place where Mexican traditions as widely known as tequila and mariachis were born, the second city of the country in population, did also place itself as a leading Mexican city in terms of technology from the 23rd to the 26th of July 2015. As Sao Paulo (Brazil) did in February 2015, during those days Guadalajara 2hosted Campus Party Mexico 2015 and gathered an audience much bigger than expected. Longing to see some of the participants such as Rodolfo Neri Vela (first Mexican astronaut), Zach King (Vine star) or Bruce Dickinson (lead vocalist of Iron Maiden), campuseros could also live a true FIWARE experience! Do you want to know what we did there? Keep on reading and discover it all!

Right next to Palco Luna, the FIWARE logo brightened with a blue light and in strong contrast to the white that dominated the place. Among other reasons, this year, FIWARE attended Campus Party México 2015 to present the new FIWARE node that is to be open and that will become the biggest node in Latin America, thus strengthening the role that FIWARE plays in Mexico and achieving technological autonomy for the country. This node was presented earlier that week in Mexico D.F. in collaboration with Infotec and the Mexican 1Technology Platform (MTP). This will allow Mexico, as Juanjo Hierro stated during Campus Party, to be the first Latin American country to deploy FIWARE and its acceleration programmes.

Participants in Campus Party Mexico 2015 could attend both an introductory speech by Juanjo Hierro, Hugo Estrada and Juan Manuel Romero in Palco Tierra and detailed workshops by technology experts to learn how to use FIWARE to make the most out of their ideas. Juan Manuel Romero did also present his own project, Cares, and his own experience as FIWARE entrepreneur, finalist of a FIWARE hackathon in other Campus Party and winner of the FIWARE Smart Society Challenge. But not only that! Attendees could also participate in the #FIWAREIoT competition. They only needed to follow FIWARE on Twitter and tell us what they would connect to the Internet of Things. The best answers got a FIWARE T-Shirt!

Let’s be honest, all of that is great, but the truth is that, if there was something that drew everybody’s attention, it was the FIWARE 4Smart Apps hackathon, whose prize climbed up to 170,000 pesos (about 10,000 €). Pedro Pablo Rodríguez won the first prize with the project HugTeddy, which allows busy parents to watch for their little children and not to miss out any detail of their growth. Sounds interesting, doesn’t it? Stay tuned because we will soon post more information about the three projects that got the three prizes, so that you can learn how they used FIWARE to develop their own projects.

In short, Campus Party Mexico was, as it always is, a great and funny experience both for the FIWARE team and all the developers that participated in our activities. The only thing we can say is… see you soon, campuseros

OAuth2-based authorization and authentication in Cosmos WebHDFS at FIWARE Lab

 Developers  Comments Off on OAuth2-based authorization and authentication in Cosmos WebHDFS at FIWARE Lab
Jul 182015
 
FIWARE

APIs in FIWARE should be RESTful APIs. And RESTful APIs in FIWARE should be protected with OAuth2”. This sentence, which is true for most of the enablers in FIWARE, did not completly applied for Cosmos BigData. Until now.

OAuth2 is the evolution of the OAuth protocol, an open standard for authorization. Using OAuth, client applications can access in a secure way certain server resources on behalf of the resource owner, and the best, without sharing their credentials with the service. This works because of a trusted authorization service in charge of emitting some pieces of security information: the access tokens. Once requested, the access token is attached to the service request so that the server may ask the authorization service for the validity of the user requesting the access (authentication) and the availability of the resource itself for this user (authorization).

FIWARE implements the above concept through the Identity Manager GE (Keyrock implementation) and the Access Control (AuthZForce implementation); these two enablers together conform the OAuth2-based authorization service in FIWARE:

  • Access tokens are requested to the Identity Manager, which is asked by the final service for authentication purposes once the tokens are received. Please observe by asking this the service not only discover who is the real FIWARE user behind the request, but the service has full certainty the user is who he/she says to be.
  • At the same time, the Identity Manager relies on the Access Control for authorization purposes. The access token gives, in addition to the real identity of the user, his/her roles according to the requested resource. The Access Control owns a list of policies regarding who is allowed to access all the resources based on the user roles.

And how does this affects to Cosmos BigData? HDFS (big) data can be accessed through the native WebHDFS RESTful API. This API was not protected with FIWARE authentication/authorization mechanisms but with Hadoop ones. This leaded Cosmos to be one of the few remaining “rebel” enablers avoiding homogeneity in the access to FIWARE APIs.

So, what’s next? Let’s learn with an example!

How can I request an access token? Do the following request to the Cosmos Token Generator in FIWARE Lab (cosmos.lab.fiware.org:13000):

$ curl -X POST "https://cosmos.lab.fiware.org/cosmos-auth/v1/token" -H "Content-Type: application/x-www-form-urlencoded" -d "grant_type=password&username=frb@tid.es&password=xxxxxxxx

{"access_token": "qjHPUcnW6leYAqr3Xw34DWLQlja0Ix", "token_type": "Bearer", "expires_in": 3600, "refresh_token": “V2Wlk7aFCnElKlW9BOmRzGhBtqgR2z"}

As you can see, your FIWARE Lab credentials are required in the payload, in the form of a password-based grant type (this will be the only time you have to give them).

Once the access token is got (in the example above, it is qjHPUcnW6leYAqr3Xw34DWLQlja0Ix), simply add it to the same WebHDFS request you were performing in the past. The token is added by using the X-Auth-Token header:

$ curl -X GET "http://cosmos.lab.fiware.org:14000/webhdfs/v1/user/frb/path/to/the/data?op=liststatus&user.name=frb" -H "X-Auth-Token: qjHPUcnW6leYAqr3Xw34DWLQlja0Ix”

{"FileStatuses":{"FileStatus":[…]}}

Now, if you try the above request with a random token the server will return the token is not valid; that's because you have not authenticated properly:

$ curl -X GET "http://cosmos.lab.fiware.org:14000/webhdfs/v1/user/frb/path/tp/the/data?op=liststatus&user.name=frb" -H "X-Auth-Token: randomtoken93487345”

User token not authorized

The same way, if using a valid token but trying to access another HDFS userspace, you will get the same answer; that's because you are not authorized to access any HDFS userspace but the one owned by you:

$ curl -X GET "http://cosmos.lab.fiware.org:14000/webhdfs/v1/user/fgalan/path/tp/the/data?op=liststatus&user.name=fgalan" -H "X-Auth-Token: qjHPUcnW6leYAqr3Xw34DWLQlja0Ix"

User token not authorized

Once this point is reached, you may say “OK, but I’m not using WebHDFS at all”. Are you sure? Because, if you are using Cygnus, the tool to build Orion context data archives, then you are using WebHDFS. This is because WebHDFS is the RESTful API used to persist the data in a HDFS backend such as Cosmos. Sadly, any Cygnus version had support for OAuth2… until now. Cygnus 0.8.2 is freshly available and supports OAUth2 through this parameter:

<your_cygnus_agent_name>.sinks.<your_sink_name>.oauth2_token = <your_token>

The token is got from cosmos.lab.fiware.org:13000 as seen before. And upgrading to Cygnus 0.8.2 is as easy as doing:

$ (sudo) yum clean all # just to clean the yum cache

$ (sudo) yum list cygnus# this will show you 0.82 is available

$ (sudo) sudo rpm -e -vv –allmatches –nodeps –noscripts –notriggers cygnus # this is needed if you have installed a version < 0.8.0

$ (sudo) yum install cygnus# this installs 0.8.2

Any doubt? Any question you may have, do not hesitate to contact us through stackoverflow.com or fiware-lab-help@lists.fiware.org. More details can be obtained from these two stack overflow questions:

http://stackoverflow.com/questions/31187977/oauth2-access-to-cosmos-webhdfs-in-fiware-lab

http://stackoverflow.com/questions/31310111/oauth2-in-cygnus

 

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

 

2

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:

 

3

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.

 

4

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:

/*

Blink

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[] = "130.206.80.47";                    // 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

  Serial.begin(9600);

  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

    while(true);

  }

The complete code is available in:

https://bitbucket.org/tidchile/ecosystem/src/

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 https://account.lab.fiware.org/ 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, http://myhost.com:1026/v1/updateContext. 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

X-Auth-Token: [TOKEN AUTHENTICATION]

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

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

{

  "contextElements":[

    {

      "type":"LED",

      "isPattern":"false",

      "id":"LED001",

      "attributes":[

        {

          "name":"switch",

          "type":"bool",

          "value":"false"

        }

      ]

    }

  ],

  "updateAction":"APPEND"

}

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 http://myhost.com:1026/v1/queryContext . 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:

{

  "entities":[

    {

      "type":"LED",

      "isPattern":"false",

      "id":"LED001"

    }

  ]

}

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 http://myhost.com:1026/v1/contextEntities/LED001 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:

 

5

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

https://bitbucket.org/tidchile/ecosystem/src/

CYBERLIGHTNING RELEASES THE CYBERVILLE® PLATFORM

 Blog  Comments Off on CYBERLIGHTNING RELEASES THE CYBERVILLE® PLATFORM
May 062015
 
enY1ocZ3

According to its webpage, “Cyberlightning is the leading 3D Internet Company with next generation controlling and monitoring solutions for the Internet of Things (IoT) networks in the Smart City context. At the moment we are developing real world and virtual world integration for European Union’s service portfolio and also at the same time enabling IoT networks to be controllable via mobile devices..” Now, making use of some of the FIWARE Generic Enablers, Cyberlighning launches CyberVille 2.0, a platform that enhances smart-node to Cloud scalability and establishes the basis for self-learning industrial IoT networks.

This platform provides a “see it at a glance” view, advanced analytics and functional control of the complex sensor and machine networks that comprise the Internet of Everything (IoE). With the addition of powerful edge-device functionality and support for independent yet connected instances of the application, organizations can implement systems that learn from the collected data and operating inputs of smart nodes and various networks layers.

“This release of CyberVille marks an important step in evolving from connected, but highly centralized data systems to an architecture that is the basis of a neural network for the Internet of Everything,” said Ville Mickelsson, CEO of Cyberlightning. “Broadly distributed intelligence enables a system that learns as it grows. For example, a machine supplier can gather operating data across multiple installations and create a pool of real-time knowledge about operating and maintenance parameters to share with all customers.”

Which is the role of FIWARE in CyberVille?

CyberVille makes use of some of the following Advanced Web UI Generic enablers:

  • GIS (Geographical Information System): It enables a robust backend for 3D map data. This GE is able to host geographical data and serve it in 3D form (where applicaple) to both mobile and web clients. The GE implementation is based on open source Geoserver project (GPL licenced) and W3DS extension.
  • RVI (Real Virtual Interaction): It captures and stores sensor data and allows its easy usage in a web browser environment. A key aspect of Augmented Reality is that virtual content is not just presented embedded within the context of the real world, but that it should also allow users to interact actively with real objects and the objects to provide input to the user.
  • 3D-UI: It allows the creation of WebGL based 3D user interfaces in a browser and the integration of interactive 3D graphics into a Web-based application.

Cyberlightning has extended these Generic Enablers to include specific features for their business. They have shared some of these changes in open source communities (they recommend us to learn more about the GeoServer project as an example).

Introduced in May 2014, the CyberVille® software platform integrates heterogeneous data and inputs from multiple control systems to create a unified view and control panel for complex networks that can be accessed on any client device, from smart phones and tablets to traditional desktops. Based on open-source, standards based Internet technology, it provides a multilayered 3D view of complex networks based on a combination of geographic information system (GIS) data sets and 3D models, along with all of the real time data feeds associated with the various objects that make up the network or networks under management.

About CyberLightning

CyberLightning provides an intelligent, end-to-end Internet of Everything (IoE) Application Platform for operational and business use in Smart City environments. The company was founded in 2010 by a core team at the Center for Internet Excellence at University of Oulu, Finland. CyberLightning is a member of the Industrial Internet Consortium (IIC), IPSO (Internet Protocol for Smart Objects) Alliance, Euroheat & Power and a Tizen Association partner. More information is available at www.cyberlightning.com 

Spotlight on FIcontent Specific Enablers for Media & Content

 Blog, Developers  Comments Off on Spotlight on FIcontent Specific Enablers for Media & Content
Apr 212015
 
ficontent

The following post has been written by the team of FIcontent. We would like to thank them for their collaboration and their willingness to participate.

The advent and spread of the Internet as well as the development of connected devices have led to a striking technological convergence of audio-visual, telephone and computer networks, enabling the communication of content more rapidly and far-reaching than ever before and leading to profound effects on people’s habits. Nowadays, citizens not only interact with other individuals but also with all kind of media.

The FIcontent project develops Specific Enablers (SEs) within the framework of the FIWARE initiative supported by the European Commission, taking into account this new social model and aiming to provide innovative, practical and valuable tools, enhancing individual’s experience towards media and content.

1. The FIcontent platforms

FIcontent partners have created and tested a rich library of SEs with reference implementations, allowing developers to put into effect functionalities and to develop an application right away in three specific domains: Social Connected TV, Smart City Services, Pervasive Games, through three specific platforms.

The Social Connected TV platform

The Social Connected TV platform is designed to foster the development and uptake of TV applications based on Future Internet technologies. This platform demonstrates a number of exciting innovations and new user experiences based on open standards such as HbbTV and HTML5. Personalized services will help users easily access and find content based on data inferred from the behaviour of individuals and groups of users, as well as on explicit data provided by the users.

A few examples of Social Connected TV SEs are presented below:

Content Enrichment provides functions to create, distribute and play interactive video content across platforms and devices by making objects in the video clickable for their viewers. Watch the Content Enrichment demonstration video.

HbbTV Application Toolkit provides a powerful tool set for Broadcasters, program editors as well as TV app developers to create HbbTV compliant TV apps in a fast and easy way. A video presents the HbbTV Application Toolkit.

2.1

HbbTV Application Toolkit SE

The Smart City Services platform

The Smart City Services platform provides contextualization, recommendation, live information, mixed reality, 3D, sharing capacities and communications technologies to enable creative people to generate, share and combine assets, objects and stories and develop mobility city services. This platform allows people to login, connect and build communities to interact with each other and gain from social network streams.

Discover some Smart City Services SEs:

Open City Database SE is an open source database management system for any smart city related data (e.g. points of interest, open city data and related media from various sources). Watch the Open City Database demonstration video.

Social Network SE is a set of software modules that enable to create a social network. Watch the Social Network demonstration video.

2.2 2.3

 

 

 

 

 

 

Test of the Social Network SE during the Carnival of Cologne, Germany

The Pervasive Games platform

The Pervasive Games platform demonstrates a strong mix of real life and Internet experience in a playful way and shows advances in 3D or virtual world environments in a way that becomes immersive and ‘’real’’. The platform focuses on multiplayer mobile gaming that leverages the future Internet technology in order to enable large groups of users to participate in innovative mobile gameplay experiences. A central theme of this new social gaming platform is moving beyond the traditional paradigm in which a user is fixed in front of a console or display. In this way, the game becomes an augmented version of the real world that delivers a more compelling experience than traditional console games or the simplistic social games that dominate today’s market.

Some Pervasive Games SEs are presented below:

Networked Virtual Character is provided as a plugin to the FIWARE Synchronization GE and thereby extends its synchronization capabilities to virtual characters while supporting a variety of cross-platform clients. Watch the Networked Virtual Character demonstration video.

Reflection mapping measures camera properties and adapt the virtual objects to fit to the camera image background visually. Reflection mapping is used in the Augmented Resistance game.

2.3 2.4

 

 

 

 

 

 

Augmented Resistance Game using the Reflection mapping SE

2. The FIWARE Media & Content Lab

In order to facilitate access to all these SEs, FIcontent is now developing the FIWARE Media & Content Lab, a live instance providing everything SMEs and developers need for discovering the FIWARE Specific Enablers for media and content, trying them with short demos, and even directly tweaking the client-side code of the Specific Enablers and seeing the results live in the browser.

The FIWARE Media & Content Lab will even allow developers to very easily deploy the Specific Enablers on the FIWARE Lab cloud or on any other machine, with its “run” function.

Stay tuned on http://mediafi.org

2.5

FIWARE Media & Content lab homepage

 

2.6

 

FIWARE Media & Content lab “Discover” page

FIWARE: A STANDARD OPEN PLATFORM FOR SMART CITIES

 Blog  Comments Off on FIWARE: A STANDARD OPEN PLATFORM FOR SMART CITIES
Mar 252015
 
Logo FIWARE Vert RGB

The following post has been written by Sergio García, architect of FIWARE's Context chapter. We would like to thank him for his collaboration and willingness to participate.

Most of the European cities are undergoing a process of transformation towards a new model of services and infrastructures management and of interaction among citizens. Smart Cities, the Cloud and the Internet of Things (IoT) are some of the factors enabling this transformation.

The first infrastructures deployed in Smart Cities have been developed with proprietary or vertical solutions (mobility and traffic management, among others) and, although they solve specific problems, they cause two inconveniences: on the one hand, they are hardly replicable and, on the other hand, they do not facilitate the creation of global ecosystems for entrepreneurs to develop applications and services for multiple cities.

As an alternative for these proprietary solutions, FIWARE is born as the result of a public-private collaboration between the European Commission and the private sector.  This open platform, which provides a set of tools for different functionalities, is an innovation ecosystem for the creation of new applications and Internet services. It is especially useful in terms of Smart Cities, as it ensures the interoperability and the creation of standard data models.

Let’s now focus on its technical aspects.

The platform provides enhanced OpenStack-based Cloud capabilities and a set of tools and libraries known as Generic Enablers (GEs) with public and open-source specifications and interfaces. These FIWARE GEs are distributed in different technical chapters and provide different capacities. For example, the Internet of Things chapter provides tools to connect sensors and other devices; while the applications’ chapter offers powerful business intelligence tools and for the development of interfaces; or as the chapter for Advanced Interfaces allows to implement functionalities related to virtual reality, augmented reality or 3D.

FIWARE Lab is the experimentation environment where technology providers, solution developers and their stakeholders and data providers (cities) can identify problems, design and build solutions on the platform and experiment with them.

Another pillar of the FIWARE architecture is context management. Smart applications and services for cities do need information about everything happening at every moment. FIWARE provides a mechanism to generate, collect, publish or query massive context information and use it for applications to react to their context. This is a complex process, as this information may come from different sources: systems, mobile apps’ users, sensor networks, etc. It is our Context Broker, through a REST implementation of API OMA NGSI, which allows to shape and access it, whatever the source is.

The use and management from data coming from “Things” (i.e. sensors, actuators and other devices) is also a complex process, as there are many different protocols in the IoT sphere, but FIWARE provides a set of GEs allowing to access the relevant information through only one API (NGSI). It not only allows to read this sensor information, but also to act on some elements. Therefore, Context Broker is an essential part of the architecture to collect data, analyse them on real time, consult archives and their analysis, as well as to publish them as open data from a city. On the other hand, other functionalities such as business intelligence, web interfaces and advanced interfaces allow the creation of very powerful applications and solutions.

FIWARE becomes then a fundamental pillar in the infrastructures of Smart Cities, as the different GEs build an architecture that can serve most of their needs. More than 15 European cities and some Spanish cities such as Málaga, Valencia, Seville, Santander or Lleida are already working and experimenting with this platform.

Among other initiatives to adopt FIWARE as Smart City platform, 31 cities from six European countries (Spain, Finland, Denmark, Italy, Portugal and Belgium) and from Brazil have recently announced at CeBIT 2015 (Hannover) the initiative “Open & Agile Smart Cities”, which is based on four main strategic elements: adopting common APIS accessing data from cities through NGSI, adopting a common platform for the publication of data such as CKAN, working on a driven-by-implementation basis and on building applications allowing to reuse, improve and define data models for different vertical markets in cities and to prove the interoperability in a city and among different cities. To that purpose, existent initiatives and models like CitySDK will be used.