50 Real IoT success stories after ten years of experience in the market

Smart Cities

Libelium presents a white paper with 50 real IoT success stories after ten years of experience in the market

With the aim to unveil its horizontal approach to the IoT market, Libelium has launched a new white paper to present 50 real smart projects deployed in 120 countries all over the world. The IoT company has summarized its most successful and appealing stories, developed with Libelium technology and its partners ecosystem, for the main verticals of the market. The white paper includes real IoT projects for environment care, water management, precision agriculture, smart cities, parking management, smart building, smart factory, logistics, retail and eHealth.

Libelium’s experience and soundness, with real solutions developed in more than 120 countries with an ecosystem of more than 90 technological companies, have labeled it as one of the market leaders. Alicia Asín, Libelium CEO, and David Gascón, Libelium CTO, analyse in the white paper the position of the company and the short-term trends and challenges that have arisen in the market.

Libelium is recognized in the IoT market to offer the most horizontal and interoperable platform allowing system integrators, software companies and Cloud servers to make compatible its sensor wireless network to more than 40 cloud platforms. “Customers escape from those who try to retain them with vendor lock-in strategies. Transparency has become indispensable for a market that is constantly in motion ”, states Alicia Asín, CEO of Libelium.

50 Real IoT success stories after ten years of experience in the market

Real-time Location Systems (RTLS). RFID vs BLE vs UWB Tags

Post_RTLS

 

RTLS are used to automatically identify and track the location of objects or people in real time, usually within a building or a delimited area. The fixed reference points receive wireless signals from RTLS tags to determine their location.

 

Examples of real-time locating systems are:

  • Tracking automobiles through an assembly line
  • Locating pallets of merchandise in a warehouse
  • Identification of people for security and safety reasons
  • Finding medical equipment in a hospital

 

The physical layer of RTLS technology is usually some form of radio frequency (RF) communication, like BLE (Bluetooth 4.0), UWB (Ultra Wide Band ) or propietary systems, etc. Tags and fixed reference points can be transmitters, receivers, or both, resulting in numerous possible technology combinations.

 

RTLS are a form of local positioning system, and do not usually refer to GPS, mobile phone tracking. Location information usually does not include speed, direction, or spatial orientation. Instead they are very cost effective, need minimal batteries, work indoor and outdoor, do not need a mobile telecom operator and use open protocols.

 

Technologies in Real-Time Location Systems RTLS

 

There is a wide variety of technologies on which RTLS can be based:

 

    • Infrared (IR). They require a clear line of sight for labels and sensors to communicate, so if a board is covered by a blanket or flips, the system may not work properly.
    • Ultrasound. Ultrasound, as a communications protocol, is slower (with longer wavelengths) than the infrared, so it generally can not match the performance of other technologies
    • Wi-Fi. Although Wi-Fi infrastructure is often preexisting in the performance environment, accuracy is limited to up to 9 meters, which makes its value as a tool for locating the location is uncertain.
    • RFID. There are two types of RFID technologies to consider, active and passive. Passive RFID technology works only in the proximity of specialized RFID readers, providing a ‘point-in-time’ location. As an example, let’s think of a fashion store where the reader sends a radio signal to a labeled item of clothing and an alarm is triggered only when the label is detected very close to the designated control point. With active RFID, it has tags that send the signal to a reader every few seconds (similar to a cell phone and a tower) and triangulation software or other methods are used to calculate the position of the marked object.
    • UWB. The advantage of UWB technology is the high level of transmission safety. The UWB signal is difficult to detect and localize, because the spectral power density is below background noise. It can reach an accuracy of 10 centimeters at measuring distances of up to 100 m.
    • BLE. The Bluetooth Low Energy (or BLE) appears from the specification in version 4.0. It is aimed at very low power applications powered by a button cell. It has a data transfer rate of 32Mb / s. It operates on frequencies of 2.4 GHz and was created for marketing reasons for smartphone and tablet devices. Important advantages of this technology are that it’s based on a universal standard, and is immediately available on mobile devices without hardware need.

 

Comparison of Different Technology Tags for RTLS:

 

comparison

 

 

Real-time Location Systems (RTLS). RFID vs BLE vs UWB Tags

Creating and loading Ontologies from XML and JSON files

creacionportada

 

It’s available in the latest FEEP IoT & Big Data Platform Sofia2 Release the new functionality to create Ontologies “Creation from JSON / XML”. This option allows you to create an ontology from a file with JSON content or an XML.
We want to create an ontology from our JSON file:
creacion1
To do this we must follow the following steps:
  • We’ll introduce the data to characterize it.

 

creation1

 

  • We’ll select the .json file, press “load attributes in JSON / XML”, choose one of the three registers that appear and select the decimal character.

 

creation2

 

Finally, we’ll generate the schema and press “load data” to create the ontology.

 

creation3

 

