Un Buen ejemplo es el de un robot que necesita tomar una pieza de una banda sinfín. Si el Robot llega tarde, la pieza ya no estará donde debía recogerla. Por lo tanto el trabajo se llevó acabo incorrectamente, aunque el robot haya llegado al lugar adecuado. Si el robot llega antes de que la pieza llegue, la pieza aun no estará ahí y el robot puede bloquear su paso.

En algunas ocasiones podemos ver referencias sobre sistemas de tiempo real cuando solo se quiere decir que el sistema es rápido. Cabe mencionar que “tiempo real” no es sinónimo de rapidez; esto significa que no es la latencia de la respuesta lo que nos enfoca en un sistema de tiempo real (esta latencia a veces esta en el orden de los segundos), el enfoque en tiempo real de la latencia es el asegurarse de que la latencia del sistema es la suficiente para resolver el problema que al cual el sistema está dedicado.

Si el tener una falla en el tiempo de latencia de un proceso del sistema lleva como consecuencia un error en el sistema entonces esos procesos se consideran de tiempo real duro. Si el tener una falla en un proceso del sistema no conlleva una falla en el sistema siempre y cuando esta falla este dentro de ciertos límites establecidos ( es posible fallar en la latencia una de cada 1000 veces o una de cada 100, o fallar siempre y cuando el error no exceda el 3% de la latencia) entonces esos procesos se llaman procesos de tiempo real suave.

Si el funcionamiento incorrecto del sistema puede llevar a la perdida de vidas o catástrofes similares entonces el sistema de tiempo real es nombrado como sistema de tiempo real de misión crítica.

Características de los sistemas de Tiempo Real

Determinismo

El determinismo es una cualidad clave en los sistemas de tiempo real. Es la capacidad de determinar con una alta probabilidad,  cuanto es el tiempo que se toma una tarea en iniciarse. Esto es importante por que los sistemas de tiempo real necesitan que ciertas tareas se ejecuten antes de que otras puedan iniciar.

Esta característica se refiere al tiempo que tarda el sistema antes de responder a una interrupción. Este dato es importante saberlo por que casi todas las peticiones de interrupción se generan por eventos externos al sistema (i.e. por una petición de servicio), así que es importante determinar el tiempo que tardara el sistema en aceptar esta petición de servicio.

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.

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

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.