¿Cuáles son los elementos esenciales de los sistemas distribuidos en tiempo real?

Un sistema distribuido en tiempo real compone dos conjuntos desafiantes de propiedades que son impuestas por el dominio del problema o el dominio de la solución (o ambos.)

Distribuido

Un sistema distribuido enlaza una serie de entidades informáticas independientes con propiedades locales a través de un mecanismo de comunicación. Como consecuencia, los algoritmos y otros componentes de diseño deben tener en cuenta el sincroníay el modelo de falla . Un resumen útil (no totalmente objetivo) de las preocupaciones de la computación distribuida se incluye en las Ocho Falacias de la Computación Distribuida de Deutsch. (Ver esta útil exposición.) Todos estos son útiles para considerar en el diseño distribuido (en tiempo real); cada uno es un punto de partida para las preocupaciones esenciales de diseño e implementación:

1. La red es confiable
2. La latencia es cero
3. El ancho de banda es infinito
4. La red es segura
5. La topología no cambia
6. Hay un administrador
7. El coste del transporte es cero
8. La red es homogénea

En tiempo real

Un sistema en tiempo real es un sistema en el que la puntualidad de la finalización de la operación forma parte de los requisitos funcionales y la medida de corrección del sistema. (Abrí una pregunta aquí para tratar de aclarar esto.) En realidad, casi todos los sistemas podrían considerarse "blandos" en tiempo real, ya que por lo general hay requisitos/expectativas no expresados para la puntualidad de las operaciones. Reservamos el término en tiempo real, a veces calificado por suave o duro, para sistemas que son incorrectos cuando no se cumplen las restricciones de tiempo. Tenga en cuenta que muchas de las preocupaciones resumidas en las falacias anteriores se cruzan con la oportunidad. (Ver también el wiki de etiquetas en tiempo real )

Es útil tener en cuenta que RT los sistemas (y DRT) existen en un continuo de requisitos, con "deterministas" (o convencionalmente, tiempo real duro) en un extremo. Sin embargo, muchos sistemas tienen limitaciones de tiempo muy importantes que, sin embargo, no son deterministas. Especialmente en el contexto de los sistemas DRT, también es útil separar el concepto de actividad urgencia de actividad prioridad. En grandes sistemas donde la latencia y el fallo son factores reales y no triviales, la gestión explícita de recursos informáticos y de comunicación para efectuar la puntualidad y otros requisitos de diseño se vuelve más importante, y la separación de estas dos dimensiones se vuelve importante.

Componiendo Distribuido con Tiempo Real

• Requisitos explícitos de puntualidad-Cuáles son los requisitos, cómo se asignan a las actividades, son verdaderos requisitos de puntualidad trans-nodo, cómo se representarán explícitamente las limitaciones de tiempo en el diseño y las implementaciones, y cómo se ¿se detectarán, notificarán y recuperarán los fallos?
• Sincronización de tiempo - ¿Cuáles son los requisitos y mecanismos para lograr la sincronización de reloj? Wiki on clock synchronization; muchas aplicaciones requieren solo NTP; requisitos más estrictos pueden requerir hardware especial (por ejemplo, IRIG-B) o enfoques.
• Requisitos de sincronía - Cuáles son las suposiciones de sincronía que limitan y los requisitos para el sistema la sincronía? Esto está conectado a la sincronía del reloj, pero no es idéntico. Algunos pensamientos sobre modelos formales de Doug Jensen; wikipedia sobre Sistema Asíncrono y Síncrono; SO question on partial event ordering ;
• Patrones de diseño - ¿Cuáles son las partes móviles, y cómo se relacionan sobre el transporte? (En particular, ¿cómo afectan estas relaciones a la oportunidad?)
• Middleware - ¿Cómo vas a ¿codificar los aspectos distribuidos del sistema? Los ejemplos incluyen CORBA en tiempo real (aquí hay una buena página de OIS ) o DDS .
• Restricciones de tiempo - ¿Cómo va a documentar, medir y hacer cumplir las restricciones de tiempo en el sistema?
• Falla parcial - Un sistema en tiempo real normalmente tiene requisitos de confiabilidad. Uno de los aspectos únicos de los sistemas distribuidos es el potencial de clases enteras de fallas llamadas fallas" parciales", debido a fallos reales de bloqueo / comunicaciones o errores de puntualidad que deben tratarse como fallos. SO pregunta sobre enfoques de conmutación por error ;
• RTOS - ¿Qué sistema operativo en tiempo real se empleará?

Algunas referencias

Para una presentación bastante tradicional de los sistemas DRT, echa un vistazo a Kopetz' libro. Para una visión más dinámica, se recomienda el trabajo de Jensen y su sitio web. En el reino de Java, sugiero leer la excelente "Introducción a la Programación Distribuida Confiable". No aborda el ámbito completo de los problemas de puntualidad, pero aborda el fracaso parcial de una manera particularmente clara.

Recientemente, el concepto de detectores de fallas (no confiables) ha surgido como una construcción de sincronía útil, que permite un razonamiento teórico útil y técnicas prácticas de formulación/diseño/construcción para sistemas DRT. El documento seminal sobre el tema es Sobre el impacto de fast detectores de fallos en sistemas tolerantes a fallos en tiempo real, por Aguilera, Le Lann y Toueg. Este periódico es un trineo pesado, pero recompensa cada onza de inversión intelectual.