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

Comparison of free versions on IoT platforms

3

 

In this post we compared capabilities of several IoT platforms (Sofia2, Azure IoT, Watson IoT and AWS IoT). Today we want to compare what each of these platforms offer without cost.

 

On one hand, the IoT Watson platform from IBM includes a maximum of 500 registered devices, a maximum of 500 application links and up to 200 MB of data:

 

ioTWatson

 

 

For its part, Microsoft Azure, allows up to 500 devices and 8000 messages per day:

 

IoTMicrosoftAzure

 

As well as a message size of 0.5 KB:

 

MicrosoftAzureTamanoMensaje

 

AWS IoT, allows up to 250,000 messages published or delivered per month:

 

AWSIoT

 

And Sofia2, in its CloudLab environment, allows you to use the IoT version of the platform without any limitation, either at the level of connected devices, nor the number or size of messages that circulate through the platform:

 

 

In table format we would be talking about:

 

   Number of Max Devices Allowed Data

Azure IoT Hub

500

8000 Messages/day

AWS IoT

 –

8300 Messages/day

Watson IoT Platform

500

200 MB/month

Sofia2 IoT Platform Unlimited

Unlimited

Comparison of free versions on IoT platforms

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

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

2.PNG

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

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

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

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

Sofia4boot: Soporte para trabajar con Sofia2 en aplicaciones Spring Boot

 

Sofia2 se aplica usualmente a escenarios IoT y BigData, pero también puede usarse como Plataforma/Arquitectura de desarrollo para el desarrollo a medida de proyectos.

 

En este sentido Sofia2 aporta:

 

  • Facilidad de uso: Sofia2 es compatible con las metodologías de desarrollo actuales, permite a los desarrolladores realizar iteraciones de forma rápida y continua sobre el modelo de datos y todo desde un interfaz Web. En contraposición un desarrollo tradicional modelo relacional impone un estricto conjunto de limitaciones al desarrollo, tanto a nivel de modelo de datos, de creación de reglas, cambios,…

 

  • Modelo de datos. Con Sofia2, el desarrollador solo tiene que crear el modelo de datos en un lugar: la Consola Web del propio producto. En un desarrollo los desarrolladores necesitan crear y mantener el modelo de datos en tres lugares mediante el uso de diferentes interfaces: la aplicación, la propia base de datos y la capa ORM.

 

  • Soporte JSON. El almacenamiento en JSON, pilar básico de numerosas aplicaciones actuales, se realiza sin dificultades y no requiere conversión. Con una SGBDR, los desarrolladores necesitan “aplanar” y transformar JSON para almacenarlo en tablas relacionales, y más tarde tienen que recuperar las capas al realizar la extracción de la base de datos.

 

  • APIs multilenguaje: Aparte del conector REST que puede usarse de forma sencilla desde cualquier lenguaje, se ofrecen APIS multilenguaje cuando se necesitan protocolos más avanzados y eficientes. Las APIs permiten comunicar de forma más sencilla con la plataforma, se ofrecen APIS Java, Javascript, C/C++, Python, Android, iOS, Node.js, Arduino,… todas estas APIs bajo licencia Apache y sin coste.

 

En este post presentamos Sofia4Bot, una librería Java que permite desarrollar aplicaciones Spring y Spring Boot que usan Sofia2 como Backend, de forma muy sencilla: basta una anotación y una clase DTO que representa nuestra ontología.

 

Preparar un proyecto Spring Boot para hacer uso de Sofia4Boot es muy sencillo y solo son necesarios tres pasos

 

  1. Añadir la dependencia de Sofia4Boot al nuestro proyecto

 

 

Os recordamos el repositorio maven de Sofia2

 

 

  1. Configurar el fichero application.properties de nuestra aplicación, para añadirle las siguientes propiedades de conexión con la plataforma, son los datos de URL, PUERTO y ENDPOINT de conexión con la plataforma y el TOKEN, KP e INSTANCIA para la gestión de la seguridad que hace la plataforma Sofia2.

 

 

  1. Inicializar Sofia2Boot, para ello en el arranque de SpringBoot le indicamos que queremos usar el Sofia2Initializer:

 

 

Ya tenemos todo listo para empezar a usar Sofia2 como repositorio de datos. Al estilo de SpringData Sofia4Boot solo requiere que definamos la Interface de nuestro Repository. El framework se encargará por debajo de realizar toda la lógica de negocio.

 

Si por ejemplo queremos trabajar con la ontología Alarma, podemos crear una interface RepositoryAlarma:

 

 

Esta interface la anotaremos con @Sofia2Repository(“Alarma”). Con esto le indicamos al framework que es una interfaz de repositorio Sofia2 que trabaja con la ontología Alarma. Tras esto, lo único que debemos hacer es definir los métodos de acceso a datos. Sofia4Boot soporta las operaciones de Query, Insert, Update y Delete. Para cada una de estas operaciones existe una anotación:

 

@Sofia2Query

@Sofia2Update

@Sofia2Delete

 

Nos permiten en la propia anotación definir la sentencia SQL de la operación

 

@Sofia2Query(“select * from Alarma where Alarma.causa=$causa”)

@Sofia2Update(“update Alarma set Alarma.causa=$valor where Alarma.causa=$param”)

@Sofia2Delete(“delete from Alarma where Alarma.causa=$parametro”)

 

Como podemos deducir de la propia sentencia se soporta el uso de parámetros para hacer sentencias dinámicas. Estos parámetros los definiremos como parámetros del método que estamos definiendo List update(@Param(“$valor”)String valor,@Param(“$param”) String param);

 

