## 3 Proposed Methodology
be aware of how the algorithm implementation can be managed and be able to do that not only from a local perspective but also remotely. The next and most important part with respect to the management of the optimization toolbox is the Compatibility SMC, which allows the agent to identify the cases in which this algorithm/optimizer is suitable for a problem. The description of a scheduling problem can be achieved using three notations. The three notations represent (i) the environment, (ii) the problem constraints, and (iii) the objectives and are enough to classify any schedule optimization problem. Similarly, these notations can be used to describe the sets of scheduling problems that the specific algorithm is compatible with. As an example, for an algorithm that is compatible with Job Shop environments, the constraints of release time and a makespan objective mean that the Job Shop scheduling problem for minimizing the makespan given jobs' release time can be solved. However, in cases where sequence-dependent setup delays are also included, the algorithm would not be able to portrait that constraint and thus, the solution will be practically wrong, and the same applies to any kind of combination of these notations. It is also important to highlight that, in recent research, there are problems that a polynomial time algorithm has been found, or at least to the relaxation of the initial problem. This is useful information for the agent in order to navigate across a database of the different algorithms and select the one that has the best time/memory performance. Of course, in most cases, scheduling problems remain hard to optimize, and polynomial complexity cannot be achieved; in those cases, there can be more than one available algorithm in the list of optimizers, and the selection is part of the agent's logic that has been developed. The above figure displays the scheduler selection process based on compatibility. As illustrated, after the agent has parsed information from the scheduling request data into the internal format, it analyses the data in order to identify the problem type for the specific dataset. The problem type definition using the three notations described above can be addressed via basic rules for the process plan identifying the different routes that are available for the different jobs and the relations between them. As also highlighted within the later sections of this paper, the production information regarding the process plan, material requirements, work orders, etc., is not something standardized within this research study. In other words, the structure and format of information is an implementation decision, while there are different information frameworks and standards suitable for describing production schedule data. Following the three-notation modeling mechanism for the scheduling problem allows the agent to characterize any scheduling problem as long as the rules are defined for each specific type. Specifically, the agent needs to be able to identify, given the input data, which rules need to be applied in order to define whether the data are derived from a specific type of problem. To give a more practical example, Job Shop environments, for example, are supported by the condition that there is only one alternative route for each order, in contrast to the Flexible Job Shop, which contains more than one. Another example is the case of batch versus continuous manufacturing, which can be defined by the ability of the scheduler to include job release time or/and family of jobs, which can be linked with material arrival dates and product types. There are, however, even more complex examples, such as inventory constraints and case-dependent policy constraints, which are hard to classify into a specific cluster of problems. From the implementation side, however, the agent is able to analyze any given problem into these categories as long as it is given a detailed set of rules that need to be satisfied for this class.