SISTEMAS DE TIEMPO REAL

TEMA 2: DISEO DE SISTEMAS DE TIEMPO REAL

DAVID RODRGUEZ HERNNDEZ
FECHA DE REVISIN: 18 Noviembre - 2008
ZAMORA (CURSO 2008/2009)
david.rgh@gmail.com
Nota importante
Este documento no pretende reemplazar al material propuesto por la UNED para la asignatura Sistemas
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 bibliografa propuesta por la Universidad para su
estudio completo.
Cualquier sugerencia, comentario o correccin sobre este documento, envelo a david.rgh@gmail.com

para poder realizar los cambios necesarios.
Podemos observar tres tcnicas de notacin:
NIVELES DE NOTACIN
Informal: Usan el lenguaje natural y diagramas imprecisos. Es legible para un rango mayor de
gente, pero est poco estandarizado y puede ser ambiguo.
Estructurada: Usan diagramas bien definidos, que se construyen a base de pequeos
componentes interconectados. Suelen tener una representacin sintctica en un lenguaje.
Formales: Tienen una base matemtica, lo que les hace muy precisos. Por ello, es legible para
un nmero ms 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 existentes (para los formales).

En la definicin 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.
Adems hay que definir los test de aceptacin.
ESPECIFICACIN DE REQUISITOS
Debido a la alta interactividad de los STR con el entorno, debe modelarse ste. Hay que tener en cuenta
aspectos como la tasa mxima de interrupciones, los modos de fallos, el nmero mximo de objetos
externos dinmicos
En estos anlisis se usan tcnicas estructuradas, como PSL y CORE. Tambin son populares otras
tcnicas, como UML (orientado a objetos), FOREST (mtodo formal), ALBERT
El modelo ms formar ms popular es VDM.

Suelen utilizarse dos aproximaciones complementarias:
ACTIVIDADES DE DISEO
Descomposicin: Se descompone el sistema en componentes los suficientemente pequeos
como para que puedan ser comprendidos y abordados por individuos o pequeos equipos.
Abstraccin: Permite dejar para ms adelante los detalles (especialmente los de
implementacin), lo que permite simplificar la visin del sistema.
Si se usase una notacin formal para la especificacin de requisitos, debe usarse tambin para el diseo
de alto nivel (para demostrar que cumplen la especificacin).
ENCAPSULAMIENTO
Los componentes de un sistema tienen funciones bien definidas y un grupo de interfaces claras. Si la
especificacin puede verificarse por la verificacin de los subcomponentes inmediatos sin necesitar
nada ms; se duce que es una descomposicin composicional.
Podemos encontrar diversos lenguajes, como Modula-2, C++, Java, Eiffel, Ada
COHESIN Y ACOPLAMIENTO
Se conoce como cohesin al grado de unin interna de un mdulo; es decir, a la relacin existente entre
sus funciones. Tenemos los siguientes grados de cohesin, ordenados de ms dbil al ms fuerte:
Casual: Los elementos slo se vinculan superficialmente, sin relevancia.
Lgica: Los elementos se relacionan desde el punto de vista del sistema completo, pero no hay
vinculacin real por software.
Temporal: Las rutinas se ejecutan en momentos similares.
Procedural: Los elementos se emplean en la misma seccin del programa.
De comunicacin: Los elementos operan sobre la misma estructura de datos.
Funcional: Los elementos realizan, entre todos, una tarea concreta.
Se conoce como acoplamiento a la interdependencia entre los mdulos de un programa. Conviene
tener una alta cohesin y un bajo acoplamiento.
APROXIMACIONES FORMALES
Se pueden utilizar redes sitio-transicin, que consiste en grafos con dos tipos de nodos: S para estados
atmicos locales y T para transiciones; y que estn relacionados por arcos. Aunque puede ser una
representacin compleja, su capacidad de abstraccin y visualizacin grfica lo convierten en un buen
marco de trabajo.
Hay pocos lenguajes de implementacin con una descripcin formal. Tenemos, por ejemplo, el CSP, en
el que cada proceso se describe en trminos de eventos externos.
Dos propiedades importantes en la comprobacin de modelos: la seguridad (asegurarse de que no va a
fallar) y la vivacidad (asegurarse de que los resultados van a ser positivos).
Los STR tambin tienen requisitos de temporalidad, por lo que se requiere el uso de la lgica temporal,
con operadores como siempre, en-algn-momento, hasta, desde.. Vase un ejemplo en la pgina 21.
Suele decirse que la lgica temporal requiere del programa completo para poder usarla; es por ello que
suele utilizarse ms en la verificacin de programas existentes que en la especificacin y desarrollo de
otros nuevos.

