Editor de diseños

REALCaSe no es un entorno que proporciona asistencia en todos las etapas del desarrollo de un sistema de tiempo real, al estilo de los entornos que hoy en día están apareciendo, agrupados bajo las siglas IPSE (Integrated Project Support En-vironment) o SEE (Software Engineering EnEn-vironment). Así por ejemplo, esta her-ramienta no proporciona apoyo en las fases de especificación de requisitos del

sistema, en el análisis de los mismos, o en el diseño preliminar del sistema. RE-ALCaSe se emplea a partir de la fase de diseño detallado de la aplicación paralela de tiempo real. El diseñador puede comenzar a trabajar con cualquier metodología, y una vez llegado a la etapa de diseño detallado, puede emplear REALCaSe para el prototipado rápido.

Como se ha visto en el capítulo anterior, la falta de herramientas con un enfoque dirigido a aplicaciones paralelas de tiempo real que hicieran uso de paradigmas típicos en programación paralela y distribuida, como segmentación o granjas de trabajo, motivó el desarrollo de REALMoD [Grana96a].

REALMoD es un lenguaje gráfico de descripción de sistemas de tiempo real, intuitivo, fácil de utilizar, con énfasis en tecnologías paralelas y distribuidas. Este lenguaje es una evolución de los populares DFD's [DeMarco78], incorporando in-formación de control que permite derivar prototipos listos para ejecución. Una exposición más detallada de este lenguaje se encuentra en el capítulo 4.

Una descripción de un sistema paralelo de tiempo real involucra los siguientes elementos: a) el nivel de tareas, en el que figuran las restricciones de tiempo real del sistema, derivadas del análisis de requisitos; b) el nivel de proceso, donde la aplicación queda organizada como un conjunto de procesos cooperantes, y c) el nivel físico, lugar donde se describe la arquitectura destino. En los siguientes párrafos se esbozan algunas características de cada nivel de abstracción.

• Nivel de tareas

Al más alto nivel de abstracción, un sistema de tiempo real se estructura como un conjunto de tareas de tiempo real, que interactúan entre sí para resolver un problema. Una tarea es un código software que tiene una entidad indepen-diente y cuya realización está sometida a unas restricciones temporales, condi-cionadas por el entorno con el que este sistema se relaciona. Las tareas pueden ser periódicas o aperiódicas. Una tarea periódica es aquella que debe re-alizarse a intervalos de tiempo fijos. Por el contrario, las tareas aperiódicas se realizan ante la presencia de estímulos externos de carácter esporádico. En la figura 3.4 se presenta un ejemplo de aplicación en el que intervienen un total de siete tareas para su resolución. Las tareas 2 y 5 no tienen entradas externas.

Se activan periódicamente. El resto de tareas han realizan sólo cuando sus entradas están disponibles. En este sistema hay predominancia de tareas es-porádicas, por lo que puede considerarse como un sistema dirigido por eventos (ver apartado 3.2).

Las restricciones de tiempo real especificadas en este nivel habrán de ser vali-dadas mediante la ejecución de prototipos del sistema. Estas restricciones se refieren fundamentalmente al periodo de activación de las tareas periódicas, y el plazo máximo de respuesta para las periódicas y aperiódicas.

• Nivel de proceso

El nivel de descripción anterior está muy próximo a las especificaciones derivadas del estudio del problema, pero no refleja los detalles de implementación del

sis-56

Identificador Período

Plazo Respuesta Instrumentación Procesos

Identificador Plazo Repuesta Instrumentación Procesos [Tarea no periódica]

[Tarea periódica]

Figura 3.4: Nivel de Tareas en un SPTR.

tema. Es en el nivel de proceso donde se definen los distintos componentes con los que se construyen los prototipos del sistema. Este nivel da una serie de elementos con los que se pueden descomponer las tareas del nivel anterior.

