BESA-ME: Framework for Robotic
MultiAgent System Design
David M. Flórez, Guillermo A. Rodríguez, Juan M. Ortiz and Enrique González
SIDRe Research Group, Pontificia Universidad Javeriana, Bogotá, Colombia
Abstract. BESA-ME is a software middleware designed to make easier and to
improve the construction of robotic control systems based on multi-agent
techniques. BESA is a behavior-oriented, event-driven and social-based general
purpose architecture designed to build concurrent applications using the multi-
agent paradigm. The BESA abstract model incorporates the concept of behavior
and the management of asynchronous events, which are very useful in the
construction of robotic systems, thus it allows to design robot control
architectures in a natural and direct fashion. BESA-ME, micro-edition, is the
adapted BESA model that is well suited to be implemented over
microcontrollers in embedded systems. Initially, it has been developed for the
PIC18F chip family, and then adapted for dsPIC60F chip family, both under the
real time operating system FreeRTOS ™.
1 Introduction
When dealing with the construction of complex systems, a design methodology
usually includes splitting the system in a set of smaller simple tasks. This approach
allows dealing with complexity and makes possible to improve the efficiency of the
system implementation by distributing the execution of these tasks on a set of
processing units. The agent paradigm provides a conceptual framework where
systems can be analyzed and synthesized as a collection of interacting entities, using a
high level abstraction, which fits in a natural fashion with the implicit concurrent
requirements of robotic systems.
The development of new products implies the incorporation of innovative and
more complex functionalities. The actual tendency of the technology used to improve
the system efficiency is to construct multi-processor, multi-core or multi-thread
machines [1]. This approach has the advantage of being easily scalable; however, in
this case it is necessary to include specialized mechanisms to solve synchronization
and communication problems. In addition to the high computational power
requirements, some applications like smart home systems [2], robotics, automation,
industrial machines and multi-robot systems [3] require that the embedded hardware
communicates frequently with external stand alone systems. As a consequence,
design of software for embedded systems must: generate modular concurrent
solutions to deal with complexity, take advantage of hardware parallelism, and be
adequate to interact in a natural fashion with external stand alone systems. It’s
M. Fl
orez D., A. Rodr
ıguez G., M. Ortiz J. and Gonz
alez E. (2007).
BESA-ME: Framework for Robotic MultiAgent System Design.
In Proceedings of the 3rd International Workshop on Multi-Agent Robotic Systems, pages 64-73
requirements to have models and platforms that ease the system design, taking
advantage of the parallel processing capabilities of the actual and future processors.
In the context of robotic systems, the design problems previously introduced are
amplified due to the fact that robots must be able to evolve in a not completely
observable environment under real time constrains. In order to deal with these critical
conditions, the designer must also take into account the following issues:
manage complex synchronization of non-deterministic events coming from
sensors and controlled actuators.
distribute the application into several processes, using communication taking
advantage of the parallel and specialized hardware.
use an unified model in both the embedded and the external components of
the system.
use of a holistic approach where the robot control unit is modeled as a unique
composed system; the system is seen as a collection of logical units, which
can be physically deployed in the available hardware (embedded or not).
The actual software tools to model, design and implement embedded distributed
and real-time systems covers different needs. Real Time Operating Systems (RTOS)
are used for the implementation of systems with time-response constraints [9]. For
instance, TURTLE [6] offers an environment based on the Unified Modeling
Language (UML) for the formal model [7]. Another interesting approach uses the
synchronous language LUSTRE, designed for the development of critical control
software [8]. These approaches are process oriented, where the basic processing units
are processes or tasks that usually communicate by message passing mechanisms.
Even if the conceptual model provided by the notion of process is very useful, general
and flexible, it has a low level of abstraction, which makes it difficult to be used in the
design of complex systems. For instance, when designing a robot or multi-robot
system, it would be preferable to use a conceptual model with higher degree of
abstraction, where notions as behaviors and goal-oriented entities could be modeled in
a more direct way.
A well suited approach to model complex problems is the Multi-Agent System
(MAS) paradigm. Different activities can be distributed into several cooperative
autonomous entities, and interactions are the basis for the dynamics of the system.
Agents respond to events coming from its environment or derived from its
interactions with other agents. The communication is the basis to construct the social
level which emerges from the inter-agent interaction [10]. A MultiAgent System,
MAS, is a computational cooperative system capable of executing concurrent tasks
through its agents.
BESA is a MAS architecture [5] [17] that aims to solve the problems that where
depicted in the precedent paragraphs. BESA provides an abstract model to construct
multi-agent systems. The initial implementation of the BESA model was developed to
work in a Java distributed environment. The BESA micro-edition, BESA-ME, is
introduced in this paper. The BESA-ME model, architecture and implementation have
been developed for embedded systems using RTOS as software support, running in
microcontrollers and DSP hardware platforms. This development is mainly motivated
to deal with the requirements involved in the design of multirobot systems, where a
recursive organizational approach is applied.
In this paper the BESA-ME conceptual model and architecture are explained.
Then, the RTOS software and hardware considerations are analyzed in order to adjust
the model to fit the constraints of a practical embedded application. Finally, the
implementation strategy is depicted and the obtained results are analyzed.
2 BESA Architecture
The BESA architecture defines a conceptual model for the implementation of an
agent framework. The construction of a complex and concurrent application must use
this agent conceptual abstraction to model the system. Then the implementation of the
system can be performed in a direct fashion exploiting the facilities provided by the
BESA application framework.
2.1 Abstract Model
The BESA abstract model is supported by three principal concepts, which provide a
theoretical frame that integrates a behavior-oriented, event-driven and social based
approach in a coherent structure.
Behavior-oriented: agents are composed by a collection of behaviors, simple
entities charged of the treatment of a set of related events.
Event-driven: asynchronous events unleash the behavior execution. They
represent signals that could be perceived by the agents. The behavior
execution is controlled determined by a guard based selector mechanism;
guards forbid events to be processed if a desired condition is not attained.
Social-based: the multi-agent system is created to form a social organization,
where well-known communication patterns can be used; it is also possible to
utilize mediator agents that help in the correct development of interaction
protocols between agents.
BESA is a concurrent oriented architecture; agents are internally seen as a
multithread system and the non-determinism, implicit in an event driven system, is
managed by a select (alting) mechanism.
2.2 Agent Level
The agents give a response to events coming from the environment or from other
agents. BESA events have a specific semantics and are marked with an event type
label. The agent has an associated treatment for each type of event. The treatment of
an event must include the rational response of the agent. When processing an event,
the data attached to the event and the internal state must be taken into account. The
response to an event can be produced by any kind of decision mechanism (neural
networks, fuzzy logic, procedural code, rule based system, etc.). This response can
include: the selection of the appropriated actions that must be executed, sending a
new event to other agents, and the modification of the internal state of the agent.
Events exchanged between agents usually follow well-defined communication
patterns, known as interaction protocols.
A BESA agent is structured with three main components: the channel, a set of
behaviors and the agent state. Figure 1 shows these components and the way they are
connected. The channel manages a mailbox where events are received, providing the
unique entry point to the agent. The received events are assigned to different ports
depending on their event type. Finally, they are transferred to the correct behavior, if
the guard condition is verified.
The behavior is an execution space that is activated when an associated event is
received. Then the corresponding treatment is executed, thus producing the rational
response to the received event. An agent can have several concurrent behaviors, thus
allowing to process several events at the same time. Notice that the way that the
parallel execution is performed depends on the capabilities of the executing
environment (hardware and software). Incoming events are received by the channel
and transferred to a queue in the appropriated behavior; events received by the same
behavior are processed in a sequential order. A guard verifying function and a
treatment function are associated to each type of event.
The agent state provides a mechanism to store information about the agent, the
environment, other agents and the global system; it is used to keep data in a persistent
way. This information usually is used in the treatment of events. The state is a
structured shared memory; thus, the concurrent access to this space must be
synchronized. The synchronization could be implemented with semaphores or other
operating system mechanisms.
2.3 Social Level
The social level aims to provide a set of predefined mechanisms and interaction
protocols that could be directly used to manage agent interaction. Some of the BESA
cooperation and communication services provide specialized ready to use agents that
act as mediators in the social organization. For instance, the group communication
service uses a mediator agent, actuating as a router, distributing events in the same
order to all the agents subscribed to the group. A more detailed presentation of the
social level is out of the scope of this paper. In [17], there is a more detailed
description of this level.
Fig. 1. Internal structure of a BESA Agent.
Fig. 2. BESA System Layer Model.
2.4 System Level
The system level is formed by a set of agent containers running in physical or virtual
machines. The container can be seen as the execution space for the agents (Figure 2).
A BESA container has a local manager in charge of handling the agent’s life cycle
and the directory services. The container also assures the correct communication
between agents “living” in different containers. The system level is designed to
comply with the FIPA standard [11]. The inter-agent interaction in the same container
is performed without the local manager intervention.
In order to make easy the communication between agents, BESA includes a
directory service. The white pages component allows to locate agents by an ID. The
yellow pages component makes possible to locate a group of agents that can provide a
specific service.
The goal of the BESA-ME design is to find how to implement the BESA model in an
embedded system, taking into account the BESA requirements and the constraints of
this kind of platforms.
The more important operating requirements of a BESA
framework are: the management of the shared resources and shared memory spaces,
and the multi-task operation and the concurrent treatment of events.
Real time operating systems are the proper tool to provide the services required to
implement BESA-ME. In particular, the communication and synchronization of the
agent behaviors requires semaphores and messages queues with blocking sending.
The concurrent operation of agents and their behaviors can be achieved by a multitask
preemptive operating system kernel. As BESA-ME is a framework for the
construction of embedded applications, usually implemented in micro- controllers and
DSPs, it is convenient to use a Real Time Operating System (RTOS) to provide the
required functionalities [5]. A BESA-ME application can be seen as a layered
structure, as shown in Figure 3. Upper layers use the abstraction and services
provided by the lower layers. The user application is designed using the abstraction of
the BESA abstract model. The BESA-ME components are implemented as concurrent
tasks using the inter-task communication mechanisms provided by the RTOS.
Finally, it is essential to adjust the BESA general model in order to fit the
constraints of a practical embedded application. In the BESA-ME implementation
model, some BESA elements are excluded in order to improve the performance and
reduce the amount of required memory. The conditions of the guard selector
mechanism are eliminated, thus reducing the control of the non-determinism implicit
in an event driven system, but improving the filtering speed of events in the channel
and allocating more memory to store events in the ports. In the container only the
white pages directory is used, so the agents can locate an agent if they know its
Fig. 3. Layers in a BESA-ME application.
4 Implementation
BESA-ME has been successfully implemented for the microcontroller family PIC18F
and the DSP dsPIC60F. The available RTOS that were selected as candidates to
support the BESA-ME implementation include the Salvo-RTOS [12], the µC/OS-II
[13], the CMX-TINY [14] and FreeRTOS [15]. Though several of the studied RTOS
were offered the required services, after a detailed analysis of their functionalities, the
FreeRTOS™ was selected. It was chosen because it’s a RTOS with a GNU license, it
is well-structured and easy to use; it also supports many microprocessors, micro-
controllers and DSPs.
4.1 Agent Level
The BESA agent is modeled by a data structure called stAgentBESA. It contains
pointers to the agent shared state and channel, an array of pointers to the behaviors
associated to the agent and the agent handler that contains the alias and the agent id.
Fig. 4. BESA-ME agent level model. The boxes represent the data structures of the agent.
The Channel Task
The Channel Task has been implemented as a RTOS task, which is blocked waiting
for incoming events. This waiting mechanism is implemented using a RTOS message
queue service. When an event is received in the Channel Reception Queue this task
looks for the incoming event type and compares it with the defined registered ports; if
a match was found, the channel task sends a message to the behaviors interested in
this event type. The same code is used to implement and create the required channel
instances thanks to the parametric data structure used to represent an agent. When an
agent is built, a channel task is created. A similar approach is used for the behaviors
tasks. The channel parameters are contained in a data structure that includes a pointer
to the channel reception queue, an array of pointers to the channel ports and some
control variables.
The Behavior Task
The behaviors have been implemented as RTOS tasks, which are blocked waiting for
messages sent from the channel. The messages contain the event attached data and a
pointer to the adequate treatment function. The association between event types and
their treatment functions is defined when the guards are created and bind to ports.
When a message is received, the adequate treatment function is executed; it
receives the event data and a pointer to the agent state. The state is a shared memory
that has a read/write protection mechanism built with a binary semaphore. In the
treatment function the microcontroller peripherals are used, mathematic operations
are performed, the external hardware is controlled, events to other agents are sent, and
the logic that implements the rationality of the agent is included.
4.2 System Level
An agent system, implemented using BESA-ME is a distributed system composed by
one or more BESA containers running in one ore more physical or virtual machines
(Figure 5). In BESA-ME, there is only one container running in each processing
device (microcontroller or DSP). Each container has a unique ID registered in the
white pages directory. When a send event service is invoked, a search for the address
of the agent is performed. If the destination agent exists in the local container, the
event is directly sent to the appropriated message queue. If the destination is not local,
the event is sent to the other registered containers; only the container where the
receiver agents exist takes into account the event and transfers it to the appropriated
Fig. 5. BESA-ME System Layer
Fig. 6. Percentage of events received successfully by an
external agent.
In the actual implementation of BESA-ME, the communication between containers
is achieved through the use of a wired bus and the I2C low level communication
protocol. The I2C protocol has been implemented in an interrupt service routine. The
BESA-ME communication process is controlled with the I2C control bits at the
physical layer and a BESA acknowledge to inform if the event has been taken
properly by the destination agent. The information required to construct event and
acknowledgment packets is written in a transmit buffer protected by a binary
semaphore. The semaphore is free when the whole message has been send. Another
semaphore prevents that one other local agent start an external communication before
the reception of a pending acknowledgment packet.
5 Experimental Results
In order to verify that the BESA-ME execution is correct, a test protocol has been
designed. The controlled independent variables include the task’s stack size, the
number of BESA-ME elements (agents, behaviors, guards) and the event production
frequency. The measured dependent variables include the response time of the system
to extern and local events, the number of errors in the inter-agents communication,
and the evaluation of the general performance of the system.
The functional test was implemented in a couple of interconnected
microcontrollers PIC18F8720 and PIC18F8620, with a processor frequency of 4 MHz
and the I2C communication frequency of 100 KHz. This value of the intervenient
variables were found by gradual increments. In the agent level the maximum number
of behaviors is 11, with only one agent in the container. For one behavior the
maximum number of guards is 20, with only one port (one event type). The maximum
number of ports is 50. In the system level the maximum number of agents per
container is 5. An extensive communication test was applied to the BESA-ME system
level [16]. In summary, the results include the response time to events and the errors
rate, in local and extern communication. In figure 6 can be observed how the event
frequency affects the communication between agents placed in different containers.
The AgentCoop project aims to build a multirobot platform. This multirobot
system is controlled using the MRCC model (MultiResolution Cooperation Control),
which provides a flexible framework to built cooperative multiagent systems. In order
to deal with the complexity of this application, the AgentCoop architecture has been
designed using the BESA conceptual model. The robotic system is composed by a set
of agents that can be deployed in a distributed environment, where high performance
stand alone computers coexist with embedded processors The design of the
AgentCoop platform represents a complex problem with the characteristics previously
analyzed in section 1. The robots of the AgentCoop project are controlled using the
dsPIC30F6012. Thus, BESA-ME has been easily migrated to work with this platform,
proving the flexibility and modularity of the actual BESA-ME framework.
6 Conclusions
BESA-ME is a useful tool to solve complex problems in embedded applications. It
allows to split complex objectives into simpler tasks, and to allocate them to
dedicated agents. BESA-ME solve the low level synchronization problems, providing
a high level abstraction model to make a more easy design and implementation of
system. The use of the BESA-ME model allow the development of MAS oriented
distributed applications for microcontrollers in a easy and efficient way, reducing the
development time.
One of the more important BESA-ME facilities is the flexibility; if a system could
not be fitted in only one microcontroller it can be distributed in two ore more
processors only by changing configuration and declaration parameters of the
middleware. The required external communication between micro-controllers is
automatically detected and managed by the BESA-ME communication services.
A comparative evaluation of BESA-ME is projected. This evaluation will be
implemented comparing the AgentCoop development model for BESA-ME and the
implementation model if using only an RTOS without BESA-ME.
1. INTEL Corporation. “Intel® Dual-Core Processors: The first step in the multi-core
revolution”, January 15th 2007.
2. SMARTHOME. “Getting Started”, January 13th
3. The Robotics Institute. “Distributed Robots Architecture”, Carnegie Mellon University. January 12th 2007.
4. Liu, Jiming. “Multi – Agent Robotic Systems”. CRC Press, Boca Ratón, Fl. 2001.
5. Gonzalez Enrique, Avila Jamir, Bustacara César. "BESA: Behavior-Oriented, Event-Driven
And Social-Based Agent Framework". PDPTA'03, Las Vegas-Usa, Csrea Press, Vol. 3,
Junio 2003, PP 1033-1039. ISBN 1-892512-43-2.
6. P.De Saqui SanneS. “Conception basée modèle des systèmes temps réel et distributes”,
Rapport Laas No05403, Toulouse, France. 7 Juillet 2005.
7. Roques, Pascal, “UML en action”. Editions Eyrolles, France. June 2004.
8. Verimag. “Synchrone”, October 2006.
9. Stallings, William. “Operating Systems: Internals and Design Principles“. Prentice Hall.
USA. 2001.
10. Weiss, Gerhard. “Multiagent systems: A modern approach to Distributed Artificial
Intelligence”. MIT Press, U.S.A 1999.
11. Foundation for Intelligent Physical Agents. “FIPA Specifications”,,
November 5th 2004.
12. PUMPKIN INC. “Salvo User Manual”,, October 23rd 2004.
13. MICRIUM. “µC/OS-II Kernel Benefits”,, November 18
14. CMX Systems. “TINY PLUS Real-Time Multi-Tasking Operating System for
Microprocessors and icrocomputers”, November 18
15. Barry, Richard. “FreeRTOS”,, November 2004 – November 2006.
16. Florez, David, Rodrigez, Guillermo, Ortiz Juan. “BESA-ME: Arquitectura de sistemas
multi-agente para microcontroladores”. Pontificia Universidad Javeriana. Bogotá,
Colombia. 2005.
17. Gonzalez Enrique, Bustacara César, Avila Jamir,. "Agents For Concurrent Programming".
CPA 2003, Enschende-Holanda, IOS PRESS, Septiembre 2003, PP 157-166. ISBN 1-