Gestión avanzada de dispositivos en Sofia2

En Sofia2 somos conscientes de que en los próximos años la importancia de la gestión de dispositivos conectados va a aumentar de forma considerable, sobre todo en el ámbito IoT. Es por ello que desde sus primeras versiones, Sofia2 proporciona una gestión de dispositivos integrada en la plataforma.

En anteriores Post ya hemos visto cómo se entiende en Sofia2 el concepto de dispositivo y de qué manera se realiza su gestión. Podemos repasar algunos conceptos básicos:

 

  • Spaces (Proyectos): Representa un entorno colaborativo virtual donde los usuarios pueden crear sus aplicaciones, por ejemplo creando Things, modelando sus entidades, aplicando algoritmos o creando visualizaciones.
  • Ontología (Entities): Una Entity (Thintology) representa el Modelo de Dominio que maneja una Thing.
  • ThinKP: Un ThinKP (en terminología Sofia2 hablamos de KP: Knowledge Processor o de ThinKP) representa a cada uno de los elementos que interactúan con la plataforma, bien publicando, bien consumiendo información.

En Sofia2 es este ThinKP el que puede representar desde un dispositivo sencillo a un Gateway o un Sistema Empresarial.

Sofia2 contaba ya con una gestión de dispositivos básica. Entre otras funcionalidades, se contemplaban:

 

  • Gestión ThinKPs activos (conexiones activas de dispositivos con la plataforma).

  • Gestión de Conexiones (conexiones físicas y lógicas y actuaciones sobre las mismas).

  • Gestión de Configuraciones SW (configuración del SW instalado en los dispositivos clientes).

  • Gestión de Assets (Inventariado de dispositivos).

En las últimas versiones de la plataforma dicha gestión se ha visto ampliada considerablemente.

 

  • Extensión del API de comunicación con la plataforma. Se han incorporado nuevas directivas:
    • Error: se utilizará para comunicar a la plataforma errores que se hayan producido en el dispositivo y que quieran registrarse en la plataforma.
    • Log: permitirá disponer de un log completo en la plataforma de las operaciones llevadas a cabo en el dispositivo.
    • Location: actualizará la ubicación del dispositivo para poder realizar un seguimiento sobre el mismo.
    • Status: mediante este tipo de mensaje el dispositivo podrá actualizar el estado en el que se encuentra y que quede registrado en Sofia2. Como estado entendemos un grupo de variables y sus valores (pueden extraerse del dispositivo en cuestión: memoria libre, uso de CPU,…).
    • La directiva Command está compuesta por dos operaciones de comunicación:
      • SubscribeCommand: Cualquier Instancia de ThinKP puede subscribirse a la recepción de comandos sin necesidad de tener sessionKey (a diferencia de las subscripciones normales). Desde Sofia2 recomendamos realizar esta suscripción siempre un dispositivo (ThinKP) inicie su actividad.
      • Command:
        • A través de esta operación es posible mandar mensajes de comando a cualquier instancia de ThinKP que se haya suscrito previamente.
        • Para realizar el envío de comandos es necesario estar autenticado en Sofia2 y disponer de una sessionKey correcta. De esta manera se evita el envío malicioso de comandos no autorizados. El mensaje de comandos tiene un campo llamado Args dónde pasar los argumentos necesarios al ThinKP sobre el que se quiera actuar. Ejemplos de uso serían:
          • Pedir a un dispositivo que se reinicie.
          • Pedir a un dispositivo que envíe su estado actual.

Mediante el envío de información a través de estos nuevos tipos de mensajes se obtendrá una visión centralizada del estado y ubicación de todos los dispositivos conectados a la plataforma en tiempo real. Se dispondrá de un histórico en el que analizar los distintos estados por los que haya pasado cada uno de ellos así como los problemas que se hayan detectado. Además se podrá actuar remotamente sobre dispositivos enviándoles comandos a ejecutar.

 

  • Unificación en la consola de toda la operativa referida a dispositivos (ThinKPs)

