Tema3

SOs de tiempo-real y embebidos

Diseo de Sistemas Operativos(cc) Jos Antonio GmezCurso 2013-14

33

18/02/14 2

ndice Definiciones

RTS y RTOS Definicin de sistema embebido

Funcionalidad y caractersticas Planificacin y kernels Estndares Ejemplos:

Linux para tiempo-real Linux para embebidos

DSO 3

Un sistema de tiempo-real (RTS) es un sistema de informacin que procesa entradas asncronas y produce salidas de un tiempo determinado y acotado.

Debe ser determinista - el tiempo requerido puede calcularse a partir de la carga del sistema, y debe ser acotado.

Es importante el tiempo de ejecucin del peor caso.

Definicin de RTS

ProcesoEntrada Salida

t

DSO 4

Modelo de STR

DSO 5

Tipos de RTS y tareas

Hard Real-time Systems garantizan que una tarea de tiempo-real se completa en su plazo.

Soft Real-time Systems solo garantizan que una tarea de tiempo-real crtica recibe ms prioridad que otras tareas (menos restrictivo).

Safety-critical systems sistema de tiempo-real con resultados catastrficos en caso de fallo.

DSO 6

Jitter (desviacin) Jitter = error cometido en la

temporizacin de una tarea en subsecuentes iteraciones de un programa o bucle

Un RTS esta optimizado para obtener un jitter bajo cuando se programa correctamente. Una tarea tomar siempre un tiempo de ejecucin similar cada vez que se ejecuta.

DSO 7

Tareas de aplicacin

Clasificacin de las tareas de aplicacin: Tareas peridicas se ejecutan a intervalos

regulares. Tareas aperidicas o asncronas su tiempo

de ejecucin no puede anticiparse, si no que esta determinado por la ocurrencia de un evento (interno o externo)

Tareas espordicas tareas aperidicas con plazos duros

DSO 8

Definicin de sistema embebido. Muchos sists. de computacin son partes de otros

sistemas en los que se realizan operaciones de control, en estos caso, hablamos de sistemas embebidos (embedded) o empotrados.

Este tipo de sistemas suelen estar limitados en cuanto a los recursos disponibles y no suelen ser visibles.

Ejemplos: telfonos mviles, radios, tv, sists. de control de automviles o avinica, electrodomsticos, etc

DSO 9

Ejemplos de sistemas Industriales: sistemas de control como SCADA (Supervisory Control

And Data Acquisition) que monitoriza y controla numerosos enventos distribuidos de inters, p. ej. EMS (Energy Management System).

Mdicos: robot para material radioactivo Perifricos: impresoras laser. Automvil: Sistemas de inyeccin de carburante multipunto. Telecomunicaciones: sistemas celulares y telfonos mviles. Aeroespaciales: navegacin asistida por computador. Internet y multimedia: video-conferencia Defensa: sistemas de guiado de misiles. Miscelanea: sistema de reserva de billetes, monitores de

transacciones.

DSO 10

Mercado de sists. embebidos Como curiosidad:

Un telfono mvil de ltima generacin tiene ms de 1 milln de lneas de cdigo.

Los costes de un avin relacionados con el software suponen un 50%

El 90% de las innovaciones en automviles las proporcionan los sistemas electrnicos. Por ejemplo, un automvil moderno puede tener 1000 micro-controladores/procesadores.

DSO 11

Entorno de desarrollo

DSO 12

Relacin STR/SE

Si bien no es lo mismo un STR que un SE, actualmente existe una convergencia creciente entre ambos.

Fuente: B. Weinberg y C. Lundholm, Embedded Linux Ready for Real-time, Montavista Software, White Paper, 2001

DSO 13

Caractersticas de un RTS Propsito sencillo no necesita todas las

caractersticas de un SO de propsito general. Pequeo tamao del software y el hardware

(poca memoria, CPU mnima, ...) Produccin en masa barata Diseado para

minimizar costes, p. ej. SoC. Requisitos de tiempo especficos diseo de

algoritmos de tiempo-real y minimizar el tiempo de respuesta a las interrupciones.

DSO 14

Caractersticas de un RTOS En general, su determinismo establece que no necesita soporte de:

Gran cantidad de perifricos, p. ej. CD, discos duros, etc. Mecanismos de seguridad y proteccin, incluida Memoria Virtual Mltiples usuarios.

Necesitamos: Planificacin apropiativa basada en prioridades Kernels apropiativos Mnima latencia de despacho Precio libre de royalties Herramientas de integracin (IDE) Cobertura de procesadores Buen soporte y documentacin API estndar

DSO 15