To create an ontology from an XML file we’ll proceed in an analogous way and will follow the same steps as for the creation through a JSON file.

 

Creating and loading Ontologies from XML and JSON files

New Notebook Module Version

image1

image2

 

In the new Sofia2 4.0 release, notebook engine has been migrated to the new Apache Zeppelin version, refactorizing the user interface and including new features and capabilities.

 

Some of the new notebooks features are:

 

  • Exporting notebooks is now available as JSON file: there are two ways to do this, from user’s notebook list and from edit notebook interface.

 

image3image4

 

  • Importation of notebook from JSON files, from the user’s notebook list.

 

image5

 

  • Exportation of generated data from different kinds of visualization in TSV/CSV format.

 

image6

 

  • Version control over different repositories like Git, Azure, S3 or ZeppelinHub.

 

image7

 

  • New visualization capabilities granted by Helium Framework throught many frontend plugins that allow create from new chart types to interpreters.

 

image8

 

  • Upgraded to Apache Zeppelin 0.7.1 and Spark 2.1

 

  • Centralizated Visualization in notebook execution information (Jobs)

 

image9

 

  • Notebooks Security improvements
New Notebook Module Version

IoT Technologies and its support in Sofia2

p1

IoT technologies make it easy to connect all kinds of things to the network and develop applications to control and manage these “things”. All the complexities of enabling connectivity, services, and deployment for these devices is the task of the IoT platform.

An IoT platform ensures integration with different hardware devices supporting a wide range of communication protocols. Through the integration interfaces provided by the platform, you can also manage the IoT data collected to specific systems for data visualization, data storage, as well as transmitting data to connected devices (configuration, notifications) or between them (controls, events ).

IoT platforms are also known as IoT Middleware, which underlines its functional role as mediator between hardware and application layers.

Let’s see an IoT flow and the components involved:

p1.PNG

Sofia2 supports each and every one of the modules in the previous diagram as follows:

 Things

         Generic IoT Platform                                  Sofia2 IoT Platform

p2                 thingssofia2

We understand Things as any device that is capable of sending data, whether sensors, surveillance cameras, robotic arms, Smart watch … Some of the devices supported by Sofia2 are:

  • Devices:
    • Opening and closing doors sensor : CLIMAX, Leedarson, Nyce, Wulian, Centralite.
    • Environmental thermometer: Several manufactures
    • Pulsoximetros: several manufactures using IEEE protocol
  • Smart Home: presence sensor: CLIMAX, Leedarson, Nyce, Wulian, Centralite, DEVELCO.
  • Smart Building: Smart Plug: Meazon, 4-Noks
  • Smart Retail:
    • Thermostat: 4-Noks, Centralite
    • IP Camera: D-LINK, Panasonic
    • Temperature and humidity sensor: Wulian, Centralite, Leedarson
    • Smoke and gas sensor: CLIMAX, DEVELCO, Leedarson, Wulian
    • Flood sensor: Centralite, CLIMAX, DEVELCO, Wulian
    • Light sensor: Leedarson
    • Smoke Listener: Centralite
    • Siren: Metalligence, Wulian
    • LED illumination: LG, Leedarson
    • Switches: CLIMAX, Centralite
    • Thermostatic valve: CLIMAX
    • Weather station: Adafruit sensors
    • Beacon: Indra, Estimote
    • Panic button: CLIMAX, Centralite
    • Smart Meters: Several manufactures
  • Smart Cities: Environmental humidity sensor: several manufactures
  • Smart Traffic: Sensor power consumption: several manufactures
  • Smart Agro: Flowmeter: several manufactures
  • Smart Tourism:
    • Tensiometer: several manufactures
    • Potentiometer: several manufactures
    • Smart metering: several manufactures
    • Traffic ligth: Cross
    • Intelligent lighting: UVAX, LUIX
    • Libelium sensors
      • Air Quality
      • Atmospheric pressure
      • Temperature
      • Humidity
      • Luminosity
      • Waspmote internal temperature, batterty level, accelerometer
  • Smart Health: scales, several manufactures using IEEE protocol
  • Smart Insurance:
    • Tensiometers: several manufactures using IEEE protocol
    • Thermometer: Fora
    • Glucometer: Fora
    • Nociceptor: several manufactures
    • Anesthesia tower: Drager, General Electric
    • Pressure sensor in bed
    • Fall sensor
    • SmartBand: Withings
  • Otros:
    • Quadrirotor/Drone: Indra, 3DRobotics, Microsoft IPCam
    • Rover/Drone: Indra
    • Raspberry Pi: Indra
    • ARduino

In addition to supporting the data collection of all these devices, Sofia2 also allows the ingestion of data from other types of sources, such as RRSS, APIs and general files:

dispositivossofia2people

Conectivity

Generic IoT Platform        Sofia2 IoT Platform

p3.PNG    Comunicacion Sofia2

