Sofia2 participa en el Laboratorio Virtual SESIAD

labVirtual

 

El Laboratorio Virtual de la Secretaría de Estado para la Sociedad de la Información y Agenda Digital (SESIAD) nace bajo la norma UNE 178104 “Sistemas integrales de gestión de la ciudad inteligente” con el objetivo de convertirse en una referencia de plataformas a nivel nacional e internacional, siendo un lugar de experimentación en el que empresas y desarrolladores puedan evaluar la compatibilidad de sus productos con diferentes plataformas Smart Cities.

 

labVirtual

 

Actualmente, plataformas que participan en el Laboratorio Virtual son Sofia2, de Minsait by Indra, SmartBrain de Cellnex y Thinking City de Telefónica. Éstas colaboran con SESIAD aportando su expertise y participando en la mejora de la interoperabilidad entre plataformas.

 

plataformas

 

Como vimos en IoT Data Models: Iniciativas y Sofia2 Data Modelexisten diferentes Iniciativas de estandarización de un Data Model en IoT. Un Data Model representa la estructura de tus datos y relaciones, y por tanto, organiza los elementos y estandariza como se relacionan unos con otros.

 

gsma1

 

Los Data Models GSMA y FIWARE se definen en JSON por lo que su representación como Ontología Sofia2 es inmediata. Vimos cómo se soportan y de qué manera tan sencilla se puede trabajar con estas entidades en Sofia2

 

Para conseguir una mejor interoperabilidad entre plataformas, se seleccionó NGSI 9/10 v2 como protocolo común para la Capa de Interoperabilidad. Vimos en este documento cómo se soportan y cómo consumir APIS modeladas conforme semántica FIWARE Data Model y publicadas en Sofia2 siguiendo el protocolo NGSI 9/10 v2.

 

En nuestra experiencia con el Laboratorio Virtual, además de realizar recomendaciones de nuevos atributos y modificaciones en los Data Model, hemos tenido la posibilidad de realizar una Prueba de Concepto (PoC) creando un Flujo de conexión y transformación de datos reales provenientes de Smart City A Coruña a GSMA/FIWARE Data Model en la Plataforma Sofia2.

 

En este ejemplo, se recogen datos de parkings de Smart Coruña y se ingestan en la plataforma Sofia2 a una Ontología. Cada vez que se recibe una instancia de esta ontología se lanza un Script que transforma estos datos adaptándolos a los Data Model y, consultándolos, vemos como efectivamente, se cumple con los Data Model.

 

flujodeconexion

 

También, en esta Prueba de Concepto, pudimos publicar estos datos por medio del API MANAGER de Sofia2, para posteriormente, ver que cualquiera con los debidos permisos, puede acceder a estos datos vía API, Curl o mediante el portal del Laboratorio Virtual.

 

consumodatos

 

Todo este proceso queda explicado en el post Adquisición, transformación y consumo de datos GSMA/FIWARE Data Model, y ha sido plasmado en el demostradorque, además de los datos de parkings, recoge datos de playas y museos.

 

demostrador

 

Puedes encontrar toda la información relativa al Laboratorio Virtual SESIAD aquí, así como todas las herramientas (Data Model, APIs, Tokens de seguridad, ejemplos…) necesarias para desarrollar en las plataformas cumpliendo con este modelo de interoperabilidad aquí

Sofia2 participa en el Laboratorio Virtual SESIAD

Integración de Lora con Sofia2

Para llevar a cabo la comunicación entre un dispositivo Lora y Sofia2 hemos utilizado un kit de Multitech formado por un nodo de pruebas que simula las transmisiones de un dispositivo con tecnología Lora y un gateway, necesario para que estos dispositivos puedan comunicarse con la red y enviar así los datos que tomen.

Kit
Kit Multiconnect utilizado.

Es necesario configurar tanto el gateway como el nodo de pruebas antes de integrar estos dispositivos en Sofia2. En esta breve guía se recogen los pasos a seguir para ambas configuraciones y todo lo necesario en Sofia2 para poder recibir y almacenar los datos enviados por Lora.

