Sistemas Operativos de

Tiempo-Real y empotrados

• Definición de RTS y RTOS.

• Definición de sistema empotrado.
• Funcionalidad y características.
• Planificación y kernels.
• Estándares.
• Ejemplos: QNX y RT-Linux.
© José Antonio Gómez Hernández,
2004
 Definición de RTS

Un sistema de tiempo-real (RTS) es un

sistema de información que procesa
entradas asíncronas y produce salidas de
un tiempo determinado y acotado.
Entrada Proceso Salida
∆t

Debe ser determinista - el tiempo

requerido puede calcularse a partir de la
carga del sistema, y debe ser acotado.
Es importante el tiempo de ejecución del
peor caso.

DSO 2
 Definición de Sist. empotrado
Muchos STR son partes de otros sistemas
en los que se realizan operaciones de
control, en estos caso, hablamos de
sistemas empotrados o embebidos
(embedded).
Este tipo de sistemas suelen estar
limitados en cuanto a los recursos
disponibles y no suelen ser visibles.
Ejemplos: teléfonos móviles, radios, tv,
sists. de control de automóviles o
aviónica, electrodomésticos, etc.
DSO 3
 Mercado de los sists.
empotrados
La venta de procesadores en 2001:
Ordenadores personales: 100 millones
de unidades
Procesadores empotrados: 300 millones
DSP: 600 millones
Microcontroladores: 8000 millones.
Como curiosidad:
Un teléfono móvil de última generación tiene más
de 1 millón de líneas de código.
Los costes de un avión relacionados con el
software suponen un 50%
El 90% de las innovaciones en automóviles las
proporcionan los sistemas electrónicos. Por
ejemplo, un automóvil moderno puede tener 1000
micro-controladores/procesadores.
DSO 4
 Relación STR/SE
No es lo mismo un STR que un SE lo que
ocurre es que actualmente hay una fuerte
convergencia cada vez mayor:

STR SE

STR + SE

DSO 5
 Caracteríscas de un RTS
Aspectos ligados al software.
Solución: descomposición.
Las principales características básicas de un
RTS son: Número asociados a
magnitudes físicas
Tamaño y complejidad asociadas al sistema
controlado.
Fiabilidad y seguridad – temasRepresentación
siguientes
aproximada. Se
Cálculo con número reales generan alarmas si
Sistema determinista:
algún dato toma un
-Tiempo en el que realizan
Interacción con dispositivos físicos
valor incorrecto.
ciertas acciones.
-Tiempos de terminación de
Eficiencia cada acción.
-Responder a situaciones
Dependencia del tiempo
Atención de eventos
transitorias enenlasparalelo.
que no
Uno o varios
pueden procesadores
garantizar los plazos.
Concurrencia Los ejecutivos cíclicos son más difíciles
de descomponer,
Tolerancia a fallos – tema siguiente corregir, programar,
…
DSO 6
Tareas independietes a nivel de SO y
 Características de un SE
Deben posee una huella pequeña – un SOE suele
utilizar un par de KB de RAM y ROM. Permite dar más
prestaciones con procesadores menos potentes.
Debe ejecutarse durante mucho tiempo sin
intervención humana – tanto hard/soft deben ser
tolerantes a fallos. Es preferible no utilizar
componentes mecánicos.
Pueden controlar dispositivos mecánicos cuyo fallo
puede ser catastrófico
Una gran autonomía implica poco consumo de
potencia.
Re-arranque autónomo si no hay operador humano
en un estado seguro y de la manera más rápida.
Debe ser lo más barato posible – fabricación en
grandes cantidades.
DSO 7
 Estructura general de un RTS

Subsistema Subsistema Subsistema

controlado de control operador

Interfaz de Interfaz
aplicación Hombre-máquina

DSO 8
 El subsistema de control

Aplicación Tareas cooperantes

API
Sistema Gestión de interrupciones, E/S, 
Operativo Gestión de Hebras , y
Gestión de memoria

Hardware CPU CACHE DISPOSITIVOS

