Análisis de Arquitecturas de Sistemas de Tiempo Real y su Adaptación a IoT

Saclier Lucas Javier

Revisor: Anacleto Valerio Adrián

Tabla de ContenidosAnálisis de Arquitecturas de Sistemas de Tiempo Real y su Adaptación a IoT

ResumenIntroducción a Sistemas de Tiempo RealConceptos y Definiciones:Introducción al Diseño de SRTArquitectura de SRTPatrones de Diseño

Estructura para la Descripción de un Patrón DiseñoPatrones Arquitectónicos de los STR

Patrones de Componentes y SubsistemasPatrones de ConcurrenciaPatrones de MemoriaPatrones de RecursosPatrones de DistribuciónPatrones de Seguridad y Confiabilidad

Patrones Arquitectónicos para el AnálisisArquitectura en CapasArquitectura en 5 capasMicrokernelArquitectura de CanalMáquina VirtualArquitectura Basada en ComponentesPatrón de Cola de MensajesPatrón de InterrupciónPatrón de Llamada ProtegidaPatrón de Ejecución CíclicaPatrón Round RobinPatrón de Prioridad EstáticaPatrón de Prioridad DinámicaPatrón de Memoria CompartidaLlamada de Procedimiento RemotoPatrón ObservadorBus de DatosProxyBrokerPatrón de Canal Único ProtegidoPatrón de Redundancia HomogéneaPatrón Monitor-ActuatorPatrón de VigilanciaPatrón de Ejecución de Seguridad

Introducción a IoTArquitectura IoTDrivers de Calidad de IoT

Árbol de Utilidad de IoTAnálisis de Patrones RTS en IoTPatrones de Distribución en IoT

Solicitud / RespuestaSuscripción de EventosMensajería AsíncronaMensajería ConfiableMultidifusiónPublicación / SuscripciónColasBroker de MensajesFederaciónDescubrimientoDelegación de Confianza

MQTT en IoTCoAP en IoTConclusiónReferencias

Análisis de Arquitecturas de Sistemas de Tiempo Real y su Adaptación a IoT

ResumenLos Sistemas de Tiempo Real (RTS) se diferencian de los Sistemas tradicionales en que el tiempo de respuesta es un factor crítico para su correcto funcionamiento (determinístico).

Si bien se suelen asociar los RTS con Sistemas Industriales, Monitoreo de Señales Fisiológicas, Sistemas Machine to Machine (M2M) y otros Sistemas donde la criticidad es alta, también podemos asociarlo a otro tipo de Sistemas.

En la actualidad existen RTS que tienen menor criticidad al factor tiempo pero requieren ser analizados y diseñados como RTS incorporando otros Atributos de Calidad. Si pensamos en “Internet of Things” (IoT), podemos comprender del desafío que nos espera. Es por ello que será analizado como un RTS en el presente trabajo.

Los Sistemas clásicos suelen resolver los drivers de calidad (o críticos) a partir de una solución de hardware robusta, software desarrollado con lenguajes de bajo nivel y con una finita interacción con otros dispositivos. La resolución del problema se suele centrar a un Controlador Lógico Programable (PLC), un Microcontrolador o Microprocesador que cumple las características específicas para cumplir esa necesidad. Esta decisión no incorpora atributos de calidad como escalabilidad o interoperabilidad que son drivers para Sistemas de IoT. No debemos minimizar estos RTS pero debemos comprender que en IoT la interacción puede ser exponencial llevada a 2128 direcciones por IPv6.

El objetivo de este Trabajo es analizar los Patrones Arquitectónicos clásicos de los RTS y evaluar cómo se adaptan a IoT. Como primer paso se deberán especificar los escenarios de atributos de calidad específicos para IoT. A partir de ello se podrá analizar la compatibilidad de los Patrones clásicos y que características se deben incluir para cumplir con los nuevos desafíos.

Considero que el trabajo es una aproximación para comprender los desafíos de los RTS, no solamente desde la Arquitectura, sino desde otros aspectos que se deben considerar en nuestra disciplina tales como la Metodología de Desarrollo o cómo definir una correcta Estrategia de Pruebas de este tipo de Sistemas.

Introducción a Sistemas de Tiempo Real

El término "tiempo real" se utiliza ampliamente en muchos contextos. Cada persona puede tener una impresión distinta lo que refiere este concepto aún más cuando no encontramos una definición en el diccionario de la Real Academia Española. En otros idiomas sucede lo mismo y no hay una definición “correcta” para este término, podemos encontrar definiciones que difieren conceptualmente. Es por ello que a lo largo de este trabajo utilizaremos este término con cuidado. Cuando le sumamos el término “sistema” debemos entender que no todos los sistemas de tiempo real (STR) son iguales, cada uno tiene sus características propias y el concepto de tiempo real será diferente en cada escenario.

Conceptos y Definiciones:

Sistema

Un sistema (Figura 1) es un mapeo de un conjunto de entradas a un conjunto de salidas. Si pensamos al sistema como una “caja negra” sin importarnos su implementación interna, podemos definir cinco características de un Sistema:

1. Un sistema es un conjunto de componentes conectados entre sí de una manera organizada.2. Un sistema es fuertemente alterado si un componente se agregado o eliminado.3. Un sistema tiene un propósito.4. Un sistema tiene un grado de permanencia.5. Un sistema fue definido con un interés particular.

Figura 1. Sistema

Tiempo de Respuesta

Es el tiempo entre la aparición de un conjunto de entradas y el comportamiento requerido por el sistema.

Sistema de Tiempo Real

Es un sistema que debe satisfacer con una respuesta en un tiempo establecido, el no cumplimiento puede llevar a riesgos o consecuencias severas. La correctitud de un sistema de tiempo real (Figura 2) se basa en una respuesta correcta en valor y en tiempo.

Figura 2. Sistema de Tiempo Real (STR)

Sistema de Tiempo Real - Soft

Es un sistema de tiempo real dónde el no cumplimiento del tiempo establecido genera pérdida de performance, pero no riesgo o consecuencias severas.

Sistema de Tiempo Real - Hard

Es un sistema de tiempo real dónde el no cumplimiento de un tiempo establecido genera riesgo o consecuencias severas.

Sistema de Tiempo Real - Firme

Es un sistema de tiempo real dónde el no cumplimiento de un conjunto acotado de tiempos no genera consecuencias severas, pero si generará consecuencias severas si el no cumplimiento es generalizado.

Evento

Es una ocurrencia que modifica el flujo principal del programa. En este tipo de Sistema podemos vincular el concepto de evento con el de interrupción.

Tiempo de Release

Es el tiempo que insume el sistema en generar una respuesta a partir de una interrupción o evento.

Sistema Derteminísitco

Es un sistema que para un grupo de valores de entrada siempre devuelve el mismo valor de valores de salida.

Introducción al Diseño de SRT

Arquitectura de SRT

El análisis identifica los requisitos esenciales de un sistema en desarrollo, haciendo hincapié en el que se necesita. En cambio el Diseño se centra en el cómo y añade detalles específicos destinados a optimizar el sistema con el fin de cumplir las necesidades de calidad del sistema. En el presente trabajo haremos foco en los Patrones de Diseño que responden a las decisiones del alto nivel del sistema, decisiones arquitectónicas. Las decisiones en este nivel afectan a la mayoría o todas las partes del sistema en cuestión. Estas decisiones se pueden agrupar en las siguientes vistas (Figura 3):

• Vista de Dominio• Vista de Componente o Subsistema• Vista de Concurrencia• Vista de Distribución• Vista de Seguridad y Fiabilidad• Vista de Despliegue

Figura 3. Vista de un Sistema de Tiempo RealVista de Dominio:

Un dominio es un área específica de conocimiento, por lo general con su propio vocabulario, y se requiere un área específica de expertise. Un Dominio es modelado a partir de paquetes del Dominio, que descomponen el sistema en elementos más pequeños para poder analizarlos de forma más simple y poder distribuirlo en los equipos de desarrollo. Este modelo lógico no se ocupa de la forma en que se estructurará el sistema en tiempo de ejecución. Se centra en las clases y las relaciones necesarias para asegurar la lógica correcta del sistema.

Vista de Distribución:

La vista de Distribución trata de cómo se distribuyen los objetos y cómo colaboran entre sí. Define sobre cómo se comunican los objetos, incluida la selección y el uso de protocolos de comunicación. En arquitecturas asimétricas, un objeto está ubicado en un espacio en particular en tiempo de diseño. Esto hace que encontrar ese objeto durante el tiempo de ejecución sea fácil, ya que los otros objetos pueden tener un conocimiento a priori sobre cómo localizar y comunicarse con el objeto en cuestión. En arquitecturas simétricas, la ubicación de un objeto no se decide hasta el momento de la ejecución. Las arquitecturas simétricas son útiles para sistemas complejos que deben equilibrar dinámicamente la carga de procesamiento en varios procesadores permitiendo escalar.

Vista de Componentes y Subsistemas:

La vista de Componentes y Subsistemas identifica los elementos de alto nivel del sistema y cómo se vinculan. Esta vista suele hacerse durante la fase de Ingeniería de Sistemas, pero también puede hacerse más tarde en la fase de diseño arquitectónico.

Vista de Recursos y Concurrencia

Esta vista de la arquitectura del sistema se centra en la gestión de los recursos y los aspectos concurrentes de la ejecución del sistema. Por concurrente, queremos decir que los objetos pueden ejecutarse en paralelo en lugar de secuencialmente. Estamos afirmando que no conocemos ni nos preocupamos por el orden relativo de ejecución de acciones entre los hilos, excepto cuando se menciona específicamente. Estos puntos de sincronización son las partes complejas del modelado de la concurrencia.

Vista de Seguridad y Confiabilidad

La vista de seguridad y confiabilidad examina cómo se define y gestiona la redundancia del sistema para aumentar estos parámetros. La arquitectura de seguridad y fiabilidad se refiere al correcto funcionamiento en presencia de fallos y errores. La redundancia puede utilizarse de muchas maneras para obtener diferentes grados y tipos de seguridad y fiabilidad. Vista de Despliegue

La vista de despliegue se centra en cómo la arquitectura de software se asigna a los dispositivos físicos. Se utiliza el concepto de un nodo para representar dispositivos físicos. Estos son a menudo estereotipados para indicar el tipo de hardware que representa el nodo. El nivel de detalle del nodo depende del modelo. Un nodo puede ser un Servidor, un Router o bien dispositivos como sensores y actuadores.

