Informatica 29 ( 2005) 233-240 233

Una encuesta de tiempo real contemporáneo Sistemas Operativos

S. Baskiyar, Ph.D. y N. Meghanathan Departamento de Ciencias de la

Computación e Ingeniería de Software de la Universidad de Auburn Auburn,
AL 36849, EE.UU. baskiyar@eng.auburn.edu

http://www.eng.auburn.edu/~baskiyar

palabras clave: programación, POSIX, núcleos.

Recibido: 26 de de junio de, de 2004

Un sistema operativo en tiempo real (RTOS) es compatible con las aplicaciones que deben cumplir con los plazos, además de proporcionar
resultados lógicamente correctas. Este artículo revisa los pre-requisitos para un RTOS para ser compatible con POSIX 1003.1b y se analiza la
gestión de memoria y la programación en RTOS. Hacemos un estudio de los prominentes pasos comerciales y de investigación RTOSs y el
esquema de implementación del sistema con un RTOS. Seleccionamos un RTOS comerciales populares dentro de cada categoría de aplicaciones
en tiempo real y se discuten sus características en tiempo real. También se presenta una comparación de la RTOSs comercial. También se discute
los resultados de la encuesta y sugerir futuras líneas de investigación en el campo de la RTOS. Povzetek: Podan je pregled operacijskih sistemov v
realnem času.

comunicaciones. El diseñador debe determinar las tareas críticas y asignarlos

