Mejoras en el despliegue y operación de la plataforma Sofia2

Captura de pantalla 2017-05-25 a las 17.14.08

 

Durante las últimas releases de Sofia2 se han ido introduciendo mejoras en los despliegues de la plataforma, apoyándose cada vez más en los principios DevOps.

 

La CI/CD se ha adaptado al despliegue con contenedores y se han introducido algunas características nuevas de Jenkins, mejorando significativamente la parte Dev de Sofia2, tales como:

 

  • Pipelines declarativos, estos estrechan aún más la distancia entre los desarrollos y los despliegues mediante un DSL más accesible y/o legible e integrado con Docker.
  • BlueOcean, este nuevo plugin permite visualizar de manera más limpia cada uno de los stages o fases de los pipelines de Jenkins.

Captura de pantalla 2017-05-25 a las 9.51.45

Para la mejora de la parte Ops, cada uno de los módulos (ControlPanel, IoTBroker, Stream Process,…) se ha contenerizado con Docker y mediante Kubernetes se automatizan los despliegues de los mismos en los distintos nodos disponibles.

 

Kubernetes es un sistema Open Source de Google que permite automatizar despliegues apoyándose en la tecnología de contenedores, además, gracias al concepto de Replication Controller de Kubernetes se garantiza el auto escalado de cualquiera de los módulos, manteniendo constante el número de réplicas (pods) de un determinado módulo.

 

La accesibilidad entre los pods de distintos módulos en el cluster se consigue mediante servicios, que además se encargan de realizar el balanceo de carga entre todas las réplicas de un mismo módulo.

 

Captura de pantalla 2017-04-06 a las 15.55.43

Mejoras en el despliegue y operación de la plataforma Sofia2

Sistemas de Localización en Tiempo Real (RTLS). RFID vs BLE vs UWB tags

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

 

 

 

 

 

 

Sistemas de Localización en Tiempo Real (RTLS). RFID vs BLE vs UWB tags

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

Minsait by Indra participa en el Digital Enterprise Show

DES_2017

 

Minsait, la unidad de Indra que da respuesta a los retos que plantea la transformación digital, tendrá un papel relevante en el Digital Enterprise Show (DES 2017), que tendrá lugar los días 23, 24 y 25 de mayo en el recinto ferial IFEMA en Madrid.

 

Los expertos de Minsait han identificado que “el cambio” está acelerándose como consecuencia del enorme grado de conectividad, que se resume en el intercambio constante de información en tiempo real a través del despliegue masivo de sensores inteligentes, y del Big Data y la inteligencia aplicada al dato, que redunda en “mayores niveles de eficiencia y automatización” mediante modelos predictivos y de ayuda a la toma de decisión.

 

Entre las intervenciones, destacan:

 

  • Big Data y Analytics, en la intervención de Silviano Andreu, Director Global de Minsait.
  • El cambio cultural y organizacional, en una ponencia de Sergio Martín Guerrero, Director de Soluciones Digitales.
  • Los riesgos asociados a las ciberamenazas, en la ponencia de Isabel González Hervás, Responsable de Tecnologías de Ciberseguridad.
  • Industria 4.0, con una intervención de Gerardo A. Villalba Bello, responsable de operaciones digitales e Industria 4.0.
  • La relación entre Blockchain y las tecnologías IoT, en la intervención de Miguel Ángel González, Director de Soluciones Digitales.

 

Para más información, accede a la web oficial del congreso

 

 

 

Minsait by Indra participa en el Digital Enterprise Show

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

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: http://sofia2.org/owncloud/public.php?service=files&t=44880063da27803905484794d8469383

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

Já está disponível a nova versão Sofia2 IoT Platform 4.0

Já está disponível a versão 4.0 de Sofia2 IoT Platform (f. FEEP IoT&Big Data Platform Sofia2). Esta versão também foi disponibilizada na Plataforma Experimental Sofia2 CloudLab.

Ver versões

Esta versão inclui numerosas novidades e melhorias, nomeadamente:

Seguir leyendo “Já está disponível a nova versão Sofia2 IoT Platform 4.0”

Já está disponível a nova versão Sofia2 IoT Platform 4.0