# ARPS: A Framework for Development, Simulation, Evaluation, and Deployment of Multi-Agent Systems
## 4 Demonstration of the Framework
### ARPS Framework Usage  
The modelling of the MAS for resource management can be accomplished by following the steps:  
1. Collect data about the resources in the environment using the available sensors. 2. Create a model of the environment, construct the resources behaviour, their relationship with each other. 3. Create the actuators and the policies to drive the agents based on the available resources. 4. Create a model of the events that will modify the environment. 5. Run the simulation, take a snapshot of the environment containing the agents deployed along with their policies, and collect the results in the CSV format. 6. Use more suitable external tools to evaluate the results. 7. Use a snapshot to deploy the agent managers and their agents in the real environment. 8. Modify the environment model, the policies, or the events and re-run step 4 to improve the agents in the actual environment. The usage of the framework can be summarized as the implementation of some interfaces, and the creation of the configuration files needed by the agent managers and agents. We have created the abstraction of the resources that provides the touchpoints to be accessed by sensors and actuators, seen in Figure 5.  
Starting with the sensors and a minimal set of the configuration files (files that will be described in detail later in this section), it is possible to execute the agents in the actual environment to collect data since a set of monitoring policies related to the implemented resources are made available automatically. Therefore, it is possible to initially create agents with the only the purpose of gathering data periodically. This data provides insight about the actual resources. This will be essential during the modelling of the environment used by the simulator. This model can be later updated when comparing the simulated environment with the actual environment. Once the resources and sensors are implemented, the next step is the implementation of the actuators. The actuators are used by the policies that drive the behaviour of the agents. These policies can be created by implementing the Policy interface, illustrated by a reflex policy in Figure 6. Since our approach is based on autonomic computing concepts [43], other types of policies, employing utility functions, or goal-based approaches can be implemented. The method _condition(event)_ can be implemented to use optimization algorithms, defined by the user, that will compute the ideal parameters and then use the results to modify the resources through their actuators. Goal-based approaches would require the user to model the states and use the method _condition(event)_ to search for the best action to perform to achieve a better state. Both policies would be executed as periodic  
Figure 5: Resources, Sensors, and Actuators structure diagrams. policies, so the event is just a time event indicating that it is time for the policy to evaluate the current state and executes its actions based on the perceived environment. Since the policies encapsulate the perception and modification of the resources, and these resources can be modified by external events, the next step is the modelling of the these events. The events arrival in the system can be stochastic or deterministic and it can be created by implementing the interface EventQueueLoader. The events are encapsulated in the SimEvent class, which in turn contains the SimTask that will be executed during the simulation. The SimTask _main_ method should provide the behaviour that will modify a resource, while the _pos_ method will contain all the finalization process to be executed, like resource release, after the task is finished. The relationship between the DES components is illustrated in Figure 7.  
Given the structure present in Figure 8, the final step before running the MAS in the actual or simulated environment is the creation of the configuration files, in JSON format, containing the implemented files previously described in this section. Both configuration files are similar in their structure.