Sistema operativo en tiempo real

Un sistema operativo en tiempo real ( RTOS ) es un sistema operativo (SO) para aplicaciones de computación en tiempo real que procesa datos y eventos con restricciones de tiempo definidas de manera crítica. Un RTOS se dirige principalmente a dispositivos con recursos limitados, como los microcontroladores . Se diferencia de un sistema operativo de tiempo compartido , como Unix , que gestiona el uso compartido de los recursos del sistema mediante un planificador, búferes de datos o priorización fija de tareas en entornos multitarea o multiprogramación. Todas las operaciones deben completarse de forma verificable dentro de las restricciones de tiempo y recursos dadas; de lo contrario, el RTOS fallará de forma segura . Los sistemas operativos en tiempo real son orientados a eventos y preventivos , lo que significa que el SO puede supervisar la prioridad relevante de las tareas en competencia y modificarla.

Una característica clave de un RTOS es su nivel de consistencia con respecto al tiempo que tarda en aceptar y completar la tarea de una aplicación ; la variabilidad se denomina " jitter ". ^{[ 1 ]} El principal objetivo de diseño no es un alto rendimiento , sino garantizar una categoría de rendimiento flexible o estricta . Un RTOS que suele cumplir con un plazo es un sistema operativo de tiempo real flexible, pero si puede cumplirlo de forma determinista, es un sistema operativo de tiempo real estricto. ^{[ 2 ]}

Un RTOS cuenta con un algoritmo avanzado para la planificación . La flexibilidad del planificador permite una orquestación más amplia de las prioridades de los procesos en todo el sistema informático, pero un sistema operativo en tiempo real se dedica con mayor frecuencia a un conjunto reducido de aplicaciones. Los factores clave en un sistema operativo en tiempo real son la mínima latencia de interrupción y la mínima latencia de cambio de subprocesos ; un sistema operativo en tiempo real se valora más por la rapidez o la previsibilidad de su respuesta que por la cantidad de trabajo que puede realizar en un período de tiempo determinado. ^{[ 3 ]}

Los diseños más comunes son:

• Orientado a eventos: cambia de tarea solo cuando un evento de mayor prioridad necesita atención; se denomina prioridad preventiva o planificación por prioridad.
• El tiempo compartido alterna las tareas en función de una interrupción programada y de eventos; también se denomina round-robin .

Los sistemas de tiempo compartido permiten cambiar de tarea con más frecuencia de la estrictamente necesaria, pero facilitan la multitarea , dando la ilusión de que un proceso o usuario tiene el uso exclusivo de una máquina.

Los primeros diseños de CPU requerían muchos ciclos para cambiar de tarea, durante los cuales la CPU no podía realizar ninguna otra actividad útil. Debido a que el cambio de tarea era tan lento, los primeros sistemas operativos intentaron minimizar el desperdicio de tiempo de CPU evitando cambios de tarea innecesarios.

En los diseños típicos, una tarea tiene tres estados:

1. En ejecución (ejecutándose en la CPU);
2. Listo (listo para ser ejecutado);
3. Bloqueado (esperando un evento, por ejemplo, una operación de entrada/salida).

La mayoría de las tareas están bloqueadas o listas la mayor parte del tiempo porque, por lo general, solo una tarea puede ejecutarse a la vez por núcleo de CPU . El número de elementos en la cola de tareas listas puede variar considerablemente, dependiendo del número de tareas que el sistema deba realizar y del tipo de planificador que utilice. En sistemas más simples, no preemptivos pero que aún admiten multitarea, una tarea tiene que ceder su tiempo en la CPU a otras tareas, lo que puede provocar que la cola de tareas listas tenga un mayor número de tareas en estado de espera para su ejecución ( agotamiento de recursos ).

Por lo general, la estructura de datos de la lista de tareas listas en el planificador está diseñada para minimizar el tiempo máximo que se pasa en la sección crítica del planificador, durante la cual se inhibe la interrupción y, en algunos casos, se desactivan todas las interrupciones; sin embargo, la elección de la estructura de datos también depende del número máximo de tareas que pueden estar en la lista de tareas listas.

Si la lista de tareas listas nunca tiene más de unas pocas, entonces una lista doblemente enlazada de tareas listas probablemente sea la opción óptima. Si la lista de tareas listas generalmente contiene solo unas pocas tareas, pero ocasionalmente contiene más, entonces la lista debe ordenarse por prioridad, de modo que encontrar la tarea de mayor prioridad para ejecutar no requiera recorrer la lista. En cambio, insertar una tarea requiere recorrer la lista.

Durante esta búsqueda, no se debe inhibir la preempción. Las secciones críticas largas deben dividirse en partes más pequeñas. Si se produce una interrupción que prepara una tarea de alta prioridad durante la inserción de una tarea de baja prioridad, esta última puede insertarse y ejecutarse inmediatamente antes de que se inserte la tarea de baja prioridad.

El tiempo de respuesta crítico, también conocido como tiempo de recuperación, es el tiempo que se tarda en poner en cola una nueva tarea lista y restablecer el estado de la tarea de mayor prioridad. En un sistema operativo en tiempo real bien diseñado, la preparación de una nueva tarea requiere de 3 a 20 instrucciones por cada entrada en la cola de tareas listas, y la restauración de la tarea lista de mayor prioridad requiere de 5 a 30 instrucciones.