DSO 9
 El hardware

En un RTS, el hardware necesita ser

determinista.
Algunos elementos que no dan respuestas
de RT:
El uso de encauzamientos y predicción
de saltos en los procesadores actuales
introduce latencias impredecibles.
El uso de caches añade sobrecarga de
ejecución cuando se produce una falta
de caché. Esto hace impredecibles los
periodos del peor caso para cambios de
espacio de direcciones y hebras
Dispositivos como tarjetas de red que
DSO utilizan Ethernet como protocolo no son 10
 Aplicaciones de tiempo-real
Suelen modelarse como un conjunto de
tareas cooperantes.
Podemos clasificar estas tareas como:
Tareas de tiempo-real duras – una
tarea crítica debe completarse en un ∆t
garantizado para que el resultado no
sea catastrófico.
Tareas de tiempo-real blandas – son
menos restrictivas, y solo requieren
recibir más prioridad sobre las menos
críticas, ya que el sistema se puede
recuperar si no se cumple un plazo.
Tareas no de tiempo-real – no tienen
plazos.
DSO 11
 Tareas de aplicación
Otra clasificación de las tareas de aplicación:
Tareas periódicas – se ejecutan a
intervalos regulares.
Tareas aperiódicas o asíncronas – su
tiempo de ejecución no puede anticiparse,
si no que esta determinado por la
ocurrencia de un evento (interno o
externo)
Tareas esporádicas – tareas aperiódicas
con plazos duros.
DSO 12
 SOs de tiempo-real (RTOS)

La característica principal de un RTOS, al

igual que en un TRS, es que es
determinista, es decir, garantiza que el
sistema software se ejecutará dentro de
una restricción temporal especificada.
Podemos clasificarlos como:
Kernels propietarios: QNX, LynxOS,
VRTX32, VxWorks, ...
Extensiones de TR de SOs comerciales:
RT-Unix, Solaris,
Kernels de investigación: MARS, ARTS,
CHAOS, ...
DSO GPL: RTLinux, KURT, … 13
 Paradigmas de diseño de
RTOS
RTOS activados por
eventos - cualquier
actividad es iniciada
en respuesta a la
ocurrencia de un RTOS activados por
evento particular tiempo -las
causado por el actividades del
entorno del sistema. sistema se inician
como instantes
predefinidos de un
tiempo
DSO globalmente 14
 Temas básicos