Patrones de Diseño

Un Patrón de Diseño es una solución generalizada un problema cotidiano. Para considerar un Patrón el problema que resuelve debe ser frecuente y su uso debe ser generalizable. El mismo debe poder ser aplicable a diferentes dominios. Un Patrón de Diseño es una estrategia para organizar un Diseño dónde se optimiza en búsqueda de cumplir uno o un conjunto de atributos de calidad. En este caso haremos hincapié en los Patrones Arquitectónicos.Los atributos de calidad que más se vinculan con los Sistemas de Tiempo Real son:

● Performance● Confiabilidad● Seguridad● Reuso● Mantenibilidad● Escalabilidad● Portabilidad● Interoperabilidad● Disponibilidad● Eficiencia (Uso de Memoria, Procesador, Consumo Energético, Ancho de Banda)

Muchas veces estos atributos de calidad entran en conflicto unos con otros, por lo que en una decisión de Diseño se debe seleccionar uno en desmedro de otro, esto sucede en los Patrones Arquitectónicos que analizaremos con posterioridad en el presente trabajo. Una decisión de Diseño debe buscar un equilibrio entre los atributos de calidad en conflicto, buscando una solución “suficientemente óptima”. El uso de Patrones de Diseño genera aspectos positivos en las soluciones Software que implementamos a partir del Reuso de soluciones efectivas en nuevos contextos. Además provee un lenguaje común y conceptos de Diseño maduros a los desarrolladores, obteniendo Diseños más comprensibles.

Estructura para la Descripción de un Patrón Diseño

Para describir y comprender de manera simple un Patrón de Diseño se propone la siguiente estructura que se utilizará para analizarlos a lo largo de este documento:

NombreEl nombre provee una referencia directa al significado del Patrón.

ClasificaciónEs la categoría dónde se ubica el Patrón.

ProblemaProvee el contexto del problema y de los aspectos de calidad que el patrón busca optimizar. Se ocupa de identificar los tipos de contextos en el que el patrón podría ser especialmenteapropiado.

ConsecuenciasEn esta sección se describe las soluciones de compromiso (tradeoffs) que se realizan cuando el Patrón es utilizado.

Patrones Arquitectónicos de los STR

Los Patrones en STR los podemos clasificar en diferentes tipos, dependiente del propósito que persigue solucionar cada uno. A continuación organizaremos y clasificaremos los Patrones:

Patrones de Componentes y Subsistemas

Los siguientes Patrones podemos considerarlos los de más alto nivel y proponen soluciones arquitectónicas a nivel Sistema. Se debe comprender que las soluciones presentadas utilizan como estrategia componentes vinculados entre sí. El Componente es una estructura de software que cumple una función específica.

● Arquitectura en Capas● Arquitectura en 5 Capas● Microkernel● Arquitectura de Canal● Patrón de Contenedor Recursivo● Patrón de Control Jerárquico● Máquina Virtual● Arquitectura basada en Componentes● Patrón de Sistemas de Tiempo Real Orientado a Objetos

Patrones de Concurrencia

Los siguientes Patrones se centran en la concurrencia. Incluye el control y asignación de los elementos arquitectónicos. Esto incluye la gestión de recursos que deben estar protegidos del acceso simultáneo.

● Patrón de Cola de Mensajes● Patrón de Interrupción● Patrón de Llamada Protegida● Patrón RendezVous● Patrón de Ejecución Cíclica● Patrón Round Robin● Patrón de Prioridad Estática● Patrón de Prioridad Dinámica

Patrones de Memoria

Los siguientes Patrones se centran en el manejo eficiente de memoria y la gestión robusta de elementos de software. Estos Patrones son de vital importancia en Sistemas de Tiempo Real y Sistemas Embebidos donde el recurso memoria es finito.

● Patrón de Asignación Estática● Patrón de Asignación de Conjuntos● Patrón de Buffer de Tamaño Fijo● Patrón de Puntero Inteligente● Patrón de “Recolección de Basura” ● Patrón de “Compactador de Basura”

Patrones de Recursos

Los siguientes Patrones se centran en el manejo eficiente de recursos Hardware. Estos Patrones son de vital importancia en Sistemas de Tiempo Real y Sistemas Embebidos donde el recursos son finitos y se debe definir una estrategia de acceso. Estos Patrones tienen vínculo directo con los Patrones de Concurrencia y también con los Patrones de Memoria, si bien ahora nos importa el recurso específico y no el manejo que hace ese recurso de memoria.

● Patrón de Sección Crítica● Patrón de Prioridad por Herencia ● Patrón de Prioridad más Alta (por Herencia)● Patrón de Prioridad más Alta Limitada (por Herencia)● Patrón de Bloqueo Simultáneo● Patrón de Bloqueo Ordenado

Patrones de Distribución

La distribución es un aspecto importante de la arquitectura. Define las políticas, los procedimientos y parte de la estructura del Sistema.. La distribución se puede pensar en forma asimétrica o simétrica. Las arquitecturas de distribución asimétrica son aquellas donde la asignación de espacio a los objetos o estructuras es en tiempo de diseño. La mayoría de loslos sistemas embebidos utilizan una arquitectura asimétrica ya que es más simple y requiere menos procesamiento. La distribución simétrica es dinámica ya que el espacio se designa en tiempo de ejecución. Si bien esto es más complejo, también es mucho más flexible y permite el balanceo de carga.Tanto para arquitecturas asimétricas como simétricas, la arquitectura de distribución existe en múltiples niveles de abstracción. El nivel de abstracción de aplicación simplemente asigna los

objetos a un espacio, ocupándose de la comunicación y control de los mismos. Este nivel está directamente relacionado con el protocolo de capa de aplicación seleccionado. De esta manera pensamos en una arquitectura de colaboración entre objetos que se descubren y se comunican sin importar las capas inferiores. También debemos pensar la distribución a otro nivel de abstracción como por ejemplo en la selección de protocolos de capa de red o enlace, esto se desarrollará en el apartado de Patrones de Comunicación.

● Memoria Compartida● Llamada a Procedimiento Remoto● Patrón Observador● Bus de Datos● Proxy● Broker

Patrones de Seguridad y Confiabilidad

Los siguientes Patrones se centran en el manejo de la seguridad y la confiabilidad del Sistema. La seguridad puede definirse como la ausencia de accidentes o pérdidas, mientras que la fiabilidad se refiere a la probabilidad que un sistema continuará funcionando durante un período de tiempo especificado. Un sistema seguro puede fallar frecuentemente siempre que no cause accidentes, mientras que la fiabilidad de un sistema no se refiere en absoluto a las consecuencias que produce en caso de fallo. Sin embargo, la seguridad y la fiabilidad tienen un aspecto importante en común: su manejo requiere redundancia de algún tipo en el diseño de sistemas. Esta redundancia es necesaria tanto para identificar los riesgos, condiciones peligrosas, como para tomar medidas correctivas.

● Patrón de Canal Único Protegido● Patrón de Redundancia Homogénea● Modelo de Redundancia Modular Triple● Patrón de Redundancia Heterogénea● Patrón Monitor-Actuador ● Patrón de Control de Sanidad● Patrón de Vigilancia● Patrón de Ejecución de Seguridad

Patrones Arquitectónicos para el Análisis

A continuación se hará una selección de Patrones que se consideran de interés para luego analizarlos en IoT. No se han seleccionado Patrones de asignación de Memoria y Recursos por considerarlos de un nivel arquitectónico menor al que analizaremos en este documento.

Patrones de Componentes y Subsistemas:

● Arquitectura en Capas● Arquitectura en 5 Capas● Microkernel● Arquitectura de Canal● Patrón de Contenedor Recursivo● Patrón de Control Jerárquico● Máquina Virtual● Arquitectura basada en Componentes

Patrones de Concurrencia:

● Cola de Mensajes● Patrón de Interrupción● Patrón de Llamada Protegida● Patrón de Ejecución Cíclica● Patrón Round Robin● Patrón de Prioridad Estática● Patrón de Prioridad Dinámica

Patrones de Distribución:

● Memoria Compartida● Llamada a Procedimiento Remoto● Observador● Bus de Datos● Proxy● Broker

Patrones de Seguridad y Confiabilidad:

● Patrón de Canal Único Protegido● Patrón de Redundancia Homogénea● Patrón Monitor-Actuador ● Patrón de Vigilancia● Patrón de Ejecución de Seguridad

Arquitectura en Capas

Descripción

El patrón de arquitectura en capas organiza los dominios en una organización jerárquica basada en su nivel de abstracción.ClasificaciónPatrón de Componentes y SubsistemasProblemaEn un sistema en el que los dominios abstractos deben ser implementados en términos de dominios más concretos, necesitamos un patrón organizacional simple. Además, en muchos sistemas necesitamos que la aplicación sea portable a otras plataformas, o queremos proporcionar una plataforma abstracta o un entorno de ejecución para que las aplicaciones puedan adaptarse fácilmente.ConsecuenciasEl patrón de arquitectura en capas permite que el sistema proporcione conceptos sumamente abstractos, estrechamente relevantes para las necesidades y el vocabulario de la aplicación, incluso cuando esos servicios serán proporcionados en última instancia por un conjunto de servicios más simples proporcionados por clases más concretas. En una arquitectura de capa cerrada, las clases en una capa sólo pueden invocar operaciones de clases en la misma capa o en la capa de abajo. En una arquitectura en capas abierta, las clases en una capa pueden invocar operaciones de clases en la misma o en cualquier capa debajo de ella. Puede haber cierta pérdida de rendimiento al proporcionar un modelo con muchos niveles de abstracción con una arquitectura en capas cerrada. Por otra parte, una arquitectura en capas cerradas ofrece una encapsulación significativamente mejor y, en general, es mucho más fácil modificar correctamente las clases en una capa ya que se puede estar seguro de que sólo se afectarán las clases de esa capa o la inmediatamente superior. Las arquitecturas lógicas tienden a ser muy portables. Las capas superiores son más específicas de la aplicación, mientras que las capas inferiores son más específicas de la plataforma. Una arquitectura en capas permite la portabilidad en ambas direcciones. Las aplicaciones son más portables porque las capas inferiores se pueden reemplazar fácilmente con capas inferiores similares específicas de otras plataformas. Por otro lado, las capas superiores se pueden reemplazar fácilmente para permitir que otras aplicaciones se despliegan en la misma plataforma.

