Modelado de Sistemas de Tiempo Real

Transcripción

1 MSc. Ing. Daniel Calegari García Grupo COAL Instituto de Computación Universidad de la República

2 Introito Prólogo No soy experto en el tema, solo tengo alguna idea a raíz de trabajos de investigación que he estado realizando. Por ende, mi objetivo es dar una visión parcial y en amplitud de de un tema relacionado con la asignatura de forma tal de: mostrar un área de trabajo que no se suele ver en la carrera despertar su curiosidad complementar el contenido de la asignatura

3 Sistemas Embebidos Sistemas Embebidos Sistemas de Tiempo Real Modelado de Sistemas Firmware es un software que se encuentra embebido (o integrado) en un dispositivo de hardware, por ejemplo en un microcontrolador. Por lo general, los sistemas embebidos deben: ser confiables: baja tasa de fallas y alta disponibilidad ser eficientes en el uso de recursos: energía, tamaño de código, peso, costo cumplir con restricciones de tiempo

4 Sistemas de Tiempo Real Sistemas Embebidos Sistemas de Tiempo Real Modelado de Sistemas "Sistema informático que mantiene una relación interactiva y temporizada con su entorno"(selic, 1999) Relación interactiva: El sistema debe disponer de interfases que permitan intercambiar estímulos con el entorno Relación temporizada: Además de la correctitud funcional, se deben considerar las restricciones temporales

5 Sistemas de Tiempo Real (2) Sistemas Embebidos Sistemas de Tiempo Real Modelado de Sistemas Concurrencia: sincronización para evitar problemas como deadlocks y posposición indefinida Distribución: fiabilidad y latencia de las comunicaciones, así como a la probabilidad de fallo Estructura Interna Dinámica: configuración dinámica en sistemas tolerantes a fallos

6 Modelado de Sistemas Sistemas Embebidos Sistemas de Tiempo Real Modelado de Sistemas Un sistema se modela para poder manejar su complejidad: Servir de ayuda para el desarrollo de la tarea (uno mismo) Visualizar lo hecho hasta el momento (uno mismo) Comunicar el avance obtenido (el cliente y el equipo de desarrollo) Documentar el desarrollo de la aplicación (el equipo de desarrollo)

7 Porqué modelar? Porqué modelar? Qué modelar? Es deseable un desarrollo lo más rápido y menos costoso posible Un error es más caro y complejo de encontrar y resolver después de la liberación del sistema al usuario Es muy importante evaluar la calidad de los sistemas conforme avanza su desarrollo.

8 Niveles de Modelado Porqué modelar? Qué modelar? Nivel 0: especificación informal Nivel 1: especificación formal (uso de técnicas con base matemática, para la especificación, diseño y construcción del sistema) Nivel 2: construcción manipulando la especificación y verificación con argumentos matemáticos Nivel 3: prueba de propiedades

9 Métodos Formales Porqué modelar? Qué modelar? Los niveles 1 al 3 se relacionan con la noción de métodos formales. In computer science, formal methods refers to mathematically based techniques for the specification, development and verification of software and hardware systems. The approach is especially important in high-integrity systems, for example where safety or security is important, to help ensure that errors are not introduced into the development process. Formal methods are particularly effective early in development at the requirements and specification levels, but can be used for a completely formal development of an implementation (e.g., a program).

10 Seven Myths of Formal Methods Porqué modelar? Qué modelar? J.A. Hall, Seven Myths of Formal Methods. IEEE Software, 7(5):11-19, September Formal methods can guarantee that software is perfect. 2 Only highly critical systems benefit from their use. 3 They involve complex mathematics. 4 Nobody uses them for real projects. J.P. Bowen and M.G. Hinchey, Seven More Myths of Formal Methods. IEEE Software, 12(4):34-41, July Formal methods delay the development process. 6 Formal methods lack tools. 7 Formal method only apply to software.