alta prioridades. Sin embargo, se debe tener cuidado para evitar la inanición, que
1 Introducción
se produce cuando las tareas de prioridad más alta siempre están listos para
Un sistema de tiempo real es uno cuya corrección implica tanto la corrección
funcionar, resultando en tiempo de procesador insuficiente para las tareas de
lógica de los productos y su oportunidad [7]. Debe satisfacer las limitaciones de
prioridad más baja [9]. interrupciones no priorizada deben evitarse si hay una
tiempo de respuesta o consecuencias graves de riesgo incluyendo el fracaso.
tarea que no puede ser anulada sin causar un fallo del sistema.
sistemas de tiempo real se clasifican como sistemas duros, firmes o blandos. En
los sistemas de tiempo real, el incumplimiento de las limitaciones de tiempo de
Idealmente, el manejador de interrupciones debe guardar el contexto,
respuesta conduce a fallo del sistema. sistemas en tiempo real firmes tienen
crear una tarea que dará servicio a la interrupción, y devolver el control al sistema
plazos duros, pero donde una cierta baja probabilidad de no cumplir un plazo
operativo. El uso de una tarea a realizar la mayor parte de servicio de interrupción
pueden ser toleradas. Sistemas en los que el rendimiento se degrada pero no
permite que el servicio se realiza en base a una prioridad elegida por el diseñador y
destruida por incumplimiento de las limitaciones de tiempo de respuesta se
ayuda a preservar el sistema de prioridad de la RTOS. Por otra parte, los buenos
denominan sistemas de tiempo real suave.
tiempos de respuesta pueden requerir pequeñas huellas de memoria en los
sistemas de recursos empobrecido. Es evidente que la elección de un RTOS en el
proceso de diseño es importante para el apoyo de prioridades, las interrupciones,
Un sistema embebido es un sistema informático en tiempo real
temporizadores, la comunicación inter-tarea, sincronización, cessing
especializada que forma parte de un sistema mayor. sistemas embebidos
multiprofesional y gestión de la memoria.
configurables y programables en el pasado, que fue diseñado para
aplicaciones especializadas, pero re- están volviendo populares.
Algunos ejemplos de integrado La organización de este documento es la siguiente. Sección 2 se
sistemas son: el sistema de microprocesador usado para controlar la mezcla de
describen los requisitos básicos de un RTOS para POSIX
combustible / aire en el carburador de automóviles, software incorporado en los
1003.1b cumplimiento. Sección 3 comentarios gestión de memoria y la
aviones, misiles, máquinas industriales, hornos de microondas, secadoras,
programación de algoritmos utilizados en RTOS. Sección 4,
máquinas expendedoras, equipos médicos, y cámaras.
clasifica RTOS populares, compara
RTOSs comercial contemporánea y analiza las características en tiempo real de dos
Observamos que la elección de un sistema operativo es importante en el
sistemas operativos de propósito general populares. La sección 5 concluye con un
diseño de un sistema en tiempo real. El diseño de un sistema en tiempo real implica
análisis de los resultados de esta encuesta con algunas sugerencias para futuras
la elección de un lenguaje adecuado, la partición de tareas y fusión, y la asignación
investigaciones.
de prioridades para la gestión de los tiempos de respuesta.
la sincronización de la lengua
primitivas tales como Horario, Señal y Espere simplificar la traducción de diseño a
2 Características
código y también ofrecer la portabilidad. Dependiendo de los objetivos de Las características deseables de un RTOS incluyen la capacidad de programar tareas y
programación, el paralelismo y la comunicación [3] puede ser equilibrada. La fusión cumplir los plazos, la facilidad de incorporar hardware externo, la recuperación de
de tareas paralelas altamente cohesivos para la ejecución secuencial puede reducir errores, la latencia de conmutación tarea de baja, de pequeño tamaño y los gastos
los gastos generales de los cambios de contexto y entre otras tareas generales. El kernel es el núcleo de un sistema operativo que ofrece la programación de
tareas, la tarea
234 Informatica 29 ( 2005) 233-240
despacho y la comunicación inter-tarea. En los sistemas integrados, generalmente
el núcleo puede servir como un RTOS mientras RTOSs comerciales como los que
se utilizan para los sistemas de control de tráfico aéreo requieren todas las
funcionalidades de un sistema operativo de propósito general. En esta sección, se
han abordado los requisitos básicos de un RTOS requisitos de cumplimiento y
POSIX.
2.1 Requerimientos básicos
Los siguientes son los requisitos básicos de un RTOS: (i) Multitarea y
apropiable: Para soportar múltiples
tareas en aplicaciones en tiempo real, un RTOS deben ser multitarea y
apropiable. El planificador debe ser capaz de anticiparse a cualquier
tarea en el sistema y dar el recurso a la tarea que más lo necesita. Un
RTOS también debe manejar múltiples niveles de interrupciones para
manejar múltiples niveles de prioridad. (Ii) Dinámica identificación plazo: Con
el fin de lograr
de preferencia, un RTOS debe ser capaz de identificar de forma
dinámica la tarea con la fecha más temprana. Para manejar los plazos,
información plazo se puede convertir en niveles de prioridad que se
utilizan para la asignación de recursos. Aunque un enfoque de este tipo
es propenso a errores, sin embargo, se emplea para la falta de una
solución mejor. (Iii) sincronización previsible: Para múltiples hilos
para comunicarse entre sí en el momento oportuno, se
requieren mecanismos de comunicación entre las tareas de
sincronización y predecibles. integridad semántica, así
como puntualidad constituye
previsibilidad. sincronización predecible requiere compromisos [14].
Capacidad de bloquear / desbloquear los recursos es una de las maneras de
lograr la integridad de los datos. Para ilustrar este punto, los métodos de
Java pueden ser declaradas con la palabra clave sincronizada, por ejemplo,
sincronizado
AddOne nula (). Sólo un hilo puede llamar a una
método sincronizado en un objeto particular, otros hilos que
intentan acceder a ese método en el mismo espera objeto;
por lo tanto la degradación del rendimiento es
posible. Molesky, Shen, y Zlokapa [12] han propuesto el Teorema
autobús diferida para unir el tiempo de espera en un semáforo en función
del número de solicitantes, el tiempo pasado en la región crítica, y los
tiempos de ejecución de la solicitud y la liberación de un semáforo. Sin
embargo, asumen que el usuario puede estimar el tiempo que cada tarea
puede obtener un bloqueo, que puede no ser siempre factible. A pesar
de que los plazos pueden ser asignados con semáforos, no hay ninguna
garantía de que las tareas críticas tengan acceso a través tareas no
críticas. Otra técnica logra aumento de velocidad por sincronización de
no bloqueo (libre-lock) usando FIFO colas [23]. El tiempo de ejecución
del peor caso de acceder a un objeto de datos compartida por lo tanto
puede ser limitada. (Iv) Niveles de prioridad suficientes: Cuando se utiliza
priorizado
la programación de tareas, el RTOS debe tener un número suficiente
de prioridad niveles, para eficaz
aplicación [9]. inversión de prioridades se produce cuando una tarea de mayor
prioridad debe esperar en una prioridad más baja
S. Beskiyar et al.
tarea para liberar un recurso ya su vez la tarea de prioridad más baja está a
la espera en una tarea de prioridad media. Dos soluciones en el trato con la
inversión de prioridades, los protocolos de la herencia y la prioridad de
techo concretamente, prioridad (PCP), necesitan suficientes niveles de
prioridad. En un mecanismo de herencia de prioridad, una tarea de bloquear
una tarea de mayor prioridad hereda la prioridad más alta para la duración
de la tarea bloqueada. En PCP una prioridad está asociada con cada
recurso que es uno más que la prioridad de su más alta usuario prioridad. El
programador hace que la prioridad de la tarea que accede igual a la del
recurso. Después de una tarea libera un recurso, su prioridad es devuelto a
su valor original. Sin embargo, cuando la prioridad de una tarea se
incrementa acceder a un recurso no debería haber estado esperando en
otro recurso. (V) latencias predefinidos: El momento de las llamadas al
sistema
debe definirse usando las siguientes especificaciones:
• latencia de conmutación de tareas o el tiempo para salvar el contexto
de una tarea que se está ejecutando y cambiar a otra.
• latencia de interrupción o el tiempo transcurrido entre la
ejecución de la última instrucción de la tarea interrumpida y
la primera instrucción de la
interrupción manejador [ 4].
• latencia de despacho de interrupciones o el tiempo para cambiar de la
última instrucción en el manejador de interrupciones
a la siguiente tarea programada para ejecutarse.
2.2 compatibilidad POSIX
IEEE Portable Operating System Interface para entornos informáticos, POSIX
1003.1b proporciona los criterios de cumplimiento de los servicios RTOS y está
diseñado para permitir a los programadores de aplicaciones escribir aplicaciones
portátiles. Los servicios requeridos para el cumplimiento incluyen los siguientes:
• Asíncrono I / O: La capacidad para solapar procesamiento de la
aplicación y la aplicación inicia operaciones I / O [5]. Para apoyar a
nivel de usuario I / O, un RTOS empotrados debe apoyar la entrega de
interrupciones externas de un dispositivo de E / S a un proceso de una
manera predecible y eficiente.
• Synchronous I / O: La capacidad para asegurar el retorno del
procedimiento de interfaz cuando se completa la operación de E / S [5].
• El bloqueo de memoria: La capacidad de garantizar residencia de memoria
mediante el almacenamiento de las secciones de un proceso que no se hace
referencia recientemente en dispositivos de memoria secundaria [20].
• Los semáforos: La capacidad para sincronizar el acceso de los recursos por
múltiples procesos [17].
• Memoria compartida: La capacidad de asignar espacio físico común
en proceso independiente espacio virtual específico [5].
• Ejecución de programación: La capacidad de programar múltiples tareas.
métodos de programación comunes incluyen
UN ESTUDIO DE CONTEMPORÁNEO ...
round robin y la prioridad basan programación preventiva.
• temporizadores: temporizadores mejorar funcionalidad y
determinismo del sistema [9].
• Comunicación entre procesos (IPC): Los métodos comunes de
comunicación RTOS incluyen buzones y colas.
• archivos en tiempo real: La capacidad de crear y acceder a archivos con un
rendimiento determinista.
• las discusiones en tiempo real: programables entidades que tienen limitaciones
de puntualidad individuales [9].
3 gestión de memoria y
programación
Esta sección aborda las cuestiones importantes de la gestión de memoria y la
programación de un RTOS.
3.1 Gestión de la memoria
Un RTOS utiliza tamaño de memoria pequeño incluyendo sólo la
funcionalidad necesaria para una aplicación durante la descartando el
resto [22]. A continuación se discuten gestión de memoria estática y
dinámica RTOSs.
gestión de memoria estática proporciona tareas con el espacio temporal de
datos. memoria libre del sistema se divide en un conjunto de bloques de memoria
de tamaño fijo, que puede ser solicitado por las tareas. Cuando termina una tarea
utilizando un bloque de memoria que debe volver a la piscina. Otra forma de
proporcionar un espacio temporal para tareas es a través de prioridades. Una
piscina de la memoria está dedicado a las tareas de alta prioridad y otra a tareas de
baja prioridad. La piscina de alta prioridad está dimensionada para tener la
demanda de memoria peor de los casos del sistema. La piscina de baja prioridad
se le da la memoria libre restante. Si las tareas de baja prioridad agotan la piscina
memoria baja prioridad, tienen que esperar a que la memoria sea devuelto a la
piscina antes de continuar su ejecución [1].
gestión de memoria dinámica emplea intercambio de memoria,
superposiciones, multiprogramación con un número fijo de tareas (MFT),
multiprogramación con un número variable de tareas (MVT) y la paginación bajo
demanda. Superposiciones permiten que los programas más grandes que la
memoria disponible para ser ejecutadas por dividir el código y el canje de ellos
desde el disco a la memoria. En MFT, un número fijo de partes de código
ecualizadas están en la memoria al mismo tiempo. Según sea necesario, las
partes se superponen desde el disco. MVT es similar a la MFT excepto que el
tamaño de la partición depende de las necesidades del programa de MVT.
sistemas de paginación bajo demanda han fijado páginas de tamaño que residen
en la memoria no contigua, a diferencia de los de MFT y MVT [7]. En muchos
sistemas embebidos, los programas del núcleo y de las aplicaciones se ejecutan
en el mismo espacio, es decir, no hay protección de memoria.
3.2 programación
En esta sección, describimos brevemente la programación de algoritmos
empleados en los sistemas operativos en tiempo real. Observamos que la
previsibilidad requiere primitivas del sistema operativo acotadas. Un análisis de
viabilidad de la programación
Informatica 29 ( 2005) 233-240 235
puede ser posible en algunos casos. la programación
literatura es enorme y se remite al lector a [15] para una discusión
detallada.
La programación de tareas puede ser cualquiera realizada
preventivamente o no de forma preventiva y, o bien estática o dinámicamente.
Para aplicaciones pequeñas, la ejecución de tareas
veces pueden estimarse antes de la ejecución y las programaciones de
tareas preliminares determinan estáticamente. Dos limitaciones comunes
en la programación son las necesidades de recursos y la prioridad de
ejecución de las tareas. Los parámetros típicos asociados con tareas son:
• el tiempo promedio de ejecución
• El peor caso de tiempo de ejecución
• gastos de envío
• Hora de llegada
• Período (para tareas periódicas). El objetivo de la
programación es minimizar o maximizar ciertos objetivos. objetivos típicos
minimizadas son: horario de longitud,
promedio tardanza o laxitud.
Alternativamente, maximizando promedio precocidad y número de llegadas que
cumplen los plazos pueden ser objetivos. En [15] enfoques de programación se
han clasificado en: enfoque impulsado tabla estática, prioridad estática
impulsado enfoque preventivo, enfoque basado en una planificación dinámica,
mejor enfoque esfuerzo dinámico, programación con tolerancia a fallos y la
recuperación de recursos. Se discuten brevemente los enfoques de abajo.
(yo) impulsado tabla estática: La viabilidad y el horario
se determinan estáticamente. Un ejemplo común es el ejecutivo
cíclico, que también se utiliza en muchos sistemas dinámicos a
gran escala en tiempo real [2]. Se asigna tareas a intervalos de
tiempo periódicos. Dentro de cada período, las tareas se
distribuyen de acuerdo a una tabla que enumera el fin de ejecutar
las tareas. Para las tareas periódicas, existe un calendario
factible si y sólo si existe un cronograma factible dentro del
mínimo común múltiplo de los períodos. Una desventaja de este
enfoque es que un conocimiento a priori de los requisitos
máximos de tareas en cada ciclo es necesario. (Ii) prioridad
estática impulsado preventiva: La viabilidad
análisis se lleva a cabo de forma estática. Las tareas son
despachada dinámicamente basándose en las prioridades. La
prioridad estática más utilizado impulsado algoritmo de
planificación preventiva para tareas periódicas es el algoritmo de
programación de velocidad monótona (RM) [8]. Un sistema
periódico debe responder con una salida antes de la próxima
entrada. Por lo tanto, el sistema de tiempo de respuesta debe ser
más corto que el tiempo mínimo entre las entradas sucesivas. RM
asigna prioridades proporcionales a la frecuencia de las tareas.
Se puede programar cualquier conjunto de
tareas a cumplir con los plazos, si la utilización total de recursos menos de
ln 2. Si no puede encontrar un horario, ningún otro esquema de
planificación de prioridad fija hará. Pero no proporciona soporte para
cambiar dinámicamente los períodos de tareas / prioridades y la inversión
de prioridades. Además, el establecimiento de prioridades de inversión se
puede producir al hacer cumplir tasa de monotonicidad, una tarea no
crítica de la mayor frecuencia de ejecución es
236 Informatica 29 ( 2005) 233-240
asignado una prioridad más alta que una tarea crítica de menor
frecuencia de ejecución. (Iii) la planificación dinámica basada en: La
viabilidad
análisis se lleva a cabo dinámicamente una tarea de llegar es
aceptada para la ejecución sólo cuando sea factible.
El análisis de viabilidad es también una fuente para
los horarios. La realización de esta misión se garantiza mediante el
conocimiento de su tiempo y las faltas de ejecución del peor caso en el
sistema. Las tareas son
enviados a los sitios por la intermediación de los recursos de una
forma centralizada oa través de ofertas. Una técnica que utiliza tanto
centralizada y hacer una oferta-enfoque realiza marginalmente mejor
que cualquiera de ellos, pero es más compleja [15]. (Iv) máximo
esfuerzo dinámico:
Aquí no
verificación de plausibilidad se realiza. Se hace un mayor esfuerzo para
cumplir con los plazos y las tareas puede ser abortado. Sin embargo,
los enfoques de la fecha más temprana para Primera (FED) y el mínimo
laxitud primero (MLF) suelen ser óptima cuando no hay sobrecargas.
La investigación sobre las condiciones de sobrecarga está todavía en
su infancia. Fecha más temprana primero (FED) de programación
puede programar sistemas de tiempo real, tanto estáticas como
dinámicas. Análisis de viabilidad para EDF se puede realizar en En 2) tiempo,
donde
norte es el número de tareas [7]. A diferencia de EDF, FML da cuenta de
los tiempos de ejecución de tareas. (V) Programación con tolerancia a fallos: Un
primario
horario será dirigido por el plazo si no hay un fracaso y un
horario secundaria se ejecutará en el plazo en caso de fallo.
Dicha técnica permite degradación elegante pero incurre en
coste de la ejecución de otro programa.
En los sistemas de tiempo real,
peor de los casos de bloqueo debe ser minimizado para tolerancia a fallos.
(Vi) La programación de la reivindicación del recurso:
los
tiempo de ejecución de la tarea real puede ser más corta
que la determina a priori debido a condicionales
o peor de los casos ejecución
supuestos. El despachador tarea puede tratar de recuperar esos
pantalones, en beneficio de las tareas en tiempo no real o mejores
garantías de puntualidad.
4 RTOSs comercial
En esta sección, seleccionamos un destacado RTOS comerciales para cada clase
de aplicaciones en tiempo real y se discuten sus características. Para los
dispositivos de memoria pequeña windows CE se ha discutido, para sistemas de
tiempo real, LynxOS, para aplicaciones embebidas VxWorks, Jbed para la
plataforma Java y de pSOS para un sistema operativo orientado a objetos. Pero
en primer lugar, se indican las capacidades comunes de estos sistemas
operativos.
• Eficiencia: La mayoría de RTOSs son micro-granos con baja sobrecarga. En
algunos, casi no hay cambio de contexto se incurre en gastos indirectos en el
envío de un mensaje al proveedor de servicio del sistema.
• sistema no apropiable llama: Ciertas porciones de llamadas de sistema
son no apropiable para el apoyo mutuo
S. Beskiyar et al.
exclusión. Estas partes están optimizados, hecho como determinista
como sea posible.
• priorizado la programación: Para compatibilidad POSIX, todos ofrecen
RTOSs al menos 32 niveles de prioridad. El número de niveles de prioridad
van de 32-512.
• control de la inversión de prioridad: Un medio de inversión de prioridades
manipulación.
• apoyo a la gestión de la memoria: Apoyo a la gestión de memoria
virtual existe, pero no necesariamente paginación. Los usuarios se
les ofrece opciones entre múltiples niveles de protección de
memoria.
4.1 windows CE
Windows CE [ 13] es un portátil sistema operativo embebido en tiempo real modular
para la pequeña memoria, dispositivos de 32 bits móviles.
windows CE tiempo rebanadas CPU entre hilos y proporciona 256 niveles de prioridad.
Para optimizar el rendimiento, todas las discusiones están habilitadas para funcionar
en modo de núcleo. windows CE kernel tiene las siguientes características:
• Durante la ejecución de código no preferente en el núcleo, tampón
look-aside traducción ( TLB) Se evitan fallos moviendo todos los
datos del núcleo en la memoria física.
• Kcalls, todas las porciones no apropiables del kernel, se rompen en
pequeñas secciones reducir la duración del código no apropiable.
• Todos los objetos de núcleo (tales como procesos, hilos, tramos
críticos, mutexes, eventos y semáforos) se asignan dinámicamente
en la memoria virtual.
• Para un transporte, una capa de adaptación equipos aísla rutinas
dependientes de dispositivo. El fabricante del equipo puede
especificar los módulos y procesos fiables para impedir que las
aplicaciones no autorizadas accedan a
aplicación del sistema programación
interfaces.
4.2 LynxOS
LynxOS [10] es un sistema operativo compatible con POSIX, multihilo diseñado para
aplicaciones en tiempo real complejos que requieren una respuesta rápida y
determinista. Es escalable desde grandes sistemas de conmutación hacia abajo a
productos de pequeño incrustado. El micro-kernel puede programar, las interrupciones
de despacho, y sincronizar las tareas. Otros servicios ofrecidos por los módulos de
servicios del núcleo de peso ligero, son TCP / IP arroyos, sistemas de E / S y de
archivo, tomas de corriente, etc. En respuesta a una interrupción, el kernel envía un
núcleo
hilo, que puede ser
priorizado y programada similar a otros hilos. La prioridad de la interrupción del
hilo de manipulación kernel es la prioridad del subproceso de usuario que
maneja el dispositivo de interrupción. Este mecanismo garantiza respuesta
predecible incluso en presencia de pesada I / O. El sistema operativo depende
de la unidad de gestión de memoria de hardware para la protección de
memoria, pero ofrece la paginación bajo demanda opcional.
Eso
utiliza políticas de planificación FIFO como prioridad, fecha límite
programación dinámica monótona, tiempo compartido, etc.
Tiene 512 niveles de prioridad y es compatible con la operación remota.
UN ESTUDIO DE CONTEMPORÁNEO ...
4.3 VxWorks
VxWorks [21] es un RTOS ampliamente adoptado en el embebido
industria con una visual desarrollo
ambiente. Es escalable, con más de 1.800 APIs y está disponible en
plataformas de CPU populares. Ofrece soporte de red, sistema de
archivos y gestión de E / S. El núcleo micro- admite 256 niveles de
prioridad, la multitarea, el cambio de contexto determinista y
programación robin preventivo y redondo,
semáforos y mutua
exclusión con herencia. TCP, UDP, tomas de corriente y los servicios de red
estándar de Berkeley pueden ser escalados dentro o fuera de la pila de red
según sea necesario. Se puede configurar para que cada tarea tiene una
memoria virtual privada bajo petición.
Para un transporte un paquete de compatibilidad Junta interactúa
con la capa dependiente del hardware.
4.4 Jbed
Jbed [ 6] es un sistema operativo de tiempo real para sistemas embebidos.
Es compatible con las aplicaciones y los controladores de dispositivos
escritos en Java. En lugar de interpretar los códigos de bytes, Jbed
traduce byte-codes en código máquina antes de la carga de clases. Su
arquitectura modular permite la carga dinámica de código y la escala de
pequeño a dispositivos de alto rendimiento.
Es compatible con la asignación de memoria en tiempo real, gestión de
excepciones y la destrucción automática de objetos. aplicaciones de tiempo real son
compatibles a través de las bibliotecas de clases específicas. Es compatible con diez
niveles de prioridad de hilo y la programación FED.
Jbed La luz es una versión más pequeña para aplicaciones rápidas y precompilados.
Contiene los componentes básicos tales como la máquina virtual núcleo, un pequeño
conjunto de bibliotecas estándar de Java, y el Jbed bibliotecas necesarias para acceder
directamente a los periféricos.
Las llamadas máquinas virtuales Java son
implementado en el kernel. Esto evita la necesidad de una interfaz nativa de
Java lenta, se necesita otra manera de hacer llamadas al sistema. Las
versiones actuales apoyan ARM7, 68k y las arquitecturas PowerPC.
4.5 de pSOS
Los objetos, en de pSOS orientados a objetos, incluyen tareas, las regiones de
memoria, colas de mensajes y semáforos.
horarios tareas de prioridad preventiva impulsada o FED y se ocupa de la inversión de
prioridades tanto por la herencia de prioridad y el protocolo de prioridades techo. El
desarrollador de aplicaciones tiene el control total sobre la gestión de interrupciones.
tareas del usuario también pueden funcionar en el modo de supervisión. Los
controladores de dispositivos pueden ser cargados dinámicamente. Una región de
memoria es un bloque contiguo de memoria física, creado en respuesta a una llamada
desde una aplicación. de pSOS asigna regiones de memoria a las tareas. Como otros
objetos, una región de memoria puede ser local o global.
Informatica 29 ( 2005) 233-240 237
4.6 sistemas operativos de propósito general
En esta sección, describimos características en tiempo real de dos sistemas
operativos de propósito general populares: Windows NT y Unix, la Tabla 1
muestra una comparación 1.
windows nativo
característica en tiempo real
NT Unix
, Multitarea preventiva basada en la Sí Sí
prioridad
hilos de interrupción diferidos Sí No
prioridades no degradantes Sí No
Los bloqueos de memoria Sí Sí
Tabla 1. características en tiempo real de Windows NT y Unix
• Derecho preferente de compra: Aunque núcleo de Windows NT es no apropiable
hay puntos dentro del núcleo donde se permite el derecho de prioridad. En
tiempo real Unix también permite que los puntos de derecho de prioridad dentro
de las llamadas al sistema.
• Llamadas a procedimiento diferido (DPC): DPC se pone en cola las llamadas a
funciones del modo kernel para ser ejecutados más tarde. Son utilizados por los
conductores para programar las operaciones de E / S, que no necesariamente
tienen que tener lugar en una rutina de servicio de interrupción a un alto nivel de
interrupción y se pueden posponer de forma segura hasta que el nivel ha bajado.
Tal mecanismo permite que el servicio de interrupciones dentro de interrupciones,
si el procesador deshabilita las interrupciones futuras cuando se está dando
servicio una interrupción.
• prioridades no degradantes: Para asegurar la imparcialidad, el sistema
manipula continuamente prioridades de los hilos en Unix y Windows NT. Sin
embargo, Windows NT proporciona una banda de prioridades de interrupción
que no pueden ser alterados. En consecuencia, existen dos tipos de
prioridades de los hilos: una clase en tiempo real y una clase dinámica. las
discusiones de clase en tiempo real funcionan con prioridades fijas que no se
alteran por el núcleo. Hay 16 niveles de prioridad en la clase en tiempo real.
Sin embargo, cualquier hilo dado se limita sólo a un subconjunto de
prioridades en el intervalo de (+ o -) 2 niveles de su prioridad inicial, pero no
más allá del conjunto de prioridades de su clase. Aunque Windows NT
proporciona tiempos de respuesta rápidos, que no es tan determinista como
un RTOS duro [11] debido a las llamadas a procedimiento diferido. Desde
Eso
subprocesos de usuario tienen prioridad más baja que DPC o ISR, ratón y
teclado manipuladores pueden adelantarse procesos urgentes. También, DPC
no se apropiado por otros DPC / hilos. Por otra parte, el desarrollador no tiene
control sobre los conductores de terceros.
Desde núcleo de Windows NT no admite la herencia de prioridad, pueden
producirse bloqueos. No es compatible con la puesta en cola prioritaria para la
comunicación entre hilos. En otras palabras, si varios subprocesos están
bloqueados a la espera de un recurso, que tendrán acceso en lugar de FIFO
orden de prioridad a diferencia de un RTOS.
1 Aunque Windows NT no estaba destinado a ser un RTOS se ha
utilizado como uno en algunos casos.
238 Informatica 29 ( 2005) 233-240
4.7 Otro RTOS comercial
La Tabla 2 enumera otra RTOSs comercial común y sus características
principales con respecto a los requisitos básicos de un RTOS discutidos en la
Sección 2. Todos los productos abajo utilizan un esquema FIFO priorizado para la
programación.
4.8 núcleos de investigación
Ahora discutiremos tres núcleos en tiempo real, extensible micro-kernel para
sistemas distribuidos en tiempo real embebidos (esmeraldas), La primavera y el
Arx para proporcionar una visión general del alcance y el tipo de investigación en
curso en el campo de la RTOS. Otros núcleos de investigación prominentes
incluyen Quimera (de la Universidad Carnegie Mellon), Armonía (de National
Research Council de Canadá) y Maruti (de la Universidad de Maryland).
EMERALDS está diseñado para pequeñas y los sistemas integrados de tamaño
medio [24]. Al trazar el núcleo en cada espacio de usuario. Por lo tanto, una
llamada al sistema no necesita ningún cambio de contexto. nivel de usuario pilas
de protocolos de comunicación y controladores de dispositivos se pueden añadir
sin modificar el kernel. Utiliza prioridades estáticas y programación dinámica. Un
usuario puede elegir la prioridad de un hilo sobre la base de la tasa monotónica,
fecha límite monotónica u otro esquema de prioridad fija. Es compatible con 32
bits prioridades por parte de no-hilo único establecimiento de la prioridad de un
hilo a su fecha límite, EDF programación se puede lograr. La prioridad se puede
modificar de forma dinámica a través de una llamada del sistema para apoyar la
planificación dinámica FED. Los mecanismos IPC se comparten memoria y el
paso de mensajes a través de los buzones de correo. Una de las prioridades de
32 bits se asigna a cada mensaje que se puede utilizar para ordenarlos para
recuperar el mensaje de mayor prioridad en primer lugar. Arx [16] emplea hilos de
nivel de usuario para la programación, la comunicación y multihilo. Consiste en las
discusiones virtuales y una la programación de eventos llamada ascendente mecanismo.
Virtual
hilos proporcionan un entorno de ejecución de nivel de núcleo para
subprocesos de usuario. Ellos son entidades pasivas que están obligados
temporalmente a las discusiones a nivel de usuario cuando sea necesario. los la
programación de eventos llamada ascendente mecanismo permite que el kernel para
notificar a los procesos de usuario de eventos del núcleo, tales como bloqueo de rosca y
la expiración del temporizador. A nivel de usuario de E / S permite a los programadores
escribir controladores de dispositivos flexibles y eficientes para dispositivos patentados.
los Primavera kernel [18] proporciona soporte en tiempo real para sistemas distribuidos.
Se puede programar tareas dinámicamente basándose en el tiempo de ejecución y las
limitaciones de recursos. Por lo tanto la necesidad de a priori calcular el peor de los casos
tiempo para tareas de bloqueo se evita. It horarios de la seguridad operacional tareas
más importantes usando una tabla estática. El núcleo ayuda a retener suficientes
semántica de aplicación para mejorar la tolerancia a fallos y el rendimiento de las
sobrecargas.
Es compatible tanto
aplicación y previsibilidad a nivel de sistema. Resorte soporta abstracción para
grupos de proceso [19], que proporciona un alto nivel de granularidad y un
mecanismo de comunicación de grupo en tiempo real. Procesos dentro de un
“grupo de procesos” en Primavera trabajar hacia un objetivo común. Primavera
soporta un lenguaje de descripción del sistema, lo que permite
S. Beskiyar et al.
programadores para predefinir grupos e imponen limitaciones de tiempo y de
precedencia sobre ellos. Es compatible tanto
grupos de multidifusión síncrona y asíncrona. logra
previsible nivel bajo repartido
la comunicación a través de memoria replicado a nivel mundial. Proporciona
abstracciones de reserva, la planificación y de extremo a extremo sincronización de la
ayuda. Una comparación de las características de Arx, esmeraldas y
Primavera muestran que todos ellos incorporan la mayoría de las recomendaciones
básicas de POSIX 1003.1 b. Sin embargo, la característica de archivos en tiempo real
no se ha incorporado en cualquiera de los núcleos de investigación anteriores.
5 Conclusión
En este trabajo se revisaron los requisitos básicos de un RTOS incluyendo
las características 1003.1b POSIX. el POSIX
estándar 1003.1b no aborda apoyo para los búferes de tamaño fijo y
multiprocesamiento heterogéneo. El diseño de un sistema embebido utilizando un
RTOS puede ayudar a reducir el costo y el tiempo de comercialización. Si una
aplicación tiene requisitos de tiempo real, un RTOS proporciona un marco
determinista para el desarrollo de código y portabilidad. Para satisfacer las
necesidades de las aplicaciones multimedia comerciales, el tamaño del código de
bajo y es necesaria la integración periférica alta. La fiabilidad de los sistemas
complejos en tiempo real se puede lograr utilizando las especificaciones de varios
niveles que verifican la exactitud de los sistemas en tiempo de compilación y
tiempo de ejecución.
6 referencias
[1] Bola SR, Embedded sistemas de microprocesadores: Diseño del
mundo real, Tercera edición, Newnes, 2002. [2] GD Carlow,
“Arquitectura del Sistema de traslado software de aviónica Primaria
espacio”, CACM, v 27, no. 9, 1984. [3] H.Gomaa, Software de Diseño
Los métodos para sistemas concurrentes y en tiempo real, Primera
edición, Addison-Wesley, 1993. [4] S.Heath, Embedded Systems
Design, Segunda edición, Newnes, 2002. [5] Operativo IEEE
Tecnología de la Información-portátil
System Interface (POSIX) -Part1: [6] Interfaz de programación de aplicaciones del
sistema, la norma ANSI / IEEE
Std 1003.1, Edición de 1996. Jbed RTOS,
http://www.esmertec.com , Acceso el 15 de Nov del 2004.
[7] PA Laplante, Real-Time Systems Diseño y análisis: el Manual
del ingeniero, Segunda edición, IEEE Press, 1997. [8] CL Liu y
Layland JW, “algoritmos de planificación de multiprogramación
en un entorno de tiempo real,” Diario de la ACM, v. 20, no. 1,
pp. 46-61, 1973. [9] JWS Liu, sistemas de tiempo real, Primera
edición, Prentice Hall, 2000. [10]
LynxOS, http://www.lynuxworks.com,
Consultado el 15 de Nov, 2004 [11]
microsoft ventanas NUEVO TESTAMENTO,
http://www.microsoft.com , Consultado el 10 de Nov, de 2004
UN ESTUDIO DE CONTEMPORÁNEO ... Informatica 29 ( 2005) 233-240 239

