UNIDAD VI

Unidad 6 6.1 Definicion 

Un sistema de tiempo real es un sistema informático en el que es significativo el tiempo en el que se producen sus acciones. No es suficiente que las acciones del sistema sean correctas lógicamente, sino que, además, deben producirse dentro de un intervalo de tiempo determinad. Esto es debido a que el sistema está conectado a un proceso externo del que recibe estímulos a los que debe responder con suficiente rapidez para evitar que evolucione a un estado indeseable. En un sistema de tiempo real existen generalmente un Sistema a Controlar y un Sistema Controlador. Es común que las actividades del STR se dividan en tareas, cada una de ellas sujetas a una serie de restricciones temporales, de entre las que destaca el plazo. Los sistemas de tiempo real se utilizan principalmente en la industria y son sistemas diseñados para funcionar en entornos con limitaciones de tiempo. 

Un sistema de tiempo real debe tener capacidad para operar en forma fiable según limitaciones de tiempo específicas; en otras palabras, debe tener capacidad para procesar adecuadamente la información recibida a intervalos definidos claramente (regulares o de otro tipo). Estos son algunos ejemplos de sistemas operativos de tiempo real: "OS-9;" “RTLinux (RealTime Linux);" “QNX;" “VxWorks” La definición canónica de un sistema de tiempo real (de Donald Gillies ) es la siguiente:"Un sistema de tiempo real es aquel en el que para que las operaciones computacionales estén correctas no depende solo de que la lógica e implementación de los programas computacionales sea correcto, sino también en el tiempo en el que dicha operación entregó su resultado. Si las restricciones de tiempo no son respetadas el sistema se dice que ha fallado. "Otros han agregado: "Por lo tanto, es esencial que las restricciones de tiempo en los sistemas sean cumplidas. El garantizar el comportamiento en el tiempo requerido necesita que el sistema sea predecible. Es también deseable que el sistema obtenga un alto grado de utilización a la vez que cumple con los requerimientos de tiempo”. 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. 

6.2 Modelos de tareas 

Los modelos resultantes de la creación del modelo de procesadores son estudiados por separado (un procesador por vez), para determinar tareas diferentes (que serán programas diferentes de manera tal que se pueden ejecutar concurrentemente o no). La distorsión agregada en esta etapa representa la subdivisión del modelo funcional de un procesador (el DFD) en distintos DFDs (uno por tarea) agrupando procesos batch, interactivos o de tiempo real, partes del DFD aisladas del resto (comunicación solamente a través de depósitos de datos), etc. Además, es probable que sea necesario agregar procesos de control de concurrencia y sincronización para el acceso a recursos compartidos (como por ejemplo los depósitos de datos). Dentro de cada procesador definido en el modelo anterior, deben asignarse procesos a diferentes tareas o particiones. En muchos sistemas operativos modernos, el manejo de tareas es transparente al desarrollador. Las tareas pueden categorizar se típicamente en Interactivas, Batch, y en Tiempo Real. Para la mayoría de los sistemas administrativos es importante determinar que partes del modelo esencial se asignaran a tareas interactivas y cuales a tareas batch. La comunicación entre tareas normalmente es provista vía el sistema operativo. 

COMUNICACIÓN ENTRE TAREAS 

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. 

6.3 Caracteristicas de las tareas 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. 

 6.4 Planificacion de tareas 

La planificación (scheduling) de un sistema de tiempo real consiste en asignar acciones a procesadores - La relación biunívoca entre acciones y procesadores es un plan de ejecución (schedule) El módulo que hace esto es el planificador (scheduler) - para ello utiliza un algoritmo de planificación. 

PLANES VÁLIDOS Y ADMISIBLES Un plan válido es un plan de ejecución que: - asigna como máximo una acción a la vez a cada procesador - asigna como máximo un procesador a la vez a cada acción - no ejecuta ninguna acción antes de su tiempo de activación. - asigna a cada trabajo un tiempo de procesador igual a su tiempo de ejecución real o máximo, según los casos - satisface todas las relaciones de precedencia y todas las restricciones en el uso de los recursos (por ejemplo, exclusión mutua). Un plan admisible (feasible schedule) es un plan válido que asegura que todas las acciones terminan antes de su tiempo límite. 

PLANIFICACIÓN ÓPTIMA Un sistema de tiempo real es planificable con un algoritmo de planificación determinado si el algoritmo siempre produce planes admisiblesUn algoritmo de planificación es óptimo si produce un plan admisible para cualquier sistema siempre que exista. 

ESQUEMAS DE PLANIFICACIÓN Planificación dirigida por tiempo (time/clock-driven) - el planificador se ejecuta cada vez que llega una señal de reloj " ejemplo: planificación cíclica. Planificación por turno circular (round-robin) - las acciones listas para ejecutarse se agrupan en una cola FIFO - cada acción se ejecuta durante una rodaja de tiempo y después se pone al final de la cola " variante: rodajas de tiempo desiguales (ponderadas) Planificación por prioridades - cada acción tiene una prioridad - se ejecuta siempre la acción de mayor prioridad entre las listas " la planificación está dirigida por sucesos (event-driven) 

