SISTEMA OPERATIVO EN TIEMPO REAL

Los sistemas de tiempo real y el análisis de sus requerimientos.


Debido que los sistemas de tiempo real tienen características especiales diferentes a los demás tipos de sistemas y que los sistemas operativos de tiempo real relegan a sus usuarios el cumplimiento de estos requerimientos (según la característica de “usuarios controladores” vista en el capítulo anterior) es importante mencionar que este tipo de requerimientos deben de tomarse en cuenta en el proceso de desarrollo. Sin embargo, como estos requerimientos no forman parte de una sola funcionalidad del sistema sino que forman parte de todo el sistema a menudo se definen como “requerimientos no funcionales”. También se argumenta que como no son parte de la aplicación sino que es como se comporta una aplicación al introducirse en un ambiente de tiempo real entonces estos son una “Característica del sistema”, más que un requerimiento. Los dos puntos de vista son erróneos, si bien es cierto que los requerimientos referentes al tiempo real se aplican a todo el sistema, a menudo tenemos que agregar o modificar software, interfaces o hardware para que estos requerimientos se cumplan, mas aun, el software debe de estar preparado para que en la eventualidad de que un trabajo no cumpla con sus requerimientos de tiempo, cancele los demás trabajos relacionados con el (si una petición de entrada / salida toma más del tiempo establecido y se cancela por el sistema, el software de entrada / salida debe de informar al usuario del proceso que este evento ocurrió). Esto es claramente parte de la funcionalidad y de comportamiento del sistema. Por lo que clasificar esta restricción como requerimiento no funcional es incorrecto. Si argumentáramos que: al ser parte de todo el sistema son una característica del sistema más que un requerimiento estaríamos diciendo que estas restricciones se cumplen con el solo hecho de pertenecer al sistema. Una característica es algo que ya esta en el sistema y que no puede ser calificada como errónea o correcta, y una restricción deberá de ser cumplida siempre y la forma en que estas restricciones se cumplen puede ser validad como errónea o correcta. Por lo que estas restricciones tampoco son una característica del sistema. Filosofías de diseño Hay dos diseños básicos. Un sistema operativo guiado por eventos sólo cambia de tarea cuando un evento necesita el servicio. Un diseño de compartición de tiempo cambia de tareas por interrupciones del reloj y por eventos. http://JRSystemPCs.iespana.es El diseño de compartición de tiempo gasta más tiempo de la UCP en cambios de tarea innecesarios. Sin embargo, da una mejor ilusión de multitarea. Programación
Responsividad La Responsividad se enfoca en el tiempo que se tarda una tarea en ejecutarse una vez que la interrupción ha sido atendida. Los aspectos a los que se enfoca son: · La cantidad de tiempo que se lleva el iniciar la ejecución de una interrupción · La cantidad de tiempo que se necesita para realizar las tareas que pidió la interrupción. · Los Efectos de Interrupciones anidadas. Una vez que el resultado del cálculo de determinismo y Responsividad es obtenido. Se convierte en una característica del sistema y un requerimiento para las aplicaciones que correrán en el. (e. g. Si diseñamos una aplicación en un sistema en el cual el 95% de las tareas deben terminar en cierto periodo de tiempo entonces es recomendable asegurarse que las tareas ejecutadas de nuestra aplicación no caigan en el 5% de bajo desempeño) Usuarios controladores En estos sistemas, el usuario (i.e los procesos que corren en el sistema) tienen un control mucho más amplio del sistema. · El proceso es capaz de especificar su prioridad · El proceso es capaz de especificar el manejo de memoria que requiere (que parte estará en caché y que parte en memoria swap y que algoritmos de memoria swap usar) · El proceso especifica que derechos tiene sobre el sistema. Esto aunque parece anárquico no lo es, debido a que los sistemas de tiempo real usan TIPOS de procesos que ya incluyen estas características, y usualmente estos TIPOS de procesos son mencionados como requerimientos. Un ejemplo es el siguiente: “Los procesos de mantenimiento no deberán exceder el 3% de la capacidad del procesador, A MENOS de que en el momento que sean ejecutados el sistema se encuentre en la ventana de tiempo de menor uso”.

Confiabilidad