Configuración de la tecnología Lora

  • Configuración del gateway

    Es necesario hacer una configuración inicial para poder usar el gateway sin problemas de conexión. La primera vez que accedemos a él lo haremos por comunicación serie usando Putty u otra herramienta similar. Las credenciales necesarias para acceder por terminal son admin/admin, y con el comando ifconfig podemos obtener su dirección IP. Una vez conocida esta IP, accedemos a ella mediante un navegador y nos encontramos con una página de Multitech donde podemos acceder usando de nuevo las mismas credenciales que antes.

    Acceso web al gateway
    Acceso web al gateway

    Nada más iniciar sesión, y solo la primera vez que lo hacemos, nos encontramos con un asistente que nos va solicitando en varios pasos modificar la contraseña, seleccionar la zona horaria y configurar la IP. Cuando nos sale esta última ventana debemos configurarla como IP estática, seleccionar el gateway correspondiente y añadir los servidores DNS.

    Una vez terminada la configuración de la IP, configuramos la parte de Lora. Para ello basta con acceder a Setup -> Lora. Aparece una pantalla como la que se muestra en la siguiente imagen donde hay muchos campos configurables de los cuales solo necesitamos modificar Name y Passphrases.

    Web
    Pantalla de configuración de Lora.
  • Configuración de Node-Red

    Una vez activada la aplicación de Node-Red podemos acceder a ella desde el menú “App” de la web. Por defecto viene diseñado un programa que simplemente recibe los datos del tester de Lora y los muestra por pantalla, pero debemos modificarlo para que la información se envíe a Sofia2.  En la imagen se muestra el diagrama de flujos final, en el que ha añadido la función “Sofia2 API WEB encoder”, encargada de dar el formato deseado y añadir una cabecera al mensaje a enviar y una salida HTTP (envío).

    Node-Red
    Configuración de Node-Red
  • Configuración del nodo de pruebas

    Configurar los parámetros del nodo de pruebas es realmente sencillo. Solamente hay que conectar el mDot vía USB a nuestro ordenador y conectarlo al nodo de pruebas con el cable de programación que viene en el mismo kit, de la forma que se muestra en la figura. Una vez hecho esto seleccionamos la opción “Configuration” en el mDot Box y accedemos al dispositivo utilizando la comunicación serie de Putty a velocidad 115200 baudios.

    Tester
    Tester de Lora utilizado

    Solamente es necesario configurar dos parámetros y para ello se utilizan los siguientes comandos AT:

    AT+NI=1,<Name>

    AT+NK=1,<Passphrase>

    AT&W para guardar los cambios realizados Y finalmente AT+Exit para salir del modo configuración.

    Los campos <Name> y <Passphrase> tienen que ser los mismos valores que los fijados anteriormente en el Gateway.

    Configuración del tester
    Configuración del tester

    Para comprobar si la configuración de ambos dispositivo ha sido correcta, podemos hacer una prueba con Node-Red.

Sofia2