En la consola de administración y configuración de la plataforma, se ha añadido una opción de menú que engloba toda la gestión asociada a ThinKPs.

 

– Mis ThinKPs: Permite dar de alta nuevos ThinKPs en la plataforma, definiendo el conjunto de datos sobre los que trabajaran, así como modificar o eliminar los ya existentes. Además se permite gestionar sus instancias y sus tokens de conexión con la plataforma.

Estado ThinKPs: Nueva opción que permite visualizar el estado de cada uno de los ThinKPs conectados con la plataforma (la veremos más en detalla a continuación en este post).

– ThinKPs Conectados: Listado de ThinKPs conectados con la plataforma así como detalles de las mismos (identificación, clave de sesión, fecha última conexión).

– Contenedor de ThinKPs: Permite desplegar ThinKPs en la propia plataforma, totalmente gestionables.

– Config SW en ThinKPs: Para asociar distintas versiones de SW y parámetros de configuración con ThinKPs o InstathinKPs.

Además como opción de administración se incluye:

– Gestión de conexiones: permite monitorizar y actuar sobre las conexiones, tanto físicas como lógicas que establecen los distintos ThinKPs con la plataforma.

 

  • Nuevo UI para la gestión centralizada de información proveniente de dispositivos (Estado ThinKPs): Esta opción muestra una lista de KPs conectados con la plataforma, así como un listado con la última información recibida desde los mismos.

En un primer listado se mostrarán las instancias de ThinKPs conectadas con la plataforma.

Si se selecciona una de las instancias de la tabla, los componentes de la pantalla quedarán filtrados, mostrando información relativa únicamente a esa instancia de ThinKP seleccionada.

A su lado se mostrará la posición de cada uno de ellos sobre un mapa. Esta información provendrá de los mensajes de tipo LOCATION que cada uno de los dispositivos ha ido enviando a la plataforma. Al mantenerse un histórico de esta información, se podrá mantener trazabilidad sobre la ubicación de cada uno de los dispositivos.

Si se sitúa el cursos sobre uno de los puntos del mapa, se ofrecerá información adicional, como la precisión, velocidad y rumbo del dispositivo.

La opción Ver en detalle, despliega un mapa a pantalla completa para una mejor visualización.

Incorpora un componente de búsqueda para filtrar entre los dispositivos mostrados y el número de dispositivos a mostrar.

Además de este componente visual que permite la localización de los dispositivos, se incorporan tres listados en los que se mostrará información proveniente de los mensajes de ERROR, LOG y STATUS recibidos desde los dispositivos.

El listado de Mensajes de Error mostrará el contenido de los mensajes de ERROR recibidos. Se incluye un campo severidad que indicará la gravedad del mensaje recibido. Como niveles de ERROR están disponibles los siguientes:

 

  • DEBUG
  • INFORMATIONAL
  • NOTICE
  • WARNING
  • ERROR
  • CRITICAL
  • ALERT
  • EMERGENCY

Además se incluye el identificador de la instancia de ThinKP que ha enviado el mensaje, un código de error asociado, el contenido del mensaje de error y la fecha de envío. Tanto el código de error como el contenido del mensaje pueden ser definidos y construidos en el propio dispositivo, siendo configurables completamente por el usuario.

Se incluye además un enlace para mostrar el detalle del log de error. Mostrará, de forma similar al detalle de ubicaciones, un interfaz que permitirá filtrar por distintos criterios y mostrar los mensajes de error en un listado a pantalla completa.

El listado de mensajes de Log, mostrará los mensajes de tipo Log que los dispositivos hayan ido enviando a la plataforma.

El listado muestra como primera columna el nivel de log del mensaje enviado. Sus posibles valores son:

 

  • TRACE
  • DEBUG
  • INFO
  • WARN
  • ERROR
  • FATAL

Se incluye también el identificador de la instancia de ThinKP que ha enviado el mensaje, el contenido del mensaje y la fecha de envío.

Al igual que para la el listado de mensajes de error se incluye un enlace para mostrar el detalle del log que mostrará un interfaz que permitirá filtrar por distintos criterios y mostrar los mensajes de log a pantalla completa.