Aunque lo ideal sera usar tcnicas formales, no estn lo suficientemente maduras como para
considerarse mtodos probados y contrastados. En su lugar, suelen utilizarse mtodos estructurados.
MTODOS DE DISEO
Un mtodo de diseo en tiempo real debera ser capaz de estructurar un sistema en tareas
concurrentes, dar soporte al desarrollo de componentes reusables ocultando la informacin, definir los
aspectos del comportamiento mediante mquinas de estado finito y analizar las prestaciones de un
diseo para determinar sus propiedades de tiempo real.
Hay que decir que muchos de los mtodos existentes no cumplen con todo lo anterior. Pueden verse
algunos de estos mtodos en las pginas 22-23 del libro base.
Las fases habituales de un modelo de ciclo de vida son la especificacin de requisitos, el diseo
arquitectnico, el diseo detallado, la codificacin y las pruebas. En los STR, los problemas de
temporizacin se detectan, en el mejor de los casos, durante las pruebas.
Ahora veremos algunos de estos modelos.
JSD
Mtodo de desarrollo de sistemas de Jackson. Usa una notacin precisa para la especificacin y la
implementacin. La implementacin resulta de unas transformaciones sobre la especificacin.
Los grafos JSD constan de procesos de 3 tipos: de entrada, de salida e internos. stos pueden enlazarse
mediante conexiones de flujos de datos asncronos con buffer o mediante conexiones de vectores de
estado (inspecciones) (permite que un proceso vea el estado interno de otro).
Estos grafos proporcionan una arquitectura del sistema y una plataforma para expresar un diseo (no
hace el diseo en s). Una ventaja de este enfoque (flujo de datos) es que se puede representar la
temporizacin (los flujos que son seales de control).
Los procesos del diseo 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 diseo para
requerir pocos procesos (son pocos los lenguajes que pueden ser apropiados para las tcnicas de
transformacin) o tratar de reducir el nmero de objetos concurrentes una vez obtenido el programa
con exceso de procesos.
Lo recomendable por JSD es utilizar la inversin: sustituir cada proceso del diseo por un procedimiento
que controle la ejecucin de un conjunto de procesos (ej: 5 procesos iguales se traducen en uno llamado
5 veces).
MASCOT3
Este se dise especficamente para los STR. Usa grficos de flujo de datos y un diseo jerrquico
(aunque puede expresarse en forma textual tambin). Es importante aqu el concepto de mdulo.
Adems de los flujos de datos, puede contener subsistemas, reas de intercomunicacin de datos,
actividades, canales, depsitos y servidores. Proporciona asimismo las sincronizaciones necesarias para
los canales y depsitos.
La implementacin puede ser mediante un lenguaje de programacin concurrente o por una plataforma
de ejecucin estndar de tiempo real. Se tiende a emplear el lenguaje Ada.
Mascot tambin tiene el problema de la proliferacin de procesos.
HRT-HOOD
Aborda de forma directa las cuestiones de los STR estrictos. Se ve el diseo como una progresin de
compromisos, que definen propiedades del sistema que los diseadores de bajo nivel no pueden
cambiar. Aquellos aspectos que no tengan compromisos, se dice que son objeto de obligaciones que
tienen que resolver los niveles inferiores del diseo.
Se conoce como refinamiento del diseo 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 diseo arquitectnico.
Diseo de la arquitectura lgica: Se orienta a los requisitos funcionales. No se ve afectado por
las restricciones del entorno.
Diseo de la arquitectura fsica: Toma en cuenta los anteriores requisitos y aade los no
funcionales. Se orienta a los requisitos de temporizacin y confiabilidad y garantiza que el
sistema funcionar correctamente, tanto en el dominio de los valores como en el del tiempo.
UML
Lenguaje unificado de modelado. Es una notacin orientada a objetos. Se trata de un lenguaje grfico
que permite ver, especificar, construir y documentar los artefactos de un sistema compuesto
principalmente por software.
Permite capturar la estructura del sistema fcilmente y posee escenarios de casos de uso, que permiten
identificar respuestas clave del sistema o las entradas del usuario. Posee tambin un modelado del
comportamiento (diagramas de estados), de empaquetado, de la topologa fsica y un soporte para
patrones y marcos orientados al objeto.
Recurdese que UML no es un mtodo, sino un lenguaje; por lo que se requiere adems un proceso de
diseo. Por ello se propone ROPES, cuyas actividades son anlisis, diseo, implementacin y prueba; y
est dirigido por casos de uso.