Una vez configurada toda la parte de los dispositivos, solamente queda desarrollar la parte necesaria en Sofia2. Necesitamos dos nuevas ontologías, un API rest y un Script de reglas para tratar los datos. En este apartado se explica brevemente cómo crear cada uno de ellos.

  • Definir las nuevas ontologías

    Lo primero que debemos hacer es crear una nueva ontología que recibirá los datos que envía el nodo de pruebas. En esta ontología se insertarán los datos “en crudo” (data RAW) tal y como los envía el dispositivo, sin aplicar ningún filtrado previo.

    ontologia
    Ejemplo de ontología con datos sin tratar.

    Estos datos suelen contener tramas con codificaciones en hexadecimal, formatos no deseados o información que debe ser tratada antes de trabajar con ella. Por ello es necesario crear un Script de reglas y una nueva ontología donde se insertarán los datos ya tratados y con el formato requerido por la base de datos para su correcto almacenamiento.

  • Api Rest

    Una vez definidas las ontologías, crearemos una API REST de tipo POST a la ontología de datos sin tratar para que los datos puedan ser insertados en ella.

    Para ello debemos entrar en API MANAGER -> APIs donde encontramos la opción “Crear API”. Una vez aquí, escribimos un nombre para nuestra API, seleccionamos la opción “Publicar ontología como API REST” y la ontología deseada. Es conveniente desactivar el número máximo de peticiones por minuto para asegurarnos de que no perdemos información. Por último, seleccionamos la operación “POST” y creamos nuestra API.

     API
    Pantalla de creación de API

     La URL que aparece en el campo “EndPoint base” es la que se debe insertar en Node-RED.

  • Script de reglas

    Una vez comprobado que los datos enviados directamente desde el dispositivo se insertan de forma correcta en la ontología deseada, debemos crear un Script para tratarlos, extraer toda la información posible y dotarlos del formato correspondiente. Para ello simplemente entramos en Reglas->Wizard creación de reglas y seleccionamos la opción “Generar regla script ontología”. Con este tipo de reglas, cada vez que el dispositivo envíe nuevos datos a la ontología se ejecutará este script en el que se tratarán los datos para luego insertarlos en la ontología final.

  • Representación de resultados

    Utilizando las herramientas de visualización de Sofia2 podemos representar de manera rápida y sencilla los datos que estamos almacenando.  Para ello entramos en visualización ->Mis Gadgets-> Crear gadgets, desde donde podemos seleccionar el tipo de herramienta que más nos conviene en función de los datos. Atendiendo a los datos que se obtienen del tester de Lora, dos tipos de visualizaciones interesantes podrían ser la representación de coordenadas en un mapa y los valores de la relación señal a ruido (SNR) a lo largo del tiempo.

    Mapa
    Representación de coordenadas en un mapa

    SNR
    Representación del parámetro SNR
Integración de Lora con Sofia2

Generación Código Cliente en TEst&Doc APIS

54

Esta nueva utilidad consiste en un editor de código cliente para las APIs de las Ontologías en los principales lenguajes de programación, de esta forma solo tendremos que copiar el código que genera e insertarlo en nuestras aplicaciones.

 

Para ello debemos acceder a la API de la Ontología que queremos invocar. En este ejemplo será “AparcamientoPublicosMadrides”. Así que accederemos al menú de “API MANAGER”, y al submenú “APIs”:Image 003

Una vez aquí, vamos a la pestaña de “Mis Suscripciones”:Image 006

Y elegimos la API que queremos probar. Y clickamos sobre el botón “Test & Doc”:Image 009

Aquí tenemos información de la API y de las funciones que expone para su consumo. Nosotros vamos a elegir la función “getAll”:Image 012

A continuación se nos muestra la información referente a dicha función, y en la parte derecha aparecerá un menú desplegable llamado “Invocación al API”, en el elegiremos el lenguaje que queremos usar para invocar a la función:Image 015

Y esto generará el trozo de código necesario para invocar a la función. Solo tendremos que completar dicho código usando el token del usuario con el que estamos logados en la parte del “x-sofia2-apikey”:Image 018

He creado una pagina de ejemplo en HTML usando JQuery, para insertar el código que nos genera para el método del API,  el codigo HTML utilizado para el ejemplo seria:

<code>

<!DOCTYPE html>
<html>

<head>
<meta charset=”UTF-8″>
<title>Test API</title>
http://code.jquery.com/jquery-2.2.3.min.js

$(document).ready(function() {
$(“#myButton”).click(function() {

var settings = {
“async”: true,
“crossDomain”: true,
“url”: “https://sofia2.com/sib-api/api/v1/aparcamientospublicosmadrides/getAll&#8221;,
“method”: “GET”,
“headers”: {
“x-sofia2-apikey”: “********************”
}
}

$.ajax(settings).done(function (response) {
console.log(response);
var num = response.data.length;
$(“#apiTestDiv”).html(“Request URL: https://sofia2.com/sib-api/api/v1/aparcamientospublicosmadrides/getAll
Num Result: ” + num);

});

});
});

</head>

<body>
<button id=”myButton”>Test API</button>
</br>
</br>

</body>

</html>

</code>

 

resultado sería asi:

Image 028

Generación Código Cliente en TEst&Doc APIS

Despliegue y monitorización de Aplicaciones Spring Boot desde Control Panel de Sofia2