Arquitectura en 5 capas

DescripciónEl patrón de arquitectura en cinco capas es una arquitectura específicamente útil para la estructuración general de muchos sistemas embebidos y en tiempo real. Es una adaptación específica del patrón de capasClasificaciónPatrón de Componentes y Subsistemas.Problema

En un sistema en el que el dominio puede considerarse que está en una misma capa de abstracción debe implementarse en términos de capas más concretas por lo se necesita un patrón organizacional simple. Además, en muchos sistemas necesitamos que la aplicación sea portable a otras plataformas, o queremos proporcionar una plataforma abstracta para la cual las aplicaciones pueden ser fácilmente adaptadas.ConsecuenciasLas consecuencias de este patrón son en gran parte iguales que para el patrón de arquitectura en capas. Este patrón está normalmente abierto en el sentido de interfaz de usuario dónde puede requerir el uso de comunicaciones específicas.Un número pequeño de capas significa que este patrón es probable que sea altamente eficiente. Sin embargo, debido a las pocas capas, puede no proporcionar niveles de abstracción adecuados para descomponer sistemas complejos.

Microkernel

Descripción El patrón de arquitectura de Microkernel es un patrón útil cuando un sistema consta de un conjunto básico de servicios que pueden aumentarse en tiempo de compilación (si lo consideramos de ejecución podríamos estar pensando en microservicios) con una variedad de servicios adicionalesClasificaciónPatrón de Componentes y SubsistemasProblema Algunos subsistemas proporcionan un conjunto de servicios básicos que pueden ser aumentados opcionalmente en tiempo de compilación y deben ser reutilizables en una variedad de contextos.ConsecuenciasEl patrón de arquitectura de Microkernel proporciona un sistema escalable en el que se pueden agregar conjuntos opcionales de servicios al sistema durante las compilaciones del sistema. Esto permite que el subsistema se configure óptimamente para el entorno específico de aplicación.

Arquitectura de Canal

DescripciónEl patrón de Arquitectura de Canal es útil en dos circunstancias diferentes. En primer lugar, es útil cuando los datos dentro de un flujo de datos se transforman secuencialmente en una serie de pasos. En segundo lugar, a gran escala, el patrón de arquitectura de canal ofrece redundancia arquitectónica para aplicaciones de alta fiabilidad y de seguridad crítica.

ClasificaciónPatrón de Componentes y SubsistemasProblemaMuchos algoritmos procesan flujos de datos, aplicando el mismo conjunto de transformaciones operacionales a cada dato a la vez. Nos gustaría una estructura arquitectónica que mejore la capacidad de rendimiento con la replicación de unidades arquitectónicas que permitan el procesamiento eficiente de múltiples datos en diferentes etapas. Además nos gustaría un Arquitectura que mejore la fiabilidad y la seguridad mediante la simple adición de procesamiento redundante.ConsecuenciasEl patrón de arquitectura de canal está bien adaptado a la transformación secuencial de datos de un estado o forma a otra. Simplifica algoritmos que se pueden descomponer fácilmente en una serie de pasos que operan sobre elementos aislados de un flujo de datos. Se pueden agregar instancias de subsistemas de canal para mejorar el rendimiento. La arquitectura es fácilmente adaptable para manejar múltiples elementos del flujo de datos en paralelo, incluso cuando están en diferentes etapas de procesamiento.

Máquina Virtual

DescripciónEl patrón de máquina virtual optimiza la portabilidad de la aplicación a expensas de la eficiencia en tiempo de ejecución. Es una buena opción en aplicaciones en las que el alto rendimiento no es un problema significativo, pero sí el poder de ejecutar la aplicación en muchas plataformas diferentes.ClasificaciónPatrón de Componentes y SubsistemasProblema El problema abordado por el Patrón de Máquina Virtual es construir una infraestructura para la ejecución de aplicaciones que sea altamente portable para una gran clase de aplicacionesConsecuenciasLas ventajas de este patrón es doble. Primero, el portar una aplicación particular o un conjunto de aplicaciones a una plataforma de hardware novedosa se simplifica en gran medida, ya que es suficiente con recompilar la máquina virtual. Además, facilita enormemente el trabajo de portar un conjunto de aplicaciones a un conjunto de diferentes plataformas de hardware.Además, una vez que existe la máquina virtual para una plataforma en particular, cada aplicación escrita para la máquina virtual se ejecutará inmediatamente en todas las plataformas. Otra ventaja del Patrón de Máquina Virtual es que las aplicaciones son muy pequeñas en comparación con los tamaños de las aplicaciones nativas. En situaciones en las que la plataforma ejecutará múltiples aplicaciones concurrentes, el patrón de máquina virtual puede reducir el uso de memoria porque la propia máquina virtual proporciona gran parte del

soporte de las aplicaciones y al usar este patrón, esta infraestructura se almacena en memoria una sola vez.

Arquitectura Basada en Componentes

DescripciónUn componente es un artefacto de tiempo de ejecución que forma la unidad básica reemplazable del software. Se puede pensar a un componente como un objeto a gran escala que contiene que una interfaz para comunicarse. Los componentes tiene su funcionamiento interno encapsulado e interfaces bien definidas independientes del lenguaje.ClasificaciónPatrón de Componentes y SubsistemasProblemaEl patrón de arquitectura basado en componentes responde a la necesidad de una arquitectura robusta en presencia de mantenimiento y altamente reutilizable en una variedad de circunstancias.ConsecuenciasLa principal ventaja de utilizar este patrón es que los sistemas (y subsistemas) pueden construirse mediante la composición de componentes previamente definidos y desarrollados. El uso de interfaces opacas, independientes del lenguaje fuente, mejora enormemente la usabilidad. Hay muchos proveedores que proporcionan componentes reutilizables hoy en una variedad de dominios: interfaz de usuario, comunicaciones, middleware de objetos distribuidos y bibliotecas matemáticas que son las más comunes. La principal desventaja es la ineficiencia potencial debido al uso de interfaces opacas. El hecho de que una interfaz sea opaca significa que el cliente de un componente simplemente no puede confiar en detalles de implementación interna del componente, lo que no permite algunas optimizaciones potenciales. Además, debido a que la funcionalidad está empaquetada en componentes de gran escala, pueden ser necesarios recursos adicionales (como ciclos de CPU o memoria) cuando sólo unos pocos servicios de un componente se utilizan realmente en el sistema de destino. Todo el componente (junto con cualquier otro componente requerido por el primero) debe incluirse en el sistema, aunque sólo se invoquen algunos de los servicios del componente en el sistema en ejecución.

Patrón de Cola de Mensajes

DescripciónEl Patrón de Cola de Mensajes usa comunicación asincrónica, implementado a través de cola de mensajes para sincronizar y compartir datos entre las tareas.ClasificaciónPatrón de Concurrencia.

ProblemaEn sistemas multihilos, los hilos deben sincronizarse y compartir datos con otros. En primer lugar, las tareas deben sincronizarse para permitir el intercambio de datos. Además los datos deben ser compartidos de tal manera que no haya posibilidad de que se corrompan los datos.ConsecuenciasEs un patrón que se puede implementar prácticamente por todos los Sistemas Operativos de Tiempo Real y lenguajes multitarea. Es conceptualmente muy simple y robusto. Las desventajas principales están vinculadas que el intercambio es asincrónico y los datos se pasan por valor y no por referencia, generando una estrategia poco eficiente en el uso de memoria, cuando el volumen de datos a intercambiar son de gran tamaño.

Patrón de Interrupción

DescripciónEn muchas aplicaciones en tiempo real ciertos eventos deben ser respondidos de manera rápida y eficiente, casi independientemente de cuándo ocurren o lo que el sistema está haciendo. Cuando esas respuestas son relativamente cortas y puede ser atómicas, entonces este patrón puede ser una excelente decisión para manejar este tipo de eventos aperiódicos.ClasificaciónPatrón de Concurrencia. ProblemaEn un sistema en el que ciertos eventos son muy urgentes, como los que pueden ocurrir a altas frecuencias o aquellos en las que la respuesta debe ser lo más rápida posible, se necesita un medio para identificar y responder rápidamente a esos eventos. Esto puede ocurrir en muchos tipos diferentes de sistemas desde simple a complejo.ConsecuenciasEste métodos se utiliza con más frecuencia para encolar las respuestas para procesarlas más tarde (procesamiento asíncrono). Raramente se utilizan como la única estrategia de concurrencia, pero pueden utilizarse como tales cuando el sistema está casi inactivo y su funcionalidad consiste en un conjunto de respuestas simples y cortas a los eventos. A menudo, estos métodos se utilizan como un complemento a otra política de concurrencia (primaria), proporcionando respuestas altamente eficientes a eventos extremadamente urgentes. Sin embargo, se debe tener cuidado de asegurar que las respuestas a las interrupciones son cortas, ya que normalmente deben ser atómicas (no interrumpibles).Cuando las respuestas a las interrupciones pueden ser cortas, este patrón proporciona respuestas muy rápidas y oportunas. Cuando se requiere una respuesta más larga, pero se puede dividir en una parte de respuesta rápida y una parte más larga, pero más lenta, entonces es común utilizar el controlador de interrupción para recibir el evento y luego encolarlo para un procesamiento asíncrono posterior por otra tarea que se ejecuta en segundo plano. La desventaja de este patrón es que se utiliza a menudo donde es inapropiado: cuando las respuestas son demasiado largas o cuando el sistema es tan activo que se pierden los eventos de interrupción porque el sistema no ha completado su respuesta a eventos anteriores.

Patrón de Llamada Protegida

