1 Replication management in Reliable Real-Time Systems Antonio La Torre De La Fuente

2 11/04/2005Replication management in Reliable Real-Time Systems2 Índice La arquitectura DEAR-COTS Introducción Principios básicos El subsistema HRTS Características Ejemplo de aplicación distribuida Object Repository HRTS Replica Manager Conclusiones

3 11/04/2005Replication management in Reliable Real-Time Systems3 Introducción Presentación de la arquitectura DEAR-COTS Arquitectura para el desarrollo de aplicaciones de tiempo real fiables usando componentes COTS (commercial off-the-shelf) Objetivo: proporcionar abstracción al programador sobre distribución y replicación

4 11/04/2005Replication management in Reliable Real-Time Systems4 Principios básicos Implementar tiempo real y tolerancia a fallos con HW no diseñado a tal efecto Ocultar los detalles de implementación subyacentes a la arquitectura Separar el ‘Hard real-time subsystem’ (HRTS) del ‘Soft real-time subsystem’ (SRTS) Las aplicaciones se desarrollan en dos fases: fase de programación y fase de configuración

5 11/04/2005Replication management in Reliable Real-Time Systems5 El subsistema HRTS Middleware entre las aplicaciones de tiempo real críticas y los componentes COTS Proporciona tolerancia a fallos en los componentes del sistema Soporta la replicación activa con conjuntos distintos de tareas replicadas en cada nodo

6 11/04/2005Replication management in Reliable Real-Time Systems6 El subsistema HRTS Los componentes son las unidades de replicación Consolidación de resultados sólo si son comunicados a otros componentes Necesidad de garantizar el determinismo de las réplicas (mismos datos y tomas de decisiones al mismo tiempo)

7 11/04/2005Replication management in Reliable Real-Time Systems7 El subsistema HRTS Dividido en dos capas: Communication manager Provee los mecanismos de comunicación para replicación, distribución y consolidación de datos Replica manager Soporta la ejecución de las aplicaciones distribuidas y es interfaz entre éstas y el “Communication manager” Proporciona un repositorio de objetos Objetos genéricos listos para ser usados en la aplicación

8 11/04/2005Replication management in Reliable Real-Time Systems8 Replica Manager El subsistema HRTS Communication manager Support Software Application in the HRTS Object repository Instantiated objects Application-level mechanisms Generic objects

9 11/04/2005Replication management in Reliable Real-Time Systems9 El subsistema HRTS Detección y recuperación de errores: tres enfoques diferentes Notificación a los niveles superiores del DCCS y no llevar a cabo ninguna otra acción Diseño de aplicaciones que realicen “apagado limpio” en caso de errores Mantenimiento del sistema en funcionamiento en modo degradado y cambio del componente erróneo Problema: amnesia de los nuevos componentes al ser añadidos

10 11/04/2005Replication management in Reliable Real-Time Systems10 El subsistema HRTS t1t1t1t1 t2t2t2t2 t3t3t3t3 t4t4t4t4 t1’t1’t1’t1’ t2’t2’t2’t2’ t4’t4’t4’t4’ t3’t3’t3’t3’ C1C1C1C1 C2C2C2C2 C2’C2’C2’C2’ C1’C1’C1’C1’ Ejemplo: Aplicación HRTS replicada

11 11/04/2005Replication management in Reliable Real-Time Systems11 Índice La arquitectura DEAR-COTS Object Repository Un ejemplo simple Interacción interna al componente Interacción entre grupos Interacción con el SRTS Interacción con el sistema a controlar Ejemplo de aplicación configurada HRTS Replica Manager Conclusiones

12 11/04/2005Replication management in Reliable Real-Time Systems12 Conjunto de objetos genéricos para ser instanciados por la aplicación Permite el reemplazo de objetos con la misma interfaz en la fase de configuración Abstrae de los mecanismos de replicación y distribución Facilita la modularidad de la aplicación Tres tipos fundamentales: Repositorio de objetos Shared data Release event Release event with data objects

13 11/04/2005Replication management in Reliable Real-Time Systems13 Un ejemplo simple Sensor Release Event With Data Controller Release Event Alarm Shared Data Actuator Release Wait Write Read Wait Release

14 11/04/2005Replication management in Reliable Real-Time Systems14 Interacción interna al componente No requiere consolidación de los resultados Cambios en los objetos para soportar la distribución y la replicación de componentes Release Event Objects y Release Event Object with Data Para soportar replicación se usa el Deterministic Release Event Object Para soportar distribución se usan dos objetos a modo de proxy: el Release Event Proxy Object y el Release Event Receive Object

15 11/04/2005Replication management in Reliable Real-Time Systems15 Interacción interna al componente Shared Data Object Para dar determinismo entre las réplicas se usa el Deterministic Shared Data Object (contiene un array de elementos junto con su tiempo de validez) Para soportar distribución nace el Distributed Shared Data Object (con cada write se disemina el valor del elemento a cada una de las réplicas de forma atómica) Para proporcionar ambas características a la vez aparece el Deterministic Distributed Shared Data Object

16 11/04/2005Replication management in Reliable Real-Time Systems16 Interacción entre grupos Se define grupo como un conjunto de componentes replicados Es necesario consolidar los valores de los datos intercambiados Para los Release Event Objects tenemos: Una tarea solicita el release y el Inter-Group Release Event Proxy Object reenvía la petición al Replica Manager Éste libera al conjunto de tareas que estaban esperando