Introducción

Se ha integrado en el componente Contenedor de ThinKPs la posibilidad de desplegar aplicaciones basadas en Spring Boot. Para simplificar la integración de estas aplicaciones con Sofia2 se ha avanzado con la funcionalidad del módulo Sofia4Boot descrito aqui.

Las aplicaciones desplegadas dentro del contenedor de Sofia2 pueden ofrecer cualquier tipo de funcionalidad, incluso si no requiere de Sofia2 más que el contenedor y el sistema de gestión (en entornos desplegados tras un Nginx puede requerir cierta configuración, como abrir puertos).

Autorización

Las aplicaciones Spring Boot que usen en contenedor de ThinKPs necesitan proporcionar ciertos credenciales a la plataforma Sofia2. Para esto es necesario disponer de un ThinKP asociado a una ontología, y proporcionar como propiedad el token de acceso (ver sección de propiedades más adelante).

Creando una aplicación nueva

Para crear una aplicación basada en Spring Boot para Sofia2 se debe empezar con incluir en el POM las dependencias necesarias. Sofia2 dispone de un repositorio Nexus con las dependencias requeridas.

Atención! Sofia4Boot requiere de una versión de Java igual o superior a 1.8

Repositorio Nexus de Sofia2

<repositories>
     <repository>
    <id>SOFIA2</id>
    <url>http://sofia2.org/nexus/content/groups/public/</url>
    </repository>
</repositories>

Dependencias de Sofia4Boot

<dependency>
    <groupId>com.indra.sofia2.boot</groupId>
    <artifactId>sofia4boot</artifactId>
    <version>1.3</version>
</dependency>

Además hay que incluir las dependencias propias de Spring Boot (en esto no hay diferencias respecto a una aplicación SpringBoot típica). Es particularmente importante asegurarse que la aplicación que generamos es autocontenida (y ejecutable). Para esto lo más normal es usar el plugin de Spring Boot:

<build>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
        </plugin>
    </plugins>
</build>

Durante el diseño de la aplicación hay que tener en cuenta que a la hora de arrancarla, el contenedor añadirá elementos adicionales a la configuración, como por ejemplo, limitación de memoria y propiedades de configuración. Un ejemplo de comando de arranque puede ser: -Xmx256m -Dspring.boot.admin.url=http://127.0.0.1:8101 -Dspring.boot.admin.prefer-ip=true. Esto incluye por ejemplo la configuración interna necesaria para registrar la aplicación en la instancia spring boot admin de Sofia2.

Clase principal

Para la clase principal usaremos una plantilla habitual para Spring Boot, a la que añadiremos el soporte para que se integre con el sistema de administración (esto se consigue añadiendo la anotación @EnableSpringBootAdminRegister).

@SpringBootApplication
@EnableSpringBootAdminRegister
public class S4BApp 
{
    public static void main (String [] args) {
        new SpringApplicationBuilder(S4BApp.class).run(args);
    }
}

La anotación @EnableSpringBootAdminRegister se encargará de registrar la aplicación en la consola, con lo que se podrá gestionar en una ventana de la consola de Sofia2:

Modelado de una ontología

La forma más fácil de modelar una ontología es descargarse las clases generadas desde el Control Panel de Sofia2. Para esto hay que ir a la opción de menú ‘Mis Ontologías’, buscar la ontología que se quiera, pulsar sobre el botón ‘Ver Ontología’ (con un icono representando un ojo), y al final de la ventana deberemos ver un botón con el texto ‘Clase Java de la Ontología’. Esto nos descargará un fichero comprimido con las clases de la ontología.

Esto también puede hacerse a mano. Un ejemplo de modelado de una ontología sencilla sería la siguiente:

Modelo de la ontología de ejemplo

{
    "$schema": "http://json-schema.org/draft-04/schema#",
    "title": "level Schema",
    "type": "object",
    "required": [
        "Level"
    ],
    "properties": {
        "Level": {
            "type": "string",
            "$ref": "#/datos"
        }
    },
    "datos": {
        "description": "descripcion",
        "type": "object",
        "required": [
            "date"
        ],
        "properties": {
            "value": {
                "type": "integer"
            },
            "date": {
                "type": "string"
            }
        }
    }
}