DescripciónLos esquemas de comunicación asíncronos, como el modelo de Cola de Mensajes, no proporcionan respuestas en tiempo y forma. Una alternativa es invocar sincrónicamente un método de un objeto que está corriendo en otro hilo, ese el patrón de llamada protegida. Es un patrón simple, aunque se debe tener cuidado para asegurar la integridad de los datos y evitar los problemas de interbloqueo.ClasificaciónPatrón de Concurrencia. ProblemaEl problema abordado por este patrón es la necesidad de sincronización a tiempo o el intercambio de datos entre hilos. En tales casos, puede que no sea posible esperar una comunicación asincrónica. Una comunicación sincrónica brindará una respuesta a tiempo, pero esto debe hacerse con cuidado para evitar la que se corrompan los datos y procesamiento erróneo.ConsecuenciasEste patrón proporciona un medio por el cual un conjunto de servicios puede proporcionarse de forma segura a través de un límite en el hilo. Esto se define para contemplar si varios objetos internos dentro del hilo llamado comparten un recurso común, ese recurso permanece protegido de la corrupción debido a problemas de exclusión mutua. Se trata de un encuentro síncrono, que proporciona una respuesta oportuna, a menos que los servicios estén bloqueados actualmente. Si los servicios están actualmente bloqueados, entonces el recurso está protegido, pero no se puede garantizar la respuesta a tiempo a menos que se haga un análisis para demostrar que el servicio es planificable.

Patrón de Ejecución Cíclica

DescripciónPara sistemas muy pequeños, o para sistemas en los que la predictibilidad de la ejecución es crucial, este patrón es un enfoque de uso común. Se utiliza mucho tanto en sistemas pequeños como en sistemas complejos. Su facilidad de implementación hace que sea una opción cuando las propiedades dinámicas del sistema son estables y bien entendidas.ClasificaciónPatrón de Concurrencia. ProblemaSe requiere la capacidad de ejecutar un conjunto de tareas más o menos independientes. La forma más sencilla de lograr esto es ejecutar lo que se llama un bucle "loop" o de ejecución cíclica que simplemente ejecuta las tareas a su vez, desde la primera hasta la última, y luego

comienza de nuevo. El tiempo de ejecución para un conjunto de tareas es constante y genera un sistema altamente predecible. ConsecuenciasLas aplicaciones sugeridas para aplicar este patrón tienen una serie de propiedades en común.• El número de tareas es constante durante todo el tiempo de ejecución del sistema.• La cantidad de tiempo que una tarea determinada asigna a cada ciclo es insignificante o constante de ciclo a ciclo.• Las tareas son en su mayoría independientes.• Se puede garantizar que el uso de recursos compartidos entre las tareas cuando esté completa cada tarea.• Existe un orden secuencial de tareas que se sabe que es adecuado para todas las situaciones.Cuando cualquiera de estas propiedades no se cumple, es probable que otra solución sea preferible al patrón ejecutivo cíclico.La principal ventaja de este patrón es su simplicidad. Sus principales desventajas son su falta de flexibilidad y la poca eficiencia. Las tareas no se pueden agregar o eliminar durante el tiempo de ejecución, por lo que su aplicabilidad se limita a los sistemas con un número reducido de tareas que se ejecutan iterativamente durante toda la vida del sistema. La respuesta a los eventos entrantes está lejos de ser óptima. Cuando se produce un evento independientemente de la tarea que se está ejecutando actualmente, debe esperar hasta que se ejecute la tarea adecuada antes de que se trate. Normalmente no se puede predecir qué tareas fallarán en una situación de sobrecarga, porque depende de qué tarea se está ejecutando cuando se produce el evento. No hay noción de criticidad o urgencia en este patrón todas las tareas son igualmente importantes.

Patrón Round Robin

DescripciónEl patrón Round Robin emplea una estrategia de planificación "justa" que puede ser apropiada para sistemas en los que es más importante progresar en todas las tareas que cumplir con plazos específicos.ClasificaciónPatrón de Concurrencia. ProblemaEl patrón Round Robin aborda la cuestión de mover un conjunto completo de tareas hacia adelante a velocidades más o menos iguales.ConsecuenciasEl Round Robin Pattern es “justo” ya que todas las tareas tienen la misma oportunidad de correr. Este patrón tiene una ventaja sobre el patrón de ejecución cíclica, en que una tarea no detendrá todo el sistema ya el temporizador interrumpirá cada tarea cuando para realizar un cambio de tarea. Además no es óptimo en términos de respuesta a eventos entrantes e inestable en el sentido de que no se puede predecir qué tarea fallará en una situación de sobrecarga. Este patrón se comporta mejor que el cíclico con un número mayor de tareas aero

no tan bien como los patrones de preferencia basados en la prioridad. A medida que aumenta el número de subprocesos, el tiempo relativo que cada tarea obtiene durante un intervalo de tiempo se reduce. Se debe tener en cuenta que incluso si una tarea no tiene nada que hacer, obtiene una división de tiempo, y esto puede resultar en aún más pérdida de eficiencia.

Patrón de Prioridad Estática

DescripciónEl patrón de prioridad estática es el método más común para planificar en un sistema de tiempo real. Tiene las ventajas de ser simple y escalar bien a un gran número de tareas. ClasificaciónPatrón de Concurrencia. ProblemaLa manera más común de modelar el tiempo para sistemas de tiempo real es asignar un intervalo de tiempo límite, comenzando con un evento entrante o el inicio de la ejecución del hilo y finalizando con la invocación de terminación de la tarea. Es una estrategia común de simplificación y permite que los sistemas pueden ser fácilmente analizados para la planificación, cuando la prioridad de las tareas también sea conocido.ConsecuenciasEste patrón representa un enfoque común para que los subprocesos de tareas interactúen con un planificador. Este patrón se puede ajustar para utilizar diferentes enfoques de planificación.En este patrón, las prioridades se asignan en el momento del diseño. Esto significa que el sistema en ejecución no puede reasignar dinámicamente prioridades en respuesta a condiciones cambiantes. Para la mayoría de los sistemas, esto es adecuado porque se cuida que el sistema esté programado en las peores condiciones. Sin embargo, esto limita la escalabilidad. Las prioridades estáticas pueden aplicarse a todos los tamaños de sistemas donde el ambiente y la respuesta del sistema deseada es altamente predecible.

Patrón de Prioridad Dinámica

DescripciónEl patrón de prioridad dinámica es similar al patrón de prioridad estática, excepto que actualiza automáticamente la prioridad de las tareas a medida que se ejecutan para reflejar condiciones cambiantes. ClasificaciónPatrón de Concurrencia. ProblemaPara sistemas de tiempo real pequeños, las permutaciones de las tareas que se ejecutan son conocidas y las tareas son estables. Los plazos son consistentes desde una invocación hasta la próxima invocación, y su tiempo de ejecución es aproximadamente similar. Esto simplifica el análisis lo suficientemente como para permitir el cálculo de la planificación del sistema en términos absolutos. En un sistema complejo, como los sistemas multitarea totalmente

simétricos, en los que la asignación de una tarea a un procesador no se conoce hasta el momento de la ejecución, este análisis es difícil o imposible. ConsecuenciasLa programación de prioridad dinámica es óptima pero no estable. La inestabilidad está vinculada a que no se puede predecir a priori qué tareas fallarán en una situación de sobrecarga.El patrón de prioridad dinámica se adapta bien a un gran número de hilos bajo condiciones que desafían la asignación estática.

Patrón de Memoria Compartida

DescripciónEl patrón de memoria compartida utiliza un área de memoria común direccionable por varios procesadores como medio para enviar mensajes y compartir datos. ClasificaciónPatrón de Distribución.ProblemaMuchos sistemas tienen que compartir datos entre varios procesadores, esta es la esencia de la distribución. En algunos casos, el acceso a los datos puede persistir durante un largo período de tiempo y la cantidad de datos compartidos puede ser grande. En tales casos, el envío de mensajes puede ser un método ineficaz para compartir dicha información. Es posible que varios equipos necesiten actualizar estos datos "globales", como en una base de datos compartida, o que sólo tengan que leerlos, como ocurre con el código ejecutable que puede ejecutarse en muchos procesadores o tablas de configuración. Es necesario disponer de un medio para compartir esos datos.ConsecuenciasEsta solución requiere el uso de memoria especializada. Los patrones funcionan bien cuando hay una cantidad relativamente grande de datos que deben estar disponibles persistentemente para varios procesadores. Dado que los datos se almacenan en un espacio globalmente accesible, pueden leerse y escribirse con la frecuencia necesaria con un overhead bajo. Debido a que los clientes sondean la memoria compartida para ver cuándo hay nuevos datos para ellos, este patrón puede no resultar en una entrega oportuna de mensajes.

Llamada de Procedimiento Remoto

DescripciónLas llamadas de procedimiento remoto (RPC) son un método común para invocar servicios de forma sincrónica entre procesadores. El equivalente orientado a objetos, llamada de método remoto (RMC), funciona de la misma manera. El cliente invoca un servicio en el servidor y espera en una condición bloqueada hasta que se complete la operación llamada.Clasificación

Patrón de Distribución.ProblemaSe necesita un media para hacer llamadas cuando el cliente y el servidor no están ubicados en el mismo equipo.ConsecuenciasLos RMC simplifican el proceso de comunicación cliente-servidor a través de una red. La escritura de los clientes y servidores se simplifica en gran medida aunque las porciones de código son específicas del protocolo. Por supuesto, la sincronización se retrasa sobre las llamadas locales debido a la necesidad de traducir en formato de datos de red y debido a retrasos en la red. Además, se puede requerir un manejo de errores más elaborado porque la infraestructura de red es inherentemente menos confiable que las llamadas locales. Si la velocidad de respuesta o la fiabilidad de la finalización del servicio es importante, entonces el protocolo de transporte subyacente debe seleccionarse teniendo en cuenta esos requisitos.

Patrón Observador

DescripciónEl patrón de Observador es quizás más de un diseño mecanicista que un patrón de diseñoarquitectónico. Sin embargo, servirá como base para otros patrones de arquitectura de colaboración de distribución. El patrón Observer (Conocido como "Publicación-Suscripción") aborda el problema específico de cómo notificar a un conjunto de clientes de manera oportuna que un valor que les interesa ha cambiado, especialmente cuando el proceso de notificación debe repetirse durante un período relativamente largo de tiempo.ClasificaciónPatrón de Distribución.ProblemaEl problema abordado por el patrón Observador es cómo notificar a un número determinado de clientes de manera oportuna valores de datos de acuerdo con alguna política abstracta, como "cuándo cambia", "cada cierto tiempo", etc. Un enfoque es que cada cliente consulte el valor de los datos, pero esto puede ser un desperdicio computacional, especialmente cuando un cliente desea ser notificado sólo cuando cambia el valor de los datos. ConsecuenciasEl patrón Observador simplifica el proceso de administración del uso compartido de valores entre un solo servidor con posiblemente muchos clientes. La simplificación se produce de varias maneras. En primer lugar, el patrón Observador tiene flexibilidad de tiempo de ejecución. Es fácil cambiar en tiempo de ejecución el número de suscriptores, así como la identidad de los suscriptores, porque el sujeto abstracto no se necesita tener ninguna información sobre sus clientes antes de su suscripción. Además, toda la información que el sujeto abstracto necesita puede ser proporcionada por los clientes durante el proceso de suscripción. En segundo lugar, una sola política para la actualización oportuna o eficiente de los clientes se puede centralizar en el servidor y no se replican en los potencialmente muchos clientes. Esto significa que el código que implementa la política de notificación debe estar

