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

Adquisición, transformación y consumo de datos GSMA/FIWARE Data Model

flujoDeconexion

En el post Cómo trabajar con Data Model FIWARE/GSMA en Sofia2 vimos cómo la plataforma Sofia2 soporta los Data Models GSMA y FIWARE. Aprendimos cómo crear Ontologías conforme a estos modelos y cómo insertar datos y consultarlos mediante la herramienta disponible en la plataforma Consola BDTR y BDH. También vimos cómo publicar esta Ontología como un API RESTFul y cómo consumir el API.

 

Además, disponemos del documento Uso de FIWARE Data Model y publicación API NGSI9donde se explica cómo consumir APIS modeladas conforme semántica FIWARE Data Model y publicadas en la Plataforma siguiendo el protocolo NGSI-9.

 

Para el ejemplo se utilizan las Ontologías:

  • GSMA_OffStreetParking_Destino
  • GSMA_PointOfInterest_Beach
  • GSMA_PointOfInterest_Museum

 

Paso a paso se explica cómo suscribirnos a éstas Ontologías, cómo consultar sus Datos mediante la Consola BDTR y BDH, cómo suscribirse a APIs NGSI-9 y consumirlas mediante el portal del desarrollador del API Manager y cómo acceder a estas APIs vía Curl.

 

consumoDatos

 

Con toda esta información, y conociendo que Sofia2 permite crear Reglas Scripts (se aconseja leer el documento Guía de Uso Motor Scripting Sofia2) que se ejecutarán ante la llegada de instancias de Ontologías o cada cierto tiempo, es fácil entender cómo podemos recibir datos con una estructura determinada y transformarlos para cumplir con estos Data Models. 

 

Lo comprobaremos mediante el siguiente flujo:

flujoDeconexion

 

En este ejemplo, se recogen datos de parkings de Smart Coruña, se ingestan en la plataforma Sofia2 a una Ontología, cada vez que se recibe una instancia de esta ontología se lanza un Script que transforma estos datos adaptándolos a los Data Model y consultándolos, vemos como efectivamente, se cumple con los Data Models GSMA y FIWARE.

 

ejemploparking

Adquisición, transformación y consumo de datos GSMA/FIWARE Data Model

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

Tecnologías Localización Tiempo Real (RTLS): RFID vs BLE vs UWB

Post_RTLS

Los Sistemas de Localización en Tiempo Real (RTLS) se utilizan para identificar y rastrear automáticamente la ubicación de objetos o personas en tiempo real, generalmente dentro de un edificio o área delimitada. Los puntos de referencia fijos reciben señales inalámbricas de los Tags RTLS para determinar su ubicación.

 

Ejemplos de sistemas de localización en tiempo real son:

  • Rastreo de automóviles a través de una línea de montaje
  • Localización de palets de mercancías en un almacén
  • Identificación de personas por razones de salud y seguridad
  • Búsqueda de equipos médicos en un hospital.

 

La capa física de la tecnología de los RTLS suele ser alguna forma de comunicación de radiofrecuencia (RF), como BLE (Bluetooth 4.0), UWB (Ultra Wide Band) o sistemas propietarios. Los Tags y puntos de referencia fijos pueden ser transmisores, receptores o ambos, existiendo numerosas combinaciones tecnológicas posibles.

 

Los RTLS son una forma de sistema de posicionamiento local, y no suelen referirse a GPS, seguimiento de teléfonos móviles. La información de ubicación normalmente no incluye la velocidad, la dirección o la orientación espacial. En cambio, son muy rentables, necesitan baterías mínimas, trabajan tanto en interiores como en exteriores, no necesitan un operador de telecomunicaciones móviles y usan protocolos abiertos.

 

Tecnologías en los Sistemas de Localización en Tiempo Real RTLS

 

