Sistema de tiempo real

El origen del tiempo real proviene de la historia reciente del control de procesos utilizando plataformas de computación digital. De hecho, un texto temprano y definitivo sobre el concepto fue publicado en 1965. El concepto de tiempo real también tiene sus raíces en la simulación por computadora, donde se dice que una simulación que se ejecuta al menos tan rápido como el proceso físico del mundo real que modela se ejecuta en tiempo real. Muchas simulaciones deben hacer un compromiso entre ejecutarse a la misma velocidad o más rápido que el tiempo real, con una fidelidad del modelo menor o mayor. Lo mismo ocurre con las interfaces gráficas de usuario (GUI) en tiempo real, como las proporcionadas por los motores de juegos de computadora. No mucho después del texto de Martin sobre sistemas en tiempo real en 1965, se publicó un artículo definitivo que estableció los fundamentos de una definición matemática de tiempo real estricto: "Scheduling Algorithms for Multiprogramming in a Hard-Real-Time Environment" [Liu73]. Liu y Layland también definieron el concepto de tiempo real flexible en 1973; sin embargo, todavía no hay una definición formal universalmente aceptada de tiempo real flexible. Se han realizado numerosos trabajos e investigaciones para definir sistemas de calidad de servicio (QoS) donde los sistemas tienen permitido ocasionalmente no cumplir con los plazos o utilizan estrategias donde se utiliza la latencia de inicio y el almacenamiento en búfer para permitir la elasticidad en los sistemas en tiempo real.

El concepto de sistemas en tiempo real estricto se comprendió mejor a partir de la experiencia y los problemas observados en los sistemas implementados. Uno de los ejemplos más famosos en sus primeras etapas fue la sobrecarga de guía del módulo lunar del Apolo 11. El sistema del Apolo 11 sufrió una sobrecarga de recursos de la CPU que amenazaba con hacer que los servicios de guía de descenso no cumplieran con los plazos y casi resulta en la cancelación del primer alunizaje en la Luna. Durante el descenso del módulo lunar y el uso del sistema de radar, el astronauta Buzz Aldrin nota una alarma del sistema de guía por computadora. Según se relata en el libro "Failure Is Not an Option" [Kranz00], Buzz transmite por radio: "Alarma del programa. Es un 1202". Eugene Kranz, el director de operaciones de la misión Apolo 11, continúa explicando: "La alarma nos dice que la computadora está atrasada en su trabajo. Si las alarmas continúan, las actualizaciones de guía, navegación y visualización de la tripulación se volverán poco confiables. Si las alarmas persisten, la computadora podría detenerse por completo, abortando posiblemente la misión". En última instancia, basándose en la experiencia adquirida con esta condición de sobrecarga en simulación, se decidió continuar y hacer caso omiso de la alarma, como todos sabemos, el módulo Eagle aterrizó y Neil Armstrong luego puso pie de manera segura en la Luna. En general, ¿cómo se sabe que un sistema está sobrecargado en cuanto a los recursos de la CPU, memoria o E/S?

Claramente, es beneficioso mantener un margen de recursos cuando el costo del fallo es demasiado alto para ser aceptable (como fue el caso del módulo lunar), pero ¿cuánto margen es suficiente? ¿Cuándo es seguro continuar con la operación a pesar de la escasez de recursos? En algunos casos, la escasez de recursos puede ser simplemente una sobrecarga temporal de la cual el sistema puede recuperarse y seguir brindando servicios que cumplan con los requisitos de diseño. La alarma 1202 puede no haber sido la causa raíz de la sobrecarga, de hecho, algunos informes apuntan a la alarma 1201 como la causa, pero lo importante es que la sobrecarga del procesador indicada por el 1202 fue el resultado de un mayor cómputo del que se podía manejar dentro de los plazos requeridos cuando se agregó el procesamiento de la alarma a la carga de trabajo normal. Peter Adler proporciona un relato más detallado para aquellos lectores interesados en los relatos históricos precisos según lo indicado por los ingenieros que estuvieron directamente involucrados [Adler 98].

Desde el Apolo 11, se han observado problemas en tiempo real aún más interesantes en el campo, lo que ha demostrado que el diseño de sistemas en tiempo real es aún más complicado que simplemente garantizar márgenes. Por ejemplo, la nave espacial Mars Pathfinder estuvo a punto de perderse debido a un problema de procesamiento en tiempo real. El problema no fue debido a una sobrecarga, sino a una inversión de prioridades que causó que se perdiera un plazo a pesar de tener un margen razonable de la CPU. Si bien se requiere un acceso seguro para la corrección funcional, cumplir con los plazos de respuesta también es un requisito para los sistemas en tiempo real. Un sistema en tiempo real debe producir respuestas funcionalmente correctas a tiempo, antes de los plazos para la corrección general del sistema. Con cierta experiencia en el desarrollo de sistemas, la mayoría de los ingenieros están familiarizados con cómo diseñar y probar un sistema para que funcione correctamente. Además, la mayoría de los ingenieros de hardware conocen métodos para diseñar la sincronización de la lógica digital y verificar su corrección. Cuando el hardware, el firmware y el software se combinan en un sistema integrado en tiempo real, es necesario diseñar y probar el tiempo de respuesta para asegurarse de que el sistema integrado cumpla con los requisitos de los plazos. Esto requiere un diseño y prueba a nivel de sistema que vayan más allá de los métodos de hardware o software típicamente utilizados.

