Sofia2 IoT Platform vs ThingWorx IoT Platform. Primeros pasos (IV. Crear aplicaciones)

sofia2vsThingWorx

 

Este es el cuarto y último post de la serie Sofia2 IoT Platform vs ThingWorx IoT Platform. Primeros pasos. El objetivo es realizar una comparativa de uso de dos plataformas IoT como son Sofia2 y ThingWorx. Para ello, realizaremos un hands on siguiendo un flujo sencillo IoT en el que simularemos un edificio que dispone de dispositivos para la lectura de consumo energético y temperatura. Para terminar, crearemos un cuadro de mando para visualizar esta información.

 

Con el fin de conseguir una mejor comprensión de esta comparativa, hemos estructurado los pasos a seguir, comunes a las dos plataformas, en 4 posts:

  1. Registro y Login. Modelado de datos
  2. Conecta tu dispositivo
  3. Simular datos de entrada
  4. Crear Aplicaciones

 

Hoy veremos el último punto.

 

Crear Aplicaciones

 

Sofia2 IoT Platform

 

Una vez que existen datos en la plataforma y a medida que los dispositivos u otras aplicaciones se conectan con Sofia2 es posible crear aplicaciones que interoperen entre sí y exploten la información existente. Las Herramientas de Visualización de Sofia2 me permiten explotar de forma sencilla y gráfica la información almacenada dentro de la Plataforma (Ontologías). Puedo crear elementos de visualización unitaria (Gadgets), unirlos en una página web (Dashboard) o incluso crear complejos sinópticos al estilo SCADA representando la evolución de las señales (Instances).

 

El siguiente paso es crear un cuadro de mando usando las capacidades de presentación gráfica de la plataforma.

 

Creando Gadgets

 

  1. Accedemos a Visualización > Mis Gadgets

MisGadgets

2. Pulsamos en Crear Gadget

3. Usaremos el Wizard para crear nuestro primer Gadget. Lo nombramos GaugeWattsVVC (GaugeWatts + Nuestras Iniciales). Pulsamos sobre Siguiente

4. Seleccionamos nuestra Ontología. Pulsamos sobre Siguiente

5. Seleccionamos Query y pulsamos sobre Siguiente

6. Seleccionamos BDTR y pulsamos sobre Siguiente

7. En el campo consulta ponemos select c.SmartBuildingVVC.watts from SmartBuildingVVC as c limit 1 (cambiando VVC por tus iniciales). Pulsamos sobre Preview

8. Bajamos y seleccionamos la pestaña del Gadget Gauge, arrastramos el atributo value a la caja de medidas, cambiamos el Nombre a Watts y obtendremos un Gadget similar a este:

gauge2

9. Volvemos a Mis Gadgets > Crear Gadget. Ahora haremos otro Gadget, esta vez de tipo área. Lo denominaremos AreaTemperatureVVC (AreaTemperature + Nuestras Iniciales). Haremos los mismos pasos que para el gadget anterior, pero cambiando la Consulta por select * from SmartBuildingVVC as c (cambiando VVC por tus iniciales). Pulsamos sobre preview. Bajamos y seleccionamos la pestaña del Gadget Área, arrastramos los atributos timestamp (que cambiaremos el nombre a Temperature) y temperature a la caja de medidas, y obtendremos un Gadget similar a este:

GadgetAreaDos

10. Por último, crearemos un tercer Gadget de tipo Mapa, que llamaremos MapaVVC (Mapa + Nuestras Iniciales). Realizaremos los mismos pasos que para el gadget anterior, usando la Consulta select * from SmartBuildingVVC as c (cambiando VVC por tus iniciales). Pulsamos sobre preview. Bajamos y seleccionamos la pestaña del Gadget Maps, arrastramos los atributos geometry.coordinates.0 y geometry.coordinates.1.

En Medidas cambiaremos el nombre a Localización. Marcaremos los atributos address, city, state y zip y obtendremos un Gadget similar a este:

crearMapaDos

 

 

Creando Mi Dashboard

 

Llamamos Dashboard al cuadro de mandos que recoge una cantidad determinada de elementos (Gadgets). Para crear un Dashboard seguiremos los siguientes pasos:

 

  1. Accedemos mediante el menú a Visualización > Mis Dashboards
  2. Pulsamos sobre Crear Dashboard
  3. Le ponemos como nombre SmartBuildingVVC (SmartBuilding + Nuestras Iniciales)
  4. Tenemos diferentes opciones de estilado, podemos elegir un tema determinado o customizarlo con los colores que elijamos de la paleta. Elegiremos el tema Dark Blue por ejemplo.

estiloDashboard

5. Bajaremos y pulsaremos sobre Nueva Página

6. Pulsaremos sobre + y añadiremos nuestros 3 Gadgets, obteniendo un Dashboard similar a:

DashboardBienn

 

 

ThingWorx

 

ThingWorx denomina Mashup Builder al lugar donde se crean las visualizaciones, siendo los widgets los componentes que se colocan en el mashup. Por lo tanto, podríamos establecer la siguiente similitud de conceptos: lo que llamábamos Gadget en Sofia2, en ThingWorx es un widget y lo que llamábamos Dashboard, ahora es un Mashup.

 

Construyendo un Mashup

 

  1. Nos situamos encima de la pestaña Mashups, en el panel de la izquierda y pulsamos en +