Caractersticas de un SE Deben posee una huella (footprint) pequea un SOE suele utilizar un par

de KB de RAM y ROM. Permite dar ms prestaciones con procesadores menos potentes.

Debe ejecutarse durante mucho tiempo sin intervencin humana tanto hard/soft deben ser tolerantes a fallos. Es preferible no utilizar componentes mecnicos.

Pueden controlar dispositivos mecnicos cuyo fallo puede ser catastrfico Una gran autonoma implica poco consumo de potencia. Re-arranque autnomo si no hay operador humano en un estado seguro y

de la manera ms rpida. Debe ser lo ms barato posible fabricacin en grandes cantidades. Debe soportar enlazado dinmico configuracin remota.

DSO 16

RTOS: clasificacin Podemos clasificarlos como:

Kernels propietarios: QNX, LynxOS, VRTX32, VxWorks, ...

Extensiones de TR de SOs comerciales: RT-Unix, Solaris,

Kernels de investigacin: MARS, ARTS, CHAOS, ...

GPL: RTLinux, KURT,

DSO 17

Caractersticas de un RTOS*

(*)www.dedicated-systems.com/encyc/publications/faq/rtfaq.html

Debe ser multihebrado y apropiativo. Poseer un tamao pequeo Cambio de contexto rpido y respuesta rpida a las interrupciones. Minimizar el tiempo en el que esta deshabilitadas las interrupciones. Planificacin por prioridades ya que no existen SOs controlados por plazos. Debe existir mecanismos de sincronizacin predecibles. Debe existir un mecanismo de herencia de prioridad. Gestin de memoria que no afecte a la predicibilidad. Acceso rpido a los archivos

DSO 18

Parmetros de fabricacin

De acuerdo con las anteriores caracterstica de fabricante de un RTOS debe especificar claramente los siguientes parmetros: Latencia de interrupcin. Tiempo mximo de realizacin de una llamada. Tiempo mximo que el SO y los manejadores

enmascaran las interrupciones. Niveles de interrupcin del sistema. Niveles IRQ de los manejadores, el tiempo mximo

que toman, ...

DSO 19

Requisitos de rendimiento RTOS

DSO 20

Latencias y principales problemas

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

Figura extada de http://www.cs.ru.nl/lab/xenomai/exercises/ex10/Exercise-10.html

Spin-lockDeshabilitar IRQIRQ compartidas

Til

Tsl

Prioridad kernel

Inversin deprioridad

Apropiacin

DSO 21

Latencia de planificacin

Tiempo de respuestaLatencia de despacho

Conflicto Despacho

Suceso Respuesta

Procesamientointerrupcin

Proceso

Tiempo

Tsl viene determinado por dos factores: Tiempo necesario para apropiar a la hebra en ejecucin 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 ms prioritaria. Si esto no ocurre se dice que se ha producido inversin de prioridad.

DSO 22

Ejemplo de algoritmos de planificacin

Como algoritmos de planificacin sencillos podemos utilizar variaciones del SJF (Primero el Ms Corto): EDF (Earliest-deadline First) Divide los trabajos por plazos, selecciona

primero el trabajo con el plazo ms prximo. Razn montona asigna prioridades inversamente al periodo.

Existe una gran multitud de algoritmos: ver http://en.wikipedia.org/wiki/Real-time_operating_system#Algorithms o A. Mohammadi y S.G. Akl, Scheduling Algoriths for Real-Time Systems, Technical Report No. 2005-499, Queen University, Ontario, Canada, 2005.

DSO 23

Inversin de prioridad, o qu paso en Marte?

Fenmeno 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 travs de: Protocolo de herencia de prioridad. Protocolos de tope (ceiling protocols).

DSO 24

Inversin de prioridad

P3Prioridad=10

Recurso

PoseeSolicita

DSO 25

Inversin de prioridad (ii)

P1Prioridad=20

P3Prioridad=10

Recurso

PoseeSolicita

Preparada >Ejecutarse

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

Ejecutnse ->Preparada

DSO 26

Inversin de prioridad (iii)

P1Prioridad=20

P3Prioridad=10

Recurso

PoseeSolicita

Ejecutndose

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

Preparada

DSO 27

Inversin de prioridad (y iv)

P1Prioridad=20

P2Prioridad=15

P3Prioridad=10

Recurso

PoseeSolicita

BloqueadaPreparada

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

Ejecutndose

DSO 28

Herencia de prioridad

P1Pglobal=20

Pheredada= 0

P2Pglobal=15

Pheredada=0

P3Pglobal=10

Pheredada=20 Recurso

PoseeSolicita