ejecutándose en un solo lugar (el servidor) en lugar de muchos lugares (los clientes individuales).

Bus de Datos

DescripciónEl Patrón de Bus de Datos abstrae el Patrón Observador proporcionando un bus común (lógico) al cual varios servidores publican su información y donde varios clientes van para obtener varios eventos y datos publicados. Este patrón es útil cuando un gran número de servidores y clientes deben compartir datos y eventos.

ClasificaciónPatrón de Distribución.ProblemaMuchos sistemas necesitan compartir muchos datos diferentes entre servidores y clientes, algunos de los cuales podrían no ser conocidos cuando se diseñó el cliente o los datos. Este patrón resuelve el problema proporcionando un almacenamiento central en el que los datos que se van a compartir pueden ser conectados junto con los metadatos que describen su contenido.ConsecuenciasEl Patrón de Bus de Datos tiene la ventaja de que siempre hay una única ubicación para que los clientes adquieran los datos necesarios y también para que los servidores publiquen sus datos. El Bus de Datos no entiende la semántica de los datos que sirve a los clientes, pero puede manejar un conjunto arbitrariamente grande de diferentes objetos y tipos de datos. El Bus de Datos es muy extensible y se pueden agregar nuevos tipos de objetos de datos incluso en tiempo de ejecución sin modificación del Bus de Datos y sus clases estrechamente relacionadas. La ubicación del bus de datos, o al menos el conocimiento de cómo enviar mensajes, debe conocerse en el momento del diseño. El tráfico requerido para administrar toda la información contenida por el Bus de Datos puede limitar la capacidad de ese nodo para realizar otro trabajo.

Proxy

DescripciónEl Patrón Proxy abstrae el verdadero servidor del cliente mediante una clase sustituta que proporciona una separación de un cliente y un servidor, permitiendo ocultar las propiedades especificadas en el servidor de los clientes.ClasificaciónPatrón de Distribución.Problema

El diseño de sistemas embebidos modernos debe ser desplegado a menudo a través de múltiples espacios de direcciones, tales como diferentes procesadores. A menudo estos detalles están sujetos a cambios durante el proceso de diseño o, peor aún, durante la implementación del sistema. Es problemático "codificar" el conocimiento de que un servidor puede ser remoto, ya que esto puede cambiar muchas veces a medida que avanza el diseño. Además, los clientes y servidores pueden reasignarse en otras arquitecturas físicas y utilizar diferentes medios de comunicación. Si los clientes son íntimamente conscientes de estos detalles de diseño el transporte de los clientes a las nuevas plataformas es más difícil. Los dos principales problemas abordados por el Patrón Proxy son la transparencia de la potencial lejanía de los servidores y el ocultamiento y encapsulación de los medios por los cuales contactar a tales servidores remotos.ConsecuenciasEl Patrón de Proxy hace un buen trabajo en aislar al cliente del conocimiento que el servidor puede ser remoto. La ventaja es que los clientes son simplificados, no teniendo que tratar de forma diferente con los clientes remotos y locales. El Patrón de Proxy también encapsula el conocimiento de cómo contactar a los servidores en las clases de proxy de modo que si los medios de comunicación cambian, menos clases deben ser actualizadas. Debido a que normalmente hay muchas menos instancias cliente-proxy (una por tipo de datos por espacio de dirección) que las instancias de cliente, se minimiza el tráfico en los medios de comunicación. Se envía un mensaje a través del bus o de la red para cada proxy, en lugar de uno por cliente. Esto reduce el tráfico de bus, un cuello de botella común en los sistemas embebidos y de tiempo real. El tráfico de los buses se reduce aún más debido al uso de una política de suscripción, se transmiten los datos sólo cuando es necesario, en contraposición al sondeo de los datos.

Broker

DescripciónEl Patrón Broker puede ser considerado como una versión simétrica del Patrón Proxy, es decir, proporciona un Patrón Proxy en situaciones donde la ubicación de los clientes y servidores no se conocen en tiempo de diseño.ClasificaciónPatrón de Concurrencia. ProblemaAdemás de los problemas abordados por el Patrón Proxy (como la transparencia de la infraestructura de comunicación), una limitación de la mayoría de los patrones de distribución es que requieren un conocimiento a priori de la ubicación de los servidores. Esto limita su uso a arquitecturas de distribución asimétrica.Idealmente, la solución debe proporcionar un medio que pueda localizar y luego invocar servicios a petición del cliente, incluida la suscripción a los datos publicados.Consecuencias

El Patrón Broker es un medio muy efectivo para ocultar la lejanía de clientes y servidores. Aunque no es completamente exitoso en ocultar todos los detalles, simplifica enormemente la creación de sistemas con arquitecturas de distribución simétrica. Hay una serie de productos de middleware que proporciona ORB (Object Request Brokers), que dan buen rendimiento, incluso en tiempo real. Además, los sistemas construidos con esta arquitectura de distribución son altamente escalables y ocultan los detalles subyacentes de los procesadores, sus ubicaciones y los medios de comunicación.

Patrón de Canal Único Protegido

DescripciónEl patrón de canal único protegido es un estrategia simple para obtener cierta seguridad y confiabilidad mediante la adición de controles y acciones adicionales. Posiblemente también será necesario un cierto nivel de hardware redundante.ClasificaciónPatrón de Seguridad y Fiabilidad. ProblemaConsiderando que la redundancia es costosa y que los requisitos de seguridad y fiabilidad de algunos sistemas pueden no ser tan críticos como con otros, se necesitan medios para mejorar la seguridad y la fiabilidad con poco esfuerzo y costo.ConsecuenciasEl patrón de canal único protegido es un medio simple para proporcionar cierto nivel de seguridad y fiabilidad en presencia de fallos sistemáticos o aleatorios. Sólo puede continuar prestando servicios en presencia de fallas transitorias. El enfoque es poco costoso tanto hardware como en costos de desarrollo, porque sólo partes del canal son redundantes.Este patrón es apropiado para sistemas con un sistema a prueba de fallos o que no necesitan seguir funcionando en presencia de un fallo persistente o cuando el sistema es sensible al costo.

Patrón de Redundancia Homogénea

DescripciónEl patrón de redundancia homogénea es principalmente un patrón para mejorar la confiabilidad al ofrecer múltiples canales. Estos canales pueden operar en secuencia o en paralelo. ClasificaciónPatrón de Seguridad y Fiabilidad. ProblemaEl problema abordado por el patrón de redundancia homogénea es proporcionar protección contra fallos aleatorios en la ejecución del sistema y poder continuar proporcionando

funcionalidad en presencia de un fallo.En caso de fallo en el canal, el sistema debe ser capaz de detectar el fallo y cambiar al canal de respaldo.ConsecuenciasEl patrón de redundancia homogénea tiene una serie de ventajas. Es conceptualmente simple y fácil de diseñar y proporciona una buena cobertura para fallos aleatorios. Se obtiene un buen aislamiento de fallos y eliminar fallas comunes. El patrón se aplica cuando las fallas aleatorias se producen a una frecuencia significativamente mayor que las fallas sistemáticas, como en ambientes hostiles. También es útil para sistemas de seguridad crítica o de alta fiabilidad que deben seguir funcionando en presencia de fallas.Las desventajas del patrón son principalmente el mayor costo y la falta de cobertura parafallas sistemáticas. El costo está generado debido a que el hardware electrónico y mecánico debe duplicarse. El patrón ejecuta un solo canal y cambia a un canal de respaldo sólo cuando se detecta un fallo. Esto significa que el paso de cálculo se pierde cuando se detecta un fallo y se pierden los datos y el tiempo de recuperación para rehacer el cálculo debe tenerse en cuenta en situaciones de tiempo crítico.

Patrón Monitor-Actuator

DescripciónEn el Patrón Monitor-Actuador, posee un sensor independiente que observa en el canal de actuación buscando una indicación de que el sistema debe ser mandado a su estado a prueba de fallos.ClasificaciónPatrón de Seguridad y Fiabilidad. ProblemaEl Patrón Monitor-Actuador aborda el problema de mejorar la seguridad en un sistema con requisitos de disponibilidad moderados a un bajo costo.ConsecuenciasEste patrón es una solución de seguridad de bajo costo que es aplicable cuando el sistema no tiene requisitos de alta disponibilidad y cuando hay un estado a prueba de fallos. Suponiendo que su implementación aísle correctamente las fallas, un fallo en el Canal de Actuación será identificado por el Canal de Monitoreo. Un fallo en el Canal de Monitoreo no afectará la correcta ejecución del Canal de Actuación. Debido a que existe una redundancia mínima, el sistema no puede continuar funcionando cuando se identifica un fallo.

Patrón de Vigilancia

DescripciónEl Patrón de Vigilancia es similar al Patrón de que es ligero y de bajo costo de implementación. El patrón de vigilancia comprueba que el procesamiento computacional interno continúa como se esperaba. Esto significa que su cobertura es mínima, y no se detectará un amplio conjunto de fallas. Por otro lado, es un patrón que puede agregar seguridad adicional cuando se combina con otros patrones más robustos.

ClasificaciónPatrón de Seguridad y Fiabilidad. ProblemaEn los Sistemas de Tiempo Real los cálculos tienen un plazo por el cual deben ser aplicados. Si el cálculo se produce después de ese plazo, el resultado puede ser erróneo o irrelevante.ConsecuenciasEs un patrón de baja cobertura por lo que rara vez se usa solo en sistemas de seguridad crítica. Identifica fallas de la base de tiempo y también se puede utilizar para detectar un interbloqueo en el canal de accionamiento. Puede combinarse con cualquiera de los otros patrones de seguridad enumerados con anterioridad.

Patrón de Ejecución de Seguridad

