UI de visualización del resultado de ejecución de procesos

Con la release 2.12 de Sofia2 se ha añadido al menú de Herramientas la opción de poder visualizar el estado de los procesos de la plataforma, como por ejemplo las reglas CEP o las reglas de Script.

menu_logprocesos

Con esta opción podremos ver detalles como el tipo de proceso, la hora de inicio y fin de ejecución, el usuario que creó el proceso (la definición de la regla CEP por ejemplo) la ontología asociada si la hubiere, el estado en el que quedó el proceso tras su ejecución , etc…

logprocesos

logprocesos_detalle

 

UI de visualización del resultado de ejecución de procesos

Módulos que componen Sofia2

Sofia2 está concebida bajo una Arquitectura modular en la que cada módulo tiene asignadas un conjunto de responsabilidades.

Esta Arquitectura puede representarse de esta forma:

  • SIB Runtime: Es el core de la plataforma, el que publica interfaces (MQTT, WebSockets, REST,…) para publicar y consultar información.
  • SIB API Manager: Es la pieza que cuando se publican APIs REST sobre las ontologías (o APIS externas) permite acceder a ellas.
  • SIB Web Console: Consola Web + API Web para gestionar/administrar la plataforma.
  • SIB Tools: se encarga de lanzar las reglas que le llegan y otros procesos como el proceso de paso BDTR a BDH
  • BDC: almacena la configuración de la Plataforma. Puede ser cualquier BD relacional. Sofia2 está certificada sobre MySQL y Oracle.
  • BDTR: almacena datos del tiempo real. La implementación de referencia funciona sobre MongoDB y permite consultar en SQL.
  • BDH: almacena información histórica, soportada sobre infraestructura Hadoop
  • SDK: ofrece APIS y herramientas para trabajar con Sofia2..
Módulos que componen Sofia2

Nuevos tipos de gadgets

En la release 2.12 de Sofia2, además de los gadget a de tipo HTML Externo se han añadido gadgets de tipo Mapa y gráficos de línea.

A través de la opción Visualizaciones -> Crear Dadget podremos elegir cualquiera de estos tipos:

menu gadgetsPara cada una de estas representaciones visuales de información de instancias de ontologías, podremos seleccionar tomar los datos en directo o a través queries:

Crear gadget lineas

En ambos casos deberemos de seleccionar la ontología/s y el atributo/s que queremos representar visualmente:

ejemplo gadget lineas

ejemplo gadget mapa

Cada uno de los gadget que se creen podrán ser luego empleados por los usuarios en sus propios Dashboard.

Nuevos tipos de gadgets

Generación Ontología a partir de Excel/CSV

La versión 2.12 de Sofia2 incorpora cambios en la funcionalidad de carga de datos a partir de un EXCEL/CSV.

La pantalla de Creación de una Ontología a partir de un Excel/CSV ahora presenta el siguiente aspecto:

El flujo de trabajo sería el siguiente:

1) Se seleccionará un fichero Excel/CSV.

Si el fichero tiene extensión .csv, se mostrará el campo delimitador que se utilizará para separar las columnas.

2) Se seleccionará o no el check “Ids de columna en la primera fila”. Permitirá indicar si contiene títulos de columna en la primera fila, que se podrán utilizar como identificadores de los atributos en el esquema.

3) Una vez seleccionados estos datos, se pulsará sobre el botón Cargar Información.

4) A continuación se mostrará una tabla en la que se incluirán los datos del Excel.

– Si se ha seleccionado el check “Ids de columna en la primera fila” se mostrarán los títulos de las columnas del Excel/CSV como identificadores. En caso contrario se mantendrán vacios. En ambos casos es un campo editable.

– Se mostrará también el dato correspondiente a la segunda fila del fichero, para que sirva de muestra.

– En la tercera columna se mostrará el tipo de datos al que pertenece el dato de la columna. En la versión actual se permiten los tipos: String, Boolean, Number, Geometry-LAT y Geometry-LON. Es modificable y debe definirlo el usuario. En principio está seleccionado el tipo String.

o En cuanto a los tipos, sólo se permite un tipo geográfico (una combinación de Geometry-LAT y Geometry-LON). Y siempre que haya uno de esos tipos, tiene que estar el otro. Como validación adicional, tampoco se pueden seleccionar varios tipos de esos dos (más de un Geometry-LAT o más de un Geometry-LON).

– La cuarta columna mostrará un check que permitirá seleccionar qué columnas se cargarán durante el proceso.

