real-time - operativos - sistemas en tiempo real pdf

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

Me estoy poniendo de pie para contratar y hoy he tenido mi primera entrevista para un puesto de contratista. Sin embargo, lo pasé, me dijeron que era principalmente un desarrollador de UI. Solo cubrí lo básico de lo que necesitaban para su backend, y debería leer sobre sistemas distribuidos antes de la segunda ronda.

Hasta ahora, en mi carrera, he estado trabajando en operaciones de correos, donde el tiempo real nunca fue necesario. Como solo me quedan unos días, ¿qué temas son esenciales que debo cubrir? ¿Primero para poder responder a su pregunta y, en general, ser visto como casi adecuado en sistemas distribuidos?

¿La pregunta era cómo mostrar datos casi en tiempo real en su interfaz de usuario? ¿Qué hay que hacer en el backend? He mencionado el patrón Productor / Consumidor para la alimentación de datos en tiempo real. Le gustó, pero dijo que necesita más en la segunda entrevista.

Cualquier ayuda sería realmente apreciada,

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

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

Repartido

Un sistema distribuido enlaza un número de entidades informáticas independientes con propiedades locales mediante un mecanismo de comunicación. Como consecuencia, los algoritmos y otros componentes de diseño deben tener en cuenta la sincronía y el modelo de falla . Se incluye un resumen útil (no completamente objetivo) de inquietudes de computación distribuida en las ocho fallas de la computación distribuida de Deutsch. (Vea 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 cuestiones de diseño e implementación esenciales:

La red es confiable.
La latencia es cero
El ancho de banda es infinito
La red es segura.
La topología no cambia.
Hay un administrador
El costo de transporte es cero
La red es homogénea.

Tiempo real

Un sistema en tiempo real es un sistema en el que la puntualidad de la finalización de la operación es parte de los requisitos funcionales y la medida de corrección del sistema. (Abrí una pregunta de SO aquí para intentar aclarar esto). En realidad, casi todos los sistemas podrían considerarse "blandos" en tiempo real, en el sentido de que generalmente existen requisitos / expectativas tácitas para la puntualidad de las operaciones. Nos reservamos el término en tiempo real , a veces calificado por soft o hard , 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 puntualidad. (Véase también la etiqueta wiki en tiempo real )

Es útil tener en cuenta que los sistemas RT (y DRT) existen en un continuo de requisitos, con "determinista" (o convencionalmente, en tiempo real difícil ) 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 urgencia de la actividad de la prioridad de la actividad. En sistemas grandes donde la latencia y la falla son factores reales y no triviales, la administración explícita de los recursos de computación y comunicación para cumplir con la puntualidad y otros requisitos de diseño se vuelve más importante, y la separación de estas dos dimensiones se vuelve importante.

Composición distribuida con tiempo real.

Requisitos explícitos de puntualidad: ¿Cuáles son los requisitos, cómo se asignan a las actividades, si son verdaderos requisitos de puntualidad de los nodos, cómo se representarán explícitamente las restricciones de tiempo en el diseño y las implementaciones, y cómo se detectarán, informarán y recuperarán las fallas? ?
Sincronización horaria : ¿Cuáles son los requisitos y los mecanismos para lograr la sincronización del reloj? Wiki sobre sincronización de reloj ; muchas aplicaciones requieren solo NTP ; los requisitos más estrictos pueden requerir hardware especial (por ejemplo, IRIG-B ) o enfoques.
Requisitos de sincronía : ¿Cuáles son los supuestos de sincronía y los requisitos para la sincronía del sistema? Esto está conectado a la sincronización del reloj, pero no es idéntico. Algunas reflexiones sobre modelos formales de Doug Jensen ; wikipedia en sistema asíncrono y Synchronous ; Entonces la pregunta sobre el ordenamiento parcial de eventos ;
Patrones de diseño : ¿Qué son las partes móviles y cómo se relacionan en el transporte? (En particular, ¿cómo afectan estas relaciones a la puntualidad?)
Middleware : ¿Cómo va 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?
Fallo parcial : un sistema en tiempo real generalmente tiene requisitos de confiabilidad. Uno de los aspectos únicos de los sistemas distribuidos es el potencial de clases enteras de fallas denominadas fallas "parciales", ya sea debido a fallas verdaderas de fallas / comunicaciones o errores de puntualidad que deben tratarse como fallas. Pregunta SO sobre los enfoques de conmutación por error ;
RTOS : ¿Qué sistemas operativos en tiempo real se utilizarán?

Algunas referencias

Para una presentación bastante tradicional de los sistemas DRT, eche un vistazo al libro de Kopetz . Para una visión más dinámica, se recomienda el trabajo de Jensen y su sitio web . En el ámbito 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 fallo parcial de una manera particularmente clara.

Recientemente, el concepto de detectores de falla (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 artículo seminal sobre el tema es Sobre el impacto de los detectores rápidos de fallas en sistemas tolerantes a fallas en tiempo real , por Aguilera, Le Lann y Toueg. Este papel es pesado en trineo, pero recompensa cada onza de inversión intelectual.

A un alto nivel hay dos formas básicas de obtener datos en tiempo real desde el back-end al front-end:

Empujar: puede "enviar" datos al cliente enviando mensajes. He usado esto en el pasado para enviar mensajes entre procesos al cliente para alertar a la UI que se ha producido una actualización. Esta es la forma más rápida de transmitir información, pero hay complicaciones. Por ejemplo, no puede (todavía) enviar mensajes IPC a una aplicación web a menos que use Flash, Silverlight, etc. Y también, debe controlar estos mensajes porque si envía demasiados, puede hacer que su UI sea menos sensible. Algunas tecnologías a considerar aquí son MSMQ, TCP / IP y los equivalentes de WCF.
Pull: su UI puede solicitar periódicamente datos del back-end. La ventaja de este método es que es fácil de codificar en la interfaz de usuario: solo sondea una fuente de datos cada X. Pero, por supuesto, la desventaja obvia es que hay un retraso entre una actualización y la aplicación que recibe. Esto puede ser inaceptable para el procesamiento en tiempo real. De todos modos, en este modelo puede llamar a un servicio web o hacer una llamada a una base de datos.

Este es solo el punto de partida, por supuesto. Se pueden utilizar ambos métodos, los datos se pueden almacenar en caché en el cliente, etc. Todo depende de las necesidades de la aplicación.