# Model Predictive Control for Flexible Job Shop Scheduling in Industry 4.0 +
## 2 Problem Description  
The scheduling problem considered in this paper was originally proposed in our previous work [17] and describes an FMS with a given set of manufacturing units in which customer specific orders are fulfilled. It is a general case of the flexible job shop (FJS), which is further discussed in Section 2.3. Every customer specific order constitutes a specific and possibly unique job in the manufacturing system. In order to arrive at a versatile modeling and control framework, we start from a very abstract description of the manufacturing problem which can be refined to describe several more specific scenarios. We want to exploit the flexibility to combine the skills of the available manufacturing units in the sense of skill based programming [6], in order to create and describe production plans. Therefore, our modeling approach has the skills as a central element. The manufacturing units have the skills to execute tasks, which are the basic building blocks for the jobs that have to be fulfilled by the manufacturing system. A job is completed once all its tasks have been completed. In a more formal way, the basic elements of the manufacturing problem are  
* a set \(\mathcal{T}=\{\tau_{1},\ldots,\tau_{n_{\tau}}\}\) of tasks that can be executed in the manufacturing system,
* a set \(\mathcal{M}=\{M_{1},\ldots,M_{n_{M}}\}\) of manufacturing units (robots, machines, automated guided vehicles, etc.) which are called machines for brevity in the rest of this paper; every machine \(M\) can only execute a subset of tasks, which is specified as \(\mathcal{T}_{M}\subset\mathcal{T}\),
* a set \(\mathcal{J}=\{I_{1},\ldots,I_{n_{\eta}}\}\) of jobs that need to be fulfilled by the manufacturing system; every job \(J\) consists of a set \(\mathcal{T}_{J}\subset\mathcal{T}\) of tasks. The purpose of the manufacturing system is to complete the jobs \(J\in\mathcal{J}\) with the available machine pool \(\mathcal{M}\). The assignment between jobs and machines is done based on the tasks, which are the linking element between them. As different jobs \(J\) and \(J^{\prime}\), which represent the instructions for the production of different goods, may share the same production steps, their sets \(\mathcal{T}_{J}\) and \(\mathcal{T}_{J^{\prime}}\) may contain the same elements. If we refer to a task \(\tau\in\mathcal{T}_{J}\) of a specific job \(J\), the pair \((\tau,J)\) of task and job is called _operation_\(O=(\tau,J)\). With this, the set of operations \(\mathcal{O}\) is defined as \(\mathcal{O}=\{(\tau,J)|\tau\in\mathcal{T}_{J}\}\subseteq(\mathcal{T}\times \mathcal{J})\). The term operation is mainly used to abbreviate certain statements, but in many cases we rather refer to the pair of task and job for the sake of clarity. In the same way different jobs might share the same tasks, also different machines \(M\) and \(M^{\prime}\) might be able to execute the same tasks and hence the corresponding sets \(\mathcal{T}_{M}\) and \(\mathcal{T}_{M^{\prime}}\) may have elements in common. In this case and when considering the framework of skill-based programming [6], the fact that both machines can execute the same task does not mean that they do it in the same way. The machines might be of a different kind and it is not even necessarily required that the machines have some specific tool, as the introduction of a multipurpose machine by [PERSON] [15] suggests. In the framework of skill based programming [6], different production times for the same task might even result form different implementations of the same task or skill on different machines. For example, the tightening of a screw can be done with a tool that can rotate infinitely, or with a robotic arm that can only rotate by a limited angle and therefore needs to turn back and forth several times needing more time for a task that requires to tighten a screw. The skill to execute a task can be seen in the most abstract and general way possible.