Es suficiente con indicar a través de la anotación @Param con que parámetro de la consulta se asocia el parámetro del método.

 

@Sofia2Insert

 

Es todavía más sencillo de usar, el método solo necesita un parámetro que será el DTO de la ontología que vamos a insertar.

 

SofiaId insert(Alarma alarmaOntologia);

 

Estos métodos nos devuelven el identificador a través del SofiaId o de una Lista de SofiaId de los elementos que han sido credos, modificados o borrados y en el caso de las consultas una Lista del objeto de la ontología.

 

Veamos cómo queda la interfaz completa:

 

 

Y su invocación desde un controlador, donde directamente invocamos las operaciones que hemos definido pero no hemos tenido que implementar. Para Spring Boot existirá un bean que implementa nuestra interfaz ya que sofia4Boot se encarga de crearlo por nosotros y de toda la lógica de conectividad con Sofia2, preparación de los mensajes y transformación de datos en JSON a nuestros objeto Java.

 

 

Podéis descargaros el proyecto de ejemplo desde nuestro repositorio github en https://github.com/Sofia2/sofia4bootexample.git

 

Para ejecutarlo basta con hacer

 

mvn spring-boot:run

 

 

Para probar el ejemplo una vez creado el Controlador podemos hacer a través de una invocación HTTP. Vamos a lanzar la consulta de todos los registros y una inserción desde el cliente POSTMAN. En el caso de la consulta, definimos una operación GET a la URL del controlador, en la URL localhost:8080

 

 

Y nos devuelve un listado con la consulta

 

 

Para la Inserción, definimos la invocación a través de una operación POST y definimos los valores del Objeto Alarma. Al estar en un cliente HTTP, definimos el objeto como JSON

 

 

El retorno de la invocación será el Id de la instancia insertada.

 

 

A medida que ejecutamos inserciones, si volvemos a lanzar la consulta veremos que cada vez aparecen nuevas instancias.

 

 

También podemos crearlo como proyecto Eclipse ejecutando >mvn eclipse:eclipse

 

Sofia4boot: Soporte para trabajar con Sofia2 en aplicaciones Spring Boot

SENA obtiene el ‘Premio a la Eficiencia Energética’

SENA

El pasado viernes 21 de Abril,  ANDESCO (Asociación Nacional de Empresas de Servicios Públicos, Comunicaciones y TV de Colombia) concedió el premio a la eficiencia energética a SENA.

SENA (Servicio Nacional de Aprendizaje), es un establecimiento público de orden nacional, adscrito al Ministerio de Trabajo de Colombia que ofrece formación gratuita a millones de colombianos que se benefician con programas técnicos y tecnológicos.

El proyecto nació como una necesidad de ahorro de energía que atendió a una emergencia nacional por escasez energética a finales de 2015. Se estableció un monitoreo en 28 sedes en diferentes pisos térmicos. En 2016 se logró ahorrar 931 millones de dólares, pero también fue muy importante el cambio en la cultura de ahorro de los trabajadores y en la de más de un millón de aprendices que se forma en SENA.

 

El proyecto de ahorro energético consiste en un Sistema de Gestión de la Energía bajo la Norma ISO 50001 de  2011, soportado en la medición y monitorización en tiempo real de los consumos de energía eléctrica, gas natural y agua, desde una plataforma online para tomar medidas a corto, mediano y largo plazo. Estos contribuyen a la optimización y el uso adecuado de los recursos energéticos, la reducción de las emisiones de gases de efecto invernadero y otros impactos ambientales, así como los costos de la Energía.

Sofia2InfografiaRecortada

FEEP IoT&BigData Platform Sofia2 es base tecnológica del SGE (Sistema de Gestión Energética) de este proyecto de ahorro energético,  así como también ha impulsado el desarrollo de soluciones de alto valor añadido en clientes de ámbitos como las Smart Cities (plataforma urbana de La Coruña) o Smart Health (Proyecto TELEA, para Teleasistencia, y SISENS, para la monitorización de pacientes, ambos  en el Servicio Galego de Saúde)

 

SENA obtiene el ‘Premio a la Eficiencia Energética’

TCO Sofia2 vs TCO Desarrollo a medida

Blog de Sofia2 IoT Platform

En este post vamos a hacer un pequeño análisis sobre el TCO de Sofia2 vs un desarrollo a medida sobre una base de datos relacional.

El coste total de propiedad (TCO) de MongoDB y Oracle incluye los costesiniciales y corrientes que incluyen software, hardware y personal.

COSTES INICIALES:

Los costes iniciales se componen de:

  • Esfuerzo de desarrollo inicial: Coste de personal + Programación del desarrollador necesaria para la aplicación
  • Esfuerzo administrativo inicial: Coste de personal + Administradores para instalar y configurar software, máquinas del clúster, particionado, …
  • Licencias de software
  • Hardware de servidores
  • Hardware de almacenamiento Almacenamiento necesario para almacenar los datos, varía en función de si se utiliza almacenamiento interno o compartido (SAN), de la cantidad de almacenamiento y de si se utilizan unidades de disco duro (HDD) o unidades de estado sólido (SSD).

COSTES CORRIENTES:

Se compone de:

  • Esfuerzo de desarrollo corriente: Personal…

Ver la entrada original 1.361 palabras más

TCO Sofia2 vs TCO Desarrollo a medida