15:43 1 de 26
Andrés Djordjalian <[email protected]>Seminario de Sistemas Embebidos
Facultad de Ingeniería de la U.B.A.
Statecharts
15:43 2 de 26
StatechartsLos diagramas de estado son particularmente útiles para modelar sistemas embebidos porque estos suelen ser reactivos
O sea, responden a eventos externos que no necesariamente tienen orden o periodicidad
En 1987 Harel propone Statecharts, una evolución del lenguaje clásico de los diagramas de estados
D. Harel, “Statecharts: A visual formalism for complex systems”, Science of Computer Programming, vol. 8 num. 3, pp. 231–274, junio de 1987
Para modelar sistemas medianamente complejos, los Statecharts son más compactos y claros que los diagramas de estados clásicos
Principalmente porque incluyen jerarquías y concurrencia
Forman parte del UML y se usan extensivamente en herramientas MDD para embebidos
15:43 3 de 26
Bibliografía recomendada
M. Samek, Practical UML Statecharts in C/C++, Capítulo 2
También está disponible como artículo en línea de EE Times
• Ver en nuestra página de material de estudio
15:43 4 de 26
¿Para qué?Samek arranca elcapítulo con unejemplo: lacalculadora quevenía con VisualBasic, que dabaerror si uno tecleaba cosas como 2, -, -, -, =
Argumenta que, de haberla modelado con una máquina de estados antes de sentarse a programar, se podían haber evitado tantos erroresAl final del capítulo diseña ese modelo
usando bastante de la semántica extendida que provee Statecharts por sobre un diagrama de estados clásico
15:43 5 de 26
Estados y transiciones
Como el diagrama de estados de una máquina de Mealy, pero usa rectángulos con esquinas redondeadas para los estados y un círculo lleno para el reset
También pueden modelar máquinas de Moore, lo vemos más adelante
Estados
Reset (Evento de) trigger(o sea, entrada)
Acción(o sea, salida)
15:43 6 de 26
Máquinas de estados extendidas
“Extendida” debido al uso de la variable key_countLos pseudoestados de decisión son otro agregado a la semántica clásica de las máquinas de estado que usa Statecharts
3 diapositivas atrás dijimos “más compactos y claros”…
15:43 7 de 26
Jerarquías
Lo que hicimos fue modelar el comportamiento dentro de “esperando” con una máquina de estadosEste tipo de jerarquización permite, en muchos casos, economizar transiciones, entre otras simplificaciones
que clarifican el diagrama y reducen la cantidad de errores en su edición
15:43 8 de 26
Jerarquías
Notar que, en el ejemplo, la transición que dispara con “pulsó ‘empezar’” sale de “ingresando tiempo”
O sea que si el sistema está en “idle”, pulsar empezar nocambia el estado
• Al menos en lo que respecta al alcance de este diagrama
El comportamiento en “ingresando tiempo”probablemente también sea útil modelarlo con un diagrama de estados
Podemos ponerlo allá adentro o en “hoja” separada
15:43 9 de 26
En mi microondas, si no se ingresó un tiempo y se presiona “empezar”, arranca con tiempo = 30s. ¿Cómo podemos modificar el diagrama de arriba para incorporar ese comportamiento?
Pueden suponer que existe una variable “tiempo” que es modificada en “ingresando tiempo” y tomada por el timer cuando este arranca
Evalúen diferentes maneras de resolverloPueden usar sintaxis de C, separando sentencias con “;”, y poner acciones en las transiciones iniciales (o sea, resets)
• Pero triggers en los resets no, ¿por qué?
Actividad
15:43 10 de 26
Concurrencia
Las dos sub-máquinas son independientesSalvo la cláusula “en ‘esperando’” en los triggers de abajo
Por eso, a la concurrencia comúnmente se le dice ortogonalidad
15:43 11 de 26
Acciones “Entry” y “Exit”
15:43 12 de 26
Transiciones internas
Notar que son similares a transiciones que empiezan y terminan en el mismo estado, salvo que no se ejecutan las acciones “entry” y “exit”A “calentar” normalmente se le dice actividad porque es un tanto constante
15:43 13 de 26
Transiciones locales y externas
En las externas se ejecutan la acciones “exit” (porque sale) y “entry” (porque vuelve a entrar), en las locales no
15:43 14 de 26
PseudoestadosSon lugares que parecen estados pero no lo son, porque el sistema no puede “estar” en ellos
Sirven para simplificar el diagrama e incorporarle algunas funcionesTipos:
Inicial (reset)• Se indican con un círculo lleno negro
Condición (o choice u opción)• Se indican con un diamante, un circulo vacío o uno que contiene una “C”• Lo usamos en la Diapositiva 6
Junturas• Se indican con un punto negro• Sirven para juntar o bifurcar transiciones cuando tienen partes en común
Historia• Se indican con un círculo que contiene una “H”• Si se entra en una transición que termina en este pseudoestado, el próximo
estado pasa a ser el último estado que tenía la (sub) máquina en cuestiónFork / Join
• Misma notación y propósito que las transiciones de las redes de Petri• Con un fork se “abre” una transición para que pueda terminar en estados de
máquinas concurrentes. Join hace lo contrario.Final
• Se indica con un círculo que contiene una “T”
15:43 15 de 26
Ejemplo
Tomado de B.P. Douglass, “UML Statecharts”, <http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.104.3629>
15:43 16 de 26
Transiciones, con más detalleForma general del rótulo de una transición:
Todos los campos son optativosLas acciones pueden ser salidas hacia el exterior, o eventos queotra parte del modelo usa como trigger
Tipos de eventos:Señal
• La recepción de una señal (asincrónica)• Es el tipo de evento más común
Tiempo• Se cumplió cierto tiempo desde la llegada al estado• Se escribe (ej.) after 200ms o también tm(200ms)
Llamada• Disparado por otra parte del sistema sincrónicamente (o sea, esa
otra parte del sistema espera hasta que la llamada es atendida) Cambio
• Cierta expresión condicional pasa a ser cierta• Se indica con when seguido de la expresión
nombre_del_evento(parámetros) [condición] / acciones
15:43 17 de 26
Transiciones, con más detalleForma general del rótulo de una transición:
La condiciónLa transición se dispara sólo si esa expresión es verdaderaPuede incluir (ej.) in(nombre_de_un_estado), para condicionar la transición a que una máquina concurrente con esta esté en cierto estado
• …como vimos en varios de los ejemplos anteriores
EjemplosevCaenPinos / GenerarRuido()evLlegóBola / cantBolas++;print(“Llegó”)evCaenPinos(n)[n>=10] / MarcarChuza()/ Inicializar()[cantidad % 10 == 0]after 10ms / InformarTimeout();AbrirPuerta()when cantidad % 10 == 0 / foo++;bar++Pulsó_Empezar[in(Puerta_Cerrada)] / Arrancar
nombre_del_evento(parámetros) [condición] / acciones
15:43 18 de 26
Preguntas Actividad
15:43 19 de 26
Statechart + requisitos de tiempo real
B.P.Douglass; “Capturing Real-Time Requirements “<http://www.embedded.com/story/OEG20011016S0126>
Notas con requermientosde temporización y de
calidad de servicio (qualityof service o QoS)
15:43 20 de 26
Dibujar el statechart de un dispenser de café y leche:El dispenser puede estar desactivado (por ejemplo para ser llenado) o activado, para lo cual se utiliza un pulsador ON/OFF. Estando activado, se sirve café manteniendo presionando un pulsador CAFÉ y se detiene ese chorro soltando el pulsador. Lo mismo ocurre con la leche y su pulsador LECHE. Hacer dos versiones del statechart: una en donde sólo pueda servirse una de las bebidas a la vez, otra en donde las dos bebidas puedan servirse simultáneamente.
Dibujar el statechart de un calefactor con termostato:El dispositivo cuenta con los siguientes pulsadores: ON/OFF, CALENTAR, ESPERAR, TERMOSTATO, TEMP+, TEMP-. Con ON/OFF se enciende y apaga. Al ser encendido, entra en un estado espera.Cuando el usuario presiona el pulsador CALENTAR, el calefactor calienta. Cuando presiona TERMOSTATO, entra en un estado en donde calienta sólo si la temperatura del ambiente, medida mediante un sensor, es menor que un valor prefijado regulable con los pulsadores TEMP+ y TEMP-.En el diagrama anterior, agregar otro modo de operación que se activa al presionar un pulsador SLEEP. En este nuevo modo, el calefactor calienta durante 10 minutos y vuelve al estado espera.
Actividades
15:43 21 de 26
¿Cómo codificar un Statechart?Una posibilidad es crear un gran switch … case, donde cada estado corresponda a un case
15:43 22 de 26
¿Cómo codificar un Statechart?
B.P. Douglass, “State Machines and Statecharts”,<http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.40.1095>
15:43 23 de 26
¿Cómo codificar un Statechart?El programa puede ser un ciclo infinito conteniendo ese switch … case
Para implementar:• Concurrencia: varios switch … case en secuencia• Jerarquías: switch … case anidados
El problema es que eso va a ocupar al 100% al procesador por más que no tenga nada “real” que hacer porque aún no llegan estímulos
• En ciencias de la computación, esta condición se llama busy wait• Igualmente, para ciertas aplicaciones es una solución aceptable
– En otras, el consumo que esto conlleva no lo es
Si el procesador tiene otro código de qué ocuparse también, puede ir después del switch … case, dentro del ciclo infinito
Esto modera el problema del busy wait, pero puede atentar contra el cumplimiento de requerimientos de tiempo real
15:43 24 de 26
Idea¿Poner al procesador en modo sleep después del switch … case?
Sleep es un modo de bajo consumo donde el microcontrolador no procesa instrucciones pero sí funcionan sus periféricos y es capaz de detectar interrupciones
Los microcontroladores normalmente ofrecen varios de estos modos, que se diferencian por las funciones que permanecen activadas y el retardo en volver al modo de ejecución normal
Si se puede, se hace que del modo sleep salga al detectar el estímulo que actúa de trigger en la máquina de estados
Si no se puede, consideremos ponerlo x tiempo (usando un timer), siempre que no comprometa los requerimientos de tiempo real
15:43 25 de 26
Maneras más avanzadas de codificarlo
En lugar de case para cada estado (“hardcodeado”), poner los datos del Statechart en un array y usar una librería
Tengan en cuenta que se pueden guardar punteros a funciones que contengan las condiciones y las accionesSi el switch … case quedaba intrincado, esto puede simplificarloAdemás, la librería puede proveer funciones avanzadas para resolver el tema del busy waitEl libro de Samek presenta una librería así
Programar el Statechart bajo un RTOSUsar una herramienta MDD
Como IBM Rational Rhapsody o el Real-Time Workshop para Simulink de Mathworks• Funcionan con varios RTOS populares
15:43 26 de 26
ConclusionesLos Statecharts son un lenguaje de creciente popularidad en embebidos
Extienden el lenguaje clásico de las máquinas de estados, en una forma que resulta muy práctica para el modelado de software
Existen diferentes maneras de implementarlosCada una tiene pros y contras en cuanto a su complejidad, consumo, tiempo de respuesta y necesidad de software de base
Sirven para detallar las ideas antes de implementarlas, lo que nos sirve para:
Ordenar las ideas, ponernos de acuerdo con colegas y documentarEjecutarlos (o sea, simularlos) para corregir errores y explorar alternativasTraducirlos automáticamente a C u otro lenguaje de programación, si contamos con una herramienta MDD apropiada
• Dentro de estas, normalmente se puede elegir la versión de C, de las librerías y de RTOS (si usamos uno); y se puede trabajar sobre el código resultante