Funcionamiento de Stateflow chart -...

Doctorado en Electrónica. “Captación Multisensorial y Sistemas Robóticos”

“SIMULACIÓN DE LA SECUENCIA DE ESTADOS UTILIZANDO

STATEFLOW CHART PARA UN AEROGENERADOR”

TRABAJO DE INVESTIGACION PARA EL CURSO: “TECNICAS AVANZADAS DE DISEÑO DE SISTEMAS

DIGITALES”

(Curso 2005-2006)

Dirigido por: Francisco Javier Rodríguez

Realizado por:

Ramón Rodríguez

Simulación de la secuencia de estados utilizando la Toolbox Simulación de la secuencia de estados utilizando la Toolbox Simulación de la secuencia de estados utilizando la Toolbox Simulación de la secuencia de estados utilizando la Toolbox

Stateflow Chart para un AerogeneradorStateflow Chart para un AerogeneradorStateflow Chart para un AerogeneradorStateflow Chart para un Aerogenerador

1 INTRODUCCIÓN A STATEFLOW. ............................................................................. 3

2 ELEMENTOS DE STATEFLOW-CHART................................................................... 7

2.1 ESTADOS (“STATES”). .................................................................................................... 7 2.2 TRANSICIONES (“TRANSITIONS”).................................................................................. 9 2.3 TRANSICIÓN POR DEFECTO (“DEFAULT TRANSITIONS”)........................................... 10 2.4 MEMORIA DE ESTADO (“HISTORY JUNCTION”). ........................................................ 11 2.5 EVENTOS (“EVENTS”)................................................................................................... 11 2.6 DATOS (“DATA”)........................................................................................................... 12 2.7 ACCIONES (“ACTIONS”). .............................................................................................. 13 2.8 UNIONES DE CONEXIÓN (“CONNECTIVE JUNCTIONS”). ............................................. 14 2.9 TABLA DE LA VERDAD (“TRUTH TABLE FUNCTIONS”). ............................................. 16



1 Introducción a Stateflow.

Stateflow es una herramienta de diseño gráfico interactiva que trabajando con simulink modela y simula sistemas dirigidos por eventos.

Estos sistemas son a menudo utilizados para modelar la lógica que controla dinámicamente dispositivos físicos como ventiladores o motores.

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 1 y que denomina statechart, traducido por algunos autores como carta de estados.

Las características fundamentales que añade este tipo de modelado de máquinas de estados al enfoque tradicional es:

1. 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.

2. 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).

3. Memoria.- Esto permite que cuando un estado, que a su vez incluye toda una máquina de estados, fue desactivado y posteriormente se activa, la máquina de estados incluida en él, continúa en el estado que tenía cuando el estado que la incluye fue desactivado.

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 figura 1-1 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).

1 Harel, David, “Statecharts: A Visual Formalism for Complex Systems,” Science of Computer Programming 8, 1987, pages 231-274.



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.

Figura 1-1.- Elementos que intervienen en la descripción de sistemas basados en Stateflow Chart.

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.



Para conocer en detalle la utilización básica de Stateflow se va a describir un sistema completo a la vez que se describen los elementos que componen las descripciones de sistemas basadas en Stateflow.

El sistema comentado es un control de temperatura de una Planta basado en la utilización de dos ventiladores para refrigerarla. El control de dichos ventiladores lo realizará un sistema completamente modelado con stateflow.

En la figura 1-2 se muestra dicho sistema completo en una captura de simulink.

Figura 1-2.-Modelo completo del sistema que incluye el bloque stateflow.

Se puede observar la interfaz del bloque Stateflow con el resto de bloques de simulink. Dicha interfaz se basa en una entrada de datos (temp) que corresponde al valor de la temperatura de la Planta, una salida de datos (airflow) que indica el numero de ventiladores encendidos y una entrada de eventos que está compuesta de una señal periódica de reloj y una señal proveniente de un interruptor de encendido del sistema.

En la figura 1-3 se muestra el diagrama de estados del sistema controlador modelado con Stateflow. El modelo incluye los siguientes comportamientos:

1. Apagado y encendido del sistema basado en la actuación sobre un interruptor.

2. Apagado y encendido del ventilador 1 cuando la temperatura supere cierto umbral 1 (120ºC).

3. Apagado y encendido del ventilador 2 cuando la temperatura supere cierto umbral 2 (150ºC).

Cada vez que cambie de valor el interruptor se produce un cambio de estado en la máquina de estados raíz activándose alternativamente los estados PowerOn y PowerOff. Cuando está activo el estado PowerOn se activan simultáneamente (concurrencia) los tres subestados (o máquinas de estados de orden jerárquico inferior) FAN1, FAN2 y SpeedValue.