Sofia2 is agnostic of the communications, with implementations in multiple protocols of light communication (REST, OPC, MODBUS,  WebSockets, MQTT, WS, JMS, AMQP…)

In addition, among others, the gateways supported by Sofia2 are:

gatewayssofia21

Services and Cloud

 Generic IoT Platform                                   Sofia2 IoT Platform

p4.PNGServiciosycloudSofia2

In the platform Sofia2 the following elementary concepts are defined:

smart space sofia2

SmartSpace

It is the collaborative universe of systems and/or devices (ThinKPs) that exchange information between them. The core of a Smart Space is the SIB (Semantic Information Broker):

SIB: It is the core of the Smart Space, acts as an element of integration of the information exchanged by the devices. There may be several in a Smart Space.

ThinKP: Each of the systems and / or applications that interoperate in the Smart Space through the SIB must be defined as ThinKP in the same. The ThinKP is an element deployed in the Smart Space that can consume and/or produce information.

Ontology: Semantic atomic element with which to model the different information systems that interoperate in the Smart Space domain.

Ontologies are semantic descriptions of a set of classes. In this way, applications that share classes (usually called concepts) of the same ontology, can exchange information through concrete instances of these common classes.

In Sofia2, these ontologies are represented in JSON-Schema format that defines and validates them.

In terms of data storage in Sofia2 we distinguish between:

databases

For each ontology can be configured a time window from which the information is considered ‘historical’.

The information remains in this database until it is automatically migrated to the historical information repository.

The stored information will be available as data source for the different modules of the platform: Integration, Machine Learning, APIManager.

Sofia2 has an API Manager with the following capabilities:

Sofia2ApiManager

Apps and Analytics

Generic IoT Platform                             Sofia2 IoT Platform

p5   AppsyAnalyticsSofia2

In sofia2/console we will find the user interface and experimentation environment with all the capabilities of the platform. In it we can not only create Ontologies to model our data, ThinKPs or ingest data files or RRSS, but also we can create rules (SCRIPTS) to process all this information in the way we are most interested, to visualize this data in Gadgets and Dashboards Or publish ontologies via API. We also have Analytics modules that will allow us to create pipelines and notebooks, or create Machine Learning flows:

ML

To conclude, here we can see the architecture of the platform Sofia2:

ArquitecturaSofia2

As well as an overview of the Sofia2 components:

flujo general Sofia2

IoT Technologies and its support in Sofia2

Visual development in Sofia2 with Raspberry, Node-RED and Dashboards

6

We have already spoken in previous publications about Node-RED, a tool for visual editing and execution of flows.

In this post will be presented a set of nodes designed to interact with Sofia2 IoT Platform and will present a small demo using those nodes deployed on a Raspberry with a SenseHat sensor.

We will start presenting this set of nodes:

nodos1

We have a configuration node that has a global reach, that is, its state will be shared between flows. This node represents a shared connection with a remote system, in this case the configuration node is responsible for creating the connection (REST or MQTT) and make it available to the other nodes.

As for the other nodes are the performers of the operations of insertion, update, deletion, queries and release of the connection.

The nodes are available in Sofia2’s Github, in the npm repository and in the official Node-RED page.

Next we will develop two flows using the Node-RED tool, one of them will be deployed in a Raspberry Pi and another in Sofia2 IoT Platform:

nodos2

The flow of the Raspberry Pi will trigger the process:

nodos3

  • A node controls the SenseHat sensor data that we have integrated with our Raspberry Pi, and triggers the flow every second with temperature, pressure and humidity data.
  • A function node performs a data processing to generate a JSON instance that matches the ontology that is registered in Sofia2.
  • One of the nodes previously presented, will be responsible for sending a message to Sofia2 IoT Platform with the data obtained from SenseHat to the ontology and will be stored in the Real Time Database, which will feed us later the Dashboard.

The flow in Sofia2 IoT Platform

flujoNodeRed

We have a flow that consists of two parts:

  • On the one hand we have a node that retrieves from an Internet service the temperature of Madrid. This data is stored in the context at the flow level.
  • On the other hand we have a node listening the events received from the Raspberry to the ontology in which the data obtained from the SenseHat board are being inserted. In this flow a simple calculation will be made to obtain the difference of temperatures, in addition a rule will be created in which if that difference exceeds a certain threshold a tweet will be sent. Note that the temperature variation data will also be stored in another ontology in Sofia2, so that you can then feed the Dashboard.

Once the demo is in progress, we create a Dashboard on the Platform, which represents the data of temperature, pressure and humidity, collected from the SenseHat sensor, and also the data of the calculated temperature variation.

nodos5

This Demo is available in a guide format at the following link:

https://github.com/Sofia2/meetups/tree/master/Taller-IoT-NodeRED

Visual development in Sofia2 with Raspberry, Node-RED and Dashboards