Concepto Plantillas Gadget

MuestraGrafoEs.JPG

En esta release se ha incorporado una nueva funcionalidad que permite disponibilizar cualquier gadget de tipo HTML5 como una plantilla. Es decir, ya no es necesario que un usuario que quiera crear un gadget HTML5 tenga conocimientos sobre HTML ni JavaScript al poder partir de un código guía ya estructurado por un usuario experimentado. A modo de muestra, un usuario sin conocimientos previos es capaz de generar este gadget a partir de una plantilla:

MuestraGrafoEs.JPG

Seguir leyendo “Concepto Plantillas Gadget”

Concepto Plantillas Gadget

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

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

Release 4.0: Soporte modelado de ontologías tipo Time Series

En la Release 4.0 de Sofia2 IoT Platform se incorpora un nuevo tipo de ontología que da soporte al concepto de series temporales.

2.PNG

Este nuevo tipo de ontología registra eventos con su marca de tiempo dentro de una ventana temporal, los cuales están agrupados en un documento en la BDTR, haciendo más eficiente la consulta, ya que con una única lectura en BDTR se pueden consultar todos, o un subconjunto de los eventos.

Esta funcionalidad está accesible desde la consola de administración Ontologías > Crear Ontología > Crear Ontología de tipo TimeSerie

Seguir leyendo “Release 4.0: Soporte modelado de ontologías tipo Time Series”

Release 4.0: Soporte modelado de ontologías tipo Time Series