DescripciónEl control de las medidas de seguridad de un sistema puede ser muy complejo. Esto puede deberse a que el sistema no puede ser simplemente apagado, sino que debe ser conducido a través de una secuencia potencialmente compleja de acciones a un estado de prueba de fallos. Este Patrón provee un mecanismo para supervisar la coordinación de potenciales múltiples canales cuando las medidas de seguridad deben ser aplicadas activamente.ClasificaciónPatrón de Seguridad y Fiabilidad. ProblemaEl problema abordado por el Patrón de Ejecución de Seguridad es proporcionar un medio para coordinar y controlar la ejecución de medidas de seguridad cuando las medidas de seguridad son complejas.ConsecuenciasEste es un patrón complejo para implementar con muchos componentes para diseñar. Por lo tanto usualmente se usa en sistemas que son complejos y altamente críticos para la seguridad, especialmente cuando el manejo de fallas es muy complejo.

Introducción a IoT

Internet de las Cosas (IoT) es un fenómeno que llegó para cambiar la forma en la que percibimos las “cosas” y nos acerca nuevos desafíos.

El avance de la tecnología nos lleva a una sociedad donde todo y todos estaremos conectados, donde IoT conecta el mundo real físico con el mundo virtual.

El número de dispositivos que se conectan a Internet crece día a día en gran número. La mayoría de los dispositivos móviles tienen sensores que nos permiten recolectar diferentes tipos de datos y procesarlos para luego poder tomar decisiones acertadas, transmitiendo la información generada a Internet para ser compartida.

De esta manera podemos comprender que IoT se trata de dispositivos, sensores, redes de datos, procesamiento que interactúan entre sí para generar información que se utilizará para tomar acciones y decisiones, dónde la nube puede ser su lugar de interacción y de almacenamiento.

Estos dispositivos tienen diferentes tamaños, capacidades, nivel de procesamiento y soportan diferentes tipos de aplicaciones.

El avance de la tecnología nos permite dispositivos más potentes, que consumen menor energía y más pequeños, donde la conectividad es muchas veces directa a Internet.

A partir de lo enunciado anteriormente podemos inferir que IoT presenta desafíos arquitectónicos profundos para que esta conjunción de elementos pueda interactuar en forma confiable y segura.

Es por ello que nos centraremos en los desafíos arquitectónicos a partir de los drivers de calidad que debe perseguir.

Arquitectura IoT

Una arquitectura inicial IoT se basa en tres simples capas (Figura 4). Esta Arquitectura presenta un flujo simple que describiremos a continuación:

1) El dispositivo obtiene un valor de una variable física, lo convierte y lo transmite a un dispositivo de capa superior. Este valor puede estar asociado a una temperatura, humedad, presión, posición, movimiento, vibración o aceleración dependiendo del tipo de sensor. Un dispositivo con una combinación de diferentes sensores permite mayor cobertura.

2) El dispositivo que recibe el valor lo procesa y dispara una acción si es necesario. Este dispositivo envía esta información (valor y acción) a la capa superior.

3) El dispositivo de capa superior brinda servicios al usuario final. Estos servicios brindan el estado del sistema y el resultado de acciones que fueron invocadas por el usuario.

Figura 4 - Arquitectura IoT Inicial

A partir de este simple flujo podemos comprender los diferentes niveles que tiene un sistema de IoT y la responsabilidad asociada a cada uno. Podemos también comprender que la comunicación entre los niveles toma un nivel preponderante para el éxito de este tipo de sistemas distribuidos. No importa que arquitectura pensemos, seguramente la comunicación esté apoyada en algún punto en la suite de protocolos TCP/IP que domina Internet desde sus inicios.Si repasamos lo definido hasta el momento podemos inferir que IoT se enmarca dentro de los Sistemas de Tiempo Real (RTS), ya que es un sistema que interactúa con su entorno físico y da una respuesta en un tiempo determinado.Luego que comprendimos la arquitectura inicial, el flujo de datos que esta conlleva y su vínculo con los RTS podemos pensar en una arquitectura más general para IoT.Esta arquitectura está dividida en cinco capas (Figura 5).

Figura 5 - Arquitectura IoT - Modelo de Cinco Capas

Estas capas serán enumeradas y descriptas a continuación:

Capa de DispositivoConsiste de los dispositivos físicos y los sensores asociados a cada uno. Dependiendo el tipo de sensor el valor puede estar asociado a una temperatura, humedad, presión, posición, movimiento, vibración, aceleración. Los valores son enviados a la capa de Red para asegurar su correcta transmisión.

Capa de RedEsta capa transmite en forma segura los datos desde los sensores a la capa de procesamiento para obtener información. El medio puede ser cableado o inalámbrico, utilizando estándares como Ethernet, 3G, 4G, WiFi, Bluetooth, infrarrojo, Bluetooth LE, LPWAN, 6LoWPAN, infrarrojo dependiendo de las características del dispositivo.

Capa de MiddlewareCada dispositivo de IoT está pensando para un fin diferente por lo que se debe conectar un servicio específico para ese fin. Este servicio procesará los valores recibidos y los almacenará mediante alguna estrategia de persistencia.

Capa de AplicaciónEsta capa se basa en la información generada en la capa anterior y es la encargada de interactuar con el usuario final a partir de diferentes plataformas. La aplicación será generada con un propósito específico, por ejemplo salud, seguridad, entretenimiento.

Capa de NegociosEs la capa de nivel superior que se nutre de la información generada en las diferentes aplicaciones y permite entender el comportamiento de los usuarios para generar nuevos modelos de negocios y mejorar los existentes.

Drivers de Calidad de IoT

La arquitectura IoT propuesta presenta diferentes desafíos. Para analizarlos debemos definir cuáles son los drivers de calidad que persigue IoT. Un driver de calidad es un atributo relevante para cumplir los objetivos establecidos para el sistema. Esta relevancia puede estar dada por el negocio o por la complejidad técnica que representa su implementación.

Los atributos de calidad que deben contemplarse en una arquitectura para IoT son los siguientes:

● Confiabilidad● Eficiencia● Escalabilidad● Interoperabilidad● Mantenibilidad● Performance● Seguridad● Usabilidad

Como podemos ver estamos enumerando un gran número de atributos, pero si pensamos en eliminar alguno de ello por considerarlo menos importante no sabríamos por cual comenzar. La priorización de los drivers es un factor importante a la hora de definir la arquitectura de un sistema por lo que luego de especificar los mismos los llevaremos a un árbol de utilidad.

A continuación desarrollaremos brevemente uno a uno mostrando el motivo de su importancia y en qué capa de las antes mencionadas debería contemplarse.

Confiabilidad Los dispositivos vinculados a IoT deben ser autosuficientes por lo que la confiabilidad es un factor predominante. Esta capacidad debe presentarse a lo largo de todo el modelo de capas. En la capa inferior los dispositivos deben tener la capacidad de recuperarse ante fallos y no generar inconvenientes severos en el sistema. En las capas superiores se puede pensar en utilizar mecanismos existentes, como utilizar TCP en la capa de Red y clusters de alta disponibilidad en la capa de Middleware. Si bien disponibilidad y confiabilidad no son lo mismo, siempre es importante que el sistema esté disponible y que ante un fallo la recuperación sea inmediata y sin pérdida de datos (confiabilidad).

EficienciaEste atributo de calidad se debe dar haciendo hincapié en lo energético. Los avances tecnológicos nos permiten mismos niveles de procesamiento a menor consumo de energía. Esto además debemos reforzarlo desde los estándares y protocolos de comunicación. Desde el software debemos analizar los módulos que permanecerán activos y con qué periodicidad se activarán.

EscalabilidadEs una cualidad que siempre se espera de algo que se piensa que puede crecer en forma exponencial. Si todos los dispositivos tienden a conectarse en forma directa a Internet el direccionamiento con IPv6 nos acerca una solución escalable. Recordemos que IPv6 soporta 2128 direcciones, siendo un total de 340 sextillones de direcciones IP. Esto nos asegura parte de la escalabilidad en la capa de Red. Debemos comprender que la escalabilidad en la capa de Red dependerá del patrón de comunicación que se seleccione entre los dispositivos. También debemos comprender que IoT generará grandes volúmenes de datos que serán necesarios en la capa de Negocio para la toma de decisiones, por lo que IoT estará estrechamente vinculado con BigData.

InteroperabilidadLos sistemas deben tener la capacidad de integrarse por lo que IoT tiene el desafío de la estandarización de mensajes y protocolos para que los dispositivos de diferentes fabricantes puedan convivir en un mismo mundo. Esta capacidad se puede abordar en la capa de Red pensando en protocolos estándares (MQTT, CoAP) o bien en la capa superior dónde la integración será a un nivel mayor. Esta decisión es clave ya que cuanto más alto sea el nivel de integración mayor son los tiempos de latencia entre dispositivos.

MantenibilidadEste atributo es vital en todas las capas, pero en muchas de ellas los estándares y la ingeniería de software establece métricas y metodologías apropiadas, pero debemos analizar que sucede a nivel dispositivo. Se debe contemplar cómo se actualizará el software (firmware) de esos dispositivos, para la disminución de errores, aceptación de nuevos estándares, agregado de nuevas funcionalidades sea de una manera dinámica y garantizando el funcionamiento de los dispositivos.

SeguridadEl número de dispositivos creciente distribuidos, tiende a generar nuevas puertas de acceso a intrusos. Esto puede generar daños físicos, fallos en el sistema o comportamientos no esperados. La intrusión y la seguridad no son tópicos específicos de IoT pero cuando juntamos el mundo real (físico) y el virtual debemos tener aún más cuidado. Se debe trabajar con la seguridad desde la primera capa del modelo, siempre considerando que técnicas como encriptación generan un mayor procesamiento (pérdida de performance) y un mayor consumo de energía (pérdida de eficiencia energética). La seguridad siempre entra en conflicto con atributos como performance, eficiencia y usabilidad es por ello que se debe encontrar un equilibrio entre ellos.

PerformanceEste atributo recorre todas las capas pero tenemos que verlo asociado cuando pensamos al IoT como un RTS. El tiempo de respuesta puede ser de importancia por ejemplo al tratar de abrir un portón desde un dispositivo móvil, si el tiempo es mayor el esperado por el usuario

carece de practicidad. Esta necesidad entra en conflicto con la seguridad como mencionamos anteriormente.