Los dos puntos cruciales en un RTOS:
Algoritmo de planificación – Su
responsabilidad es determinar un orden
de ejecución de las tareas de TR que
sea factible (que satisfaga los requisitos
de tiempo y recursos para esas tareas.
El kernel del sistema – que suministra
las primitivas y características básicas
para una sincronización y comunicación
eficientes, respuesta garantiza a las
interrupciones, sistema de archivos
DSO rápido y fiable, y eficiente gestión de 15
 Planificación de tiempo-real
La elección del algoritmo de planificación
depende de muchos factores:
# procesadores y características
( homogéneos o heterogéneos),
relaciones de precedencia entre tareas de
la aplicación,
método de sincronización,
naturaleza de la aplicación (apropiativa o
no).

DSO 16
 Taxonomía de planificación

Planificación de tiempo-
real
Uniprocesadores Multipocesadores/Distribuida

Estática
(Razón Dinámica Enumerativa
Teoría de
monótona) grafos Teoría de
colas
Heurística Probabilística
Aperiódica EDF/MLFMUF
Computación Aproximada
imprecisa
Inversión de Compartición
prioridad de recursos Robo de ciclo/
sobrecarga

DSO 17
 Ejemplo de algoritmos
Como algoritmos de planificación podemos
utilizar variaciones del SJF (Primero el Más
Corto):
EDF (Earliest-deadline First) – Divide los
trabajos por plazos, selecciona primero el
trabajo con el plazo más próximo
Razón monótona – asigna prioridades
inversamente al periodo.

DSO 18
 Características de un buen
RTOS*
Debe ser multihebrado y apropiativo.
Poseer un tamaño pequeño
Cambio de contexto rápido y respuesta
rápida a las interrupciones.
Minimizar el tiempo en el que esta
deshabilitadas las interrupciones.
Planificación por prioridades ya que no
existen SOs controlados por plazos.
Debe existir mecanismos de sincronización
predecibles.
Debe existir un mecanismo de herencia de
prioridad.
Gestión de memoria que no afecte a la
(*)www.dedicated-
predicibilidad.
systems.com/encyc/publications/faq/rtfaq.html
DSO 19
 Parámetros de fabricación
De acuerdo con las anteriores característica
de fabricante de un RTOS debe especificar
claramente los siguientes parámetros:
Latencia de interrupción.
Tiempo máximo de realización de una
llamada.
Tiempo máximo que el SO y los
manejadores enmascaran las
interrupciones.
Niveles de interrupción del sistema.
Niveles IRQ de los manejadores, el tiempo
máximo que toman, ...

DSO 20
 Lantencias

Por ejemplo, en QNX:

Pentium a 166MHz → Til= 3.3 µs ; Tsl=2.93 µ
s
486DX4 a 100MHz → Til= 5.6 µs ; Tsl=11.1
µs
DSO 21
 Latencia de planificación

❑ Tsl viene determinado por dos factores:

Tiempo necesario para apropiar a la
◆
hebra en ejecución ➨ los kernel deben
ser apropiativos.
◆ Al apropiar a la hebra en curso,
debemos liberar los recursos que utiliza
si estos van a ser usados por la hebra
Sucesomás prioritaria. Si esto no ocurre se
Tiempo de respuesta dice
Respuesta
que se ha producido inversión de
prioridad. Latencia de despacho
Procesamiento Proceso
interrupción Conflicto Despacho

Tiempo
DSO 22
 Inversión de prioridad,
o ¿qué paso en Marte?
Fenómeno que se da cuando no atendemos a una
hebra/proceso de acuerdo a la prioridad que tiene.
Se produce cuando un proceso (o hebra) de cierta
prioridad, P2, se ejecuta antes que otra de mayor
prioridad, P1, debido a que P1 espera por un recurso
que tiene bloqueado otro proceso, P3.
Se solventa a través de:
Protocolo de herencia de prioridad – lo veremos en
breve.
Protocolos de tope (ceiling protocols).

DSO 23
 Inversión de prioridad

P3
Prioridad=10
Recurso

Posee
Solicita

DSO 24
 Inversión de prioridad

Sea P1 que se desbloquea o se crea ­> 
P1 se ejecuta por tener mayor prioridad

P3 P1
Prioridad=10 Prioridad=20
Recurso
Ejecutánse ­>Preparada Preparada –>Ejecutarse

Posee
Solicita

DSO 25
 Inversión de prioridad

P1 solicitar recurso: si no se puede apropiar P3, 
entonces P1 se bloquea

P3 P1
Prioridad=10 Prioridad=20
Recurso
Preparada Ejecutándose

Posee
Solicita

DSO 26
 Si aparece un P2 con prioridad mayor que P3, 
entonces P2 se ejecuta

P3 P1 P2
Prioridad=10 Prioridad=20 Prioridad=15
Recurso
Preparada Bloqueada Ejecutándose

Posee
Solicita

DSO 27
 Herencia de prioridad
Una hebra tiene dos prioridades: su prioridad global y
la heredada. El valor de prioridad para planificar una
hebra es el mayor de estos números.
Cuado una hebra se bloquea en un recurso lega
(presta) su prioridad a la hebra poseedora del
recurso.
La propiedad de herencia de prioridad es transitiva.

P3 P1 P2
Pglobal=10 Pglobal=20 Pglobal=15
Pheredada=20 Recurso Pheredada= 0 Pheredada=0
Ejecutándose Ejecutándose Preparada

Posee
Solicita
DSO 28
 Estándares
POSIX 1003.1b (antiguo 1003.4):
incluye funciones para:
E/S síncronas y asíncronas
Primitivas IPC
Habilidad para bloquear y mantener
memoria
Planificación por prioridades
Archivo de tiempo real, y
Cronómetro.
TROM (The Real-time Operating-system
Nucleus). Consta de varios
subproyectos entre ellos:
ITROM – especificación del RTOS para
sistemas empotrados e industriales,
DSO µITROM - microprocesadores y 29
 Evaluación de rendimiento
Existen tres métodos generales:
Benchmarks de grano fino o medidas del
comportamiento de kernel a bajo nivel,
que evalúan el comportamiento hard-soft
de las primitivas más frecuentemente
utilizadas – Rhealstone.
Bechmarks orientados a la aplicación que
dan una visón de mayor nivel como
número de plazos perdidos. Hartstone.
Evaluación basadas en simulación

DSO 30
 Ejemplos de RTOS
Existen multitud de RTOS en el mercado,
pero no todos están bien documentados.
Algunos de los más documentados son:
QNX (www.qnx.com)
Linux de tiempo-real:
(www.realtimelinux.org)
• RATAI
• RTLinux
• Kurt....

DSO 31
 RTOS conforme
POSIX1.b que suministra
multitarea, planificación
apropiativa controlada
por prioridades, y un
rápido cambio de
contexto.
QNX es muy flexible en
cuanto a configuración
ya que está construido
sobre un microkernel,
denominado Neutrino.
DSO 32
 Estructura de QNX

El µkernel solo realiza

planificación y paso de
mensajes.
Servicios
implementandos como
procesos de sistema:
 Proc,: Gestor de
procesos.
 Fsys: Gestor de
archivos.
 Dev: Gestor de
DSO
dispositivos. 33
 Interfaz gráfica (Photon)

 Construida como un µkernel

y una serie de procesos
cooperantes.

Bajo requerimiento de
memoria .
Flexible y extensible.
Conectividad entre
plataformas.
DSO 34
 Linux

Linux esta diseñado para optimizar el

rendimiento medio y tratar de repartir
imparcialmente la CPU, no considera el
peor caso. Por ello no es adecuado en
tiempo-real. En concreto:
Planificación no predecible (depende de
la carga).
Resolución baja de cronómetros (10ms).
Kernel no apropiativo.
Deshabilita interrupciones como
mecanismo de sincronización.
Planificación oculta
DSO Utiliza memoria virtual. 35
 Linux (cont.)
Linux soporta parcialmente el estándar
POSIX.1b. Implementa funciones para:
Control del planificador – políticas
SCHED_FIFO, SCHED_RR y SCHED_OTHER.
Existen 100 niveles de prioridad. Podemos
determinar el mánimo y mímino nivel de
cada política con
sched_get_priority_min() y
sched_get_priority_max() , así como el
tiempo del cuanto con
sched_rr_get_interval().
Bloqueo de memoria
Esto permite sólo algunas aplicaciones de
tiempo real soft.
DSO 36
 Cronómetros
Resolución de cronómetros y relojes:
La resolución real de Linux es de 10 ms (1
jiffy).
Los mecanismos de notificación de tiempo
(mitades inferiores, colas de tareas o
interrupciones software) introducen
impredecibilidad.
Existen modificaciones de Linux, UTIME, que
suministran resolución de microsegundos.

DSO 37
 Real-time Linux (RT-Linux*)
Se construye un kernel de tiempo-real bajo
Linux. De esta forma, Linux se convierte en
una tarea del kernel de tiempo-real que se
ejecuta sólo cuando no hay tareas de
tiempo-real. Por otra parte, apropiamos
Linux, cuando hay tareas de tiempo-real que
necesitan la CPU.
El kernel de tiempo real es no apropiativo, y
su retraso máximo de planificación en un
Pentium 129 es menor de 20 µs.

(*) http://luz.cs.nmt.edu/index.html
DSO
http://bernia.disca.upv.es/ 38
 Características
SO de tiempo-real estricto.
Extensiones para SMP
Uso de un API próxima al estándar de hebras
POSIX: planificación, señales, sistema de
archivos, semáforos y variables de condición.
Depuración mediante gdb.
Acceso directo al hardware
Comunicación con los procesos mediante
memoria compartida y cauces.
Resolución de tiempo próxima al
microsegundo.
Mecanismo para incorporar nuevos
componentes:
DSO GNAT, LightWeight IP, … 39
 Arquitectura de RT-Linux

Interrupción
Tarea de tiempo­real
software

DSO 40
 Relación entre RT-Linux y
Linux
RT-Linux no es un código independiente, es
decir, no es una nueva versión de Linux.
Cada versión de RT-Linux esta diseñda para
funcionar sobre una versión de Linux. Por
ejemplo, RT-Linux Versión 3 necesita un
kernel de Linux 2.4.48 o superior.
Parte de la distribución de RTLinux es un
parche para la correspondiente versión de
Linux, y, otra parte, es un conjunto de
módulos cargables.

DSO 41
 Emulación de interrupciones

Linux deshabilita las interrupciones

como medio de sincronización. No hay
forma de acotar el tiempo que estas
están deshabilitadas.
Solución: Emulación de interrupciones –
El estado de las interrupciones Linux lo
mantiene el emulador en una variable.
Si Linux tiene habilitadas las
interrupciones, el emulador le notifica
inmediatamente la ocurrencia de ellas.
Si no, el emulador las encola para
notificárselas cuando vuelva a
DSO habilitarlas. 42
 Macros de emulación
S_CLI : S_IRET:
push %ds
movl $0, SFIF
pushl %eax
pushl %edx
S_STI : movl $KERNEL_DS,
%edx
sti
mov %dx, %ds
pushfl cli
pushl $KERNEL_CS movl SFREQ, %edx
pushl $1f andl SFMASK, %edx
bsfl %edx, %eax
S_IRET jz 1f
1: S_CLI
sti
jmp SFIDT (,%eax,4)
1:
movl $1, SFIF
popl %edx
popl %eax
popl %ds
iret
DSO 43
 Las tareas de tiempo-real
Estas tareas tienen las siguientes
características:
Comparten el espacio de memoria del
núcleo.
No pueden hacer uso de llamadas al
sistema.
Se ejecutan en modo kernel: acceso a
cualquier instrucción y puerto de E/S.
Las páginas de memoria de código y datos
no pueden ser intercambias a disco.
DSO
Asignación estática de recursos (no 44
 Estructura de una aplicación
RT Fifo
User Process
RT Fifo

X Windows Linux Kernel

RT Process

Display Disk Network

Peripheral Device

Principal inconveniente: hay que partir las

aplicaciones en una parte no de tiempo-real (se
ejecuta como proceso de usuario) y la parte de
tiempo-real (se ejecuta como tarea de tiempo-real).
La comunicación entre un proceso Linux y uno de
tiempo-real se hace a través de dos FIFOS de
DSO tiempo-real (una tarea no se bloquea al leer/escribir
45
 “Hola Mundo” en RTLinux (i)
pthread_t thread;
void * start_routine(void * arg) {
...
}

int init_module(void) { Estructura del módulo:

return pthread_create(&thread, NULL, Rutina de arranque
start_routine, 0); Rutina de inicialización
} Rutina de descarga

int cleanup_module(void) {
pthread_delete(thread);
}

DSO 46
 “Hola Mundo” (y ii)
 void * start_routine(void *arg) {
Identificador de la hebra
  struct sched_param p;
Tiempo actual
  p.sched_priority = 1;
  pthread_set_attr_schedparam(pthread_self(),
  SCHED_FIFO, &p);
  pthread_make_periodic_np(pthread_self(),
  gethrtime(), 500000000);
  while (1) {
  pthread_wait_np();
  rtl_printf(“Hola Mundo !\n”);
  }
  return 0;
 }

Establece parámetros de planificación

Permite despertar a una hebra de forma periódica
Suspende la ejecución de la hebra invocante

DSO 47
 Planificación
El planificador es en si mismo un módulo
cargable
Planificador apropiativo basado en
prioridades asignadas estáticamente.
Se planifica la tarea de tiempo-real
preparada con mayor prioridad.
El kernel de Linux puede ser visto como una
tarea de tiempo-real con la mínima prioridad.
Otras posibles políticas de planificación son
EDF y RM (vistas con anterioridad)
DSO 48
 Temporización
Debemos establecer un punto de consenso
entre la gestión de la interrupción de reloj y
la deriva (jitter – diferencia entre el tiempo
en que debe planificarse una tarea y el
instante en el que realmente se planifica)
Solución: programamos en chip de reloj para
que interrumpa a la CPU en el mismo
instante en que debemos planificar el evento
(modo un-disparo).
El tiempo global es la suma de todos los
intervalos entre interrupciones.
Se sigue simulando el tick de 10 ms.
DSO 49
 SOs para PDAs
Algunos SOs para PDAs (Personal Digital
Assistants):
Comerciales:
• Windows CE
• Symbian OS
• Palm OS
• ….
Bajo licencia libre:
• Sistemas Linux: RTLinux, RATAI, µ
CLinux, EtLinux
• Sistemas no-Linux: Adeos, eCos, RT-
DSO EMS, Jaluna, Fiasco y DROPS, … 50
 Conceptos básicos
El segmento de mercado que describimos recibe el
nombre de WID (Wireless Information Device), y
comprende desde PDAs (computador de manos libres
+ comunicaciones ocasionales) a teléfonos móviles
(comunicación de voz + soporte de libro de
direcciones y mensajes).
El segmento tiene características que lo hacen
especial:
Los dispositivos son pequeños y móviles
Es un mercado de masas de consumidores,
empresas y profesionales
Los fabricantes deben diferenciar sus productos al
objeto de innovar y competir en un mercado de 51
DSO
 Características de los SOs
Respecto al SO, no es suficiente reducir el
tamaño de un sistema operativo para PC o
dotar de comunicaciones a un SO básico.
Debemos abordar:
Proceso de arranque rápido
Respuesta inmediata para cambiar de una
tarea a otra.
Operaciones de copias de seguridad y
sincronización eficientes.
Por ello, es adecuado utilizar un RTOS.
DSO 52
 Windows CE: características
Sistema dividido en 220
Huella de memoria reducida
módulos (exe/dll). Cada uno
dividido en varios
Enfoque modular componentes (archivos LIB).
Los componentes son
ROMables, y comprimibles
Portabilidad del procesador
(Ejecución
Soporta 5 de ROM o flash).
procesadores:
Win32 compatibilidad ARM/StrongARM, MIPS, PPC,
SuperH, X86
Herramientas de desarrollo integrales
Soporta un subconjunto de la
Conectividad API Win32
Procesamiento de tiempo real
-ActiveSync: sincronización
activa entre el PC de sobremesa
y el dispositivo CE.
-Remote API: Control remoto del
dispositivo desde un aplicación
DSO en el PC 53
 Windows CE: arquitectura
Applications

Embedded Shell
Remote 
Connectivity
Windows CE Shell Services

WIN32 APIs
COREDLL, WINSOCK, OLE, COMMCTRL, COMMDLG, WININET, TAPI

Kernel Device  File

GWES
Library Manager Manager
IrDA TCP/IP
OAL Device 
Drivers File drivers
Bootloader drivers

OEM Hardware

DSO 54
 Symbian OS: características
Extremadamente eficiente respecto de la
potencia – consume la mitad o un tercio
respecto de otros sistemas.
Código muy compacto y pequeña huella lo
que permite una mayor adaptación al
consumidor (mejorando a Windows CE).
Aunque se puede portar a otras plataformas
utiliza como base la arquitectura ARM (que
considera la mejor plataforma en términos
de MIPS por vatio y coste).

DSO 55
 Arquitectura de SymbianOS

DSO 56