1. Introducción a SDL

Transcripción

1 1. Introducción a SDL Esta sección tiene como objetivo dar una visión general de lo que es el lenguaje SDL, para que un usuario que lea esta memoria no se vea obligado a buscar información externa sobre ello, ya que en varios puntos de este documento se presentarán algunos ejemplos en SDL o se harán referencias al lenguaje. No es ni mucho menos un manual completo, por lo que no entraremos en todos los detalles. 1.1 Qué es SDL? SDL es un lenguaje orientado a la especificación y descripción de sistemas de telecomunicaciones que funcionan en tiempo real (control de sistemas, protocolos de comunicaciones, etc.). Además, permite elegir entre dos formas sintácticas diferentes para la representación de sistemas. La primera es SDL/GR (Graphical Representation), siendo un lenguaje gráfico que define la estructura y flujos de control del sistema. La segunda es SDL/PR (Phrase Representation), el cual es un lenguaje de programación. Principalmente nos centraremos en la primera. 1.2 Entidades El lenguaje SDL se compone de entidades en forma de jerarquía. La entidad principal es el sistema, el cual está compuesto por bloques. Los bloques están conectados entre sí y con el entorno mediante canales, los cuales transportan señales. Dentro de los bloques tenemos procesos, los cuales están definidos por una máquina de estados finita extendida, con variables, parámetros, acciones y temporizadores. Los procesos también se comunican entre sí por medio de señales. Podríamos resumir la jerarquía de la siguiente forma: Pág. 1 de 18

2 1.2.1 Sistema Un sistema es la entidad de más alto nivel y obviamente representa a todo el sistema que queremos modelar. Está separado de su entorno por la frontera del sistema, con el que se comunica por medio de señales. Además, un sistema contiene un conjunto de bloques, que también se comunican por medio de señales. Las señales, como ya sabemos, se transmiten por medio de canales. El conjunto sistema/entorno se puede resumir de la siguiente forma: Asimismo, el contenido de un sistema se podría explicar con el siguiente diagrama: Pág. 2 de 18

3 1.2.2 Bloque Un bloque contiene una o más definiciones de proceso de un sistema (al menos una). La misión de un bloque es agrupar procesos que realizan una cierta función. Como ya sabemos, los bloques se comunican mediante canales por lo que la definición de un bloque proporcionará una interfaz de comunicación estática para comunicarse con otros procesos. Además establece un ámbito para definiciones de proceso. Un ejemplo sencillo podría ser el siguiente: Proceso Un proceso se define como una máquina de estados finita extendida. Como ya sabemos, en una máquina de estados existen estados y transiciones entre ellos. En este caso se da una transición de un estado a otro siempre que se recibe una señal válida de otro proceso o del entorno. Al realizarse esa transición, se pueden realizar operaciones como manipular datos locales al proceso (se hace por medio de variables locales, permitiendo cualquier tipo de datos incluido struct), enviar señales (a otros procesos o al entorno), llamar a un procedimiento o incluso crear instancias de procesos. Las señales recibidas por el proceso se denominan señales de entrada y las señales enviadas se denominan señales de salida, aunque en el conjunto de señales de entrada válidas debemos añadir las señales del temporizador. Además, una señal solo puede ser consumida por un proceso cuando éste se encuentra en un estado. Pueden existir varias instancias de un proceso ejecutándose concurrentemente, y además simultáneamente con instancias de procesos distintos. Por otro lado, los procesos tienen acceso al tiempo absoluto NOW, y pueden realizar cálculos de tiempos. Con respecto a la recepción de señales de un proceso, debemos destacar que cada proceso (mejor dicho, cada instancia) tiene una única cola de señales de entrada que no comparte con otros. Aparte de esto, para cada estado hay un conjunto de señales de conservación (saved signals). Éstas son señales que podremos evitar o conservar en un estado concreto para posponer su procesamiento, ya que debido a que las señales se almacenan en una cola FIFO puede ser que nos interese evitar ciertas señales para consumirlas posteriormente y no interrumpir el funcionamiento del sistema. Éstas Pág. 3 de 18

