1

Desarrollo de software para STR

2

Desarrollo de software para STR

© Las características específicas de los STR condicionan los métodos y herramientas utilizados para desarrollar el software

© No todas las técnicas que se usan para construir otros tipos de sistemas sirven para el software de tiempo real3 suele haber problemas de fiabilidad y determinismo temporal

© Nos centraremos en los lenguajes de programación y sistemas operativos

3

Sistemas operativos

© Los sistemas operativos convencionales no son adecuados para realizar sistemas de tiempo real3 son versiones modificadas de S.O de tiempo compartido3 no tienen un comportamiento determinista3 no permiten garantizar los tiempos de respuesta

© Las características particulares de estos sistemas3 Multitarea mediante system call

G No tienen en cuenta el tiempoG Introducen retardos ilimitados en el tiempo de ejecución de las tareas

3 Planificación basada en prioridadesG Flexible

• Permite implementar diferentes estrategias para manejar procesosmodificando la regla para asignar prioridades

4

Sistemas operativos

G Dificultad en proyectar las restricciones temporales en un conjunto de prioridades

• Tienen un número limitado de niveles de prioridad mientras que los plazos de finalización pueden variar en un plazo más amplio

• En entornos dinámicos la llegada de una nueva tarea puede necesitar la modificación completa del conjunto de prioridades

3 Respuesta rápida a interrupciones externasG Solución

• Prioridades para interrupciones más altas que para procesos• Reducir el código ejecutado con interrupciones inhabilitadas

G Problemas• Retardos ilimitados en la ejecución de los procesos• Un proceso siempre será interrumpido por un driver• No se puede determinar de antemano el número de interrupciones que sufrirá

un proceso

5

Sistemas operativos

3 Mecanismos para la comunicación y sincronización entre procesosG Sincronización de tareas y exclusión mutua en recursos compartido

mediante semáforosG Si no hay protocolos para entrar en secciones críticas pueden provocar

problemas como inversión de prioridades, bloqueo encadenado y deadlock

3 Núcleos (kernel) pequeños y cambios de contexto rápidosG Reduce los gastos del sistemasîmenor tiempo medio de respuesta îno

garantiza los deadlines de las tareas individualesG Kernel pequeño î menor funcionalidad

3 Reloj de tiempo realG Característica esencial pero acompañada de mecanismos adicionales para

el manejo de tiempo como• Primitivas para especificar explícitamente las restricciones temporales • Activación automática de tareas periódicas

6

Sistemas operativos

© En general, las características de diseño de STR3 Garantizar la correcta ejecución de todas las tareas hard3 Administrar el uso de recursos compartidos3 Ofrecer un buen tiempo de respuesta a las tareas que no tengan plazo

de finalización3 Recuperación ante fallos software o hardware3 Soportar los cambios de modo

3 Eficiente en los cambios de contexto y tiempos de respuesta a interrupciones

7

Factor Sist de Tiempo Compartido

Sist de Tiempo Real

Capacidad Alto rendimiento

Plazos finalización garantizados

Grado de respuesta

Rápida respuesta media

Asegurado el tiempo respuesta en

el peor caso Respuesta a sobrecarga

Igualdad

Estabilidad

S. Tiempo Compartido vs S. Tiempo Real

Sistemas operativos

8

© STC3 Mejorar las prestaciones para el caso medio3 La capacidad del sistema se mide por su rendimiento medio3 Conseguir un tiempo de respuesta medio que sea rápido3 Igualdad

© STR3 Asegurar que el comportamiento del peor caso es aceptable

3 La capacidad del sistema se mide por su planificabilidad G habilidad de las tareas para cumplir todas las hard deadlines

3 Mejorar el tiempo de respuesta para peor caso en tareas con hard deadlines

3 Estabilidad en situaciones de sobrecarga G el sistema satisface las deadlines críticas incluso si no puede satisfacer

todas las deadlines

Sistemas operativos

9

Sistemas operativos

© Predicibilidad3 Basándose en las características del kernel y en la información