Y un ejemplo de instancia:

{
    "Level": {
        "value": 1,
        "date": "string"
    }
}

Las clases Java de modelado serían:

Modelo de datos

public class Level {

    private String date;
    private Integer value;

    public Level() {

    }

    public Level(String date, Integer value) {
        this.date = date;
        this.value = value;
    }

    public String getDate() {
        return date;
    }

    public void setDate(String date) {
        this.date = date;
    }

    public Integer getValue() {
        return value;
    }

    public void setValue(Integer value) {
        this.value = value;
    }
}

Y como la ontología tiene un nivel adicional para controlar siempre los valores, tendremos que incluir un wrapper

Envoltorio de ontología

public class LevelOntology extends Ontology<Level> {

    @JsonProperty("Level")
    private Level level;

    public LevelOntology () {}

    public LevelOntology (String date, Integer value) {
        level = new Level(date, value);
    }

    @Override
    public void setData(Level level) {
        this.level = level;
    }

    @Override
    public Level getData() {
        return level;
    }
}

Acceso al repositorio de la ontología

Para operar con la ontología disponemos de un conjunto de anotaciones que nos autogeneran el código de operación necesario. Un ejemplo de repositorio para la sencilla ontología del ejemplo anterior:

@Sofia2Repository("level")
public interface LevelRepository {

    @Sofia2Query("select * from level")
    List<LevelOntology> findAll ();

    @Sofia2Query("select * from level where Level.value=0")
    List<LevelOntology> findAllZeros ();

    @Sofia2Query("select * from level where Level.value=$value")
    List<LevelOntology> findAllWhereValueMatches (@Param("$value") Integer value);

    @Sofia2Insert
    SofiaId save(LevelOntology levelOntology);

    @Sofia2Query("db.level.remove({\"Level.value\":$value})")
    SofiaIds deleteWhereValueMatches(@Param(value = "$value") Integer value);

    @Sofia2Delete
    List<SofiaId> delete(String id);
}

Este repositorio no tiene código, es sólo un interfaz, siendo la librería de Sofia4Boot la encargada de generar y registrar en el contexto de spring la clase de implementación necesaria, con lo cual ya podremos disponer de ella de la forma habitual en spring:

@Autowired private LevelRepository levelRepository;

Añadiendo funcionalidad

Para este ejemplo, simplemente voy a hacer que cada n minutos se genere un nuevo valor aleatorio para la ontología. Para esto implementamos un servicio proveedor de valores que se encargue de hacer inserciones en la ontología:

@Service
public class Provider {

    private static final Logger log = LoggerFactory.getLogger(Provider.class);
    private Random random = new Random();

    @Autowired
    private LevelRepository levelRepository;

    public void sendRandomMessage () {

        try {
            // --- create new level value
            Instant now = Instant.now();
            Integer value = random.nextInt(10);
            LevelOntology levelOntology = new LevelOntology(now.toString(), value);
            log.info("Inserting data ontology: {}, ", levelOntology);
            // --- insert a random value
            SofiaId id = levelRepository.save(new LevelOntology(now.toString(), value));
            log.info("Created new record with value '{}' and id '{}'", value, id.getId().getOid());
        } catch (Exception e) {
            log.warn("Captured exception running app", e);
        }
    }
}

Y para que se ejecute cada intervalo genero un job con un planificador (un scheduler) que arranque cuando la aplicación haya terminado de cargarlo todo:

@Configuration
public class JobConfig implements ApplicationListener<ContextRefreshedEvent> {

    private final Logger log = LoggerFactory.getLogger(JobConfig.class);
    private final ScheduledExecutorService scheduler = Executors.newScheduledThreadPool(1);

    @Autowired
    private Config config;
    @Autowired
    private Provider provider;

    @Override
    public void onApplicationEvent(ContextRefreshedEvent contextRefreshedEvent) {

        log.info("Scheduling tasks ({} minutes)", config.getIntervalInMinutes());
        Runnable task = new Runnable() {
            @Override
            public void run() {
                provider.sendRandomMessage();
            }
        };

        Integer interval = config.getIntervalInMinutes();
        scheduler.scheduleAtFixedRate(task, interval, interval, TimeUnit.MINUTES);
    }
}