4 señales serán las primeras en ser consumidas una vez se haya realizado la transición de estado en el mismo orden en el que llegaron. Dicho esto, el esquema de un proceso quedaría de la siguiente forma: Canal Con respecto a los canales no tenemos mucho que decir. Ya sabemos que un canal es una ruta para transportar señales entre dos bloques o un bloque y su entorno (si es entre dos bloques no puede ser el mismo en los dos extremos). Podemos añadir que el orden en el que llegarán las señales será el mismo que el orden en el que se envían desde el otro extremo. Asimismo, para cada canal debe haber una lista de señales que transporta. Para terminar, podemos decir que pueden existir varios canales entre dos extremos. Un ejemplo podría ser: Señal Una señal es un flujo de información entre procesos. La declaración de señales en SDL/GR se realiza mediante la inclusión de un cuadro TEXT (ver sección 1.3), cuyo contenido debe comenzar por la etiqueta SIGNAL y posteriormente los nombres de las señales seguido de los tipos de los parámetros entre paréntesis (siendo esto opcional), como por ejemplo: Pág. 4 de 18

5 1.2.6 Temporizadores Uno de los recursos que pueden utilizar los procesos son los temporizadores. Un temporizador es un objeto que puede operar con tiempos. Se inicializa con la sentencia SET, en cuyo caso se le asocia un valor de tiempo. Cuando el tiempo del sistema llega al tiempo establecido para el temporizador, se añade a la cola de señales de entrada (ver sección 1.2.3) una señal con el mismo nombre que el temporizador. Otra de las operaciones que se pueden aplicar a un temporizador es la operación de RESET, la cual desactivará la operación anterior (además, si hay una señal en la cola de entrada correspondiente al temporizador también se suprime). Dicho esto se pueden distinguir dos estados del temporizador, activo e inactivo. Estará activo desde la inicialización hasta el consumo de la señal del temporizador por parte del proceso (en cualquier otro caso estará inactivo). Cuando realizamos una operación de RESET, el temporizador pasará de activo a inactivo. Para referirnos a un tiempo concreto normalmente utilizaremos el tiempo absoluto del sistema (NOW), que es visible por todos los procesos y se comparte. Dicho esto, explicaremos como manejar estas operaciones con SDL/GR. Primeramente, la declaración de un temporizador se realiza mediante la inclusión de un cuadro TEXT (ver sección 1.3) con la etiqueta TIMER seguido del nombre que le queremos dar al temporizador. Un ejemplo sería: El cual declararía un temporizador llamado T. La inicialización se efectúa mediante la sentencia SET, que recibe dos argumentos. El primero de ellos es el tiempo en el cual vence el temporizador, como ya hemos dicho utilizaremos la sentencia NOW para utilizar el tiempo actual del sistema sumándole los segundos que queramos que pasen hasta la activación del temporizador. Esta sentencia la deberemos añadir en un cuadro TASK (ver sección 1.3) dentro de la definición de un procedimiento. Un ejemplo sería: Activaría el temporizador T para ser activado tras 13 segundos. Pág. 5 de 18