El listado de mensajes de Status mostrará los mensajes de estado que se han recibido desde los dispositivos. En este caso se mostrará la identificación de la instancia de Thinkp, así como el valor de las variables enviadas desde el dispositivo y la fecha de envío de las mismas.

Se dispone también del mismo enlace Ver en detalle con la misma funcionalidad que en el resto de listados:

 

  • El envío de mensajes de la directiva COMMAND se realiza mediante el api SSAP que proporciona la plataforma. El formato de dichos mensajes sería el siguiente:

SUBSCRIBECOMMAND

{“messageId”:null,”sessionKey”:null,”ontology”:null,”direction”:”REQUEST”,”messageType”:”SUBSCRIBECOMMAND”,”body”:”{“thinkp”:”TestKP”,”thinkpInstance”:” THINKP:INS “,”token”:”XXXXXXXXXXXXXXXXX”,”type”:”STATUS”}”}

COMMAND

{“messageId”:null,”sessionKey”:”XXXXXXXXXXXXXXX”,”ontology”:null,”direction”:”REQUEST”,”messageType”:”COMMAND”,”body”:”{“thinkp”:”TestKP”,”thinkpInstance”:”THINKP:INS”,”type”:”STATUS”,”args”:null}”}

El futuras versiones de la plataforma, se implementará un interfaz que permita el envío de mensajes a dispositivos.

Gestión avanzada de dispositivos en Sofia2

Logroño adjudica la implantación de su Plataforma Smart City

LogronoSmartCity

 

La Junta de Gobierno Local del Ayuntamiento de Logroño, en su sesión del pasado miércoles 12 de Abril adjudicó el suministro, implantación, desarrollo y mantenimiento de la Plataforma ‘Smart Logroño‘ a la UTE Indra Sistemas y Suma Info.

 

FEEP IoT&BigData Platform Sofia2 servirá como base tecnológica para este proyecto que se extenderá hasta 2021.

Sofia2InfografiaRecortada

 

Según ha informado el portavoz del equipo de Gobierno municipal, Miguel Sainz, la propuesta de la UTE adjudicataria “proporciona una solución de plataforma de gestión integral robusta, consolidada y madura” que, además, contempla la propia evolución de la plataforma con una visión “global e integradora de la ciudad, la administración y los ciudadanos.

La plataforma incluirá “dos portales de información”, de los que el primero será de acceso a los datos públicos, “un ‘opendata’ que proporcionará información municipal sobre cifras estadísticas y de servicios de gran utilidad para que los emprendedores puedan tomar decisiones y crear negocios”.

 

El segundo de los portales, será el “Smart city”, que “permitirá que las relaciones del ciudadano con el Ayuntamiento sean más transparentes” y tendrá acceso directo a contenidos de la plataforma, como el servicio 010, la gestión del tráfico y alumbrado y “un proyecto piloto de la gestión y manejo de la red municipal de aguas”.

 

También se plantea la normalización de la información, gestión de dispositivos, gestión analítica y georreferenciada de los datos y la elaboración de mapas, informes e indicadores para la gestión de los servicios.

 

 

 

 

 

 

 

Logroño adjudica la implantación de su Plataforma Smart City

Creación grupo Meetup IoT & BigData Sofia2 Lab

portadaMeetup1

 

IoT & BigData Sofia2 Lab es el nuevo grupo que se ha creado en la plataforma Meetup.com para dar a conocer las capacidades de la plataforma  IoT y Big Data de Minsait, Sofia2.

 

Los Meetups son grupos virtuales de personas interesadas en temáticas comunes que se reúnen para debatir y exponer sobre ellos (en nuestro caso tecnológicas y de innovación).

 

El grupo se ha creado con la intención de realizar reuniones y eventos al menos una vez al mes. Se pretende que estas reuniones no solo tengan carácter divulgativo, sino además involucrar a los asistentes en la realización de talleres y ejemplos prácticos en torno a Sofia2 y las tecnologías IoT y Big Data.

 