Existe una amplia variedad de tecnologías en las que se pueden basar los RTLS:

 

  • Infrarrojos (IR). Requieren una línea de visión clara para que las etiquetas y los sensores se comuniquen, por lo que si una placa está cubierta por una manta o se voltea, es posible que el sistema no funcione correctamente
  • Ultrasonidos. El ultrasonido, como protocolo de comunicaciones, es más lento (con longitudes de onda más largas) que el infrarrojo, por lo que generalmente no puede igualar el rendimiento de otras tecnologías.
  • Wi-Fi. Aunque la infraestructura Wi-Fi a menudo es preexistente en el entorno de actuación, la precisión se limita a hasta 9 metros, lo que hace que su valor como herramienta de localización de la ubicación sea incierto.
  • RFID: Hay dos tipos de tecnologías RFID a considerar, activo y pasivo. La tecnología RFID pasiva funciona sólo en la proximidad de lectores RFID especializados, proporcionando una ubicación ‘punto-en-tiempo’. Como ejemplo, pensemos en una tienda de moda donde el lector envía una señal de radio a un artículo etiquetado de ropa y una alarma se activa sólo cuando la etiqueta se detecta muy cerca del punto de estrangulación designado. Con RFID activo, tiene etiquetas que envían la señal a un lector cada pocos segundos (similar a un teléfono celular y una torre) y el software de triangulación u otros métodos se utilizan para calcular la posición del objeto marcado.
  • UWB: La ventaja de la tecnología UWB es el alto nivel de seguridad de transmisión. La señal UWB es difícil de detectar y localizar, porque la densidad de potencia espectral se encuentra por debajo del ruido térmico de fondo. Puede alcanzar una precisión de 10 centímetros a distancias de medición de hasta 100m.
  • BLE: El bluetooth de baja energía (Bluetooth Low Energy o BLE) aparece desde la especificación en su versión 4.0. Está dirigido a aplicaciones de muy baja potencia alimentados con una pila de botón. Tiene una velocidad de emisión y transferencia de datos de 32Mb/s. Funciona en las frecuencias de 2,4 GHz y fue creada por razones de marketing para dispositivos smartphone y tablet. Ventajas importantes de esta tecnología son que se basa en un estándar universal, y está disponible inmediatamente sobre dispositivos móviles sin la necesidad de un hardware.

 

Comparativa de Tags de diferentes tecnologías para los RTLS:

comparativa

 

 

 

 

 

 

Tecnologías Localización Tiempo Real (RTLS): RFID vs BLE vs UWB

Sigfox vs LoRa: comparando redes LPWAN

Las redes LPWAN (redes de banda ancha y baja potencia) son un tipo de red de comunicación inalámbrica diseñada para comunicaciones de gran alcance pero que sólo puede manejar velocidades de datos muy bajas.

Estas redes se adaptan perfectamente al caso de uso IoT, donde los objetos conectados envían pequeñas cantidades de datos generados por el sensor y funcionan con la energía de la batería.

Seguir leyendo “Sigfox vs LoRa: comparando redes LPWAN”

Sigfox vs LoRa: comparando redes LPWAN

Orquestación de notebooks desde motor de flujos: Procesamiento de imágenes con Sofia2

image1

En la nueva versión de Sofia2 se ha añadido un nuevo nodo al motor de flujos capaz de gestionar ejecuciones sobre notebooks de la plataforma.

Con esta nueva característica, se pueden orquestar procesos basados en notebook e incluso paralelizar los mismos distribuyendo la carga de trabajo. Es posible pasar parámetros dinámicos a estos notebooks, pudiendo incluir información fija o generada por un flujo sobre cualquier lenguaje usado en los notebooks y más adelante iniciar una ejecución con los mismos.

Al igual que los parámetros de entrada, se posibilita la salida de los datos generados por uno o varios párrafos de un notebook, incluyendo información generada por un proceso analítico dentro del flujo y tomar decisiones en base al mismo.

Vamos a ver un tutorial de uso del mismo. Tendremos varios elementos de Sofia2 que nos ayudarán a construir y procesar una imagen que el usuario incluirá a través de una web, los cuales son:

  • Proyecto Web: Donde alojaremos la web donde el usuario subirá su imagen y verá los resultados.
  • Binary Repository: Para almacenar y recuperar las diferentes imágenes generadas
  • SSAP: Que nos servirá para comunicarnos entre los diferentes elementos
  • Motor de Flujos (Nodered + nodo Notebook Launcher)
  • Notebooks Sofia2: Usaremos dentro de los mismos Python junto con la librería PIL para procesar imágenes.
  • Gadgets Sofia2: Tendremos un gadget donde se mostrará el histograma de la imagen subida

Lo primero que haremos, será crear un proyecto en Sofia2 que tendrá un domino del motor de flujos y que también tendrá asociada la web.

image2

En la web asociada al proyecto tendremos una interfaz simple que permitirá subir un imagen al binary repository, realizará un POST sobre una URL que iniciará el flujo de procesamiento (al que le pasará los datos de la imagen ya subida) y que mediante el protocolo SSAP se subscribirá a la ontología donde recibirá los resultados de las imágenes ya procesadas.

image3

La url donde se pueden ver los resultados y el código fuente es la siguiente https://sofia2.com/web/imageprocess/imageFlow.html

A continuación, veremos los notebooks necesarios para el procesamiento, así como la configuración necesaria en el motor de flujos. Los notebooks se han construido de manera que cada uno haga una funcionalidad concreta y aislada.

Conversor de RGB a escala de grises: recibe como parámetro una sessionKey válida y el identificador del binary repository (la referencia de la imagen de entrada). Utilizando lenguaje Python y la librería PIL se obtendrá esa imagen del binary repository se convertirá a escala de grises y se volverá a subir al binary repository.