11 Qué modelar? Prólogo Porqué modelar? Qué modelar? Más allá de los requerimientos funcionales, son los no funcionales (atributos de calidad) los que tienen un gran impacto en el diseño de un sistema de tiempo real. distribución de los componentes de hardware y protocolos de comunicación entre ellos restricciones temporales que afectan el desempeño del sistema (performance) concurrencia y sincronización en el acceso a recursos compartidos planning y scheduling de tareas propiedades generales (liveness y safety)

12 Porqué modelar? Qué modelar? Modelos teóricos: Grafos Temporizados, FOCUS [Bro02], SDL (Specification and Description Language) Description Language), Prototipos ad hoc [?] Modelos gráficos: UML Profile for Schedulability, Performance, and Time [UML], UML Profile for System on a Chip [MM05] Herramientas de Verificación: Kronos, UPPAAL [UPP] Simulación: SystemC [Sys], VHDL (VHSIC Hardware Description Language)

13 Modelo Teórico :: FOCUS :: Heater Control Porqué modelar? Qué modelar?

14 Porqué modelar? Qué modelar? Modelo Gráfico :: UML Profile for SPT :: Web-Based Video-Streaming Application

15 Porqué modelar? Qué modelar? Herramientas de Verificación :: UPPAAL :: Bang and Olufsen Audio/Video Protocol Dos emisores de datos a través de un bus (generadores de frames, observadores de bus y detectores de colisiones) Criterio de correctitud del protocolo: A[] (A.eof == 1 imply (A.diff == 0 and B.res == 0)) Whenever (A[]) a frame has been sent (A.eof equals 1), the sent frame must be intact (A.diff equals 0), and other senders must not have discovered a collision (B.res equals 0)

16 Porqué modelar? Qué modelar? Simulación :: SystemC :: UML Profile for SoC Design (Clock and Reset)

17 Y ahora? Prólogo Y ahora? Desarrollo Dirigido por Modelos He modelado el sistema que deseo y lo he verificado Deseo implementarlo sin cometer errores Desearía no tener que verificar también la implementación Para ello necesitaría definir una transformación formal entre mis modelos y el código para una plataforma determinada

18 Desarrollo Dirigido por Modelos Y ahora? Desarrollo Dirigido por Modelos Un enfoque es considerar a los modelos como especificaciones ejecutables => Usando un entorno de desarrollo unificado => Enlazando directamente los requerimientos con el diseño => Integrando testing con diseño para identificar y corregir errores => Simulando el sistema a construir para mejorar su diseño => Generando automáticamente el código embebido

19 Desarrollo Dirigido por Modelos MathWorks :: Real-Time Workshop Embedded Coder Y ahora? Desarrollo Dirigido por Modelos El producto Real-Time Workshop Embedded Coder genera código C para varias plataformas a partir de modelos Permite especificar modelos gráficos de estructura y comportamiento Posee herramienta de verificación y documentación de código Genera código ANSI/ISO C y C++ Incorpora librería de optimización para el lenguaje objetivo Permite ejecutar el código en el ambiente de producción y generar reportes de ejecución Existe una librería para PIC (

20 Desarrollo Dirigido por Modelos MathWorks :: Real-Time Workshop Embedded Coder Y ahora? Desarrollo Dirigido por Modelos

21 Resumen Prólogo Resumen Bibliografía Realizar modelos de un sistema previa construcción del mismo puede ser beneficioso, más aún en un entorno complejo como el de sistemas de tiempo real. Existen diferentes niveles en los cuales se puede modelar. Además, existen múltiples alternativas. La elección depende principalmente del propósito del modelo. Un propósito habitual es permitir en última instancia generar el código para la ejecución del sistema en cierta plataforma. Para ello es conveniente contar con alguna herramienta de soporte.

22 Bibliografía Prólogo Resumen Bibliografía [Bro02] M. Broy et al. The Design of Distributed Systems, An Introduction to Focus Technical Report TUM-I9202, Technische Universität München, [MM05] G. Martin and W. Muller. UML for SOC Design Birkhäuser Publisher, ISBN , [Sys] SystemC. [Mat] MathWorks Real-Time Workshop Embedded Coder. [UML] UML Resource Page. [UPP] UPPAAL web site.

23 Defer no time, delays have dangerous ends W. Shakespeare