Departamento de

Sistemas e Informática

Sistemas Digitales II

Máquina de Estado Finito (MEF)

Implementación en código C
2020
 Contenido
 Sistemas Embebidos – Plataforma HW y aplicación SW
 Uso de modelos
 Sistemas Reactivos - Formalización
 MEF
 Statecharts
 Diagramas de Estado UML
 Codificación en C
 Desarrollo de una aplicación SW
 Objetivos
 Pautas de trabajo
 Ejemplo 2
 Material de consulta

 David Harel. “Statecharts: a Visual Formalism for Complex

Systems”, Elsevier Science Publishers, 1987.
 Miro Samek, “Practical UML Statecharts in C/C++, Second
Edition: Event-Driven Programming for Embedded Systems,”
Elsevier, 2009. Cap. 2 – Cap. 3.
(ftp://197.155.77.5/sourceforge/q/qp/qpc/doc/PSiCC.pdf)
 OMG Unified Modeling Language, Version 2.5 – Cap. 14, 2015.
 Mari Carmen Otero Vidal. “Diagramas de Estado”. Universidad
del País Vasco-Euskal Herriko Unibertsitatea. Dpto. de Lenguajes
y Sistemas Informáticos, 2012. 3
 Sistema digital ABSTRACCIÓN

MODELO DE
COMPORTAMIENTO

Requerimientos Características de las plataformas

4
 Desarrollo del sistema (HW + SW)

La plataforma HW está definida pero puede “personalizarse”

Aplicación SW – Bibliotecas

 Clock gating (módulo SIM)

 Selección de función de pines (MUX en PORT)
 Configuración de módulos 5
 HW y SW NVIC CORE
… P
P
B
CORTEX M0+ I/O Port
SysTick S.C.
core_cm0plus
(CMSIS)
AHB Lite

SRAM FLASH Peripheral Bridge

Advanced Peripheral Bus (APB)

UART
… GPIO PORT

fsl_uart.c … fsl_gpio.c fsl_port.c 6

 Desarrollo de la aplicación SW

Desarrollar software embebido es una tarea compleja

 Recursos limitados (silicio – energía)

 Ambientes hostiles
 Restricciones temporales, necesidad de robustez y fiabilidad
 Posibilidades limitadas de depuración

Se requieren herramientas para disminuir el tiempo, costo y

complejidad del desarrollo en todas las etapas de su ciclo de vida
7
 Desarrollo de la aplicación SW

 Expresan, clara y explícitamente, el

propósito y la funcionalidad del diseño.
MODELOS
 Constituyen una abstracción de mayor
nivel que el código fuente.

Permiten una documentación correcta del código

Aumentan la capacidad de prueba y mantenimiento

Disminuyen los tiempos para agregar o modificar funcionalidad

8
 Sistemas Reactivos

Un sistema reactivo interactúa continuamente con el

medio y su comportamiento está dirigido por eventos que
pueden ser tanto externos como internos.

 Los eventos pueden ser asincrónicos y requerir

respuesta rápida.
 La reacción del sistema depende de su estado
(contexto) y del tipo de evento que se presente.
 El conjunto de reacciones define el comportamiento
dinámico del sistema.
9
 Sistemas Reactivos

La gran mayoría de los sistemas embebidos son reactivos e

interactúan con el medio en base a sensores y actuadores

Su dinámica se representa usando un modelo de comportamiento

que especifica con claridad su evolución frente a eventos

 Funciones matemáticas
FORMALIZACIÓN  Redes de Petri
 Diagramas de Estados / Tablas de Estados
10
 Sistemas Reactivos: Formalización

Máquina de
SD1
Estado Finito
Redes de
Petri
Salidas/Acciones

Salidas/Acciones Salidas/Acciones

 Modelan el comportamiento del sistema

 Utilizan representaciones gráficas (diagramas) 11

 Sistemas Reactivos: Formalización
 Orientado a sistemas con recursos
Redes de compartidos y/o evoluciones paralelas.
Petri
 Implementación sistemática en código C.

 Formalismo sencillo que provee una

vista rápida y clara del sistema.

Máquina de  Permite reutilizar estrategias lo que

Estado Finito simplifica su implementación.

 Menor sistematicidad al codificar el

12
modelo.
 Autómata Finito

Sistema discreto que:

 Tiene un número finito de entradas E (símbolos de entrada).

 Tiene un número finito de salidas S (símbolos de salida).

 Los símbolos que recibe y emite evolucionan con el tiempo.

 El estado interno del sistema (colección de variables de

estado) es el resultado de la evolución del autómata a partir de
un estado inicial, luego de transcurrido un tiempo
determinado.
13
 MEF - Evolución

Las MEF tradicionales (Moore / Mealy) sufren un

crecimiento desmedido del número de estados y
transiciones cuando los sistemas son complejos.

StateCharts Extiende el lenguaje del Diagrama de

(Harel – 1987) Estados para manejar la complejidad

Agrega elementos a los StateCharts

UML
para incorporar Orientación Objetos
14
 StateCharts: Principales aportes

Contextos “pseudo-ortogonales”

 Cada contexto se enfoca en una parte del comportamiento del sistema.

 En la práctica los contextos no son completamente independientes.

 Las MEF de distintos contextos se comunican por eventos (variables).

Samek (Cap.2)- 2009

15
 StateCharts: Principales aportes

Estados compuestos o anidados

 En una MEF jerárquica un estado de un nivel superior contiene una sub-
MEF anidada. Puede haber varios niveles de anidamiento.
 Los superestados abordan el comportamiento común de sus subestados.
 Se establece una jerarquía de comportamiento (abstracción).
 Se reduce el número de estados (manejo de la complejidad).
Samek (Cap.2)- 2009

16
 MEF jerárquica: Transiciones

 `Transiciones específicas:

 Desde un subestado (T1).

 Hacia un subestado (T2).

 Transiciones generales:

 Desde un superestado (T3).

 Hacia un superestado (T4).

Schiefer -IBM

17
 MEF jerárquica: Transiciones con historia
Las acciones “simultáneas”
no deben ser conflictivas

Seshia, Berkeley - 2015

Una transición con historia implica que al abandonar el

superestado, se hace necesario recordar a que subestado se debe
volver. 18
 MEF jerárquica : Transiciones con Reset
Seshia, Berkeley - 2015

Las acciones “simultáneas”

no deben ser conflictivas

Una transición con reset implica que al abandonar el superestado,

se puede olvidar a que subestado se debe volver.
19
 StateCharts: Principales aportes

MEF Jerárquicas:

 Toda MEF jerárquica se puede llevar a una MEF plana. El

costo a pagar es que la complejidad de la representación se
incrementa.

 Las MEF jerárquicas permiten compactar la representación

del comportamiento de un sistema complejo

 Si se utilizan estas MEF, recordar que las acciones

“simultáneas” no deben tener conflictos entre ellas.

20
 MEF - Diagramas de Estado - UML

Conjunto de estados por los que pasa una aplicación como reacción a
la presencia de distintos eventos, junto con sus respuestas y acciones.

Ocurrencias externas o internas que pueden

EVENTOS:
causar la transición de un estado a otro

 Condición booleana que toma el valor verdadero.

 Llegada de una señal.

 Temporización.
21
 MEF - Diagramas de Estado - UML
Estados:

Un estado identifica una condición o una situación en la vida

de un sistema. El sistema permanece en un estado durante un
tiempo finito durante el cual se ejecuta alguna actividad o se
espera que suceda algún evento.
Otero-2012
Nombre
Atributos

Acciones, actividades y
transiciones internas
22
 MEF - Diagramas de Estado - UML
Operaciones atómicas que no pueden ser
ACCIONES: interrumpidas por eventos ya que se ejecutan
en forma instantánea (en HW salidas)

 Llamada a una operación.

 Envío de una señal.

Tareas asociadas con los estados,

ACTIVIDADES:
duraderas e interrumpibles.

 Enviando un mensaje.
 Esperando un evento
 Realizando un cálculo. 23
 MEF - Diagramas de Estado - UML
Acciones, actividades y
transiciones internas
Sintaxis formal:
nombre-evento ‘(’lista-argumentos‘)’ ‘[’guard-condition‘]’ ‘/’ expresión-acción
Acciones especiales:
 entry ‘/’ expresión-acción Utilizan palabras clave reservadas y
 exit ‘/’ expresión-acción los argumentos están implícitos

Actividades:
Se ejecutan mientras se está en el
 do ‘/’ expresión-acción
estado (calculando, esperando,…)
Transiciones internas:
Evento que no causa cambio
 help / display help 24
de estado
 MEF - Diagramas de Estado - UML

Transiciones

Sintaxis formal:
nombre-evento ‘(’lista-argumentos‘)’ ‘[’guard-condition‘]’ ‘/’ expresión-acción

Evento que da lugar Condición Se ejecuta al

a la transición necesaria para que dispararse la
ocurra la transición transición

Puede haber más de una expresión-acción en una transición

separadas por el carácter ‘/’
25
 Diagramas de Estado (ascensor) - MEF

Otero-2012

El ascensor inicia en primer piso, puede subir o bajar. Si está detenido

en un piso se lanza un temporizador. Al cumplirse el tiempo límite el
ascensor baja al primer piso. No tiene estado final. 26
 Objetivos

ESPECIFICAR EL COMPORTAMIENTO DINÁMICO DEL SISTEMA

 Dividir el comportamiento general en secciones para facilitar

el análisis y promover el reuso, manteniendo la estructura y
relación entre las partes.

 Implementar en código C el comportamiento, conservando la

coherencia con la formalización realizada.

 Facilitar la mantención del código

27
 Pautas generales

 El comportamiento completo del sistema se puede dividir en

varias MEF que interactúan entre sí:
 Pueden trabajar en distintos contextos (enfoque “plano”).
 Pueden representar una jerarquía de tareas.
 Pueden presentarse ambas situaciones.

Schiefer -IBM

28
 Pautas generales

 Las MEFs se comunican entre ellas para intercambiar

información relevante al comportamiento que implementan
(mensajes – variables).
 Al implementar se debe decidir dónde ubicar el código
correspondiente a cada MEF.
 El comportamiento relativo a las IRQs debe ubicarse en los
handlers asociados, recordando que el mecanismo de ejecución
está soportado por NVIC. Los eventos que disparan el
comportamiento asociado son la llegada asincrónica de IRQs
 Si se utilizan MEF jerárquicas, serán los superestados los que
llamarán a las subMEFs anidadas. 29
 Pautas generales

Comunicación entre MEFs

 Se utilizan variables para registrar los eventos que conectan

las distintas MEFs.
 Las variables deben ser leídas y la MEF que las utiliza las
limpia para habilitar un nuevo evento de interés.

Cada MEF guarda el estado en que se encuentra en

una variable. Esta variable, debe ser modificada solo
por la MEF con la que esta asociada 30
 MEF – Codificación C

La MEF se codifica en C utilizando

la sentencia switch - case
31
 MEF – Codificación C

SWITCH CASE anidado es muy utilizado para la implementación de MEFs.

Incluye una variable “estado” como discriminador del 1ºnivel de SWITCH.

 Es simple y sólo incluye una variable escalar por MEF.

 Requiere enumerar estados y disparadores.
 El tiempo de atención de los eventos no es constante y
depende del desempeño de los dos niveles del SWITCH, que
se degrada con la cantidad de casos a cubrir.
 Los elementos de cada MEF son específicos al
comportamiento que implementan. Es importante aislar
funcionalidad que se repite en distintas aplicaciones !!
32
 Resolución problema ejemplo

El planteo consiste en utilizar el pulsador SW1 y el LED

rojo disponibles en la placa. Al energizar la placa el LED
debe estar apagado. Si se pulsa SW1 se debe cambiar el
estado del LED, si estaba apagado, encenderlo, y si
estaba encendido, apagarlo.

 Identificar las tareas a abordar

 Modelar las tareas utilizando MEF
 Codificar en C
33
Solución – Consideraciones de Hardware

34
 Solución – División en subproblemas

 Detección de pulsada: La detección de “pulsada” es muy

frecuente en un sistema embebido y consiste en detectar el
instante en que un pulsador pasa de estar sin pulsar a
pulsado. Esta detección debe independizar al resto del
problema de tener en cuenta los rebotes y la forma en que los
pulsadores están conectados con el microcontrolador.

 Manejo del LED: El manejo del LED es propio del problema

planteado, es decir, su comportamiento debe responder a la
consigna del problema.

La implementación incluirá dos MEF.

35
Solución – Detección de Pulsada
La variable eventSW actúa
como nexo entre esta MEF
que detecta el pulsado y la
que actúa sobre el led.

Tendremos dos MEF

“planas” que trabajan en
contextos pseudoortogonales.

Se recurre a una función propia de

la placa para recuperar el estado de
36
uno de sus componentes (SW).
 Solución – Detección de Pulsada
void key_periodicTask1ms(void)
{
switch (estSW)
{
case ESPERANDO_ACTIVACION:
if (board_getSw(BOARD_SW_ID_1))
{
eventSW = 1;
estSW = ESPERANDO_DESACTIVACION;
}
break;

case ESPERANDO_DESACTIVACION:
if (!board_getSw(BOARD_SW_ID_1))
{
estSW = ESPERANDO_ACTIVACION;
} En forma periódica, se
break;
evalúa el estado del
default: switch y se notifica con la
estSW = ESPERANDO_ACTIVACION;
break; variable eventSW
}
} 37
 Solución – Control Led bool key_getPressEv(void)
{
bool ret;

MEF encargada de manejar el led ret = eventSW;

eventSW = 0;

return ret;
Implementa el }
comportamiento
solicitado

Se recupera el valor de
Devuelve la variable y se la
eventSW limpia para poder
detectar otro pulsado

38
 Solución – Control Led
El modificador STATIC, en este contexto,
produce una única inicialización de la
variable al inicio y encapsula el estado, que
sólo será modificado por la propia MEF
void mefLed(void)
{
static estMefLed_enum estMefLed = EST_MEF_LED_INICIALIZACION;

switch (estMefLed)
{
case EST_MEF_LED_INICIALIZACION:
board_setLed(BOARD_LED_ID_ROJO, BOARD_LED_MSG_OFF);
estMefLed = EST_MEF_LED_ESPERANDO_EV;
break;

case EST_MEF_LED_ESPERANDO_EV:
if (key_getPressEv())
board_setLed(BOARD_LED_ID_ROJO, BOARD_LED_MSG_TOGGLE);
break;
}
} 39
Solución – Función main e IRQ
int main(void)
{
// Se inicializan funciones de la placa
board_init();

// Inicializa keyboard
key_init();

// Se inicializa el timer PIT

PIT_Init();

while(1)
{
mefLed(); La MEF que se ocupa del manejo de los
} LEDs, se invoca en el bucle infinito.
}

void PIT_IRQHandler(void)
{
PIT_HAL_ClearIntFlag(PIT, 1);
La MEF que detecta el pulsado del
key_periodicTask1ms();
}
SW se ubica en el handler del PIT
40
 Solución – Esquema general
MEF detección pulsada
event SW
comunica las MEF
 Tarea periódica (handler PIT)
 Utiliza función de board para
detectar estado SW
MEF manejo Led
 Propio del problema, se
ubica en el bucle infinito
 Utiliza una función que
recupera el evento de
pulsada y limpia la variable
41
¿Preguntas?