6 Por otro lado, la reinicialización de un temporizador se realiza mediante la sentencia RESET, la cual recibe un único argumento correspondiente al nombre del temporizador. También debe ir dentro de un cuadro TASK (ver sección 1.3). Para reinicializar el temporizador anterior añadiríamos: Para terminar, vamos a resumir el comportamiento de un temporizador en el siguiente autómata: 1.3 Símbolos Una vez entendidas las entidades de las que se compone un sistema especificado en SDL vamos a ver los principales símbolos de los que se componen. A no ser que se especifique lo contrario nos estaremos refiriendo siempre al nivel de proceso dentro de la jerarquía. Símbolo Nombre Uso Include Se usa para incluir librerías SDL en el sistema. Utilizaremos la directiva #include seguida de la librería que queremos añadir entre comillas simples. Text Contiene la declaración de las estructuras, variables, temporizadores y señales. Para la declaración de variables deberemos utilizar la palabra reservada DCL seguido del nombre (uno o varios) y el tipo de la variable que queremos declarar. También se pueden inicializar de forma análoga al lenguaje C. Los tipos predefinidos más comunes son Boolean, Character, Charstring, Integer, Natural y Real. Un ejemplo sencillo sería el siguiente: Pág. 6 de 18

7 Para la declaración de constantes utilizaremos la palabra reservada SIGNAL seguida del nombre de la señal y los parámetros que contendrá entre paréntesis. Como por ejemplo: Start State En los niveles de bloque y sistema será solamente para señales y canales. Indica el comienzo de un proceso. Debe existir una vez por cada proceso. Simboliza un estado del sistema. Input Output Task Save Decision Indica la espera de una señal de entrada por lo que se tratará de un símbolo bloqueante. Debe encontrarse inmediatamente después de un símbolo de estado. Si la señal es recibida se consume y se produce una transición de estado poniendo a disposición del proceso la información transportada por la señal. Si la señal lleva información (parámetros) debe ser copiada en variables locales al proceso, es decir, debe haber una variable local al proceso con el mismo nombre que indiquemos en el parámetro de la señal. En caso contrario se descartará el valor y no se almacenará en ningún sitio. Envía una señal, usualmente se realizará al final de una transición. Usado para realizar tareas generales, como por ejemplo asignación de variables u operaciones sobre temporizadores. Puede contener una lista de asignaciones separadas por comas. Añade una señal al conjunto de señales de conservación de un estado. Podemos añadir una señal concreta o podemos usar el símbolo * para referirnos a todas las señales. Es usada para escoger entre dos rutas alternativas según el resultado de una condición. Pág. 7 de 18

8 Connector Stop Un conector posee una etiqueta que simboliza la continuación desde otro conector que posea la misma etiqueta, es decir, se utilizan para realizar saltos incondicionales. Indica la terminación de un proceso. Procedure call Ejecuta la llamada a un procedimiento previamente declarado. Procedure reference Procedure start Declaración de un procedimiento el cual es llamado en el proceso actual. Comienza la definición de un proceso. Procedure return Text extension Retorno de procedimiento a donde fue llamado. Se utiliza para incluir comentarios. Pág. 8 de 18

9 2. El protocolo parada y espera El protocolo de comunicación más sencillo entre dos puntos lógicamente correcto es el protocolo de parada y espera. Si lo situamos en la pila de protocolos TCP/IP correspondería al nivel 2 o nivel de enlace. Será el ejemplo que usaremos como referencia a lo largo de esta memoria. 2.1 Descripción A grandes rasgos el funcionamiento del protocolo consiste en: La estación emisora envía una trama a la estación receptora. La estación receptora después de la llegada de la trama, envía una señal para indicar que puede continuar. La estación emisora debe esperar esta señal para mandar la siguiente trama. Pero es obvio que se pueden perder tramas durante la transmisión por lo que debe tener recuperación de errores. Para ello utiliza un mecanismo de ARQ (automatic repeat request), que consiste en retransmisiones por parte del emisor si se detecta algún tipo de error. En el caso anterior si se pierde una trama de datos habríamos perdido información. Para solucionar esto el emisor incorpora un temporizador de retransmisión, y en el caso de no recibir la trama de confirmación en un intervalo determinado de tiempo realiza una retransmisión de la misma trama. Pág. 9 de 18

