Title: Arquitecturas de Software para Sistemas Embebidos
1Arquitecturas de Software para Sistemas Embebidos
- Pontificia Universidad Católica de Chile
- Departamento de Ciencia de la Computación
- IIC3552 Sistemas Embebidos de Tiempo Real
- Gerardo León Pablo Straub
2Objetivos
- Definir arquitectura de software
- Conocer los principales tipos de arquitecturas
- Aprender a diseñar usando los principales tipos
de arquitecturas de sistemas embebidos
3Contenidos
- En esta clase y la siguiente veremos
- Concepto de arquitectura de software
- Patrones de arquitecturas de software
- Estratos (layers)
- Tubos y filtros (pipes and filters)
- Micronúcleo (microkernel)
- Ejecutivo cíclico (cyclic executive)
- Ciclo de eventos (event loop)
- Máquinas de estados (state machines)
4Patrones de arquitectura de software
- Estratos (layers)
- Tubos y filtros (pipes and filters)
- Micronúcleo (microkernel)
- Pizarrón (blackboard)
- Modelo-vista-controlador (model-view-controller)
- Presentación-abstracción-control
(presentation-abstraction-control) - Reflexión (reflection)
- Otros patrones...
5Patrones de diseño
- Los patrones de diseño representan clases de
diseños reutilizables - Describimos un patrón con un formato de patrón
- Nombre
- Ejemplo
- Contexto
- Problema
- Fuerzas
- Solución
- Estructura
- Dinámica
- Proceso de diseño
- Ejemplo resuelto
- Variantes
- Ejemplos de usos conocidos
6Patrón Estratos (layers)
- El patrón de arquitectura Estratos sirve para
estructurar aplicaciones que se pueden
descom-poner en partes a distintos niveles de
abstracción - EJEMPLO Protocolos de comunicación, en donde
hay varios niveles de comunicación, partiendo
desde el hardware pasando por la comunicación
punto a punto y llegando a los protocolos de
aplicaciones.
Estratos
7Modelo OSI de 7 estratos
Aplicación
Nivel 7 Protocolos varios para tareas comunes
Presentación
Nivel 6 Estructura y da semántica a la
información
Sesión
Nivel 5 Control y sincronización de diálogos
Transporte
Nivel 4 Manda paquetes garantizados
Red
Nivel 3 Selecciona una ruta
Enlace de datos
Nivel 2 Detecta y corrige errores en mensajes
Físico
Nivel 1 Transmite bits al computador vecino
8Contexto y problema
- CONTEXTO Descomponer un gran sistema
- PROBLEMA En un gran sistema la información se
maneja a distintos niveles de abstracción - Niveles desde algo muy cercano a la máquina hasta
algo de muy alto nivel - Se quiere que los servicios de un nivel se puedan
usar en otros sistemas
Estratos
9Fuerzas
- Cambios no deben afectar a todo el sistema
- Las interfaces deben ser estables (estándares)
- Debe ser posible intercambiar partes
- Los estratos de bajo nivel pueden servir en otros
sistemas futuros - No es fácil determinar la granularidad
- Componentes complejas deben subdividirse
- Cruzar fronteras puede afectar el rendimiento
- Hay que definir fronteras para dividir el trabajo
Estratos
10Solución
- Estructurar el sistema en un conjunto de estratos
uno sobre otro - El estrato j da servicios al nivel j1 y recibe
servicios del nivel j-1 - Todas las componentes de un estrato están al
mismo nivel de abstracción - Cada nivel tiene varias componentes y tiene su
propia arquitectura del nivel - El estrato cero es el hardware
Estratos
11Representaciones gráficas de los estratos
Cebolla (onion)
Nivel N
4
3
Nivel j
2
1
Nivel 2
Nivel 1
Hardware
Estratos
12Estructura
- La estructura es simple, porque hay sólo una
clase de componentes el estrato.
Clase Estrato j
- Colaboradores
- Estrato j-1
- Responsabilidad
- Dar servicios al estrato j1
- Delega tareas en el estrato j-1
Estratos
13Dinámica
- Escenario 1
- Un cliente pide un servicio al estrato N
- El estrato no puede hacerlo solo, así que pide
servicios al nivel N-1, llegando eventualmente al
nivel 1 - En el nivel 1 se hace el servicio y se van
devolviendo e integrando los resultados en los
niveles 2, 3 ... N - Escenario 2
- Una cadena de acciones parte en el nivel 1 que
recibe un estímulo externo y se pasa mediante
notificación a los niveles 2, 3 ... N - Cada nivel recibe una notificación y manda una
notificación al nivel superior
Estratos
14Dinámica
- Escenario 3
- Un cliente pide un servicio al estrato N
- El estrato no puede hacerlo solo, así que pide
servicios al nivel N-1, pero antes de llegar al
nivel 1 hay un nivel j que puede resolverlo - En el nivel j se hace el servicio y se van
devolviendo e integrando los resultados en los
niveles j1 ... N - Escenario 4
- Una cadena de acciones parte en el nivel 1 que
recibe un estímulo externo y se pasa mediante
notificación a los niveles 2, 3 ... j lt N - El nivel j determina que el mensaje no es
relevante
Estratos
15Dinámica
- Escenario 5
- Aquí hay dos pilas con los mismos estratos que se
comunica - Si bien la comunicación real sólo ocurre en el
estrato 1, se da la ilusión de comunicación entre
estratos correspondientes
Estratos
16Proceso de diseño
- Definir el criterio de abstracción (ej.,
distancia del hardware, complejidad conceptual) - Fichas del ajedrez
- Jugadas básicas
- Tácticas
- Estrategias
- Determinar cantidad de estratos
- Nombrar los estratos y asignarles funciones
- Especificar los servicios de cada estrato
- Si es necesario refinar más, vaya al paso 1
Estratos
17Proceso de diseño
- Especificar la interfaz de cada estrato
- Estructurar cada uno de los estratos
- Especificar comunicación entre estratos
adyacentes - Desacoplar estratos adyacentes
- hay varios patrones de diseño que ayudan a
hacerlo - tener interfaces dinámicas
- usar call-backs
- Diseñar una estrategia de manejo de errores
Estratos
18Ejemplo resuelto
FTP
FTP
Protocolo FTP
TCP
TCP
Protocolo TCP
IP
IP
Protocolo IP
Ethernet
Ethernet
Protocolo Ethernet
Conexión física
Estratos
19Variantes
- Sistema estratificado relajado
- La relación entre estratos no es tan estricta
- Cada estrato puede usar los estratos de más
abajo, no sólo el estrato inmediatamente inferior - Algunos estratos pueden ser parcialmente opacos,
otros totalmente opacos - Se gana flexibilidad y rendimiento
- Se pierde mantenibilidad (un precio caro)
Estratos
20Usos conocidos
- Máquinas virtuales
- APIs (application programming interfaces)
- Varias arquitecturas de sistemas de información
- Tradicionales, cliente servidor de 2 ó 3 capas,
distribuidos y orientados a objeto, y basados en
Web - Sistemas operativos
- Sistemas de comunicaciones
- Sistemas embebidos en general
Estratos
21Windows NT Estratos relajados
Estratos
22Sistema embebido típico
Application
Services
Higher level services
Drivers
Device drivers (low-level)
OSAL
Operating system abstraction layer
RTOS
Real-time operating system
Estratos
23Arquitectura de TVControl
Application
Action Routines
Automatic Routines
Command Interpreter
State Machine
Screens
Texts
Scheduler
Device Drivers
OSD
Control Panel
Closed caption
Time Base
Remote Control
I2C
Fonts
TV Set Hardware
Estratos
24Patrón Tubos y filtros (pipes and filters)
- El patrón de arquitectura Tubos y filtros sirve
para estructurar sistemas que procesan flujos de
datos - Cada paso del proceso se encapsula en un filtro
- Los datos se pasan a través de tubos entre
filtros adyacentes - Los filtros se pueden usar en varios sistemas
- EJEMPLO
- Un compilador portátil, con un lenguaje
intermedio que se ejecuta en una máquina virtual
o mediante un traductor backend
Tubos y filtros
25Estructura del compilador
Programa en ASCII
Análisis léxico
Flujo de tokens
Análisis sintáctico
Árbol sintáctico abstracto
Análisis semántico
Árbol sintáctico abstracto aumentado
Generación de código intermedio
Código intermedio
Optimización
Código intermedio
Backend INTEL
Backend Alfa
Intérprete
Tubos y filtros
26Contexto y Problema
- CONTEXTO Procesamiento de flujos de datos
- PROBLEMA Se debe hacer un sistema que procesa
flujos (streams) de datos - Se quiere implementar en partes
- hay varios desarrolladores
- la tarea global se descompone naturalmente en
subtareas - los requisitos probablemente van a cambiar.
- Mediante el intercambio de filtros se obtiene
flexibilidad y se puede hacer una familia de
sistemas relacionados
Tubos y filtros
27Fuerzas
- Mejoras futuras se deben hacer mediante cambios o
nuevas combinaciones de pasos de proceso - Pasos de procesamiento pequeños son más fáciles
de reutilizar - Pasos no adyacentes no comparten información
- Hay varias entradas (red, sensores, archivos)
- Debe ser posible almacenar y/o presentar
resultados - El almacenamiento de resultados parciales en
archivos conduce a errores, si lo hacen los
usuarios - A veces conviene procesar los pasos en paralelo
Tubos y filtros
28Solución
- El patrón de arquitectura Tubos y filtros divide
la tarea de un sistema en sub-tareas en serie - Sub-tareas conectadas por un flujo de datos
- La salida de una subtarea es la entrada de la
siguiente - Los pasos de procesamiento corresponden a las
componentes de tipo filtro - La entrada proviene de una fuente de datos
- La salida se va a un pozo de datos
- Las componentes de arriba se conectan con tuberías
Tubos y filtros
29Estructura
- Los filtros son las compo-nentes de procesamiento
- Tipos de procesamiento
- enriquecer los datos
- refinar/concentrar los datos
- transformar los datos
- Opciones de control
- datos son tirados (pulled) por tubo de salida
- datos son empujados (pushed) por tubo de entrada
- el filtro está activo en una iteración de
lectura, proceso y escritura
Clase Filtro
- Responsabilidad
- Obtener datos de entrada
- Ejecutar una función con sus datos
- Entregar datos de salida
Tubos y filtros
30Estructura (cont.)
- Los tubos son las compo-nentes de conexión
- Su función es sincronizar el flujo de datos.
- Si alguno de los filtros adyacentes es pasivo, el
tubo se puede implementar como un llamado. Esto
dificulta el reuso de los filtros.
Clase Tubo
- Colaboradores
- Fuente de datos
- Pozo de datos
- Filtro
- Responsabilidad
- Transferir datos
- Sincronizar componentes vecinos
Tubos y filtros
31Estructura (cont.)
- La fuente de datos es la entrada del sistema.
- El pozo de datos es la salida del sistema.
Clase Fuente de datos
Clase Pozo de datos
- Responsabilidad
- Entregar datos a la tubería de procesamiento
- Responsabilidad
- Consumir la salida
Tubos y filtros
32Dinámica - Escenario 1
- La fuente de datos empuja
Filtro1 empuja/envía
Fuente de datos empuja/envía
Filtro2 empuja/envía
Pozo de datos
DATOS
DATOS
DATOS
Tubos y filtros
33Dinámica - Escenario 2
Filtro1 tira
Fuente de datos
Filtro2 tira
Pozo de datos tira
DATOS
DATOS
DATOS
Tubos y filtros
34Dinámica - Escenario 3
- El segundo filtro tira y empuja
Filtro1 tira
Fuente de datos
Filtro2 tira/empuja
Pozo de datos
DATOS
DATOS
DATOS
Tubos y filtros
35Dinámica - Escenario 4
- Los dos filtros tiran y empujan (tipo Unix)
Filtro1 tira/empuja
Fuente de datos
Filtro2 tira/empuja
Pozo de datos
Tubo con un buffer
DATOS
DATOS
DATOS
DATOS
DATOS
DATOS
DATOS
DATOS
Tubos y filtros
36Proceso de diseño
- Dividir el sistema en una secuencia de pasos de
procesamiento - Definir el formato de los datos a pasar en cada
etapa - Decidir cómo implementar cada conexión
- Esto determina si los filtros son activos o
pasivos - Diseñar e implementar los filtros
- Diseñar el manejo de errores
- Establecer la tubería
Tubos y filtros
37Ejemplo resuelto
- Varios programas conectados por tubos de Unix
- 1 Front end, con las primeras cuatro etapas,
que comparten la tabla de símbolos - Análisis léxico (tira)
- Análisis sintáctico (tira/empuja)
- Análisis semántico (empuja)
- Generación de código (empuja)
- 2 Optimizador
- 3 Intérprete
- 4 Generador de código (hay varios de éstos)
Tubos y filtros
38Variante
- Una variante son las tuberías con tés (varias
salidas) y con uniones (varias entradas) - Esta variante es común en los sistemas embebidos
Tubos y filtros
39Usos conocidos
- En Unix los tubos y filtros son parte de la
manera de vivir - La comunicación entre procesos se puede hacer a
través de tubos con nombre (named pipes) - Hay software educativo basado en este paradigma,
en donde los niños construyen inventos y
experimentos basados en muchas componentes
simuladas que se conectan en forma gráfica
Tubos y filtros
40Ventajas
- No es necesario tener archivos intermedios
- Flexibilidad mediante cambio de filtros
- Reuso de filtros y de tuberías completas
- Prototipos rápidos basados en filtros existentes
(filtros genéricos como awk y sed) - Procesamiento paralelo eficiente
Tubos y filtros
41Desventajas
- Compartir información es caro o inflexible
- El costo (overhead) del paralelismo puede ser muy
grande - Hay costo de transformación de datos
- Usualmente se usa un formato de datos tipo
mínimo común denominador (ej., ASCII) - Esto implica conversiones para datos más
complejos - Es difícil implementar un manejo de excepciones
adecuado
Tubos y filtros
42Patrón Micronúcleo (microkernel)
- El patrón de arquitectura Micronúcleo sirve para
sistemas que deben ser adaptables a requisitos
cambiantes. - Separa la funcionalidad mínima de la
funcionalidad extendida y propia de un cliente - Sirve de enchufe para estas extensiones y
coordina sus colaboraciones - EJEMPLO Queremos un sistema operativo que se
pueda portar a otro hardware, y que ejecute
programas escritos para sistemas operativos
populares existentes (Unix, Windows)
Micronúcleo
43Contexto y Problema
- CONTEXTO El desarrollo de varias aplicaciones
con interfaces de programación parecidas y
basadas en el mismo núcleo funcional. - PROBLEMA Una plataforma de aplicaciones debe
existir por muchos años y por ende sobre distinto
hardware y software. - La plataforma debe ser portátil, extensible y
adaptable, para poder integrar nuevas tecnologías.
Micronúcleo
44Solución
- Encapsular los servicios fundamentales de la
plataforma en una componente micronúcleo - Uno de esos servicios es comunicación entre las
demás componentes (ej., IPC) - Los servicios fundamentales que son grandes se
ponen en servidores internos - Los servidores externos implementan su propia
visión del micronúcleo, en un proceso separado
que representa otra plataforma - Los clientes se comunican con los servidores
externos a través del servicio del micronúcleo
Micronúcleo
45Estructura
- Hay 5 tipos de componentes
- El micro-núcleo, que provee la funcionalidad
básica, comunicación y gestión de recursos - Los servidores internos, extensiones del
micro-núcleo (usualmente gestionan recursos, son
drivers) - Los servidores externos, que implementan (emulan)
plataformas - Los clientes, que ejecutan sobre un servidor
externo - Los adaptadores, que se compilan en conjunto con
el cliente (stubs) para que un cliente de una
plataforma emulada compile sin modificación
Micronúcleo
46Usos conocidos
- El sistema operativo Mach, creado en 1986 y que
formó la base de NeXTStep y de OSF/1 - Mach tiene a Unix BSD como un servidor
externo, y ejecuta más rápido que versiones
monolíticas de BSD - El sistema operativo Ameoba, con muchos servicios
internos para reducir el tamaño del micro-núcleo - Windows NT, tiene 3 servidores externos Win32,
OS/2 1.x, POSIX (estándar de Unix) - MKDE es un SABD basado en micro-núcleo
Micronúcleo
47Patrón Ejecutivo cíclico (Cyclic executive)
- El patrón Ejecutivo cíclico permite estructurar
sistemas embebidos de tiempo real crítico, sin
sistema operativo y con un único proceso - El sistema consta de un programa principal que
inicializa y luego entra en un ciclo infinito, en
donde realiza tareas repetitivas fijas - Nombre alternativo Línea de tiempo (Timeline)
- EJEMPLO Software de un computador de control de
vuelo, que procesa la información de plan de
vuelo, instrumentos, estado y entrega comandos al
avión e información a los tripulantes.
Ejecutivo cíclico
48Contexto y Problema
- CONTEXTO Un sistema embebido de tiempo real
estricto debe realizar varias tareas en una
secuencia fija. - PROBLEMA En sistemas de tiempo real estricto se
desea predecibilidad en los tiempos en que se
ejecutan las tareas. - Se prefiere tener una secuencia fija repetitiva
para garantizar los tiempos de respuesta - Se desea separar los distintos tipos de tareas
- Tiempos de procesamiento son acotados
Ejecutivo cíclico
49Fuerzas
- Cada tarea tiene un procesamiento fijo que debe
realizarse repetidas veces - Algunas tareas tienen tiempos de ciclo muy
pequeños en relación a otras tareas - Es posible programar las tareas en forma
prefijada - Debe garantizarse que el procesamiento se
completa hasta antes del próximo ciclo
Ejecutivo cíclico
50Solución
- Se determina el tiempo mínimo de ciclo
- Se organizan los demás tiempos de ciclo como
múltiplos de este tiempo de ciclo menor - Un timer dispara al ejecutivo por cada ciclo
menor - Una secuencia no repetitiva de ciclos menores es
un ciclo mayor - Las tareas se implementan como procedimientos y
se ponen en una list fija para cada ciclo menor - Cada ciclo menor invoca a todas los
procedimientos de la lista - Las tareas largas se subdividen en tareas
menores, con menor tiempo de ciclo
Ejecutivo cíclico
51Estructura
- Hay dos componentes el ejecutivo cíclico y el
procedimiento
Clase Ejecutivo cíclico
- Colaboradores
- Procedimiento
Clase Procedimiento
Colaboradores
- Responsabilidad
- Invocar a todos los procedimiento de cada ciclo
menor - Repetir
- Responsabilidad
- Ejecutar un ciclo de una tarea repetitiva
Ejecutivo cíclico
52Dinámica
- Ejemplo con cuatro tareas a distintas frecuencias
Ejecutivo cíclico
53Proceso de diseño
- Identificar todas las tareas repetitivas y sus
tiempos de ciclo - Identificar el ciclo menor ajustar tiempos
dentro de las restricciones de modo que los demás
periodos sean múltiplos de periodo menor - Diseñar los procedimientos de cada tarea acotar
sus tiempos de proceso - Asignar los procedimientos a cada ciclo menor
- Si el tiempo de proceso de un ciclo menor excede
el periodo menor, dividir en dos un procedimiento
lento y luego ir al paso 4
54Ejemplo resuelto Control de vuelo
- Tiempos típicos (la mayoría estrictos)
- 20 ms máximo para responder a cambios de actitud
- 1 s para cambios de estado de equipos
- Interfaz humana usable (ej., 100 ms para un
tecla) - Computador con 2 a 5 procesadores (1MB c/u)
- Un hilo de control por cada procesador
- Datos compartidos dentro de cada procesador
- Paso de mensajes entre procesadores dato por el
ejecutivo o el sistema operativo
Ejecutivo cíclico
55Ventajas y desventajas
- Ventajas
- Se pueden garantizar el cumplimiento de tiempos
mediante análisis previo - Desventajas
- Proceso de diseño tiene una repetición que no es
claro cómo terminar - Al haber cambios en tiempos de ciclo o agregar
tareas se repite un buena parte del proceso de
diseño
Ejecutivo cíclico
56Patrón Ciclo de eventos (event loop)
- El patrón Ciclo de eventos permite estructurar
sistemas embebidos, sin sistema operativo y
usualmente con un único proceso - El sistema consta de un programa principal que
inicializa y luego entra en una iteración
infinita, en donde procesa eventos - Los eventos son comunicados mediante preguntas
del microcontrolador (polling) y banderas de
eventos (event flags) - EJEMPLO Software de control de un TV
- TVControl tiene una arquitectura estratificada
con un programa principal basado en ciclo de
eventos
Ciclo de eventos
57Contexto y Problema
- CONTEXTO Dar estructura de control con múltiples
actividades sin usar un RTOS - PROBLEMA En sistemas embebidos pequeños se
necesita responder a varios eventos - El sistema responde a eventos externos e internos
- Se desea programar las respuestas a eventos en
forma de rutinas independientes del flujo de
control general del sistema - No se puede usar un RTOS por razones de memoria
Ciclo de eventos
58Fuerzas
- Se desea que las respuestas a eventos se
programen en forma separada - Hay eventos externos que se conocen por una
interrupción o vía condición a revisar (polling) - Hay eventos internos, posiblemente cíclicos, que
son controlados por una alarma de reloj (timer) - El tiempo de proceso de cada eventos es breve
- Restricciones de tiempo real son permisivas
- Futuras versiones del sistema pueden modificar la
lista de eventos
Ciclo de eventos
59Solución
- Se crea un programa principal que inicializa el
sistema y luego entra en el ciclo de eventos - Usualmente el ciclo es infinito, pero puede haber
algún evento de finalización - El ciclo de eventos revisa cada uno de los
posibles eventos si el evento ha ocurrido, llama
a la función que maneja ese tipo de eventos - Una rutina de servicio de interrupción (ISR)
levanta una bandera de eventos para su servicio
desde el ciclo de eventos
Ciclo de eventos
60Estructura
- Hay tres componentes principales ciclo de
eventos, rutinas de acción, y rutinas de servicio
de interrupción
Clase Ciclo de eventos
- Colaboradores
- Rutinas de acción
Clase Rutina de acción
Colaboradores
- Responsabilidad
- Revisar las ocurrencias de eventos e invocar a
las rutinas de acción del caso - Repetir la revisión
- Responsabilidad
- Procesar un evento
Ciclo de eventos
61Estructura (cont.)
Clase ISR
- Colaboradores
- Ciclo de eventos
- Responsabilidad
- Indicar que hubo un evento externo
Ciclo de eventos
62Dinámica
- Escenario 1 proceso de una interrupción
- Una interrupción invoca a su ISR
- La ISR levanta una bandera de eventos
- El ciclo de eventos pregunta por la bandera, baja
la bandera, e invoca a la rutina de acción
correspondiente - Escenario 2 proceso de evento por polling
- El ciclo de eventos pregunta por un evento
externo (polling) - Si el evento ha ocurrido, se invoca a la rutina
de acción - Escenario 3 proceso de evento interno
- El ciclo de eventos pregunta si un timer activo
ha llegado a cero - Si esto ha ocurrido, se invoca a la rutina de
acción
Ciclo de eventos
63Dinámica (cont.)
- Escenario 4 no hay eventos
- El ciclo de eventos ha preguntado por todos los
eventos posibles - Ahora va nuevamente a preguntar, usando espera
ocupada (busy waiting)
Ciclo de eventos
64Proceso de diseño
- Identificar todos los eventos a los que debe
responder el sistema - Por cada evento, identificar si se dispara
mediante una interrupción, condición externa a
revisar (polling), o mediante una alarma de reloj
- Diseñar el ciclo de eventos, preguntando por cada
evento en secuencia - Diseñar una rutina de acción por cada evento
- Esta rutina de acción puede disparar otros
eventos mediante banderas de eventos o alarmas de
reloj - Diseñar un ISR simple por cada interrupción
Ciclo de eventos
65Implementación
- El programa principal inicializa el sistema y
luego entra en el ciclo de eventos (iteración
infinita) - El ciclo de eventos es básicamente una lista de
instrucciones if-then no anidadas - If (evento_x_ocurrió) then rutina_de_acción_x
- If (evento_y_ocurrió) then rutina_de_acción_y
- Al preguntar si un evento ocurrió debe usarse una
instrucción tipo test-and-set para evitar pérdida
de eventos - Cada rutina de acción es una función separada
- Por cada interrupción se hace una ISR que levanta
una bandera
Ciclo de eventos
66Variantes
- Las ISR sirven los eventos en la interrupción en
vez de usar banderas de eventos - Esto asegura un servicio inmediato de la
interrupción - Debemos asegurar que no perdemos interrupciones
- Puede haber un RTOS y múltiples procesos
- No debe hacerse espera ocupada
- Prioridades basadas en restricciones de tiempo
- Se necesita sincronización entre procesos
- Hay que evitar la inversión de prioridades
- Eventos aperiódicos deben acotar tiempo de proceso
Ciclo de eventos
67Usos conocidos
- Este patrón y sus variantes son usados en
sistemas embebidos de tiempo real no estricto,
que no usan sistema operativo - Para unos pocos eventos de tiempo real estricto
es posible usar la variante en que una ISR sirve
el evento - Para eventos repetitivos de tiempo real estricto
se recomienda el patrón Ejecutivo cíclico
Ciclo de eventos
68Ventajas y desventajas
- Ventajas
- Es simple agregar más eventos y tareas
- Es trivial cambiar periodos de eventos cíclicos
- Desventajas
- Es difícil garantizar tiempos de ejecución
acotados, debido a la ejecución flexible y por
ende impredecible de eventos - Si hubiera concurrencia (variante) es posible
tener inversión de prioridades
Ciclo de eventos
69Patrón Máquinas de estados
- Las Maquinas de estado se usan para representar
secuencias de eventos complejas, usualmente
relacionadas a interacciones con el usuario o con
sistemas externos. - Son parte de un sistema mayor, quizá con estratos
- EJEMPLO Interfaz con el usuario de un televisor
Máquinas de estados
70Contexto y Problema
- CONTEXTO Un sistema debe responder a secuencias
de eventos el mismo evento tiene distintos
significados dependiendo de los eventos
anteriores. - Ejemplo La tecla Power significa encender o
apagar el equipo dependiendo de la paridad del
número de veces que se ha presionado - PROBLEMA Es necesario registrar la historia
relevante de eventos anteriores para saber cómo
responder, para responder adecuadamente a cada
caso.
Máquinas de estados
71Fuerzas
- Las interacciones son complejas
- La historia relevante se codifica en estados
- Cada estado tiene sus propias respuestas frente a
un evento determinado - Algunos eventos cambian el estado
- El sistema debe tener determinadas reacciones
frente a determinadas secuencias de eventos - Debe ser fácil modificar el comportamiento del
sistema
Máquinas de estados
72Solución
- Codificar el comportamiento del sistema mediante
una máquina de estados - Codificar la máquina de estados en estructuras de
datos - Las posibles respuestas se codifican en rutinas
de acción - Hacer un intérprete que dado un estado actual y
un evento, invoque a la rutina de acción y
determine el próximo estado - El intérprete se ejecuta cada vez que hay un
evento de interacción
Máquinas de estados
73Estructura
- Hay dos tipos de componentes activas el
intérprete y las rutinas de acción
Clase Intérprete
- Colaboradores
- Rutinas de acción
Clase Rutina de acción
Colaboradores
- Responsabilidad
- Invocar a la rutina de acción correspondiente al
estado actual y al evento - Determinar el próximo estado, dado el estado
actual y el evento
- Responsabilidad
- Dar respuesta a un evento en un estado
determinado
Máquinas de estados
74Estructuras de datos
- Tabla de estados subíndices a la primera
transición de cada estado - Tabla de transiciones descripciones de todas las
transiciones de todos los estados
Tabla de Transiciones
Evento Acción Prox. estado
0 1 2
Tabla de Estados
0 1 2
3 4 5
6 7
Máquinas de estados
75Dinámica
- Escenario 1 evento válido en estado actual
- Al detectarse un evento se encuentra una
transición en el estado actual para el evento - Se invoca a la rutina de acción de la transición
- El estado actual es ahora el próximo estado
- Escenario 2 evento no valido en estado actual
- Al detectarse un evento no se encuentra una
transición en el estado actual para el evento - Se toma una acción por omisión ejemplos
- Tener un estado por omisión con todos los
eventos - Ignorar el evento
Máquinas de estados
76Implementación
- Para determinar la transición que debe
ejecutarse, se hace una búsqueda secuencial en la
tabla de transiciones - Se parte desde la primera transición del estado
- Se termina al encontrar el evento o al llegar a
las transiciones del estado siguiente - Si se ha encontrado el evento, se invoca a la
rutina de acción y se asigna el próximo estado - Si no se ha encontrado el evento, se toma una
acción predeterminada - Buscar en estado por omisión
- Ignorar el evento
Máquinas de estados
77Proceso de diseño
- Se enumeran todos los estados
- Por cada estado se identifican sus transiciones
de estado evento, respuesta, próximo estado - Las respuestas se asocian a rutinas de acción,
usualmente con parámetros - Se codifica la máquina
- Toda la información en la tabla de transiciones
- Se determina la tabla de estado mediante
subíndices a las tablas de transiciones - Lo anterior se hace en forma automática con
alguna herramienta ad-hoc
78Ejemplo resuelto
- Máquina de estados de TVControl es a su vez una
rutina de acción de un ciclo de eventos, que
procesa todos los eventos de interacción
Máquinas de estados
79Lenguaje de la máquina de estados
FUNCTIONS MENU STATE MODE_SETUP_STATE
MENU_EVENT SetMainMenu 0 4
FUNCTIONS_ITEM_STATE VOL_UP_EVENT
AvChannelMenu 0 0 MODE_SETUP_STATE
VOL_DOWN_EVENT AvChannelMenu 0 0
MODE_SETUP_STATE AV_EVENT AvChannelMenu
0 0 MODE_SETUP_STATE PRV_CH_EVENT
JumpPrevMenuCh 0 0 MODE_SETUP_STATE
CH_DOWN_EVENT SelectFuncItem 0 1
SYSTEM_SETUP_STATE CH_UP_EVENT
SelectFuncItem 0 0 EXIT_FUNCTIONS_MENU_STATE
END STATE
Máquinas de estados
80Variantes
- Máquinas de estados con varios estados por
omisión (otra columna de la tabla de estados) - Parámetros para rutinas de acción
- Codificación rectangular de estados
- Una matriz de eventos y estados
- Se ahorra la búsqueda secuencial a costa de
memoria - Siempre existe la transición
- Máquinas de estado recursivas
- Statecharts estados anidados, estados paralelos,
transiciones múltiples
Máquinas de estados
81Usos conocidos
- Casi todos los reconcedores de comandos,
incluyendo los compiladores, están basados en una
máquina de estados - Como la implementación puede ser muy chica se
puede usar en sistemas sencillos como
electrodomésticos o equipos de electrónica de
consumo
Máquinas de estados
82Referencias
- Los patrones Estratos, Tubos y filtros, y
Micronúcleo fueron adoptados de - F. Buschmann, R. Meunier, H. Rohnert, P.
Sommerlad M. Stal, Pattern-oriented Software
Architecture A System of Patterns, John Wiley
Sons, 1996. - Los patrones Ciclo de eventos, Máquina de
estados, Ejecutivo cíclico y Sistema de mensajes
no han sido publicados los dos últimos están
inspirados de - D. Locke M. Gerhardt, Real-Time Architectures
Parts 1 2, slides used in Embedded Systems
Conference, 2000.