## 3 Proposed Methodology  
This section introduces an agent architecture (Figure 1) which provides a high level of abstraction to the scheduling problem. The agent shown in Figure 1 could also be referenced as a meta-agent for scheduling, as it aims to use multiple scheduling methodologies while trying to solve the scheduling problem of a production environment. Its key characteristic is that the optimization process is cut off from the core agent logic, which allows the agent to be able to navigate through an arbitrary number of available optimization methods for a given problem. In other words, the agent has access to a toolbox of scheduling solutions, from which it can select based on the type of the problem and the toolbox capabilities. Of course, this raises the issue of accurate scheduler selection for a given problem, which is part of the main logic that is defined within the agent's skills and, in practice, is addressed through the AAS concept. The AAS information model aims to address this issue by allowing a problem-compatibility description for each one of the available scheduling solutions, which can then be used to map the scheduler with requested problems. The AAS also enables a standardized way of communication between agents as well as other I4.0 systems. In contrast to other assets that use the AAS description to achieve interoperability, it is important to highlight that agents are built on top of the AOP language and message-based interaction to communicate with other agents. As such, on the one hand, agents do not need AAS as the interface for exchanging information within the MAS, but they do need it when it comes to communication with systems that do not belong within the MAS. To this end, the AAS concept serves as the description of communication within the MAS (description of capabilities and messages for agent-to-agent interaction), as well as provides access to entities that do not belong to the MAS. Each one of the components displayed in Figure 1 is a composite of classes and interfaces. The scheduling services represent the lower level of optimization within the agent, i.e., the scheduling algorithm and mathematical formulation of the problem. This layer consists of an arbitrary number of schedulers, each one aiming to provide a solution to a specific scheduling problem. The algorithm, as well as the type of problems suitable for that scheduler, may differ from one another, thus allowing a wider range of problems suitable for the meta-agent. Each scheduler also expects a different I/O format. For example, in the case that a scheduler is designed to give solutions to the Travel Salesman Problem (TSP), information should be formatted into cities, travel distances, and so on; in other words, in a format that the scheduler can understand. This brings in the need for the scheduler connector to ensure information is restructured into the format accepted by the scheduler. In addition, it builds a stable connection between the scheduling software and the agent software, which is necessary, especially in cases where the algorithm is executed on a different computational resource. One of the primary aspects of this approach is the ability to select among different scheduling methods based on the input problem definition and user requirements. This is what makes the agent a meta-agent and addresses the challenges for abstraction in the scheduling agent. In order for the meta-agent to be able to decide among the different algorithms, it needs to have a classification of the algorithm based on the problems that it is able to solve. This aspect was also supported primarily by the AAS concept, as it allowed the description of the capabilities of each scheduler individually based on the problems that it is able to process. This can set up the compatibility requirements for the scheduler and allow the agent to select among an arbitrary number of schedulers. Within the remainder of the section, the detailed description of the agent AAS is elaborated.