Asistente para la creación de reglas

Sofia2 cuenta con un motor de reglas CEP y de Script que son muy útiles para la gestión automática de eventos, como por ejemplo, si alguien inserta algo en una ontología determinada, podemos hacer que automáticamente mande un email a una cuenta de correo electrónico, o que realice otra inserción en una ontología diferente, etc.

Las posibilidades que ofrecen, ya no solo las reglas CEP y script de manera independiente, sino la combinación de ambas, son infinitas. Pero, para los que entran en contacto por primera vez con estas herramientas, puede ser difícil al principio crearlas y ver sus posibilidades. Para ello hemos diseñado un Asistente de creación de reglas para facilitar la creación las mismas en base a unas plantillas. Actualmente solo disponemos dos plantillas, una para detectar la ausencia de un determinado evento y otra para filtrar los eventos que se produzcan. Todo ello intentando abstraer al usuario lo máximo posible de lenguajes y sintaxis a los que puede que no esté acostumbrado.

Os mostramos ahora paso a paso como crear cada una de las dos reglas usando esta herramienta.

Regla de ausencia

Primero, para llegar al menú de selección de la plantilla de ausencia, es necesario que seleccionéis en el menú de la izquierda en el apartado “Reglas” la opción “Crear Regla con Wizard”. Os aparecerá una lista con las opciones que hay, debéis seleccionar ahora la primera opción, donde pone “Generar regla utilizando plantillas” y pulsamos en SIGUIENTE.

Ahora debería aparecerte una lista con las plantillas disponibles. Si pulsas sobre cada una de ellas, podrás observar a la derecha una breve descripción de su funcionalidad. En esta ocasión seleccionaremos la plantilla de ausencia y pulsaremos en SIGUIENTE.

En este segundo paso nos encontramos en una pantalla con diferentes campos que deberemos rellenar. El primero se trata del Nombre de la regla, el cual solo puede estar formado por letras, en el segundo campo seleccionamos la ontología sobre la que queramos detectar la ausencia y finalmente introducimos el tiempo para la ausencia. Comprobamos que está todo correcto y pulsamos en siguiente. Aquí será cuando se generen automáticamente el evento y la regla CEP de entrada que detectará la ausencia.

Ahora deberíamos estar en el paso 3 con prácticamente todos los campos rellenos, a excepción de las pestañas THEN, ELSE y ERROR del script. En estos campos, podemos realizar cualquier acción utilizando la APISofia, como podemos ver en la imagen de abajo que nos mandaría un e-mail a la cuenta de Sofia para avisarnos de la ausencia. Una vez le demos a siguiente terminaremos el proceso y estará todo creado y funcionando.

Regla con filtros

Para utilizar esta plantilla, haremos como en el caso de la Plantilla de ausencia, hasta llegar al menú de selección de plantillas, donde describíamos el funcionamiento de cada una, pero en este caso seleccionamos la que pone “Plantilla con filtros” y le damos a siguiente.

En este primer paso tendremos que rellenar el campo identificación con las mismas restricciones de antes, y tendremos que seleccionar una ontología sobre la que queramos hacer el filtrado y cargar sus campos. Una vez cargados podremos empezar a crear los filtros e ir añadiéndolos a la tabla. Siempre tendremos la opción de editar los filtros una vez agregados en el caso de que, por cualquier motivo, nos hayamos equivocado a la hora de agregarlo, o simplemente queramos modificarlos.

Como podrás observar, en la tabla, la primera columna contiene unos selectores con dos opciones (AND y OR) en todas las filas menos en la primera. De esta manera cada filtro se combina con el inmediatamente superior con la operación que indiquemos en esa columna. Si ya hemos agregado todos los filtros y estamos satisfechos con las reglas creadas, podemos darle a siguiente para pasar al último paso.

Como habrás podido observar, esta pantalla se parece mucho a la del último paso de la Plantilla de ausencia, con la diferencia de que la pestaña IF estará llena de código que se ha generado automáticamente a partir de los filtros agregados en el paso anterior. Aunque por debajo su funcionamiento es ligeramente diferente, nosotros tendremos que rellenar los mismos campos (pestañas THEN, ELSE y ERROR) que en el caso de la ausencia. Una vez terminemos de rellenar las pestañas, pulsaremos sobre el botón siguiente y se habrá creado el Script de filtrado.

De momento estas son las dos únicas plantillas disponibles, pero en un futuro la lista crecerá con más opciones.

Asistente para la creación de reglas