Mashup

 

2. Para Mashup Type seleccionamos Page

3. Para Layout Options seleccionamos Static y pulsamos Done

4. En la pestaña Widgets de la izquierda, hacemos click y arrastramos el widget Gauge en el lienzo del centro. Este widget mostrará los watios simulados en uso.

5. Seleccionamos el objeto Gauge en el lienzo. La parte inferior izquierda de la pantalla contiene las propiedades del widget. Nos desplazamos hacia abajo y cambiamos el valor de la propiedad Legend a Watts. Observe que la etiqueta del lienzo se ha actualizado para mostrar la palabra “Watts”

6. Si el widget OpenStreetMap no está disponible, descargue e instale la Extensión de Mapa de Open Street desde ThingWorx IoT Marketplace https://marketplace.thingworx.com/

7. Hacemos click y arrastramos el widget OpenStreetMap en el lienzo del centro

8. Hacemos click y arrastramos el widget Time Series Chart en el lienzo del centro

9. Movemos los widgets y los cambiamos de tamaño para que quepan en el lienzo

10. Pulsamos en Save y nombramos el Mashup, por ejemplo MyHomeMash

mashupAMedias

 

 

Suministrando datos a un Mashup

 

  1. Si no estamos en modo edición, hacemos click en el botón de edición naranja.

edicionMashup

2. En la ficha Datos en la parte superior derecha de Mashup Builder, hacemos click en el botón verde +

3. Buscamos el Thing MyHouse en la barra de búsqueda Select Entity.

4. En la barra Select Services, buscamos QueryPropertyHistory y hacemos click en la flecha derecha azul para seleccionar este servicio. Este servicio recuperará todas las propiedades registradas del Thing MyHome

5. Marcamos la casilla Mashup Loaded y hacemos click en Done. Esto ejecutará el servicio y recuperará los datos cuando se cargue el Mashup.

addData

6. Seleccionamos y expandimos la pestaña All Data en la parte superior derecha de Mashup Builder. Se mostrarán todas las salidas de la llamada de servicio.

7. Arrastramos la propiedad watts al widget Gauge en el lienzo. Seleccionamos # Data para el destino de enlace.

MashupDesarrollado

 

8. Hacemos lo mismo para el widget OpenStreetMap vinculando house_lat_long a la SelectedLocation en el mapa.

9. Con el widget OpenStreetMap seleccionado, hacemos click en la propiedad ShowSelectionMarker en la ventana de propiedades del widget en la parte inferior izquierda del Generador de Mashup.

10. Para el Time Series Chart, arrastramos el contenedor All Data en el widget y seleccionamos Data como el destino de enlace

11. Con el widget Time Series Chart seleccionado, establecemos las siguientes propiedades mediante la ventana de propiedades del widget en la parte inferior izquierda del Mashup Builder:

Property Value
XAxisField  timestamp
DataField1 temperature

12. Pulsamos sobre Save para guardar los cambios

 

Lanzando la Aplicación

 

  1. Iniciamos la aplicación seleccionando el botón View Mashup en la parte superior. Es posible que debamos habilitar el cuadro emergente en su navegador para ver el mashup.
  2. Obtendremos un Mashup similar a este:

MashupFinal

Sofia2 IoT Platform vs ThingWorx IoT Platform. Primeros pasos (IV. Crear aplicaciones)

Sofia2 IoT Platform vs ThingWorx IoT Platform. Primeros pasos (III. Simular datos de entrada)

sofia2vsThingWorx

 

Este es el tercer post de la serie Sofia2 IoT Platform vs ThingWorx IoT Platform. Primeros pasos. El objetivo es realizar una comparativa de uso de dos plataformas IoT como son Sofia2 y ThingWorx. Para ello, realizaremos un hands on siguiendo un flujo sencillo IoT en el que simularemos un edificio que dispone de dispositivos para la lectura de consumo energético y temperatura. Para terminar, crearemos un cuadro de mando para visualizar esta información.

 

Con el fin de conseguir una mejor comprensión de esta comparativa, hemos estructurado los pasos a seguir, comunes a las dos plataformas, en 4 posts:

  1. Registro y Login. Modelado de datos
  2. Conecta tu dispositivo
  3. Simular datos de entrada
  4. Crear Aplicaciones

 

Hoy veremos el tercer punto.

 

Simular Datos de Entrada

 

Sofia2 IoT Platform

 

Puesto que no tenemos un dispositivo real que inserte información en nuestra ontología, debemos simular los datos que nos enviaría el sensor de nuestro Smart Building. Sofia2 dispone de una funcionalidad muy interesante implementada en la consola de administración llamada “Simulador Tiempo Real Instancias de Ontología” que nos permite simular datos para insertarlos en una ontología. Antes de crear un simulador, debemos crear diversos generadores de instancias, que nos generarán datos entre un listado de valores, con un valor fijo o datos random, pudiendo elegir entre varios tipos de datos según lo que nos convenga generar. Podemos ampliar información sobre el Simulador de datos en el siguiente post

 