Podemos observar 3 clases de lenguaje de programacin que se utilizan o han sido utilizados para
desarrollar STR: ensamblador, de implantacin de sistemas secuenciales y concurrente de alto nivel.
IMPLEMENTACIN
ENSAMBLADOR
Sola utilizarse inicialmente, ya que los lenguajes de alto nivel no tenan suficiente soporte para la
mayora de microcomputadores. Lo malo es que el ensamblador es un tipo de lenguaje orientado a la
mquina. Es decir, no se puede llevar fcilmente de una mquina a otra, hace falta reescribirlo (con
todas las complicaciones que conlleva).
LENGUAJES DE IMPLEMENTACIN DE SISTEMAS SECUENCIALES
Los lenguajes de alto nivel comenzaron a tener ms ventajas que inconvenientes. Aparecieron lenguajes
nuevos especficos para la programacin embebida, como Jovial o Coral66; y ms recientemente C y
C++. Son lenguajes secuenciales 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 PROGRAMACIN CONCURRENTE DE ALTO NIVEL
Durante la dcada de los 70, la complejidad de la programacin creci y surgi lo que se conoce como la
crisis del software, durante la cual, los sistemas no tenan fiabilidad ni respondan a las necesidades,
adems de que el coste final del software es impredecible y no se puede mantener fcilmente. 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 aplicaciones; por lo que naci Ada,
que fue actualizado una dcada despus para aportar la experiencia de esos aos transcurridos. Hay
otros lenguajes, como Modula-1 y sus actualizaciones. Posteriormente aparecieron ms: PEARL, CHILL,
Java, Mesa Existe tambin occam, que es mucho ms reducido y no da soporte a sistemas grandes y
complejos.
CRITERIOS GENERALES DE DISEO DE LENGUAJES
Los lenguajes para el diseo de sistemas embebidos no suelen limitarse a esos: tambin se usan para la
implementacin de sistemas para aplicaciones, como compiladores y SSOO. Podemos distinguir 6
criterios que deben seguir los lenguajes de tiempo real:
Seguridad: Consiste en el grado en que el compilador o el sistema de soporte en tiempo de
ejecucin pueden detectar los errores de programacin, con los lmites de sentido comn. Esto
nos permite reducir el coste, al detectar de forma temprana los errores. Sin embargo, puede
complicar el lenguaje.
Legibilidad: Las palabras clave, la facilidad de definicin de tipos, mecanismos de
modularizacin son determinantes para un lenguaje legible. Reduce los costes de la
documentacin, aporta seguridad y es ms fcil de mantener. Puede provocar un aumento de
la longitud de los programas.
Flexibilidad: El programador debe poder expresar directamente todas las operaciones
oportunas, sin tener que recurrir a cdigo mquina o al SO.
Simplicidad: Cuanto ms simple sea, ms sencillo es producir compiladores, menor es el coste
de formacin de programadores y evita en mayor medida errores de programacin por malas
interpretaciones en el lenguaje.
Portabilidad: Un ejemplo claro es 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
manipulacin de recursos hardware.
Eficiencia: Ya dijimos que un STR debe garantizar una respuesta dentro de los intervalos
marcados. Deben evitarse sobrecargas que retarden esta respuesta.