Eliminar Fichero, eliminará el fichero seleccionado y vaciará la tabla de atributos, el esquema generado y la instancia asociada al esquema.

5) Al pulsar sobre Generar Esquema, se generará el esquema correspondiente, utilizando para ello los atributos seleccionados en la tabla (con sus identificadores y tipos asociados) y el nombre de la ontología.

6) Si se pulsa sobre Generar Instancia, se generará una instancia de la ontología utilizando el esquema generado.

7) Para terminar, se pulsará sobre Crear, que creará la ontología y cargará los datos incluidos en el Excel. Finalizado el proceso, se redirigirá a la pantalla de consulta, donde se mostrará un informe de la carga de datos:

Generación Ontología a partir de Excel/CSV

Cyber-Physical Systems

En el mundillo de la I+D, manejamos hoy los conceptos que serán populares dentro de un par de años. En el momento actual, son tendencia los Cyber-Physical Systems (CPS), que pronto formaran parte de nuestro lenguaje cotidiano, como lo son hoy Internet of Things (IoT), o Big Data.

Vamos a ver una breve introducción de que es y para qué sirve un CPS.

CPS tiene muchas definiciones y no es un concepto nuevo, pero es en los últimos meses cuando se han popularizado. En una descripción muy genérica, se referiría a sistemas IT embebidos en objetos físicos, que están interconectados y pretenden facilitar a los usuarios servicios y aplicaciones más avanzados que los actuales.

El objetivo es que, a través de los CPS, el mundo físico es transformado en un mundo virtual para formar una Internet de las Cosas, Datos y Servicios.

Un CPS es un sistema complejo autónomo que incluye otros sistemas (como un Sistema de Sistemas) con tecnologías Smart. Aplicar la tecnología Smart a los sistemas embebidos les proporciona una ventaja sobre otros sistemas no Smart. De esta manera, un fabricante de vehículos puede considerar que un coche, o un avión, es un CPS en sí mismo, y desde una perspectiva diferente, una Smart City también lo sería.

grafico_coche_CPS

El desarrollo de los CPS se está viendo impulsado por tres tendencias convergentes que son:

  • La proliferación de sistemas embebidos inteligentes.
  • La aparición de nuevos Servicios IT, como servicios de pago o servicios en la nube.
  • Las comunidades y ecosistemas de desarrolladores, como App Stores, Android o Eclipse.

El proyecto europeo del FP7 CyPhERS considera los CPS como el próximo salto tecnológico en la industria de los objetos embebidos. Hay una serie de factores que apoyan esto, basado en el rápido progreso tecnológico de los últimos años. Las tecnologías Wireless han provocado el boom de la ubicuidad a través de la popularización de Bluetooth y ZigBee; y desde una perspectiva más social, los usuarios están experimentando el cambio de paradigma que supone que no exista un dispositivo para cada una de las funcionalidades, sino que estas funcionalidades estén siendo distribuidas en la red de objetos embebidos.  Para hacer esto, los CPS están sirviéndose de tecnologías pre-existentes, como pueden ser tecnologías cloud, redes de sensores, sistemas IT y tecnologías de Internet de las Cosas.

IoT es una de las tecnologías que los CPS usan y necesitan para representar objetos virtualmente con unos identificadores únicos en una red similar a como ocurre en Internet. CPS por tanto evoluciona IoT y proporcionará servicios adicionales, los llamados servicios Smart, que no estaban presentes en las tecnologías IoT.

Aquí es donde encaja como anillo al dedo SOFIA2. Un CPS requiere tecnología que permita gestionar esas interconexiones, los flujos de información y los servicios prestados en los dispositivos Smart embebidos, y SOFIA2 se presta de manera natural para proveer estas características.

Llegados a este punto, ¿deberíamos empezar a pensar en CPSofia?

Cyber-Physical Systems

Mensaje SSAP BULK

Una de las funcionalidades incluidas en la Release 2.12 de Sofia2 es el mensaje SSAP BULK añadido al juego de operaciones SSAP.

Se trata de un mensaje enviado por un KP al SIB en el que se pueden agrupar varios mensajes de tipo INSERT, UPDATE y DELETE. De este modo, es posible agrupar en el código de una App Sofia2 (KP) un conjunto de mensajes que se notificarán posteriormente al SIB en un único envío.

Una vez recibido un mensaje de tipo BULK en el SIB, este será descompuesto y cada mensaje INSERT, UPDATE o DELETE agrupado, se procesará de manera individual del mismo modo que si hubieran sido enviados por separado.