Simulando los datos

 

  1. Accedemos a ONTOLOGIAS > Simulador Tiempo Real Instancias de Ontología:
  2. Seleccionamos Crear Simulador.
  3. Vamos a Crear un Generador para cada uno de los atributos que aparecen en la Ontología SmartBuildingVVC (SmartBuilding + Nuestras iniciales), con los siguientes datos fijos. Para ello, escribimos los siguientes datos para cada uno de los generadores (todos con insertar instancia cada 5 seg) y pulsamos Añadir Generador después de introducirlos:
Nombre del Generador Tipo de Generador Valor
houseID Fixed Number 12345
address Fixed String 140 Kendrick Street
city Fixed String Needham
state Fixed String MA
zip Fixed Number 02494
lightID Fixed Number 11111
thermostatID Fixed Number 99999
latitudd Fixed Number 42
longitudd Fixed Number -71

 

4. Nos faltarán dos atributos, watts y temperature, para los que queremos generar datos aleatorios. Para el generador de Nombre watts, elegiremos un Tipo de Generador Random Integer, Insertar Instancia cada 5 segundos, Desde 0 hasta Para el generador de Nombre temperature, elegiremos un Tipo de Generador Random Integer, Insertar Instancia cada 5 segundos, Desde 0 hasta 40. Obteniendo:

GeneradoresDeInstancias

 

5. Pulsamos sobre la pestaña Ontología y seleccionamos nuestra Ontología SmartBuildingVVC (SmartBuilding + Nuestras Iniciales) y seleccionamos para cada atributo, su generador correspondiente

DatosSimuladorBien

 

6. Le ponemos como Identificador SimuladorSmartBuildingVVC (SimuladorSmartBuilding + Nuestras Iniciales) y pulsamos sobre Crear Simulador.

7. Pulsamos sobre el lápiz de nuestro Simulador y en la parte inferior pulsamos sobre ¡Empezar! Con esto empezarán a generarse datos. Pasados un par de minutos, pulsamos sobre ¡Parar!

 

Verificando que los datos se han simulado correctamente

 

  1. Accedemos a la opción de menú Herramientas > Consola BDTR y BDH:

ConsolaBDTR

 

2. Seleccionamos con doble click nuestra Ontología, pulsamos Generar Query y pulsamos sobre Realizar Consulta. Resultando unos datos similares a:

datos2

 

ThingWorx

 

Ahora que hay un lugar para almacenar los datos, vamos a crear algunos datos. Importaremos entidades que simulan los datos de un Smart Building. Estas entidades incluyen un servicio de javascript que simula los datos, así como un temporizador que se ejecuta en un intervalo establecido.

 

Importar las entidades de simulación de datos

 

  1. Descargaremos el archivo Foundation Simulator file a nuestro ordenador
  2. Pulsaremos en Import/Export > From File (situado en la parte superior de la consola)

import

 

3. Seleccionamos el archivo que hemos descargado

4. Pulsamos Import y cuando veamos el mensaje de cargado correctamente pulsamos en close

 

Exportar las entidades importadas

 

  1. Pulsamos sobre el Thing Foundation_Quickstart_Services
  2. Pulsamos en Subscriptions
  3. Seleccionamos el lápiz a la izquierda de Esta suscripción se basa en un temporizador. Cada 30 segundos se ejecuta un script que simulará los datos del Thing MyHouse que creamos y actualizará sus Propiedades.

editarSubsciption

 

4. Seleccionamos la pestaña Subscription Info

5. Seleccionamos el check Enabled para comenzar la simulación

enabled

 

6. Pulsamos en Done y luego Save

 

Verificamos que los datos se están simulando

 

  1. Abrimos el Thing MyHouse y seleccionamos la pestaña Properties
  2. Pulsamos sobre el símbolo de Refresh de la columna Value bajo HouseGatewayTT

propertiesRefresh

 

3. Comprobamos como los valores de temperature y watts varían cada 30 segundos gracias a la simulación

 

datosss

 

 

Sofia2 IoT Platform vs ThingWorx IoT Platform. Primeros pasos (III. Simular datos de entrada)

Sofia2 IoT Platform vs ThingWorx IoT Platform. Primeros pasos (II. Conecta tu dispositivo)

 

sofia2vsThingWorx

 

Este es el segundo post de la serie Sofia2 IoT Platform vs ThingWorx IoT Platform. Primeros pasos. El objetivo es realizar una comparativa de uso de dos plataformas IoT como son Sofia2 y ThingWorx. Para ello, realizaremos un hands on siguiendo un flujo sencillo IoT en el que simularemos un edificio que dispone de dispositivos para la lectura de consumo energético y temperatura. Para terminar, crearemos un cuadro de mando para visualizar esta información.

 

Con el fin de conseguir una mejor comprensión de esta comparativa, hemos estructurado los pasos a seguir, comunes a las dos plataformas, en 4 posts:

  1. Registro y Login. Modelado de datos
  2. Conecta tu dispositivo
  3. Simular datos de entrada
  4. Crear Aplicaciones

 

Hoy veremos el segundo punto.

 

Conecta tu dispositivo

 

Sofia2 IoT Platform

 

Creando un ThinKP

 

Una vez que hemos definido el modelo de datos y lo hemos plasmado en una ontología, tenemos que crear el ThinKP, que, como vimos en el anterior post, representa a cada uno de los elementos que interactúan con la plataforma. En Sofia2 se creará de manera sencilla siguiendo los siguientes pasos:

 

  1. Accedemos al menú Mis ThinKPs