Ejecutndose PreparadaEjecutndose

Una hebra tiene dos prioridades: su prioridad global y la heredada. El valor de prioridad para planificar una hebra es el mayor de estos nmeros.

Cuando 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. El diseo en Linux lo podemos ver en Documentation/rt-mutex-

design.txt.

DSO 29

Estndares POSIX 1003.1b (antiguo 1003.4): Estndar de SO de propsito

general con extensiones de tiempo-real que incluye funciones para: E/S sncronas y asncronas Primitivas IPC Habilidad para bloquear y mantener memoria Planificacin por prioridades Archivos de tiempo real, y Cronmetros.

TROM (The Real-time Operating-system Nucleus). Consta de varios subproyectos entre ellos: ITROM especificacin del RTOS para sistemas empotrados e industriales, ITROM - microprocesadores y microcontroladores de bajo coste.

OSEK para sistemas de automocin. APEX para sistemas avinicos.

DSO 30

Linux como SOTR

Vamos a estudiar las posibilidades de Linux para su adopcin como SOTR: Versiones hasta la 2.6 Extensiones de tiempo-real

DSO 31

Linux con (s)RTOS

Podemos catalogarlo como un Soft Real-time OS.

Esta optimizado para tener: Un buen tiempo medio de respuesta Una alta productividad

Adecuado para: Aplicaciones multimedia VoIP Video/Audio Streamming

DSO 32

Linux como RTOS Principales caracterstica para soportar RT:

Dos polticas de planificacin de RT: FIFO (SCHED_FIFO) RR (SCHED_RR)

Gestin rpida de IRQ (manejo en 2 etapas) Responsividad alta (cronmetros de alta resolucin, 1000

Hz ticks, ) Kernel apropiativo Bloqueo de memoria (mlockall()) Seales de tiempo-real (32 -SIGRTMIN- a 64 -SIGRTMAX)

.. pero qu hay de la predecibilidad?

DSO 33

Linux como (H) RTOS Algunos caminos kernel no pueden ser apropiados Las interrupciones se deshabilitan en las secciones

crticas de muchos manejadores. Gestin de ISRs no predecible: ack rpido a los

dispositivos, pero la duracin de la mayora de manejadores bottom-half es no predecible.

La gestin de IRQ no considera prioridades. Latencias de planificacin bastante altas para

procesos en modo usuario para HRT.

DSO 34

Cmo solventar estos problemas

Enfoque monokernel: Cambios realizados en los fuentes del kernel para alcanzar los requisitos

de tiempo-real El porte debera hacerse a travs de las versiones Principalmente comerciales: TimeSys, MontaVista Linux, etc. Tambin fuentes abiertas: parche PREEMPT_RT (Igno Molnar)

Enfoque kernel dual: Los cambios con locales: simplifica el porte. Nuevas (complejas) capas intermedias entre el hardware y el SO que

manejan los requisitos de tiempo-real, de forma que el SO no afecta a las tareas de tiempo-real.

Principalmente fuentes abiertas: RTAI, RTLinuxFree PaRTiKle, Xenomai Pero tambin comerciales: Wind River Real-time Core Linux

DSO 35

Enfoque kernel dual

Ideas: Insertar una capa

de abstraccin hardware entre HW y OS.

Ejecutar Linux como un proceso normal de baja prioridad sobre un planificador de RT.

DSO 36

Enfoque kernel dual Pros:

Baja latencia en IRQ Manejo predecible de IRQ Polticas fiables de RT (FIFO,

RR, RM, EDF,...) Cambio de tareas rpido Politicas de asignacin de

recursos que tienen en cuenta la prioridad

Mecanismos de sincronizacin ad-hoc

Contras: Podemos perder las

caractersticas de RT al llamar a funciones de las bibliotecas estndares.

Debemos permanecer en el kernel: las llamadas a funciones de biblioteca no RT estn prohibidas.

Los manejadores deben se adaptados para RT

Uso de API no conforme (a veces, propietaria)

Comunicacin limitada con aplicaciones estndares de Linux.

DSO 37

Comparacin

Fuente: Berger, 2010

DSO 38

Soporte nativo kernel para HTR

A partir de la versin 2.6.23, podemos explotar algunas caractersticas del kernel para HTR: Polticas de planificacin de tiempo-real CPU affinity (IRQ y task affinity) CPUsets y sched_domain

DSO 39

Afinidad de la CPU

El mecanismo de afinidad permite ligar una tarea RT y sus interrupciones relacionadas a una CPU, evitando que otras tareas o IRQs se ejecuten en esta CPU.