Se trata de un mensaje síncrono en el que la App Sofia2 envia al SIB el atributo body de cada tipo de mensaje INSERT, UPDATE, DELETE agrupado y el SIB responde con un resumen conteniendo

  • Operaciones correctas: El ID de los objetos insertados, modificados, eliminados
  • Operaciones erróneas: El mensaje erróneo junto con la descripción del error

El formato de este mensaje es el siguiente:

Request: Solicitud desde App Sofia2 a SIB:

{

“body”:”[

{\”body\”:\”<INSERT_MESSAGE1_BODY>\”, \”ontology\”:\”TestSensorTemperatura\”, \”type\”:\”INSERT\”},

{\”body\”:\”<INSERT_MESSAGE2_BODY>\”, \”ontology\”:\”TestSensorTemperatura\”, \”type\”:\”INSERT\”},

{\”body\”:\”<UPDATE_MESSAGE1_BODY>\”, \”ontology\”:\”TestSensorTemperatura\”, \”type\”:\”UPDATE\”},

{\”body\”:\”<UPDATE_MESSAGE2_BODY>\”, \”ontology\”:\”TestSensorTemperatura\”, \”type\”:\”UPDATE\”}

]”,

“direction”:”REQUEST”,

“messageId”:null,

“messageType”:”BULK”,

“ontology”:null,

“sessionKey”:”<SESSION_KEY>”

}

Response: Respuesta desde el SIB

{

“body”:”{

\”data\”:\”{

\\\”deleteSummary\\\”:null,

\\\”insertSummary\\\”:{

\\\”errors\\\”:[],

\\\”objectIds\\\”:[···········]

},

\\\”updateSummary\\\”:{

\\\”errors\\\”:[],

\\\”objectIds\\\”:[···········]

}

}\”,

\”error\”:null,

\”errorCode\”:null,

\”ok\”:true

}”,

“direction”:”RESPONSE”,

“messageId”:null,

“messageType”:”BULK”,

“ontology”:null,

“sessionKey”:”<SESSION_KEY>”

}

A la hora de programar Apps Sofia2, el API Java proporciona utilidades para trabajar con el mensaje SSAP BULK:

En este sentido, se ha añadido al API Java la clase SSAPBulkMessage: Es una clase derviada de SSAPMessage, hereda todos sus atributos y añade métodos para facilitar la construcción de un mensaje SSAP de tipo BULK a partir de mensajes SSAP de tipo INSERT, UPDATE y DELETE. Estos métodos son:

· addMessage(ssapMessage: SSAPMessage):SSAPBulkMessage: Añade al atributo “body” del mensaje SSAPBulkMessage el mensaje INSERT, UPDATE o DELETE indicado por parámetros.

Devuelve el propio objeto SSAPBulkMessage para facilitar el encadenamiento de mensajes de la siguiente forma:

msgBulk.addMessage(msgInsert1).addMessage(msgInsert2).addMessage(msgInsert3);

· addMessage(ssapMessages: List<SSAPMessage>):void: Añade al atributo “body” del mensaje SSAPBulkMessage una lista de mensajes INSERT, UPDATE o DELETE indicada por parámetros.

En caso de que alguno de los mensajes añadidos no sea de tipo INSERT, UPDATE o DELETE, el método lanzará una excepción de tipo NotSupportedMessageTypeExepcion.

En caso de que el mensaje añadido no sea de tipo INSERT, UPDATE o DELETE, ambos métodos lanzarán una excepción de tipo NotSupportedMessageTypeExepcion.

Asimismo, se ha añadido a la clase SSAPMessageGenerator el método generateBulkMessage(sessionKey:String, ontology:String) para generar un mensaje SSAPBulkMessage indicando la sessionKey y la ontologia.

La respuesta será un objeto SSAPMessage cuyo atributo body puede ser procesado como objetos Java utilizando las siguientes clases y sus métodos fromJson y toJson

· SSAPBodyBulkReturnMessage: Cuerpo de la respuesta de un mensaje de tipo BULK. Contiene 3 atributos de tipo SSAPBulkOperationSummary indicando el resumen de la ejecución en el SIB de las operaciones INSERT, UPDATE o DELETE contenidas en el mensaje de BULK.

· SSAPBulkOperationSummary: Resumen de un conjunto de operaciones INSERT, UPDATE o DELETE tras ser procesadas en el SIB. Contiene la lista de ObjectsIds afectados en BDTR para cada operación. Asi como en caso de producirse una lista objetos de tipo SSAPBulkOperationErrorSummary conteniendo la informacióncada error provocado por cada mensaje durante su operación.