RTOS, Vendedor Enhebrar mecanismos de prevención de prioridad de anfitriones de desarrollo, de almendra

niveles Y sincronización inversión previsto características
PRIORIT

AMX, Kadak Ventanas, memoria predecible disponibilidad

N / A buzones; Espere- Sí
Products Ltd. solicitudes de reactivación bloque

C Ejecutivo, JMI
Los mensajes, las colas de
Software Systems, 32 Sí Windows, Solaris
datos dinámicos
Inc.

CORTEZA, Windows / Unix, CPU-independiente

en tiempo real recursiva cabellos, Sí, utiliza el techo de gestor de interrupción de software; estática y
62
australiana Embedded mutex prioridad dinámicamente modelos de memoria segmentada
Systems.

Delta OS, C oreTek Semáforos,

Systems, Inc. 256 temporizadores, colas de Sí Windows, Linux.
mensajes

Windows, Linux Para

Ecos Semáforos, temporizadores y Sí, utiliza el techo de
1-32 suave tiempo real incrustado
RedHat, Inc. contadores prioridad
aplicaciones en dispositivos pequeños

Realzar Windows, Linux, perfilado para recoger información de

Buzón, binario
Sistemas de tiempo para cada tarea; tarea de tiempo de activación
255 y semáforo No
microcontroladores independiente del número de tareas.
contador
Segger.

