It is difficult to gauge the absolute execution times of simulation platforms. Absolute times can only be measured for specific simulation models that are simulated on specific simulation hardware. However, it is possible to look at computational complexities and their impact on how well simulation tools scale. While it is known that the individual software tools, JADE and OPNET Modeler, can scale easily to a significant number of agents and network nodes, it needs to be shown that this is also true for MAC-Sim. Thus, the focus here is on defining the computational complexities that have been added in the course of the platform development. The complexities are expressed in the Big-O notation.
The Big-O notation expresses the runtime of an algorithm with respect to the input size n. In our context the input size is the number of agents and network nodes that are simulated. For example, if the runtime of an algorithm grows linearly with the number of agents/nodes, it is said that the complexity is O(n). If the runtime is constant regardless of the input size, the complexity is O(1). The most typical types are: constant O(1), logarithmic O(log(n)), linear O(n), n-log-n O(nlog(n)), and quadratic O(n2).
It is important to understand that the Big-O notation does not describe the runtime in absolute values. For example, two algorithms with linear behaviour are both classified as O(n) even though one might perform better than the other in terms of absolute runtime. 4.7.1 Computational Complexities
Table 4.2 lists the computational complexities of the operations on data structures that can grow with the number of simulated agents and network nodes. Both, the FedAgent and the RTIAgent use sorted linked lists to maintain their behaviour or event lists. While the sizes of the behaviour lists are usually very small but may be influenced by the number of agents in the MAS, the size of the event list of the RTIAgent is always the number of registered FedAgents plus any incoming message events. As can be seen in the table, the worst complexity is O(n), which happens when a new list element has to be inserted into the existing sorted list. In fact, O(n) represents the worst-case for this operation, which holds true if every insertion is made at the very end of the sorted list.
4.8. SUMMARY
Table 4.2: Computational complexities of added simulation components. Number of agents and network nodes is denoted as n.
Component Data Structure Operation Complexity
FedAgent sorted behaviour list insert/read O(n)/O(1)
RTIAgent
sorted event list insert/read O(n)/O(1)
map (agent ID, node ID) add/get O(1)/O(1)
map (message ID, agent messages) add/get O(1)/O(1) Connection Manager map (node ID, IP addresses) add/get O(1)/O(1) map (connection ID, child process) add/get O(1)/O(1)
On the other hand, there is a constant runtime (O(1)) for reading the next behaviour or event from the sorted lists because they are always at the beginning of the lists and no search is required.
Another data structure that is used is the map. A map can be thought of a table with two columns for which the entries in the second column can be found through their associated elements in the first column. Both, adding and finding map elements, can be performed with constant complexity (O(1)) provided that the maximum size of the map is known or well guessed. The RTIAgent reads the agent-node mapping file into a map and stores intercepted agent messages in a map for later delivery. The Connection Manager process also utilises maps to associate node IDs with IP addresses and connection IDs with their associated child processes.
Considering all computational complexities of the added simulation components, the added runtime increases linearly with the number of simulated agents and network nodes. This suggests that the developed components scale well and do not introduce a significant performance overhead. Specific data on the performance of the simulation platform is given later for the case study as part of the results in section 5.7.
4.8 Summary
This chapter presented an implementation of a co-simulation platform that was based on the design and architecture suggested in the previous chapter. It was named MAC-Sim (Multi-Agent and Communication Simulator) and it federates the Java Agent DEvelop- ment Framework (JADE) with the OPNET Modeler.
All implementation details were shown and discussed that were necessary to realise the federation of JADE and OPNET Modeler. Various new Java classes were added to JADE, which implement the concepts of agent message management, controlled ex- ecution of agents’ behaviours, and communication with the RTI. OPNET Modeler was extended by a new generic agent application model and HLA Interface. The applica- tion model can represent any agent in the associated MAS (implemented in JADE) and accurately simulate their message communication based on protocols such as TCP and UDP.
This chapter also discussed the processing overhead that may have been added by the newly implemented code. The computational complexities of the relevant added elements such as data structures were analysed. The results suggest that the overhead grows linearly with the number of simulated elements and that therefore the added code would scale.
Overall, this chapter showed a successful implementation of the previously motivated platform design, which can be used for MAS development and validation. The next chapter utilises the platform to implement and analyse an agent-based remote backup relay supervision scheme.