Professional Documents
Culture Documents
Tiempo-Real y empotrados
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
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
DSO 9
El hardware
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
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
Bajo requerimiento de
memoria .
Flexible y extensible.
Conectividad entre
plataformas.
DSO 34
Linux
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 tiemporeal
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
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;
}
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
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