10 Con esto habríamos solucionado el problema de pérdida de tramas pero no de pérdida de confirmaciones. Si se produce una de ellas, el receptor recibirá dos tramas duplicadas porque vencerá el temporizador como hemos dicho anteriormente, y dicha trama se desechará. Para solucionar este caso introduciremos numeraciones en las tramas y en las confirmaciones, de este modo el receptor cada vez que confirme una trama enviará además el número de trama por la que espera. Podemos observar que una vez llega la trama de confirmación ACK con parámetro 1 el emisor ya sabe que el receptor espera por esa trama, enviándosela posteriormente. Por último, podemos destacar que sólo son necesarias dos numeraciones de tramas (0 y 1), ya que una vez enviada la trama 1 volveremos a enviar la trama 0. Pág. 10 de 18

11 2.2 Especificación en SDL Una vez conocido el protocolo parada y espera vamos a ver como sería su especificación en SDL. A nivel de sistema tendríamos lo siguiente: El sistema contiene dos bloques, uno será el emisor y otro el receptor. Entre ambos podemos ver que hay dos canales (C1 y C2) por los que se enviarán las señales TRAMA_DATOS y ACK. Aparte, el emisor posee otro canal de entrada (C3) por el que le llega la señal DATOS_EMISOR del exterior o entorno. En la pila de protocolos TCP/IP esta señal sería enviada por el nivel superior (nivel 3), pero como no vamos a modelar ese nivel la señal la enviará el usuario mediante una interfaz. El receptor también posee otro canal (C4) pero en este caso de salida, el cual transporta la señal DATOS_RECEPTOR hacia el entorno. Esta señal también debería ser enviada al nivel 3 pero por los mismos motivos se manifestará en la interfaz de usuario como la anterior. También observamos que hay un cuadro text con la declaración de las señales dichas anteriormente, debemos declarar TRAMA_DATOS y ACK con un parámetro entero para la numeración de tramas y confirmaciones como hemos dicho en el apartado anterior. Pág. 11 de 18

12 2.2.1 El bloque emisor El bloque emisor corresponde a toda la entidad emisora y contiene lo siguiente: Principalmente, el bloque EMISOR contiene un único proceso que se denomina EMISOR igualmente. Este nivel debe ser coherente con los distintos niveles, por lo que el bloque deberá tener la misma interfaz (canales de entrada y de salida) que el que aparece en el nivel de sistema. En este caso no declararemos las señales porque ya lo hicimos en el nivel superior. Pág. 12 de 18

13 El proceso EMISOR está definido de la siguiente forma: Dentro de este proceso tenemos un total de 3 variables locales. La primera de ellas es n y se utiliza para recibir el parámetro de la señal ACK una vez la recibamos (ver apartado 1.3). La segunda es nsec y representa la numeración de la trama que vamos a enviar, por lo que se utilizará como parámetro en la señal TRAMA_DATOS. Por último tenemos incnsec, la cual contiene el valor que deseamos recibir en un ACK, es decir, la numeración que tiene que llevar un ACK recibido para confirmar la última trama enviada. En el comienzo del proceso lo primero que se realiza es una inicialización de la variable nsec a cero, esto es, para que la primera trama se envíe con dicha numeración. Posteriormente se pasa al estado DESOCUPADO. Pág. 13 de 18

14 Como ya hemos dicho, un símbolo de estado debe estar seguido de un símbolo Input. En este caso esperaremos por la señal DATOS_EMISOR que como ya hemos mencionado provendría del nivel 3 indicándonos que debemos enviar una trama al otro extremo. Durante esta transición de estado lo primero que realizaremos será enviar la señal TRAMA_DATOS al bloque receptor con el parámetro nsec como habíamos dicho anteriormente. Seguidamente deberemos calcular el número de secuencia que deberá llevar la trama ACK que recibiremos para que la confirmación de la trama enviada sea correcta. Para ello almacenamos el número de secuencia recientemente enviado en la variable incnsec, y llamamos al procedimiento INC_MOD_incnsec que calculará el valor esperado en una trama ACK a partir del número de secuencia recientemente enviado con la trama de datos (en nuestro caso como solo tenemos dos números de secuencia cambiará 0 por 1 y 1 por 0). Para terminar esta transición inicializamos el temporizador de retransmisión T. El estado al que saltaremos será ESPERANDO_ACK, que simboliza el intervalo de tiempo en el cual el emisor envía la trama y espera la confirmación ACK. Pág. 14 de 18

