Sistemas Operativos de tiempo real

RTAI (Real Time Application Interface).

Sistemas Operativos de Tiempo Real

La arquitectura de un sistema operativo de propósito general divide a la memoria física de un computador en un espacio de usuario (user space) y un espacio de kernel (kernel space). El kernel multitarea es capaz de manejar múltiples aplicaciones que se encuentren en el espacio de usuario, simulando la asignación de todos los recursos de hardware para cada uno de ellos. La comunicación entre los procesos del espacio de usuario y el kernel se realiza mediante las llamadas a sistema las cuales típicamente buscan acceder a los recursos de hardware administrados por el kernel, el cual hace posible que exista transparencia de acceso al usuario.

· 

Las principales labores de un sistema operativo son:

 

· Gestión y planificación de procesos.

· Gestión de memoria.

· Interacción con el hardware.

· Servidor de archivos.

· Servidor de comunicaciones.

 

En este punto podemos señalar que la principal función de un sistema operativo de tiempo real es la de proveer un servicio adecuado a las aplicaciones que requieran respuesta en un intervalo de tiempo determinado.

 

Para poder cuantificar esta propiedad, presentamos dos medidas del tiempo de respuesta de un sistema operativo, las cuales se denominan latencia y jitter.

 

Latencia en un evento.

 

Se denomina evento a una interrupción que puede ser tanto de software como de hardware.

 

La latencia ante una interrupción hardware es el tiempo desde que se produce la interrupción hasta que se ejecuta la primera instrucción de la rutina de tratamiento. Puede haber retrasos debido al acceso al bus.

 

La latencia ante una interrupción software es el tiempo desde que la señal es generada hasta que la primera instrucción de la tarea es ejecutada. Aquí el valor depende únicamente del acceso a los registros del procesador.

 

Período de Jitter.

 

El período de Jitter cuantifica las desviaciones temporales que presenta la ejecución de una tarea periódica con respecto al tiempo que demora cada ciclo.

En conclusión el sistema operativo de tiempo real deberá asegurarnos valores bajos de latencia y jitter, y dentro de márgenes de variación máxima determinados.

Arquitectura de sistema operativo.

Tipos de tiempo real.

Un programa ó un sistema operativo es considerado como de tiempo real, si a pesar de las restricciones de tiempo generadas por las tareas de tiempo real, le permiten trabajar y funcionar correctamente.

 

Se distinguen las siguientes clases:

 

· Tiempo real estricto (Hard Real Time): En algunos casos no cumplir un plazo puede tener consecuencias catastróficas, a este tipo de plazo se le llama plazo estricto. Si una aplicación tiene plazos estrictos y una resolución de tiempo muy fina, a esta le llamaremos Aplicación de RT estricta. Un buen ejemplo podría ser un robot que maneja autos. Si el robot detecta una escenario de peligro en el cual debe frenar lo más rápido posible y pospone esta tarea para bajar un cristal, las consecuencias pueden ser catastróficas.

· Tiempo real flexible (Soft Real Time): Cuando el no cumplir un plazo no trae consecuencias graves, este plazo es considerado un plazo flexible. Ahora si una aplicación tiene plazos flexibles y la resolución de tiempo no es muy fina, a esta aplicación se le llama Aplicación RT flexible. Un buen ejemplo de una aplicación de RT suave es un editor de texto. No importa que tan rápido tecleemos mientras podamos ver los caracteres que acabamos te teclear. Además podemos permitir un retardo de algunos milisegundos.

· Tiempo real firme (Firm Real Time): Existen aplicaciones que permiten fallar algunos plazos pero que requieren de una resolución de tiempo muy fina. A este tipo la denominaremos Aplicación de RT firme. Por ejemplo, un sistema de videoconferencia el cual permite que no actualicemos una imagen por cada 1000. Esta aplicación a pesar de tener un plazo suave requiere una resolución de tiempo muy fina.