Este camino ha sido seguido por Asymmetric MultiPorcessor-Linux que permite alcanzar: Tiempo de ejecucin determinista Baja sobrecarga del sistema Alto rendimiento y responsividad

DSO 40

Afinidad de CPU y CPUsets Podemos asignar IRQs y tareas a una CPU:

Procfs permite asignar interrupciones a una CPU La llamada sched_setaffinity puede usarse para asignar una

tarea a una CPU Cpuset ofrece ms flexibilidad:

Suministra un mecanismo para asociar un conjunto de CPUs (y nodos de memoria) con un conjunto de tareas.

Todas las tareas hijas se ejecutan automticamente en el mismo conjunto que su padre.

DSO 41

Cpusets y real-time Un cpusets define un dominio de planificacin que incluye a todas

las CPUs de un cpuset. El equilibrio de carga se realiza slo dentro de un sched_domain. Cpusets permiten fcilmente controlar las distribucin de tareas (y

aislamiento) sobre las CPUs del sistema. Esto se suele utilizar en multiprocesadores para tiempo-real.

Usado junto con IRQ afinidad puede asegurar el aislamiento de las tareas de tiempo-real en el sistema.

DSO 42

Cuestiones por resolver

Apropiar el kernel en los caminos ms crticos.

Asignar prioridades a los manejadores de IRQ.

Solucin: Parche de tiempo-real apropiativo desarrollado por Igno Molnar continuando con el parche de Montavista, e integrado en el mainline kernel 2.6.23.

DSO 43

Real-Time Preemption Patch Los principales cambios que introduce son:

El parche permite opcin de configuracin apropiacin total (los caminos kernel no apropiativos se reducen a menos del 5%).

Cronmetros de alta resolucin: POSIX hrtimers. Protocolos de herencia de prioridad y mejora de los mecanismo de

sincronizacin con Priority Inheritance Mutexes (PI-mutexes y PI-futexes).

Los manejadores IRQs se hebran: todas las softirqs y hardirqs se ejecutan en hebras kernel con una prioridad asignada.

DSO 44

Configuracin Opciones de configuracin:

PREEMPT_NONE modelo convencional de apropiacin para servidores o sistemas de clculo

PREEMPT_VOLUNTARY aade +puntos para reducir la latencia de replanificacin para mejorar la respuesta a costa de una reduccin ligera de rendimiento. Sists. desktop.

PREEMPT todo el kernel apropiativo salvo SC. Desktop o empotrados con latencias de ms.

PREEMPT_BKL reduce la latencia haciendo apropiativo el BKL. Desktops.

DSO 45

Apropiacin: evolucin

Fuente: Montavista

DSO 46

Configuracin (y ii)

DSO 47

Apropiatividad vs. No apropiatividad

(a) MP3 sin apropiacin (b) MP3 con apropiacin

DSO 48

Rendimiento Comparacin entre los tiempos de

respuesta medios y del peor caso en kernel 2.4 y 2.6

Fuente: linuxfordevices.com

DSO 49

Latencia de apropiacin

DSO 50

Linux: manejo interrupciones

Fuente: Montevista

DSO 51

Nueva gestin interrupciones

Fuente: Montevista

DSO 52

IRQ como hebras

Las IRQs hebradas pueden (des)habilitarse mediante: Lnea de rdenes: hardirq_preemt=0/1 /proc: /proc/sys/kernel/hardirq_preemption

Igual para las softiqr.

DSO 53

Hebrar una IRQ

request_irq() crea una hebra e incluye nuestra funcin:if (! (new->flags & IRQF_NODELAY)) if (start_irq_thread(irq, desc)) return -ENOMEM;

DSO 54

Hebrar una IRQ (y ii) Creamos la hebra kernel con start_irq_thread():831 static int start_irq_thread(int irq, struct irq_desc *desc)832 {833 if (desc->thread || !ok_to_create_irq_threads)834 return 0;835 836 desc->thread = kthread_create(do_irqd, desc, "IRQ-%d", irq);837 if (!desc->thread) {838 printk(KERN_ERR "irqd: could not create IRQ thread %d!\n", irq);839 return -ENOMEM;840 }841 842 /*843 * An interrupt may have come in before the thread pointer was844 * stored in desc->thread; make sure the thread gets woken up in845 * such a case:846 */847 smp_mb();848 wake_up_process(desc->thread);849 850 return 0;851 }

DSO 55

Bloqueo y apropiacin

El cdigo protegido por cerrojos no es apropiable: Kernel 2.6: 11,000 secciones crticas Labor de prueba y limpieza de SC. No hay control sobre manejadores de

terceros.

