Sistemas Operativos En Tiempo Real

Sistemas operativos en tiempo real

Enrique Vilches Cruces. Escuela Universitaria Politécnica de Málaga. Curso 2008-2009.

Ingeniería Técnica Industrial Especialidad Mecánica.

Resumen

Los sistemas operativos en tiempo real fueron diseñados para aplicaciones basadas en el tiempo real, por lo que se exigen continuas correcciones a las acciones o respuestas que da el sistema bajo una restricción de tiempo. En el caso de que dichas restricciones no sean respetadas, diremos que el sistema ha fallado. Para garantizar el correcto funcionamiento de este tipo de sistemas se necesita que éste sea determinista, es decir, que ejecutado con los mismos datos en cualquier otro momento dará la misma respuesta o resultado.

1. CARACTERÍSTICAS

1. No se precisa mucha memoria para su ejecución.

2. Fiabilidad.

3. Capacidad de interactuar con el usuario.

4. Cualquier cambio en el hardware puede hacer que se inicialice alguno de sus comandos.

5. Sensibilidad.

6. Tiempo de respuesta predecible para eventos electrónicos.

7. El ya citado determinismo.

8. Multi-arquitectura, es decir, que puede funcionar con distintos tipos de CPU.

9. Tolerancia a los fallos del sistema.

1.2. Procesador

Una peculiaridad de estos sistemas operativos es la dificultad de demostrar que cumplen con el período del reloj interno del ordenador para hacer sus ya citadas restricciones, puesto que posee un algoritmo de programación muy especializado y a veces las interrupciones o correcciones que se deben hacer son muchas, poniendo así en compromiso la velocidad de procesamiento de la CPU.

2. REQUERIMIENTOS

Existen dos tipos de sistemas operativos de tiempo real en cuanto a las restricciones de las tareas: Los sistemas rígidos de tiempo real en los cuales el incumplimiento de requisitos temporales supone un fallo grave del sistema (Críticos) y los sistemas flexibles de tiempo real en los cuales un incumplimiento esporádico de los requisitos temporales no condiciona al sistema (No críticos). En los sistemas que haremos inciso serán en los que existe una convivencia entre tareas críticas y tareas no críticas.

Una vez esclarecido esto, podemos tratar de los requerimientos del sistema.

Lo fundamental en este tipo de sistemas es la estructura dinámica de tareas de tiempo crítico: Se podrá introducir una nueva tarea crítica siempre y cuando el sistema no se encuentre sobrecargado, para que esta nueva tarea que intentamos insertar no afecte a las demás tareas críticas ya existentes, sin embargo, una tarea no crítica siempre podrá ser añadida, pues solo basta la ralentización de su procesamiento para no afectar a las tareas críticas ya existentes.

En aplicaciones de tiempo real lo importante es realizar sus tareas justo en el momento adecuado, ni antes ni después, es decir, en instantes fijos y predeterminados (Determinismo).

2

3. PROGRAMACIÓN.

En los diseños más comunes de programación cada tarea tiene tres estados: ejecución, preparada y bloqueada, aunque la mayoría de las tareas están bloqueadas casi todo el tiempo. Sólo se ejecuta una tarea por CPU y la lista de las tareas suele ser muy corta, de dos o tres tareas como mucho.

Lo más complicado de este tipo de sistemas operativos es diseñar el programador. Normalmente la estructura de los datos de la lista de tareas del programador es diseñada para que necesiten interrupciones de tiempo solamente durante períodos de tiempo muy cortos, cuando se busca una parte de la lista muy específica.

Esto último da lugar a que otras tareas de la lista puedan ser ejecutadas independientemente del tiempo de interrupción de alguna otra tarea, son asíncronas.

Un ejemplo de buena programación es una lista conectada de tareas ordenadas por prioridad. Como la mayoría de las listas de tareas solo disponen de dos o tres comandos, una búsqueda secuencial siempre va a ser la respuesta más rápida, puesto que necesita de un tiempo de ejecución menor que el resto de programaciones.

El tiempo que se necesita para poner en cola una nueva tarea y reconfigurar el estado de la tarea con la prioridad más alta se llama “tiempo de respuesta crítico”.

Preparar una nueva tarea precisa de 3 a 20 instrucciones por cada entrada en la cola y restaurar la tarea de prioridad máxima necesita de 5 a 30 instrucciones.

3.1. Sistema de interacción entre tareas.

Existía un pequeño problema que escapa a la programación de estos sistemas, y era el que las distintas tareas en algunas ocasiones debían utilizar los mismos datos o componentes físicos al mismo tiempo, pero no era computable que fueran a la vez. Para solucionar este inconveniente se ideó una especie de código donde las tareas interactuaban entre sí, se idearon dos modelos.

El primero que mencionaremos es el sistema de semáforos, en el cual, cuando un semáforo estaba cerrado había una cola de instrucciones esperando la apertura de éste. No obstante surgieron dos problemas a este modelo: “inversión de propiedades” y “puntos muertos”.

En la inversión de propiedades nos encontramos con que una tarea de máxima prioridad no se ejecuta porque otra de mínima prioridad tiene un semáforo. Si se diera el caso en el que una tarea de prioridad intermedia no dejase ejecutar la de prioridad baja, la de prioridad máxima nunca se ejecutaría.

En los puntos muertos se da el caso en el que dos tareas tienen dos semáforos pero en orden inverso. Esto se resuelve normalmente mediante un diseño cuidadoso, realizando colas o quitando semáforos, que pasan el control de un semáforo a la tarea de más alta prioridad en determinadas condiciones.

El otro tipo de interacción entre tareas es que se manden mensajes entre ellas. No obstante se sigue teniendo el mismo problema de inversión de prioridades que tiene lugar cuando una tarea está funcionando en un mensaje de baja prioridad, e ignora un mensaje de más alta prioridad en su correo. Los puntos muertos ocurren cuando dos tareas esperan a que la otra responda.

Está comprobado que el sistema de mensajes entre tareas da mucho

...