Figura 1-3.- Diagrama de Stateflow Chart del controlador de la planta.

Cuando están activos los estados FAN1 y FAN2 se ejecutan las máquinas de estados que están incluidas en ellos y que alternan entre ON y OFF, que se corresponden con el encendido y apagado de cada uno de los ventiladores.

Figura 1-4.- Estructura jerárquica del diagrama de estados stateflow.



En la figura 1-4 se muestra como se estructuran de forma jerárquica los distintos estados del diagrama del controlador.

2 Elementos de Stateflow-Chart.

Se pasa a describir los distintos elementos que se utilizan en los diagramas de estados realizados con stateflow que se pueden observar reunidos en la figura 2-1.

Figura 2-1.- Muestra de los distintos elementos utilizados en los Stateflow chart.

2.1 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 2-1 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.



Dentro de un estado, por tanto, pueden existir otros que se agruparán entre ellos de una de las dos formas posibles:

1. 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.

2. Alternativamente (OR exclusive).- Se indican en el gráfico con línea continua y se ejecutan de forma exclusiva uno cada vez.

La figura 2-2 representa los dos tipos de estados de forma gráfica.

Figura 2-2.- Representación de los dos tipos de estados utilizables.

Los estados pueden disponer de acciones a realizar en distintos instantes de su ejecución:

1. Entrada (entry).- Cuando se activa el estado una sola vez.

2. Durante (during).- Mientras esté activo el estado cada vez que se evalué el diagrama.

3. Salida (exit).- Cuando se desactiva el estado una sola vez.

4. Cuando (on).- Estando activo si se produce cierto evento.

En la figura 2-3 se muestra un estado que utiliza las distintas opciones.

Figura 2-3.- Estado con las distintas opciones de acciones a realizar indicadas.

El ejemplo planteado (Figura 1-3) contiene dos tipos de acciones utilizadas, como se puede observar en la figura 2-4:



• Entrada (entry = en).-En el estado de PowerOff.

• Durante (during = du).- Mientras esté activo el estado SpeedValue, es decir mientras esté activo el estado PowerOn.

Figura 2-4.- Estados utilizados en el ejemplo del controlador de temperatura.

2.2 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 figura 2-5.

• 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.

Figura 2-5.- Nomenclatura utilizada para representar las transiciones.

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.

2.3 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 ejemplo (Figura 1-3) 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.

Figura 2-6.- Ejemplo de utilización de transición por defecto.



2.4 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 la figura 2-7 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.

Figura 2-7.- Ejemplo de uso de la memoria de estado.

2.5 Eventos (“Events”).

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 2-8 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.

Figura 2-8.- Ventana de captura y edición de nuevos eventos, en este caso el evento ‘event’ 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 figura 1-3 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 la figura 1-2.

2.6 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 figura 2-9 se observa la ventana de introducción de datos para la definición de un dato interno al diagrama.



Figura 2-9.- Captura de pantalla de la ventana de introducción de datos del diagrama.

Otros datos habituales son los datos que se comparten con el espacio de simulink mediante los puertos de entrada y de salida.

2.7 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’, como se muestra en la figura 2-10 .



Figura 2-10.- Ejemplo de condición para ejecución de acción con implicación temporal.

Existen otras opciones temporales como: before, at y every.

2.8 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 figura 2-11 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’.

Figura 2-11.- Ejemplo de estructura if-then-else.

En la figura 2-12 se observa otro ejemplo claramente descrito.



Figura 2-12.- Otro ejemplo de estructura if-then-else.

• Variaciones sobre la estructura de un bucle ‘for’.

En la figura 2-13 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’.

Figura 2-13.- Ejemplo de implementación de un bucle.

• Transiciones tanto de múltiples orígenes a un destino, como de un único origen a múltiples destinos.

En la figura 2-14 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’.



Figura 2-14.- Ejemplo de múltiples destinos/orígenes.

2.9 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 figuras 2-15 y 2-16 se ve la aplicación de dicho modo descriptivo.

Figura 2-15.- Pseudos código de aplicación de la tabla de verdad.



Figura 2-16.- Ejemplo de descripción del comportamiento mediante tabla de la verdad.



3 IMPLEMENTACIÓN EN STATEFLOW CHART.

El funcionamiento del TCU ha sido modelado mediante la herramienta Stateflow-Chart permitiendo comprobar los modelos sin codificar para una máquina específica, ni decidir que parte implementar en código, y que otra en hardware.