DSO 56

RT-mutex o PI-mutex Real-Time mutexes con

herencia de prioridad. Deteccin de

interbloqueos. wait_list esta

ordenada por prioridad: Procesamiento de la lista

constante en tiempo Minimiza latencia para

despertar a una tarea.

struct rt_mutex { spinlock_t wait_lock; struct plist_head wait_list; struct task_struct *owner;};

Funciones: rt_mutex_init() rt_mutex_lock() rt_mutex_unlock() rt_mutex_trylock()

DSO 57

Kernel 2.6: primitivas sincronizacin

Otras primitivas de sincronizacin: RCU (Read-Copy-Update) -mejora el

rendimiento en multiprocesadores. Cuando se va a modificar estructura se hace una copia, se permite el acceso para lectura con la actualizacin de la copia; cuando no hay lectores se desecha la estructura original.

DSO 58

Cuantificar el rendimiento El parche RT permite ciertas medidas de

rendimiento: Latencia de interrupcin Latencia de despacho Histogramas para lo peores infractores

Algunas medidas usan la misma entrada en /proc por lo que solo una de ellas puede estar activa a la vez.

DSO 59

Configurar las medidas

DSO 60

Kernel 2.6 Soporte para NPTL (Native Posix Thread Library) -

Mantiene el modelo 1:1, optimiza clone para la creacin de hebras, relacin peer-to-peer entre hebras, mejor gestin de seales.

DSO 61

Linux 2.6 embebido Asume uCLinux (Linux for Microcontrollers) -

permite construir el kernel sin gestin de memoria virtual (procesadores sin MMU, /linux/mm/nommu.c).

Caractersticas: API de Linux uCkernel < 512 KB; uCkernel + tools < 900 KB Pila TCP/IP completa -- SO empotrado listo para Internet Soporta la mayora de protocolos de red. Soporta numerosos sistemas de archivos: NFS, ext2, ROMfs and

JFFS (Journaling FLASH File System), MS-DOS, and FAT16/32 Audio y video: ALSA (Advanced Linux Sound Architecture) para

facilitar el soporte de dispositivos USB (480 Mb/s de ancho de banda frente a los 12Mb/s actuales) y MIDI

DSO 62

Linux 2.6 embebido(y ii)

Soporte para DVB (Digital Video Broadcasting) Permite 4095 tipos de dispositivos principales y +1 milln de sub-

dispositivos por tipo. Soporte para sistemas de archivos distribuidos:

NFSv4, AFS y Coda, InterMezzo (soportan operaciones desconectadas sobre archivos en cach).

Soporte de la especificacin ACPI (Advanced Configuration and Power Interface) las decisiones de gestin de potencia las toma el SO en lugar de la BIOS (APM).

18/02/14 63

Multi-core en sistemas de tiempo-real y empotrados

El sistemas de tiempo-real con plazos estrictos, la planificacin de tareas no es suficiente para alcanzar predecibilidad. Los eventos y tareas crticas del sistema siguen introduciendo cierta impredecibilidad.

Para tratar este problema se recurre al particionado del sistema vertical u horizontalmente, como vimos al final del tema anterior.

18/02/14 64

Enlaces

Parches de tiempo-real:http://www.kernel.org/pub/linux/kernel/projects/rt/ RT Kernel HOWTO en la RT Wiki:https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO Test RT de Thomas Gleixner:http://www.kernel.org/pub/linux/kernel/people/tglx/rt-tests/

18/02/14 65

Bibliografa S. Rostedt, y D. V. Hart, Internals of the RT Patch,

Proceeding of the Linux Symposium, vol. two, Ottawa, Canada, June 27-30th, 2007.

E. Betti et al. Hard Real-time Performances in Multiprocessor-Embedded Systems Using ASMP-Linux, EURASIP Journal on Embedded Systems, 2008.

S.T. Dietrich y D. Walker, The Evolution of Real-Time Linux, disponible en http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.151.6125

R. Berger, Embedded GNU/Linux and Real-Time an executive summary, Proceeding of Embedded World Conference, Nrnberg, Germany, 2-4th March, 2010.

DSO 66

Para finalizar el tema Los sistemas embebidos se estn utilizando utilizando en

todos los rincones de nuestro espacio de trabajo y vital, lo que esta forzando cada ves ms a construir sistemas confiables (dependables): Fiables (reliabilty) continuidad de servicio correcto Disponibles (availability) preparado para el uso Libres de riesgos (safety) evitar consecuencias

catastrficas en su entorno y/o el operador Seguros (security) evitar accesos no autorizados

... pero esto lo veremos en el tema siguiente.