Software agents and multi-agent systems are pivotal in the development of distributed autonomous systems. While various agent platforms have been proposed, only a selected few are considered state-ofthe-art. These agents exhibit a spectrum of intelligence, from reactive behaviours to advanced reasoning and planning. Integrating these capabilities within multi-agent systems enables distributed artificial intelligence, a programming paradigm where autonomous entities collaborate intelligently across a network to achieve common objectives. The advent of 5G technology is reshaping distributed systems, shifting computation towards the network's edge. This transition has led to a proliferation of embedded devices with microcontrollers, known for low power consumption and not so ample computing resources. In this context, this paradigm aligns seamlessly with small cooperating entities dispersed throughout the network. However, providing agent platforms for embedded devices is challenging. Current stateof-the-art MAS platforms, mostly Java-based, pose concerns about memory and speed overhead for microcontrollers. Addressing these challenges, we introduce DEMOCLE, a multi-agent platform for embedded systems. DEMOCLE enables logic/declarative agent programming directly in C++, utilising object orientation, macros, and recent language features like lambdas. The runtime system is lightweight, incurring minimal overhead in both time and space. This paper ofers a comprehensive overview of DEMOCLE, showcasing its features, advantages, and architecture. Additionally, it provides a practical application example.
Since a long time, software agents and multi-agent systems (MAS) have proven their efectiveness
in the development of distributed autonomous systems. A large variety of agent platforms
have been proposed for this reason, even if nowadays only a few of them are considered the
state-of-the-art [
A key aspect of software agents is their capability to exhibit a certain form of intelligence, ranging from simple reactive behaviours to more complex ones, that include activities like reasoning, planning, pattern identification, etc. Embedding these characteristic inside multi-agent systems enables the so-called distributed artificial intelligence a programming paradigm where several autonomous computing entities, spread over the network, cooperate in an intelligent way to achieve a common goal. However, the way in which distributed systems are being designed and implemented nowadays is changing drastically, above all with the introduction of the 5G technology: the trend is to move computations away from big datacenters and server farms towards the "edge" of the network in the view of splitting the complexity into several cooperating pieces running in small computing platforms placed at the edge of the network. This is the reason why the technology market is currently ofering a large number of embedded devices equipped with microcontrollers (MCU), such as Arduino, ESP32 or the STM32 NUCLEO system, that feature very low power consumption, adequate computing resources and, above all, one or more types of wireless connectivity systems (WiFi, LoRA, Bluetooth, BLE, etc.). Together with hardware devices, there is also a wide number of software platforms and libraries that allow developers to write software for such computing devices.
In this new view of distributed computing, the MAS paradigm perfectly fits the concept of
having small cooperating computing entities spread over the network, but the main problem is
the availability of agent platforms for embedded devices. Indeed, the state-of-the-art of MAS
platforms is mainly featured by Java-based tools, such as JADE [
With these concepts in mind and on the basis of the experience of our research group in the context of symbolic reasoning, we developed Democle, a multi-agent platform for embedded system able to ofer a new way to program logic/declarative agents directly in C++ using a BDI paradigm. This aim is reached by strongly exploiting object orientation, macros, together with some features of recent versions of the language, such as lambdas. The runtime system is particularly light and does not add a sensible overhead both in time and space.
The paper describes Democle, showing its features, advantages and architecture, and completing the description also with an example of its usage in a real application.
The paper is structured as follows. Section 2 deals with related work. Section 3 describes the Democle platform providing all of its features. Section 4 presents a case-study, thus showing the efectiveness of Democle. Section 5 reports our conclusions.
The survey [
We already cited JADE [
Similarly, there are many Python-based tools, such as SPADE, PROFETA [
Agent - engine: Engine - name: std::string + start(): void + run(): void
DEMOCLE - _instance: DEMOCLE - registry: [Agent] + instance(): DEMOCLE
Engine KnowledgeBase -- kabg:eKntn:oAwgleendtgeBase - beliefs : [AtomicFormula] -- ipnltaennst:io[nPsla:n[I]ntention] 1 1 ++ raestsraecrtt__bbeelliieeff((AAttoommiiccFFoorrmmuullaaff))::bbooooll + run(): void 1
0..*
Intention - plan: Plan - context: Context
Context - engine: Engine - variables: map<string, flexi_type> 1..*
Plan - event: Event - condition: Condition - body : _func
Event - evt_type: enum - bel: AtomicFormula 0..*
AtomicFormula - _type 0..1 1 - _terms: [term]
1..* 0..* term - val : flexi_type
Condition - elements: [AtomicFormula] 1 not ofer all the features of the language thus forcing the developer to patch the source code of the platform.
As for C++ based platforms, we can cite Mobile-C [
In the author’s knowledge, the only proposal for BDI programming for MCUs is
EmbeddedBDI [
Democle is a multi-agent platform to develop MASs with embedded devices exploiting the
BDI paradigm. In this sense, Democle basically uses a logic/declarative approach by ofering a
series of constructs to represent beliefs, to manipulate and query the knowledge base, and to
express reactive and proactive plans. This is achieved by providing (i) a platform to define and
implement agents together with their behaviour, and (ii) an object library and a macro package
to express agent’s behaviour by means of a declarative language. Democle can be considered
the successor of PROFETA [
In the following subsection we will describe first the software architecture of Democle and subsequently the characteristics of the language provided.
Democle is a platform organised in an object-oriented way strongly exploiting the features of the C++ language. Its object-based architecture is shown in Figure 1.
The basic entity is the Agent class which represents a single agent. Developers can subclass it to create the agents of the application and implement the behaviour by means of the specification of one or more plans using the declarative syntax. An agent is characterised by a literal name, expressed in the class’ constructor; all created agents are gathered in the singleton instance of the DEMOCLE class. Each agent, when started, runs in a thread so it’s up to the underlying executive (or operating system) the way in which concurrent execution and scheduling are performed.
An object of the Engine class is associated to each agent; this object has the task of concretely executing the plans. It has the complete knowledge of the agent’s defined plans and, by means of an infinite loop, continuously selects the appropriate plan to be executed according to the BDI paradigm. The Engine is also tied to the KnowledgeBase which acts as the repository of the beliefs of the agent and also contains the proper code to perform belief insertion/removal, belief query and belief unification.
A belief is represented as an instance of the AtomicFormula class; indeed this class is used for many others entities of Democle, as it will be detailed in the paper below, in these cases the attribute _type represent the kind of entity the object represent. Since, according to traditional declarative/logic programming, an atomic formula can have one or more paramters, that in turn can be ground terms or variables, the AtomicFormula class is designed to receive, in the constructor, a variadic number of parameters that are stored in the attribute _terms that is a vector of term objects. Indeed the term class is a wrapper that represent either a constant value or a variable that can be free or bound.
As it has been said above, the Engine object tied to an agent contains the set of the plans of the agent, represented as a vector of Plan objects. Conceptually, a Democle plan is defined according to the same principles of similar frameworks, i.e. PHIDIAS, PROFETA and AgentSpeak, and is featured by: • a plan head, that can be either an event related to the modification of the knowledge base (adding or removing a belief), or a procedure call; • a condition, that is a PROLOG-style predicate that performs a query on the knowledge base; • a plan body, that is a C++ code that is executed when the plan head matches the event/call and the related condition is true.
According to the BDI model, when an event occurs all plans whose head and condition match the event become intentions, i.e. instances of the Intention class. The diference of an Intention w.r.t. a Plan lies in the fact that the free variables of a plan become bound to the proper variable according to the event occurred and the result of the query to the knowledge base, if present; variables and associated values are stored in a Context object, therefore an Intention is mainly a container of the Plan activated and the Context that represents bound variables. When an Intention is selected for the execution, the associated plan’s body is called and the Context object is passed as parameter, so that the C++ code can receive variable values and act properly.
Writing plans in Democle implies to use a proper syntax that is C++ in its nature, but, since it uses some operators, the meaning the statements must be thought in a logic/declarative way. The syntax is derived from that of PROFETA and PHIDIAS, which, in turn, is inspired by AgentSpeak. Plans uses beliefs and variables, that, before appearing in the code, must be declared. Beliefs are declared as global symbols using the macro belief(bel_name), while variables are declared as agent-local symbols by means of the macro var(var_name). Plans are then defined in the body of the method run() of the subclass of the Agent class. We refer to Figures 2 and 3 to explain the way in which the plans of an agent can be expressed. The code shows the implementation of the case study described in Section 4; in the following we will deal with the syntax, while a comprehensive explanation of the functioning of the code is reported in the relevant section.
A reactive plan is defined by using the + or - symbol followed by the specification of a belief with zero or more ground terms or free variables. These plans are triggered by the occurrence of an assertion or retraction of the relevant belief in the knowledge base of the agent.
A proactive plan, which is something like a function or procedure, is expressed by using an atomic formula as the head with zero or more ground terms or free variables. These plans are triggered by a specific call from the body of another plan.
Both reactive and proactive plans can be defined with one or more clauses, i.e. plans with the same head or triggering event but difering in the condition part, which is a predicate made of one or more belief-checks in the knowledge base also using variables to be unified, in the PROLOG style. Condition is defined using the / symbol after the plan’s head and expressing beliefs in sequences using the connective &.
Plan’s body appears after the condition following the symbol » and is represented by a C++ functor that receives as parameter a Context object; this object can be used to retrieve the values of the variables that are bound by the Democle engine during the event/condition match.
There are two important additional features that are provided by Democle, they are sensors and agent communication.
+temperature(T,H) >> [T,H](Context & c) {
c << calc_max((float)c[T], (int)c[H]); calc_max(T,H) / (temperature(T1,H1) & gt(T1, T)) >> [T1,H1](Context & c) {
c << calc_max((float)c[T1], (int)c[H1]); calc_max(T,H) >> [T,H](Context & c) {
c + temp_max((float)c[T], (int)c[H]); class Temperature : public Agent { public:
Temperature() : Agent("temperature") {}; void run() { var(T); var(H); var(T1); var(H1); AnalogInputSampler * as = new AnalogInputSampler("A0", A0, -55.0, 150.0, 3600); attach(as); +adc("A0", T) >> [T](Context & c) { float t = c[T]; time_t raw_time; struct tm *complete_time; time(&raw_time); complete_time = localtime(&raw_time); c + temperature(t, complete_time.tm_hour); c << "risk_evaluator" << temperature(t, complete_time.tm_hour);
Sensors are objects (subclass of Sensor) that are used to make agents get data from the external world. A sensor is attached to an agent by using the statement attach(...) in the agent’s run() method, passing the Sensor object as parameter. A (subclass of) Sensor must implement the sense() method that must contain the code performing the acquisition of the data and generating, as a result, a belief asserted in the agent’s knowledge base so that a plan can be triggered.
Even if the developer can easily design her/his own sensors, Democle ofers a sensor library 1 1In the current version, the library contains few sensors but we plan to expand it during the development of the platform. mainly designed to interface the most widely used peripherals of a microcontroller, and in particular: • Timer, that generates a tick() belief2 with a given periodicity; • DigitalInputHandler, that generates a user-defined belief when a rising or falling edge is detected in a digital input pin; • AnalogInputSampler, that performs periodic sample of an ADC channel, generating the adc() belief for each sample acquired.
The other important feature of Democle is agent communication. This is performed by asserting (or retracting) a belief in the destination agent’s knowledge base. To make this possible, the receiving agent must declare the possibility of “opening” its knowledge base to external beliefs sent by other agent. This is done by using the accept(...) statement together with the specification of the belief’s name and its arity. When a message is accepted, it can be received by the agent and, in turn, can trigger a plan in order to have a specific code reacting to the message. In this case, the Context of the plan also hold the name of the sender so that the plan can also include the code to make a reply, if needed.
To show the efectiveness of Democle, we report in this section a simple case-study of a MAS for healthcare patient monitoring. In this application, we consider, as the embedded device, a ESP32 Dev-Kit, equipped with a temperature sensor, an heartbeat sensor and wireless connectivity. The framework used to program the device is PlatformIO with the Arduino libraries.
The aim of the application is to measure periodically temperature and heartbeat and, in case of a possible risk, send a proper alert message. The case-study is quite simple, but it is intended to provide a more complete as possible short overview of the various features of Democle. The code of the example is provided in the listings of Figures 2 and 3.
We consider three agents, Temperature and Heartbeat that have the task of sampling the relevant data each hour and computing the maximum value in the 24 hours. The single acquisition received by both agents is also forwarded to the RiskEvaluator agent, that checks for the risk and, if it is the case, sends an alert message. Temperature and Heartbeat agents have the same behaviour but difers in the data acquired and the beliefs manipulated, so, to avoid a long description, we limit our study to the first agent only.
As Figure 2 shows, after the includes, a Democle program requires the declaration of the concepts used, i.e. beliefs and procedures. As the figure shows, Democle provides also additional types of beliefs that are reactors and singletons that behave according to a diferent semantics: reactors are beliefs that do not populate the knowledge base but can only trigger reactive plans, so they can be used when an event occurs but does not need to store a specific knowledge; singletons are beliefs that can exist in a single instance inside the knowledge base; asserting a yet existing singleton implies to replace the old one (and trigger the plan, if present).
Then the declaration (and implementation) of the Temperature comes, as a subclass of the main Agent class. The method run() reports the complete code of the behaviour of the agent. 2Indeed it is a reactor, a special kind of belief that is described in Section 4.
+temperature(T,H) / heartbeat(V,H) >> [T, V, H](Context & c) {
c << evaluate((float)c[T], (float)c[V], (int)c[H]); +heartbeat(V,H) / temperature(T,H) >> [T, V, H](Context & c) {
c << evaluate((float)c[T], (float)c[V], (int)c[H]); In the first part (lines 18 and 19), variables used in plans are declared as well as the sensor, the AnalogInputSampler in our case, that is attached to the agent with the statement in line 20.
Lines 21–28 reports the reactive plan that is triggered when the adc() belief (reactor) is asserted: indeed this operation is performed by the AnalogInputSampler each hour. As a result, variable T is bound to the temperature value sampled and the plan’s body gets the current time and asserts the belief temperature() with the value as first parameter and the hour as the second parameter (line 26). The same belief is sent to the RiskEvaluator agent (addressed by name) for further processing (line 27). The last operations are performed by involving the Context object obtained by the plan’s body: it is not only the repository of the bound variables but also acts as a proxy of the agent, thus, by using the operators +, - and «, we can add or remove beliefs, call a procedure or send a message to another agent, as Listing 1 and 2 shows in lines 26, 27, 31, 35 and 39, for Listing 1, and 13, 17, 25 and 26 for Listing 2.
After the assertion of belief temperature() the plan defined in lines 30–32 is triggered, which has the aim of computing the maximum temperature of the day till now. Such an operation is performed by the plans related to procedure calc_max() reported in lines 34–40. As the reader can see, there are two plans (two clauses) having both the same head, but the former includes a condition part. In detail, plan in lines 34–36 is triggered when another belief temperature() is found in the knowledge base but with the value of T1 greater than3 the current maximum temperature (variable T); as a result the new temperature becomes the new temporary maximum and the procedure is called recursively. But when the condition is false, we have found the absolute maximum so the plan in lines 38–40 can be triggered that, as the action, stores the maximum temperature (and the hour in which it has been sampled) in the knowledge base using the proper belief.
Agent Heartbeat features the same behaviour of Temperature, but uses a diferent sensor and the beliefs heartbeat() and heartbeat_max() to store the current and the maximum value of the heartbeat sensed.
The last agent of the application is RiskEvaluator, whose code is reported in Figure 3. After class definition and variable definition, the listing shows the presence of the accept() statement, which expresses the fact that the specified beliefs, also with the given number of parameters (arity), can be accepted by this agent as external messages sent to it. Since this agent has the aim of processing both temperature and heartbeat data, two reactive plans are defined: the former triggered by the temperature() belief, the latter triggered by the heartbeat() belief. Both plans checks for the presence of the other belief in the knowledge base, but given that the hour parameter is the same (otherwise correlation is not possible), and, as a result, call the evaluate() procedure (lines 20–27): it checks if an alert is worth to be sent and then (lines 25 and 26) removes the received beliefs from the knowledge base because they are no more useful.
The listing in Figure 3 ends with the C++ setup() function which is the one executed by the Arduino framework when the program is started. It shows how agents are created in Democle: they must be simply instantiated and then started by calling the method start().
This paper has introduced Democle, C++ a platform that allows developers to program MASs using the BDI paradigm for MCU-based hardware and thus suitable to build MASs for IoT/Edge computing. The peculiar feature of Democle is the possibility of specifying beliefs and plans in logic/declarative manner, embedding the declarative code inside the same C++ source code. This is made possible thanks to the use of operator overloading and lambda functions, two very important characteristics provided by the C++.
Democle is currently in an early development stage even if the logic/declarative engine is complete. New features are planned, such as a simpler way to access Context variables, additional 3The statement gt(T1,T) is a library predicate and returns true when the first parameter is greater than the second one. sensor classes for all the peripherals of MCUs and a flexible way to perform distributed agent communication, among diferent devices and using diferent wireless communication protocol.
Democle is released with the BSD license and can be obtained through github at the URL http://github.com/corradosantoro/democle.
This work is supported by the MIUR PRIN project “T-LADIES”.