Como ha demostrado la historia, incluso los sistemas que fueron ampliamente probados no lograron proporcionar respuestas dentro de los plazos requeridos. ¿Cómo ocurren las sobrecargas o inversiones inesperadas? Para responder a estas preguntas, primero se debe entender la teoría fundamental del tiempo real estricto.

• Sincronización mas precisa. Los sistemas en tiempo real se crean para realizar tareas que deben realizarse dentro de escalas de tiempo de ciclo precisas (hasta microsegundos).
• Mayor previsibilidad y confiabilidad. Como los sistemas en tiempo real procesan datos dentro de marcos de tiempo predecibles y establecidos, la ejecución de tareas o cargas de trabajo está prácticamente garantizada, lo que aumenta la confiabilidad de los sistemas de misión crítica.
• Priorización de las cargas de trabajo en tiempo real. La capacidad de priorizar ciertas cargas de trabajo sobre otras es fundamental cuando las cargas de trabajo específicas en tiempo real deben completarse según lo programado para evitar fallas catastróficas del sistema. Algunos (pero no todos) los sistemas en tiempo real tienen esta capacidad en términos de carga de trabajo o priorización de tareas.

Estructura general de sistemas operativos en tiempo real

• Sistema a controlar: Cualquier sistema que pueda ser controlado
• Interfaz con el sistema. adaptar las señales que desde el sistema se envían al computador y desde el computador se mandan al sistema. Está formado por conversores analógicos digitales y digitales analógicos, que permiten medir el estado del sistema a controlar e imponer un control sobre la operación a realizar en dicho sistema.
• Reloj de tiempo real. Un reloj que permita tomar muestras de las señales recibidas de los dispositivos, así como, mandarles determinadas señales en los momentos precisos. El reloj de tiempo real provoca una interrupción en cada período de muestreo
• Consola del operador. Permite al operador humano realizar intervenciones manuales (arranque, parada, modificaciones en el comportamiento del sistema, etc.)
• Pantallas. Se utilizan para enviar información al operador sobre el estado del sistema.
• Base de datos. Los cambios de estado del sistema son guardados en una base de datos que el operador e ingenieros de control pueden interrogar en caso de fallo del sistema o para obtener información con propósito de gestión. Esta información va creciendo y se utiliza para tomar las decisiones que surgen con el funcionamiento del sistema.
• Sistema de monitorización remoto. En procesos industriales, la monitorización de la planta es esencial para reducir costos y aumentar la producción. Las decisiones relativas a la producción de una planta pueden repercutir en el rendimiento de otras plantas que dependen de ella, como es el caso de una planta que produce materia prima para otra.
• Computador. El software que controla las operaciones del sistema está escrito en módulos que reflejan la naturaleza física del entorno. De forma general, estos módulos son:
• Algoritmos de control digital. Realizan el control del sistema.
• Registros de datos. Permiten guardar los cambios de estado del sistema.
• Información de dirección. Permiten facilitar información sobre el estado del sistema y las operaciones que se realizan a los encargados de la dirección del sistema global.
• Interfaz con el operador. Para interactuar con el operador.
• Tamaño y complejidad. A menudo problemas relacionados con sistemas en tiempo real se convierten en problemas de gran tamaño y complejidad.
• Manipulación de números reales. Es la manera de representar los valores leídos del mundo real en un computador.
• Seguridad y fiabilidad. Los sistemas en tiempo real suelen estar relacionados con procesos en los que los fallos tienen consecuencias graves, por lo tanto la tolerancia a fallos es un factor de vital importancia en su diseño.
• Concurrencia. A menudo es necesario controlar el acceso a recursos compartidos, ejecutar varias tareas en paralelo, lo que provoca que los STR presenten un cierto grado de procesamiento en multitarea.
• Eficiencia. Esta característica es exigible a todo tipo de sistemas, aún más en sistemas que pueden ser críticos, como los STR. Con esta característica se pretende asegura que el funcionamiento lógico de sistema es correcto y óptimo
• Dependencia del tiempo. Como ya hemos visto el tiempo es el factor distintivo de los STR, a los que se les exige no solo una corrección lógica, si no que cumplan unos determinados requerimientos temporales. Su comportamiento temporal tiene que ser determinista, y a la hora del diseño, hay que prever el peor de los casos
• Dispositivos de E/S especiales. La conexión con el exterior está adaptada a los procesos que se controlan y a menudo condicionan el funcionamiento del sistema. Las interacciones con el exterior pueden ser activas o pasivas, es decir, el sistema debe controlar el acceso al medio físico, o bien el medio físico perturba de alguna manera al sistema de control.