· SSAPBulkOperationErrorSummary: Contiene para cada mensaje ejecutado con errorores en el SIB el atributo body de la petición y de la respuesta.

En el siguiente fragmento de código podemos ver un ejemplo de utilización:


//Genera un mensaje de INSERT

SSAPMessage msgInsert1=SSAPMessageGenerator.getInstance().generateInsertMessage(sessionKey, ONTOLOGY_NAME, ONTOLOGY_INSTANCE);

//Genera un mensaje de INSERT

SSAPMessage msgInsert2=SSAPMessageGenerator.getInstance().generateInsertMessage(sessionKey, ONTOLOGY_NAME, ONTOLOGY_INSTANCE);

//Genera un mensaje INSERT de SQLLIKE

SSAPMessage msgInsert3=SSAPMessageGenerator.getInstance().generateInsertMessage(sessionKey, ONTOLOGY_NAME, ONTOLOGY_INSERT_SQLLIKE, SSAPQueryType.SQLLIKE);

//Genera un mensaje de UPDATE

SSAPMessage msgUpate1=SSAPMessageGenerator.getInstance().generateUpdateMessage(sessionKey, ONTOLOGY_NAME, ONTOLOGY_UPDATE, ONTOLOGY_UPDATE_WHERE);

//Genera un mensaje UPDATE de SQLLIKE

SSAPMessage msgUpate2=SSAPMessageGenerator.getInstance().generateUpdateMessage(sessionKey, ONTOLOGY_NAME, null, ONTOLOGY_UPDATE_SQLLIKE, SSAPQueryType.SQLLIKE);

SSAPBulkMessage msgBulk=SSAPMessageGenerator.getInstance().generateBulkMessage(sessionKey, "";);

try{

msgBulk.addMessage(msgInsert1).addMessage(msgInsert2).addMessage(msgInsert3).addMessage(msgUpate1).addMessage(msgUpate2);

} catch(NotSupportedMessageTypeException e){

e.printStackTrace();

}

log.info("Envia mensaje BULK al SIB: "+msgBulk.toJson());

SSAPMessage respuesta=kp.send(msgBulk);

log.info("Recibe respuesta BULK desde el SIB: "+respuesta.toJson());

SSAPBodyReturnMessage bodyBulkReturn=SSAPBodyReturnMessage.fromJsonToSSAPBodyReturnMessage(respuesta.getBody());

SSAPBodyBulkReturnMessage summary=SSAPBodyBulkReturnMessage.fromJsonToSSAPBodyBulkReturnMessage(bodyBulkReturn.getData());

assertEquals(3, summary.getInsertSummary().getObjectIds().size());

log.info("ObjectIds insertados");

for(String oid:summary.getInsertSummary().getObjectIds()){

log.info(oid);

}

Mensaje SSAP BULK

Roadmap Sofia2 Q4 2014

En Sofia2 seguimos trabajando con el enfoque de una release mensual, esto nos ayuda a mantener un enfoque de desarrollo ágil e iterativo además de a mantener el compromiso y motivación de todo el equipo.

El plan de releases para este último cuatrimestre de 2014 es este:

· Release 2.12 para el 26 de septiembre

· Release 2.13 para el 24 de octubre

· Release 2.14 para el 21 de noviembre

· Release 2.15 para el 19 de diciembre

En este periodo el equipo de Sofia2 ha puesto el foco en un conjunto de áreas que se concentran en estas:

· Difusión de la Plataforma, en este ámbito estamos trabajando en diversas iniciativas con Universidades tanto españolas como europeas y latinoamericanas, además de en la realización de diversas demostraciones de las capacidades de la plataforma (en el ámbito de Smart Cities, Smart Home, Redes Sociales,…)

· APIS para otras plataformas : incorporaremos APIS para lenguajes como Python y para plataforma iOS

· Integración con otros productos Indra: dentro de Indra existen diversos soluciones tanto transversales como de negocio, se está trabajando para integrar algunas de estas de modo que complementen las capacidades de la plataforma Sofia2.

· Soporte integrado Dashboards la versión actual ya integra capacidades de gadgets de visualización y dashboards, se está trabajando en incluir nuevas funcionalidades y un diseño gráfico más avanzado.

· Soporte integrado para la adquisición de datos desde redes sociales: la plataforma permitirá configurar que información quiero recoger de redes sociales como Twitter y Facebook de modo que esta quedarán disponibilizada en la plataforma permitiendo suscribirse a esta, procesarla,…

Roadmap Sofia2 Q4 2014