Aprovechando la posibilidad de stateflow de la descripción jerárquica es fácil modelar el comportamiento de forma muy parecida a la propia descripción del dispositivo realizada anteriormente.

Como se puede observar en la figura 3-1 están representados los tres subsistemas de control del TCU, esto es el subsistema de control de guiñada (SUBSISTEMA_GUI), el subsistema de control de paso (SUBSISTEMA_PASO) y el control de la secuencia de arranque del sistema (SECUENCIA__ARRANQUE).

Dichos estados están modelados como estados concurrentes (AND).

Figura 3-1.- Diagrama general de estados.

3.1 Estado: SECUENCIA_ARRANQUE

El estado secuencia de arranque se subdivide en varios estados que se pasan a describir.

El estado por defecto, marcado por la transición por defecto es el de FUERA_DE_LINEA, que es un estado sencillo en el que se activa la salida STOP.



3.1.1 Estado: FUNCIONAMIENTO

En este estado es en el que se entra para arrancar el sistema, y desarrolla una serie de subastados hasta llegar al de SERVO que es el de funcionamiento normal del generador.

El estado de HABILITADO está únicamente para indicar el inicio de esta fase, pues no realiza ninguna acción. Es por ello que no tiene condición en su transición de salida.

Figura 3-2.- Estado FUNCIONAMIENTO

3.1.1.1 Estado: DESARROLLAMIENTO

En la figura 3-3 se comprueba que este estado tiene dos subastados, uno que es el de por defecto que realiza las comprobaciones y acciones correspondientes, y otro al que se pasa cuando todos los chequeos dan positivo.

Todas las comprobaciones se hacen el primero donde hay dos procesos concurrentes modelados mediante estados en forma AND. El final de estas fases se consigue mediante la generación de un evento interno: ‘OK’.



Figura 3-3.- Estado DESARROLLAMIENTO.

3.1.1.2 Estado: PRUEBA_DE_PASO

En este estado vuelve a haber dos estados concurrentes, mientras que el envio del evento OK se ha modelado desde uno de ellos (figura 3-4).

Figura 3-4.- Estado PRUEBA_DE_PASO.



3.1.1.3 Estado: ALINEACIÓN_GUIÑADA

Este es un estado sencillo que realiza una acción y una comprobación (figura 3-5).

Figura 3-5.- Estado: ALINEACIÓN_GUIÑADA

3.1.1.4 Estado: ACCIONAMIENTO_A_ESTADO_DE_ALERTA

Como el anterior, este es un estado sencillo que realiza una acción y una comprobación (figura 3-6).

Figura 3-6.- Estado: ACCIONAMIENTO_A_ESTADO_DE_ALERTA

3.1.1.5 Estado: ESTADO_DE_ALERTA

Como el anterior, este es un estado sencillo que realiza una acción y una comprobación (figura 3-7).



Figura 3-7.- Estado: ESTADO_DE_ALERTA

3.1.1.6 Estado: AUMENTADOR_SERVO

En este estado únicamente se realiza una accción (figura 3-8).

Figura 3-8.- Estado: AUMENTADOR_SERVO

3.1.1.7 Estado: SERVO

Este es el último estado y se permanece en él hasta parar el sistema, con lo que quedan todos los demás subsistemas en marcha (figura 3-9).



Figura 3-9.- Estado: SERVO.

3.1.2 Estado: PARADA_NORMAL

Este estado es totalmente similar a los otros dos tipos de paradas con pequeñas diferencias de valores de salidas, como se describió en el apartado correspondiente. En la figura 3-10 se aprecia su desarrollo que conlleva una serie de acciones.



Figura 3-10.- Estado: PARADA_NORMAL, totalmente similar a los otros tipos de parada.



3.2 Estado: SUBSISTEMA GUIñADA

Este es un estado concurrente con el de funcionamiento que controla el giro de guiñada y el sistema de amortiguamiento en función de estar habilitado o no, (1er nivel), y del error de guiñada que es una entrada del sistema (ERROR_GUI).

Figura 3-11.- Estado: SUBSITEMA_GUIÑADA



3.3 Estado: SUBSISTEMA PASO

Este es un estado concurrente con el de funcionamiento que controla el paso de las palas del aerogenerador, mediante la actuación sobre la salida velocidad del cilindro (VEL_CIL), en función del paso deseado y la lectura del paso conseguido.

Figura 3-12.- Estado: SUBSISTEMA_PASO.

Funcionamiento de Stateflow chart -...

Documents

Transcript of Funcionamiento de Stateflow chart -...