ERTOS Entre hilos de mensajes, Windows, DOS, OS / 2. interrupción de alta velocidad

JK Microsystems, Inc. 256 colas, semáforos No impulsada rutinas de puerto serie

Semáforos, puntos de
INTEGRIDAD interrupción se pueden colocar Se utiliza en aplicaciones embebidas críticos; orientado a
Sí, mutex,
Greenhills 255 en cualquier lugar objetos; soportes distribuidos
semáforo
Software, Inc. el sistema tratamiento; tarea de perfiles de ejecución.
que incluye ISR.

IRIX SGI, doble precisión de apoyo de matriz;

255 Las colas de mensajes Sí
1.1.1.1.1 SGI escalabilidad multi-tubo

nuclear Plus
tubería
Accelerated N / A buzones, Sí Ventanas.
y colas
Technology, Inc.
OS-9
Microware y
65535 semáforo Sí Ventanas.
Systems colas
Corporation.
Windows, Solaris, Linux. Definida por el usuario resolución
OSE reloj del sistema; tolerante a fallos;
32 Paso de mensajes Sí
Sistemas de OSE. adecuado para la telefonía celular
aplicaciones.
RT-Linux Sí, bloquee las estructuras de
Memoria compartida oa través Linux; soportes difícil tiempo real
Finitos Máquina de 1024 datos gratuitas y
de archivos aplicaciones
Estados laboratorios. techo de prioridad