ThinKP1

 

2. Pulsamos sobre Nuevo ThinKP y daremos un nombre AppSmartBuildingVVC (AppSmartBuilding + nuestras iniciales), y una descripción al ThinKP. Seleccionaremos la ontología SmartBuildingVVC que va a utilizar y pulsaremos en Crear.

ThinKP2

 

Siempre podremos acceder a nuestros Token mediante la pestaña Mis Tokens.

 

ThingWorx

 

Creando un Thing

 

Una Thing es una representación digital de un dispositivo físico. En términos de programación, es similar a una instancia de una clase. Crearemos un Thing basándonos en el modelo de datos que creamos anteriormente, nuestro Thing Template llamado HouseGatewayTT.

 

  1. Accedemos al menú izquierdo situándonos encima de Thing y pulsamos en +

thing1

 

2. En el campo Name introduciremos MyHouse

3. En el campo Tags seleccionaremos FoundationQuickstart:Home Application

4. En el campo Thing Template seleccionaremos HouseGatewayTT

thinggg

 

5. Pulsaremos en Save y así guardaremos el Thing

 

Creando un Flujo de Valor

 

Ahora que hemos creado el modelo de datos, debemos crear un destino de almacenamiento para los datos que se transmiten desde los dispositivos. El servidor Foundation ofrece varias formas de almacenar estos datos. Utilizaremos un flujo de valor que es una manera rápida y fácil de almacenar datos de series de tiempo.

 

  1. Iremos a la pestaña Data Storage situada en el lateral izquierdo, nos situaremos sobre Value Streams y pulsaremos en +

ValueStreams1

 

2. Seleccionamos Value Stream y pulsamos Choose

3. Escribimos Foundation_Quickstart_ValueStream en el campo Name

4. En Tags seleccionamos FoundationQuickstart:Home Application

5. Pulsamos Save

 

Actualizando el Thing Template

 

  1. Pulsamos sobre HouseGatewayTT en la página principal
  2. Confirmamos que nos encontramos en la pestaña de Información General (General Information)
  3. Pulsamos edit
  4. Pulsamos en la varita mágica en el campo Value Stream y seleccionamos Foundation_Quickstart_ValueStream
  5. Pulsamos en Save para guardar los cambios

EditTemplate

 

Como hemos podido comprobar, los dos últimos pasos, “Creando un Flujo de Valor en ThingWorx” y “Actualizar el Thing Template”, no son necesarios realizarlos en Sofia2 puesto que al crear la Ontología, se configuran por defecto las Bases de datos de tiempo real e históricas. Además, podremos configurarlas en Ontologías > Mis Ontologías y al pulsar al lápiz en nuestra Ontología  SmartBuildingVVC (SmartBuilding + nuestras iniciales) en la pestaña de Opciones avanzadas:

ontoAvanzadas

 

Sofia2 IoT Platform vs ThingWorx IoT Platform. Primeros pasos (II. Conecta tu dispositivo)

Comparativa solución Edge Sofia2 – AWS IoT

Diagrama01

En una arquitectura IoT, una de las capas fundamentales es la de dispositivos, ya que una gran parte (si no toda, dependiendo del caso concreto) de la captación de información se realiza en dicha capa.

 

Por lo que dentro de la estrategia de cualquier plataforma IoT, disponer de cierta capacidad de procesamiento en los dispositivos, lo que viene denominándose computación en edge, es importante por ciertas razones. Por citar algunas:

 

  • Funcionamiento off-line en casos de perdida de conexión con la plataforma.
  • Realizar en campo una primera agregación y filtrado de los datos, antes de enviarlos a plataforma.
  • Necesidad de velocidad de respuesta en tiempo real sin latencias de red, para acciones que no necesiten de intervención de alto nivel desde plataforma.

 

Es por esto, que una plataforma IoT no está completa si no proporciona a los desarrolladores unas APIs y marco de trabajo que faciliten el desarrollo de aplicaciones en los dispositivos o concentradores.

 

En los últimos años, han surgido placas comerciales como Raspberry-PI, Beagle Bone, ODroid… que por 50€ proporcionan dispositivos con capacidades de procesamiento suficientes para ejecutar lógica compleja en Java, Python, Node.js, C/C++…, e interfaces de red y GPIO, que los convierten en el producto ideal para que innovadores, startups o cualquier otro tipo de empresa desarrollen sus propios productos en su propio laboratorio IoT, sin apenas problemas al hacer la transición al tipo de placa que desplegarán en producción ya que existen multitud de fabricantes que construyen sus concentradores y PCs industriales en estas mismas arquitecturas hardware.

 

En este post analizábamos la propuesta que hace Amazon desde AWS IoT para gestionar el procesamiento en Edge. Hoy, vamos a realizar una comparativa con la propuesta desde Sofia2:

 

  • APIs de programación en dispositivo: Se trata del nivel de integración de más bajo nivel, donde un dispositivo no tiene por qué ser un Gateway, sino que realiza una conexión directa a plataforma.

 

En AWS IoT  disponemos de las siguientes: Java, Javascript, Python, C, Arduino e IOS.

Diagrama01

 

En Sofia2 encontramos APIs de programación para: Java, Javascript, Python, Node.js, C, Arduino, .NET, Android, IOS.

