Yéssica Forero Navarro Raúl Ernesto Gómez Mendoza Diana Carolina Mogollón Ruiz Luis Fernando...

Arquitectura de SoftwareSistema de Control y Monitoreo de Oficinas y Viviendas Inteligentes

Yéssica Forero Navarro Raúl Ernesto Gómez MendozaDiana Carolina Mogollón Ruiz

Luis Fernando TaboadaErnesto Fabián Vargas Madrid

Introducción. Estrategia arquitectural. Vista funcional.◦ Elementos de la vista funcional.

Vista de despliegue.◦ Modelo de aplicación.◦ Modelo de red.

Vista de información.◦ Estructura de datos◦ Flujo de información de eventos.◦ Flujo de información de reglas.

Desempeño – Tácticas. Experimento.◦ Aspectos de implementación.◦ Estructura de la Trama◦ TimeSpecs◦ Resultados obtenidos.

Lecciones aprendidas.

Agenda

La siguiente presentación tiene como objetivo exponer el segundo avance en la descripción de la arquitectura de software del Sistema de Control y Monitoreo de Oficinas y Viviendas Inteligentes (SCMOVI), haciendo especial énfasis en mostrar las decisiones arquitecturales desde la perspectiva de desempeño.

Introducción

Descripción general estrategia arquitectural

Vista Funcional

Elementos Vista Funcional

Componente Descripción

Concentrador Uno por inmueble (envío de todos los tipos de señales generadas).

Monitor de señales Recibe las señales, hace una validación básica y envía el mensaje al bus.

Bus de eventos Facilita la comunicación entre el monitor, procesadores, notificador y registro de eventos.

Procesador de Señales de Ubicación

Valida las señales RFID contra las reglas configuradas.

Principales componentes

Elementos Vista FuncionalComponente Descripción

Notificador Envía mensajes de alerta a quien corresponda de acuerdo al tipo de evento generado.

Generador de reportes Presenta información histórica de los estados del inmueble.

Procesador de Señales de Cambio de Estado

Valida los diferentes tipos de señales que implican un cambio de estado, tales como señal de humo, señal de abrir/cerrar una ventana o puerta y señal térmica indicando cantidad de personas.

Administrador de Reglas Al momento de iniciar el sistema carga en memoria las reglas de las casas de una urbanización.

Elementos Vista Funcional

Conectores Descripción

JDBC Acceso a BD (Síncrono).

HTTP Acceso a reportes (Síncrono).

Sockets Comunicación monitor de señales y servidor de tiempo. (Síncrono).

JMS Comunicación con el bus de mensajes (Asíncrono).

Acceso a memoria Acceso a blackboard (Síncrono).

Vista de Despliegue - Aplicación

Vista de Despliegue - Red

Vista de Información – Estructura de datos

Vista de Información – Flujo de eventos

Eventos

Registro de Eventos Consulta de

Eventos

Procesadores de señales de

sensores y tags RFID

Notificador Interno Propietarios

Vista de Información – Flujo de reglas

Reglas

Consulta Reglas

Actualiza Reglas

Ingresa Reglas

Procesadores de señales

Administrador del sistema

Administrador interno de

reglas Distribuye reglas

Compara reglas

Desempeño - TácticasTáctica Ubicación Objetivo

Rata de Eventos En los concentradores

Mejorar la escalabilidad: Controlar la frecuencia de muestreo de las señales enviadas por los sensores.

Leader-Followers En los procesadores

Aumentar la concurrencia: Baja el overhead cuando las acciones son atómicas, de corta duración, repetitivas y basadas en eventos.

Half Sync/Half Async

En los procesadores

Mejorar la latencia: El primer mensaje de alarma se envía con la primera información disponible, y luego se envia un segundo mensaje indicando la cantidad de personas que hay en la casa.

EXPERIMENTO

Uso de tramas de arrays de bytes para la comunicación entre los componentes, con el fin de disminuir el peso de la información y disminuir la carga de los procesos al tener que convertir los datos.

Uso de Timespecs (expresiones regulares para expresar intervalos de tiempo) para la representación de reglas de uso de activos en formato ligero y flexible.

Reglas en memoria (blackboard), se utilizó una estructura de HashMap en memoria para agilizar la búsqueda de reglas de una casa, un tag RFID o una antena específica por su identificador.

Servidor JMS para el manejo de la mensajería asíncrona (bus de mensajes). Se utilizó un servidor JMS de Apache, (ActiveMQ). Este servidor permite definir los elementos necesarios para establecer comunicación asíncrona por colas (1 a 1) o por tópicos (1 a n). La configuración de la mensajería se puede hacer programáticamente o por medio de JNDI. No necesita servidor J2EE.

Aspectos de implementación

Estructura de la Trama

Expresiones regulares para representar cualquier intervalo de tiempo.

Flexible - Formato ligero

Ejemplos:◦ Lunes y martes: [0, 1] w◦ Entre 5pm y 8pm: [17-20]h◦ 3 días a partir del 1 de marzo de 2010: {3M2010Y-}{/3d}

Reglas en memoria no cambian de acuerdo al tiempo.

Se pregunta si el time de una señal esta contenido en el Timespec de una regla antes de validar contra la regla.

Timespecs

Resultados

1 5 10 25 50 75 100 150 200 250 300

Tiempo (ms) 38 73 87 121 237 398 471 792 891 938 1091

100

300

500

700

900

1100

Escalabilidad

Controlar la frecuencia de muestreo de señales en el concentrador de cada casa, nos permitió poder procesar mayor cantidad de señales de casas aumentando la escalabilidad del sistema.

La creación de abundantes hilos de ejecución no siempre es la mejor alternativa, se debe tener un equilibrio entre cantidad y funcionalidad.

La táctica Half Sync/Half Async nos permitió entregar una rápida primer respuesta, mientras se prepara la información completa en una segunda notificación.

Lecciones aprendidas