Para cargar la configuración estamos usando una clase Java mapeada por Spring con un fichero de configuración:

@Configuration
@ConfigurationProperties(prefix = "s4b")
public class Config {

    // el valor por defecto es 1, y la property se mapea contra 's4b.intervalInMinutes'
    private Integer intervalInMinutes = 1;

    public Integer getIntervalInMinutes() {
        return intervalInMinutes;
    }

    public void setIntervalInMinutes(Integer intervalInMinutes) {
        this.intervalInMinutes = intervalInMinutes;
    }
}

Configuración de la aplicación

A parte de la configuración habitual de Spring, existen propiedades adicionales referentes a Sofia4Boot, y además están las propias de nuestra aplicación.

La configuración específica de Sofia4Boot que nos aplica está referida a continuación:

Propiedad Valor de ejemplo Descripción
sofia2.host sofia2.com El host del servicio MQTT
sofia2.port 1884 El puerto para MQTT
sofia2.kp levelkp El kp al que se asocia la aplicación
sofia2.instance levelkp-demo El nombre de esta instancia de thinkp
sofia2.token 5118bt0acc2e464782dfwb52af582h9z El token de autorización del thinkp
sofia2.mqtt false Decide si se utiliza rest (false) o mqtt (true)
sofia2.endpoint http://sofia2.com/sib/services/ssap La URL del endpoint SSAP de Sofia2

Las propiedades propias de este ejemplo, junto con las de Spring Boot:

Propiedad Valor de ejemplo Descripción
logging.file ${spring.application.name}.log El nombre del archivo de logs a generar
server.port 0 Si fuera necesario, el puerto en el que se quiere arrancar el servicio. Esto requiere actualizar la configuración de Nginx
management.security.enabled false Esta property se asegura que se utiliza el sistema de autenticación de sofía, y no el que tiene spring boot admin por defecto
s4b.intervalInMinutes 5 inserta un valor nuevo a la ontología cada 5 minutos

Desplegando en el Contenedor de ThinKPs

Para desplegar nuestra aplicación dentro del contenedor de ThinKPs de Sofia2 deberemos haber completado los siguientes pasos:

  1. Generar una ontología en la plataforma, o seleccionar una que ya esté disponible (puede estar vacía si no se necesitan datos).
  2. Crear un KP, y generar un token, que se usarán para autorizar a nuestra aplicación (como cualquier otro dispositivo).
  3. Implementar nuestra aplicación y disponer del archivo ‘jar’ para desplegarlo.

Hecho esto, accedemos a la consola de Sofia2, menú ‘Contenedor ThinKPs’, y una vez allí haremos click en el botón con el texto ‘Nuevo ThinKP en contenedor’. Rellenamos la ventana que nos muestra la consola asegurandonos de:

  • Marcar el tipo de aplicacion como ‘Aplicación Spring Boot’
  • Seleccionar un token de autenticación (que coincida con el que incluimos en la configuración de nuestra aplicación!).
  • Cargamos nuestro archivo jar
  • Seleccionamos un nombre para nuestro contenedor, asegurandonos de incluir la extensión ‘.jar’

Un ejemplo:

Cuando termine (según nuestra conexión y el tamaño del JAR puede tardar un poco), deberíamos ver una ventana con la descripción parecida a la siguiente:

Aquí tenemos el botón que nos permite arrancar nuestra aplicación (por defecto están paradas nada más crearlas).

Spring Boot Admin

Una vez nuestra aplicación está arrancada y si está configurada correctamente, pasado un rato deberíamos poder verla registrada en el servicio de administración de Spring Boot Admin, en el menú ‘ThinKPs -> Administración de Spring Boot’, como puede verse a continuación:

Pulsando sobre el botón ‘Details’ podemos ver más detalles acerca de nuestra aplicación, como por ejemplo:

Despliegue y monitorización de Aplicaciones Spring Boot desde Control Panel de Sofia2

Premio enerTIC para el proyecto de eficiencia energética de SENA basado en Sofia2