15 Dentro de este estado tenemos dos transiciones posibles. La primera de ellas es que recibamos una trama ACK (corresponde a la rama de la izquierda). Si esto ocurre deberemos realizar una comprobación sobre el parámetro que contiene dicha señal, que habremos copiado en la variable local n. En la transición al estado ESPERANDO_ACK hemos dejado el valor correcto que debe contener una trama ACK recibida en la variable incnsec, por lo tanto comprobaremos si n es igual a incnsec en un símbolo de bifurcación. Si esto se cumple (rama true) incrementaremos la variable nsec mediante el procedimiento INC_MOD_nsec y pasaremos al estado DESOCUPADO nuevamente. En caso contrario, el ACK que hemos recibido lleva un número de secuencia incorrecto (rama false), por lo que deberemos pasar nuevamente al estado ESPERANDO_ACK habiendo desechado la trama. La otra opción (rama de la derecha) se dará en el caso de que venza el temporizador de retransmisión, la cual se realizará si recibimos la señal T (recordemos que si un temporizador vence envía una señal con su mismo nombre al proceso actual). Si esto ocurre quiere decir que algo no ha ido bien y que deberemos retransmitir la trama. Por lo tanto enviaremos la señal TRAMA_DATOS con el mismo parámetro nsec (sin modificarle ya que se trata de la misma trama). Seguidamente volvemos a inicializar el temporizador y pasamos al mismo estado ESPERANDO_ACK. Para terminar la explicación del bloque EMISOR vamos a ver la definición de dos procedimientos: INC_MOD_incnsec e INC_MOD_nsec. Dado que son procedimientos auxiliares, deben tener su correspondiente símbolo de declaración como muestra la siguiente figura: Pág. 15 de 18

16 Éstos, como ya hemos dicho, estos procedimientos incrementan los valores de incnsec y nsec respectivamente. El primero de ellos está definido de la siguiente forma: Al tratarse de un procedimiento comienza con el símbolo Procedure Start (ver sección 1.3). Seguidamente realiza una comprobación sobre la variable incnsec que queremos incrementar. Si el valor de la variable es igual a cero cambiará su valor a uno y viceversa. En ambos casos se retorna del procedimiento con el símbolo correspondiente. El otro procedimiento INC_MOD_nsec queda de la siguiente forma: Pág. 16 de 18

17 En este caso no hace falta realizar ninguna explicación, ya que es similar al anterior pero modificando la variable nsec El bloque receptor El bloque receptor corresponde a toda la entidad receptora y contiene lo siguiente: El bloque RECEPTOR contiene un único proceso que se denomina RECEPTOR igualmente. Como hemos dicho en el apartado anterior este nivel debe ser coherente con los distintos niveles, por lo que el bloque deberá tener la misma interfaz (canales de entrada y de salida) que el que aparece en el nivel de sistema. Tampoco declararemos ninguna señal porque ya lo hicimos en el nivel de sistema. Pág. 17 de 18

18 La definición del proceso RECEPTOR queda de la siguiente forma: Podemos observar que hemos realizado la declaración de tres variables enteras. La primera de ellas se denomina rec y sirve para recoger el parámetro que contiene la señal TRAMA_DATOS una vez recibida. La segunda es nesp, que servirá para almacenar el número de secuencia que tiene que tener la trama de datos para que sea correcta. Por último tenemos la variable aux, la cual es una variable auxiliar que utilizaremos para devolver el valor de Pág. 18 de 18