UsabilidadSi bien este término se relaciona con la facilidad de usar el sistema y pensaríamos vincularlo solamente con la capa de Aplicación, tenemos que considerar también en la facilidad de configuración de los dispositivos, por lo que la solución debe ser integral. Se debe enfocar a que la inclusión de nuevos dispositivos a un sistema IoT sea simple, esto permitirá desarrollar el negocio de una manera más rápida.

Árbol de Utilidad de IoTA continuación se presentará un árbol de utilidad (Figura 6), donde podemos ver como ramas los drivers de calidad de IOT y como hojas los escenarios a resolver.

Figura 6. Árbol de Utilidad de un Sistema IoT

Análisis de Patrones RTS en IoT

Luego de haber seleccionado una serie de Patrones para el análisis y comprender los desafíos arquitectónicos de IoT, debemos comprender cómo se comportan los mismos en los escenarios de IoT. Para ello se analizará cómo se vincula cada Patrón con los Drivers de Calidad antes enumerados.

Arquitectura en CapasPermite pensar la Arquitectura IoT en capas con diferentes niveles de abstracción favoreciendo la mantenibilidad y la flexibilidad de la solución. Además con adecuados niveles de separación de responsabilidades puede garantizar buena interoperabilidad. Como desventaja debemos considerar la pérdida de performance si el número de capas es elevado.

Arquitectura en 5 capasEs un caso particular del anterior, donde la cantidad de capas es adecuado y es con el cual se ha definido la arquitectura lógica de IoT con anterioridad.

MicrokernelSe lo debe vincular a la capa de dispositivo con el fin de tener servicios activos e inactivos según la necesidad y en la búsqueda de la eficiencia energética.

Arquitectura de CanalSe lo debe vincular a la posibilidad de mejorar la disponibilidad a partir de la redundancia de componentes en la capa de dispositivo.

Máquina VirtualPermite reducir costos de Hardware en capa de middleware o superior. No es recomendable para capa de dispositivo ya que se genera un mayor uso de recursos de procesamiento, de energía y pérdida de performance.

Arquitectura Basada en ComponentesPermite pensar la Arquitectura IoT en componentes con diferentes responsabilidades favoreciendo la mantenibilidad y la flexibilidad de la solución. Además con adecuados niveles de separación de responsabilidades puede garantizar buena interoperabilidad en capas superiores.

Patrón de Cola de MensajesPermite conectar dos componentes o dispositivos a través de una comunicación asincrónica. Se debe considerar para la capa de middleware o superior. En capas inferiores puede requerir un mayor procesamiento y un espacio de almacenamiento de intermedio no disponible a esos niveles.

Patrón de InterrupciónSe lo debe vincular principalmente a la capa de dispositivo para la adquisición de señales de sensores o dispositivos de entrada por el usuario, por ejemplo un teclado o un lector .

Patrón de Llamada ProtegidaPermite conectar dos componentes o dispositivos a través de una comunicación sincrónica. La respuesta es a tiempo pero se debe garantizar a través de algún mecanismo la integridad de los datos. Se lo debe considerar para la capa de dispositivo.

Patrón de Ejecución CíclicaSe lo debe vincular principalmente a la capa de dispositivo para la ejecución de rutinas simples y con un flujo principal único.

Patrón Round RobinSe lo debe vincular principalmente a la capa de dispositivo para desarrollar un planificador simple que ejecute todas las rutinas con la misma prioridad y asegure que todas se ejecuten.

Patrón de Prioridad EstáticaSe lo debe vincular principalmente a la capa de dispositivo para desarrollar un planificador ejecuta las rutinas o procesos con una prioridad y asegure una correcta priorización de tareas.

Patrón de Prioridad DinámicaSe lo debe vincular principalmente a la capa de dispositivo para desarrollar un planificador ejecuta las rutinas o procesos con una prioridad que cambia según necesidad y asegure una correcta priorización de tareas.

Patrón de Memoria CompartidaSe lo debe vincular a la capa de dispositivo como estrategia de compartir datos entre los diferentes procesadores que pueda tener la solución a nivel hardware. También se debe pensar en cómo compartir datos en la capa de middleware, seguramente aplicando algún patrón que surge a partir de este.

Llamada de Procedimiento RemotoEs una estrategia para vincular dispositivo y la capa de middleware a través de la capa de red. Se debe considerar la latencia de la red, la posibilidad de pérdida de respuestas y el procesamiento que genera en la capa de dispositivo. Este Patrón favorece la interoperabilidad de la solución. Puede entrar en conflicto con la eficiencia energética si es necesario aplicar cuestiones de seguridad por parte de la capa del dispositivo y puede aumentar el consumo de ancho de banda dependiendo del protocolo y los mensajes a intercambiar.

Patrón ObservadorSe lo debe vincular con la capa de dispositivo y la capa de middleware. En la capa de dispositivo orientado al vínculo de sensores y actuadores. En la capa de middleware vinculando la capa de dispositivo con la capa de aplicación. Es una estrategia simple que

favorece la interoperabilidad y puede escalar. Elimina la necesidad de consultar continuamente cambios por lo que favorece la eficiencia energética y eficiencia en el uso de ancho de banda.

Bus de DatosSe lo debe vincular con la capa de dispositivo y la capa de middleware. Lo podemos considerar una estrategia para escalar el observador a través de un bus común de datos. Esto brinda interoperabilidad y extensibilidad ya que el bus puede soportar tipos de datos heterogéneos.

ProxySe lo debe vincular con la capa de dispositivo y la capa de middleware. Lo podemos considerar una estrategia para simplificar el desarrollo y mejorar la mantenibilidad de la solución. Además favorece la escalabilidad y la eficiencia en el ancho de banda.

BrokerEstá relacionado con el Proxy con la diferencia que genera una arquitectura simétrica. Favorece la escalabilidad, la interoperabilidad y performance (tiempo de respuesta).

Patrón de Canal Único ProtegidoSe lo debe vincular con la capa de dispositivo brindando seguridad y fiabilidad a un costo de hardware y desarrollo razonable. No permite la continuidad de uso pero si la detección de fallas y las posibles consecuencias.

Patrón de Redundancia HomogéneaSe lo debe vincular con la capa de dispositivo brindando seguridad y fiabilidad a un costo de hardware y desarrollo mayor que el patrón anterior. Permite la continuidad de uso a partir de cambiar de canal al de respaldo, garantiza disponibilidad pero puede perder datos durante el proceso de cambio.

Patrón Monitor-ActuatorSe lo debe vincular con la capa de dispositivo brindando seguridad a un costo de hardware y desarrollo bajo. En caso de detección de fallo pasa al sistema a modo prueba de fallos y el sistema no puede continuar funcionando.

Patrón de VigilanciaSe lo debe vincular con la capa de dispositivo brindando seguridad y fiabilidad a un costo de desarrollo bajo, para recuperación automática en caso de falla (confiabilidad).

Patrón de Ejecución de Seguridad

Se lo debe vincular con la capa de dispositivo brindando seguridad y fiabilidad a un costo de desarrollo elevado. Es vital para sistemas que deben ir a una posición segura en caso de fallo, o determinar qué pasos se deben seguir luego de una detección de fallo.

En el siguiente cuadro veremos reflejados los atributos de calidad que se verán favorecidos y perjudicados a partir de la implementación de cada Patrón.

Patrón Atributos + Atributos -

Arquitectura en Capas MantenibilidadFlexibilidad

Performance

Arquitectura en 5 capas MantenibilidadFlexibilidad

Performance

Microkernel Eficiencia EnergéticaExtensibilidad

Simplicidad

Arquitectura de Canal Seguridad Simplicidad

Máquina Virtual Portabilidad Performance

Arquitectura Basada en Componentes

Extensibilidad Simplicidad

Patrón de Cola de Mensajes

Simplicidad PerformanceEficiencia

Patrón de Interrupción Simplicidad Confiabilidad

Patrón de Llamada Protegida

Performance Eficiencia Energética

Patrón de Ejecución Cíclica

Simplicidad Eficiencia Energética

Patrón Round Robin Simplicidad Extensibilidad

Patrón de Prioridad Estática

Simplicidad Escalabilidad

Patrón de Prioridad Dinámica

ExtensibilidadEscalabilidad

Simplicidad

Patrón de Memoria Compartida

Performance SimplicidadEficiencia Energética

Llamada de Procedimiento Remoto

Interoperabilidad ConfiabilidadPerformance

Patrón Observador InteroperabilidadEficiencia Energética

Escalabilidad

Simplicidad

Bus de Datos InteroperabilidadEscalabilidadExtensibilidad

Performance

Proxy InteroperabilidadSimplicidad

PerformanceEficiencia EnergéticaEficiencia Ancho de Banda

Broker InteroperabilidadSimplicidadEscalabilidad

PerformanceEficiencia EnergéticaEficiencia Ancho de Banda

Patrón de Canal Único Protegido

SeguridadSimplicidad

Confiabilidad

Patrón de Redundancia Homogénea

SeguridadConfiabilidad

Simplicidad

Patrón Monitor-Actuator SeguridadSimplicidad

Confiabilidad

Patrón de Vigilancia DisponibilidadSimplicidad

ConfiabilidadSeguridad

Patrón de Ejecución de Seguridad

SeguridadConfiabilidad

Simplicidad

Patrones de Distribución en IoT

Luego de haber analizado los patrones disponibles en los STR en el marco de IoT podemos comprender que el principal desafío está vinculado a la comunicación. La Arquitectura de un sistema IoT puede ver como un STR en las capas inferiores y como un sistema de información en las capas superiores. Nuestro desafío es conectar estos dos mundos a través de los Patrones de Distribución. Es por ello que analizaremos los mismos con un enfoque práctico, vinculando los patrones con protocolos y estándares existentes que los implementan.

Solicitud / Respuesta

Solicitud/Respuesta es quizás el patrón de distribución más conocido. Se compone de un cliente que solicita un servicio de un servidor (Figura 7). Este es el patrón que utiliza HTTP, y es la base para la arquitectura orientada a servicios, servicios web, y REST. Es un patrón útil, especialmente si se tiene una arquitectura cliente-servidor o maestro-esclavo. Otros protocolos que soportan este patrón son el Protocolo de Aplicación restringida (COAP) y el Protocolo extensible de Mensajería y Presencia extensible (XMPP).

