Upload
others
View
0
Download
0
Embed Size (px)
Citation preview
BESA MICRO-EDITION, ARQUITECTURA DE SISTEMAS MULTIAGENTE PARA
MICROCONTROLADORES
T.G. 0505
DAVID MAGIN FLOREZ RUBIO
GUILLERMO ANDRES RODRÍGUEZ CANTOR
JUAN MANUEL ORTIZ GÓMEZ
PONTIFICIA UNIVERSIDAD JAVERIANA
FACULTAD DE INGENIERIA
CARRERA DE INGENIERIA ELECTRÓNICA
BOGOTÁ
2005
BESA MICRO-EDITION, ARQUITECTURA DE SISTEMAS MULTIAGENTE PARA
MICROCONTROLADORES
T.G. 0505
DAVID MAGIN FLOREZ RUBIO
GUILLERMO ANDRES RODRÍGUEZ CANTOR
JUAN MANUEL ORTIZ GÓMEZ
Informe Final
Director
ENRIQUE GONZALEZ
Ingeniero Eléctrico
PONTIFICIA UNIVERSIDAD JAVERIANA
FACULTAD DE INGENIERIA
CARRERA DE INGENIERIA ELECTRÓNICA
BOGOTÁ
2005
ii
TABLA DE CONTENIDO
INTRODUCCIÓN 1
1. OBJETIVOS 3
1.1. OBJETIVO GENERAL 3 1.2. OBJETIVOS ESPECÍFICOS 3
2. MARCO TEÓRICO 5
2.1. SISTEMAS MULTI-AGENTE 5 Aplicaciones 5
2.2. ARQUITECTURA BESA DE SISTEMAS MULTI-AGENTE 6 2.2.1. DEFINICIÓN DE AGENTE 6
Estructura de un Agente (Canal – Comportamiento – Estado) 7 Definición de Contenedor 8
2.2.2. REQUERIMIENTOS DE BESA 9 Necesidades de Sincronización 9 Necesidades de Concurrencia 10 Comunicación entre Agentes 10
2.3. SISTEMAS OPERATIVOS 11 2.3.1. SISTEMAS OPERATIVOS EN TIEMPO REAL 12 2.3.2. PLANIFICACIÓN 13 2.3.3. MECANISMOS DE SINCRONIZACIÓN 15
Semáforos 16 Mensajes 17
2.3.4. MANEJO DE MEMORIA 18
3. DESARROLLO 21
3.1. REQUERIMIENTOS DE BESA 21 3.2. SELECCIÓN DEL RTOS Y DE LA FAMILIA DE MICROCONTROLADORES 21 3.2.1. BÚSQUEDA Y SELECCIÓN DEL RTOS 21 3.2.2. SELECCIÓN DE LA FAMILIA DE MICROCONTROLADORES 24 3.2.3. APROPIACIÓN DEL RTOS 26
Gestión de Memoria 26 Pruebas Realizadas 26
3.3. CONSTRUCCIÓN DEL MODELO BESA-ME 27 3.3.1. DESCRIPCIÓN GENERAL 27 3.3.2. NIVEL AGENTE 28
Estructuras Asociadas a la Identificación del Agente 29 Construcción del Canal 30 Construcción del Comportamiento 32 El Estado 33 Simulación del envío de un Evento al Canal y ejecución de sus Comportamientos 34
3.3.3. NIVEL SISTEMA 34 Creación del Contenedor 35 El Administrador Local en BESA-ME 37 Envío de Eventos BESA desde Interrupciones 37 Comunicación entre Agentes 39
iii
3.4. PROTOCOLO DE COMUNICACIÓN EXTERNA 40 3.4.1. PROTOCOLO DE COMUNICACIÓN A NIVEL BYTE 40
Selección del Protocolo de Comunicación a Nivel Byte 40 Introducción al Funcionamiento del Protocolo I2C 41 Implementación del Protocolo de Comunicación a Nivel Byte 43
3.4.2. PROTOCOLO DE COMUNICACIÓN A NIVEL TRAMA 46 Trama Evento BESA 46 Trama Acknowledge BESA 47 Secuencia de Comunicación del Protocolo a Nivel Trama 48
4. PRUEBAS Y ANÁLISIS DE RESULTADOS 61
4.1. PROTOCOLO DE PRUEBAS 61 4.1.1. IDENTIFICACIÓN DE VARIABLES 61
Variables Independientes 61 Variables Intervinientes 63 Variables Dependientes 63
4.1.2. PRUEBAS A REALIZAR 64 Pruebas de Capacidad 64 Pruebas de Comunicación 64 Pruebas de Interrupciones 65
4.2. ANÁLISIS DE LOS RESULTADOS OBTENIDOS 65 4.2.1. PRUEBAS DE CAPACIDAD 65
Tamaño del Stack 66 Cantidad de Agentes por Contenedor 66 Cantidad de Comportamientos 68 Cantidad de Guardas 69 Cantidad de Puertos 69 Síntesis de Resultados Obtenidos 70
4.2.2. PRUEBAS DE COMUNICACIÓN 70 Envíos de Eventos por el Canal de Comunicación 71 Tiempos de Respuesta a Eventos 74 Tipos de Errores en la Comunicación Externa 77
4.2.3. PRUEBAS DE INTERRUPCIONES 81
5. CONCLUSIONES 87
6. BIBLIOGRAFIA 91
7. ANEXOS 93
ANEXO A. MANUAL DEL USUARIO. 93 ANEXO B. CODIGO DE PROGRAMACION. 94
iv
INDICE DE FIGURAS
Figura 1. Arquitectura interna de un agente. Tomado del artículo BESA.5 7 Figura 2. Modelo del nivel de sistema BESA. Tomado de BESA.5 9 Figura 3. Modelo de Agente en BESA-ME 29 Figura 4. Estructuras asociadas al Agente 29 Figura 5. Estructura asociada al canal. 30 Figura 6. Estructura asociada a los Puerto y a las Guardas. 31 Figura 7. Estructura del Mensaje recibido por el Comportamiento. 31 Figura 8. Estructura asociada al Comportamiento. 33 Figura 9. Nivel Sistema en BESA-ME con el servicio de comunicación entre contenedores. El
administrador local se encarga del manejo de los eventos. 35 Figura 10. Estructura asociada Contenedor. 36 Figura 11. Estructura de los buffer de Transmisión y de Recepción para la comunicación entre
contenedores. 36 Figura 12. BESA_DATA, Estructura en la que almacenan los datos de usuario. 37 Figura 13. BESA_EVENT, Estructura en la que se almacena el tipo de evento y el
BESA_DATA. 37 Figura 14. ISR_BESA_EVENT, Estructura en la que se almacena un BESA_EVENT cuando
quiere ser enviado desde una rutina de interrupción. 38 Figura 15. Diagrama de bloques del tratamiento de eventos desde una rutina de
interrupción. 38 Figura 16. Formato de tramas utilizadas para la comunicación entre Contenedores. 46 Figura 17. Tipos de respuesta acknowledge en BESA-ME. Ejemplo del envío de un agente X a
un agente Z ubicados en distintos contenedores. 49 Figura 18. Señales START, no Acknowledge Hardware y STOP. 54 Figura 19. Señales presentes durante la comunicación exitosa desde un contenedor hacia otro
contenedor. Tamaño máximo de Datos igual a 6. DataSize igual a 8. 55 Figura 20. Envío y recepción de eventos al bus I2C por medio de interrupciones. 56 Figura 21. Diagrama de flujo de la comunicación entre agentes en BESA-ME. 60 Figura 22. Envíos exitoso para diferentes frecuencias de envío y tamaño de cola igual a
uno. 73 Figura 23. Envíos exitoso para diferentes frecuencias de envío y tamaño de cola igual a
dos. 73 Figura 24. Envíos exitoso para diferentes frecuencias de envío y tamaño de cola igual a
tres. 74 Figura 25. Tiempos de atención a eventos periódicos de envíos externos, desde los
comportamientos. 75
v
Figura 26. Tiempos de atención a eventos periódicos de envíos locales, desde los comportamientos. 76
Figura 27. Envíos exitosos vs periodo de envío, para dos agentes ubicados en distintos contenedores. Cada punto representa un grupo de 100 envíos 77
Figura 28. Porcentaje de causas de error para un xDelayTime de 2ms. 78 Figura 29. Porcentaje de causas de error para un xDelayTime de 11ms. 78 Figura 30. Porcentaje de causas de error para un xDelayTime de 14ms. 78 Figura 31. Porcentaje de causas de error para un xDelayTime de 20ms. 79 Figura 32. Envíos exitosos vs periodo de envío, para 2 agentes productores y un
consumidor. 80 Figura 33. Porcentaje de Causas de error para un xDelayTime de 3 ms. 80 Figura 34. Porcentaje de Causas de error para un xDelayTime de 10 ms. 81 Figura 35. Porcentaje de Causas de error para un xDelayTime de 14 ms. 81 Figura 36. Envíos generados desde interrupciones periódicas. 83 Figura 37. Distribución de los agentes y sus respectivos comportamientos para la aplicación
de demostración. 85 Figura 38. Distribución de los agentes según los recursos físicos disponibles. 86
vi
INDICE DE TABLAS
Tabla 1. Comparación de los recursos de memoria entre PIC18F452 y PIC18F8720. 25 Tabla 2. Descripción de los bytes de la trama Event BESA para un Data Size de
tamaño N. 47 Tabla 3. Descripción de los bytes de la trama Ack BESA. Constante para cualquier tamaño
de datos. 48 Tabla 4. Valores de los Stacks. 66 Tabla 5. Tiempos de Respuesta para distintas cantidades de Agentes en un Contenedor.
Todos los tiempos en milisegundos. 67 Tabla 6. Tiempos de Respuesta para distintas cantidades de Comportamientos en un
Contenedor. 68 Tabla 7. Cantidad máxima de Guardas en un contenedor 69 Tabla 8. Tiempos de respuesta a eventos con distintas cantidades de Puertos 69 Tabla 9. Envíos de Eventos por el puerto I2C con diferentes tamaños de colas y periodos de
envío. 71 Tabla 10. Tiempos de respuesta a un envío remoto por I2C. 74 Tabla 11. Tiempos de atención a los envíos externos de eventos generados
periódicamente. 75 Tabla 12. Tiempos de atención a los envíos locales de eventos generados
periódicamente. 76 Tabla 13. Promedio de Envíos exitosos y fallidos generados desde una rutina de interrupción
a un agente local. 82
vii
INTRODUCCIÓN
En la cotidianidad se puede observar que para la solución eficiente de problemas complejos,
resulta conveniente dividirlos en tareas más simples que puedan ejecutarse por separado. Un
buen resultado depende de la coordinación entre ellas. Éste mismo concepto puede ser llevado a
la industria, donde el avance de la tecnología plantea nuevos retos que requieren soluciones
rápidas y efectivas.
Existe un modelo que abstrae el concepto de tareas distribuidas y que propone un esquema para
la construcción de sistemas complejos. Éste modelo es conocido como Sistema Multi-Agente
(SMA).
A partir de los desarrollos sobre SMA publicados por Jiming Liu, se puede obtener una visión
general del origen y justificación de este modelo. Sus desarrollos respondían a la pregunta de
por qué tener múltiples individuos afirmando: “por la misma razón que organizaciones como las
conformadas por abejas y hormigas están formadas por grupos de individuos nacidos con una
labor específica, los individuos se comunican entre sí, para entre todos, lograr un objetivo
común”1. De esta forma, se muestra la existencia de entidades (individuos) especializadas para
el desarrollo de determinadas labores y como a través de estas entidades, es posible distribuir
las tareas, disminuyendo la carga para cada uno de ellos y mejorando el resultado final.
Los SMA no sólo son una tecnología muy prometedora, también están emergiendo como una
nueva manera del pensamiento: un paradigma conceptual para analizar problemas y para el
diseño de sistemas; un medio para manejar la complejidad, distribución e interactividad, y
quizás una nueva perspectiva en las ciencias de la computación y la inteligencia artificial2.
El diseño de aplicaciones desde el concepto SMA presenta algunas dificultades tales como la falta
de herramientas para su desarrollo y su reducido uso industrial. Para darle solución a lo anterior
hemos desarrollado una herramienta de programación de alto nivel que facilita la distribución de
tareas y su aplicación en un entorno hardware, con la característica de permitir al diseñador
modificarlas en una forma eficiente, así como realizar labores de mantenimiento o actualización
del sistema (escalabilidad). Dado el extendido uso de los microcontroladores para aplicaciones
industriales y de investigación, la implementación de la herramienta se ha realizado sobre estos
dispositivos.
1 LIU, Jiming. “Multi – Agent Robotic Systems”. CRC Press, Boca Ratón, Fl. 2001 2 Robocup Federation, “RoboCup Home Page”. http://www. robocup.org.
1
Debido al enfoque Multi-Agente de la herramienta que fue implementada, este libro comienza
con un resumen de las generalidades y aplicaciones de los SMA. En el capítulo siguiente se
describe BESA, la arquitectura de SMA desarrollada en la Pontificia Universidad Javeriana, con
base en la cual se ha desarrollado la herramienta descrita en este trabajo y que da origen a su
nombre BESA Micro Edition (BESA-ME). Una vez identificadas las necesidades de este modelo de
SMA y su aplicación a microcontroladores, se muestra la necesidad de usar un Sistema
Operativo que las soporte, por lo cual continuamos con un capítulo donde se explican las
características generales y se describen más a fondo los Sistemas Operativos de tipo Tiempo
Real (RTOS por sus siglas en inglés). Luego, en el desarrollo, se sintetizan lo requerimientos de
ejecución de la arquitectura BESA, con base en estos se explica como se seleccionó el RTOS para
soportar el modelo y como fue construido el modelo BESA adaptado a las características de un
micro-controlador y a un ambiente distribuido de dos microcontroladores. Por último, se
exponen las pruebas y sus resultados, con los cuales se evaluaron las características de
capacidad y velocidad de la herramienta aplicada a una plataforma hardware específica.
BESA-ME es entonces una herramienta innovadora, económica y de gran facilidad de aplicación,
diseñada con posibilidades de ser actualizada a medida que los microcontroladores evolucionen.
2
1. OBJETIVOS
1.1. Objetivo General
Desarrollar una plataforma de software que implemente el modelo BESA para una familia de
microcontroladores, permitiendo la creación de aplicaciones con enfoque Multi-Agente.
1.2. Objetivos Específicos
1. Seleccionar e implementar para una familia de microcontroladores, un sistema operativo ya
existente que posea las características de un RTOS y proporcione los servicios básicos de un
ambiente multitarea requeridos por el modelo BESA.
2. Diseñar e implementar una plataforma de software basada en el modelo BESA que funcione
sobre el RTOS seleccionado e implementado y que soporte la creación de aplicaciones con
enfoque Multi-Agente.
3. Desarrollar el servicio de comunicación entre agentes de dos microcontroladores de la misma
familia adecuado para el modelo BESA.
3
4
2. MARCO TEÓRICO
En este marco teórico se muestra un resumen de las generalidades y aplicaciones de los
Sistemas Multi-Agente. Con base en esto se describe el modelo abstracto de SMA planteado por
la arquitectura BESA. Dadas las características que plantea este modelo y su aplicación a
microcontroladores, se muestra la necesidad de usar un Sistema Operativo Tiempo Real, sobre
el cual se profundiza también.
2.1. Sistemas Multi-agente
Un Sistema Multi-Agente (SMA) es un sistema computacional con características de autonomía,
es decir, capaz de ejecutar ciertas tareas dentro de un entorno determinado y modificarlo, según
la función especifica para la cual fue diseñado. Las funciones que puede realizar están definidas
por un conjunto de instrucciones que pueden ser ejecutadas o no. La arquitectura del sistema
determina la forma de comunicación entre agentes y la administración de los recursos3.
En la estandarización de estas arquitecturas de SMA, la fundación FIPA (Foundation for
Intelligent Physics Agents) ha creado ciertas directrices. Propone una plataforma de software
que contiene la definición de un lenguaje de comunicación entre agentes y los elementos básicos
para la construcción del sistema4.
Aplicaciones
Actualmente los Agentes y los sistemas multiagente son una de las tecnologías más prominentes
y atractivas de la ingeniería y la informática. Las tecnologías, métodos y teorías de sistemas
multiagentes están contribuyendo en diversos dominios de aplicación, tales como: recuperación
de información, diseño de interfases de usuario, robótica, juegos de computador, educación,
ambientes de entretenimiento, manejo y administración de proyectos, simulación social, realidad
virtual, etc.
En la solución de muchos de estos problemas se emplean mecanismos de control de software y
de hardware, como algoritmos computacionales y máquinas dedicadas que utilizan
microcontroladores y DSP.
3 WEISS, Gerhard. “Multiagent systems: A modern approach to Distributed Artificial Intelligence”.
Masachussets, U.S.A 1999. 4 Foundation For Intelligent Physical Agents, http://www.fipa.org, Noviembre 5 del 2004.
5
http://www.fipa.org/
2.2. Arquitectura BESA de Sistemas Multi-Agente
BESA es una arquitectura para la construcción de Sistemas Multi-Agente, que implementa tres
conceptos principales en su modelo abstracto de SMA5, de los cuales se desprende la sigla
BESA:
• Behavior – Oriented: Los agentes se descomponen modularmente en entidades más
simples, las cuales poseen ciertos comportamientos con una semántica asociada entre
ellos, que permite la cooperación. Un agente está compuesto por un conjunto de
comportamientos concurrentes.
• Event – Driven: Los eventos que desencadenan la ejecución de comportamientos son
señales que pueden ser percibidas o usadas por los agentes y esta ejecución depende de un
mecanismo selector que evalúa el estado actual de la entidad y el estado de comunicación
asociado a la detección del evento.
• Social – Based: El sistema se crea sobre una organización social de agentes, compuesta
en un conjunto de organizaciones de más bajo nivel, que conservan la estructura de un
agente y cuyos últimos eslabones son los agentes individuales.
2.2.1. Definición de Agente
Un agente es la unidad abstracta fundamental a partir de la cual se conforma el sistema Multi-
Agente BESA. A nivel social es la unidad más simple que sirve como base para construir
cualquier nivel superior. Su arquitectura interna determina la estructura del sistema, los
mecanismos de interacción entre los mismos agentes y el tratamiento dado a los eventos con el
fin de obtener una respuesta.
Los agentes responden a eventos provenientes del entorno o de una tarea en ejecución. Así
como el agente puede percibir eventos provenientes del entorno, también puede modificarlo.
Para esto, cada evento que se defina en el sistema debe tener un tratamiento asociado, de
manera que cuando el agente lo perciba ejecute un procedimiento y se obtenga un resultado.
Un agente debe además poder comunicarse con los demás agentes del sistema, pues es
fundamental la interacción entre ellos para lograr el objetivo esperado a través de la ejecución
concurrente de las tareas, el intercambio de eventos y la respuesta dada a los mismos.
5 GONZALEZ, Enrique, AVILA, Jamir, BUSTACARA, César. “BESA” Bogotá, Colombia. 2003.
6
Estructura de un Agente (Canal – Comportamiento – Estado)
La arquitectura interna de los agentes integra cuatro elementos importantes: una composición
modular de comportamientos, un canal compuesto por un buzón de recepción y un mecanismo
selector de eventos y un estado.
Figura 1. Arquitectura interna de un agente. Tomado del artículo BESA.5
El canal y el comportamiento son las dos tareas por las cuales está compuesto un agente como
mínimo. En el canal se reciben los eventos; para cada tipo de evento debe existir un puerto al
cual se asigna el evento recibido para ser transferido a los comportamientos asociados. Allí se
almacenan y se ejecutan los procedimientos relacionados a cada evento.
Como se observa en la figura 1, el canal está formado por un buzón de entrada, donde se
reciben los eventos direccionados al agente. Mediante un mecanismo selector basado en
guardas los eventos que se reciben se transfieren al puerto correspondiente. Los puertos al
igual que el buzón de entrada son colas, que permiten almacenar varios eventos de un mismo
tipo en un puerto específico.
La política implementada para el despacho de los eventos es FIFO (First in – First out), razón por
la cual por cada tipo de evento asignado a un agente, debe existir un puerto asociado, con el fin
de evitar el bloqueo entre eventos y que no se ejecuten los procedimientos relacionados en el
momento adecuado.
7
El evento almacenado en el puerto sólo se transfiere al comportamiento correspondiente cuando
se comprueba una condición booleana, que se puede ver afectada por el mismo evento o por
una variable que influye en la condición, disparando la guarda.
Los comportamientos son tareas que pueden ejecutarse en paralelo y deben estar asociados con
la guarda asociada al tipo de evento. Cada comportamiento tiene una cola para recibir eventos
provenientes de los puertos del canal; cuando llega el evento, el comportamiento ejecuta
automáticamente la función de tratamiento correspondiente.
Un sistema multitarea permite que varios procesos sean ejecutados al mismo tiempo,
compartiendo uno o más procesadores. BESA tiene la característica de ser una arquitectura
multitarea ya que debe coordinar concurrentemente el uso del canal de comunicación y la
ejecución de los comportamientos de los agentes en tiempo real. Tener más de un
comportamiento en la arquitectura de un agente permite el paralelismo en el sistema, es decir,
la ejecución de diferentes procedimientos en tiempo real, como respuesta a eventos que pueden
ser concurrentes o no.
Dentro de la arquitectura del agente existe un espacio denominado Estado (State) reservado
para guardar información acerca del contexto del agente, del entorno, de los demás agentes y
del sistema en general, según el tipo de información que el usuario final requiera. El estado
puede ser accedido desde las funciones de tratamiento que se ejecutan en el comportamiento;
puede ser leído y modificado según se requiera, por lo que debe ser protegido para que sólo
pueda ser accedido por una tarea a la vez.
Definición de Contenedor
Un conjunto de agentes reunidos da origen a un nivel social más abstracto conocido como
sistema. En BESA un sistema está formado por contenedores, que pueden funcionar en
diferentes máquinas físicas o virtuales.
Un contenedor es un espacio de ejecución donde los agentes habitan. Estos están manejados
por un administrador local que es el encargado de la gestión del ciclo de vida de los agentes y de
permitir la comunicación con agentes de otros contenedores.
8
Figura 2. Modelo del nivel de sistema BESA. Tomado de BESA.5
Los agentes pertenecientes a un mismo contenedor interactúan directamente, a diferencia de los
agentes ubicados en distintos contenedores, los cuales se comunican entre si a través de un
único puerto compatible con FIPA, el cual recibe la comunicación y las consultas de otros
sistemas externos. (Ver Figura 2).
2.2.2. Requerimientos de BESA
Necesidades de Sincronización
En la construcción del modelo de implementación (BESA-ME, BESA-Micro Edition) surge la
necesidad de proteger estructuras y variables que pueden ser accedidas por varias tareas al
mismo tiempo. Si una tarea accede a determinada variable y está utilizando la información
contenida en ésta, ninguna otra tarea debe acceder a la misma variable hasta que no sea
liberada por la tarea anterior. En el peor de los casos el acceso simultáneo por más de una
tarea a una variable podría causar que ésta sea modificada mientras está siendo accedida y
generar un error en la información o en la ejecución.
Para evitar que esto suceda es necesario contar con algún mecanismo de señalización que
proteja la variable a la que se accede y la información contenida en ella, de manera que en los
casos críticos en los que se requiera, sólo una tarea pueda acceder la variable a la vez.
La utilización de semáforos es seguramente la solución más adecuada para solucionar los
problemas de sincronización. Cuando se va a acceder a una variable crítica, se baja el
semáforo, cuando se libera la variable se sube el semáforo y otra tarea puede accederla.
9
Necesidades de Concurrencia
Debido a que el modelo abstracto de BESA plantea la ejecución de los comportamientos en
paralelo, se requiere que la arquitectura BESA sea una arquitectura multitarea, creando cada
comportamiento y cada canal como una tarea del sistema operativo, lo que permite su ejecución
concurrente por parte del planificador del RTOS.
Cada agente puede tener más de un comportamiento, y a cada comportamiento le son
asignados eventos con sus respectivas funciones de tratamiento; las funciones deben ser
ejecutadas entonces simultáneamente para responder a los eventos en tiempo real a medida
que se vayan presentando. Puede ser útil entonces, el manejo de prioridades para asegurar la
ejecución de ciertos comportamientos críticos que requieran una acción inmediata, teniendo
presente que se debe evitar la inanición de las tareas de menor prioridad.
El hecho de que el canal sea una tarea que se ejecute paralelamente con los comportamientos,
asegura al máximo la recepción de los eventos que le sean dirigidos y su reenvío a los
comportamientos correspondientes.
Comunicación entre Agentes
BESA plantea un servicio de directorios que facilita la comunicación entre los agentes. El
servicio tiene dos secciones principales: una de páginas blancas donde es posible ubicar los
agentes por una identificación dada en el momento de la creación; y otra de páginas amarillas
donde se puede localizar a un grupo de agentes que tengan ciertas características en común,
según su especialidad. Cada contenedor tiene su propio servicio de directorios.
La comunicación entre agentes se puede dar de dos maneras diferentes: entre agentes del
mismo contenedor o entre agentes de contenedores distintos.
Comunicación entre Agentes del Mismo Contenedor
Cuando un agente quiere comunicarse con otro, recurre entonces al servicio de directorios para
poder localizar el destinatario, ya sea por su identificación o por su especialidad. Si los agentes
pertenecen al mismo contenedor, la comunicación es directa, envían información de uno a otro,
sin que el administrador local del contenedor intervenga.
Comunicación entre Agentes de Distintos Contenedores
El agente acude al servicio de directorios para localizar al agente con el que se quiere comunicar.
Una vez localizado, la comunicación se realiza a través del puerto serial al que todos los
contenedores pueden acceder, el cual se encarga de transmitir y recibir la información
proveniente de otro contenedor y entregarla al agente correspondiente.
10
Los contenedores deben tener en su servicio de directorios la información correspondiente a los
agentes existentes en los demás contenedores. Si un agente es creado o destruido, el
administrador local del contenedor debe informar a todos los otros contenedores del sistema,
con el fin de que sea actualizado su servicio de directorios. Lo mismo debe hacerse en el
arranque del sistema para que cada contenedor conozca a de la existencia de otros
contenedores y agentes6.
2.3. Sistemas Operativos
Los Sistemas Operativos (SO) son uno de los más grandes logros en el desarrollo de software y
constituyen uno de los más complejos programas. La búsqueda por lograr una administración
eficiente y segura de los recursos de un computador ha llevado al desarrollo de los conceptos de
proceso, gestión de memoria, seguridad y protección de la información, planificación y gestión
de recursos, y estructura de sistema7.
El concepto de proceso es uno de lo grandes logros en el desarrollo de SO. Se define como la
mínima unidad de actividad; está caracterizada por una ejecución secuencial, por un estado
actual y por estar asociada a un conjunto de recursos. Está compuesto por una o más unidades
de trabajo conocidas como hilos, estos incluyen un contexto propio y áreas de datos propias, a
partir de las cuales se logran establecer bifurcaciones a subrutinas, es decir, son
interrumpibles y permiten que los procesos cedan y retomen el control del procesador (control
expropiativo), utilizando así, la técnica de multi-hilos para ejecutar varias tareas independientes
(multiproceso)8.
Para la administración del paso de ejecución de un proceso a otro y sus implicaciones existen
varios algoritmos de planificación. Esta administración parte de 5 posibles estados de los
procesos: Nuevo, Listo, Ejecutándose, Bloqueado y Terminado, según los cuales se deben tomar
las acciones determinadas por el algoritmo de planificación.
En la actualidad el estándar POSIX, define la interfaz que los sistemas operativos deben ofrecer
a las aplicaciones, así como la semántica de los servicios ofrecidos por esta interfaz.
6 GONZALEZ, Enrique, AVILA, Jamir, BUSTACARA, César. “BESA” Bogotá, Colombia. 2003. 7 STALLINGS, William. “Sistemas Operativos”. Prentice Hall. Madrid, España. 2001. 8 STALLINGS, William. “Sistemas Operativos”. Prentice Hall. Madrid, España. 2001.
11
2.3.1. Sistemas Operativos en Tiempo Real
Cuando un sistema computacional requiere dar respuesta a determinados dispositivos en tiempo
real, aspectos como la administración eficiente de la memoria y el aumento en la eficiencia de
utilización de la CPU se hacen secundarios, tal es el caso de las plataformas robóticas y mallas
de control industrial. Esta necesidad ya ha sido detectada por empresas diseñadoras de
microcontroladores usados en aplicaciones de tiempo real y ha sido superada mediante el
desarrollo de sistemas operativos para estos dispositivos, son conocidos como sistemas
operativos en tiempo real (RTOS, siglas en inglés).
Los Sistemas Operativos Tiempo Real son diseñados para administrar la respuesta a sucesos o
eventos, de tal forma que se respeten ciertos rangos de tiempo de respuesta, los cuales, en el
caso de ser críticos para el sistema, requieren atención inmediata. En todo caso el RTOS es
determinista, en consecuencia permite que el usuario prediga los tiempos de respuesta que el
RTOS proporcionará al sistema informático que administra. Estos eventos, normalmente se
producen en el entorno del sistema; estos llegan como interrupciones al procesador, ya sean por
software o hardware. Los RTOS deben atender ráfagas de miles de interrupciones que activan
diferentes procesos. Para no perder ningún suceso recibido, el RTOS debe trabajar con la
técnica multiproceso, la cual ejecuta los procesos independientemente unos de otros, pero en
ciertas aplicaciones se deben tener estrategias para asignar prioridad a los procesos y
ejecutarlos según su importancia, lo cual se logra con una planificación expropiativa basada en
prioridades.
Algunas de las características más importantes de los RTOS son9:
- La gestión de dispositivos críticos en tiempo.
- Sofisticadas estrategias para la gestión de interrupciones.
- Eficiente almacenamiento de E/S.
- Permiten acceso desde los programas de usuario a los vectores de interrupción para
prestar servicio a los sucesos.
Otras áreas críticas en los RTOS son el determinismo, la sensibilidad, el control del usuario, la
gran fiabilidad y la tolerancia a los fallos.10
Entre éste tipo de SO se encuentran muchas versiones comerciales de alto costo como URTX,
RTX, QNX, útiles para dispositivos de alto desempeño como los microprocesadores 80X86 y
9 MILENKOVICH, Milan. “Sistemas Operativos: Conceptos y Diseño”. Mc. Graw Hill, Madrid, España. 1998. 10 STALLINGS, William. “Sistemas Operativos”. Prentice Hall. Madrid, España. 2001.
12
algunos de libre distribución como SALVOTM y la migración del SO MartOS al MC6833211.
SALVOTM, con versiones para microcontroladores Microchip, TI y Motorola entre otros, soporta
multiproceso y en su versión de libre distribución soporta hasta tres tareas simultáneas12.
2.3.2. Planificación
El planificador es un conjunto de políticas y mecanismos incorporados al Sistema Operativo que
gobiernan el orden en que se ejecutan las tareas en un sistema multiprogramado. El objetivo
primario de la planificación es optimizar el rendimiento del sistema de acuerdo con los criterios
considerados más importantes por los diseñadores. Existen 3 clases de planificadores, los
cuales se clasifican según la frecuencia con la que es invocado por el procesador; estas son
planificaciones a largo, mediano y corto plazo; este último es el único que se implementa en los
RTOS.
El planificador a corto plazo, también conocido como distribuidor (Dispacher), es el que toma
decisiones con una mayor frecuencia y detalle sobre la tarea que se ejecutará a continuación. Su
principal objetivo es maximizar el rendimiento del sistema de acuerdo con un conjunto de
criterios elegidos. El planificador a corto plazo debe ser ejecutado por lo tanto, cada vez que
una tarea se detenga (bloqueo), o cada vez que un suceso (interno o externo) ocurra. Éste es el
tipo de planificador que soportan los sistemas RTOS, ya que el tiempo de ejecución es el criterio
más importante a tener en cuenta. La suspensión, la terminación o aborto de una tarea en
ejecución, son también sucesos que pueden necesitar la llamada al planificador a corto plazo.13
Los algoritmos o mecanismos de planificación se pueden dividir en dos grandes grupos,
expropiativos y no expropiativos. La no expropiación implica que cuando una tarea de mayor
prioridad aparece, la tarea actual en ejecución no se ve obligada a ceder la propiedad del
procesador, sino hasta que éste termine su ejecución. Con planificación expropiativa una tarea
en ejecución puede ser sustituida por una tarea de mayor prioridad en cualquier instante, lo que
implica entonces una mayor carga de trabajo para el planificador pero un menor tiempo de
respuesta a los eventos críticos. Las características que deben cumplir los RTOS son apoyadas
por el uso de planificación expropiativa.
Round Robin (RR), planificación por turno rotatorio o también conocida como fracciones de
tiempo, presenta una apropiación del reloj de modo que se genera periódicamente una
interrupción indicando que la tarea que se encuentra en ejecución tiene que ser colocada en la
11 CASTO GUTIÉRREZ, Alberto, “Migración de un Sistema Operativo De Tiempo Real, MaRTE OS, a un
microcontrolador”, http://marte.unican.es/alberto_slides.ppt, Septiembre 5 de 2004. 12 SALVOTM, http://www.pumpkinc.com, Febrero 15 de 2004. 13 MILENKOVICH, Milan. “Sistemas Operativos: Conceptos y Diseño”. Mc. Graw Hill, Madrid, España. 1998.
13
http://marte.unican.es/alberto_slides.ppthttp://www.pumpkinc.com/
cola de listas y se selecciona la siguiente, según un FIFO. El criterio de diseño es el tiempo de
duración de los cuantos (fracciones de tiempo) que se va a usar. Si el cuanto es muy pequeño,
las tareas cortas tendrán que pasar varias veces por el sistema antes de ser finalizados,
generando una sobrecarga en la gestión de recursos. Si el cuanto es muy grande, RR se
degenera en un simple FIFO donde las tareas cortas tienen que esperar mucho tiempo.
Existen otros algoritmos de planificación que presentan una serie de características más
complejas, impidiendo así cumplir con los criterios necesarios para la implementación de un
RTOS. Algunos de estos son SRT (Shortest Remaining Time), para el cual la tarea con menor
tiempo esperado de ejecución será la más prioritaria; Realimentación el cual presenta un
mecanismo dinámico de colas y prioridades. Cada cola representa un nivel de prioridad, y el más
alto es el de las tareas más nuevas. Una vez una tarea vuelve a su estado de Lista, luego de su
primera ejecución, es colocado en la segunda cola de menor prioridad. Después de cada
ejecución, la tarea Lista es degradada al nivel inmediatamente inferior de prioridad. Cada una de
estas colas funciona con la filosofía de FIFO, menos la última, que funciona con el mecanismo de
RR por no poder descender más; Planificación de colas multi-nivel (MLQ, Multiple-Level Queues),
el cual clasifica la carga de trabajo de acuerdo con sus características y mantiene colas de tareas
separadas servidas por diferentes planificadores. Una posible separación sería programas
interactivos, tareas del sistema y trabajos de lotes (simuladores). Estas asociaciones no son de
gran utilidad, para sistemas en tiempo real, por lo que no se suele implementar esta disciplina
en RTOS.
Un criterio más que debe cumplir un RTOS en el que se desee implementar en un sistema Multi-
Agente es el “tiempo de respuesta”, es decir, cualquier opción que presente una reducción en el
tiempo de procesamiento y de decisión, debe aparecer en las posibilidades de adopción para
éste proyecto. La no utilización de planificadores a largo y mediano plazo es una decisión
evidente para cumplir con los parámetros necesarios, ya que el tiempo de procesamiento
requerido por cada uno de ellos, implica retardos indeseables. Por esta misma razón, los
algoritmos de planificación que requieren de cálculos complejos son desechados de las
posibilidades de implementación, como los son SPN (Shortest Process Next), SRT (Shortest
Remaining Time), Mayor Tasa De Respuesta y Colas Multi-Nivel, métodos descritos
anteriormente.
“La planificación dinámica del mejor resultado es el método utilizado en la mayoría de los
sistemas en tiempo real comercializados en la actualidad. Cuando llega una tarea, el sistema le
asigna una prioridad en función de sus características. Normalmente, se emplea alguna forma
de planificación por plazos, como puede ser la de primero el plazo más próximo. En general, las
tareas son aperiódicas, por lo que no es posible un análisis estático de planificación. Con este
tipo de planificación, no se sabe si se va a cumplir una restricción de tiempo hasta que vence el
14
plazo o la tarea termina. Esta es la mayor desventaja de esta forma de planificación. Su
ventaja está en la facilidad de implementación.”
El uso de múltiples colas, cada una de ellas de distintas prioridades (diferente al mecanismo de
Colas Multi-Nivel), recorridas con el mecanismo de turno rotatorio, se presenta como la mejor
opción de implementación para los requerimientos de BESA, ya que la característica de Event –
Driven requiere de una selección de tareas basada en prioridades, y de rotación equitativa,
además, su fácil implementación garantiza una rápida ejecución del planificador, evitando de
esta forma la inanición de procesos14.
2.3.3. Mecanismos de sincronización
Los sistemas operativos de tipo tiempo real (RTOS) soporten la concurrencia de tareas. Esta
característica tiene varios niveles de complejidad dependiendo el tipo de relación que tienen
entre sí las tareas que requieren el uso del procesador, así: estas tareas pueden ser
independientes y no conocer la existencia de las otras (competencia), tener conocimiento
indirecto de las otras tareas (cooperación por compartimiento) o tener conocimiento directo de
las otras tareas (cooperación por comunicación). Las anteriores relaciones llevan a situaciones
de competencia y de cooperación que deben ser soportadas por el sistema operativo o tenidas
en cuenta por el programador.
Para que un sistema soporte la concurrencia sincronizada de tareas, en éste se deben realizar
dos acciones fundamentales: la Administración de recursos globales y la Gestión óptima de los
recursos. Para llevarlas a cabo se han diseñado los mecanismos de sincronización. Estos
permiten solucionar los tres problemas principales de la sincronización entre tareas: la exclusión
mutua, el inter-bloqueo y la inanición de las tareas.
El problema de la exclusión mutua se da cuando un recurso puede ser usado por una sola tarea
y no puede compartir su tiempo con otras hasta que la tarea salga de la sección de programa
que lo usa, estos recursos son llamados recursos críticos y la región del programa que los usa
son llamadas regiones críticas. El sistema operativo junto con otros servicios se deben encargar
de que sólo una tarea opere en su sección crítica a la vez. Por otro lado el inter-bloqueo se
presenta cuando dos tareas (o más) esperan la liberación de un recurso compartido, y a s vez,
esta espera retiene la liberación de otro recurso. Por último la inanición de una tarea se da
cuando el SO le concede el uso de un recurso a determinadas tareas periódicamente y se impide
que alguna o algunas tareas determinadas vuelvan a tomar el control del procesador, por
ejemplo por ser de baja prioridad.
14 MILENKOVICH, Milan. “Sistemas Operativos: Conceptos y Diseño”. Mc. Graw Hill, Madrid, España. 1998.
15
Los problemas de sincronización que aparecen por la concurrencia de tareas son
fundamentalmente los mismos tanto para un sistema monoprocesador, donde se intercalan las
tareas, como para un sistema multiprocesador, donde también hay superposición
(simultaneidad) en la ejecución de tareas.
Las soluciones a los anteriores problemas se pueden agrupar en tres tipos:
• Por software, estas son implementadas en el código de programa de usuario. Los
Algoritmos de Dekker y de Peterson ofrecen una solución de éste tipo15.
• Desde sistema operativo, a través de funcionalidades como los semáforos y los
mensajes.
• Por Hardware, como, por ejemplo, el uso de inhabilitación por interrupciones.
El primer tipo es propenso a errores y a generar sobrecarga en el sistema. Las soluciones por
Hardware usan instrucciones de máquina por lo que no son soluciones generales. Estos
problemas no se presentan en las soluciones implementadas como servicios del sistema
operativo o del lenguaje de programación, por esto y otras ventajas adicionales, se han
convertido en las estrategias de sincronización de más éxito. Dado que cubren las necesidades
de facilidad de programación y portabilidad, necesarias para el desarrollo del proyecto, serán las
óptimas para cumplir los objetivos planteados. Explicamos su funcionamiento básico a
continuación.
Semáforos
El principio de los semáforos es la cooperación entre las tareas por medio de la generación de
señales y usados como mecanismos de sincronización permiten que se cumpla la exclusión
mutua entre tareas y evitan el interbloqueo. Los semáforos son variables que se modifican a
través de dos tipos de señales, una señal que indica que una tarea está esperando un resultado
y que llamaremos down y una señal que indica que se ha producido el resultado la cual
llamaremos up con la cual el semáforo debe “dejar pasar” una de las tareas que se encontraban
“esperando” en ese semáforo.
La variable semáforo puede iniciar en un valor no negativo y se debe disminuir en una unidad
cuando haya down y aumentar cuando se produzca up. Si al llegar un down el valor del
semáforo se hace negativo entonces la tarea que generó el down se bloquea ya que dicho valor
indica que no hay resultados disponibles para la tarea que los solicita. Ahora, cuando se
produce una señal up hacia cierto semáforo, significa que se produjo un resultado de interés
para las tareas que hayan estado esperando o para las que van a llegar a esperar, por lo cual se
incrementa en una unidad el valor del semáforo respectivo.
15 STALLINGS, William. “Sistemas Operativos”. Prentice Hall. Madrid, España. 2001.
16
Para decidir a cual de las tareas que produjeron un down en determinado semáforo se le debe
dar el control del procesador cuando ocurra el siguiente up (debido a la liberación de un recurso,
por ejemplo) se ha encontrado que la política más equitativa es FIFO, esta decisión es
independiente del mecanismo de planificación del sistema operativo. FIFO es la política para
semáforos más apropiada para el RTOS a implementar ya que disminuirá el riesgo de inanición
de una tarea en el acceso a un recurso. Una vez una tarea haya solicitado acceso al semáforo
ninguna tarea de más prioridad podrá quitárselo.
Los semáforos permiten solucionar el problema de la exclusión mutua, mediante identificadores
que avisen con una señal down cuando se entra en la sección crítica de un programa. Sin
embargo, el éxito del uso de semáforos depende de su correcto manejo, debido a que la falta del
uso de alguna de estas dos señales puede llegar a bloquear el sistema.
Mensajes
El paso de mensajes entre procesos permite que las tareas cooperantes se sincronicen y que a
su vez intercambien información. El servicio de mensajería es útil en sistemas distribuidos, en
sistemas multiprocesador y monoprocesador de memoria compartida. Por lo cual será de gran
utilidad para la comunicación entre agentes.
Por un lado tenemos el intercambio de información. Para intercambiar información se necesita
al menos un sencillo protocolo de comunicación que permita la sincronización de los mensajes.
El esquema más sencillo consiste en el uso de las primitivas send y receive. Con estas primitivas
se pueden generar distintas configuraciones: bloqueo de la tarea tras generar send hasta que
reciba una respuesta, o no bloqueo, bloqueo tras generar receive hasta encontrar un mensaje o
no bloqueo. Según el tipo de sistema a desarrollar existen diferentes técnicas para solucionar
problemas como la pérdida de los mensajes o el bloqueo indefinido de las tareas al esperar un
mensaje que nunca llega.
Para enviar y recibir mensajes hacia y desde la tarea correcta se usa el direccionamiento directo
e indirecto, para cada primitiva. La primitiva send con direccionamiento directo requiere tener
identificadores para cada tarea, el cual debe ser enviado al llamar la primitiva. En el caso de
direccionamiento indirecto los mensajes se envían a una estructura de datos formada por colas
(denominada buzón), en las cuales se almacena temporalmente la información hasta que un
receptor la lee, es análogo a un arreglo de buzones donde cada uno ha sido creado para
establecer distintos tipos de relaciones entre las tareas. Estas relaciones pueden ser de un
emisor a un receptor (comunicación punto a punto), de un emisor a muchos receptores o de
muchos emisores a un receptor, para éste último caso el buzón es denominado puerto.
17
La primitiva receive con direccionamiento directo requiere que cada tarea tenga conocimiento
anticipado sobre qué tarea o tareas le enviarán información, pero para los casos en que es
imposible predecir de qué tareas se va a recibir un mensaje en cada instante, se usa el
direccionamiento implícito, en éste, al ejecutar la primitiva receive, la tarea receptora espera el
identificador de la tarea que da origen al mensaje, proveniente de la ejecución de un send.
Cuando sucede un envío con exitosa recepción, el sistema puede realizar una copia del mensaje
en una cola o buzón, o simplemente transferir el apuntador a la información, lo cual la
convertiría en memoria compartida. Cuando se realiza copia del mensaje se asegura que no se
modificará indeseablemente el contenido de la información, sin embargo, éste método es lento,
ya que a medida que crece el tamaño de la información crece el tiempo de transferencia,
además utiliza más memoria para la creación de los buzones pero evita usar recursos adicionales
para proteger la información. El traslado del apuntador utiliza eficientemente la memoria, pero
se debe tener cuidado (usando los mecanismos adecuados) para no modificar los mensajes
originales en casos indeseados.
Cuando se quiere minimizar la carga de procesamiento y minimizar el coste de almacenamiento,
requerimientos de este proyecto, se usa un formato de mensajes de tamaño corto y fijo apoyado
en una organización de memoria por ejemplo pool de buffers, concepto que se ampliará en la
sección 2.3.4. En el formato del mensaje se incluye algunas veces información sobre la prioridad
del mensaje, para soportar el caso en el que no se desee tomar los mensajes de un buzón con
política FIFO. Por otro lado el paso de mensajes permite la sincronización respecto a los recursos
del sistema, es decir, soporta la exclusión mutua16.
2.3.4. Manejo de memoria
Dadas las características de memoria de los microcontroladores actuales, se necesita una
estrategia para el manejo de memoria que no consuma muchos recursos del dispositivo y que no
sobre cargue el procesador. La estrategia más sencilla es definir cuales son los tamaños de
palabra más útiles para el sistema operativo y crear arreglos de buffers de estos tamaños, y
solicitarlos al sistema a medida que se vayan necesitando.
La anterior estrategia es conocida como pool of buffers. Presenta la ventaja de requerir mínimo
sobre costo en el uso del procesador ya que elimina la búsqueda de espacios de memoria libres
al dejarlos de tamaño fijo. Sin embargo puede llegar a ser ineficiente el uso de la memoria
cuando se reserva un espacio mayor al máximo de los buffers necesario o se usa menos espacio
que el menor de los reservados. Además, el programador debe ser muy cuidadoso de liberar los
16 MILENKOVICH, Milan. “Sistemas Operativos: Conceptos y Diseño”. Mc. Graw Hill, Madrid, España. 1998.
18
semáforos de protección una vez han sido usados los buffers, para permitir la posterior
reutilización de los mismos.
19
20
3. DESARROLLO
Se comenzó por analizar los requerimientos de la arquitectura BESA; con base en estos se
explica como se seleccionó el RTOS para soportar la construcción y aplicación del modelo. Se
adaptó el modelo BESA a las características de un micro-controlador, luego se diseño y aplicó
un protocolo de comunicación para la extensión del modelo a un ambiente distribuido que usa
dos microcontroladores.
3.1. Requerimientos de BESA
En el capítulo 2 se describieron las características de Concurrencia, Sincronización y
Comunicación entre tareas como los principales requerimientos del modelo BESA. Como se
mostró en el aparte de sistemas operativos, estas características son soportadas por los RTOS
actuales, pero adicional a estos requerimientos surge uno nuevo, ya que al ser implementado
sobre un microcontrolador se hace crítica la capacidad de memoria del hardware. En
consecuencia es indispensable tener en cuenta que el modelo se pueda implementar sobre las
condiciones de memoria del dispositivo seleccionado.
3.2. Selección del RTOS y de la Familia de Microcontroladores
Se realizó una investigación sobre el funcionamiento de un RTOS en un micro controlador
desarrollando un kernel básico sobre un PIC18F452. Luego se buscaron los RTOS disponibles en
el mercado, buscando que tuvieran las características necesarias para implementar el modelo
BESA. Teniendo en cuenta criterios de bajo costo y facilidad de adaptación a nuestras
necesidades se seleccionó el RTOS freeRTOS y se estudiaron los posibles microcontroladores
sobre los cuales desarrollar la aplicación.
3.2.1. Búsqueda y Selección del RTOS
El Sistema Operativo necesario para la implementación de BESA debe ser como primera medida
de tiempo real, ya que se requiere dar respuesta a los eventos con la mayor rapidez posible y de
manera simultánea. Por esta razón el planificador debe dar tiempo de procesamiento a todas las
tareas que lo requieran, y contar con la característica de expropiación para permitir que tareas
de mayor prioridad tomen el control del procesador cuando lo necesiten. Además el SO debe
brindar un mecanismo para la creación y eliminación de tareas, y la posibilidad de suspenderlas
y reactivarlas, ya sea a una o a todas simultáneamente, en cualquier instante del
procesamiento.
21
El RTOS debe brindar la posibilidad de utilizar Semáforos, mecanismo seleccionado como la
mejor opción para solucionar los problemas de Sincronización, ya que permite el uso adecuado
de los espacios de memoria compartida a los que varias tareas (canal, comportamientos y otras)
pueden acceder, como el estado y los buffers utilizados para las transmisiones de un contenedor
a otro.
Un motivo por el cual una tarea puede llegar a bloquearse, es el envío no exitoso de un mensaje
a otra tarea; esta razón trae consigo la necesidad de un servicio de transmisión de mensajes
entre tareas, que permita la acumulación de mensajes cuando el planificador no permita su
inmediata recepción por tener bloqueada la tarea destino. Esto se logra por medio de colas tipo
buzón, en las cuales se puedan almacenar temporalmente eventos que serán atendidos una vez
la tarea destino sea desbloqueada y pueda recibir y dar tratamiento a los eventos enviados.
La búsqueda de un sistema operativo arrojó como resultados varios RTOS de libre distribución
desarrollados por distintas organizaciones y versiones de demostración de algunas empresas. De
todos estos destacamos aquí dos de los más sobresalientes y que más se acomodaban a
nuestras necesidades, SALVOTM y freeRTOSTM.
SALVOTM, del grupo PumpkincTM, fue diseñado expresamente para sistema embebidos, cuyas
aplicaciones típicas usan entre 1 y 2K bytes de ROM, y entre 50 y 100 bytes de RAM. Cumple
con el criterio de multitarea cooperativa, servicio de eventos, bloqueo y suspensión de tareas, y
con muchos otros aspectos necesarios descritos anteriormente para el desarrollo del proyecto.
SALVOTM puede implementar en una gran cantidad de dispositivos, como son:
• Familia 8051 y derivados.
• ARClite microRISC.
• ARM® ARM7TDMI®
• Atmel® AVR® y MegaAVR™
• Motorola M68HC11
• TI's MSP430 Microcontriolador de baja potencia
• Microchip PIC12|14000|16|17|18 PICmicro® MCUs
• TI's TMS320C2000 DSPs
Sin embargo, la versión demo de SALVOTM que puede ser adquirida libremente permite crear
únicamente 3 tareas como máximo, lo que impediría en gran parte un buen aprovechamiento
del mismo17. La adquisición de la versión completa implica una inversión económica que no está
contemplada en el proyecto, razón de peso para desistir de este RTOS.
17 SALVOTM, http://www.pumpkinc.com, Febrero 15 de 2004.
22
http://www.pumpkinc.com/
FreeRTOSTM ofrece bajo consumo memoria RAM puesto que ha sido desarrollado específicamente
para aplicaciones con sistemas embebidos (microcontroladores). Presenta además tres modelos
posibles de asignación de memoria para la implementación de las aplicaciones. Utiliza un tipo de
planificación expropiativa que implementa colas por cada nivel de prioridad, recorridas cíclica y
equitativamente según el mecanismo FIFO; también ofrece un sistema de sincronización por
medio de semáforos binarios.
FreeRTOSTM es de libre distribución, es de fácil implementación y entendimiento gracias a que se
puede acceder libremente a su documentación. FreeRTOSTM también puede ser implementado
en una gran variedad de dispositivos18:
• LPC2106, LPC2124 and LPC2129 (ARM7). Incluye código para el manejo de I2C. Renesas
H8S2329 (Hitachi H8/S) con un demo de EDK2329.
• Atmel AT91SAM7 o las familias (AT91SAM7S32, AT91SAM7S64, AT91SAM7S128,
AT91SAM7S256). Incluye código para el manejo de USB para IAR Kickstart.
• AT91FR40008 con demo de ATEB40X .
• MSP430 con manejador de LCD.
• HCS12 (MC9S12C32)
• Cygnal 8051 / 8052
• Microchip PICMicro (PIC18)
• Atmel AVR (MegaAVR) con código de demostración STK500.
• RDC8822 Microcontroller (AMD clon embebido del 186) con demo para Flashlite 186
SBC.
• PC [corre con FreeDOS u otro DOS]
FreeRTOSv2.6.0 ofrece todas las características necesarias para la correcta implementación de
la arquitectura BESA, así como servicios que facilitaron las pruebas ejecutadas en el transcurso
del proyecto. Los códigos y la documentación pueden ser descargados de Internet y traen
adjunto tres programas de demostración que sirven para familiarizarse con el RTOS, sirviendo
de punto de partida para nuevas aplicaciones. Se puede observar que este sistema operativo
tiene más oportunidades de migración a otros procesadores que los ofrecidos por SALVOTM, y por
consiguiente mayores aplicaciones posibles para el futuro de BESA-ME. Además cuenta con un
foro en la red donde es posible aclarar dudas y compartir inconvenientes y soluciones junto con
los demás usuarios y los desarrolladores del RTOS. Todas estas características llevaron a tomar
la decisión de implementar FreeRTOSTM como sistema operativo soporte a la plataforma BESA-
ME desarrollada.
18 FreeRTOSTM, www.freertos.org. Mayo 25 de 2005.
23
http://www.freertos.org/
3.2.2. Selección de la Familia de Microcontroladores
La familia de microcontroladores fue escogida con los siguientes criterios:
• Debe ser soportada por el RTOS escogido. (freeRTOSTM)
• Se analizó que tuviera la memoria suficiente para soportar el RTOS seleccionado y dejar
libre la memoria necesaria para el código BESA-ME.
• El tercer criterio fue que ofreciera un módulo para la comunicación con otros dispositivos
microcontroladores, para permitir que agentes de distintos contenedores pueden
interactuar.
• Para la generación de interrupciones interpretadas como eventos en el contesto BESA-
ME y la interacción con otros dispositivos hardware como respuesta a estos, se observó
que ofreciera un número de puertos y periféricos considerable.
• Finalmente se tuvo en cuenta la familia de microcontroladores más usados en el
contexto académico de los proyectos desarrollados en la Carrera de Ingeniería
Electrónica de la Pontificia Universidad Javeriana, en el cual se desarrolla BESA-ME.
Cualquiera de los sistemas embebidos que se desee implementar en la práctica, presentará
como criterio más crítico, la limitación de los recursos físicos. En éste caso, los requerimientos
de BESA indican que el recurso más limitado es el de memoria, pues esta arquitectura requiere
del uso constante de buzones para la recepción y envío de mensajes. Además, es necesaria la
asignación dinámica de segmentos de memoria que serán utilizados y reutilizados según la
aplicación implementada. El stack requerido por las tareas para guardar su información cuando
se produce un cambio de contexto, y las estructuras propias de BESA implican también un
espacio de memoria. El continuo manejo de colas, (tanto para planificación de tareas, como
para los comportamientos y eventos del sistema) que serán modificadas y leídas por distintas
tareas (las colas son memoria compartida), implica también el manejo de semáforos, que
también consumen memoria, para la correcta sincronización en el acceso a los espacios de
memoria que lo necesiten. Todos estos aspectos demuestran porque el aprovechamiento de la
memoria al máximo es un aspecto crítico del presente proyecto.
De esta forma, los criterios de selección del microcontrolador para el proyecto, están ligados con
la selección del RTOS freeRTOS. Este RTOS presenta demostraciones específicas para el
microcontrolador PIC18F452 de microchip. Además, la universidad posee el hardware necesario
para la programación de estos dispositivos (ICD2 – In Circuit Debbuger), así como el software
de simulación y de programación (MPLAB). Adicionalmente, la plataforma ROBOCOOP19 que
sería un ambiente óptimo para la aplicación de BESA-ME usa el microcontrolador PIC18F452.
19 ROBOCOOP Es un proyecto de robótica distribuida, desarrollado en la Pontificia Universidad Javeriana.
24
El PIC18F452 se acomoda fácilmente a las necesidades de la arquitectura BESA gracias al
soporte que presta el sistema operativo a este dispositivo. Sin embargo, no fue el
microcontrolador usado para finalizar el desarrollo de BESA-ME.
Luego de realizar la construcción del Nivel Agente, expuesto más adelante, se encontró que la
capacidad de memoria del PIC18F452 sólo permitía la creación de 1 agente y 2
comportamientos, razón por la cual se decidió realizar una migración de freeRTOSTM a otro
microcontrolador de la misma familia pero con más capacidad de memoria. Se escogió el
PIC18F8720, por las características que se muestran en la Tabla 1.
Para lograr esto fue necesario modificar el archivo p18f8720.lkr que viene incluido en los
archivos del compilador mcc18 de Microchip para el lenguaje de programación C. Estas
modificaciones fueron necesarias debido a que el manejo de memoria que hace freeRTOSTM
requiere que se defina un gran bloque de memoria sobre el cual se separan los bytes de RAM a
medida que se solicitan (ver anexo C).
PIC18F452 20 PIC18F8720 21
Memoria de Programa (Bytes) 32K 128K
Memoria de Programa (Instrucciones) 16384 65536
Memoria de Datos (Bytes) 1536 3840
Memoria de Datos EEPROM (Bytes) 256 1024
Fuentes de Interrupciones 18 18
Tabla 1. Comparación de los recursos de memoria entre PIC18F452 y PIC18F8720.
Realizando esta migración de freeRTOS se demostró parte de la fácil implementación de la
arquitectura BESA-ME en una gran variedad de microcontroladores, ya que a Nivel de Agente la
migración sólo depende de que el RTOS, la capa inferior de la arquitectura, sea portada al
dispositivo deseado. Esta familia de microcontroladores está siendo usada además en los
proyectos de investigación del grupo SIRPP
22 de la Pontificia Universidad Javeriana. De esta
forma, la plataforma BESA-ME será la base de futuras aplicaciones tanto para SIRP como para
aquellos estudiantes que deseen enfocar el desarrollo de sus proyectos por medio de sistemas
Multi-Agente.
20 MICROCHIP, PIC18FXX2 Data Sheet, Microchip Technology Inc 2002. 21 MICROCHIP, PIC18F6520/8520/6620/8620/6720/8720 Data Sheet, Microchip Technology Inc 2002. 22 SIRP, Sistemas inteligentes, Robótica y Percepción. Grupo de Investigación de la Facultad de Ingeniería
Electrónica, Pontifica Universidad Javeriana.
25
3.2.3. Apropiación del RTOS
FreeRTOSTM presenta tres programas de demostración que son descargados junto con el sistema
operativo. Cada uno de estos demos presenta características distintas con el fin de que el
usuario se acomode a distintos aspectos del sistema. El circuito inicial creado para la realización
de las pruebas se basó completamente en las necesidades de dichos demos.
Gestión de Memoria
FreeRTOSTM presenta tres esquemas para el manejo de memoria. La asignación estática de
espacios de memoria se presenta como opción para sistemas en la cuales no se creará ni se
eliminarán dinámicamente tareas, colas o semáforos; de tal forma que esta distribución se
realiza sólo una vez en el sistema. El segundo esquema de planeación, asigna espacios de
memoria que luego podrán ser liberados, sin embargo puede llegar a se ineficiente en su
funcionamiento, si los tamaños asignados en la creación de diversas variables son distintos,
presentando indeseablemente segmentación de memoria. Y por último, el tercer esquema
maneja dinámicamente la asignación de la memoria RAM, pero se sugiere que sea utilizado
aplicaciones con computadores de escritorio, ya que requiere de mucho más procesamiento.
BESA-ME utilizará entonces el primer modelo de manejo de memoria, ya que no requiere la
liberación dinámica de espacios, puesto que las tareas creadas inicialmente, no serán destruidas
nunca. Además es el esquema de más fácil aplicación, y el que mejor se desempeña en
dispositivos microcontroladores.
Pruebas Realizadas
Luego de confirmar el correcto funcionamiento del RTOS, se procedió a realizar la primera
aproximación de las tareas necesarias para la implementación de los requerimientos de BESA.
Para esto se realizaron las siguientes pruebas:
1. Una tarea envía a otra un dato, éste dato es puesto en una cola compartida de tamaño
1. La tarea que envía el dato (productora) se duerme durante un tiempo prudencial
para poder apreciar fácilmente el suceso (aproximadamente 500ms). Cuando la tarea
consumidora recibe el dato, lo muestra en el respectivo LED del puerto B, configurado
como salida. Cuando el productor se despierta, incrementa el valor anterior, y manda un
nuevo dato, para que el consumidor lo muestre.
2. Ahora, aparece una tercera tarea que envía con una frecuencia menor, a la misma cola
un dato negativo, de tal forma que cada vez que llega un dato el consumidor
decrementa en uno el orden de muestra de los LEDs. En esta segunda prueba, las
tareas funcionan perfectamente, no se pierden datos ni se alteran los mismos.
26
3. En la tercera prueba, una cuarta tarea aparece como productora, introduciendo un valor
constante de 2 que se suma al valor acumulado, dando la apariencia de un salto en la
secuencia de los LED. En esta última prueba todos los productores presentan la misma
prioridad, y el consumidor tiene una prioridad de cero. Con estas características, el
sistema no funciona correctamente, se pierden datos. Sin embargo aumentando el
tamaño de la cola N (N = Número de productores), el sistema regresa a la normalidad.
Cuando el consumidor tiene mayor prioridad, ningún dato se pierde, aun cuando la cola
sea de tamaño unitario.
Una vez identificadas a plenitud las características de los métodos de envió y recepción de
mensajes por medio de colas, la creación y bloqueo de tareas con las primitivas del RTOS, se
procedió a la construcción del modelo abstracto de BESA.
3.3. Construcción del Modelo BESA-ME
Diseñado para ser implementado en un microcontrolador, en el modelo BESA-ME se modificaron
algunos servicios originales del modelo abstracto planteado por BESA, con el objetivo de ahorrar
memoria y mejorar velocidad de respuesta, pero conservando siempre la esencia de la
arquitectura.
3.3.1. Descripción General
Dentro de las características que fueron modificadas se encuentran las condiciones booleanas,
que se presentan en el mecanismo selector de guardas. Las condiciones booleanas ya no se
verificarán para la activación de los comportamientos asociados. Para éste proyecto, no son de
vital importancia. Su ausencia permitirá la reducción de gran parte el tiempo de filtrado de los
eventos en los puertos, y la minimización del uso de memoria para la ubicación de los eventos
que llegan a los puertos.
Igualmente el servicio de directorio de agentes, fue simplificado eliminando la sección de
páginas amarillas. En consecuencia, el usuario puede hacer envíos a un agente sólo si conoce el
nombre del agente, el cual es llamado alias en el contexto BESA-ME.
Los eventos recibidos por un agente, son almacenados directamente en una cola FIFO (tipo
buzón) de eventos entrantes, propia del canal de cada agente. Se decidió recibir estos eventos
por recopia y no por apuntador para garantizar la seguridad de la información pero en
detrimento de la velocidad de respuesta a los eventos. Estos eventos son ubicados en los
puertos correspondientes según el tipo de evento al que pertenezca. Existen tantos puertos
como tipos de eventos declarados inicialmente. Cuando un evento llega a un puerto, se crea un
27
mensaje especial para ser enviado a los correspondientes comportamientos. Éste mensaje
contiene el apuntador a la función que se debe ejecutar, y el dato proveniente del evento BESA
inicial. Cuando el mensaje llega a la cola de recepción del comportamiento, éste se desbloquea,
e invoca a la función correspondiente mandándole como parámetro el dato asociado a evento
BESA. Esta función asociada, es la que el usuario final podrá programar directamente. En las
funciones asociadas también se pueden presentar envíos de datos a otros agentes, ya sean del
mismo contenedor o de otro.
En el modelo abstracto de BESA, a nivel social, existen agentes mediadores que pueden servir
como despachadores de eventos entrantes al contenedor, para distribuirlo a los agentes
destinatarios. Un agente mediador puede servir también para manejar mecanismos de
cooperación y asignación de tareas.
Sin embargo, el modelo de implementación BESA – ME no contiene en su sistema agentes
mediadores ya que la distribución de eventos, se realiza directamente a través del servicio de
envíos dentro del contenedor cuando son originados por otro agente, o desde una tarea
adaptador, encargada de recibir los eventos desde otro contenedor o desde las rutinas de
interrupción del microcontrolador, con el objetivo de repartirlos adecuadamente. Por tal razón en
lugar del nivel social, en BESA-ME hablaremos de nivel sistema.
Otra característica importante es que, tras analizar el concepto de contenedor de BESA, como el
espacio donde habitan y cumplen sus ciclos de vida los agentes, hemos decidido abstraer cada
microcontrolador como un contenedor. El contenedor debe ser visto como el medio de
interacción local de los agentes.
Las estructuras y funciones de cada uno de los componentes del sistema BESA-ME se describirán
a continuación separadas en dos niveles: El nivel agente en el cual no existe el contenedor y el
nivel sistema donde inician las interacciones entre agentes.
3.3.2. Nivel Agente
La implementación del modelo de agente BESA-ME, requiere de mínimo dos tareas para cumplir
con el modelo BESA, estas son: la tarea encargada de cumplir las funcionalidades del canal y la
que ejecuta cada comportamiento. En el caso más sencillo de agente se debe tener mínimo un
comportamiento. Además, ligados a la creación del agente, deben existir mecanismos de
identificación para ser usados por las tareas canal y comportamiento.
Estas tareas son re-entrantes, en consecuencia, el mismo código es usado cada vez que se crea
un agente o un comportamiento adicional, lo cual reduce la cantidad de memoria de programa
28
usada al escalar el sistema. En la Figura 3 se muestra la estructura implementada del agente,
que se explica a continuación.
Behavior_1
Behavior_2
Guard_1
Guard_X
Port_
1
Guard_1
Guard_Z
Port_
M
Guard_2
Guard_1
Guard_Y
Por
t_2 Guard_2
Guard_2
Events
AGENT
Estado
Buzón
CHANNEL
Beh_1
Beh_2
Beh_N
Behavior_N
Action_1
Action_2
Action_N
Figura 3. Modelo de Agente en BESA-ME
Estructuras Asociadas a la Identificación del Agente
El agente esta constituido por sus dos tareas básicas (Canal y Comportamiento) y por dos
estructuras que permiten que el agente acceda a la información del sistema y que el sistema
obtenga información de él, estas estructuras son:
Figura 4. Estructuras asociadas al Agente
Estructura Agente (stAgentBESA): Contiene datos como el estado del agente, el apuntador a la
estructura del canal asociado a dicho agente, una lista de los comportamientos que se
29
encuentran asociados a dicho agente, y por último una estructura stAgentHandler que contiene a
su vez el Alias y el AgentID, el cual para el caso de BESA-ME no es usado, ya que basta con el
Alias para identificar al agente, sin embargo éste se deja allí para futuras aplicaciones. También
está contenido aquí el apuntador a la cola de recepción del canal para la recepción de eventos.
Podemos ver entonces que con el conocimiento del Alias, se puede acceder a toda la información
relacionada con el agente. En la Figura 4 se observa el código con el que fue implementada.
Construcción del Canal
El canal es el encargado de recibir los eventos provenientes del entorno o de otros agentes, para
luego asociarlos al puerto correspondiente, de esta forma el dato es enviado a los
comportamientos indicados por la guarda asociada al puerto. Para esto, el canal debe contar,
como mínimo, con un buzón de entrada (cola de recepción), un puerto por cada tipo de evento y
una guarda que asocie el evento a un comportamiento.
Estructura Canal (stChannelBESA): Contiene un apuntador a la cola de recepción del canal
(xQueueRxChannel), un arreglo de apuntadores a los diferentes puertos que lo comprenden
(apChannelPorts) y una variable para indicar el número de puertos (número de eventos) que
tiene el canal (NumPortChannel). En la Figura 5 se observa el código con el que fue
implementada.
Figura 5. Estructura asociada al canal.
El tamaño del arreglo de apuntadores está definido por el máximo número de puertos que el
usuario haya establecido para el canal. Nótese que no se maneja un sistema de colas de
almacenamiento de eventos retenidos, debido a que no se implementaron las condiciones
booleanas de las guardas.
Estructura Puerto: (stPortBESA) Cada puerto contiene una constante que indica el tipo de evento
al que corresponde (xEventType), una variable que indica el número de asociaciones definidas
para el tipo de evento (NumBindGuards) y un arreglo de apuntadores a guardas que contienen
la información necesaria de cada asociación del puerto (apBindGuard).
Estructura Guarda: (stGuardBESA) Tiene un apuntador a la función de tratamiento asociada al
tipo de evento que debe ejecutarse en el comportamiento (*ActionFunction) y un apuntador a la
30
cola de recepción del comportamiento asociado (xQueueRxBehavior). En la Figura 6 se observa
el código con el que fue implementada la guarda BESA y el puerto BESA.
Figura 6. Estructura asociada a los Puerto y a las Guardas.
Estructura Mensaje para el Comportamiento: (stMsgBehavior) Tiene un apuntador a los datos
que se envían en el evento (pEventData) y un apuntador a la función de tratamiento asociada al
tipo de evento (*ActionFunction) que debe ejecutarse en el comportamiento. De esta forma el
usuario sólo tendrá que realizar la programación correspondiente a las funciones asociadas, con
los datos entrantes al agente. En la Figura 7 se observa el código con el que fue implementado
el tipo Mensaje a comportamiento.
Figura 7. Estructura del Mensaje recibido por el Comportamiento.
Para la ejecución del canal se creó una tarea a partir de los servicios del RTOS, la tarea asociada
al canal se denomina vChannel. Esta es la encarga de revisar constantemente el buzón de
entrada de mensajes para saber si ha recibido un evento; si no hay un evento pendiente en la
cola, esta tarea se bloquea hasta que alguno llegue. Cuando se recibe un evento, la tarea debe
verificar el tipo de evento y compararlo con los puertos existentes; si no existe un puerto para
este tipo de evento el canal no ejecuta ninguna operación y el evento es ignorado; informándole
además al transmisor inicial que el evento no pertenece al sistema. Al identificar el puerto
correspondiente, se evalúa el número de asociaciones existentes, para la correcta ubicación del
evento y se accede a las guardas para crear el mensaje y enviarlo al comportamiento indicado
por la guarda.
La tarea vChannel recibe como parámetro el apuntador a la estructura del canal pChannel, para
así poder tener acceso a las demás estructuras. Dentro de esta tarea se crea el mensaje que se
31
envía al comportamiento, como se muestra a continuación en pseudo código de la tarea
vChannel:
void vChannel (void *pvParameters)
{
Creación de los apuntadores a las estructuras stPort, stGuard, stChannel, stEvent y stMsgBehavior;
Asignación de los apuntadores a las estructuras creadas.
for( infinito )
{
if ( hay algún evento nuevo en la cola de recepción del canal? )
{
for ( Se recorre cada uno de los puertos del arreglo de puertos )
{
If ( el tipo de evento recibido es igual al tipo de evento del puerto actual?)
{
For ( Recorrer el arreglo de guardas para el puerto actual )
{
Armar el mensaje para el comportamiento indicado en la guarda;
Enviar el apuntador del mensaje a la cola de recepción del comportamiento indicado por
la guarda actual;
if ( envió no exitoso )
{ intentar de nuevo el envío; }
}
}else
{
Aumentar la posición del apuntador para cambiar de posición en el arreglo de puertos;
}
}
}
}
Construcción del Comportamiento
El comportamiento es el encargado de recibir los mensajes que contienen el dato y el apuntador
a la función de tratamiento que haya sido determinada por el usuario para el tipo de evento.
Debe tener entonces una cola de recepción para almacenar los mensajes. Además es necesario
acceder al estado del agente para obtener información del estado y poder modificarlo.
La estructura asociada al Comportamiento es:
Estructura Comportamiento: Tiene un apuntador a la cola de recepción del comportamiento
(xQueueRxBehavior) y un apuntador al “Handler” del Agente (pAgentHandler) que permite
acceder a su estructura y por ende al estado del agente. La estructura de los comportamientos
se muestra en la figura 8.
32
Figura 8. Estructura asociada al Comportamiento.
Para la ejecución del comportamiento se creó una tarea a partir de los servicios del RTOS, la
tarea asociada al comportamiento se llama vBehavior. Es la encargada de revisar
constantemente su cola de recepción para verificar la llegada de mensajes. Cuando llega un
mensaje, el comportamiento debe propiciar la ejecución de la función de tratamiento, la cual
debe recibir como entrada el apuntador al evento BESA que fue enviado en el mensaje y un
apuntador al Agente al cual pertenece el comportamiento, a través del cual puede acceder al
estado, si así lo requiere el usuario. A continuación se presenta el pseudo código de vBehavior:
void vBehavior ( void *pvParameters )
{
Creación de las las variables tipo stBehaviorBESA y stMsgBehavior;
Creación y asignación de los apuntadores a las estructuras creadas;
for ( infinito )
{
if ( llegó algún evento a la cola de recepción del comportamiento )
{
Se invoca la función de acción según lo indica el apuntador en el mensaje que
acaba de llegar y se le mandan los datos recibidos;
}
}
}
El Estado
El estado es un espacio de memoria compartida que sólo debe ser accedido desde las acciones
ligadas a los comportamientos. A través del estado los comportamientos pueden actualizar
información relativa al agente y a los procesos que éste ejecuta.
Su implementación se realizó a través de una cola con capacidad para almacenar una apuntador
de tipo void. Se crearon las funciones TakeStateData y GiveStateData para permitir al usuario
modificar el estado en una forma segura. Su uso se explica en el manual del usuario que se
encuentra en el anexo A.
33
Simulación del Envío de un Evento al Canal y Ejecución de sus Comportamientos
Para verificar el correcto funcionamiento de la estructura de un agente, antes de expandir el
modelo a más agentes y distintos contenedores, se realizó una prueba creando una tarea
adicional para enviar eventos al canal.
La tarea adicional llamada vPrueba envía al buzón del canal un determinado evento,
bloqueándose luego de esto por un tiempo determinado; luego se despierta para repetir el
envío. El canal recibe el evento, busca el puerto correspondiente y allí verifica la guarda para
crear el mensaje y enviarlo al comportamiento adecuado. Una vez el mensaje llega al buzón del
comportamiento, éste lo recibe y llama la función de tratamiento asociada para ejecutarla.
El correcto funcionamiento de está primera aproximación del agente se observó a través de la
ejecución de la función asociada, la cual conmutaba unos LED de acuerdo al dato recibido.
Luego de observar el correcto desempeño del agente, se procede a aumentar el número de
comportamientos asociados a un mismo tipo de evento. Prueba que arrojó resultados positivos
observando la conmutación correspondiente de los LED; la última fase de estas primeras
aproximaciones acerca de la configuración de un agente se basaron en la creación de distintos
tipos de eventos enviados a un mismo agente, el cual activa a su vez, luego del tratamiento
propio de cada entidad, los comportamientos asociados con sus respectivas funciones.
3.3.3. Nivel Sistema
Una vez la estructura de cada agente esta completa, es necesario establecer el nivel superior del
sistema BESA, es decir, el conjunto de varios agentes funcionando en el contexto de un
contenedor.
34
ActuadorSensor
Agentes
BUS SERIAL I2C
Contenedor A
Páginas Blancas
Administrador Local
ActuadorSensor
Agentes
Contenedor B
Páginas Blancas
Administrador Local
ActuadorSensor
Agentes
Contenedor C
Páginas Blancas
Administrador Local
ActuadorSensor
Agentes
BUS SERIAL I2C
Contenedor A
Páginas Blancas
Administrador Local
ActuadorSensor
Agentes
Contenedor B
Páginas Blancas
Administrador Local
ActuadorSensor
Agentes
Contenedor C
Páginas Blancas
Administrador Local
Figura 9. Nivel Sistema en BESA-ME con el servicio de comunicación entre contenedores. El administrador
local se encarga del manejo de los eventos.
Un sistema de agentes implementado en BESA–ME se considera como un sistema distribuido
compuesto por uno o varios contenedores BESA, los cuales funcionan en diversas máquinas
físicas o virtuales, en este caso, cada contenedor esta ubicado en un microcontrolador
(contenedor físico).
La integración de mas de un contenedor y la posibilidad de comunicación entre los agentes
pertenecientes a éstos a través del protocolo serial I2C, completa el modelo BESA-Micro Edition
a nivel de sistema distribuido. En la figura 9 se observa una representación gráfica del modelo
implementado.
Creación del Contenedor
BESA-ME tiene estipulado, en su modelo de implementación, que cada contenedor esta
contenido en un microcontrolador, el cual para efectos de la comunicación necesitará un número
de identificación fijo, el cual está estipulado por una constante denominada CONTAINER_ID a la
cual se le deben asignar valores desde 01H hasta 80H, para un máximo de 127 contenedores.
El CONTAINER_ID es asignado por el usuario.
35
Figura 10. Estructura asociada Contenedor.
Cada contenedor contiene una estructura necesaria para almacenar la información de los
agentes internos y los de otros contenedores, tal como se muestra en la Figura 10 (directorio de
páginas blancas de los agentes de todo el sistema). Además contendrá dos buffers para
almacenar temporalmente los datos entrantes y salientes de la comunicación entre distintos
contenedores. Esta utilización de espacios de memoria compartida (buffers, ver Figura 11) hace
necesario el uso de sistemas de sincronización que permitan el manejo seguro de estos espacios
de memoria. Se utilizan entonces dos semáforos propios de los servicios de freeRTOSTM, los
cuales serán explicados en la sección de comunicación entre contenedores.
Figura 11. Estructura de los buffer de Transmisión y de Recepción para la comunicación entre contenedores.
El contenedor también contiene dos colas de recepción para manejar la información proveniente
de otros contenedores. Estas colas permiten un manejo seguro del protocolo de comunicación
entre contenedores. Hay otra cola más para la recepción de eventos BESA desde una rutina de
interrupción.
Los Eventos BESA en BESA-ME han sido implementados de tal forma que el usuario