Sí, mediante la
ThreadX Exclusiones mutuas, desactivación de preferencia
encima

Expresar Logic, Inc. 32 semáforos de conteo y rangos de prioridades y por Ventanas.

mensajería la herencia de prioridad

Windows, Solaris, Linux, multiprocesador

QNX Neutrino simétrico Los sistemas. cada sistema operativo
Sí, utilizando la herencia de
QNX Software 64 Paso de mensajes componente se ejecuta en su propio espacio de direcciones
prioridad
Systems Ltd. protegida MMU-

Tabla 2. Características de comercial RTOSs

240 Informatica 29 ( 2005) 233-240 S. Beskiyar et al.

[12] L. Molesky, C. Shen, G. Zlokapa, “predecible 7 Expresiones de gratitud

Los mecanismos de sincronización para multiprocesador Sistemas
En este trabajo se ha desarrollado mientras que el primer autor enseñaba
de Tiempo Real,”monedas, Universidad de Massachusetts, Informe
clases en tiempo real y computación empotrados en los últimos años. Como
Técnico 90-30, 1990.
tal, varios estudiantes dentro de estas clases ayudaron generosamente en
[13] C. Muench, la tecnología Windows CE
esta obra a la que el primer autor está muy agradecido. El primer autor
Tutorial: Soluciones de Windows Desarrollado para el desarrollador,
también agradece al Dr. James H. Cruz, Departamento de Ciencias de la
Primera edición, Addison Wesley, 2000. [14]
Computación e Ingeniería de Software de la Universidad de Auburn, Auburn,
R. Ortega, “La previsibilidad sincronización en tiempo real
AL para la revisión de este documento. Este trabajo fue apoyado en parte por
Systems,” Reporte técnico, Departamento de Ciencias de la Computación de la
un número de la National Science Foundation Grant 0408136 y 0411540
Universidad de Washington, 1994. [15]
subvención interna y la Universidad de Auburn.
K. Ramamritham y JA Stancovic,
“Programación de Algoritmos y Sistemas de Soporte de
funcionamiento para sistemas en tiempo real”, Actas de la IEEE, pp.
55-67, Jan 1994. [16]
HY Seo, y J.Park. “ARX / ULTRA: Un Nuevo 8 Biografía
Real-Time Kernel Arquitectura para Apoyar el usuario Nivel
S. Baskiyar es Profesor Adjunto en el Departamento de Ciencias de
Hilos,”Informe Técnico SNU-EE-TR1997-
la Computación e Ingeniería de Software de la Universidad de
3, Facultad de Ingeniería Eléctrica, Universidad Nacional de Seúl,
Auburn, Auburn, Alabama. Sus líneas de investigación están en las
1997. [17]
áreas de programación de tareas de Clusters, Arquitectura de
A. Silberschatz, Galvin PB y G. Gagne,
Ordenadores y Sistemas Embebidos. Ha publicado numerosos
Operating Systems Concepts, Sexta edición, John Wiley, 2001.
trabajos en el área de Programación de tareas de Clusters. Recibió
[18]
el doctorado y MSEE de la Universidad de Minnesota, Minneapolis y
JA Stankovic y K. Ramamritham, “The
el BE (Electrónica y Comunicaciones) grado en el Instituto Indio de
Primavera Kernel: Un nuevo paradigma para duros en tiempo real
Ciencia, Bangalore. Recibió la licenciatura en física con honores y
sistemas operativos,”ACM Sistemas Operativos Review, vol. 23, no. 3,
distinción en Matemáticas. Recibió el Estado competitiva en el mérito
pp. 54-71, 1989. [19]
y el Instituto Indio de Ciencia becas. Ha impartido cursos en tiempo
M. Teo, “Un análisis preliminar de la primavera y el
real y Embedded Computing, Informática
POSIX 4,”Primavera documento interno de 1995, disponible
a http: // www-
cs.umass.edu/spring/internal/spring-kernel-docs.html [20]
Arquitectura, Operando sistemas,
The Open Group, http://www.opengroup.org/ ,
La programación del microprocesador y Interconexión y Diseño
Consultado el 10 de Nov, 2004 [21]
VLSI. Su experiencia incluye trabajar como profesor adjunto en la
VxWorks, http://www.windriver.com, Consultado el 10 de Nov,
Universidad de Western Michigan, como Ingeniero de Software
2004 [22]
Senior en el Unisys Corporation y como Ingeniero Asistente de
C. Walls, “RTOS para el microcontrolador
Informática en Ingeniería y Tata Locomotive Company Ltd., India.
Aplicaciones “, Ingeniería Electrónica, vol. 68, no.
831, pp. 57-61, 1996.
N. Meghanathan recibió el grado de Maestría en
[23] Y. Zhang, sin bloqueo de sincronización:
Ciencias de la Computación de la Universidad de Auburn, Auburn, AL en
Algoritmos y Evaluación del Desempeño, Ph.D. Tesis,
2002. Obtuvo la Licenciatura en Ingeniería Química de la Universidad de
Chalmers University of Technology, Suecia, 2003. [24]
Anna, Chennai, India. Él fue asistente de investigación en el Departamento
de Ciencias de la Computación e Ingeniería de Software de la Universidad de
KM Zuberi y KG Shin, “EMERALDS: A
Auburn.
-Pequeña de memoria en tiempo real micro-kernel,”IEEE Trans. en
Ingeniería de Software, vol. 27, no. 10, pp. 909-928, octubre de 2001.