Control de procesos industriales

En la industria, los sistemas en tiempo real se utilizan para controlar y supervisar procesos como la producción de alimentos, bebidas, productos químicos y farmacéuticos, entre otros. Estos sistemas garantizan que las operaciones se realicen de manera precisa y eficiente, asegurando la calidad del producto final.

Sistemas de transporte

Los sistemas de transporte, como los aviones, trenes, automóviles y barcos, utilizan sistemas en tiempo real para controlar los procesos de navegación, comunicación y seguridad. Estos sistemas permiten a los operadores responder rápidamente a los cambios en el entorno y garantizar la seguridad de los pasajeros y la carga.

Telecomunicaciones

En la industria de las telecomunicaciones, los sistemas en tiempo real se utilizan para controlar el flujo de información en redes de alta velocidad, como la transmisión de datos, voz y video en tiempo real. Estos sistemas garantizan una comunicación fluida y confiable entre los usuarios y los dispositivos.

Sistemas de defensa

Los sistemas de defensa utilizan sistemas en tiempo real para el monitoreo y la respuesta a posibles amenazas, como ataques cibernéticos, guerra electrónica, interceptación de señales y otros tipos de actividad hostil. Estos sistemas permiten a los operadores actuar rápidamente para proteger la seguridad nacional y los intereses militares.

Sistemas médicos

En la medicina, los sistemas en tiempo real se utilizan para monitorear y controlar las funciones vitales de los pacientes, como la frecuencia cardíaca, la presión arterial y la respiración. Estos sistemas permiten a los médicos responder rápidamente a cualquier cambio en el estado del paciente y proporcionar una atención médica oportuna y eficiente.

Las características especiales de los sistemas en tiempo real diferentes a los demás tipos de sistemas introducen en la definición del sistema una serie requerimientos no funcionales, que no se refieren directamente a las funciones específicas si no a propiedades emergentes como por ejemplo, requisitos de fiabilidad, eficiencia o implementación.[2] El diseño por análisis estructurado que emplea la descripción gráfica se enfoca en el desarrollo de especificaciones del programa que está formado por módulos independientes desde el punto de vista funcional.

La computación en tiempo real (o informática en tiempo real) está relacionada con los sistemas de hardware y software que se ven limitados por problemas de tiempo. El software de tiempo real debe necesariamente tener la característica de un tiempo de respuesta crítico.

Por ejemplo, el software encargado de controlar un respirador artificial debe ser de tiempo real, ya que un retraso en su tiempo de respuesta no es aceptable. Algunos tipos de programas como los empleados para jugar al ajedrez solo disponen del tiempo necesario para poder efectuar la siguiente jugada.

Se podría hacer una distinción, por ejemplo, un sistema de gestión del motor de un coche es un sistema en tiempo real activo porque una señal retrasada puede causar un daño o fallo en el motor. Otros ejemplos de sistemas integrados en tiempo real activos son los sistemas médicos como los marcadores de pasos artificiales y los controladores de procesos industriales.

Los sistemas de tiempo real pasivos se utilizan normalmente cuando hay un acceso compartido y se necesitan mantener actualizados un número de sistemas conectados con una situación cambiante. Un ejemplo serían los programas que mantienen y actualizan los planes de vuelo de las compañías aéreas comerciales. Estos programas pueden funcionar en cuestión de segundos.

No sería posible ofrecer vuelos comerciales modernos si estas operaciones no se pudieran realizar de manera fiable en tiempo real. Los sistemas de audio y video en directo también son sistemas en tiempo real pasivos típicos ya que si se sobrepasan los límites de tiempo lo único que puede pasar es que se empeore la calidad pero el sistema continua trabajando.

Las necesidades de los programas de tiempo real se pueden solucionar con sistemas operativos en tiempo real, que ofrecen un marco sobre el que construir aplicaciones de programas en tiempo real.

Un sistema operativo de tiempo real (SOTR o RTOS -Real Time Operating System en inglés) es un sistema operativo que ha sido desarrollado para aplicaciones de tiempo real. Como tal, se le exige corrección en sus respuestas bajo ciertas restricciones de tiempo. Si no las respeta, se dirá que el sistema ha fallado. Para garantizar el comportamiento correcto en el tiempo requerido se necesita que el sistema sea predecible (determinista).

• Sistema operativo en tiempo real
• Data Distribution Service

• Descripción general y ejemplos de sistemas en tiempo real: Intel. (n.d.). Intel. https://www.intel.es/content/www/es/es/robotics/real-time-systems.html

• Pratt, J. & Siewert, S. (2016). Real-Time Embedded Components and Systems with Linux and RTOS. MERCURY LEARNING and INFORMATION.

• Comp.realtime: Frequently Asked Questions (FAQs) (versión 3.6)
• Bina Ramamurthy
• Descripción general y ejemplos de sistemas en tiempo real: Intelen Intel