## 3 Proposed Methodology
The compatibility requirements are the problem description information, namely environment, constraints, and objectives, which allow the agent to map the suitable algorithms to the specific problem description. Equivalently, the parameters may override any existing default parameterization of the algorithm performed during the initialization of the agent. The response is created as the optimization process has finished, while the \"ScheduleResponse\" is also broadcasted. Now, an interesting debate on the utilization of AAS is whether dynamic information should be stored on the AAS directly. In essence, the AAS file is an asset description metamodel, and it is not meant for direct storage of asset values. In other words, in the case of a shopfloor machine, an AAS would enable access to machine-specific components, e.g., a machine sensor. However, it does not necessarily mean that data would also be loaded upon the AAS repository, i.e., uploading sensor data upon the AAS file. Most of the time, this is a design choice, as the description of the AAS does not exclude that dynamic data may also be loaded. On the other hand, AASs do not act as an extended storage of historical data, and although they could perform this role, it is usually out of the scope of using the AAS. With that being said, there can be defined two separate methods for requesting and receiving a new schedule operation in the planning agent (shown in Figure 4). The first and more orthological way is through the MAS, based on the principles of AOP. The agent is, in essence, an entity that responds to events from the MAS, such that the planning agent is an entity that responds to the scheduling events which are broadcasted by other agents. A significant detail is that the scheduling request sent from the agent should follow the format of the request that is referenced within the AAS description. So, in practice, the inner format of the event follows the same object format as the SMC described within the AAS, except it is transferred as a serialized object because it is sent directly as a message within the MAS. The scheduling agent can follow the procedure--of selecting the optimizer and optimizing the schedule--for completing the scheduling request and uploading the input message onto the AAS repository for traceability reasons, if needed. The second way to request a new schedule is directly via the AAS. In practice, this is what AAS files are for: providing access to the asset's operations and information free of hardware or software-specific requirements. In the case of the agent, this may slightly differ, as agents primarily interact with each other using AOP; nevertheless, this method also allows external entities (out of the MAS) to interfere with the agent when required. Just by calling the corresponding operation from the agent's skill SMC and uploading the accompanying information, any external software can have access to the scheduling services provided by the agent. This type of interaction is primarily for third-party entities outside of the MAS, which have no access to the message-based communication established by the MAS framework. Figure 4: Workflow for scheduler selection within the agent.