PLANIFICACIÓN CON Y SIN DESALOJO Planificación con desalojo (preemptive scheduling) - se puede desalojar del procesador una acción que se está ejecutando para dar paso a otra " se usa normalmente con prioridades. Planificación sin desalojo (non-preemptive scheduling) - una acción que ha comenzado a ejecutarse sólo deja el procesador si termina su ejecución necesita un recurso que no está disponible abandona el procesador voluntariamente. 6.5 Sincronizacion Sincronizar archivos o datos. La sincronización de archivos es utilizada para mantener la misma versión de archivos en múltiples dispositivos. Por ejemplo, sincronizar la libreta de dirección de un teléfono con la libreta de direcciones de una computadora. Las funciones de cadena de suministro están integradas e interactúan en tiempo real; cuando se hacen cambios a un área, el efecto es reflejado automáticamente a través de la cadena de suministro. Características de los Sistemas Operativos en Tiempo Real Se caracterizan por presentar requisitos especiales en cinco áreas generales: ð Determinismo ð Sensibilidad ð Control del usuario ð Fiabiidad ð Tolerancia a los fallos Un sistema operativo es determinista si realiza las operaciones en instantes fijos y predeterminados o en intervalos de tiempos predeterminados. 

Cuando compiten varios procesos por los recursos y por el tiempo del procesador, depende, en primer lugar, de la velocidad con la que pueda responder a las interrupciones y en segundo lugar, de si el sistema posee suficiente capacidad para gestionar todas las peticiones en el tiempo requerido. Un sistema operativo para operar de forma determinista es el retardo máximo que se produce de la llegada de la interrupción de un dispositivo de alta prioridad hasta que comienza el servicio. La sensibilidad. El determinismo hace referencia a cuanto tiempo consume un sistema operativo en reconocer una interrupción. La sensibilidad se refiere a cuanto tiempo consume un sistema operativo en dar servicio a la interrupción después de reconocerla. 

Las características de la sensibilidad son, entre otras: 

1- La cantidad de tiempo necesario para iniciar la gestión de la interrupción y comenzar la ejecución de su rutina de tratamiento (ISR, interrupt service routine). 

2- La cantidad de tiempo necesario para ejecutar la ISR. Generalmente, depende de la plataforma del hardware. 

3- El efecto del tratamiento de interrupciones. El servicio se retrasara si una ISR puede ser interrumpida por la llegada de otra interrupción. 

El determinismo y la sensibilidad forman conjuntamente el tiempo de respuesta a sucesos externos. Los requisitos en tiempo de respuesta son críticos ya que cada sistema debe cumplir los requisitos de tiempo impuesto por los individuos, dispositivos y flujos de datos externos al sistema. El control del usuario es generalmente mucho mayor en un sistema operativo en tiempo real que en un sistema operativo ordinario. En sistema operativo típico que no sea en tiempo real, el usuario no tiene control sobre la función de planificación del sistema operativo. 

En un sistema en tiempo real resulta esencial permitir al usuario un control preciso sobre la prioridad de las tareas. El usuario debe poder distinguir entre tareas rígidas y flexibles y especificar prioridades relativas dentro de cada clase. Un sistema en tiempo real también permitirá al usuario especificar características. Que procesos deben estar siempre residente en la memoria principal. La fiabilidad es normalmente mucho mas importante en sistemas en tiempo real que en los que no lo son. Un fallo transitorio en un sistema que no sea en tiempo real puede resolverse simplemente volviendo a reiniciar el sistema. Un fallo de un procesador en un multiprocesador que no sea en tiempo real produce una reducción del nivel de servicio hasta que se repara o sustituye el procesador averiado. Pero un sistema en tiempo real responde y controla sucesos en tiempo real. Las perdidas o degradaciones del rendimiento pueden tener consecuencias catastróficas, que pueden ir desde perdida financieras hasta daños en equipo e incluso perdida de vidas humanas. La tolerancia a los fallos es una característica que hace referencia a la capacidad de un sistema de conservar la máxima capacidad y los máximos datos posibles en caso de fallos por Ej., un sistema UNIX clásico típico, cuando detecta datos corruptos en el núcleo, genera un mensaje de error en la consola del sistema, vuelca el contenido de la memoria en el disco para un análisis posterior y finaliza la ejecución del sistema. Un sistema en tiempo real intentara corregir el problema o minimizar sus efectos mientras continua la ejecución. Un aspecto importante a la tolerancia a los fallos es la estabilidad. 

Un sistema en tiempo real si, en los casos en los que es imposible cumplir todos los plazos de ejecución de las tareas, el sistema cumple los plazos de las tareas mas criticas y de mayor prioridad, incluso si no se cumple los de alguna tarea menos critica. 

Para cumplir los requisitos anteriores los sistemas operativos actuales en tiempo real incluyen normalmente las siguientes características. 

- Cambios rápidos de procesos o hilos. 

- Pequeño tamaño (con una mínima funcionalidad asociada). 

- Capacidad de responder rápidamente a interrupciones externas. 

- Multitarea con herramientas de comunicación entre procesos, como semáforos, señales y sucesos. 

- Uso de archivos secuénciales especiales que puedan acumular datos a alta velocidad. - Planificación preferente basadas en prioridades. 

- Reducción de intervalos en los que están inhabilitadas las interrupciones. 

- Primitivas para demorar tareas durante un tiempo fijo y para detenerlas y reanudarlas. 

- Alarmas especiales y temporizadores. 

El corazón de un sistema en tiempo real es el planificador de tares a corto plazo. Lo que resulta importante es que todas las tareas rígidas de tiempo real acaben (o comiencen) en su plazo y que también acaben (o comiencen) en su plazo tantas tareas flexibles de tiempo real como sea posible. La mayoría de los sistemas operativos actuales en tiempo real son incapaces de trabajar directamente con plazos. En su lugar, se han diseñado para ser tan sensibles como sea posible a las tareas de tiempo real, de forma que, cuando se aproxima un plazo se pueda planificar rápidamente la traerá. Las aplicaciones de tiempo real normalmente necesitan tiempos de respuesta deterministas en un rango de varios milisegundo, las aplicaciones al límite, como los simuladores de aviones militares, por Ej. presentan a menudo restricciones en un rango de diez a cien microsegundos.