La confiabilidad en un sistema de tiempo real es otra característica clave. El sistema no debe de ser solamente libre de fallas pero más aun, la calidad del servicio que presta no debe de degradarse más allá de un límite determinado.
El sistema debe de seguir en funcionamiento a pesar de catástrofes, o fallas mecánicas. Usualmente una degradación en el servicio en un sistema de tiempo real lleva consecuencias catastróficas,
Operación a prueba de fallas duras (Fail soft operation)
El sistema debe de fallar de manera que: cuando ocurra una falla, el sistema preserve la mayor parte de los datos y capacidades del sistema en la máxima medida posible.
Que el sistema sea estable, I. E. Que si para el sistema es imposible cumplir con todas las tareas sin exceder sus restricciones de tiempo, entonces el sistema cumplirá con las tareas más críticas y de más alta prioridad.
En los diseños típicos, una tarea tiene tres estados: ejecución, preparada y bloqueada. La mayoría de las tareas están bloqueadas casi todo el tiempo. Solamente se ejecuta una tarea por UCP. La lista de tareas preparadas suele ser corta, de dos o tres tareas como mucho.
El problema principal es diseñar el programador. Usualmente, la estructura de los datos de la lista de tareas preparadas en el programador está diseñada para que cada búsqueda, inserción y eliminación necesiten interrupciones de cierre solamente durante un periodo de tiempo muy pequeño, cuando se buscan partes de la lista muy definidas.
Esto significa que otras tareas pueden operar en la lista asincrónicamente, mientras que se busca. Una buena programación típica es una lista conectada bidireccional de tareas preparadas, ordenadas por orden de prioridad. Hay que tener en cuenta que no es rápido de buscar sino determinista. La mayoría de las listas de tareas preparadas sólo tienen dos o tres entradas, por lo que una búsqueda secuencial es usualmente la más rápida, porque requiere muy poco tiempo de instalación.
El tiempo de respuesta crítico es el tiempo que necesita para poner en la cola una nueva tarea preparada y restaurar el estado de la tarea de más alta prioridad.
En un sistema operativo en tiempo real bien diseñado, preparar una nueva tarea necesita de 3 a 20 instrucciones por cada entrada en la cola y la restauración de la tarea preparada de máxima prioridad de 5 a 30 instrucciones. En un procesador 68000 20MHz, los tiempos de cambio de tarea son de 20 microsegundos con dos tareas preparadas.
Cientos de UCP MIP ARM pueden cambiar en unos pocos de microsegundos..
Relación de las tareas entre sí
Las diferentes tareas de un sistema no pueden utilizar los mismos datos o componentes físicos al mismo tiempo. Hay dos diseños destacados para tratar este problema.
Uno de los diseños utiliza semáforos. En general, el semáforo puede estar cerrado o abierto. Cuando está cerrado hay una cola de tareas esperando la apertura del semáforo.
Los problemas con los diseños de semáforos son bien conocidos: inversión de prioridades y puntos muertos.
En la inversión de prioridades, una tarea de mucha prioridad espera porque otra tarea de baja prioridad tiene un semáforo. Si una tarea de prioridad intermedia impide la ejecución de la tarea de menor prioridad, la de más alta prioridad nunca llega a ejecutarse. Una solución típica sería tener a la tarea que tiene el semáforo ejecutada a la prioridad de la tarea que lleva más tiempo esperando.
En un punto muerto, dos tareas tienen dos semáforos pero en el 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.
La otra solución es que las tareas se manden mensajes entre ellas. Esto tiene los mismos problemas: La inversión de prioridades 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.
Aunque su comportamiento en tiempo real es menos claro que los sistemas de semáforos, los sistemas basados en mensajes normalmente se despegan y se comportan mejor que los sistemas de semáforo. http://jrsystempcs.iespana.es
Procesamiento de las interrupciones.
Las interrupciones son la forma más común de pasar información desde el mundo exterior al programa y son, por naturaleza, impredecibles. En un sistema de tiempo real estas interrupciones pueden informar diferentes eventos como la presencia de nueva información en un puerto de comunicaciones, de una nueva muestra de audio en un equipo de sonido o de un nuevo cuadro de imagen en una videograbadora digital.
Para que el programa cumpla con su cometido de ser tiempo real es necesario que el sistema atienda la interrupción y procese la información obtenida antes de que se presente la siguiente interrupción. Como el microprocesador normalmente solo puede atender una interrupción a la vez, es necesario que los controladores de tiempo real se ejecuten en el menor tiempo posible. Esto se logra no procesando la señal dentro de la interrupción, sino enviando un mensaje a una tarea o solucionando un semaforo que está siendo esperado por una tarea. El programador se encarga de activar la tarea y esta se encarga de adquirir la información y completar el procesamiento de la misma.
El tiempo que transcurre entre la generación de la interrupción y el momento en el cual esta es atendida se llama latencia de interrupción. El inverso de esta latencia es una frecuencia llamada frecuencia de saturación, si las señales que están siendo procesadas tienen una frecuencia mayor a la de saturación, el sistema será físicamente incapaz de procesarlas. En todo caso la mayor frecuencia que puede procesarse es mucho menor que la frecuencia de saturación y depende de las operaciones que deban realizarse sobre la información recibida.
Reparto de la memoria
Hay dos problemas con el reparto de la memoria en SOTR (sistemas operativos en tiempo real).
El primero, la velocidad del reparto es importante. Un esquema de reparto de memoria estándar recorre una lista conectada de longitud indeterminada para encontrar un bloque de memoria libre; sin embargo, esto no es aceptable ya que el reparto de la memoria debe ocurrir en un tiempo fijo en el SOTR.
En segundo lugar, la memoria puede fragmentarse cuando las regiones libres se pueden separar por regiones que están en uso. Esto puede provocar que se pare un programa, sin posibilidad de obtener memoria, aunque en teoría exista suficiente memoria. Una solución es tener una lista vinculada LIFO de bloques de memoria de tamaño fijo. Esto funciona asombrosamente bien en un sistema simple.