Sistema operativo de tiempo real
Un sistema operativo de tiempo real es aquel que ha sido desarrollado para aplicaciones de tiempo real. Como tal, se le exige corrección en sus respuestas bajo ciertas restricciones de tiempo. Si no las respeta, se dirá que el sistema ha fallado. Para garantizar el comportamiento correcto en el tiempo requerido se necesita que el sistema sea predecible...
Características Generales
Usado típicamente para aplicaciones integradas, normalmente tiene las siguientes características:
- No utiliza mucha memoria
- Cualquier evento en el soporte físico puede hacer que se ejecute una tarea
- Multi-arquitectura (código portado a cualquier tipo de CPU)
- Muchos tienen tiempos de respuesta predecibles para eventos electrónicos
- Determinismo:
Realiza operaciones en instantes de tiempo fijos predeterminados o dentro de intervalos de tiempo predeterminados. Cuando múltiples procesos compiten por recursos y tiempo de procesador, ningún sistema puede ser totalmente determinista. En un sistema operativo de tiempo real, las solicitudes de servicio de los procesos son dirigidas por eventos externos y temporizaciones. El grado en el que un sistema operativo puede satisfacer de manera determinista las solicitudes depende, primero, de la velocidad a la que es capaz de responder a las interrupciones y, segundo, de si el sistema tiene capacidad suficiente para manejar todas las solicitudes dentro del tiempo requerido. En sistemas operativos no de tiempo real, este retardo puede estar en el rango de decenas a cientos de milisegundos, mientras que en un sistema operativo de tiempo real este retardo puede tener un límite superior en algún punto entre los pocos microsegundos y el milisegundo.
- Reactividad:
Cuánto tiempo tarda el sistema operativo, después del reconocimiento, en servir la interrupción. La reactividad incluye los siguientes aspectos: 1. La cantidad de tiempo necesario para manejar inicialmente la interrupción y comenzar a ejecutar la rutina de servicio de la interrupción (RSI). Si la ejecución de la RSI necesita un cambio de proceso, entonces el retardo será mayor que si la RSI puede ser ejecutada dentro del contexto del proceso actual. 2. La cantidad de tiempo necesario para realizar la RSI. Esto depende, generalmente, de la plataforma hardware. 3. El efecto del anidamiento de interrupciones. Si una RSI puede ser interrumpida por la llegada de otra interrupción, entonces el servicio se retrasará. El determinismo y la reactividad juntos conforman el tiempo de respuesta a eventos externos. Los requisitos de tiempo de respuesta son críticos para los sistemas de tiempo real, dado que estos sistemas deben cumplir requisitos de tiempo impuestos por individuos, dispositivos o flujos de datos ex- ternos al sistema.
- Control del usuario :
En un sistema operativo no de tiempo real, el usuario no tiene control sobre la función de planificación o bien el sistema operativo sólo puede proporcionar una guía burda, como la agrupación de usuarios en más de una clase de prioridad. En un sistema de tiempo real es esencial permitirle al usuario un control de grano fino sobre la prioridad de la tarea. El usuario debe ser capaz de distinguir entre tareas duras y suaves y de especificar prioridades relativas dentro de cada clase. Un sistema de tiempo real puede también permitirle al usuario especificar características como el uso de paginación en los procesos, qué procesos deben residir siempre en memoria principal, qué algoritmos de transferencia a disco deben utilizarse, qué derechos tienen los procesos de las varias bandas de prioridad, etcétera.
- Fiabilidad:
Un sistema de tiempo real ha de responder y controlar eventos en tiempo real. La pérdida o degradación de sus prestaciones puede tener consecuencias catastróficas.
- Operación de fallo suave:
Se refiere a la habilidad del sistema de fallar de tal manera que se preserve tanta capacidad y datos como sea posible. Un sistema de tiempo real intentará o bien corregir el problema o bien minimizar sus efectos continuando, en todo caso, en ejecución. Un sistema de tiempo real es estable si, en los casos en los que sea imposible cumplir los plazos de todas las tareas, el sistema cumplirá los plazos de sus tareas más críticas, de más alta prioridad, aunque los plazos de algunas tareas menos críticas no se satisfagan. Para cumplir los requisitos precedentes, los sistemas operativos de tiempo real incluyen de forma representativa las siguientes características
- Cambio de proceso o hilo rápido.
- Pequeño tamaño (que está asociado con funcionalidades mínimas).
- Capacidad para responder rápidamente a interrupciones externas.
- Multitarea con herramientas para la comunicación entre procesos como semáforos, señales y eventos.
- Utilización de ficheros secuenciales especiales que pueden acumular datos a alta velocidad.
- Planificación expulsiva basada en prioridades.
- Minimización de los intervalos durante los cuales se deshabilitan las interrupciones.
- Primitivas para retardar tareas durante una cantidad dada de tiempo y para parar/retomar tareas.
- Alarmas y temporizaciones especiales.
Lo más importante de un sistema de tiempo real es el planificador de tareas a corto plazo. En el diseño de tal planificador, la equidad y la minimización del tiempo medio de respuesta no son lo más importante. Lo que es importante es que todas las tareas de tiempo real duro se completen (o comiencen) en su plazo y que tantas tareas de tiempo real suave como sea posible también se completen (o comiencen) en su plazo.
Procesador
Este tipo de sistemas operativos no es necesariamente eficiente en el sentido de tener una capacidad de procesamiento alta. El algoritmo de programación especializado, y a veces una tasa de interrupción del reloj alta pueden interferir en la capacidad de procesamiento.
Aunque para propósito general un procesador moderno suele ser más rápido, para programación en tiempo real deben utilizarse procesadores lo más predecibles posible, sin paginación. Todos estos factores en un procesador añade una aleatoriedad que hace que sea difícil demostrar que el sistema es viable, es decir, que cumpla con los plazos de tiempo para la ejecución de las tareas y la atención de los servicios o interrupciones.
Un sistema operativo de tiempo real puede ser implementado en microcontroladores o procesadores digitales de señal "DSP's", así, se pueden desarrollar aplicaciones embebidas en diferentes áreas de la electrónica.
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.
El diseño de compartición de tiempo gasta más tiempo de la CPU en cambios de tarea innecesarios. Sin embargo, da una mejor ilusión de multitarea. Normalmente se utiliza un sistema de prioridades fijas.
Uno de los algoritmos que suelen usarse para la asignación de prioridades es el Rate-Monotonic Schedule. Si el conjunto de tareas que tenemos es viable con alguna asignación de prioridades fijas, también es viable con el Rate-Monotonic Schedule, donde la tarea más prioritaria es la de menor periodo. Esto no quiere decir que si no es viable con Rate-Monotonic Schedule no sea viable con asignaciones de prioridad variable. Puede darse el caso de encontrarnos con un sistema viable con prioridades variables y que no sea viable con prioridades fijas.
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 período 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 microsegundos.
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 métodos para tratar este problema.
Uno de los métodos utiliza semáforos. En general, el semáforo binario 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 Bloqueo mutuo (deadlocks).
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 otorgar a la tarea que tiene el semáforo la prioridad de la tarea más prioritaria de las que están esperando dicho semáforo. Esto se denomina algoritmo de herencia básica de prioridad.
En un punto muerto, dos tareas (T1,T2) pretenden adquirir dos semáforos (semA, semB) en orden inverso. En este caso si T1 adquiere semA y T2 adquiere semB cuando intenten adquirir el segundo semáforo no podrán hacerlo ya que lo tiene la otra tarea. De esta forma entran en un punto muerto del que ninguna de las dos tareas puede salir sin intervención externa. Esto se resuelve normalmente mediante un diseño por ej. obligando a adquirir los semáforos en un orden concreto.
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á tratando un mensaje de baja prioridad, e ignora un mensaje de más alta prioridad en su correo. Los puntos muertos ocurren cuando dos tareas realizan envíos bloqueantes (se quedan en la función de envío esperando a que el receptor reciba el mensaje). Si T1 manda un mensaje de forma bloqueante a T2 y T2 manda un mensaje de igual forma a T1 ninguna de las dos tareas saldrá de la función de envío quedando ambas bloqueadas ya que no podrán llegar a la función de recepción. Puede resolverse reordenando envíos y recepciones o empleando envíos no bloqueantes o temporizados.
Aunque su comportamiento en tiempo real es algo más difícil de analizar que los sistemas de semáforos, los sistemas basados en mensajes normalmente son más sencillos de desarrollar que los sistemas de semáforo.
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 semáforo 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 ésta 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.
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.
La paginación suele desactivarse en los sistemas en tiempo real, ya que es un factor bastante aleatorio e impredecible, que varía el tiempo de respuesta y no nos permite asegurar que se cumplirán los plazos, debido al trasiego de páginas de memoria con un dispositivo de almacenamiento (thrashing)
Planificación de tiempo real
Los distintos enfoques de la planificación dependen de 1. cuando el sistema realiza análisis de planificabilidad; y si lo hace, de 2. si se realiza estática o dinámicamente; y de 3. si el resultado del análisis produce un plan de planificación de acuerdo al cual se desarrollarán las tareas en tiempo de ejecución. En base a estas consideraciones se identifican las siguientes clases de algoritmos: • Enfoques estáticos dirigidos por tabla. En éstos se realiza un análisis estático de la factibilidad de la planificación. El resultado del análisis es una planificación que determina cuando, en tiempo de ejecución, debe comenzar a ejecutarse cada tarea. • Enfoques estáticos expulsivos dirigidos por prioridad. También se realiza un análisis está- tico, pero no se obtiene una planificación. En cambio, el análisis se utiliza para asignar prioridades a las tareas, y así puede utilizarse un planificador expulsivo tradicional basado en prioridades. • Enfoques dinámicos basados en un plan. La factibilidad se determina en tiempo de ejecución (dinámicamente) en vez de antes de comenzar la ejecución (estáticamente). Una nueva tarea será aceptada como ejecutable sólo si es posible satisfacer sus restricciones de tiempo. Uno de los resultados del análisis de factibilidad es un plan que se usará para decidir cuándo poner en marcha la tarea. • Enfoques dinámicos de mejor esfuerzo. No se realiza análisis de factibilidad. El sistema intenta cumplir todos los plazos y aborta la ejecución de cualquier proceso cuyo plazo haya fallado.
2.1) Planificación estática dirigida por tabla. Aplicable a tareas que son periódicas, los datos de entrada para el análisis son: tiempo periódico de llegada, tiempo de ejecución, plazo periódico de finalización, y prioridad relativa de cada tarea. El planificador intenta encontrar un plan que le permita cumplir todos los requisitos de todas las tareas periódicas. Éste es un enfoque predecible pero no flexible, un cambio en cualquiera de los requisitos de las tareas requiere rehacer toda la planificación. Algoritmos de planificación: plazo más cercano primero, técnicas de plazos periódicos. 2.2) Planificación estática con expulsión dirigida por prioridad. Hace uso del mecanismo de planificación expulsivo dirigido por prioridades, Fig. 2, En un sistema de tiempo real, la asignación de prioridades está relacionada con las restricciones de tiempo asociadas a cada tarea. Algoritmos de planificación: algoritmo de tasa monótona; asigna prioridades estáticas a las tareas basándose en sus longitudes y sus periodos. 2.3) Planificación dinámica basada en un plan. Cuando llega una nueva tarea, pero antes de que comience su ejecución, se intentará crear un plan que contenga las tareas previamente planificadas así como la nueva. Si la tarea recién llegada puede ser planificada de manera que se cumplan sus plazos sin que ninguna otra tarea planificada anteriormente pierda un plazo, la nueva tarea será aceptada poniéndose en marcha el nuevo plan de planificación. 2.4) Planificación dinámica de mejor esfuerzo. Cuando llega una tarea, el sistema le asigna una prioridad basada en las características de la misma. De forma característica se utiliza algún tipo de planificación basada en plazos como la planificación del plazo más cercano. Así, las tareas no son periódicas y por tanto no es posible realizar un análisis estático de planificabilidad. Con este tipo de planificación, no sabremos si una determinada restricción de tiempo será satisfecha hasta que venza su plazo o la tarea se complete.
Comunicaciones
Para las comunicaciones se suelen usar conexiones o redes deterministas CAN bus o puertos serie, ya que las redes más usuales, como Ethernet son indeterministas y no pueden garantizarnos el tiempo de respuesta. El sistema CAN bus es utilizado para la interconexión de dispositivos electrónicos de control (ECU) en los vehículos.
Algunos Ejemplos
- Haiku (sistema operativo)
- QNX
- PuyOL
- RT-11
- MaRTE OS
- EasyTasks
- LynxOS
- RedHat Embedded Linux
- eCos (Linux)
- SOOS
- VxWorks
- Windows CE
- Linchos
- UNIX (Algunos)
- DuinOS
- RTAI
- Symbian
- BlackBerry 10
- Microware OS-9
- FreeRTOS
Principales fabricantes
Principales fabricantes de sistemas RTOS en 2009[1]
- Estados Unidos Nucleus RTOS (filial de Mentor Graphics)
- Suecia ENEA OSE (filial de ENEA AB)
- Estados Unidos Wind River Systems (filial de Intel Corporation)
Referencias
- . Archivado desde el original el 14 de julio de 2014. Consultado el 13 de julio de 2014.
Enlaces externos
- EasyTask OS
- MaRTE OS
- FreeRTOS
- Desarrollo de drivers y aplicaciones en sistemas embebidos (FreeRtos) (enlace roto disponible en Internet Archive; véase el historial, la primera versión y la última). Ing. Marcelo Lorenzati, Universidad Nacional de Mar del Plata
- Foro FreeRTOS en castellano (enlace roto disponible en Internet Archive; véase el historial, la primera versión y la última).
- SOOS Project
- Curso de FreeRTOS con microcontroladores PIC
- DuinOS (enlace roto disponible en Internet Archive; véase el historial, la primera versión y la última).
- Milos
- OsaRTOS para PIC