El sistema operativo en tiempo real ( RTOS , en inglés real-time operating system , RTOS ) es un tipo de sistema operativo especializado , cuyo objetivo principal es proporcionar el conjunto necesario y suficiente de funciones para el diseño, desarrollo y operación de real -time. sistemas de tiempo en equipos de hardware específicos.
La Especificación UNIX, Revisión 2, define:
El tiempo real en los sistemas operativos es la capacidad del sistema operativo para proporcionar el nivel de servicio requerido en un cierto período de tiempo. [una]
Texto original (inglés)[ mostrarocultar] Tiempo real en sistemas operativos: la capacidad del sistema operativo para proporcionar un nivel de servicio requerido en un tiempo de respuesta limitado. [2]El RTOS ideal tiene un comportamiento predecible en todos los escenarios de carga, incluidas las interrupciones simultáneas y la ejecución de subprocesos [3] .
Los sistemas operativos en tiempo real a veces se dividen en dos tipos: sistemas en tiempo real estrictos y sistemas en tiempo real flexibles [4] .
Un sistema operativo que puede proporcionar el tiempo de ejecución requerido para una tarea en tiempo real, incluso en los peores casos, se denomina sistema operativo en tiempo real duro . Un sistema que puede proporcionar el tiempo de ejecución requerido para una tarea en tiempo real en promedio se denomina sistema operativo suave en tiempo real .
Los sistemas de tiempo real duro no permiten retrasos en la respuesta del sistema, ya que esto puede conducir a la pérdida de relevancia de los resultados, grandes pérdidas financieras o incluso accidentes y desastres. Una situación en la que el procesamiento de eventos ocurre más allá del tiempo permitido se considera un error fatal en un sistema de tiempo real estricto. Cuando se produce tal situación, el sistema operativo aborta la operación y la bloquea para que, en la medida de lo posible, no se vea afectada la fiabilidad y disponibilidad del resto del sistema. Ejemplos de sistemas duros en tiempo real pueden ser los sistemas de control a bordo (en un avión, nave espacial, barco, etc.), sistemas de protección de emergencia, registradores de eventos de emergencia [5] .
En un sistema suave en tiempo real, el retraso en la respuesta se considera un error recuperable que puede aumentar el costo de los resultados y reducir el rendimiento, pero no es fatal. Un ejemplo es el funcionamiento de una red informática [6] . Si el sistema no tuvo tiempo de procesar el siguiente paquete recibido, esto provocará una parada en el lado de la transmisión y un reenvío (según el protocolo ). No se pierden datos, pero se degrada el rendimiento de la red.
La principal diferencia entre los sistemas de tiempo real duro y suave se puede describir de la siguiente manera: un sistema de tiempo real duro nunca se retrasará con una reacción a un evento, un sistema de tiempo real suave no se retrasará con una reacción a un evento [6] .
A menudo, un sistema operativo en tiempo real se considera solo un sistema que se puede usar para resolver problemas difíciles en tiempo real. Esta definición significa que el RTOS tiene las herramientas necesarias, pero también significa que estas herramientas deben usarse correctamente [5] .
La mayoría del software está orientado al tiempo real suave. Dichos sistemas se caracterizan por:
Un ejemplo clásico de una tarea en la que se requiere un RTOS es el control de un robot que extrae una pieza de una cinta transportadora . La pieza se está moviendo y el robot solo tiene una pequeña ventana de tiempo en la que puede levantarla. Si se retrasa, entonces la pieza ya no estará en la sección correcta del transportador y, por lo tanto, no se realizará el trabajo, a pesar de que el robot esté en el lugar correcto. Si se prepara antes, entonces la parte no tendrá tiempo de subir todavía y bloqueará su camino.
Además, para los sistemas operativos, a veces se utiliza el concepto de “ tiempo real interactivo ”, que define el umbral mínimo para responder a los eventos de la interfaz gráfica, durante el cual el operador, una persona, puede esperar tranquilamente, sin nerviosismo. que el sistema reaccione a las instrucciones que se le dan.
Tabla que compara RTOS y sistemas operativos convencionales [5] :
| sistema operativo en tiempo real | SO de propósito general | |
|---|---|---|
| la tarea principal | Gestionar para responder a los eventos que ocurren en el equipo | Distribución óptima de los recursos informáticos entre usuarios y tareas |
| en que se enfoca | Manejo de eventos externos | Manejo de las acciones del usuario |
| como se coloca | Una herramienta para crear un complejo específico de hardware y software en tiempo real | Percibido por el usuario como un conjunto de aplicaciones listas para usar |
| quien esta destinado | Desarrollador calificado | Usuario intermedio |
En su desarrollo, los RTOS se construyeron sobre la base de las siguientes arquitecturas :
| Arquitectura monolítica | Arquitectura escalonada (en capas) | Arquitectura cliente-servidor |
El núcleo RTOS proporciona el funcionamiento del nivel de SO abstracto intermedio, que oculta del software de la aplicación los detalles del dispositivo técnico del procesador (varios procesadores) y el hardware asociado [7] .
Esta capa abstracta proporciona cinco categorías principales de servicios para software de aplicación [7] [8] :
Además de los servicios básicos, muchos RTOS ofrecen líneas de componentes complementarios para organizar conceptos de alto nivel como sistema de archivos , redes, administración de redes, administración de bases de datos , interfaz gráfica de usuario , etc. Aunque muchos de estos componentes son mucho más grandes y más complejos, que el propio núcleo RTOS, sin embargo, se basan en sus servicios. Cada uno de estos componentes se incluye en el sistema integrado solo si se necesitan sus servicios para ejecutar la aplicación integrada, y solo para mantener el consumo de memoria al mínimo [7] .
Muchos sistemas operativos de uso general también admiten los servicios anteriores. Sin embargo, la diferencia clave entre los servicios básicos de RTOS es la naturaleza determinista , basada en un estricto control de tiempo, de su trabajo. En este caso, se entiende por determinismo el hecho de que la ejecución de un servicio del sistema operativo requiera un intervalo de tiempo de duración conocida. Teóricamente, este tiempo se puede calcular mediante fórmulas matemáticas , que deben ser estrictamente algebraicas y no deben incluir ningún parámetro de tiempo de naturaleza aleatoria. Cualquier variable aleatoria que determine el tiempo de ejecución de una tarea en el RTOS puede provocar un retraso no deseado en la aplicación, entonces la siguiente tarea no encajará en su cuanto de tiempo, lo que provocará un error [7] .
En este sentido, los sistemas operativos de propósito general no son deterministas. Sus servicios pueden permitir retrasos aleatorios en su trabajo, lo que puede provocar una ralentización en la respuesta de la aplicación a las acciones del usuario en un momento desconocido conocido. Al diseñar sistemas operativos convencionales, los desarrolladores no se centran en el aparato matemático para calcular el tiempo de ejecución de una tarea y un servicio específicos. Esto no es crítico para este tipo de sistemas [7] .
La mayoría de los RTOS realizan la programación de tareas de acuerdo con el siguiente esquema [7] . A cada tarea de la aplicación se le asigna una determinada prioridad. Cuanto mayor sea la prioridad, mayor será la reactividad de la tarea. La alta reactividad se logra mediante la implementación de un enfoque de programación de prioridad preventiva, cuya esencia es que el programador puede detener la ejecución de cualquier tarea en un momento arbitrario si se determina que otra tarea debe iniciarse inmediatamente.
El esquema descrito funciona de acuerdo con la siguiente regla: si dos tareas están listas para ejecutarse al mismo tiempo, pero la primera tiene una prioridad alta y la segunda tiene una baja, entonces el programador dará preferencia a la primera. . La segunda tarea se iniciará solo después de que la primera complete su trabajo.
Es posible que ya se esté ejecutando una tarea de baja prioridad y el programador reciba un mensaje de que otra tarea de mayor prioridad está lista para ejecutarse. Esto puede deberse a alguna influencia externa (interrupción de hardware), como un cambio de estado del interruptor en un dispositivo controlado por el RTOS. En tal situación, el programador de tareas se comportará de acuerdo con el enfoque de programación preventiva de prioridad de la siguiente manera. Una tarea con una prioridad baja podrá completar la instrucción de máquina actual (pero no la instrucción descrita en el código fuente del programa en lenguaje de alto nivel ), después de lo cual se suspende la ejecución de la tarea [7] . A continuación, se inicia una tarea con una prioridad alta. Una vez que finaliza, el planificador inicia la primera tarea interrumpida con la instrucción de la máquina que sigue a la última ejecutada.
Cada vez que el programador de tareas recibe una señal sobre la ocurrencia de algún evento externo (disparador), cuya causa puede ser tanto de hardware como de software, actúa de acuerdo con el siguiente algoritmo [7] :
Estos cinco pasos del algoritmo también se denominan cambio de tareas.
En RTOS convencional, una tarea puede estar en tres estados posibles:
La mayoría de las veces, la mayoría de las tareas están bloqueadas. Solo se puede ejecutar una tarea en la CPU en un momento dado. En los RTOS primitivos, la lista de tareas listas para ejecutar suele ser muy corta, puede constar de no más de dos o tres elementos.
La función principal del administrador de RTOS es compilar dicho programador de tareas.
Si no hay más de dos o tres tareas en la lista de las últimas tareas listas para ejecutarse, se supone que todas las tareas están ubicadas en el orden óptimo. Si hay situaciones en las que el número de tareas en la lista supera el límite permitido, las tareas se ordenan por orden de prioridad.
Actualmente, para resolver el problema de la planificación eficiente en RTOS, dos enfoques se desarrollan más intensamente [9] :
Para grandes cargas del sistema, EDF es más eficiente que RMS.
Los sistemas multitarea necesitan distribuir el acceso a los recursos. El acceso simultáneo de dos o más procesos a cualquier área de memoria u otros recursos supone una cierta amenaza. Hay tres formas de resolver este problema: bloqueo temporal de interrupciones , semáforos binarios , envío de señales. RTOS generalmente no usa la primera forma porque la aplicación de usuario no puede controlar el procesador tanto como quisiera. Sin embargo, muchos sistemas integrados y RTOS permiten que las aplicaciones se ejecuten en modo kernel para acceder a las llamadas del sistema y controlar el entorno de ejecución sin la intervención del sistema operativo.
En los sistemas monoprocesador, la mejor solución es una aplicación que se ejecute en modo kernel y que pueda bloquear las interrupciones. Mientras la interrupción está deshabilitada, la aplicación usa los recursos del proceso solo y no se puede ejecutar ninguna otra tarea o interrupción. Por lo tanto, todos los recursos críticos están protegidos. Después de que la aplicación haya completado las actividades críticas, debe habilitar las interrupciones, si las hubiera. El bloqueo de interrupciones solo se permite cuando el tiempo de ejecución de la sección crítica más largo es menor que el tiempo de respuesta de interrupción permitido. Por lo general, este método de protección se usa solo cuando la longitud del código crítico no supera unas pocas líneas y no contiene bucles . Este método es ideal para proteger registros .
Cuando la longitud de la sección crítica es mayor que la longitud máxima o contiene ciclos, el programador debe usar mecanismos que sean idénticos o imiten el comportamiento de los sistemas de propósito general, como semáforos y señalización.
Los siguientes problemas de asignación de memoria reciben más atención en RTOS que en los sistemas operativos de propósito general.
En primer lugar, la velocidad de asignación de memoria. El esquema de asignación de memoria estándar implica escanear una lista de longitud indefinida para encontrar un área de memoria libre de un tamaño determinado, y esto es inaceptable, ya que en un RTOS la asignación de memoria debe ocurrir en un tiempo fijo.
En segundo lugar, la memoria puede fragmentarse si sus áreas libres están divididas por procesos que ya se están ejecutando. Esto puede hacer que el programa se detenga debido a su incapacidad para usar la nueva ubicación de memoria. Un algoritmo de asignación de memoria que aumente gradualmente la fragmentación de la memoria puede funcionar bien en los sistemas de escritorio si se reinician al menos una vez al mes, pero es inaceptable para los sistemas integrados que se ejecutan durante años sin reiniciar.
Un algoritmo simple con una longitud fija de bloques de memoria funciona muy bien en sistemas integrados simples.
Además, este algoritmo funciona bien en sistemas de escritorio, especialmente cuando, durante el procesamiento de un bloque de memoria por parte de un núcleo, otro núcleo procesa el siguiente bloque de memoria. RTOS optimizados para escritorio, como Unison Operating System o DSPnano RTOS, brindan esta capacidad.
| Sistemas operativos en tiempo real | |
|---|---|
| |
| abierto | |
| Propiedad |
|
| histórico |
|
| |
| Aspectos de los sistemas operativos | |||||
|---|---|---|---|---|---|
| |||||
| Tipos |
| ||||
| Núcleo |
| ||||
| Gestión de procesos |
| ||||
| Gestión y direccionamiento de memoria | |||||
| Herramientas de carga e inicialización | |||||
| caparazón | |||||
| Otro | |||||
| Categoría Wikimedia Commons Wikilibros Wikcionario | |||||