SmartEnergySena

 

El proyecto de eficiencia energética desarrollado por el Servicio Nacional de Aprendizaje (SENA) de Colombia, en colaboración con Indra, ha ganado el premio de enerTIC 2017 en la categoría de Smart International Projects.

 

Sofia2InfografiaRecortada

 

La plataforma Smart Energy está basada en Minsait IoT Sofia2 (http://sofia2.com), la solución IoT con capacidades Big Data de Minsait, la unidad de transformación digital de Indra. Actúa como un gran “cerebro” integrador capaz de monitorizar los distintos dispositivos de medición de energía, agua y gas desplegados por las diversas sedes del SENA, almacenar información, visualizar gráficos y establecer previsiones de consumo mediante la combinación de los datos históricos de la base de datos y los recogidos en tiempo real.

 

Según el primer estudio sobre 28 sedes del SENA, los ahorros podrían llegar a suponer una reducción de alrededor del 25% en el caso de la factura energética, con un retorno de inversión de 1,7 años, en el supuesto de implementar medidas de poca inversión.

 

Estamos muy orgullosos de formar parte de este proyecto como base tecnológica de la plataforma Smart Energy. Puedes leer la noticia completa aquí

Premio enerTIC para el proyecto de eficiencia energética de SENA basado en Sofia2

Funcionalidad soporte multi-BDTR

image0141

En la Release 4.2 de Sofia2 IoT Platform se introdujo el concepto de multi-BDTR. Hasta ahora una instalación de Sofia2 sólo podía funcionar con una BDTR y con una BDH, es decir, si se usaba MongoDB como base de datos BDTR entonces todas las ontologías se almacenaban en esta base de datos.

En esta versión hemos añadido la capacidad de que en una misma instalación de Sofia2 se puedan gestionar diferentes BDTRs, de esta forma cuando creamos una ontología podemos seleccionar la base de datos sobre la que queremos que trabaje. Esta opción la podemos encontrar en Opciones Avanzadas > Seleccionar instancia BDTR en todas las pantallas de creación de ontología:

image0132

Esta funcionalidad nos permite tener tanto bases de datos relacionales como no relacionales en nuestra instancia de Sofia2. Para trabajar con bases de datos relacionales ,como puede ser un PostgreSQL se ha añadido una nueva funcionalidad que nos permite crear ontologías sobre este tipo de base de datos, a la cual podemos acceder desde el menú Ontologías > Crear Ontología > Crear Ontología en Base de Datos Relacional

image006

Lo que nos llevará al formulario para crear la ontología paso a paso, donde nuevamente en Opciones Avanzadas encontraremos el listado de BDTRs relacionales disponibles en la instancia de Sofia2:

post

La configuración de todas las BDTRs las realiza el administrados del sistema de la instancia de Sofia2, para ello se ha creado un nuevo rol SYS_ADMIN. Si accedemos a la instancia de Sofia2 con este rol podremos ver en un primer momento un listado de las BDTRs disponibles para la instancia:

post2

Si accedemos a Crear Instancia tenemos un formulario con todos los campos necesarios para configurar nuestras BDTRs:

post3

Cabe destacar que solo podemos tener una BDTR por defecto y que será en la cual se creen todas las ontologías si no seleccionamos ninguna BDTR en concreto en el apartado de Opciones Avanzadas de creación de ontologías.

Funcionalidad soporte multi-BDTR

10 Tendencias Tecnológicas para 2018 según Gartner: Digital (III)

Tras revisar la tendencia dedicada a Intelligenthoy trataremos la tendencia Digital, que se compone de Digital Twins, Cloud a Edge, Plataforma conversacional y experiencia inmersiva:

Tendencia 4: Digital Twins:

Un Digital Twin es una representación digital de una entidad o sistema del mundo real. En el contexto de IoT, los “gemelos digitales” están vinculados a objetos del mundo real y ofrecen información sobre el estado de las partes que componen la Thing, responden a los cambios,… Con un estimado de 21 billones de sensores y endpoints conectados para 2020, existirán Digital Twins para para miles de millones de cosas en el futuro cercano. Potencialmente esto permitirá ahorrar miles de millones de dólares en reparaciones y mantenimiento (MRO) además de optimizar el rendimiento de los assets IoT.

A corto plazo, los gemelos digitales ofrecen ayuda con la gestión de activos, pero también ofrecerán valor en la eficiencia operativa y mejoras sobre cómo se usan los productos y cómo se pueden mejorar.

Fuera del IoT, existe un potencial creciente para vincularlos a entidades que no son simplemente "cosas". "Con el tiempo, las representaciones digitales de prácticamente todos los aspectos de nuestro mundo estarán conectadas dinámicamente con sus contrapartes del mundo real y usando capacidades basadas en inteligencia artificial permitirán simulación avanzada, operación y análisis ", dice Cearley. "Los planificadores urbanos, especialistas en marketing digital, profesionales de la salud y planificadores industriales se beneficiarán de este cambio a largo plazo hacia el mundo gemelo digital integrado". Por ejemplo, los modelos futuros de humanos podrían ofrecer datos biométricos y médicos, y los gemelos digitales para ciudades enteras permitir simulaciones avanzadas.

Tendencia n° 5: Del Cloud al Edge:

Edge computing describe una topología informática en la que el procesamiento y recopilación de la información se ubica más cerca de las fuentes de esta información. Los desafíos de conectividad y latencia, las restricciones de ancho de banda y una mayor funcionalidad en el Edge favorecen los modelos distribuidos. Las empresas deberían comenzar a utilizar patrones de diseño Edge en sus arquitecturas, especialmente en el ámbito IoT.

Aunque es común suponer que la computación cloud y Edge son competencia, en realidad es un malentendido de los conceptos. Cuando se implementan en conjunto, Cloud se usa para crear el modelo orientado a servicios y Edge ofrece un estilo de entrega que permite la ejecución de aspectos desconectados del servicio en la nube.

Tendencia n° 6: Plataformas Conversacionales

Las plataformas conversacionales impulsarán un cambio de paradigma en el cual la carga de traducir la intención cambia del usuario a la computadora. Estos sistemas son capaces de ofrecer respuestas simples (¿Cómo está el clima?) o interacciones más complicadas (reserve una reserva en el restaurante italiano en Parker Ave.)

Estas plataformas continuarán evolucionando hacia acciones aún más complejas, como la recolección de testimonios orales de testigos de crímenes y actuando sobre esa información creando un boceto de la cara del sospechoso basado en el testimonio. E

l desafío que enfrentan las plataformas de conversación es que los usuarios deben comunicarse de una manera muy estructurada, y esto a menudo es una experiencia frustrante. Un diferenciador principal entre las plataformas de conversación será la solidez de sus modelos de conversación y los modelos de API y eventos utilizados para acceder, invocar y organizar servicios de terceros para ofrecer resultados complejos.

Tendencia nº 7: Experiencia inmersiva

La realidad aumentada (AR), la realidad virtual (RV) y la realidad mixta están cambiando la forma en que las personas perciben e interactúan con el mundo digital. Combinado con plataformas conversacionales, surgirá un cambio fundamental en la experiencia del usuario hacia una experiencia invisible e inmersiva. Los proveedores de aplicaciones, los proveedores de software de sistemas y los proveedores de plataformas de desarrollo competirán por ofrecer este modelo.

Durante los próximos cinco años, la atención se centrará en la realidad mixta, que está emergiendo como la experiencia de inmersión donde el usuario interactúa con objetos digitales y del mundo real mientras mantiene una presencia en el mundo físico. La realidad mixta existe a lo largo de un espectro e incluye pantallas montadas en la cabeza (HMD) para AR o VR, así como AR basado en teléfonos inteligentes y tabletas.

Dada la ubicuidad de los dispositivos móviles, la liberación de Apple de ARkit e iPhone X, Tango de Google y Arcore, y la disponibilidad de kits de desarrollo de software de AR multiplataforma como Wikitude, esperamos que las batallas por AR basados ​​en teléfonos inteligentes y MR se calienten en 2018.

10 Tendencias Tecnológicas para 2018 según Gartner: Digital (III)