Así por ejemplo, por criterios de diseño, puede ser aconsejable segmentar una tarea en varios procesos que ejecuten en paralelo, de tal manera que la salida del primer proceso sea la entrada del segundo, y así sucesivamente. De esta manera es posible ubicar cada proceso (o etapa) en un procesador distinto, consiguiendo aumentar el paralelismo de dicha tarea, y mejorar el número de datos producidos por unidad de tiempo (throughtput), dada su organización segmentada.

En concreto, el nivel de proceso proporciona a) procesos, entidades sujetas a planificación y que llevan a cabo las funciones del programa, b) caminos de datos, que permiten conectar procesos con c) mecanismos de intercambio de datos, que especifican las características de los medios de comunicación;

d) entidades externas, que representan los límites del sistema considerado;

y e) subsistemas, que permiten agrupar modelos y convertirlos en nuevos el-ementos replicables, reduciendo la simbología gráfica de manera considerable y favoreciendo el entendimiento del diseño. La figura 3.5 muestra la repre-sentación gráfica de distintos elementos del nivel de proceso.

Un detalle original de este lenguaje de diseño es que proporciona los elemen-tos necesarios para construir diversos paradigmas de programación paralela (ver figura 3.5) como segmentación gracias a los procesos etapa, granjas con los procesos F, y servidores replicados con los procesos S. Un análisis pormenorizado de estos paradigmas se encuentra en el capítulo 4, así como en

PROCESOS

Etapa o

Segmento Granja

Servidor

Replicado Temporizador

MECANISMOS DE COMUNICACIÓN

Memoria Cola de Canal CSP compartida mensajes

Almacén genérico

F. DATOS ENT. EXTERNA

® © © © —

At = °°

m

SUBSISTEMA

Figura 3.5: Elementos del nivel de proceso.

el apéndice A.

• Nivel físico

El nivel físico se compone de una serie de procesadores, interconectados me-diante una serie de enlaces de comunicación. En este nivel de descripción sólo es necesario especificar el número de procesadores de que consta la máquina paralela. Esto es fundamental a efectos de generación de código final del SPTR para la arquitectura destino.

Los tres niveles arriba citados están muy desacoplados, o en otras palabras, se refieren a distintos tipos de información. Esto es muy deseable, ya que conduce a especificaciones no redundantes, pero hace necesario establecer asociaciones entre los diferentes niveles. Para ello, se definen dos proyecciones, a saber: a) tareas con procesos, y b) procesos con nodos de computación.

• Proyección entre el nivel de tareas y el nivel de proceso

Las tareas se descomponen en uno o más procesos, pertenecientes al nivel de proceso. Por tanto, esta proyección sirve para asociar a cada tarea los procesos de que está formada.

• Proyección entre los niveles de proceso y físico

De esta forma, se podrá determinar en qué nodos se sitúan los distintos pro-cesos. Además, existen otros elementos del nivel de proceso que necesitan ubicación en determinados nodos, como por ejemplo las colas de mensajes POSIX. En efecto, el nodo donde se sitúa una cola de mensajes debe aportar la memoria necesaria para guardar los mensajes enviados y no recepcionados.

En la figura 3.6 se muestra un ejemplo de diseño realizado con el editor gráfico de REALMoD. Corresponde a un prototipo del sistema de monitorización del tren de laminado abordado dentro del proyecto ESCORT (ilustrado en la figura 1.2). El diseño ha sido realizado siguiendo el modelo de programación PMS, por lo que los

58

mecanismos de comunicación entre procesos sólo pueden ser este tipo de canales. En la figura se ha representado únicamente el nivel de proceso. Obsérvense algunos de los elementos ya citados dentro de este nivel, como procesos, flujos de datos, canales PMS y entidades externas.

H jwisrsraw.www/

n i .

+

®

(?)

Ccñ

—

9

Y»w Prototyp. Trac*Brows«r Qpllons

mpt2v

/

c

Tipil/ / ^ mP« °1

\ ' ? / / ^ |CSP |

••4HTv> a ^[cspl-!1-?-(t>...tS5-^cspl

*' • \ \ \ n r r i mpts ttistpialf mptlS

i w3 \ F ) |CSP|

: \ \ trscKingf m a l 3

\ N,^ mpl11 thldSptt mp"»