Stateflow es una herramienta de diseño gráfico interactiva que trabajando con simulink modela y simula sistemas dirigidos por estados o eventos.
Estos sistemas son a menudo utilizados para modelar la lógica que controla dinámicamente dispositivos físicos como ventiladores, motores y otros dispositivos.
Los sistemas dirigidos por eventos pueden ser modelados como máquinas de estados.
En realidad el tipo de máquinas de estados que Stateflow permite que sean descritas es una variante de las clásicas máquinas de estados. Ésta variante es la descrita por Harel y que denomina statechart, traducido por algunos autores como cuadro de estados.
Las características fundamentales que añade este tipo de modelado de máquinas de estados al enfoque tradicional es:
- Estructura jerárquica del diagrama.- Esto permite crear máquinas de estados tradicionales dentro de un estado de la de nivel superior. De esta forma solo se desarrolla el comportamiento de dicha máquina de nivel inferior, cuando la de nivel superior tiene activo el estado correspondiente.
- Estados paralelos (concurrencia).- Permite que dos estados estén activos a la vez, que junto con la estructura jerárquica permite que dos máquinas de estados de nivel inferior se ejecuten a la vez de forma concurrente (en realidad se ejecutan secuencialmente, pero con más de un estado activo a la vez).
- Estados paralelos (concurrencia).- Permite que dos estados estén activos a la vez, que junto con la estructura jerárquica permite que dos máquinas de estados de nivel inferior se ejecuten a la vez de forma concurrente (en realidad se ejecutan secuencialmente, pero con más de un estado activo a la vez).
Con estas características se superan limitaciones clásicas de las máquinas de estados y nos aproxima, en posibilidades, a las descripciones realizadas con redes de Petri.
El sistema descrito mediante la herramienta estará incluido en una modelización completa del problema mediante simulink, siendo un bloque más del diagrama.
En la siguiente figura se observa la estructura de todos los elementos implicados en la descripción de sistemas mediante Stateflow. En primer lugar en la parte superior izquierda se representa en un rectángulo todos los elementos de un diagrama de simulink, y entre ellos la descripción realizada con Stateflow. En dicho diagrama se asume que la máquina objetivo está completamente modelada mediante elementos de simulink, comunicándose con stateflow mediante señales de entrada y de salida, que se representan en la figura como datos y eventos (data/event).
A su vez Stateflow se indica como dos subsistemas: el diagrama general de estados (Chart) y los estados propiamente dichos, si bien no queda claramente indicado que cada uno de esos estados puede contener en sí otro diagrama completo que solo se ejecutará o cumplirá sus funciones en el caso de que el estado al que pertenece esté activo.
De esa forma la estructura jerárquica crecería en forma de árbol hasta llegar a estados que no contengan más que sus propias acciones a realizar al estar activos.
Una característica fundamental de Stateflow es que para realizar la simulación genera código C que es compilado para el entorno utilizado. Asimismo puede ser optimizado para la implementación en la plataforma de destino mediante la utilización de Stateflow Coder que genera código C portable.
En el caso de utilizar Real-Time Workshop quedaría perfectamente integrado el código generado por Stateflow Coder.
Elementos de Stateflow - Chart
Estados (States)
Los estados representan o bien estados propiamente dichos como en el planteamiento clásico de máquinas de estados, o bien engloban una completa máquina de estados que solo se ejecuta cuando dicho estado esté activo.
Este anidamiento de máquinas sobre estados se puede hacer de forma recursiva. En la figura anterior se puede observar como en la máquina de estados incluida en el estado ‘StateA’ del diagrama raíz existen dos estados StateA1 y StateA2. En el primero existe una máquina de estados formada por tres estados StateA1a, StateA1b y StateA1c.
- En paralelo (AND).- Se indican en el gráfico con línea discontinua y se ejecutan todos a la vez, lo que funcionalmente se puede entender como de forma concurrente.
- Alternativamente (OR exclusive).- Se indican en el gráfico con línea continua y se ejecutan de forma exclusiva uno cada vez.
La siguiente figura representa los dos tipos de estados de forma gráfica.
Los estados pueden disponer de acciones a realizar en distintos instantes de su ejecución:
- Entrada (entry).- Cuando se activa el estado una sola vez.
- Durante (during).- Mientras esté activo el estado cada vez que se evalué el diagrama.
- Salida (exit).- Cuando se desactiva el estado una sola vez.
- Cuando (on).- Estando activo si se produce cierto evento.
En la figura acontinuación se muestra un estado que utiliza las distintas opciones.
Transiciones (Transitions)
Las transiciones representadas mediante un segmento orientado indican el siguiente estado a estar activo cuando lo esté el estado de origen, es decir, dado un estado activo y del que se origina una transición a otro, si se cumplen las condiciones adosadas a la transición, dejará de estar activo el primero para pasar a estarlo el segundo.
Si una transición no tiene ninguna condición se produce cada vez que se evalué el diagrama (por ocurrir cualquier evento). En general las transiciones tienen alguna condición que debe cumplirse para que se produzcan.
La nomenclatura utilizada para representar las transiciones es la de la siguiente tabla.
- Evento (event).- Indica que evento provocará que sea evaluada la condición de la transición. En ausencia de evento de forma explícita será válido cualquier evento del diagrama, incluido el paso por cada periodo de muestreo de simulink.
- Condición (condition).- Se expresa que condición debe de ser cierta para que se active la transición habiéndose producido el evento correspondiente y se ejecute la acción_condicionada.
- Acción_condicionada (condition_action).- Se ejecuta cuando es cierta la condición anterior.
- Acción de transición (transition_action).- Se ejecuta la acción antes de ser excitado el estado siguiente.
En el ejemplo se dispone de cuatro transiciones con una condición, cada una, en las que se evalúa la temperatura de la Planta para apagar o encender los ventiladores, y dos transiciones sin condición, solo con referencia al evento (SWITCH), que son la que van y vienen de PowerOff y PowerOn.
Transición por defecto (“Default Transitions”)
La transición por defecto es aquella que se activa al ser activado la máquina de estados donde está incluida, es decir que cada vez que se active una máquina de estados se activará el estado apuntado por la transición por defecto.
La transición por defecto no tiene por tanto origen pues no viene de ningún estado anterior. Solo tiene sentido aplicarlas cuando los estados están agrupados en forma de activación alternativa, y no cuando lo están en forma paralela, ya que en ese caso no hay ambigüedad posible.
En el siguiente ejemplo hay tres transiciones por defecto que hacen que: en el arranque del sistema el estado activo sea PowerOff , y que al activarse PowerOn los estados activos en FAN1 y FAN2 sean Off.
En la figura 2-6 se puede ver la utilidad de la transición por defecto que provoca que al activarse el estado Lights siempre esté activo el estado Off..
Memoria de estado (“History Junction”)
Cuando se introduce provoca que al reactivarse una máquina de estados en vez de activarse el estado apuntado por la transición por defecto se active el último que estuvo activo.
En el siguiente ejemplo se puede observar un ejemplo en el que la memoria de estado corresponde con el símbolo H inscrito en un círculo.
El sistema puede estar en Power_on u off, y mientras que la primera vez que se activa (Power_on) el estado activo dentro de Power_on es Low, las siguientes veces que se activa el estado activo será el último que lo estuvo. Es decir que aunque hay una transición por defecto esta ya no actúa después de la primera ejecución de la máquina de estados.
Todas las transiciones reaccionan a los eventos que son las situaciones previamente definidas, y que en el desarrollo de funcionamiento de la máquina, se producen. Cada vez que se produce un evento provoca que se evalúen los estados y transiciones del diagrama.
Los eventos no se aprecian gráficamente en el diagrama, solo se observan las etiquetas que los definen. En la creación de un diagrama es preciso definir en que consiste cada evento, para ello se utiliza la parte de la herramienta denominada ‘Stateflow Explorer’.
Existen diversas formas de generar eventos pero, sin duda, la más habitual es la de introducir una señal de reloj que periódicamente, y con uno de sus flancos, provoque la evaluación de las condiciones en todas las transiciones. Esto implica directamente implementaciones digitales inmediatas.
Se pueden utilizar múltiples entradas para provocar con sus flancos eventos, eso sí, todas entran por un único pin al bloque de stateflow en forma de array de entradas.
Esto puede tener utilidad para disponer por ejemplo de varios relojes de distintas frecuencias, entradas de interrupción por flanco, etc.
El aspecto de la ventana de introducción de eventos, así como de otros elementos, es como la de la figura acontinuación en la que se muestra el evento ‘event’ que se producirá cuando se produzca el flanco de bajada de la señal número dos de las que entran por el pin de eventos.
En el ejemplo descriptivo de la imagen anterior no se observa la indicación explícita de ningún evento dentro de las máquinas incluidas en PowerOn, esto es por que se ha utilizado una señal periódica de reloj para excitar el diagrama, además entre los superestados PowerOn y PowerOff si se expresa el evento SWITCH que corresponde con la otra entrada de eventos procedente de un switch como se puede observar en el diagrama de estados anterior.
Datos (“Data”).
Los datos que internamente para el procesado de la información que el diagrama precise deben ser previamente definidos, salvo que se utilicen referencias al espacio de trabajo de Matlab, aunque como el fin último es la implementación esto último no sería recomendable.
En la siguiente figura se observa la ventana de introducción de datos para la definición de un dato interno al diagrama.
Otros datos habituales son los datos que se comparten con el espacio de simulink mediante los puertos de entrada y de salida.
Acciones (“Actions”)
Se pueden realizar acciones tanto en las transiciones, como en los estados en las distintas opciones que los estados contemplan, ya descritas en el apartado correspondiente.
Dado que stateflow para su ejecución compila el modelo previamente a la ejecución, a partir de una versión intermedia en C, para las acciones se puede usar un subconjunto de instrucciones propias de C. También admite la ejecución de scripts de Matlab mediante el operador de ámbito: ‘ml.’.
Entre las operaciones que son permitidas en la ejecución de acciones están las operaciones lógicas, desplazamientos, incrementos y decrementos, operadores cast, punteros, etc.
Incluso se pueden declarar funciones en C en fichero de código fuente aparte para ser llamadas dichas funciones desde las llamadas a las acciones del diagrama.
Existe también la posibilidad de ejecutar acciones basándose en condiciones que tienen implicaciones temporales con los eventos, como por ejemplo la siguiente que solo se activa cuando además de producirse el evento ‘CLK’ es necesario que sea la décima vez que se produce y además la ‘temperatura’ tenga el valor de ‘frío’.
CLK[after(10,CLK)&&temp==COLD]
Existen otras opciones temporales como: before, at y every.
Uniones de conexión (“Connective Junctions”)
Las uniones de conexiones permiten la representación de difrentes posibles caminos de transición desde una única transición. Permiten hacer la representación, entre otras, de las siguientes situaciones:
- Estructuras ‘if-then-else’.
En la siguiente figura se observa de forma gráfica el equivalente a la siguiente expresión:
Habiéndose producido el evento E-one, “If (C_one) then ‘B’, else if (C_two) then ‘C’, else ‘D’.
- Variaciones sobre la estructura de un bucle ‘for’.
En la siguiente figura se observa de forma gráfica el equivalente a un bucle de diez iteraciones en la unión antes de que se produzca la transición de ‘A’ a ‘B’.
- Transiciones tanto de múltiples orígenes a un destino, como de un único origen a múltiples destinos.
En la figura siguiente se observa la siguiente situación: Tanto en la primera ejecución, como tras la ocurrencia del evento ‘UPDATE’ se ejecuta la acción ‘start_adc()’, luego a partir de varios orígenes se ha ejecutado la misma transición. A continuación hay un lazo que obliga a esperar hasta que sea cierta la condición ‘adc_busy()’, es decir, se termine la conversión analógico a digital. Cuando por fin se termine, no se cumplirá la anterior condición, y por tanto se testeará la siguiente transición, que solo sirve para ejecutar la acción de leer el adc, donde se llega a una unión de transiciones que permite llevar a distintos estados en función de la lectura del adc almacenada en una variable local ‘sensorValue’, esto es, si menor que 100 el siguiente estado será ‘Low’, si mayor que 200, será High, y en caso contrario (ELSE) ‘Normal’.
Tabla de la verdad (“Truth Table Functions”)
Mediante una tabla de verdad se puede expresar de una forma clásica el comportamiento de parte del sistema.
Se definen las posibles condiciones que se pueden cumplir y las posibles acciones que se pueden realizar, relacionadas ambas con la propia tabla de comportamiento.
En las siguientes imágenes se ve la aplicación de dicho modo descriptivo.
0 comentarios:
Publicar un comentario