Es evidente que las pruebas de un STR deben ser muy exigentes y estrictas. Sin embargo, los errores ms
comunes de los STR suelen provocarse por interacciones sutiles entre procesos y en situaciones difciles
muy concretas de reproducir durante las pruebas.
PRUEBA
Las pruebas no se hacen slo sobre el sistema final, sino tambin sobre el diseo y sus mdulos. No slo
hay que comprobar el sistema en el entorno correcto, sino tambin en entornos incorrectos e
imprevisibles.
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 ejecucin normales y anormales (e incluso situaciones presuntamente
imposibles). Para los STR, sera conveniente un simulador multiprocesador, y a veces es imposible
construir uno adecuado por la complejidad del programa en cuestin.
Los simuladores de STR se consideran sistemas STR por s mismos, lo que implica que tambin deben ser
probados. Debe tenerse en cuenta que el desarrollo de un simulador es costoso en tiempo y dinero
(incluso puede costar ms que el propio software final); pero es un dinero bien invertido.

Los ciclos de vida clsicos (ej: en cascada) implica que cualquier error en los requisitos o especificacin
no se detectan hasta la entrega. Por ello, se utilizan prototipos, que permiten comprobar que la
especificacin de requisitos es correcta y completa, adems de que el cliente puede probarlo y aclarar
los requisitos. Algunos errores se detectan as de forma temprana.
PROTOTIPADO
El prototipo debe tener un coste significativamente menor que el sistema final, utilizando lenguajes de
ms alto nivel (por ejemplo). Un lenguaje popular para el prototipado es el APL.
Actualmente, muchas herramientas de diseo incorporan generacin de cdigo, 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 aplicacin; para ello
se necesita una simulacin, como ya se vio antes.
La emulacin de un STR grande es muy costosa y se requieren muchos recursos de cmputo. En estas
emulaciones hay que tener en cuenta diversos factores, como la velocidad de ejecucin del procesador,
las estructuras del cdigo para construir un modelo de emulacin.

Los STR suelen afectar a seres humanos en su funcionamiento. Esta interaccin supone una gran
variabilidad en el sistema, por lo que el diseo de esta interaccin (HCI) es crtica.
INTERACCIN HOMBRE-MQUINA
Es importante la modularidad. Es decir, las actividades de HCI deben estar aisladas y con interfaces bien
definidas. Adems, la interaccin debe estar controlada, por ejemplo para evitar rdenes humanas
peligrosas o no autorizadas.
La mayora de STR se conoce como sistemas de iniciativa 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 aplicacin o el resto del sistema. Sin embargo, es imposible capturar todos, ya que
por ejemplo, un cambio crtico podra ser perfectamente legtimo y, a la vez, el operador puede
confundirse. Es importante una buena formacin de los operadores, adems de definir bien las
interfaces de entrada/salida para evitar confusiones en la mayor medida posible (esto ltimo no es fcil
de definir, puesto que entran en juego factores psicolgicos).
Es importante que se proporcionen datos suficientes al usuario para que ste pueda conocer bien los
efectos de cada operacin. Adems, el orden en que se cumplimenten los parmetros no debe afectar a
la operacin en s; y en el caso de sistemas con varios modos de operacin, debe mostrarse cul es el
que est vigente en ese momento. Tngase en cuenta que no todos los cambios son producidos por
humanos, por lo que el usuario debe estar bien informado del estado en todo momento.
Naturalmente, existen otros factores que influyen en el comportamiento humano (sobrecarga de tareas,
jornadas largas, satisfaccin en el trabajo) pero estas ya se alejan del tema que estamos tratando.

Para obtener una calidad alta, es preciso gestionar bien tanto la programacin como el diseo. Aqu son
importantes los trminos de verificacin y validacin.
GESTIN DEL DISEO
Debe asegurarse la aplicacin correcta de las tcnicas necesarias. Existen herramientas de apoyo para
realizar todas estas comprobaciones, pero tienen que tener una calidad extremadamente alta.
Recurdese que estas herramientas no sustituyen al equipo humano; deben aplicarse rigurosamente las
tcnicas para producir STR de calidad y asequibles.
Hay que evitar los mtodos informales y los lenguajes inapropiados de bajo nivel.