Figura 7. Patrón Solicitud/Respuesta

Un inconveniente de este patrón es la desigualdad de los participantes, que también es evidente en la topología de Internet. La comunicación bidireccional, donde ambas partes solicitan la información el uno del otro, puede ser difícil, especialmente si los firewalls están presentes. Se debe definir quién es el cliente y el servidor. Si el sensor es el cliente y el middleware el servidor, el sensor puede reportar sus datos cuando elija, pero el middleware tendrá dificultades para ir a buscar la información cuando quiera. Si el sensor es el servidor y el middleware el cliente, el middleware puede recoger datos cuando es necesario, pero el sensor puede no estar protegido por un firewall, dejando que cualquiera se pueda conectar a él. Como consecuencia de ello, cualquiera de los eventos y las suscripciones a eventos o la seguridad es difícil de manejar y, a veces requieren servicios adicionales o recursos sustanciales si los firewalls son usados en la red (Figura 8).

Figura 8 - Dos Escenarios posibles en Solicitud/Respuesta

Suscripción de Eventos

El patrón de suscripción de eventos permite a un cliente suscribirse a eventos de un tipo determinado de un servidor. El servidor informa al cliente cada vez que se activa el evento, sin tener que consultar constantemente el servidor (Figura 9). Mecanismos de suscripción de eventos avanzados pueden incluir requisitos de específicos del cliente: cuando se desean eventos y en qué condiciones. Los beneficios de utilizar este patrón es que la mitad de los mensajes no son necesarios en el tiempo y la latencia de cambios se mantiene a un mínimo. Protocolos que soportan este modelo incluyen CoAP; XMPP; y la notificación de la arquitectura general de eventos, que es parte de la arquitectura universal Plug and Play, una versión extendida de HTTP.

Figura 9 - Patrón Subscripción de Eventos

Mensajería Asíncrona

La mensajería asíncrona es la capacidad de enviar un mensaje entre pares en una red. El patrón asume que los mensajes pueden viajar en ambas direcciones, y no hay ninguna diferencia jerárquica implícita entre los participantes (Figura 10). Si un protocolo compatible con el patrón de distribución asíncrona de mensajería, todos los otros patrones de distribución pueden ser construidos en la parte superior de la misma. Protocolos que soportan este patrón incluyen XMPP; Advanced Message Queuing Protocol (AMQP); y, en el nivel IP, el protocolo de datagramas de usuario (UDP), aunque este último protocolo podría tener problemas con los firewalls.

Figura 10. Patrón de Mensajería Asíncrona

Mensajería ConfiablePara aplicaciones críticas, es importante saber que un mensaje ha sido entregado exactamente una vez en el destino, y el patrón de distribución asíncrona de mensajería hace precisamente eso. El mensaje puede perderse en el camino, pero utilizando el patrón de solicitud/ respuesta, puede intentar enviar el mensaje hasta que un acuse de recibo (o respuesta) se devuelve desde el destino. Debido a que tanto el mensaje y su respuesta se pueden perder, este método se asegura de que el mensaje se entrega al menos una vez a su destino, sino a lo sumo una vez, o al menos una vez- no es suficientemente buena para algunas aplicaciones, tales como las que requieren transacciones o los que hacen conteo. La mensajería confiable es una manera de asegurar que un mensaje se entrega exactamente una vez a su destino. Los protocolos que admiten mensajería confiable incluyen Message Queue Telemetry Transport (MQTT), AMQP, y through published open extensions-HTTP y XMPP.

MultidifusiónLos patrones anteriores se han preocupado por la comunicación entre dos entidades. A veces, sin embargo, un patrón más eficiente es necesario si la misma información se va a enviar a múltiples entidades, al mismo tiempo. El patrón de este tipo más simple es el patrón de multidifusión. En este caso, el emisor envía un mensaje a través de un intermediario (un broker), que a su vez lo distribuye a varios destinatarios que solicitaron participación en la comunicación (Figura 11). Este patrón ahorra ancho de banda porque el remitente no tiene que enviar mensajes individuales a todas las partes por sí mismo. De hecho, el remitente no tiene ni siquiera saber quiénes son los destinatarios.Este patrón puede ser útil en muchas formas-por ejemplo, cuando se sincronizan múltiples entidades o cuando se distribuye

información a muchos destinatarios. Los protocolos que soportan multidifusión incluyen XMPP, AMQP, y UDP.Una palabra de advertencia, sin embargo: Aunque puede utilizar este patrón para ahorrar ancho de banda, se utiliza a menudo como un medio para superar las restricciones en el protocolo elegido y apoya al patrón de evento de suscripción. Además, la multidifusión es inherentemente difícil de conseguir, y es más eficiente en términos de ancho de banda sólo si los destinatarios utilizan realmente la mayor parte de los valores transmitidos. Si utiliza la multidifusión frecuentemente para disminuir la latencia en una red donde se desea la suscripción de eventos pero no es posible, el patrón de multidifusión podría drásticamente aumentar en vez de disminuir el ancho de banda requerido.

Figura 11. Patrón de Multidifusión

Publicación / SuscripciónEl patrón de distribución de publicación / suscripción es una extensión del modelo de multidifusión, con la principal diferencia de que los mensajes transmitidos también se almacenan en el nodo intermediario. Los mensajes, o una referencia a los mensajes, se distribuyen a los suscriptos correspondientes, en función de protocolo. Sólo el último mensaje se almacena, un número determinado de mensajes se almacenan, o todos los mensajes se almacenan en el intermediario, según el protocolo elegido y la configuración del intermediario. La diferencia entre la distribución de todo el mensaje y la distribución de sólo una referencia a el mensaje es importante y afecta al rendimiento de la solución en términos de ancho de banda consumido. Si los suscriptores consumen la mayor parte de los mensajes, la transmisión de los mensajes en sí mismos es más eficiente, como en el caso de la multidifusión. Sin embargo, si el consumo se produce sólo a demanda, enviar referencias más cortas es más eficiente debido a que estos mensajes son más pequeños y los suscriptores utilizarán sólo una minoría de ellos para recuperar un mensaje real. Para buscar un mensaje

en el último caso, una acción de solicitud/ respuesta necesita ser realizado. Los protocolos que soportan el patrón de publicación / suscripción incluyen MQTT, AMQP, y XMPP.

ColasColas (primero en entrar, primero en salir) es un patrón de distribución que permite a una o más entidades enviar mensajes o elementos de trabajo a una cola, y luego permita a uno o más receptores recibir estos mensajes de una manera ordenada (Figura 12). Las colas normalmente residen en un nodo intermediario o red a la que están conectados todos los participantes. Las colas son una excelente herramienta para equilibrar la carga, donde los elementos de trabajo recogidos de varias fuentes se deben distribuir entre los trabajadores existentes, tal vez con un rendimiento diferente. Mediante el uso de una cola, se evita cualquier enlace físico entre los proveedores de datos y los trabajadores y por lo tanto se puede extender fácilmente o restringir tanto el conjunto de proveedores de datos como el conjunto de los trabajadores, dependiendo de la carga de trabajo real. Entre los protocolos sólo AMQP soporta colas de forma nativa.

Figura 12. Patrón de Cola de Mensajes.

Broker de MensajesComponentes de middleware esencialmente estandarizados, brokers de mensajes proporcionan una solución elegante al problema que los firewalls imponen a la distribución bidireccional entre pares en una red. Trabajan permitiendo a las entidades que se conecten a ellos, y luego mediar en los mensajes entre los clientes conectados. Debido a que todas las

conexiones se realizan desde los dispositivos hacia el broker, sólo el broker tiene que ser accesible desde Internet. Los firewalls no tienen que aceptar o reenviar conexiones entrantes a los dispositivos, como sería necesario si ha utilizado un protocolo estricto punto a punto.Además de los mensajes de intermediación, los brokers pueden proporcionar importantes servicios a entidades relacionadas, tales como actuar como intermediarios en la multidifusión, publicación / suscripción, y los patrones de colas. Los Brokers de mensajes también suelen proporcionar servicios de autenticación de clientes, algo que puede ser difícil para los dispositivos conectados en redes distribuidas. Por lo tanto, si el broker reenvía las identidades de las partes incluidas en la comunicación que ya están autenticadas, las entidades pueden utilizar esta información para tomar decisiones de seguridad sin la necesidad de implementar la autenticación personalizada en cada dispositivo. Aunque la comunicación punto a punto podría ser una opción para muchos, dicha solución ha de manejar la autenticación de cliente por sí misma para evitar ser inseguro. Si se utiliza un protocolo que incluye brokers de mensajes, puede que no necesite desarrollar su propio middleware para hacer andar la solución. Los protocolos que utilizan los brokers de alguna u otra forma incluyen XMPP, AMQP y MQTT.

FederaciónFederación es un patrón importante en el que una red global se divide en partes lógicas para permitir la escalabilidad global y el crecimiento orgánico (Figura 13). La clave aquí es permitir el crecimiento sin limitar el rendimiento de la red existente utilizando el enfoque divide y conquistarás. En la comunicación sin brokers, tales como HTTP o CoAP, la federación tiene lugar en el nivel de dominio. Cada dominio apunta a su propio conjunto de direcciones IP anfitrión de su propio servidor web. Se pueden añadir nuevos servidores web sobre los nuevos dominios sin limitar el acceso a los servidores web existentes. Esto ha sido un elemento clave para el éxito y la escalabilidad de la World Wide Web.Cuando se utiliza un protocolo de broker que soporta federación, los brokers se conectan entre sí para enrutar o retransmitir mensajes. Cada broker se encarga de la autenticación en su propio dominio y reconoce cómo conectarse a otros dominios para reenviar mensajes a ellos. El protocolo más conocido de brokers que soporta federación es el Protocolo simple de transferencia de correo (SMTP). Entre los protocolos de broker descritos en este artículo, sólo XMPP admite federación. Redes de brokers con federación proporcionan una manera elegante de atribuir una identidad global para cada entidad.

Figura 13. Patrón Federación.

DescubrimientoSurgen varios problemas en un escenario de distribución masiva. En primer lugar, las cosas no conocen bien la identidad de red ni la identidad del propietario en el momento de producción: Sólo conocen su identidad conceptual. Después de la instalación y configuración, que preferiblemente utiliza alguna técnica para lograr “cero configuración”, aprenden su nue