Arquitecturas de Software para Sistemas Embebidos

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

2
Objetivos

• Definir arquitectura de software
• Conocer los principales tipos de arquitecturas
• Aprender a diseñar usando los principales tipos
  de arquitecturas de sistemas embebidos

3
Contenidos

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

4
Patrones 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...

5
Patrones 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

6
Patró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
7
Modelo 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
8
Contexto 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
9
Fuerzas

• 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
10
Solució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
11
Representaciones gráficas de los estratos

• Pila (stack)

Cebolla (onion)
Nivel N
4
3
Nivel j
2
1
Nivel 2
Nivel 1
Hardware
Estratos
12
Estructura

• 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
13
Diná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
14
Diná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
15
Diná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
16
Proceso 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
17
Proceso 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
18
Ejemplo resuelto
FTP
FTP
Protocolo FTP
TCP
TCP
Protocolo TCP
IP
IP
Protocolo IP
Ethernet
Ethernet
Protocolo Ethernet
Conexión física
Estratos
19
Variantes

• 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
20
Usos 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
21
Windows NT Estratos relajados
Estratos
22
Sistema embebido típico
Application
Services
Higher level services
Drivers
Device drivers (low-level)
OSAL
Operating system abstraction layer
RTOS
Real-time operating system
Estratos
23
Arquitectura 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
24
Patró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
25
Estructura 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
26
Contexto 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
27
Fuerzas

• 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
28
Solució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
29
Estructura

• 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

• Colaboradores
• Tubo

• Responsabilidad
• Obtener datos de entrada
• Ejecutar una función con sus datos
• Entregar datos de salida

Tubos y filtros
30
Estructura (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
31
Estructura (cont.)

• La fuente de datos es la entrada del sistema.
• El pozo de datos es la salida del sistema.

Clase Fuente de datos

• Colaboradores
• Tubo

Clase Pozo de datos

• Colaboradores
• Tubo

• Responsabilidad
• Entregar datos a la tubería de procesamiento

• Responsabilidad
• Consumir la salida

Tubos y filtros
32
Diná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
33
Dinámica - Escenario 2

• El pozo de datos tira

Filtro1 tira
Fuente de datos
Filtro2 tira
Pozo de datos tira
DATOS
DATOS
DATOS
Tubos y filtros
34
Diná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
35
Diná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
36
Proceso 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
37
Ejemplo 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
38
Variante

• 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
39
Usos 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
40
Ventajas

• 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
41
Desventajas

• 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
42
Patró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
43
Contexto 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
44
Solució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
45
Estructura

• 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
46
Usos 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
47
Patró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
48
Contexto 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
49
Fuerzas

• 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
50
Solució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
51
Estructura

• 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
52
Dinámica

• Ejemplo con cuatro tareas a distintas frecuencias

Ejecutivo cíclico
53
Proceso 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

54
Ejemplo 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
55
Ventajas 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
56
Patró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
57
Contexto 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
58
Fuerzas

• 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
59
Solució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
60
Estructura

• 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
61
Estructura (cont.)
Clase ISR

• Colaboradores
• Ciclo de eventos

• Responsabilidad
• Indicar que hubo un evento externo

Ciclo de eventos
62
Diná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
63
Diná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
64
Proceso 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
65
Implementació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
66
Variantes

• 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
67
Usos 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
68
Ventajas 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
69
Patró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
70
Contexto 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
71
Fuerzas

• 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
72
Solució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
73
Estructura

• 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
74
Estructuras 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
75
Diná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
76
Implementació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
77
Proceso 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

78
Ejemplo 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
79
Lenguaje 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
80
Variantes

• 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
81
Usos 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
82
Referencias

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