SISTEMAS DE TIEMPO REAL
TEMA 2: DISEÑO DE SISTEMAS DE TIEMPO REAL
DAVID RODRÍGUEZ HERNÁNDEZ FECHA DE REVISIÓN: 18 – Noviembre - 2008 ZAMORA (CURSO 2008/2009)
[email protected] [email protected]
Nota importante: Este documento no pretende reemplazar al material propuesto por la UNED para la asignatura Sistema Sistemass de tiempo Real. Su finalidad es presentar de una forma esquematizada los contenidos de la asignatura, para facilitar el estudio de la misma. Es conveniente disponer de la bibliografía propuesta por la Universidad para su estudio completo. Cualquier o corrección sobre este documento, envíelo a
[email protected] para podersugerencia, realizar loscomentario cambios necesarios.
NIVELES DE NOTACIÓN NOTACIÓN Podemos observar tres técnicas de notación:
•
•
•
Informal: Usan el lenguaje natural Informal: natural y diagr diagramas amas imprecisos. imprecisos. Es legible para un rango rango mayor de gente, pero está poco estandarizado y puede ser ambiguo. Estructurada: Usan diagramas bien definidos, que se Estructurada: se const construyen ruyen a base base de pe pequeños queños componentes interconectados. interconectados. Suelen tener una representación representación sintáctica en un lenguaje. Formales: Tienen una base matemática, lo que les hace muy precisos. Formales: precisos. Por ell ello, o, es legible para un número más reducido de personas.
Los requisitos estrictos de los STR provocan que la tendencia sea usar las notaciones formales (o, al menos, las estructuradas), pero son pocos los ingenieros con los conocimientos suficientes para ello y son pocas las herramientas herramientas existentes (para los formales).
ESPECIFICACIÓN DE REQUISITOS REQUISITOS En la definición de requisitos, se ha de tener especial cuidado en el comportamiento temporal del sistema y en los requisitos de fiabilidad y el comportamiento en caso de fallos en los componentes. Además hay que definir los test de aceptación. Debido a la alta interactividad de los STR con el entorno, debe modelarse éste. Hay que tener en cuenta aspectos como la tasa máxima de interrupciones, los modos de fallos, el número máximo de objetos externos dinámicos… En estos análisis se usan técnicas estructuradas, como PSL y CORE CORE.. También son populares otras técnicas, como UML UML (orientado (orientado a objetos), FOREST FOREST (método (método formal), ALBERT ALBERT… … El modelo más formar más popular es VDM VDM..
ACTIVIDADES DE DISEÑO DISEÑO Suelen utilizarse dos aproximaciones complementarias: complementarias:
•
•
Descomposición: Se descompone el sistema Descomposición: sistema en en componentes los suficientemente suficientemente pequeños como para que puedan ser comprendidos y abordados por individuos o pequeños equipos. Abstracción: Abstracción: Permite dejar para más adelante los detalles (especialmente los de implementación), implementació n), lo que permite simplificar la visión del sistema.
Si se usase una notación formal para la especificación de requisitos, debe usarse también para el diseño de alto nivel (para demostrar que cumplen la especificación). ENCAPSULAMIENTO ENCAPSULAMIENTO Los componentes de un sistema tienen funciones bien definidas y un grupo de interfaces claras. Si la especificación puede verificarse por la verificación de los subcomponentes inmediatos sin necesitar nada más; se duce que es una descomposici descomposición ón composicional. composicional. Podemos encontrar diversos lenguajes, como Modula-2, C++, Java, Eiffel, E iffel, Ada… COHESIÓN Y ACOPLAMIENTO ACOPLAMIENTO Se conoce como cohesión cohesión al al grado de unión interna de un módulo; es decir, a la relación existente entre sus funciones. Tenemos los siguientes grados de cohesión, ordenados de más débil al más fuerte:
•
•
•
• •
•
Casual: Los elementos sólo se vinculan Casual: vinculan superficialmente, superficialmente, sin relevancia. relevancia. Lógica: Los elementos se relacionan Lógica: relacionan desde el punto punto de vista del sistema sistema completo, pero no hay hay vinculación real por software. Temporal: Las rutinas Temporal: rutinas se ejecutan ejecutan en momentos similares. similares. Procedural: Los elementos se emplean en la misma Procedural: misma sección del programa. programa. De comunicación: comunicación: Los elementos operan sobre la la misma estructura estructura de datos. datos. Funcional: Los elementos realizan, entre todos, una tarea concreta. Funcional:
Se conoce como acoplamiento acoplamiento a la interdependencia entre los módulos de un programa. Conviene tener una alta cohesión y un bajo acoplamiento. APROXIMACIONES FORMALES FORMALES Se pueden utilizar redes sitio-transición sitio-transición,, que consiste en grafos con dos tipos de nodos: S para estados atómicos locales y T para transiciones; y que están relacionados por arcos. Aunque puede ser una representación compleja, su capacidad de abstracción y visualización gráfica lo convierten en un buen marco de trabajo. Hay pocos lenguajes de implementación con una descripción formal. Tenemos, por ejemplo, el CSP CSP,, en el que cada proceso se describe en términos de eventos externos. Dos propiedades importantes en la comprobación de modelos: la seguridad seguridad (asegurarse (asegurarse de que no va a fallar) y la vivacidad vivacidad (asegurarse (asegurarse de que los resultados van a ser positivos). Los STR también tienen requisitos de temporalidad, por lo que se requiere el uso de la lógica temporal, temporal, con operadores como siempre siempre,, en-algún-momento en-algún-momento,, hasta hasta,, desde desde….. ….. Véase un ejemplo en la página 21.
Suele decirse que la lógica temporal requiere del programa completo para poder usarla; es por ello que suele utilizarse más en la verificación de programas existentes que en la especificación y desarrollo de otros nuevos.
MÉTODOS DE DISEÑO DISEÑO Aunque lo ideal sería usar técnicas formales, no están lo suficientemente maduras como para considerarse métodos probados y contrastados. En su lugar, suelen utilizarse métodos estructurados. Un método de diseño en tiempo real debería ser capaz de estructurar un sistema en tareas concurrentes, dar soporte al desarrollo de componentes reusables ocultando la información, definir los aspectos del comportamiento mediante máquinas de estado finito y analizar las prestaciones de un diseño para determinar sus propiedades de tiempo real. Hay que decir que muchos de los métodos existentes no cumplen con todo lo anterior. Pueden verse algunos de estos métodos en las páginas 22-23 del libro base. Las fases habituales de un modelo de ciclo de vida son la especificación de requisitos, el diseño arquitectónico, el diseño detallado, la codificación y las pruebas. En los STR, los problemas de temporización se detectan, en el mejor de los casos, durante las pruebas. Ahora veremos algunos de estos modelos. JSD JSD Método de desarrollo de sistemas de Jackson. Jackson . Usa una notación precisa para la especificación y la implementación. La implementación resulta de unas transformaciones sobre la especificación. Los grafos JSD constan de procesos de 3 tipos: de entrada, de salida e internos. Éstos pueden enlazarse mediante conexiones de flujos de datos asíncronos con buffer o mediante conexiones de vectores de estado (inspecciones (inspecciones)) (permite que un proceso vea el estado interno de otro). Estos grafos proporcionan una arquitectura del sistema y una plataforma para expresar un diseño (no hace el diseño en sí). Una ventaja de este enfoque (flujo de datos) es que se puede representar la temporización (los flujos que son señales de control). Los procesos del diseño y los flujos de datos con buffer pueden codificarse como procesos del programa; pero eso ocasiona a veces un exceso de procesos. Para evitarlo, podemos transformar el diseño para requerir pocos procesos (son pocos los lenguajes que pueden ser apropiados para las técnicas de transformación) o tratar de reducir el número de objetos concurrentes una vez obtenido el programa con exceso de procesos. Lo recomendable por JSD es utilizar la inversión inversión:: sustituir cada proceso del diseño por un procedimiento que controle la ejecución de un conjunto de procesos (ej: 5 procesos iguales se traducen en uno llamado 5 veces). MASCOT3 MASCOT3 Este se diseñó específicamente para los STR. Usa gráficos de flujo de datos y un diseño jerárquico (aunque puede expresarse en forma textual también). Es importante aquí el concepto de módulo módulo.. Además de los flujos de datos, puede contener subsistemas, áreas de intercomunicación de datos, actividades, canales, depósitos y servidores. Proporciona asimismo las sincronizaciones necesarias para los canales y depósitos. La implementación puede ser mediante un lenguaje de programación concurrente o por una plataforma de ejecución estándar de tiempo real. Se tiende a emplear el lenguaje Ada Ada..
Mascot también tiene el problema de la proliferación de procesos. HRT-HOOD HRT-HOOD Aborda de forma directa las cuestiones de los STR estrictos. Se ve el diseño como una progresión de compromisos,, que definen propiedades del sistema que los diseñadores de bajo nivel no pueden compromisos cambiar. Aquellos aspectos que no tengan compromisos, se dice que son objeto de obligaciones obligaciones que tienen que resolver los niveles inferiores del diseño. Se conoce como refinamiento del diseño diseño al proceso por el cual se transforman las obligaciones en compromisos. En este proceso puede haber restricciones impuestas por el hardware y el software sobre el que se construye (recursos, restricciones de mecanismos…). HRT-HOOD define dos actividades para el diseño arquitectónico.
•
•
Diseño de la arquitectura lógica: lógica: Se orienta a los requisitos requisitos funcionales. funcionales. No se ve afectado por las restricciones del entorno. Diseño de la arquitectura física: física: Toma en cuenta los anteriores requisitos y añade añade llos os no funcionales. Se orienta a los requisitos de temporización y confiabilidad y garantiza que el sistema funcionará correctamente, correctamente, tanto en el dominio de los valores como en el del tiempo.
UML Lenguaje unificado de modelado. modelado . Es una notación orientada a objetos. Se trata de un lenguaje gráfico que permite ver, especificar, construir y documentar los artefactos de un sistema compuesto principalmente por software. Permite capturar la estructura del sistema fácilmente y posee escenarios de casos de uso, que permiten identificar respuestas clave del sistema o las entradas del usuario. Posee también un modelado del comportamiento (diagramas (diagramas de estados), estados), de empaquetado, de la topología física y un soporte para patrones y marcos orientados al objeto. Recuérdese que UML no es un método, sino un lenguaje; por lo que se requiere además un proceso de diseño. Por ello se propone ROPES ROPES,, cuyas actividades son análisis, diseño, implementación y prueba; y está dirigido por casos de uso.
IMPLEMENTACIÓN IMPLEMENTACIÓN Podemos observar 3 clases clases de lenguaje de programación programación que se utilizan o han sido utilizados utilizados para desarrollar STR: ensamblador, de implantación de sistemas secuenciales y concurrente de alto nivel. ENSAMBLADOR Solía utilizarse inicialmente, ya que los lenguajes de alto nivel no tenían suficiente soporte para la mayoría de microcomputadores. Lo malo es que el ensamblador es un tipo de lenguaje orientado a la máquina. Es decir, no se puede llevar fácilmente de una máquina a otra, hace falta reescribirlo (con todas las complicaciones que conlleva). LENGUAJES DE IMPLEMENTACIÓN DE SISTEMAS SECUENCIALES SECUENCIALES Los lenguajes de alto nivel comenzaron a tener más ventajas que inconvenientes. Aparecieron lenguajes nuevos específicos para la programación embebida, como Jovial o Coral66 Coral66;; y más recientemente C y C++.. Son lenguajes secuenciales C++ secuenciales y y tienen carencias de control y fiabilidad para tiempo real, por lo que suele ser necesario basarse en el soporte del SO y en fragmentos de ensamblador. LENGUAJES DE PROGRAMACIÓN CONCURRENTE DE ALTO NIVEL Durante la década de los 70, la complejidad de la programación creció y surgió lo que se conoce como la crisis del software, software, durante la cual, los sistemas no tenían fiabilidad ni respondían a las necesidades, además de que el coste final del software es impredecible y no se puede mantener fácilmente. Por otra parte, se entrega tarde y sin ser óptimo ni portable a otros sistemas. Se buscaba un lenguaje de alto nivel que pueda servir para todas las aplicaci aplicaciones; ones; por lo que nació Ada Ada,, que fue actualizado una década después para aportar la experiencia de esos años transcurridos. Hay otros lenguajes, como Modula-1 Modula-1 y y sus actualizaciones. Posteriormente aparecieron más: PEARL PEARL,, CHILL CHILL,, Java,, Mesa Java Mesa… … Existe también occam occam,, que es mucho más reducido y no da soporte a sistemas grandes y complejos. CRITERIOS GENERALES DE DISEÑO DE LENGUAJES Los lenguajes para el diseño de sistemas embebidos no suelen limitarse a esos: también se usan para la implementación de sistemas para aplicaciones, como compiladores compiladores y SSOO SSOO.. Podemos distinguir 6 criterios que deben seguir los lenguajes de tiempo real:
•
•
•
•
Seguridad: Consiste en el Seguridad: el grado en que el compilador o el sistema sistema de soporte en tiempo de ejecución pueden detectar los errores de programación, con los límites de sentido común. Esto nos permite reducir el coste, al detectar de forma temprana los errores. Sin embargo, puede complicar el lenguaje. Legibilidad: Legibilidad: Las palabras clave, la facilidad de definición de tipos, mecanismos de modularización… son determinantes para un lenguaje legible. Reduce los costes de la documentación, aporta seguridad y es más fácil de mantener. Puede provocar un aumento de la longitud de los programas. Flexibilidad: El programador debe poder expresar directamente todas las operaciones Flexibilidad: oportunas, sin tener que recurrir a código máquina o al SO. Simplicidad: Cuanto más simple Simplicidad: simple sea, más sencillo es producir producir compiladores, compiladores, menor es el coste coste de formación de programadores y evita en mayor medida errores de programación por malas interpretacioness en el lenguaje. interpretacione
•
•
Portabilidad: Un ejemplo claro es Java Portabilidad: Java.. Es bueno que sea independiente del hardware sobre el que se ejecuta. En los STR es complicado, ya que estos programas se involucran en la manipulación de recursos hardware. Eficiencia: Ya dijimos que un STR debe garantizar Eficiencia: garantizar una respuesta dentro de los intervalos intervalos marcados. Deben evitarse sobrecargas que retarden esta respuesta.
PRUEBA Es evidente que las pruebas de un STR deben ser muy exigentes y estrictas. Sin embargo, los errores más comunes de los STR suelen provocarse por interacciones sutiles entre procesos y en situaciones difíciles muy concretas de reproducir durante las pruebas. Las pruebas no se hacen sólo sobre el sistema final, sino también sobre el diseño y sus módulos. No sólo hay que comprobar el sistema en el entorno correcto, sino también en entornos incorrectos e imprevisibles. SIMULADORES SIMULADORES Son los entornos de prueba para el software. Es un programa que imita las acciones que hará el sistema final. Pueden crear situaciones de ejecución normales y anormales (e incluso situaciones presuntamente imposibles). Para los STR, sería conveniente un simulador multiprocesador, y a veces es imposible construir uno adecuado por la complejidad del programa en cuestión. Los simuladores de STR se consideran sistemas STR por sí mismos, lo que implica que también deben ser probados. Debe tenerse en cuenta que el desarrollo de un simulador es costoso en tiempo y dinero (incluso puede costar más que el propio software final); pero es un dinero bien invertido.
PROTOTIPADO PROTOTIPADO Los ciclos de vida clásicos (ej: en cascada) implica que cualquier error en los requisitos o especificación no se detectan hasta la entrega. Por ello, se utilizan prototipos prototipos,, que permiten comprobar que la especificación de requisitos es correcta y completa, además de que el cliente puede probarlo y aclarar los requisitos. Algunos errores se detectan así de forma temprana. El prototipo debe tener un coste significativamente menor que el sistema final, utilizando lenguajes de más alto nivel (por ejemplo). Un lenguaje popular para el prototipado es el APL APL.. Actualmente, muchas herramientas herramientas de diseño incorporan generación de código, que pueden servir para el prototipo (ya que no tiene la suficiente calidad para el sistema final). Sin embargo, los prototipos no tienen en cuenta los aspectos del tiempo real de la aplicación; para ello se necesita una simulación simulación,, como ya se vio antes. La emulación de un STR grande es muy costosa y se requieren muchos recursos de cómputo. En estas emulaciones hay que tener en cuenta diversos factores, como la velocidad de ejecución del procesador, las estructuras del código… para construir un modelo de emulación.
INTERACCIÓN HOMBRE-MÁQUINA HOMBRE-MÁQUINA Los STR suelen afectar a seres humanos en su funcionamiento. Esta interacción supone una gran variabilidad variabili dad en el sistema, por lo que el diseño de esta interacción ((HCI HCI)) es crítica. Es importante la modularidad modularidad.. Es decir, las actividades de HCI deben estar aisladas y con interfaces bien definidas. Además, la interacción debe estar controlada, por ejemplo para evitar órdenes humanas peligrosas o no autorizadas. La mayoría de STR se conoce como sistemas de iniciativa mixta; mixta; es decir, en ocasiones el computador tiene el control y otras veces el operador. Se intenta que todos los errores derivados del usuario se capturen en el software de control de la interfaz y no en el de aplicación o el resto del sistema. Sin embargo, es imposible capturar todos, ya que por ejemplo, un cambio crítico podría ser perfectamente legítimo y, a la vez, el operador puede confundirse. Es importante una buena formación de los operadores, además de definir bien las interfaces de entrada/salida para evitar confusiones en la mayor medida posible (esto último no es fácil de definir, puesto que entran en juego factores psicológicos). Es importante que se proporcionen datos suficientes al usuario para que éste pueda conocer bien los efectos de cada operación. Además, el orden en que se cumplimenten los parámetros no debe afectar a la operación en sí; y en el caso de sistemas con varios modos de operación, debe mostrarse cuál es el que está vigente en el ese momento. cuenta que todosenlos cambios son producidos por humanos, por lo que usuario debe Téngase estar bieneninformado delno estado todo momento. Naturalmente, existen otros factores que influyen en el comportamiento humano (sobrecarga de tareas, Naturalmente, jornadas largas, largas, satisfacción en el trabajo…) trabajo…) pero estas ya se alejan del tema tema que estamos tratando. tratando.
GESTIÓN DEL DISEÑO DISEÑO Para obtener una calidad alta, es preciso gestionar bien tanto la programación como el diseño. Aquí son importantes los términos de verificación verificación y y validación validación.. Debe asegurarse la aplicación correcta de las técnicas necesarias. Existen herramientas de apoyo para realizar todas estas comprobaciones, pero tienen que tener una calidad extremadamente alta. Recuérdese que estas herramientas no sustituyen al equipo humano; deben aplicarse rigurosamente rigurosamente las técnicas para producir STR de calidad y asequibles. Hay que evitar los métodos informales y los lenguajes inapropiados de bajo nivel.