17 11/04/2005Replication management in Reliable Real-Time Systems17 Interacción entre grupos Un caso particular: si la tarea que invoca el release no está replicada Para los Shared Data Objects: Necesidad de consolidar los valores escritos (write) Solución similar a la del Deterministic Distributed Shared Object Casos especiales: La tarea escritora no está replicada La tarea lectora no está replicada

18 11/04/2005Replication management in Reliable Real-Time Systems18 Interacción con el SRTS Debe soportar el intercambio de información entre ambos subsistemas Especial cuidado con el flujo de información en sentido SRTS -> HRTS Mecanismos de comunicación muy dependientes de la plataforma (Sistema operativo) Modelo genérico para la interconexión

19 11/04/2005Replication management in Reliable Real-Time Systems19 Interacción con el SRTS Instantiated Object Application Specific Operating System Specific HRTS SRTS Incoming Data

20 11/04/2005Replication management in Reliable Real-Time Systems20 Interacción con el sistema a controlar Realizada a través de sensores y mecanismos de respuesta a eventos Muy dependiente de la aplicación y la plataforma La ejecución de la respuesta puede realizarla una única tarea de todas las réplicas o consensuarse con algún mecanismo de voto

21 11/04/2005Replication management in Reliable Real-Time Systems21 Ejemplo de aplicación configurada En la fase de configuración se sustituyen los objetos genéricos por sus equivalentes para soportar replicación, distribución o determinismo Sólo es necesario cambiar la instanciación de los objetos porque tienen la misma interfaz Veamos el ejemplo anterior una vez configurado

22 11/04/2005Replication management in Reliable Real-Time Systems22 Ejemplo de aplicación configurada Sensor Release Event With Data Controller Release Event Alarm Shared Data Actuator Release Wait Write Read Wait Release Component C 1 Component C 2 Component C 3 Intra-component communication Inter-group communication

23 11/04/2005Replication management in Reliable Real-Time Systems23 Ejemplo de aplicación configurada Sensor Inter-group Release Event With Data Controller Deterministic Release Event Alarm Inter-group Shared Data Actuator Release Wait Write Read Wait Release Component C 1 Component C 2 Component C 3 Intra-component communication Inter-group communication

24 11/04/2005Replication management in Reliable Real-Time Systems24 Índice La arquitectura DEAR-COTS Object Repository HRTS Replica manager Property Recorder Module Replication Support Module Application Support Module Error Manager Module Conclusiones

25 11/04/2005Replication management in Reliable Real-Time Systems25 HRTS Replica Manager Da soporte a los recursos descritos anteriormente (4 módulos principales) Property recorder: base de datos del Replica Manager Replication support module: permite la interacción entre tareas replicadas Application support module: almacena los tiempos de las tareas periódicas Error manager module: registra los errores acontecidos en cada nodo

26 11/04/2005Replication management in Reliable Real-Time Systems26 HRTS Replica Manager Communication manager Application in the HRTS Application-level mechanisms Replication Support Property Recorder Application Support Error Manager Replica Manager

27 11/04/2005Replication management in Reliable Real-Time Systems27 Property Recorder Module Almacena toda la información necesaria para el funcionamiento de la replicación/distribución Diferenciamos dos tipos de información: Información de configuración de la aplicación (component structure, task info., network info.) Información de ejecución de la aplicación (tiempos de liberación de tareas, estado de componentes) Cada nodo almacena información local (el Replication Support Module es el encargado de transferir esta información a los nodos relacionados)

28 11/04/2005Replication management in Reliable Real-Time Systems28 Replication Support Module Es el núcleo de la capa de gestión de replicación (Replica Manager) Provee todos los mecanismos para la replicación y la distribución Asimismo, es el encargado de la interconexión con el subsistema de comunicación a través de la interfaz proporcionada por el Communication Manager

29 11/04/2005Replication management in Reliable Real-Time Systems29 Application Support Module Proporciona una interfaz para las aplicaciones periódicas, lanzadas por el sistema operativo Registra el instante en el que estas aplicaciones fueron lanzadas Controla la ejecución de estas tareas y las suspende/activa en función del estado de los componentes

30 11/04/2005Replication management in Reliable Real-Time Systems30 Error Manager Module Registra y, si es posible, notifica los errores ocurridos en la comunicación y consolidación de los datos Dos alternativas Comunicar el error a un gestor de errores propio a la aplicación Diseminar el error a través de todo el sistema Posibles errores Consolidación: valor no propuesto o erróneo Comunicación: error en la red (duplicados, etc.)

31 11/04/2005Replication management in Reliable Real-Time Systems31 Índice La arquitectura DEAR-COTS Object Repository HRTS Replica manager Conclusiones

32 11/04/2005Replication management in Reliable Real-Time Systems32 Conclusiones Diseño de aplicaciones de Tiempo Real distribuidas usando componentes COTS Alta fiabilidad de las aplicaciones Abstracción acerca de la distribución y la replicación Baja sobrecarga del sistema debida al uso de esta arquitectura (balance positivo)

33 11/04/2005Replication management in Reliable Real-Time Systems33 Referencias Replication Management in Reliable Real- Time Systems, L. M. Pinho, F. vasques, A. Wellings, Real-Time Systems, 26, 261-296, 2004. The Dear-Cots Web Site: http://dear- cots.di.fc.ul.pt/

34 Gracias por su atención ¿Alguna pregunta?