5. Sistemas Operativos de Tiempo Real (RTOS) 5.1. Introduccién Los sistemas operativos de tiempo real (RTOS) es un sistema operative que se caracteriza por ser usado en aplicaciones como: * Telecomunicaciones: teléfonos celulares * Automotriz: unidad electrénica de control (Electronic Control Unit ~ ECU), sistemas de antibloqueo de frenos, etc. © Aeroespacial: * Industrial: Maquinaria, robots, etc, En la actualidad, muchos sistemas son parte de un sistema embebido de tiempo real. Los sistemas en tiempo real (RTOS ~ Real time operating System) son sistemas informaticos que interactuan repetidamente con su entorno fisico y responden dentro de un plazo de tiempo determinado. Es decir, los RTOS exigen un comportamiento predecible ya que se requiere reaccionar a un estimulo del medio ambiente dentro de los pardmetros definidos para la respuesta. “Tiempo real” no se refiere a inmediatamente. Sin embargo, esté relacionado con la velocidad de respuesta del sistema en cuestién. La figura 5.1 muestra un diagrama de un sistema embebido de tiempo real. 128Respuesta 1s de —fisspuesta, ‘Ambiente " ——“— Sistema_, Sistema Embebido ——— >] de Tiempo Real — La distincién fundamental entre los sistemas que son y los que no son de tiempo real es: * Laexactitud de un sistema de tiempo real depende no solo de los resultados légicos de la computacién, sino también del instante cn cl que se producen los resultados. * Enos sistemas de tiempo real puede no valer nada la realizacién de una accién, aunque sea la correcta si se hace fuera de tiempo, incluso puede ser indeseable. * Las acciones del sistema en intervalos de tiempo bien definidos, el disefio y la realizacién de sisternas en tiempo real conlleva una dificultad especial. * No basta con que el sistema sea rpido si no que debe ser determinista, es decir, su comportamiento debe ser el correcto en cualquier circunstancia incluso cuando el sistema este sobrecargado, todo esto implica una adecuada administracién de la prioridades de los procesos dentro del sistema. 129Confiabilidad: la probabilidad de que el sistema trabaje correctamente en el tiempo t= x +/- (tolerancia aceptada). Disponibilidad: Probabilidad de que el sistema responda correctamente dentro del intervalo de tiempo requerido. Los sistemas operativos de tiempo real aislan las tareas y los procesos, permitiendo a cada desarrollador de un grupo a escribir cédigo como si tuviera uso exclusivo del Hardware y sus recursos (como memoria, puertos, ctc.). Sin embargo, cl discfio cn su conjunto para un sistema embebido debe de considerar los problemas adherentes de datos compartidos y multiprocesos, Ademas los RTOS deben de ser personalizados para el Hardware en el cual sera implementado, Por lo regular Sistema Operativo de tiempo real suele tener la misma arquitectura general que un Sistema Operativo convencional, pero su diferencia radica en que proporciona mayor prioridad a los elementos de control y procesamiento que son utilizados para ejecutar los provesos o areas. Un RTOS debe de tener las siguientes caracteristicas bésicas: 130 EI RTOS debe ser multitarea y permisible. EI RTOS debe poder asignar prioridades a las tareas. EI RTOS debe proporcionar medios de comunicacién y sincronizacion entre tareas. EI RTOS debe poder evitar el problema de inversién de prioridades. El comportamiento temporal del RTOS debe ser conocido.Un sistema operativo en tiempo real generalmente usa un micro-kernel o nticleo minimizado de sus elementos, de tal manera que las aplicaciones o los procesos compiten con el administrador de tareas al mismo nivel que las tareas o aplicaciones propias del sistema rador operativo, es decir que un proceso critico puede tener mayor prioridad que el admis de archivos o el mismo administrador de memoria. -1 Tiempo real VS. smpartido Un sistema de este tipo es aquel que necesita de tiempos de respuesta muy cortos, incluso del orden de microsegundos o nanosegundbs, en el caso de procesos criticos. Los sistemas de tiempo real generan alguna accion en respuesta a sucesos externos. Para realizar esta funcién, ejecutan una adquisicién y control de datos a alta velocidad bajo varias ligaduras de tiempo y fiabilidad. Debido a que estas ligaduras son muy rigurosas, los sistemas de tiempo real estan frecuentemente dedicados a una Unica aplicacién. Durante muchos afios, los principales consumidores de sistemas de tiempo real eran militares. Sin embargo, hoy la significativa reduccién del costo del Hardware ha hecho posible para la mayoria de las compaftias, proporcionar sistemas (y productos) de tiempo real para diversas aplicaciones, que incluyen control de procesos, automatizacion industrial, investigacién médica y cientffica, gréficos de computadoras, comunicaciones locales y de largo alcance, sistemas aeroespaciales, prueba asistida por computadora y un vasto abanico de instrumentacién industrial, 131Los sistemas de tiempo real son diferentes de los sistemas de tiempo compartido en varias cuestiones fundamentales. Entre estas se encuentran una alta predictibilidad, velocidad de respuesta y habilidad para responder a eventos criticos. 5.2. Caracteristicas de los RTOS Existen diversas caracteristicas que hacen de los sistemas operativos de tiempo real una herramienta Util para el disefio de Software Embebido. En esta seccién se exploran sus caracteristicas mas importantes, como su arquitectura, determinismo, tolerancia a fallos, fiabilidad, entre otros, 5.2.1. Arquitectura Los sistemas operatives en general pueden tener 3 tipos bésicos de arquitecturas Arquitectura plona figura 5.2., Arquitectura Monvlitita figura 5.3 y Arquitectura de micro kernel figura 5.4. Estos modelos difieren de acuerdo al disefio interno del kernel del sistema operativo, asi como también otro Software de sisterna que ha sido incorporado en el sistema, 132Ln ere de fearon en ‘TeoaBae, [shine ds Aches) Manor do nade! Soles ‘Contoadores de spose Convoloeres de Re! Hevavare Figura 5.2. RTOS con arquitectura plana. 133Protea terns ornet Monotieo| ‘Aplicaciin ‘plea Figura 5.3. RTOS con arquitectura monolitica. 134ered Enns ‘Sais econ 7 EI sistema Operativo en tiempo Real, logra su determinismo y alta eficiencia debido precisamente a su arquitectura, para el objeto de este libro describiremos la arquitectura de micro-kernel Arquitectura Micro-Kernel. La arquitectura "microkernel" (6 RTOS Cliente-servidor) se ha puesto de moda. Aunque muchos nuevos sistemas operativos se dice que son "microniicleos" (0 incluso "nanokernels"), el 135término no puede significar mucho sin una definicién clara. “Un micronticleo es un nticleo pequefio que ofrece los minimos servicios utilizados por un equipo de procesos cooperatives” Tiene las siguientes caracteristicas: * Todos los controladores de dispositivos son independientes. * Todos los dispositivos provistos de proteccién de la memoria a través de la memoria virtual. Microkernel proporciona la planificacién de procesos, el IPC, interrumpe la manipulacién, y bajo nivel de acceso a la red. A diferencia de las arquitecturas multi nivel (Monoliticas) los procesos compiten por el uso del Procesador al mismo nivel que los procesos propios del sistema como el administrador de procesos, el administrador de archivos, inclusive con el administrador de memoria. Es gracias @ esta arquitectura que los procesos son mas deterministicos. Ademas, este tipo de arquitectura es mas escalable (por ser modular), ya que componentes adicionales pueden ser agregados dindmicamente. Este tipo de arquitectura tiene otra ventaja fundamental: se puede agregar tareas de alta y baja prioridad, de modo que se puede hacer un mejor uso de los recursos. Se recomienda la utilizacién de una arquitectura microkernel si la aplicacién puede permitir los requerimientos extras: ‘osto extra, mas memoria RAM y ROM, etc. 136r po de respu Los sistemas operativos de tiempo real deben responder a estimulos externos en el ambiente dentro de un pre-determinado limite de tiempo. Los RTOS deben de producir un resultado correcto y producirlo a tiempo. Esto implica que el tiempo de respuesta es tan importante como lv currecto de los resultados, Los RTOS deben de ser disefiados para poder cumplir con estas expectativas de tiempo. Para poder responder ante estas expectativas, la correcta decisién del disefiador entre los procesos que deben desarrollar el Software y el Hardware es crucial. Una de las preguntas que el disefiador debe hacerse es: {La combinacién Hardware ~ Software que se esta utilizando es apropiada para satisfacer el tiempo de respuesta? Si la respuesta es negativa, debe de hacerse un ani is de velocidad del procesador, de dispositivos de entrada / salida, de ancho de banda, tamafio de memoria, etc. Esto se realiza para determinar los posibles cambios de arquitectura a realizar para que la combinacién Hardware — Software sea la apropiada Andlisis del tiempo de respuesta Este tipo de analisis consta de dos etapas: la primera etapa consiste en predecir el peor tiempo de respuesta para cada tarea. Posteriormente, se compara el peor caso de respuesta con el tiempo limite requerido para la tarea. Este anilisis requiere el peor tiempo de respuesta R, de tal forma que: 137R=C +l, Donde ies la maxima interferencia que la tarea / puede experimentar para cualquier interval discreto de tiempo r. La maxima interferencia que puede ocurrir. Ocurre cuando todas las ‘areas de alta prloridad son llamadas al mismo tempo. De modo que en el andlisis asumiremo: que todas las tareas son liberadas en a+ t=0. La interferencia de una tarea se analiza de la siguiente manera: Dada una tarea periédica i d mayor prioridad que i, el nimero de veces que la tarea es realizada en un tiempo entre 0 y es definido por: Num jecucion Cada vez, la tarea liberada i es retrasada de su tiempo de ejecucién Cj. Con esto, se puede calcular el maximo tiempo de interferencia para una tarea en especifico. (r)s Si definimos a hp(i) como todas las tareas de més alta prioridad que la tarea i, entonces la Tiempoimrerserencia interferencia con la tarea i puede ser representada de la siguiente manera: 1385.2.3. Determinismo Un SO es determinista si realiza las operaciones en instantes fijos y predeterminados o en intervalos de tiempo predeterminados. En un RTOS, las solicitudes de servicios vienen dictadas por eventos y temporizaciones externas. 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 nar todas las en segundo lugar, de si el sistema posee suficiente capacidad para ges peticiones en el tiempo requerido. Se considerara determinista si se puede calcular el retardo maximo que se produce desde la llegada de la interrupcién de un dispositivo hasta que se comienza el servicio. En general, si se puede calcular el maximo tiempo de una llamada del sistema. En los RTOS esta cuota maxima es del orden de microsegundos. En los SO pueden estar en el rango de milisegundos. El determinismo es el tiempo que tarda el sistema en reconocer la interrupcién ibilidad es el tiempo que consume el SOTR en dar servicio a la interrupcién Incluye: 139+ Tiempo necesario para iniciar la gestién de la interrupcién y comenzar la ejecucién de su rutina de tratamiento (ISR). * Tiempo para ejecutar la ISR. * Elefecto del anidamiento de interrupciones. 5.2.5. Control de usuario. El control de usuario es generalmente mucho mayor en un sistema operativo en tiempo real que en un sistema operativo ordinario esto se debe a que 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 rigidas y flexibles y especificar prioridades relativas dentro de cada clase. Un sistema en tiempo real también permitiré al usuario especificar ciertas caracteristicas. Por ejemplo, los procesos que deben estar siempre residente en la memoria principal. El usuario tiene control sobre las pri ridades de las tareas de la aplicacién. Puede especificar aspectos de paginacién o intercambio de procesos. En sistemas distribuidos, la asignacién de procesos a procesadores. 5.2.6. Fiabilidad. Un fallo de un sistema normal se soluciona arrancando de nuevo el sistema. Los fallos en un RTOS pueden dar lugar a resultados catastréficos. 140La fiabilidad de un sistema tiene mucha relacién con la tolerancia a fallos (seccién 5.2.7). estos dos factores han sido cruciales en disefio de sistemas embebidos. Debido a defectos de hardware, interferencias electromagnéticas, las fallas pueden ocurrir en tiempo de ejecucién. Esto resulta especialmente importante cuando se ejecutan sistemas dindmicos, criticos (ej. Sistemas aviénicos) o en ambientes vulnerables. 5.2.7. Tolerancia a fallos. Un RTOS debe disefiarse para responder incluso ante fallos. La tolerancia a fallos es una caracteristica que hace referencia a la capacidad de un sistema de conservar el maximo rendimiento y los maximos datos posibles en caso de fallo: En un RTOS se intentaré corregir el problema o minimizar sus efectos mientras se contintia la ejecucién Otro aspecto importante en la estabilidad es que si no se cumnplen los plazos de algunas tareas, el RTOS debe garantizar que al menos se cumplen los plazos de las més criticas Para poder satisfacer las caracteristicas anteriores los RTOS deben ofrecer lo siguiente: + Soporte para la planificacién de procesos en tiempo real: Un RTOS debe proporcionar soporte para la creacién, borrado y planificacién de multiples procesos, cada uno de los cuales monitorean o controla parte de una aplicacidn. Tipicamente en un RTOS es posible definir prioridades para procesos e interrupciones. En contraste en un sistema 141142 operativo de tiempo compartido, solo el propio sistema operativo determina el orden en que se ejecutan los procesos, Planificacién por prioridad: Un RTOS debe asegurar que un proceso de alta prioridad, cuando esté listo para ejecutarse, pase por delante de un proceso de mds baja prioridad. El SO debera ser capaz reconocer la condicién (usualmente a través de una interrupcién), pasar por delante del proceso que se est ejecutando y realizar un répido cambio de contexto para permitir Ia ejecucién de un proceso de mas alta prioridad, Garantia de respuesta ante interrupciones: Un RTOS debe reconocer muy répidamente la aparicién de una interrupcién 0 un evento, y tomar una accién determinista (bien definida en términos funcionales y temporales) para atender ese evento. Debe responder tanto a interrupciones de tipo Hardware como Software. El propio SO debe ser interrumpible y reentrante. Las interrupciones son una fuente introductoria de indeterminismo, imponen la aparicién de latencias. Comunicacién interprocesos: Un RTOS debe ser capaz de soportar comunicaciones. interprocesos de manera fiable y precisa, tales camo seméforas, paso de mensajes y memoria compartida. Estas facilidades se emplean para sincronizar y coordinar la ejecucién de procesos, asi como la proteccidn de datos y la comparticién de recursos. Adquisicién de datos a alta velocidad: Es necesario que el sistema sea capaz de manejar conjuntos de datos con una alta velocidad de adquisicién. De esta forma, un RTOS proporciona medios para optimizar el almacenamiento de datos en disco, sobre todo a través de £/S buffereada. Otras caracteristicas adicionales pueden ser la posibilidad de pre asignar bloques de archivos contiguos (almacenamiento secuencial) y dar control al usuario sobre los buffers,* Soporte de E/S: Las aplicaciones TR tipicamente incluyen cierto ntimero de interfaces de £/S. Un RTOS debe proporcionar herramientas para incorporar facilmente dispositivos de E/S especificos (incluso a medida), Deben ademés soportar €/S asincrona donde un proceso puede iniciar una operacién de E/S, y luego continuar con su ejecucién mientras concurrentemente se esté realizando la operacién de E/S. * Control por parte del usuario de los recursos del sistema: Una caracteristica clave de los RTOS es la capacidad de proporcionar a los usuarios el control especifico de los recursos del sistema, incluyendo la propia CPU, memoria y recursos de E/S. El control del CPU se logra sobre la base de una planificacién por prioridades en la cual los usuarios pueden establecer las prioridades de los procesos. ‘Ademés, se dispone de temporizadores en tiempo real y de funciones para manejarlos para planificar eventos y periodos de espera. Un RTOS debe también de facilitar el bloqueo de la memoria, de esta forma se puede garantizar que un programa o parte de él permanece en la memoria, a fin de poder realizar cambios de cantexto de manera més rapida cuando acurre una interrupcién. Deberia ser capaz de permitir al usuario la asignacién de buffers y la posibilidad de bloquear y desbloquear archivos y dispositivos. 5.2.8. Comunicacién entre tareas Las diferentes tareas de un sistema no pueden utilizar los mismos datos o componentes fisicos al mismo tiempo. Hay dos disefios destacados para tratar este problema. Uno de los disefios utiliza semaforos. En general, el semaforo puede estar cerrado o abierto. 143Cuando esté cerrado hay una cola de tareas esperando la apertura del semaforo. Los problemas con los disefios de semaforos son bien conocidos: inversion de prioridades, esto es, 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 mds alta prioridad nunca llega a ejecutarse. Una solucién t(pica seria tener a la tarea que tiene el semaforo ejecutada a la prioridad de la tarea que lleva mas tiempo esperando. Puntos muertos, esto significa que, dos tareas tienen dos seméforos pero en el orden inverso. Esto se resuelve normalmente mediante un disefio cuidadoso, realizando colas 0 quitando semdforos, que pasan el control de un semaforo a la tarea de ms 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 mas 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 144sistemas de seméforo. 5.2.9. Concurrencia En el mundo fisico y real es preciso controlar acciones que se estén dando de forma simulténea, Una forma de enfrentarse a este cometido es preparar un conjunto de programas que se comuniquen entre si de tal manera que cada uno controle un aspecto de la funcionalidad del sistema. De esta forma seria mas facil elaborar un conjunto de programas sencillos que uno grande y complejo. Si ademas como es frecuente en los sistemas con los que trabajamos, la respuesta del sistema debe estar condicionada a eventos temporales nos encontramos con una dificultad facer las necesidades del sistema mediante un Unico programa. enorme para sa Denominamos programacién concurrente a la notacién y técnicas de programacién que expresan el paralelismo potencial y que resuelvan los problemas resultantes de la sincronizaci6n y comunicacién. Un programa ordinario consiste en un conjunto de declaraciones de datos y de instrucciones, escrito en un lenguaje de programacién. Las instrucciones son ejecutadas secuencialmente. El camino de ejecucién a través del conjunto de instrucciones puede diferir de una ejecucién a otra, debido a variaciones en las entradas, pero para unos datos determinados solo hay un camino de ejecucién posible. Este tipo de programa se conoce como programa secuencial. 145Un programa concurrente est formado por un conjunto de programas secuenciales llamados procesos 0 hilos que son ejecutados en un paralelismo abstracto. El paralelismo es abstracto por que no es necesario utilizar un procesador fisico para ejecutar cada proceso. Aunque el programa concurrente sea ejecutado en un dnico procesador, podemos suponer que los procesos estén siendo ejecutados simulténeamente, sin preocuparnos por los detalles del paralelismo fisico que puede proporcionar o no nuestra computadora. Una propiedad fundamental de la programacién concurrente es el indeterminismo: dado un instante de tiempo, no es conocido que va a ocurtir en el instante siguiente. Para la Implementaclén sobre un Unico procesador, no puede saberse si va a ocurrir 0 no una interrupci6n que cause un intercambio del proceso que esté siendo ejecutado. En el caso de un sistema multiprocesador, las velocidades de los procesadores no estén sincronizadas, por lo que no puede saberse que procesador va a ser el primero en ejecutar su siguiente instruccién. Todos los sistemas en tiempo real son inherentemente concurrentes. Los lenguajes para sistemas en tiempo real tendrén un mayor poder expresivo si proporcionan al programador las primitivas para realizar una programacién concurrente. 1465.3. Tipos de RTOS Un sistema de tiempo real debe de satisfacer las restricciones del tiempo de respuesta sin sufrir la degradacién del rendimiento de sistema. Si el sistema sufre la degradacién del rendimiento pero no falla, el sistema se conoce como sistema de tiempo real blando (No critico o suave). De lo contrario, si el sistema falla, al sistema se le conoce como tiempo real duro (Critico). Un diagrama para ejemplificar los sistemas de tiempo real critico y no critico, se muestran en la figura 5.5. 4. Da Tap Realcnce som = Nocti > Visrirde Vidsopor Sitar decor yyoq,, Guias de Cort ecwrico ‘sua Ieee: Porat ‘nl emote Figura 5.3. Ejemplo de RTOS Critico y no-critico. Los sistemas de tiempo real pueden ser de dos tipos, esto es en funcién de su severidad en el tratamiento de los errores que puedan presentarse: 47* Sistemas de tiempo real blandos o Soft real-time systems: estos pueden tolerar u exceso en el tiempo de respuesta, con una penalizacién por el incumplimiento del plazo. Estos sistemas garantizan que las tareas criticas se ejecutan en tiempo. Aqui | datos son almacenados en memorias no volatiles, no utilizan técnicas de memori virtual ni tiempo compartido, estas técnicas no pueden ser implementadas e Hardware. + Sistemas de tlempo real duros u Hard real-time systems: aqui la respuesta fuera d ‘término no tiene valor alguno, y produce la falla del sistema, Estos sistemas tienen menos utilidades que los implementados por hardware, por ejemplo no pueden utilizarse para control industrial y robético. Pero si para multimedia, supervision de controles industriales y realidad virtual. 5.3.1. RTOS de tipo Duro (Ci Los sistemas de tiempo real duro o estricto tienen las siguientes caracteristicas: * Todas las acciones deben ocurrir dentro de un tiempo especificado. * Una respuesta tardfa no tiene valor. Ejemplo: Control de vuelo Sistemas multimedia 148Aquila respuesta fuera de termino no tiene valor alguno, y produce la falla del sistema. Estos sistemas tienen menos utilidades que los implementados por Software, por ejemplo no pueden uti irse para control industrial y robdtico pero si para multimedia, supervision de controles industriales y realidad virtual. Estén también los sistemas de misién critica: que es cuando la latencia de un proceso del sistema sobrepasa su cota maxima puede llevar a la pérdida de vidas o a catastrofes similares. Los sistemas operativos de tiempo real duros, el cumplimiento del tiempo es deterministico. El determinismo no dice nada de la magnitud del tiempo limite. Puede ser microsegundos o semanas. Las caracteristicas de las tareas de este tipo de RTOS incluyen: * Pardmetros de tiempo, como periodo de llegada. * Tiempo maximo a umbral de llegada. * Tarea precedente. + Latencia del servicio. © Prioridades de las interrupciones. © Mecanismos arbitrarios. El conocimiento a priori de estas caracteristicas son importantes para poder asignar recursos a Lodas las Larees, principal mente las eriticas 1495.3.2. RTOS de tipo Blando (No critico) También conocidos como sistemas de tiempo real flexibles y entre sus caracteristicas estan: * Se pueden perder plazos de vez en cuando * Elvalor de la respuesta decrece con el tiempo La figura 5.6 muestra un esquema de restricciones de tiempo para los SOTR Ejemplo: Adquisicion de datos. Estos sistemas pueden tolerar un exceso en el tiempo de respuesta, con una penalizacién por el incumplimiento del plazo. Estos sistemas garantizan que las tareas criticas se ejecuten en tiempo. Aqui los datos son almacenados en memorias no volatiles, no utilizan técnicas de memoria virtual ni tiempo compartido, estas técnicas no pueden ser implementadas en hardware. Valor Valor Valor Fecha limite de tiempo Fechalimite de tiempo Fechalimite de tiempo {a) Plazo duro (b)plazo firme (c)Plazo suave 1505.4. Eventos de RTOS Un evento es cualquier tipo de interrupcién, tanto interna, como externa al procesador. Por ejemplo la ocurrencia de algo (una tecla fue presionada, ocurrié un error, 0 una respuesta que se esperaba nunca sucedié) que una tarea puede esperar. Se asocia un evento al rasto de la aplicaci6n (primeramente tareas, pero también a la rutina de servicio de interrupcién, y cédigo de fondo) a través de los servicios de eventos del RTOS. ‘También, casi cualquier parte de un programa puede sefialar la ocurrencia de un evento, por tanto dejando saber a los demés que el evento ocurrid. Ejemplos de eventos pueden ser: * Una Interrupcion. + Aparicién de un error. * Una interrupcién periédica. * Un recurso siendo liberado. * Un pin de &/S cambiando de estado. * Una tecla presionada de un teclado, * Un cardcter siendo recibido o transmitido via RS-232. * Informacion que se pasa de una parte de la aplicacién a otra, etc. 151Existen diversos estados de eventos que generalmente se encuentran en un RTOS. Estos Tip: En muchos sistemas de tiempo real, los eventos presentes y futuros son muy dificiles de predecir, inclusive si se toman en cuenta todas las variables de ambiente y eventos ejecutados previamente. Debido a esto, se necesita informacién a priori, es decir, el conocimiento previo de los procesos a ejecutarse y las caracteristicas ambientales de ejecucién para poder disponer de recursos necesarios antes que el proceso se ejecute. una camara de video ocurren de manera sincrona. Los eventos isosincronos ocurren con regularidad tinicamente por cierta tiernpo pre definido. estados son: 152 Hibernacién: el evento es puesto a “dormi inicializado. El evento es liberado y ejecutado después que otro evento ocurra. En preparacién: el evento entra a este estado después de que el evento anterior es completado y este evento esta disponible para ejecutarse. En general los eventos de los RTOS son de 3 tipos: asincronos, sincronos e isosincronos. Los eventos asincronos son completamente impredecibles. Como ejemplos de este tipo de eventos pueden ser: una llamada a celular que llega a una torre receptora 0 una sefial que indique al microcontrolador de un auto a abrir la bolsa de aire, En estos ejemplos se puede observar que es practicamente imposible predecir estos eventos. *Los eventos sincronos son predecibles y ocurren con regularidad. Por ejemplo, el audio y video de inmediatamente después de ser creado es* En ejecucién: un evento de esta ejecutando al momento. + Suspendido (bloqueado): El evento esté en preparacién y entra al estado de suspendido cuando su ejecucién no puede proceder por alguna razén. Un evento puede ser suspendido debido a falta de recursos, 0 bloqueado temporalmente mientras espera una sincronizacién con alin otro evento. © Terminado: un evento ha sido completado. EI flujo de estados en un evento se muestra la figura 5.7. 153154 Figura 5.7. Estados tipicos de un evento en un RTOS.5.5. Procesos Los sistemas operativos de tiempo real requieren de caracteristicas especiales para ejecutar las funciones y tareas sin exceder las limitantes de tiempo dadas. Debido a esto, las funciones de un RTOS se dividen en procesos (también conocidos como tareas). Un proceso es la unidad basica de programacién que un sistema operativo puede controlar. Cada sistema operativo define un proceso de manera diferente. Un proceso implementa una funcién computacional. Para crear el proceso se utiliza el Kernel. El kernel ademas de crear el proceso, le asigna espacio de memoria al proceso y lee el cddigo a ser ejecutado de la memoria. Para poder hablar mas a detalle de procesos, es necesario hacer mencién a la diferencia entre lun programa y un proceso, Un programa es simplemente una secuencia estdtica de instrucciones. Sin embargo, la ejecucién de instrucciones son dindmicas en el sentido en el que diversas propiedades cambian con respecto al tiempo en el que se ejecutan y la secuencia de instruccién que se le dan al hardware. En este sentido, un proceso es creado por el RTOS para eneapsular toda Ia informacidn invalicrada en la ejecucién del programa (ei. El contador de programa ("program counter”), el tamafio asignado de memoria, etc). Esto significa que el programa es solo una parte de la tarea como se muestra en la figura 5.8. 155Existen diversos tipos de procesos en tiempo real. Algunos tipos son: + Periédicos: Se ejecutan regularmente de acuerdo con un itinerario (schedule) pre- definido. * Esporddicos: Son ejecutados de acuerdo a eventos o condiciones externas al proceso, Este tipo de procesos se ejecutan de acuerdo a un itinerario pre-definido. * Espontdneos: Estos procesos de tiempo real son opcionales y solo se ejecutan en respuesta a eventos 0 condiciones externas al proceso, tinicamente si existen los recursos para hacerlo. 5.5.1. Multiproceso Un sistema operativo se denomina multiprocesos cuando muchas tareas (también conocidas como procesos) se pueden ejecutar al mismo tiempo. 156Las aplicaciones consisten en una secuencia de instrucciones llamadas procesos. Estos procesos permanecen activos, en espera, suspendidos, o se eliminan en forma alternativa, segtin la prioridad que se les haya concedido, o se pueden elecutar en forma simulténea. Multiproceso es un término que hace referencia al cémo la CPU ejecuta concurrentemente procesos almacenados en memoria principal. Por tanto, la CPU no puede ejecutar concurrentemente varios procesos sin que su tiempo sea compartido por estos mismos procesos. La relacién entre varios programas y varios procesos en un RTOS se muestra en la figura 5.9. roerama ros eee Como se muestra en la figura 5.9, el RTOS multiproceso requiere de que cada proceso se 157mantenga independiente de los otros y no afecte ningtin otro. Si el sistema dispone de una CPU para cada proceso, entonces hablamos de multiproceso real. En cambio, siel sistema tiene tun Unico CPU, al sistema operativo no le quedaré mas remedio que repartir el tiempo de ejecucién de esa tinica CPU entre todos los procesos, con el objetivo de aproximarse lo mas posible a lo que serfa la situacién ideal: paralelismo real. En la practica lo que se hace es intercalar la ejecucién de pequefios fragmentos de los procesos en explotacién. Por tanto, cada proceso concluiré cuando lo haga la tiltima instruccién-maquina del dltimo de sus fragmentos, Hablamos, asi, de multiproceso virtual o emulado, Por ejemplo, se tienen 3 tareas en un periodo de 200ms como se muestra en la figura 5.10. 20 20 area t Tarea2 oe 50 30 10 teers ee Tiempo 0 50 100 150 200 " 2 8 Figura 5.10. Di 158ee en eee En este caso de ejemplo, la tarea 1 tiene la més alta prioridad debido a que tiene la mas corta duracién, aunque no es la nica raz6n para darle prioridad més alta, como ya se mencioné. Le siguen en prioridad la tarea 2 y la tarea 3, respectivamente. Como se nuestra en la figura 5.10, la tarea 1 terminara tan pronto como se ejecute la primera porcion de las tareas 2 y 3. La tarea 3, det En el ejemplo de la figura 5.10 la tarea 3 es interrumpida a los 100ms para poder terminar la jo a que es de menor prioridad, puede dejar ejecutar la tarea 1 0 2, segiin sea necesario. tarea 1. Después de esta interrupcidn se reanuda la tarea 3 hasta los 150ms, En un sistema embebido, el multiproceso es mucho mas comtin que en sistemas convencionales. Por ejemplo, en los teléfonos celulares actuales, el sistema dispone de tanto de un procesador digital de sefiales (DSP) para ejecutar Ia interfaz de radio, y un microprocesador para manejar la interfaz del usuario. Para que el RTOS mifulti-praceso pueda asignar un cierto tiempa a cada tarea, se dehe de relizar una serie de procesos como implementacién, manejo del itinerario (scheduling), sincronizacién y comunicaci6n entre tareas. Con esto se da la ilusién de que el sistema puede manejar varios procesos al mismo tiempo, como se mostré en la figura 5.10. Un sistema operativo multiproceso se refiere al ntimero de procesadores del sistema, que es més de uno y éste es capaz de usarlos todos para distribuir su carga de trabajo, Generalmente estos sistemas trabajan de dos formas: simétrica 0 asimétricamente. 159Asimétrica. Cuando se trabaja de manera asimétrica, el sistema operativo selecciona a uno de los procesadores el cual jugaré el papel de procesador maestro y serviré como pivote para distribuir la carga a los demas procesadores, que reciben el nombre de esclavos, Simétrica. Cuando se trabaja de manera simétrica, los procesos o partes de ellos son enviados indistintamente a cual quiera de los procesadores disponibles, teniendo, tedricamente, una mejor distribucién y equilibrio en la carga de trabajo bajo este esquema. Un aspecto importante a considerar en estos sistemas es la forma de crear aplicaciones para aprovechar los varios procesadores. Existen aplicaciones que fueron hechas para correr en sistemas monoproceso que no toman ninguna ventaja a menos que el sistema operativo o e| compilador detecte secciones de cédigo paralelizable, los cuales son ejecutados al mismo tiempo en procesadores diferentes. Por otro lado, el programador puede modificar sus algoritmos y aprovechar por si mismo esta facilidad, pero esta ultima opcién las mas de las veces es costosa en horas hombre y muy tediosa, obligando al programador a ocupar tanto 0 mas tiempo a la paralelizacién que a elaborar el algoritmo iniciel. Algunos RTOS multi reas proven una funcionalidad Ilamadas hilos o hebras(thread). Los hilos son una alternativa para encapsular una instancia o un programa. Cada tarea (o proceso) puede contener tantos hilos como sea necesario. Los hilos son creadas dentro de una tarea y no pueden ser cambiados a otra tarea, por lo que el hilo es atado a la tarea en cuestion. 160Los hilos son secuencias de instrucciones dentro de un proceso. A diferencia de las tareas que tienen recursos de memoria independientes y son inaccesibles a otra tareas, los hilos de una tarea comparten los mismos recursos a la tarea a la que estdn atados. El uso de hilos tiene una ventaja fundamental: no necesitan mecanismos de comunicacién entre tareas, debido a que todos los hilos de una tarea comparten recursos. Esto se muestra en la figura 5.11. (rosamee 08 En general, los desarrolladores de software definen cada tarea (0 hilo) por separado para cada una de las actividades del Sistema Embebido para simplificar todas las acciones a realizar por el sistema. 5.5.2. Implementacién de los Procesos En los RTOS multi-procesos, las tareas estdn estructuradas jerérquicamente en tareas padres y 161tareas hijas. Cuando se ejecuta una tarea al principio, ésta se llama tarea inicial. A partir de ésta tarea inicial, las demas tareas se crean. Este proceso se muestra en la figura 5.12. area inical Tarea | es 5.6. Dificultades de Tiempo Real El disefio de los sistemas operativos de tiempo real presenta serias dificultades para el isefio de los Sistemas Operativos de disefiador 0 arquitecto de Software Embebido. Uno de estas dificultades es que contrario al software tradicional, el software embebido se maneja en tiempo real y debe interactuar con el 162medicambiente. En muchas ocasiones el medioambiente de los sistemas de tiempo real es complejo y cambiante. Muchos sistemas operativos de tiempo real, no solo interacttian con uno, sino con muchas entidades o sistemas, cada uno de ellos con diversas caracterfsticas y propiedades. En el ejemplo de la torre de recepcién de llamadas celulares, el sistema debe de ser capaz de interactuar con miles de llamadas simulténeas, cada una con diferentes caracteristicas y requerimientos. Todo este sistema debe ser manejado y coordinado de manera precisa, Otra de las dificultades de los RTOS es el tiempo de respuesta. Las caracteristicas del tiempo de respuesta han sido explicadas previamente en este capitulo. Solo queda enfatizar la importancia que el RTOS funcione dentro de los limites del tiempo de respuesta, Asi mismo, un Sistema Embebido con una utilizacién constante mayor al 90% del total de su capacidad puede sufrir de comportamiento impredecible o erratico. A este nivel de utilizacién, las tareas de menor prioridad en un sistema pueden no ser ejecutadas tan seguidas como se espera. Como regla general, los sistemas operativos de tiempo real que son cargados al 90% 0 més, toman mucho més tiempo para ser desarrollados (en ocasiones incluso el doble de tiempo). Bajo estas caracteristicas, la utilizacién de multiples procesadores puede ayudar, pero la comunicacién entre los procesadores puede aumentar la complejicad del sistema. Otra de las dificultades en el disefio de RTOS es la velocidad de la comunicacién y los dispositivos de entrada / salida (I/O). Muchos problemas de tiempo de respuesta del sistema 163son debido al procesador siendo sobrecargado y con latencias muy altas debido al tiempo en el que se obtienen datos de y hacia el sistema principal por medio de los dispositivos de E/S, Como se ha comentado, los RTOS interacttan con el medio ambiente, el cual es inherentemente inestable. Por esta razn, los RTOS deben de ser capaces de detectar y sobreponerse a las fallas en el medio ambiente. Ademds de fallas externas, los RTOS deben de ser capaces de sobreponerse a fallas internas, 5.7. Seleccion de los RTOS En la actualidad, el mercado de los Sistemas Embebidos ha crecido enormemente y se ha vuelto muy competitivo. Los desarrolladores han encontrado que los Sistemas son mas complejos y los grupos de trabajo mas grandes. Los RTOS comerciales varian enormemente en funcionalidad, rendimiento, servicio y precio, Existen RTOS que comercialmente tienen algunas funciones para organizacién de itinerario multi-proceso y que estén disponibles a un bajo precio, hasta RTOS mucho mas complejos que pueden ser bastante caros. Con tantas opciones, los equipos de desarrolladores suelen basar esta desicién basados en el rendimiento, funcionalidad 0 compatibilidad con su compilador u otras herramientas de desarrollo. En general, los equipos de desarrolladores, tienden a resistirse a cambiar de RTOS, a menos que se perciba una mejora substancial en las herramientas de desarrollo. in embargo, es recomendable que los desarrolladores tomen en cuenta no solo la conveniencia, sino también 164funcionalidad del RTOS para trabajo en equipo, tiempo de salir al mercado, optimizacién de cédigo, conversién de diagrama de bloques, grafos y diagramas de estado (FSM) a cédigo, etc. Las razones principales por las cuales los proyectos logran ser completados usando ciertos RTOS son diversas. Una de las razones es la facilidad de uso. Entrenar a un ingeniero nuevo en Un sistema que no conoce puede tomar tiempo y afectar la productividad y el termino del proyecto de manera negativa. Ademés, el soporte técnico, la disponibilidad del cédigo fuente ya documentacién son factores que pueden ayudar a que la curva de aprendizaje sea menor. Cor de Rendimiento de RTOS Existen algunas consideraciones de rendimiento del RTOS a tener en cuenta. En general, estas ideraciones consideraciones de rendimiento estén regidos por como el Sistema realiza el manejo de memoria y procesos y la manera por la cual el sistema maneja el itinerario (Schedule). Los principales indivadures de reiidimiento del sistema se enlistan @ continuaci * Throughput. Es el numero de procesos que se ejecutan por el procesador principal en un tiempo determinado. Mientras mas procesos se puedan ejecutar, el rendimiento es obviamente mayor. * Tiempo de ejecucién. Es el tiempo promedio que tarda un proceso en ejecutarse completamente. El tamafio del proceso afecta este in ador. Sin embargo, si se hacen pruebas con procesos criticos y / 0 complejos y se toma el promedio, se puede tene un buen indicador sobre el tiempo de ejecucién. 165* Tiempo de espera. El tiempo total de un proces en que tiene que esperar para poder ejecutarse se denomina tiempo de espera. Para poder medir este indicador se recomienda hacer un cuello de botella en el sistema enviando muchos procesos ala ves para que haya procesos que tengan que esperar su turno en ser ejecutados. Al promedio del tiempo en que los procesos estén en espera servira de base para este \dicador. 5.8. ItInerarlo (Scheduling) en los RTOS 5.8.1. Hilos y Procesos (Process & Threads) Para comprender de una manera mas simple los procesos y los hilos los estudiaremos mediante una analogia. El proceso (Process) es como una casa, la casa es un contenedor con ciertos atributos (numero de recamaras, color del piso, cocina, bafios etc..) Podemos considerar que una casa por si sola no hace ninguna actividad, por lo tanto se le conoce como un objeto pasivo esto es efectivamente un proceso es considerado como un objeto pasivo. Ahora veamos que los ocupantes de esta casa son los hilos (Threads), la gente viviendo en la casa es considerada como las abjetas activos del proceso, y realizan actividades tales como cocinar, ver la televisin, limpiar, etc. Un solo ocupante de la casa (Single Thread) , para aquellos que han vivido solos en una casa sabran que pueden hacer cualquier cosa que deseen en un tiempo cualquiera, lo Unico que deben de hacer es ir y tomar el recurso necesario para hacer las cosas, digamos no tienen que 166pedir permiso a nadie para entrar al bafio o cocinar o mirar la telveision en el canal que sea. Sin embargo cuando hay mas de un ocupante en la casa (Multi Thread) las cosas cambian draméticamente, supongamos que en una casa viven el esposo la esposa y sus dos hijos, en caso de que alguno de los habitantes de la casa tenga la necesidad de ir al bafio y la casa solo tiene un baffo, tiene que verificar si el bafio esta disponible o no, para estos casos es necesario implementar medidas de seguridad y protocols de uso, como por ejemplo asegurar las puertas del bafio, dar prioridad a las actividades, horarios, etc. Asi como un ocupante de la casa requiere de su espacio un hilo requiere de su espacio de memoria, de igual manera si el proceso agrega otro recurso al sistema todos los ocupantes tienen acceso @ este nuevo recurso, esto es por que estan direccionados en el mismo espacio de memoria. Lo interesante en este escenario es identificar si todos los hilos tienen acceso a los nuevos recursos del sistema, digamos que se compro un taladro y los nifios no deben de tener acceso a este nuevo recurso. En caso de que mas de un hilo requiera tener acceso a un recurso se considera que estos hilos deben de estar sincronizados, en el caso de que solo un hilo tenga acceso a un recurso se dice que no requiere de sincronizacién. 5.8. i6n Mutua (Mutual Exclusion, Mutex) Continuando con la analogia de la casa, supongamos que uno de los hilos desea ocupar el bafio 167