Con poco más de un mes de existencia, IoT & BigData Sofia2 Lab, cuenta ya con casi 300 miembros (puedes acceder e inscribirte a él aquí), y dos Meetups realizados.

 

7

 

En el primero de ellos, realizado el 8 de marzo, se presentó la plataforma, se identificaron las oportunidades IoT, la propuesta de Sofia2 en el mundo IoT y se desarrolló un taller con dispositivos Beacon y app móvil Sofia2

 

IMG_0738

 

El segundo Meetup, denominado “Taller IoT. Desarrollo visual en Sofia2 con Raspberry, Node-RED y dashboards”, reunió a más de 50 personas, y en él, se profundizó en un flujo típico IoT: Se realizó un pequeño taller práctico, donde con unas Raspberrys Pi se utilizó Node-RED para capturar información de sensores y enviarla a la plataforma, donde también a través del soporte con  Node-RED se definió un flujo visual para su tratamiento.

 

El próximo 4 de Mayo se celebrará el tercer Meetup, ” Taller Sofia2 Analytics: ¿Sabes cuántas horas te pasas en la oficina?” en el que se presentarán los componentes y se pondrán a prueba las capacidades analíticas de la plataforma siguiendo la siguiente agenda:

 

1. Presentación de los componentes y capacidades analíticas de la plataforma, breve descripción del Notebook Apache Zeppelin y su integración con Python, con Spark…

2. Visualización de datos con matplotlib y seaborn. Que gráficos se soportan y cuando hay que utilizarlos.

3. Demo Analytics empleado del mes. Los asistentes que quieran, utilizando la plataforma y las librerías pandas y seaborn de Python, podrán ver el número de horas al día que estuvieron en la oficina el mes pasado.

 

Si quieres asistir a este Meetup, incríbete gratuitamente aquí

 

Creación grupo Meetup IoT & BigData Sofia2 Lab

Primer Meetup: Presentación del grupo “IoT & BigData Sofia2 Lab”

El pasado miércoles 8 de marzo se realizó el primer Meetup sobre la plataforma Sofia2 llamado Presentación del grupo “IoT & BigData Sofia2 Lab” (Puedes acceder a la página del evento aquí). Los meetups sirven para reunir a personas interesadas en temáticas comunes y debatir y exponer sobre ello.

 

meetupPrimero

 

Seguir leyendo “Primer Meetup: Presentación del grupo “IoT & BigData Sofia2 Lab””

Primer Meetup: Presentación del grupo “IoT & BigData Sofia2 Lab”

Sofia2 meets NB-IoT

imagen-1

Yes,  Narrow Band IoT or NB-IoT  is here, or you may call it LTE Cat.NB1. Remember it is a Low Power Wide Area (LPWA) technology that works virtually anywhere.

 

But, what is NB-IoT?

 

It is a new 3GPP radio-access technology designed to achieve excellent coexistence performance with legacy GSM, General Packet Radio Service (GPRS) and LTE technologies. NB-IoT requires 180 kHz minimum system bandwidth for downlink and uplink. A GSM operator can replace one GSM carrier (200 kHz) with NB-IoT. NB-IoT is optimized to ensure harmonious coexistence with LTE, and thus such an “in-band” deployment of NB-IoT inside an LTE carrier will not compromise the performance of LTE or NB-IoT. An LTE operator also has the option of deploying NB-IoT in the guardband of the LTE carrier.

 

NB-IoT reuses the LTE design extensively, including downlink orthogonal frequency-division multiple-access (OFDMA), uplink single-carrier frequency division multiple-access (SC-FDMA), channel coding, rate matching, interleaving, etc. Therefore it reduces the time required to develop full specifications. Also, it is expected that development times for NB-IoT products will be significantly reduced due to existing LTE equipment and software vendors. In other words, using NB-IoT leverages current vendors’ infrastructures, avoiding extra deployment costs.

 

To summarize, NB-IoT has been designed to be used by Internet of Things applications:

 

imagen-1

 

Seguir leyendo “Sofia2 meets NB-IoT”

Sofia2 meets NB-IoT