Download Desarrollo de software para STR

Desarrollo de software para
STR
1
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 real
3 suele haber problemas de fiabilidad y determinismo temporal
© Nos centraremos en los lenguajes de programación y sistemas
operativos
2
Sistemas operativos
© Los sistemas operativos convencionales no son adecuados
para realizar sistemas de tiempo real
3 son versiones modificadas de S.O de tiempo compartido
3 no tienen un comportamiento determinista
3 no permiten garantizar los tiempos de respuesta
© Las características particulares de estos sistemas
3 Multitarea mediante system call
G No tienen en cuenta el tiempo
G Introducen retardos ilimitados en el tiempo de ejecución de las tareas
3 Planificación basada en prioridades
G Flexible
• Permite implementar diferentes estrategias para manejar procesos
modificando la regla para asignar prioridades
3
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 externas
G 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
4
Sistemas operativos
3 Mecanismos para la comunicación y sincronización entre procesos
G Sincronización de tareas y exclusión mutua en recursos compartido
mediante semáforos
G 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ápidos
G Reduce los gastos del sistemas”menor tiempo medio de respuesta ”no
garantiza los deadlines de las tareas individuales
G Kernel pequeño ” menor funcionalidad
3 Reloj de tiempo real
G 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
5
Sistemas operativos
© En general, las características de diseño de STR
3 Garantizar la correcta ejecución de todas las tareas hard
3 Administrar el uso de recursos compartidos
3 Ofrecer un buen tiempo de respuesta a las tareas que no tengan plazo
de finalización
3 Recuperación ante fallos software o hardware
3 Soportar los cambios de modo
3 Eficiente en los cambios de contexto y tiempos de respuesta a
interrupciones
6
Sistemas operativos
S. Tiempo Compartido vs S. Tiempo Real
Factor
Sist de Tiempo
Compartido
Sist de Tiempo
Real
Capacidad
Alto
rendimiento
Plazos finalización
garantizados
Grado de
respuesta
Respuesta a
sobrecarga
Rápida
Asegurado el
respuesta media tiempo respuesta en
el peor caso
Igualdad
Estabilidad
7
Sistemas operativos
© STC
3 Mejorar las prestaciones para el caso medio
3 La capacidad del sistema se mide por su rendimiento medio
3 Conseguir un tiempo de respuesta medio que sea rápido
3 Igualdad
© STR
3 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
8
Sistemas operativos
© Predicibilidad
3 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 tareas
G Garantizar de antemano que se cumplirán todas las restricciones
temporales críticas
3 Depende de
G 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
9
Sistemas operativos
© DMA
3 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 esperar
3 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 rendimiento
3 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é
10
Sistemas operativos
© Interrupciones
3 Se sirven de acuerdo a un esquema de prioridades fijas, asignándole
una prioridad más alta que a los procesos
3 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
11
Sistemas operativos
© Llamadas al sistema
3 Cada llamada caracterizada por un tiempo de ejecución limitado
3 Se debe poder expropiar cada primitiva del kernel (preemptable)
© Semáforos
3 Plantean problemas de inversión de prioridades, que introducen
retardos no deterministas
3 Se deben utilizar protocolos particulares cada vez que una tarea quiere
entrar en una sección crítica
G Basic Priority Inheritance, Priority Ceiling, etc.
© Manejo de memoria
3 Evitar esquemas de paginación bajo demanda
G Introducen retardos no deterministas debido a fallos de página y
reemplazos de páginas
12
Sistemas operativos
© Un sistema operativo de tiempo real debe soportar
3 Concurrencia
G procesos ligeros (threads) con memoria común
3 Temporización
G medida de tiempos, manejo de tareas con restricciones temporales y
ejecución periódica
3 Planificación
G 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
13
Sistemas operativos: POSIX
© Es un conjunto de normas IEEE/ ISO que definen interfaces
de sistemas operativos
© Permiten desarrollar software portátil y reutilizable ( Portable
Operating 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ón con conjuntos de
servicios estándar
© Hay interfaces para C, Ada, y otros lenguajes
14
Normas POSIX
© POSIX 1, 1a
© POSIX 1b, 1d, 1i, 1j
© POSIX 1c
© POSIX 1e
© POSIX 1f
© POSIX 1 g
© POSIX 1h
© POSIX 21
© POSIX 5,5a, 5b
Interfaz básica similar a UNIX™
Extensiones de tiempo real
Procesos ligeros (threads)
Seguridad
NFS
Servicios de red (sockets, XTI)
Tolerancia de fallos
Comunicaciones de tiempo real
Interfaces para Ada
15
Perfiles de aplicación POSIX
© Definen subconjuntos de servicios para distintos tipos de
aplicaciones
© POSIX 13 : Perfiles para sistemas de tiempo real
3 PSE50 : sistema de tiempo real mínimo
G sin gestión de memoria, ficheros ni terminal
G sólo threads (procesos no pesados)
3 PSE51 : controlador de tiempo real
G tiene sistema de ficheros y terminal
3 PSE52 : sistema de tiempo real dedicado
G tiene gestión de memoria y procesos pesados
3 PSE53 : sistema de tiempo real generalizado
G sistema completo con todo tipo de servicios
16
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)
17
S.O de Tiempo Real
© Kernel basado en prioridades para aplicaciones empotradas
3 VX Works, QNX, Chorus, VRTX32, pSOS, OS9, ...
© Extensiones de tiempo real para S.O de tiempo compartido
3 RT-UNIX, RT-LINUX, RT -MACH, ...
© Sistemas operativos de investigación
3 CHAOS (SO de TR orientado a objetos), MARS, Spring, ARTS, RK,
TIMIX, HARTOS, YARTOS, HARTIK,...
© RTEMS (Real Time Executive for Military Systems
18
Lenguajes de programación
© Un lenguaje de programación de sistemas de tiempo real debe
facilitar la realización de sistemas
3 concurrentes (simultaneidad de acciones)
3 fiables
3 con un comportamiento temporal analizable
© Características de un Lenguaje de programación de TR
3 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ámicas
3 Ausencia de recursividad
3 Bucles limitados por tiempo
19
Lenguajes de programación
© Hay tres clases de lenguajes de interés para STR
3 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
20
Lenguajes de programación: C
© Es un lenguaje muy utilizado para programación de sistemas
© Es un lenguaje
3 estructurado, con bloques
3 con escasez de tipos
3 muy flexible (pero a veces poco seguro)
© No tiene integrada la concurrencia ni el tiempo real
3 se consigue invocando servicios del sistema operativo de forma
explícita
© No facilita la descomposición en módulos ni la programación
con objetos
3 se puede hacer con C++ (una extensión de C para programar con
objetos)
21
Lenguajes de programación: ADA
© Es un lenguaje diseñado específicamente para sistemas de
tiempo real empotrados
3 concurrencia
3 tiempo real
3 acceso al hardware e interrupciones
© Es un lenguaje imperativo, descendiente de Pascal
3 estructura en bloques
3 fuertemente tipado
© Está pensado para construir sistemas grandes y cambiantes
3 paquetes (módulos) y esquemas genéricos
3 extensión de tipos con herencia
3 biblioteca jerárquica
3 interfaces normalizadas con otros lenguajes (C, Fortran)
22
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 implementaciones
3 unos anexos especializados para
G programación de sistemas
G sistemas de tiempo real
G sistemas distribuidos
G sistemas de información
G cálculo numérico
G fiabilidad y seguridad
3 Los anexos definen
G paquetes de biblioteca
G mecanismos de implementación
G no añaden sintaxis ni vocabulario al lenguaje
23