Inglês (pdf)
Artigo em XML
Referências do artigo
Tradução automática
Enviar este artigo por email
Citado por SciELO 
Similares em
SciELO 
Permalink
Introduction
Embedded computers are the core of any electronic system, and satellites are not the exception. In fact, satellite designers are adopting the use of distributed spacecraft architectures to improve their performance and making their subsystem’s integration easier and faster. The shift from a centralized computing architecture towards a distributed architecture offers new advantages. For example, it improves fault-tolerant capabilities by enabling resource sharing among subsystems (1). Also, it is easier to reconfigure and to upgrade the onboard software on the fly, which brings flexibility in the mission operations (2) (3). However, these new advantages come at a cost: the onboard software complexity of the space missions is increased. According to (4), the primary cause of the growth in satellite software complexity comes from the mission requirements related to coordination and control-related tasks during the mission operation phase.
Both coordination and control activities demand a deterministic (real-time) behavior to the computers onboard of the satellites. This onboard software is characterized by being autonomous. Thus, it can make decisions without human intervention with specific time constraints. In particular, spacecraft maneuvers and fault detection, identification and recovery tasks are the most critical features needed to ensure the safety of the spacecraft (5) (6)As the onboard coordination and control activities require a high degree of autonomy, the use of Multi- Agent Systems (MAS) is proposed as a software architecture style to develop satellite software with intelligent capabilities (7). The critical feature of this architectural style lies in its capacity for addressing problems by distributing them to different agents (8). According to (9), an agent is an autonomous computational entity that is assigned to a specific role within the system, communicates with other agents and perceives their environment. A group of agents (MAS) work in a proactive sense to achieve a specific mission goal.
In general, most of the MAS-based applications do not use a standard platform or framework for its implementation (10). However, there are several solutions available for MAS-based applications development. Some of them are based on the specifications established by The Foundation for Intelligent Physical Agents (FIPA), for instance, JADE (11), SPADE (12), and Mobile-C (13). The main advantage of being a FIPA-compliant platform/framework is the ability of applications interoperability among different platform/frameworks.
There are also other successful MAS-based non-FIPA compliant frameworks designs such BESA-ME (14), EmSBot (15) and ObjectAgent (3) that enable the implementation of embedded MAS-based software.
Despite that JADE is the most used MAS-based application development platform (16) and the JADE agent platform runtime’s memory footprint is around 100kb (making it suitable for embedded devices) (17), it does not fulfil the real-time requirements of the spacecraft system. Similarly, SPADE does not offer real-time support either. Moreover, Mobile-C framework runs on OSs that are not suitable for highly-constrained embedded platforms.
Lastly, the above-mentioned non-FIPA compliant frameworks (BESA-ME, EmSBot and ObjectAgent), although successfully implemented, they do not discuss the implementation of the minimum technology required to build a MAS-based platform specified by FIPA.
Furthermore, as shown, there are several approaches of MAS-based platform/framework/ application implementations in embedded systems, but there are no reports on the literature about how the mapping methodology of an agent to a RTOS environment might affect the CPU’s load, power consumption and latency.
Therefore, the purpose of this paper is to present a MAS framework that bridges the gap between real-time features and implementation based on the FIPA specifications. This framework is built based on a design strategy that considers the effect of the mapping on the CPU’s load, power performance and latency of the system. Multi-Agent Framework for Embedded Systems (MAES), is a FIPA-based framework with real-time capabilities designed to be suitable for highly constrained embedded devices used in computers for pocketqube satellites.
The outline of the paper is as follows: Section 2 describes the software architectures aspects considered for the design of MAES, then Section 3 focuses on the implementation strategy, specifically in the key components to make the platform FIPA-compatible. Section 4 shows a characterization of MAES using a set of applications with different levels of complexity to show the value of adopting MAS-based software design in small satellites missions. Finally, Section 5 draws the main conclusions and discusses the future work intended.
MAES Architecture
The development of a multi-agent systems framework for satellite systems responds to the need of having distributed and concurrent execution environment for autonomous onboard software execution. This section starts with a description of the satellite execution infrastructure, to continue with the MAES framework design. The end goal is to show the feasibility and value of adopting multi-agent-based software development approach for satellite software development.
Satellite Software Architecture
This paper considers a highly miniaturized satellite using the pocketqube form factor. As discussed in (16), this highly integrated spacecraft, with an approximated volume of 5cm x 5cm x 15 cm, consists of a distributed electronic system with three primary embedded computers for electrical power management, for attitude determination and control and for command and data handling tasks. All these computers are based on the MSP432P401R microcontroller that features an ARM Cortex-M4 processor capable of running multi-threading applications with the TI-RTOS operating system. In principle, this tiny satellite is capable of running distributed and concurrent software for its operation.
This work assumes that satellite’s onboard software (OBSW) can be modeled as a Multi-Agent System (MAS), and these agents are mapped into one of the pocketqube computers for their execution, so each of the onboard computers provides an execution platform for agents to live (logical containers). Either the agents or their private behavior functions can rely their execution on TI-RTOS threads called tasks. Also, this work takes as inputs the FIPA standards for implementing the MAS components. The software architecture model for this pocketqube mission is presented in figure 1, where the interface between different software layers is highlighted. MAES framework is implemented as a middleware module in charge of enabling the operation of the MAS based capabilities for a single pocketqube computer.
MAES Framework Design
A set of software components were engineered using object-oriented abstractions to provide with the required FIPA-based features in MAES framework. The core of the MAES design is the agent class that is an extension of the task module in the TI-RTOS. This class allows the composition of agents with one behavior supplied by the behaviors class. These behaviors can be either generic or composed, depending on the software requirements, which provides flexibility. Agents can interact with each other by sending and receiving messages. For that purpose, agents use the mailbox module from the TI-RTOS.
Agents also can be grouped into organizations, depending on the software requirements. For that purpose, the MAES organization class provides the abstractions required for agents to organize and execution within the MAES execution platform, that aggregates all the organizations living in the execution environment. Figure 2 shows the relationship of these classes within the MAES framework. Section 3 focuses on the implementation aspects of each class and their integration.
MAES Framework Implementation
The implementation of the MAES framework was carried out using the integrated development environment (IDE) Code Composer Studio (Version: 7.1.0.00016) with the Texas Instruments Compiler (Version: TI v16.9.1 LTS) and the XDCtools (Version: 3.32.0.06_core).
The hardware platform provided for this research was the SimpleLinkTM MSP432P401R LaunchPadTM
Development Kit. The microcontroller used by the development board is the MSP432P401R microcontroller (ARM Cortex-M4) running at 48MHz. Additionally, a Sensors Booster Pack Plug-in Module was connected to the Launchpad. This module contains a light sensor, an infrared sensor, an Inertial Measurement Unit (IMU) (featuring an accelerometer and gyroscope), a magnetometer and an environmental sensor.
The framework was written using C++, which is an Object-Oriented Programming (OOP) Language. Table 1 shows that each of the mandatory FIPA components is implemented accordingly through different classes provided in MAES framework.
The following subsection describes in detail the implementation of each MAES class.
Agent Class
An instance of the Agent class contains the variables that describe the Agent’s AID, mailbox handle, local name, priority, and organization characteristic. The instance also has a pointer to a memory stack defined by the developer. This stack is used for storing the agent’s context and variables.
Generic Behavior Class
The MAES framework provides classes that can be used by the developer to implement customized behavior. An instance of Generic Behavior class allows the user to implement one behavior for an agent. The instance contains methods that can be overwritten by the developer: setup(), action() and done(). Additionally, the developer can also overwrite methods related to Failure Detection, Identification and Recovery tasks (FDIR). The FDIR methods intend to detect faults and identify the origin of the fault in the shortest time possible. Therefore, reducing the diagnostic time and increasing the system availability (17). With the FDIR methods, the agent autonomy and reliability are increased as it can detect, identify and recover from its failure instead of having a centralized managing authority to perform those actions. The execution flow of these methods is shown in figure 3.
To execute the methods shown in figure 3, the method executed() has to be called from a wrapper function. If required, several behaviors can be implemented as separate subroutines in the wrapper function, and its execution order is determined by the developer by using patterns such as Finite State Machines.
Agent Organization Class
The Agent Organization class allows the developer to create organizations. Each organization groups the agents into one of the following topology types: Hierarchy and Team. The Agent Organization object contains methods such adding an agent to the organization, banning an agent, removing an agent from the organization, among several others.
Agent Platform Class
An instance of the Agent Platform Class contains methods to initialize the constructed agents, to initialize the platform and to perform the services. Additionally, this class creates the AMS agent.
The AMS agent performs actions such register/de-register an agent, suspend/resume an agent, kill an agent and restart an agent. The behavior of the AMS agent is shown in figure 4.
Agent Message Class
Each agent’s mailbox is created in the Agent Platform class. However, the message object to be exchanged during the agent’s communication is not constructed yet. Therefore, MAES framework provides a method for the message object creation and management through the Agent Message class. An instance of the Agent Message class contains the message object to be exchanged between two agents and the methods to manipulate the object. The message object contains the sender’s AID, the target’s AID, the message type and the message’s content. Also, there are methods to manipulate the message object such send, receive, add receivers, among others.
MAES Framework Workflow
Figure 5 shows the workflow to be followed to use the MAES framework properly. This consist of three phases namely project setup, agent construction, and platform construction. In the setup phase, all the dependencies are configured and verified in the integrated development environment. For the agent construction phase both the stack and behavior parameters are established, then during the platform constriction phase, the boot agent service is instanced the application is launched by the TI-RTOS scheduler.
MAES Benchmark
This section describes the experiments conducted to study the real-time characteristics and the impact on the memory allocation, CPU’s load and power consumption of the MAES framework on any application. For this, four applications with a different level of complexity were used.
The following list describes the used applications, and it is ordered from the simplest to the most complex level:
Blink LED application: Blinks two LEDs.
Telemetry Logger application: Logs temperature, voltage and current value and outputs the value in UART interface.
Command and Data Handling System application: Receives commands from the user through UART interface and performs the according action.
Attitude Estimation algorithm application: Implementation of a quaternion-based Extended- Kalman Filter (EKF) based on the work of Sabatini (2006) (18)
The Attitude Estimation Algorithm was implemented in MAES and JADE framework to study the real-time characteristic of MAES framework; the JADE library was chosen for comparison purposes since it is the most common known-tool for MAS-based development.
Then, to study the impact of MAES framework on the memory, CPU’s load and power consumption it was developed two versions for each of the applications: without MAES and with MAES. Each of the benchmark tests is explained in further detail in the following sections. To achieve consistency with the results, all the experiments were run on the same Launchpad board and were implemented in the same environment with the same compiling tools.
Real-time characteristics
This experiment compares the execution time of the EKF algorithm in MAES and in JADE. The execution time of the algorithm is measured each time that a new data arrives. The data is logged during 5 minutes at 10Hz sampling rate. The mean and variance of both framework’s execution time are shown in table 2.
JADE’s execution time varies on each call as the processor might be busy executing other system’s processes. On the other hand, MAES’ execution time is consistent the real-time operating system ensures predictability in its behavior. Figure 6 shows the probability density function for both frameworks.
As seen, JADE’s execution time is widely spread while it is concentrated in MAES. Despite that the algorithm executes faster in JADE in average, JADE cannot guarantee that on each call the algorithm execution time will be consistent. On the other hand, the execution time in MAES is consistent as it lies on top of a real-time operating system that ensures predictable execution pattern behavior.
Memory Performance
The Launchpad includes 256KB Flash memory and 64KB SRAM memory. Figure 7 shows the memory usage for the application on both implementations.
For all the applications, there is an increment in memory utilization (program memory and SRAM) when using a MAES implementation. The increment in the SRAM memory is due to the dynamic object allocation of MAES framework. An Agent Platform object requires 4,400 bytes, and an additional Agent object requires 36 bytes in the dynamic memory. Then, the increment in the Flash memory is due to the additional code size of the MAES framework as shown in table 3.
It is noteworthy that the difference between the two implementations is reduced as the application’s complexity increases. Therefore, the MAES framework is more suitable for the more complex application than the simple software implementations.
Even though that the memory usage is increased using MAES framework, the user coding effort is reduced as shown in table 4.
The without-MAES implementation requires additional coding effort for creating tasks and signaling mechanisms. On the other hand, the with-MAES implementation already contains all the agent routines and communication method standardized for the developer use.
CPU’s load
The RTOS Analyzer’s Load Analysis tool from Code Composer Studio is used to measure the CPU utilization for each application in the benchmark. For that, it captures the average CPU utilization for each task/agent. According to this tool, there is an increment for all the tested applications. As an example, table 5 shows the increment for the Attitude Determination Application.
The increment of the CPU load in the MAES implementation is due to the communication method used in MAES. MAES not only implements the mailbox module but also, additional instructions are enclosed in the method send() from the Agent Message class. The additional instructions check the recipient validity. Table 6 shows the average duration for each communication method.
Even though that the MAES post/pend pair is mailbox-based, this pair contains additional instructions to verify the recipient validity. Therefore, this increases the average number of cycles for the MAES communication method.
Power consumption
A set of experiments were conducted to verify the MAES’s implementation impact on the power consumption. For that, the power profile from each application implemented with MAES is compared against its non-agent implementation. The results are shown in table 7.
There is an increase in the power consumption for an application using the MAES implementation. The additional power consumption is the MAES framework is due to the extra CPU utilization required for the MAES’ communication method as reported in Section 4.3. However, the impact of the MAES framework on the power performance was deemed negligible as the difference is lower than 1%.
Conclusions and Future Work
Conclusions
This paper has shown the feasibility of a Multi-Agent Framework for Embedded Systems (MAES) that is a FIPA-based framework with real-time capabilities designed to be suitable for highly constrained embedded devices used in highly miniaturized satellites.
The framework was developed on top of a Real-Time operating system (TI-RTOS) to guarantee determinism on agent’s execution. The MAES framework’s real-time characteristic was demonstrated in the benchmark analysis with an Attitude Determination application based on the Kalman filter. The experiments demonstrated that algorithm execution time in MAES is consistent with a variance in the order 105 s2. Based on that experiment, MAES ensures predictable behavior in its execution.
Results have also shown that the user coding effort is reduced as the tasks and communication routines are standardized and encapsulated into MAES’ class methods. However, it comes at a cost as the MAES-based applications show a minimum increase in memory, CPU’s load, and power consumption. Furthermore, it was also shown that MAES is more suitable for more complex applications.
Even though that there is an increase in the memory allocation, it is demonstrated that the framework is lightweight as this only requires additionally 5,826 bytes in the Flash memory. Furthermore, an Agent Platform object requires 4,400 bytes, and an additional Agent object requires 36 bytes in the SRAM memory.
In conclusion, MAES is a real-time, lightweight and scalable framework compatible with highly resource-constrained embedded computers.
Future Work
Despite the MAES framework was developed based on the FIPA specifications, the framework is not fully FIPA-compliant. Specifically, the MAES framework messages are not compliant with the FIPA Agent Communication Language (ACL). Thus, it presents an implementation opportunity to expand MAES’ functionality. The framework can be expanded to perform agents’ inter-platform communication when FIPA ACL is integrated.