Estructura de un sistema operativo de tiempo real.

Como se puede comprobar esta metodología es adecuada para aplicaciones de audio y vídeo donde el periodo de interrupciones es del orden de 1 milisegundo, pero inadecuado cuando ya hablamos de menos de 1 milisegundo.

 

· Modificaciones sobre el kernel estándar (Patch).

 

· Existen básicamente 4 estrategias de modificación del kernel de Linux para proveer capacidades de tiempo real. Una de ellas, y la que es de nuestro interés estudiar, implica añadir un segundo kernel (kernel dual) para manejar las tareas de tiempo real.

 

Esta estrategia presenta una serie de beneficis y limitaciones los cuales son resumidos a continuación:

 

 

· Utilización de Micro-kernel para proveer tiempo real.

 

Esta estrategia añade un segundo kernel que en realidad es una capa interfaz entre el hardware y el kernel estándar, lo que se llama tradicionalmente HAL (Hardware Abstraction Layer). Esta capa, micro-kernel, controla la ejecución de las tareas de tiempo real y ejecuta el kernel estándar como una tarea en background, es decir, el kernel estándar sólo ejecuta cuando no hay tareas de tiempo real pendientes.

 

Este microkernel intercepta las interrupciones hardware y asegura que las tareas de tiempo real ejecuten con la mayor prioridad posible de forma que la latencia se minimice.

 

Ejemplo de implementación de esta metodología son RTLinux y RTAI.

Rendimiento del sistema.

Si comparamos por ejemplo el kernel estándar con RTLinux podremos observar claramente como existe gran diferencia tanto en la latencia en las interrupciones como en el jitter, siendo mucho menos para el caso de RTLinux y siempre en el orden de 1 a 10 microsegundos para un Pentium a 100Mhz.

 

Si comparamos entre si las distintas estrategias de diseño de un sistema operativo de tiempo real podremos observar que las diferencias no son tan amplias si las comparamos con el kernel estándar.

El objetivo de un sistema operativo de tiempo real es reducir la latencia y el jitter en las interrupciones, tanto internas como externas, al orden de microsegundos.

 

Es decir, la parte fundamental para convertir un sistema operativo de propósito general en un sistema operativo de tiempo real es el manejo de las interrupciones.

 

El procesamiento de interrupciones en el kernel estándar esta divido en 2 tareas. Una tarea que se encarga de leer los datos del dispositivo físico y escribirlos en un buffer, es lo que se conoce como manejador de interrupciones, y una tarea que se encarga de pasar los datos del buffer a otro para que sean accesible por el kernel. Con este esquema, cuando el manejador esta ejecutando, todas las interrupciones están inhibidas con el siguiente retardo impredecible en el servicio de otras interrupciones que se puedan haber producido y por tanto en los valores de latencia y jitter.

 

Para conseguir reducir la latencia y el jitter se han desarrollado distintas alternativas que modifican el kernel de linux en este aspecto fundamentalmente.

 

Actualmente hay dos corrientes de diseño:

 

· Atención prioritaria en el kernel estándar (Preemptable kernel)

 

Esta metodología modifica el kernel en profundidad de forma que los procesos de kernel se ejecuten con máxima prioridad de forma que puedan interrumpir a procesos de menor prioridad en el acceso a los recursos que necesiten.

 

Esta metodología implica cambios en los manejadores de interrupciones para que las interrupciones de alta prioridad no sean bloqueadas por el manejador de interrupciones mientras esta manejando otra de menor prioridad.

 

A partir de la versión 2.5.4 del kernel de Linux se incorpora esta metodología.

 

Como se puede observar en la figura la tarea de tiempo real esta controlada por el planificador del kernel y es una más de las tareas que controla el kernel. Esta tarea hace referencia a los procesos de tiempo real en el espacio de usuario. El planificador sabe que las tareas de tiempo real tiene mayor prioridad que las tareas que no son de tiempo real.