Agent Model Overview

The main common denominator of all configuration design methodologies including MAS is the need to elicit and maintain the system requirements independent of the proposed solution alternatives (Ferreira et al. [131]). Consequently there is a need for Requirements Agent which is able to provide clear objectives to those agents involved in the configuration process. Furthermore, they need to be able to represent

91 the interests of the customer/system user to validate possible system configurations against the original requirements. The need for assessment capabilities in this agent is justified by the possibility of a big list of configuration solutions, which will be filtered and ranked by this agent based.

Another important aspect within this problem domain is the equipment modules. It is proposed that each equipment module should be represented by Equipment Module

Agents that have a detailed understanding of the module’s capabilities and

behaviour, which is viewed as crucial to enable the concept of self-configuration. The Equipment Module Agents have to play a key role in the bottom up approach to the MAS configuration process, because they are representations of the equipment modules enhanced with methods to enable the collaboration with other agents to achieve MAS configurations. Each Equipment Module Agent should only be aware of its own capabilities and only should have a very limited understanding of the surrounding world to maximise the adaptability and scalability of the framework. This provides the ability to introduce new modules, or remove them without the need to adjust the self-configuration methodology. Consequently, there needs to be a mechanism which validates the logical consistency of the agreed interactions between collaborating Equipment Module Agents. An agent system is in itself a modular system where new agents can be introduced as long as they adhere to the agent architecture rules. This characteristic allows the creation of interactions with expert agents that can be enhanced in the future to cater for the changes in the constantly evolving domain of MAS (Onori and Oliveira [18]).

The role of a mediator has been introduced to the agent architecture to create a configuration assessment mechanism. This role will be fulfilled by an MAS Expert

Agent which is responsible for assessing the logical conditions of the configurations

based on its internal knowledge model. The need for the introduction of these concepts into a separate agent is supported by the nature of this knowledge, which is in constant evolution. If this knowledge was built in to the configuration methods, e.g. the internal decision making models of Equipment Module Agents, future changes might require a complete change of the configuration methodology. Therefore, it is proposed that this knowledge is decoupled into the MAS Expert

92

Agent, which can be changed or even replaced in order to allow the evolution of this

knowledge.

The MAS Expert Agent is expected to change, however its interactions in the agent architecture will not. This strengthens the need of clear communication and iteration protocols which are required to work in the future iterations of this agent. The general premise to establish an interaction is its need, thus the question is which agent or agents require this expert knowledge. At first glance both Requirements

Agents and Equipment Module Agents can benefit from access, but a closer look

shows the redundancy of establishing interactions for both. The requirements could be extended by the MAS Expert Agent to contain extra constraints for the MAS configuration. However, this would not include equipment module specific constraints, therefore the Equipment Module Agents will require an additional interaction with the MAS Expert Agent, regardless of prior interactions with the

Requirements Agent. On the other hand if the MAS Expert Agent only interacts

with the Equipment Module Agents, the extension of the requirements will occur as part of the configuration assessment. Therefore it is proposed that the MAS Expert

Agent only interact with the Equipment Module Agents for validating

configuration that fulfil the requirements as they were set.

This architecture will potentially provide a very large number of possible solutions. Some method for early evaluation of the likely success a consortium needs to be available to reduce the computation effort required. Ideally, this evaluation should be synthesised from the actual performance characteristics of the modules. To provide some bases for early comparison, it is proposed that the Equipment Module Agents deploys Performance Simulation Agent a simulation environment. These agents represent the physical and process capabilities of the modules and dynamically interact with each other to determine the resulting behaviour and performance characteristics of a consortium. The information provided by these agents is used for the final decision of which configuration is better. The decoupling the simulation process from the Equipment Module Agents is justified by the computer intensive task that configuration methodology already is. Furthermore this decoupling provides the means for equipment suppliers to supply this computational effort as a service, which reduces the computational requirements on their clients, the system integrators. In addiction it is envisioned that each Equipment Module Agents will

93 run multiple simulations, therefore the use of distributed computing is seen as the best option. This vision was supported and generally accepted within the EUPASS consortium (EUPASS [4]).

The organizational structure for these agents is based on the agent-roles discussed above. The Requirements Agent is hierarchically above the Equipment Module

Agent, since it triggers the beginning of the collaboration process and it terminates it

by making a selection.

The Performance Simulation Agent is hierarchically below the Equipment

Module Agent, since this agent is the only one with the information required to

deploy it. The MAS Expert Agent is on higher level from the Equipment Module

Agent since it can provide a global view of the configurations. An overview of this

can be seen in Figure 5.2.

Figure 5.2 - Agent Architecture Class Overview

The existence of different agent types emphasises the need for clear separation of levels. In the proposed agent model there are three clear tiers. The first tier is the triggering configuration tier where the Requirements Agent sits. The second tier is collaboration establishment tier, where the MAS configurations are established. This tier is populated by Equipment Module Agents and MAS Expert Agents. The final tier is the virtual sandpit tier, where the Performance Simulation Agent are deployed to assess performance characteristic of given configurations. The proposed three tier structure requires some decoupling of agent roles, particularly across tiers, for a clear architecture design.

+Advertise new requirements() +Assess configuration proposals() +Suply list of interested agents()

-Assembly Process Requirements Description -Equipment Module Constraints

-Economic Constraints Requirements Agent

+Establish collaboration() +Assess interest in requirements() +Deploy simulation agents() +Establish formal collaboration() +Evaluate collaboration() +Establish unique collaboration() +Advertise requirements() -Equipment Description -Equipment Constraints

Equipment Module Agent

+Validation Assessment()

+Request Performance Assessment() -Global understanding of MAS -Knowledge of Configuration Patterns -Knowlewdge of Performance Patterns

MAS Expert Agent

+Simulate collaboration() +Process inputs()

+Collaborate to optimize configuration() -Capability Model

-Behaviour Model

Performance Simulation Agent System Integrator

Embedded MAS Expert Knowledge

Internal Models Influenced by Equipment providers Customers Requirements

94 All agents have to be able to communicate, which is an intrinsic characteristic of agent technology. However, the agents will disregard communications that are not modelled in this chapter.