¿What is SIGFOX?

 

SIGFOX is a global cellular connectivity solution for the Internet of Things. It was designed for low speed communications which allow us to reduce prices and energy consumption to the connected devices.

 

SIGFOX is based in an antennas infrastructure and base stations fully independent from the existing networks.

This low speed network is gradually going to be deployed in 60 countries over the next five years.

SIGFOX releases the IoT potential providing a highly scalable global network for connected devices. SIGFOXReady™ devices connect to Internet without any supplementary cost related to its geographic situation and without any additional network configuration for a specific location.

This worldwide connectivity solution is managed by SIGFOX thanks to its collaboration program throughout the cellular network operators, connecting all local ecosystems to the global networks. Unlike all phone companies trying to increase the bandwidth to 2/3/4G to give service to smartphones and tablets, the main SIGFOX target is to allow every object to connect to the Internet, affordably, wherever it is and without the need of charge its battery.

It is impossible to imagine the deployment of billions of connected devices with high communication costs and considering such volumes, every square centimeter of microchip counts. SIGFOX protocol is compatible with the majority of existent transceivers, and therefore it is easily accessible to all the modules and devices manufacturers.

 

SIGFOX is already deployed in:

 

It is expected to be introduced in all this: http://www.sigfox.com/es/#!/connected-world/sigfox-network-operator

At technological level, SIGFOX uses the UNB (Ultra Narrow Band), based on radio technology, to connect devices to its global network. The usage of UNB is essential to supply a high capacity network, evolutionary and with very low energetic cost, keeping a star cellular infrastructure, simple and easy to deploy.

If you are thinking about using SIGFOX in your application, it is important to take into account that SIGFOX is a connectivity solution focused on low speed devices. In SIGFOX you can send between 0 and 140 messages per day and each message contains up to 12 bytes of real useful data. The protocol itself already transmits the device ID, so those 12 can be structures as we want without any limit.

SIGFOX also offers an API and a SIGFOX CLOUD which offers a web application interface to manage the devices and the data integration configuration, as well as standard web APIs to automatize the managing of the devices and to implement data integration. The APIs are based on HTTPS REST requests, like GET or POST and the load format used is JSON. They can provide IPv6 interfaces to its devices too, as well as the MQTT protocol.

A “thing” needs a certified modem to be able to send messages using SIGFOX.

The image below shows some application examples:

 

The Price depends on the volume of the messages exchanged between devices as well as on the number of them. For more information contact with their local SNO.

If you want to know more about SIGFOX, take a look to their WhitePaper.

¿What is SIGFOX?

IoT Protocols (MQTT, REST,CoAP, XMPP) and SOFIA2

In this post IoT Protocol Wars: MQTT vs CoAP vs XMPP, Oleg Puzanov, an IoT expert (I highly recommend his Blog IoT Primer) analyzes the main IoT protocols currently available.

· MQTT and its variants like MQTT-S

· CoAP

· XMPP

· REST API

The diagram below resumes the main features of each protocol.

 

Oleg’s conclusion after the analysis is pretty clear: “My personal experience with these protocols in IoT space makes me lean towards MQTT / MQTT-S or REST API in the end”.

It is also really interesting this other Google Docs public document, where all these protocols are analyzed in a much deeper way.

About SOFIA2:

As all of you familiar with Sofia2 may already know, between all different connectors implemented in SOFIA2, we have the REST connector and MQTT connector (as well as WebSockets –trial stage-, Ajax Push, Web Services and the possibility to create your own connectors).

IoT Protocols (MQTT, REST,CoAP, XMPP) and SOFIA2

¿Qué es oneM2M?

oneM2M es un proyecto de Asociación entre 7 Organizaciones líderes de Desarrollo de Estándares ICT (CCSA China Communications Standards Association, TTA Telecommunications Technology Association, ARIB Association of Radio Industries and Business, TTC Telecommunication Technology Committee of Japan , ETSI European Telecommunications Standards Institute, ATIS Alliance for Telecommunications Industry Solutions, TIA Telecommunications Industry Association) que se han unido para lanzar una nueva organización para asegurar el despliegue de sistemas de comunicación M2M de una manera más eficiente.

Para ellos todas las organizaciones acordaron cooperar en la producción, definición y mantenimiento de las Especificaciones Técnicas así como los Reportes Técnicos relacionados con soluciones M2M enfocados hacia la Capa de Servicio.

Inicialmente las organizaciones de oneM2M deben preparar, aprobar y mantener los documentos técnicos necesarios para:

1. Casos de uso y requerimientos para un conjunto común de capacidades de la capa de Servicio

2. Aspectos de la capa de Servicio con una definición a alto nivel y de manera detallada de la arquitectura

3. Protocolos/APIs/objetos estándar basados en la arquitectura

4. Aspectos relacionados con la privacidad y la seguridad

5. Accesibilidad y descubrimiento de aplicaciones

6. Interoperabilidad

7. Almacenamiento de datos para registros con fines estadísticos y de facturación

8. Identificación y nombramiento de dispositivos y aplicaciones

9. Modelos de información y de gestión de datos (incluyendo funcionalidades de suscripción y notificación)

10. Aspectos de gestión (incluyendo la gestión remota de entidades)

11. Casos de uso comunes, aspectos de terminales y módulos, incluyendo la capa de Interfaces/ APIs entre:

  • Las capas de aplicación y servicio
  • La capa de servicio y las funciones de comunicación

En 2014 fue lanzada la primera Candidate Release del estándar oneM2M.

Vamos a resumir sus principales características.

Casos de uso

OneM2M estableció unos casos de uso iniciales aplicables a los diferentes segmentos la industria M2M.

Esto es solo un cuadro resumen, si deseáis conocer con más detalle las especificaciones de cada uno de los casos de uso podéis descargaros el documento oficial aquí.

Arquitectura y especificaciones

En un principio se realizó un análisis de las arquitecturas propuestas para el estándar oneM2M junto con un estudio sobre como unir las arquitecturas propuestas. Obteniendo como resultado el documento Arquitectura funcional del estándar de la Candidate Release.

El modelo arquitectónico de oneM2M consiste en un modelo por capas compuesto por la capa de Aplicación, la capa de Servicios Comunes y la capa de los Servicios de Red.

capas oneM2M

Arquitectura funcional

oneM2M

La imagen nos muestra la estructura básica de un modelo oneM2M.

Los diferentes componentes que podemos ver en la imagen superior son instancias de las capas que vimos en el apartado anterior.

1. AE o Entidad de Aplicación: Representa una instancia de la lógica de la aplicación para soluciones punto a punto M2M. Ejemplos de posibles AEs podrían ser una instancia de una aplicación de seguimiento de flota (flota de autobuses interurbanos por ejemplo), una instancia de una aplicación de monitorización del azúcar en sangre, etc.

2. CSE o Entidad de Servicios Comunes: Representa la instancia de un conjunto de Funciones de Servicios Comunes (CSF) en los entornos M2M. Algún ejemplo de las funciones ofrecidas por un CSE es la función de Gestión de Datos, la de gestión de Dispositivos, la de gestión de Suscripciones M2M o Servicios de Localización.

3. NSE o Entidad de Servicios de Red: Una entidad de Servicios de red proporciona servicios de la red subyacente a los CSEs.

Relaciones entre entidades oneM2M

Las diferentes entidades se agrupar en nodos que pueden existir en un espacio oneM2M y pueden relacionarse entre sí.

oneM2MCom

Como podemos ver en la imagen existen diferentes tipos de nodos, tenemos el Infrastructure Node (IN), el Middle Node (MN), el Application Service Node (ASN) y el Application Dedicated Node (ADN) los cuales pueden comunicarse entre sí a través de los diferentes puntos de referencia que podemos observar. Dependiendo del tipo de nodo las restricciones de comunicaciones entre los diferentes nodos son distintos, para más información acudir a la sección 6.1 del Documento de Arquitectura Funcional de M2M.

Los diferentes nodos pueden estar localizados en diferentes puntos de la red M2M. Por ejemplo tanto los ASN como los ADN, pueden estar alojados en un dispositivo M2M. Un MN puede estar alojado en un Gateway M2M. En el caso de los INs solo puede existir un nodo de este estilo en el dominio de la infraestructura (Infrastructure Domain en la imagen) por Proveedor de Servicio en un sistema oneM2M.

Aspectos de Seguridad

OneM2M más allá de proporcionar soluciones de seguridad que protegen la integridad de la capa de servicios M2M, la arquitectura oneM2M expone, a través de su API, más servicios de seguridad que se ponen a disposición aplicaciones M2M. Esto permite a las aplicaciones M2M beneficiarse de las soluciones de seguridad desplegadas en el Servicio de Arquitectura M2M, sin añadir soluciones de seguridad redundantes y / o propietarias.

¿Qué es oneM2M?