asociada a cada tarea el sistema debe de ser capaz de G Predecir la evolución de las tareasG Garantizar de antemano que se cumplirán todas las restricciones

temporales críticas

3 Depende deG Características de la arquitectura del hardware

• Prebúsqueda de instrucciones, pipelining, memoria caché, DMA

G Mecanismos y políticas del kernel• Algoritmo de planificación, semáforos, políticas de manejo de memoria, de

interrupciones

G Lenguaje de programación

10

Sistemas operativos

© DMA3 Si CPU y dispositivo DMA necesitan un ciclo de memoria , el bus se

asigna al dispositivo DMA y la CPU debe esperar (cycle stealing)3 No hay forma de predecir cuántas veces la CPU debe esperar3 Solución: time-slice method

G Cada ciclo de memoria se divide en dos: uno reservado para DMA y otro para CPU

© Caché3 80% de las veces los datos están en caché y las operaciones de

escritura degradan el rendimiento3 Para hacer análisis del peor caso se supondría

G fallo en caché para cada acceso a memoria (Procesador sin caché o no habilitada)

G Estimar el tiempo de ejecución con un modelo matemático de la caché

11

Sistemas operativos

© Interrupciones3 Se sirven de acuerdo a un esquema de prioridades fijas, asignándole

una prioridad más alta que a los procesos3 Tres planteamientos

G Inhabilitar las interrupciones externas excepto la del timer y manejar los dispositivos manejados por tareas de aplicación

• Baja eficiencia del procesador

G Inhabilitar las interrupciones externas excepto la del timer y manejar los dispositivos mediante rutinas dedicadas del kernel que se activan de forma periódica por el timer

• Espera ocupada de las rutinas que manejan I/O

G Habilitar las interrupciones y reducir los drivers al menor tamaño posible• Cada driver activará una tarea que se encargará de manejar el dispositivo• Se asigna una prioridad a la tarea que maneja cada dispositivo que es

independiente de otras prioridades

12

Sistemas operativos

© Llamadas al sistema3 Cada llamada caracterizada por un tiempo de ejecución limitado3 Se debe poder expropiar cada primitiva del kernel (preemptable)

© Semáforos3 Plantean problemas de inversión de prioridades, que introducen

retardos no deterministas3 Se deben utilizar protocolos particulares cada vez que una tarea quiere

entrar en una sección críticaG Basic Priority Inheritance, Priority Ceiling, etc.

©Manejo de memoria3 Evitar esquemas de paginación bajo demanda

G Introducen retardos no deterministas debido a fallos de página yreemplazos de páginas

13

Sistemas operativos

© Un sistema operativo de tiempo real debe soportar3 Concurrencia

G procesos ligeros (threads) con memoria común

3 TemporizaciónG medida de tiempos, manejo de tareas con restricciones temporales y

ejecución periódica

3 PlanificaciónG prioridades fijas con desalojo, acceso a recursos con protocolos de

herencia de prioridad

3 Dispositivos de E/ S G acceso a recursos de hardware e interrupciones

14

Sistemas operativos: POSIX

© Es un conjunto de normas IEEE/ ISO que definen interfaces de sistemas operativos

© Permiten desarrollar software portátil y reutilizable ( PortableOperating System Interface) + X

© Las normas definen servicios que se pueden incluir o no en un sistema operativo particular

© Además se definen perfiles de aplicacióncon conjuntos de servicios estándar

© Hay interfaces para C, Ada, y otros lenguajes

15

Normas POSIX

© POSIX 1, 1a Interfaz básica similar a UNIX™© POSIX 1b, 1d, 1i, 1j Extensiones de tiempo real© POSIX 1c Procesos ligeros (threads)© POSIX 1e Seguridad© POSIX 1f NFS© POSIX 1 g Servicios de red (sockets, XTI)© POSIX 1h Tolerancia de fallos© POSIX 21 Comunicaciones de tiempo real© POSIX 5,5a, 5b Interfaces para Ada

16