Diagrama01.jpg

 

En conclusión: Ambas plataformas están bastante alineadas con los principales lenguajes del mercado, incluyendo Sofia2 alguno más, tan importante en el mundo dispositivo como lo es Node.js y en movilidad Android.

 

  • Gateways de plataforma: Son el componente de la plataforma que disponibiliza un protocolo de comunicación para que los dispositivos puedan enviar datos a la plataforma. Son especialmente importantes ya que no todos los dispositivos pueden implementar cualquier protocolo, por lo que podrían limitar la conexión a la plataforma para determinados clientes.

 

En AWS IoT el broker de comunicación es exclusivamente MQTT, bien mediante conexión TCP/IP como por HTTP vía Websocket.

 

Diagrama01.jpg

 

En Sofia2 se dispone de los principales protocolos de comunicación IoT: MQTT, DWR (Ajax Push), REST, Websocket, AMQP.

 

A su vez, en Sofia2 los gateways de comunicación están concebidos como plugins, esto es, módulos arquitectónicamente independientes del resto de la plataforma, lo que permite habilitar en cada instalación solo los necesarios, y facilita la tarea de incluir nuevos protocolos de comunicación, sin tener que modificar nada en la plataforma, en función de necesidades concretas de un cliente (Se han desarrollado gateways específicos para JMS, Webservices o sockets TCP/IP).

Diagrama01

 

Asimismo, el API Manager de Sofia2 proporciona otro interfaz para que cualquier dispositivo se pueda conectar con la plataforma, tanto para enviar como para consultar información, en este caso trabajando con APIs REST.

Diagrama01

 

En conclusión: El conjunto de protocolos de comunicación para conectar con la plataforma es más completo en Sofia2, proveyendo a los dispositivos de un mayor número o de alternativas, así como de la posibilidad de incluir nuevos protocolos si así lo demanda el proyecto.

 

  • Arquitectura edge basada en gateway concentrador: Es el caso en el que un dispositivo dentro de una red local asume el rol de intermediario con la plataforma, coordinando al resto de dispositivos, convirtiéndose en el anfitrión.

 

En AWS IoT la propuesta es Greengrass Core. Como comentábamos en este post se trata de un software que proporciona soporte para:

 

Mensajería MQTT en la red local del conjunto de dispositivos que coordina.

Despliegue desde plataforma y ejecución de funciones AWS Lambda en Python 2.7

Seguridad integrada con AWS IoT.

Gestión de sombras de dispositivo.

Integración con AWS IoT e invocación desde Lamdas a otros servicios AWS.

 

El dispositivo concentrador que ejecute Greengrass Core en un grupo AWS necesita procesador ARM o x86 de 1GHz, 128MB de RAM y SO Linux.

Diagrama01.jpg

El alta de un grupo, esto es conjunto de dispositivos coordinados por otro, se realiza desde la plataforma, de manera que es posible hacer una gestión remota, así como desplegar/actualizar nuevas funciones Lambda para modificar o reconfigurar el software en campo.

 

En Sofia2 el modelo de gateway propuesto es el KP Modelo, descargable desde la web de sofia2.com.

Diagrama01.jpg

El KP Modelo es un contenedor software, desarrollado en Java, que proporciona a los desarrolladores un entorno para la ejecución de sus aplicaciones. El KP Modelo de Sofia2, proporciona a los desarrolladores un conjunto de APIs y herramientas, para que solo se tengan que preocupar de programar la lógica de negocio de sus aplicaciones, proporcionando el KP Modelo de manera transparente, toda la infraestructura para gestionar:

 

Conexiones y reconexiones a la plataforma.

Garantía de entrega de mensajes (almacenamiento en local en modo offline y reintentos de envio).

Actualizaciones de software, configuración y reconfiguración desde plataforma.

Monitorización JMX.

 

Dentro del KP Modelo pueden convivir distintas aplicaciones concurrentemente.

 

Las aplicaciones desplegadas en el KP Modelo de Sofia2 son aplicaciones Java, que mediante un patrón event-bus, la implementación de ciertas interfaces codificando la lógica de negocio, y el uso de APIs que abstraen la política de envío de mensajes y reintentos, permiten ejecutar cualquier lógica de negocio y comunicarse con la plataforma Sofia2 en modo bidireccional (envío/notificación).

 

Estas aplicaciones se empaquetan como ficheros .war junto con su configuración y se versionan en la plataforma Sofia2, de manera que se pueden gestionar tanto desde la consola de administración como a través de los servicios REST de administración.

 

Una vez versionado tanto el software como la configuración, la gestión de la configuración de cada KP Modelo físico también se realiza desde la propia plataforma, pudiendo modificar en cualquier momento la versión que se tiene que ejecutar, de manera que KP Modelo físico descargará tanto el software como su configuración, lo desplegará en el contenedor e iniciará su ejecución.

 

A diferencia de AWS Greegrass, el KP Modelo de Sofia2 no proporciona en sí ningún broker de mensajería de MQTT o de cualquier otro tipo para conectar al gateway concentrador el resto de dispositivos. Sino que el broker puede ser desplegado o bien de manera externa y ya una aplicación contenida en el KP Modelo se conecta al broker para recoger los mensajes, o bien como otra aplicación contenida en el KP Modelo, que embebe al propio broker.

 