En sistemas avanzados, las tareas en tiempo real comparten recursos informáticos con muchas tareas que no lo son, y la lista de tareas listas puede ser arbitrariamente larga. En tales sistemas, una lista de tareas listas del planificador implementada como una lista enlazada sería inadecuada.

Un sistema operativo multitarea como Unix es deficiente en tareas en tiempo real. El planificador da la máxima prioridad a los trabajos con menor demanda de recursos del ordenador, por lo que no hay forma de garantizar que un trabajo crítico en tiempo real tenga acceso a suficientes recursos. Los sistemas multitarea deben gestionar el uso compartido de datos y recursos de hardware entre múltiples tareas. Generalmente, no es seguro que dos tareas accedan simultáneamente a los mismos datos o recursos de hardware específicos. ^{[ 5 ]} Existen tres enfoques comunes para resolver este problema:

Dado que un controlador de interrupciones impide la ejecución de la tarea de mayor prioridad, y que los sistemas operativos en tiempo real están diseñados para minimizar la latencia de los subprocesos, los controladores de interrupciones suelen ser lo más breves posible. El controlador de interrupciones pospone toda interacción con el hardware, si es posible; normalmente, basta con reconocer o deshabilitar la interrupción (para que no se produzca de nuevo cuando el controlador de interrupciones finalice) y notificar a una tarea que debe realizar una tarea. Esto se puede lograr desbloqueando una tarea del controlador mediante la liberación de un semáforo, el establecimiento de una bandera o el envío de un mensaje. Un planificador suele proporcionar la capacidad de desbloquear una tarea desde el contexto del controlador de interrupciones.

Un sistema operativo (SO) mantiene catálogos de los objetos que administra, como subprocesos, mutexes, memoria, etc. Las actualizaciones de este catálogo deben controlarse estrictamente. Por esta razón, puede resultar problemático que un controlador de interrupciones llame a una función del SO mientras la aplicación también lo hace. La función del SO llamada desde un controlador de interrupciones podría encontrar la base de datos de objetos en un estado inconsistente debido a la actualización de la aplicación. Existen dos enfoques principales para abordar este problema: la arquitectura unificada y la arquitectura segmentada. Los sistemas operativos en tiempo real (RTOS) que implementan la arquitectura unificada resuelven el problema simplemente deshabilitando las interrupciones mientras se actualiza el catálogo interno. La desventaja es que aumenta la latencia de las interrupciones, pudiendo incluso perderse algunas. La arquitectura segmentada no realiza llamadas directas al SO, sino que delega el trabajo relacionado con el SO a un controlador independiente. Este controlador se ejecuta con mayor prioridad que cualquier subproceso, pero menor que los controladores de interrupciones. La ventaja de esta arquitectura es que añade muy pocos ciclos a la latencia de las interrupciones. Como resultado, los sistemas operativos que implementan la arquitectura segmentada son más predecibles y pueden manejar tasas de interrupción más altas en comparación con la arquitectura unificada.

Del mismo modo, el modo de administración del sistema en hardware compatible con x86 puede tardar mucho tiempo antes de que devuelva el control al sistema operativo.

La asignación de memoria es más crítica en un sistema operativo en tiempo real que en otros sistemas operativos.

En primer lugar, para garantizar la estabilidad, no debe haber fugas de memoria (memoria asignada que no se libera tras su uso). El dispositivo debe funcionar indefinidamente, sin necesidad de reiniciarse. Por este motivo, no se recomienda la asignación dinámica de memoria . Siempre que sea posible, toda la memoria necesaria se especifica de forma estática durante la compilación.

Otra razón para evitar la asignación dinámica de memoria es la fragmentación de la memoria. Con la asignación y liberación frecuentes de pequeños bloques de memoria, puede darse una situación en la que la memoria disponible se divida en varias secciones y el RTOS no pueda asignar un bloque de memoria continuo lo suficientemente grande, aunque haya suficiente memoria libre. En segundo lugar, la velocidad de asignación es importante. Un esquema estándar de asignación de memoria examina una lista enlazada de longitud indeterminada para encontrar un bloque de memoria libre adecuado, ^{[ 6 ]} lo cual es inaceptable en un RTOS ya que la asignación de memoria debe ocurrir dentro de un cierto lapso de tiempo.

Debido a que los discos mecánicos tienen tiempos de respuesta mucho más largos e impredecibles, el intercambio a archivos de disco no se utiliza por las mismas razones que la asignación de RAM que se comentaron anteriormente.

El sencillo algoritmo de bloques de tamaño fijo funciona bastante bien para sistemas embebidos simples debido a su baja sobrecarga.

Si bien todos los sistemas operativos en tiempo real (RTOS) pueden ejecutarse en microcontroladores para los que tienen puertos, algunos, como Zephyr, son capaces de abstraer aún más varios controladores de dispositivos, como memorias flash externas, dispositivos I2C o periféricos internos como comandos UART y modos de suspensión. Esto elimina la necesidad de que el desarrollador cree controladores, ya que se proporciona un conjunto de API para portar los controladores no compatibles, mientras que los compatibles están listos para usarse en el código de la aplicación.