1 / 24

Sistemas de tiempo real

Sistemas de tiempo real. Sebastián Sánchez Prieto. Bibliografía. A. Burns and A. J. Wellings. “Real-Time Systems and their Programming Languages”. Addison-Wesley, 2nd Edition. 1996 M. H. Klein et al. “A Practitioner´s Handbook for Real-Time Analysis”. Kluwer Academic Publishers. 1993

Download Presentation

Sistemas de tiempo real

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Sistemas de tiempo real Sebastián Sánchez Prieto

  2. Bibliografía • A. Burns and A. J. Wellings. “Real-Time Systems and their Programming Languages”. Addison-Wesley, 2nd Edition. 1996 • M. H. Klein et al. “A Practitioner´s Handbook for Real-Time Analysis”. Kluwer Academic Publishers. 1993 • H. Gomaa. “Software Design Methods for Real-Time Systems”. Addison-Wesley. 1993 • G. De Micheli and M. Sami. “Hardware/Software Co-Design. Kluwer Academic Publishers”. 1996 • B. O. Gallmeister. “Programming for the Real World. POSIX.4”. O’Reilly & Associates, Inc. 1995 • D. Lewine. “POSIX. Programmer’s Guide”. O’Reilly & Associates, Inc. 1991 • A. S. Tanenbaum. “Sistemas Operativos Distribuidos”. Prentice Hall. 1996 • M. Barabanov. “A Linux-based Real-Time Operating System”. M. S. Thesis. Junio 1997

  3. Definición (Donald Gillies) • Un sistema de tiempo real (STR) es aquel en el cual los resultados son correctos, no sólo si la computación es correcta, sino también el tiempo en el cual se producen los resultados • Si no se verifican las restricciones de tiempo, se dice que se ha producido un fallo en el sistema • Otros han añadido: • Así pues, es fundamental garantizar las restricciones de tiempo, lo cual implica que el sistema sea predecible. Además, sería deseable que el grado de utilización del sistema sea alto a la vez que se mantienen estas restricciones

  4. Ejemplo • Ejemplo: robot que debe coger un objeto que viaja por una cinta transportadora • Sistema de tiempo real no es sinónimo de sistema rápido ni de sistema interactivo (i.e. radiotelescopio) • Aunque las velocidades de proceso aumenten los STR seguirán existiendo

  5. Mercado de los sistemas empotrados • Curiosidades: • 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 SW supone un 50% • El 90% de las innovaciones en automóviles las proporcionan los sistemas electrónicos Año 2001

  6. Dónde se utilizan los STR • Sistemas de mando y control • Sistemas de control de procesos • Sistemas de control de vuelo • Sistemas de control de automóviles • Sistemas de defensa • Sistemas de vigilancia intensiva • Sistemas multimedia • Electrónica de consumo • Sistemas de telecomunicación, etc.

  7. Clasificación de los STR • Críticos (hard real time systems): los plazos de respuesta deben respetarse en todas las circunstancias, una sola respuesta tardía a un suceso puede tener consecuencias fatales (sistemas de control de centrales nucleares o de aviones) • Acríticos (soft real time systems): se puede tolerar retrasos ocasionales en la respuesta a un suceso (el sistema de control de una lavadora) • ¿Qué se entiende por criticidad? • En algunas ocasiones se habla de funciones de validez o de utilidad que definen la valía de los resultados en función de su tardanza

  8. Otra clasificación • Sistemas activados por eventos • Las interrupciones determinan la evolución del sistema • Pueden fallar si la carga es alta • Sistemas activados por tiempo • Sólo interrumpe el reloj de tiempo real • Operan mejor con cargas altas (“pueden pensarse las cosas”) • También hay sistemas mixtos

  9. Sistema de control Sistema controlado Estructura de un STR Indicadores Consignas Acciones Medidas Entradas externas Salidas externas

  10. Estructura de un STR • El sistema de control (STR) actúa sobre el sistema controlado para conseguir un comportamiento definido • Es muy común emplear un esquema realimentado • En función de las medidas opera un algoritmo de control • Ese algoritmo de control determina las acciones impuestas al sistema controlado • Ejemplos: controlador PID, controlador deadbeat o filtros de Kalman • Un aspecto de suma importancia son los tiempos en los que se lleva a cabo cada acción

  11. Ejemplo: Control digital Controlador r(t) rk A/D Ley de control uk Referencia D/A yk A/D u(t) y(t) Sensor Planta Actuador

  12. Sistemas empotrados • Muchos STR son partes de otros sistemas en los que realizan operaciones de control • En estos casos hablamos de sistemas empotrados o “embedded systems” • Este tipo de sistemas suelen estar limitados en cuanto a recursos y no son visibles • Ejemplos: • Teléfonos móviles, radios, televisores, etc. • Sistemas de control en automóviles • Electrodomésticos

  13. Características de los STR • Los Sistemas de Tiempo Real (STR) llevan asociadas una serie de características básicas como las siguientes: • Tamaño y complejidad • Fiabilidad y seguridad • Cálculos con números reales • Interacción con dispositivos físicos • Eficiencia • Dependencia del tiempo • Concurrencia • Tolerancia ante fallos

  14. Tamaño y complejidad • Son dos aspectos ligados al software • Un factor muy importante es la necesidad de realizar cambios • Solución: descomponer el sistema en subsistemas pequeños

  15. Fiabilidad y seguridad • Fiabilidad • Es la probabilidad de proporcionar el servicio especificado • Para una tasa de fallos de  averías/hora la media de tiempo entre averías MTTF=1/  • Si MTTF > 109 hablamos de sistemas ultrafiables • Seguridad • Los sistemas críticos deben ser ultrafiables • Para ciertos proyectos es necesaria una certificación oficial • Los requisitos de fiabilidad y seguridad en los STR son mayores que en el resto • Según Hecht y Hecht (1986), los sistemas software complejos, por cada millón de líneas de código contienen una media de 20.000 errores • El 90% de esos errores pueden ser detectados con sistemas de comprobación • 200 errores de los restantes se detectan durante el primer año. Los 1800 restantes permanecen sin detectar

  16. ¿De dónde provienen los errores? • Una especificación inadecuada • Errores de diseño de los componentes SW • Averías en los componentes de hardware • Interferencias transitorias o permanentes en los sistemas de comunicación • Los errores 3 y 4 tienen un comportamiento previsible con métodos estadísticos • El lenguaje de programación debe facilitar el desarrollo de sistemas seguros • Se hace necesario el empleo de técnicas de prevención y tolerancia ante fallos

  17. Cálculos con números reales • Números asociados a magnitudes físicas asociadas al sistema controlado • Los datos crudos son filtrados y convertidos a datos de ingeniería • Se representan de forma aproximada en un ordenador • Tipos de representaciones: coma fija y coma flotante • Cuando algún dato toma valores incorrectos, se generan alarmas

  18. Dependencia del tiempo • Tiempos en los cuales se deben llevar a cabo determinadas acciones • Tiempos de terminación de cada acción • Responder a situaciones transitorias en las que no se pueden garantizar todos los plazos • Realizar cambios dinámicos en el comportamiento temporal del sistema • El comportamiento del sistema debe ser DETERMINISTA

  19. Aspectos temporales Límite (Deadline) Instante de activación Plazo máximo de respuesta Inicio Fin Tiempo de respuesta El tiempo de respuesta puede variar (jitter)

  20. Concurrencia • Se deben atender diversos tipos de eventos en paralelo • Puede ser suficiente con un sólo procesador • En ocasiones es necesario recurrir a sistemas multiprocesador • ¿Cómo expresar la concurrencia desde el programa? • Con ejecutivos cíclicos • Con tareas independientes • Los ejecutivos cíclicos son sencillos, pero: • Complican la labor del programador • Los programas resultantes son oscuros y poco elegantes • Programas difíciles de corregir • Es más difícil la descomposición • Es difícil llevar el programa a un sistema multiprocesador • Colocar el código de manejo de fallos es problemático

  21. Concurrencia • Con tareas independientes, las cuales pueden ser soportadas por: • El lenguaje: caso de Ada o Modula • El sistema operativo • Un SOTR debe proporcionar soporte básico para tareas de tiempo real, tolerancia a fallos, determinismo, etc. • Aspectos cruciales que deben considerarse: • El factor tiempo • Los protocolos de comunicación • La asignación de recursos

  22. Características de los SOTR • Poseen un cambio de contexto rápido • Poseen un tamaño pequeño • Responden a las interrupciones externas de una forma rápida • Minimizan los tiempos con interrupciones deshabilitadas • Proporcionan esquemas de gestión de memoria que no afecten a la predictibilidad • y proporcionan archivos de acceso rápido

  23. Elementos proporcionados • Con objeto de mantener las especificaciones de tiempo los SOTR: • Poseen un reloj de tiempo real • Proporcionan planificación basada en prioridades • Proporcionan alarmas y timeouts, y • Las tareas pueden activarse en intervalos de tiempo definidos

  24. Lenguajes de programación • Básicamente cabe considerar tres alternativas: • Lenguajes ensambladores • Proporcionan la máxima flexibilidad pero los desarrollos son costosos y poco fiables • Lenguajes secuenciales (C, Pascal, FORTRAN, etc.) • Deben tener un SOTR por debajo • Lenguajes concurrentes (Ada, Modula, concurrent C, etc.) • El lenguaje proporciona la concurrencia y el tiempo real

More Related