Esto puede añadir un extra de trabajo, pero da mayor libertad a la hora de elegir otros protocolos, sobre todo protocolos industriales o legados (Modbus, OPC, Zigbee…).

 

Además, independientemente del KP Modelo, aunque se puede utilizar en un modelo hibrido si resultase interesante, Sofia2 ha apostado por Node-RED como motor de ejecución de flujos tanto para la parte plataforma, como para la capa edge.

 

Node-RED tiene un marcado carácter IoT y puede ejecutarse prácticamente en cualquier dispositivo que pueda ejecutar Node.js, permitiendo a los usuarios desarrollar flujos mediante la conexión de nodos, que pueden conectar prácticamente con cualquier cosa, desde un pin GPIO, hasta un bot de Telegram, pasando por brokers MQTT, servidores de correo, servicios REST…

Diagrama01

 

Dentro de la apuesta de Sofia2 por Node-RED, se han desarrollado y puesto a disposición de la comunidad de Node-RED un conjunto de nodos que permiten a los dispositivos conectar con la plataforma Sofia2, tanto para enviar, como para consumir información:

Diagrama01.jpg

 

A la vez que se ha desarrollado la infraestructura necesaria para poder editar los flujos de manera remota desde la consola de administración de Sofia2 y desplegarlos en los dispositivos de forma remota de manera individual o masiva mediante un agente Java muy ligero:

Diagrama01

En el siguiente video podéis verlo en mayor detalle: https://www.youtube.com/watch?v=if-B8R_d1cw

 

En conclusión: Ambas plataformas apuestan por realizar una gestión centralizada tanto del software como de su configuración, proveyendo mecanismos de despliegue y reconfiguración remotos.

 

AWS proporciona un runtime muy potente, pero menos abierto al desarrollador edge, con lógica de programación mediante funciones AWS Lamda y de nuevo orientado únicamente al protocolo MQTT. El KP Modelo de Sofia2 deja abierta la elección del protocolo en la red interna de dispositivos y proporciona mayor libertad permitiendo la ejecución de aplicaciones con la complejidad que el desarrollador decida. A su vez la integración de capacidades Node-RED, abre la puerta a que usuarios menos técnicos y más cercanos al negocio, puedan desarrollar aplicaciones de forma visual.

 

En ambos casos se apuesta por Gateways de capacidades muy reducidas con arquitecturas de bajo coste, un procesador ARM con apenas 128MB es suficiente para ambas alternativas.

 

  • Arquitectura de plataforma descentralizada: En este caso se trata de una arquitectura de computación en edge más compleja que la lógica en ejecución en un gateway, permitiendo el despliegue en campo de distintos componentes de la plataforma, funcionando de manera federada con la plataforma central. Se trata de un escenario muy útil donde hay que coordinar de manera local e independiente todos los elementos de una fábrica, edificio, planta… pero a la vez es necesario mantener una visión global a nivel de lo que está ocurriendo en toda la organización o empresa, propietaria de dichas fábricas o edificios.

 

Para este escenario solo encontramos una alternativa con Sofia2, que proporciona esta descentralización gracias a la Sofia2 Gateway Edition, se trata de una versión más ligera de Sofia2 que incluye:

 

IoT Broker con todas sus capacidades.

Motor de reglas.

Base de datos de tiempo real.

Opcionalmente Base de datos de configuración local.

 

La Sofia2 Gateway Edition proporciona a cada planta autonomía para procesar todos los eventos que ocurran y ejecutar las reglas asociadas para llevar a cabo las acciones necesarias a nivel de planta y disparar las alertas que dichos eventos pudieran estar provocando, a su vez, los eventos de cada planta se almacenan en su una Base de datos de tiempo real local, lo que permite disponer a nivel de planta de todos los cuadros de mando con indicadores relevantes en la planta. Además, para mayor autonomía se puede optar por desplegar la Base de datos de configuración, de manera local en cada planta, lo que permite trabajar en modo desconectado de la instalación central.

Diagrama01.jpg

Toda la información de tiempo real y en su caso de configuración de cada despliegue local de la Sofia2 Gateway Edition, se sincroniza en tiempo real con la instalación central de Sofia2. Lo que a su vez permite disponer de una visión global e integrada de toda la empresa, permitiendo construir reglas, procesos y cuadros de mando que agreguen información de los distintos despliegues de la Sofia2 Gateway Edition.

 

A su vez, desde la instalación central se pueden desencadenar acciones en Gateways de planta concretos, de manera que es posible disponer de reglas de más alto nivel, que analizando y evaluando eventos de las distintas plantas, ocasionen actuaciones en una concreta.

 

No es de extrañar que esta edición de Sofia2 esté íntimamente ligada a escenarios Industrial IoT, en los que es necesario gestionar y sincronizar información de distintas plantas, que a su vez han de tener un funcionamiento autónomo.

 

Comparativa solución Edge Sofia2 – AWS IoT

Sofia2 IoT Platform vs ThingWorx IoT Platform. Primeros pasos (I. Registro y Login. Modelado de datos)

sofia2vsThingWorx

 

Anteriormente hemos realizado comparativas entre diferentes plataformas IoT:

El objetivo de este post es realizar una comparativa de uso de dos plataformas IoT como son Sofia2 y ThingWorx. Para ello, realizaremos un hands on siguiendo un flujo sencillo IoT en el que simularemos un edificio que dispone de dispositivos para la lectura de consumo energético y temperatura. Para terminar, crearemos un cuadro de mando para visualizar esta información.

Con el fin de conseguir una mejor comprensión de esta comparativa, estructuraremos los pasos a seguir, comunes a las dos plataformas, en 4 posts:

  1. Registro y Login. Modelado de datos
  2. Conecta tu dispositivo
  3. Simular datos de entrada
  4. Crear Aplicaciones

 

Hoy empezamos con la primera parte. Manos a la obra!

 

Registro y Login

 

Sofia2 IoT Platform

 

Comenzaremos por acceder al Panel de Control de Sofia2. Si estamos en la Plataforma de Experimentación y no tenemos usuario, pulsaremos en Crear una cuenta nueva

registoSofia2

 

Una vez hecho el LOGIN si nuestro rol es USUARIO: RolUsuario    solicitaremos el pasoacc para poder crear Ontologías.

PasoAColaborador

 

Una gran ventaja que ofrece Sofia2 Iot Platform es que podremos usar el entorno de experimentación de forma gratuita sin límite de tiempo.

 

 

ThingWorx Iot Platform

 

Para crear una cuenta en esta plataforma debemos ir a su web y pulsar en Sign Up y rellenar su formulario.

SignUp

 

Recibiremos un email donde tendremos que pinchar en el enlace para logarnos y, una vez logados pincharemos en la pestaña superior derecha:

thingg

 

Pulsaremos en Create Foundation Server, y en unos minutos, el servidor se creará. Posteriormente, tendremos que pulsar en Launch Foundation Server para lanzar el servidor y poder usar ThingWorx.

 

Este entorno lo tendremos disponible de forma gratuita durante 30 días.

thing30dias

 

 

Modelado de datos

 

Sofia2 IoT Platform

 

Creando Ontologías

 

La plataforma Sofia2 funciona en torno a los datos enviados por los dispositivos o aplicaciones conectados. Cualquier evento, medida, comando… se gestiona en la plataforma como una entidad, que es almacenada, puede ser consultada y además puede desencadenar ciertas acciones (notificaciones, ejecución de reglas/flujos…).

 

La Plataforma sofia2 gestiona dos tipos de entidades:

 

  • Assets. Un asset es todo elemento (físico o virtual) capaz de generar o consumir información de carácter sensorial y gestionarla a través de la Plataforma Sofia2
  • Ontologías. Los assets generan información y dicha información se modela por medio de ontologías en la Plataforma

 

Una Ontología representa el Modelo de Dominio que maneja un ThinKP: Un Dispositivo (en terminología Sofia2 hablamos de KP: Knowledge Processor o de ThinKP por la unión de Thing + KP) representa a cada uno de los elementos que interactúan con la plataforma, bien publicando, o bien consumiendo información. Un ThinKP puede representar desde un dispositivo sencillo (un Arduino o un iBeacon) a un Gateway (una Raspberry) o un Sistema Empresarial (Backend Java). Un ThinKP puede manejar una o varias Ontologías.

 

Las Ontologías se representan en JSON y pueden representar un modelo básico (como si fuera una Tabla) o un modelo complejo con relaciones (como si tuviésemos un conjunto de tablas relacionadas). Cuando un Dispositivo (ThinKP) envía una medida hablamos de Instance (Instancia de Ontología). Las Ontologías pueden crearse de diversas formas: visualmente en un diagrama de clases UML, a través de un esquema JSON o XML, campo a campo o a partir de un CSV/XLS.

 

Por lo tanto, una Ontología tiene los siguientes propósitos:

 

  • Definir semánticamente el tipo de datos, con sus atributos y restricciones.
  • Definir el soporte físico (Colecciones, Tablas…) para el almacenamiento de datos tanto en base de datos de tiempo real como en histórico.
  • Definir las reglas de seguridad en el acceso a la información contenida en la ontología.

 

Para conocer con más detalle las Ontologías, tenemos a nuestra disposición los siguientes documentos:

 

 

En la consola de administración de Sofia2 existen diferentes alternativas para crear una ontología. En este caso utilizaremos la opción de Crear ontología paso a paso.

 

  1. Entramos en la consola de administración y seleccionaremos Ontologías > Crear Ontología

crearOntologia0

 

2. A continuación Creación Paso a Paso. Modelaremos una ontología para simular un edificio inteligente y los datos de iluminación y temperatura que recogerá. Para ello queremos disponer de los atributos:

Propiedad Tipo de dato
SmartBuildingId string
address string
city string
state string
zip string
geometry object
lightID string
watts integer
thermostatID string
temperature integer

 

3. Escribiremos SmartBuildingVVC (SmartBuilding + nuestras iniciales) en el campo Nombre, la marcaremos como Activa, le daremos una descripción y palabras clave en Meta_inf:

CrearOntologia1

 

4. A continuación pulsaremos en Selección Plantilla y elegiremos la plantilla SmartBuildingBasic perteneciente a la Categoría Smart Building:

CrearOntologia2

 

Veremos cómo nos aparecen todas las propiedades que queríamos para modelizar nuestra Ontología. Podremos añadir o quitar cualquiera de estas propiedades con el check que nos aparece en la última columna de la tabla:

CrearOntologia3

 

También podremos añadir nuevas propiedades pulsando en la pestaña Añadir Nuevas Propiedades.

 

5. En la Pestaña Generador Esquema e Instancia JSON pulsaremos en Generar Esquema, con lo que obtendremos el JSON-Schema correspondiente a nuestro modelado de datos:

CrearOntologia4

 

6. Finalmente podemos Generar una Instancia con un dato de ejemplo para el tipo de datos definido por esta ontología, y darla de alta en la plataforma pulsando Crear.

 

Resumen:

 

Al finalizar este paso, habremos dado de alta en Sofia2 una ontología, caracterizada por:

 

  • Definir el tipo de datos SmartBuildingVVC, Que tendrá los atributos definidos anteriormente. De forma que la plataforma admitirá Instancias que contengan datos en formato JSON del tipo: {“SmartBuildingBasic”:{ “SmartBuildingId”:”string”,”address”:”string”,”city”:”string”,”state”:”string”,”zip”:”string”,”geometry”:{“type”:”Point”,”coordinates”:[9,19.3]},”lightID”:”string”,”watts”:1,”thermostatID”:”string”,”temperature”:1}}
  • Definición en Base de datos de tiempo real del soporte de almacenamiento para la ontología. En una instalación de referencia (Con MongoDB como BDTR) esto se materializa en una colección llamada SmartBuildingVVC ¸ que será donde se almacenen en tiempo real los datos.
  • Definición en Base de datos histórica del soporte de almacenamiento de datos históricos para la ontología. En una instalación de referencia (Con Hive sobre Hadoop como BDH) esto se materializa en una tabla Hive llamada SmartBuildingVVC ¸ que será donde se almacenen los datos cuando su ventana de tiempo real finalice.
  • Definición de permisos sobre la ontología. En este caso solo tiene permiso el propietario, ya que fue declarada como privada. No obstante, desde el menú de ontologías, el propietario puede dar permisos (Lectura, Escritura o Total) a usuarios concretos, o a grupos de usuarios con los que tenga proyectos comunes. Para ampliar información, podemos consultar el post Concepto de Space/Proyecto

 

Gráficamente hemos intervenido en los siguientes componentes de la plataforma:

resumen

 

 

ThingWorx

 

En ThingWorx, antes de comenzar a crear entidades en la plataforma, es útil crear etiquetas de modelo (Model Tags) para que pueda exportar y guardar las entidades que ha creado. Las Model Tags son términos utilizados para categorizar y agrupar elementos en toda la plataforma. Estas etiquetas pueden usarse para agrupar, controlar versiones, buscar y migrar entidades. Las etiquetas del modelo consisten en un “vocabulario” y un “término” (vocabulario: término). Por ejemplo, Color: Azul o Departamento: Finanzas.

 

Creando un vocabulario de Model Tag

 

  1. Una vez lanzado el servidor pulsando Launch Foundation Server, nos situaremos sobre la pestaña Model Tags y pulsaremos en +

ModelTag+

 

2. Escribiremos “FoundationQuickstart” en el campo Name y pulsaremos en Save.

 

 

Creando un término de Model Tag

 

  1. Abrimos el vocabulario “FoundationQuickstart” y pulsamos en edit.
  2. Pulsamos en Manage Terms

manageTerms

 

3. Introducimos “Home Application” en el primer campo y pulsamos Add Term.

HomeAplication

 

Con esto ya tendremos creados un vocabulario y un término, ahora crearemos un Thing Template (Modelo de Thing).

 

 

Creando un Thing Template

 

Un Thing Template, nos servirá para modelar los datos, de la misma forma que hicimos al crear una Ontología en Sofia2.

 

  1. Nos situaremos encima de “Thing Templates” y pulsaremos en +

ThingTemplate+

 

2. En el campo Name escribiremos: “HouseGatewayTT

 

3. En el campo Tags pulsaremos en el icono de la varita mágica y seleccionaremos el tag FoundationQuickstart:Home Application

tagss

 

 

4. En el campo Base Thing Template seleccionaremos Generic Thing como modelo.

BaseThingTemplate

 

5. Pulsando ahora en Properties en el menú izquierdo y pulsando en Add My Property empezaremos a introducir los atributos que formarán nuestro esquema. Para ello, introduciremos el nombre (Name), el tipo de dato (Base Type) y seleccionaremos los diferentes aspectos que queremos que tengan. (Persistent: Las propiedades que no son persistentes restablecerán sus valores a su valor predeterminado después de una Thing o reinicio del sistema. Logged: Especifica si el valor de la propiedad debe registrarse automáticamente en un flujo de valores siempre que cambie los datos, en función del tipo de cambio de datos) Pulsamos Done and Add y repetimos estos pasos para cada propiedad. Para la última propiedad, pulsamos Done y luego, Save.

 

Atributos a introducir:

Name Base Type Persistent Logged
HouseId string x
address string x
city string x
state string x
zip string x
house_lat_long location x x
lightID string x x
watts number x x
thermostatID string x x
temperature number x x

 

 

Completamos los campos:

introDatos

 

Con lo que obtendremos:

ThinggggTemplate

Sofia2 IoT Platform vs ThingWorx IoT Platform. Primeros pasos (I. Registro y Login. Modelado de datos)