Perfiles de aplicación POSIX

© Definen subconjuntos de servicios para distintos tipos de aplicaciones

© POSIX 13 : Perfiles para sistemas de tiempo real3 PSE50 : sistema de tiempo real mínimo

G sin gestión de memoria, ficheros ni terminalG sólo threads (procesos no pesados)

3 PSE51 : controlador de tiempo realG tiene sistema de ficheros y terminal

3 PSE52 : sistema de tiempo real dedicadoG tiene gestión de memoria y procesos pesados

3 PSE53 : sistema de tiempo real generalizadoG sistema completo con todo tipo de servicios

17

S.O de Tiempo Real

© VRTX (Versatile Real-Timer Executive)© VX Works© QNX© RTEMS (Real Time Executive for Military Systems)© RT-MACH© CHORUS© SPRING© HARTOS©MARS© CHAOS (SO de TR orientado a objetos)© RT-Linux (SO de TR de libre distribución)

18

S.O de Tiempo Real

© Kernel basado en prioridades para aplicaciones empotradas3 VX Works, QNX, Chorus, VRTX32, pSOS, OS9, ...

© Extensiones de tiempo real para S.O de tiempo compartido3 RT-UNIX, RT-LINUX, RT -MACH, ...

© Sistemas operativos de investigación3 CHAOS (SO de TR orientado a objetos), MARS, Spring, ARTS, RK,

TIMIX, HARTOS, YARTOS, HARTIK,...

© RTEMS (Real Time Executive for Military Systems

19

Lenguajes de programación

© Un lenguaje de programación de sistemas de tiempo real debe facilitar la realización de sistemas3 concurrentes (simultaneidad de acciones)3 fiables3 con un comportamiento temporal analizable

© Características de un Lenguaje de programación de TR3 Debería forzar al programador a especificar límites de tiempo y

excepciones de timeout en todos los bucles, esperas y estamentos de acceso a dispositivos

3 Ausencia de estructuras de datos dinámicas3 Ausencia de recursividad 3 Bucles limitados por tiempo

20

Lenguajes de programación

© Hay tres clases de lenguajes de interés para STR3 Lenguajes ensambladores

G Flexibles y eficientes, pero costosos y poco fiables

3 Lenguajes secuenciales (Fortran, Pascal, C, ...)G Necesitan un SO para concurrencia y tiempo real

3 Lenguajes concurrentes (Modula, Ada, Real-Time Euclid...)G Concurrencia y tiempo real incluidos en el lenguaje

21

Lenguajes de programación: C

© Es un lenguaje muy utilizado para programación de sistemas© Es un lenguaje

3 estructurado, con bloques3 con escasez de tipos3 muy flexible (pero a veces poco seguro)

© No tiene integrada la concurrencia ni el tiempo real3 se consigue invocando servicios del sistema operativo de forma

explícita

© No facilita la descomposición en módulos ni la programación con objetos3 se puede hacer con C++ (una extensión de C para programar con

objetos)

22

Lenguajes de programación: ADA

© Es un lenguaje diseñado específicamente para sistemas de tiempo real empotrados3 concurrencia3 tiempo real3 acceso al hardware e interrupciones

© Es un lenguaje imperativo, descendiente de Pascal3 estructura en bloques

3 fuertemente tipado

© Está pensado para construir sistemas grandes y cambiantes3 paquetes (módulos) y esquemas genéricos3 extensión de tipos con herencia3 biblioteca jerárquica3 interfaces normalizadas con otros lenguajes (C, Fortran)

23

Lenguajes de programación: ADA 95

© Es la versión actual normalizada de Ada© La norma define

3 un núcleo común para todas las implementaciones3 unos anexos especializados para

G programación de sistemasG sistemas de tiempo realG sistemas distribuidosG sistemas de informaciónG cálculo numéricoG fiabilidad y seguridad

3 Los anexos definenG paquetes de bibliotecaG mecanismos de implementaciónG no añaden sintaxis ni vocabulario al lenguaje