En este notebook podemos comprobar cómo se pueden recibir parámetros en el mismo. Simplemente usando z.input(“nombreParámetro”) crearemos un párrafo que podrá recibir datos dinámicos de forma externa por un formulario, esto no solo es válido para Python, se puede incluir igualmente en otros lenguajes soportados en los notebook como por ejemplo con el interpreter de Spark(scala).

image4

image5

Teniendo ese notebook creado, dentro del motor de flujos podremos añadirlo con el nodo Notebook Launcher:

image6

Al añadir ese nodo, podremos seleccionar cualquiera de los notebooks del usuario en la configuración:

image7

Posteriormente añadiremos el párrafo de entrada (se nos mostrará la lista de los mismos junto con el título y el texto de los mismos):

image8

Al añadir un párrafo con parámetros de entrada, se nos desplegará el formulario correspondiente para configurar cada entrada dinámicamente.

image9

En cuanto a la salida del párrafo (la cual, en este caso, será el nuevo identificador del binary repository de la imagen procesada) la haremos como salida del último párrafo el cuál imprimirá ese identificador. De manera análoga a los parámetros de entrada seleccionaremos un párrafo de salida. Además, se le podrá añadir un tópico para poder distinguir esta salida de otras en nodos posteriores.

image10

Si tuviéramos varios párrafos de salida, podríamos incluir diferentes salidas distinguidas por tópico.

image11

Al enviarlas, podrá ser por array en el mismo puerto (Split Output desactivado) o por diferentes puertos de salida (Split Output activado):

image12

Filtro Blur sobre imagen RGB: similar al notebook anterior salvo que se hará un filtro blur sobre un imagen.

image13image14

Obtención histograma: en este caso se leerá la imagen y se devolverá en el último párrafo el array del histograma

image15

Agrupación de datos: notebook que unificará los datos de los diferentes notebook de procesamiento para conformar una salida única que se enviará posteriormente a la ontología de salida por SSAP a Sofia2.

image16

En este caso, en la configuración del nodo, al tener varios notebooks de entrada tendremos que tener activado el Workflow Mode. Con esta opción, este nodo, se esperará a todos los notebooks de entrada antes de ejecutarse (cada notebook le enviará un parámetro). A parte, al tener varias entradas y no saber el orden de las mismas, tendremos que diferenciar las entradas del nodo por tópico para direccionarlas correctamente. Este direccionamiento se puede hacer de 3 formas:

  • payload: única entrada y se recoge el parámetro el contenido de “payload”
  • payload[n]: múltiples entradas, se recoge la que llega en posición n
  • payload{“topic”:”t1″}: múltiples entradas, se busca la que “topic” sea igual a “t1”

Para este nodo en concreto tendremos:

image17

Ahora, vamos a ver el flujo de procesamiento completo dentro del motor de flujos:

image1

La primera parte del mismo crea un endpoint REST de tipo POST (este será el disparador de todo el flujo). Dentro de este POST se incluirán por JSON los datos de:

  • SessionKey: sessionKey del usuario contra Sofia2. Se usará en todos los acceso al binary repository o al enviar mensajes SSAP
  • BinaryID: id en el binary repository de la imagen inicial

image18

A parte también se incluirá la sessionKey (común para todos los procesos) en el contexto del flow mediante el nodo function.

image19

Más adelante esta información llega a 3 nodos de tipo Notebook Launcher:

image20

Cada uno de estos notebooks recibirá como parámetro el ID del Binario junto con la sessionKey (desde el contexto del flow).

image21

La salida en el caso concreto del conversor a escala de grises va tanto al notebook de agrupación de datos, como a otro notebook idéntico al de filtrado blur.

image22

Aquí, se puede el porqué de la distinción por funcionalidad completa y aislada de los notebooks pudiendo verlos como “cajas negras” reutilizables que procesa con una entrada y una salida. A parte, el nodo notebook launcher crea una instancia de ejecución nueva para cada notebook, por lo que se puede usar varios nodos iguales en paralelo.

Finalmente, se crea un mensaje SSAP que se envía por POST a la ontología destino.

image23

image24

El resultado de todo este proceso, al subir una imagen de este tipo:

image25

Obtendremos al terminar el procesamiento las diferentes imágenes:

  • Imagen con filtro blur
  • Imagen en escala de grises
  • Imagen en escala de grises más filtro blur
  • Histograma en un gadget

image26

El código de los notebook así como la exportación del flujo de nodered puede descargar en el siguiente enlace del github de Sofia2: https://github.com/Sofia2/Sofia2-ImageProcessing

 

Orquestación de notebooks desde motor de flujos: Procesamiento de imágenes con Sofia2

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