Cloud-based Rapid Elastic MAnufacturing

Transcription

1 Cloud-based Rapid Elastic MAnufacturing WP5 Cloud Manufacturing Process and Optimisation Framework D5.9 T5.5 CREMA Runtime Optimisation - Prototype I Deliverable Lead: DFKI Contributing Partners: DFKI, IKER, TCO Delivery 12/2016 Dissemination Level: Public Version 1.0 This deliverable provides a description of the first prototype implementation of task T5.5 Runtime Optimisation. As stated in the Description of Action (DoA), this deliverable is a prototype (software) deliverable. As such, this document is reduced in length and its only purpose is to briefly describe the prototype functionality as well as to give installation instructions and usage clarifications. This document is delivered with instructions to obtain the software itself.

2 Status Deliverable Lead Internal Reviewer 1 Internal Reviewer 2 Type Work Package ID Matthias Klusch, DFKI Jessica Gil, TCO Olena Skarlat, TUV Other WP5: Cloud Manufacturing Process and Optimisation Framework D5.9 T5.5 CREMA Runtime Optimisation Prototype I Due Date Delivery Date Status For Approval Note The type of the official deliverable is OTHER, as it is a software deliverable. This document mainly describes how to obtain the software and how to run it. Disclaimer The views represented in this document only reflect the views of the authors and not the views of the European Union. The European Union is not liable for any use that may be made of the information contained in this document. Furthermore, the information is provided as is and no guarantee or warranty is given that the information is fit for any particular purpose. The user of the information uses it at its sole risk and liability. 2 / 22

3 Project Partners Ascora GmbH, Germany Information Catalyst, United Kingdom TechnischeUniversität Wien, Austria Technology Application Network Limited, United Kingdom German Research Center for Artificial Intelligence, Germany IKERLAN S. Coop., Spain Ubisense, United Kingdom Tenneco automotive Europe bvba, Belgium FAGOR ARRASATE S. Coop., Spain Goizper, Spain 3 / 22

4 Executive Summary This deliverable provides the requirements, installation, and execution details of the Design Time and Runtime Optimisation (ODERU) component with focus on its functionality for process optimisation at runtime (ORU). The ORU part of ODERU is responsible for functional and non-functional optimisation of service-based process models in BPMN at their time of execution. The first prototype of ODERU provides a complete set of functions for optimal semantic service-based implementation of annotated process models and the solving of process-relevant constraint optimisation problems in the CREMA use cases at runtime. For the functional optimisation at runtime, ODERU obtains from the process execution component PRU the process service plan which execution has been stopped for reoptimisation and its execution log. ODERU retrieves the corresponding process model description from the CRI and the set of available semantic services from MPM excluding those which are currently not leasable by OSL. Based on these information it re-optimises the identified remaining part of the process service plan with a pattern-based semantic service composition planner and returns the respectively new plan to the PRU for execution. The CREMA use case specific constraint optimisation problems (COP) to be solved by ODERU for a non-functional optimisation of the given process service plan with actual input data at runtime have been specified with the user partners. Special software modules for solving these use case specific optimisation as well as optimal job-shop scheduling problems are included in the first prototype software. These modules are not yet integrated with the workflow of the component. The application of the first prototype to the process optimisation at runtime in the CREMA use cases has been approved by the user partners. Ongoing research and development of the final version of the ORU part of ODERU until month M30 is mainly concerned with (a) the integration of the COP solving modules for nonfunctional optimisation of process service plans at runtime, (b) the interaction with MON and BDA for this purpose, and (c) the optional approval of re-optimised process service plans by a human user before they are returned to PRU. The software of the first prototype is available at (password: crema_reviewers_1234). 4 / 22

5 Table of Contents 1 Introduction CREMA Project Overview Deliverable Purpose, Scope and Context Status and Target Audience Abbreviations and Glossary Structure Scope and Relationship Requirements, Installation and Execution ODERU Requirements ODERU Installation ODERU Execution Limitations, Research and further Developments Application to Use Cases Optimisation at Runtime in Use Case I Optimisation at Runtime in Use Case II / 22

6 List of Figures and Tables Figures Figure 1: ODERU position in the CREMA platform architecture... 9 Figure 2: Implemented subcomponents of ODERU for runtime optimisation Figure 3: Constituents of OEE Figure 4: Example of COP for Use Case II process model and returned optimal solution. 20 Tables Table 1: Status of implemented ODERU functionality / 22

7 1 Introduction CREMA Cloud-based Rapid Elastic MAnufacturing is a project funded by the Horizon 2020 Programme of the European Commission under Grant Agreement No Within this deliverable, the process of installation and execution of the software prototype is described to support administrators and users. 1.1 CREMA Project Overview CREMA aims at simplifying the establishment, management, adaptation, and monitoring of dynamic, cross-organisational manufacturing processes following Cloud manufacturing principles. CREMA will also provide the means to integrate data from distributed locations as if the complete manufacturing was carried out on the same shop floor, by integrating extra- and inter-plant manufacturing assets and making them mobile. CREMA will be built upon concepts and methods from the fields of Virtual Factories, Serviceoriented Computing, Ubiquitous Computing, Cyber-Physical Systems, the Internet of Things and the Internet of Services, and naturally and most importantly Cloud computing. To achieve its goals, the project will define tools and approaches in these areas: Manufacturing Virtualisation& Interoperability Cloud Manufacturing Process and Optimisation Framework Cloud Manufacturing Collaboration, Knowledge and Stakeholder Interaction Framework Thus, to achieve its goals, CREMA conducts original research and applies technologies from the fields of full end-to-end integration of Cloud manufacturing, integration of manufacturing assets and corresponding data sources, the design and execution of manufacturing processes, to the end user support via collaboration and interaction tools. For more information, please refer to the project Website Deliverable Purpose, Scope and Context The purpose of this deliverable is to accompany the initial prototype implementation of the CREMA component ODERU for runtime optimisation (ORU) in T5.5. As such, its main purpose is to briefly clarify the scope of the relevant part of the ODERU prototype, and (as in D5.7) to show the download, installation instructions and the use of the API of the ODERU software. The document is limited in length as the main focus of the task is the software itself rather than its accompanying document. 1.3 Status and Target Audience This document is listed in the Description of Action (DoA) as public, which means Restricted to other programme participants (including the Commission Services), primarily since the audience of the document is largely internal. It is true, of course, that the largest audience for dissemination itself is external, but this document covers only the planning around this and not the outputs of doing this and hence its non-public nature / 22

8 1.4 Abbreviations and Glossary A glossary of common terms and roles related to the realisation of CREMA as well as a list of abbreviations is provided as an online glossary 2 / abbreviations list Structure This deliverable is broken down into the following sections: Section 1 (Introduction): Provides an introduction for this deliverable, including a general overview of the project, and outlines the purpose, scope, context, status, and target audience of this deliverable Section 2 (Scope and Relationship): Clarifies the context and scope of the first software prototype deliverable for runtime optimisation, and its relationship with other CREMA components for this purpose Section 3 (Requirements, Installation and Execution): Outlines the prerequisites, installation instructions and methods to use the software component Section 4 (Limitations, Research and further Developments): Describes the limitations of the first prototype of ODERU with focus on process optimisation at runtime Section 5 (Application to Use Cases): Describes an example application of the software component for optimisation of service-based process models at their execution time in CREMA Use Case I (Machinery Maintenance) and CREMA Use Case II (Automotive) References: Provides the details of the references mentioned in the document / 22

9 2 Scope and Relationship The ODERU component implements functionalities for process optimisation at design time and runtime. The first prototype focuses on functional optimisation of process models. This section summarizes the ODERU part for the optimisation at runtime (ORU). As depicted in Figure 1, for process optimisation at runtime, ODERU receives a request from PRU to re-optimise a currently executed process service plan of a process model. The request includes the identifier of the process model, service plan and actual process execution log. ODERU retrieves the process model description from CRI and the set of currently available semantic services from MPM excluding those which are not leasable by OSL. This is followed by the functionally optimal re-implementation of the identified remaining part of the process model instance with services. The resulting new process service plan is returned to PRU for further execution. Figure 1: ODERU position in the CREMA platform architecture The first prototype of ODERU was developed by DFKI and implements the functional process model optimisation at runtime (see Figure 2, Table 1) with a new pattern-based semantic process service composition planner, and interaction with the PRU, MPM, and CRI. The non-functional optimisation of a process service plan at runtime requires to solve the constraint optimisation problem (COP) that is included in the process model with actual input data for and from the current process execution. The computed solution of this actual COP allows to determine the optimal service parameter values for executing the (remaining part of the) process service plan by PRU. The first prototype of ODERU includes open-source 9 / 22

10 Java software for COP solving: JaCoP 4.4 4, BnB-ADOPT 5, and shopst. The JaCoP solver was adopted for solving the CREMA use case specific COPs, the BnB-ADOPT solver was re-engineered by DFKI for the execution of distributed COP solving in the cloud, and the shopst solver was developed by DFKI for approximated optimal, anytime job-shop scheduling based on simulated trading [FN16]. These solvers are not accessible via the ODERU REST API but included in the prototype software package as separate software modules. Figure 2: Implemented subcomponents of ODERU for runtime optimisation The status of the implemented functionality of the first prototype of ODERU (see deliverables D3.2 and D3.3) is shown in Table 1. Functionalities which will be improved within the next reporting period until month M30 are marked as preliminary ( P ). The integration of the COP solving software and data stream engine of the first prototype for the full implementation of non-functional optimisation of process service plans at runtime is due for the second prototype / 22

11 Table 1: Status of implemented ODERU functionality ID in D3.2 Functionality REST Method Done Late Due M30 Design Time/ Runtime ODERU_ F010 ODERU_ F020 ODERU_H 510 ODERU_ F050 ODERU_ F040 ODERU_H 520 Functionally optimal composition of process service plan for given process model in BPMN (Module S2P service selection and planning, first version with pattern-based semantic service planner PS2P) Non-functional optimisation of a process model by solving of associated constraint optimisation problem COP (Module Simulation-based service plan optimisation ) Realise (functionally compose and nonfunctionally optimise) a process service plan for a given process model Functionally optimal composition of process service plan for process instance (first version of S2P module with patternbased semantic service planner PS2P) Non-functional optimisation of a process instance Realise (functionally compose and nonfunctionally optimise) a process service plan for a process instance. PUT P D PUT X D PUT X D PUT P R PUT X R PUT X R ODERU_ F030 Approve a newly service plan computed process PUT X D/R ODERU_ F060 ODERU_ F070 ODERU_ F080 ODERU_ F100 ODERU_ F110 ODERU_ F120 Return ordered list of services implementing a given process task (service selection) Retrieve previously computed process service plan for a given process model Retrieve previously computed process service plan for a given process instance Notify about a new/updated service in the MPM component (push approach) Remove an existing service from the MPM component (push approach) Notify about a new data bucket from an external buffered stream GET X D/R GET X D GET X R PUT X D/R DELETE X D/R PUT X D/R 11 / 22

12 ID in D3.2 Functionality REST Method Done Late Due M30 Design Time/ Runtime N/A Implement a module Data Stream Processing (RDF stream reasoning) -- X R N/A N/A Example C-SPARQL queries for complex event processing in use cases for module Data Stream processing (first version) Non-functional optimisation of a given jobshop schedule (process plan) with the developed COP solver shopst as part of the module Simulation-based service plan optimisation (first version) -- P R -- P D/R 12 / 22

13 3 Requirements, Installation and Execution The ODERU component provides process optimisation at design time (ODE, see deliverable D5.7) and runtime (ORU). This section provides requirements for running the ODERU component, its installation and instructions to make the component available for interconnected components at runtime, and describes the process how to execute the installed instance of this CREMA component. The same holds for the COP solving software that is part of the first ODERU prototype software package. Since there is no graphical user interface (GUI) the component can only be used via the ODERU REST API, which is documented at The software of the first prototype of ODERU is available at (password: crema_reviewers_1234). Note: For reasons of self-containment of this document, this section is the same as in the deliverable D5.7 (Section 3). 3.1 ODERU Requirements A few preparations to install and run the ODERU component and the COP solving software in the first prototype software package have to be made. It is recommended to use a Linuxbased operating system (e.g., Ubuntu 16.04) to host the Docker 6 VM. The Docker version used for the testing is (build number 8488). The installation of Java JDK version 8 and respective setting of the PATH environment variable is required. 3.2 ODERU Installation The complete software of the first prototype of ODERU is available in the file ODERU_Prototype1.zip which is available at the location (password: crema_reviewers_1234). The ODERU is delivered in a self-contained form as a Docker image and can be obtained from the location (password: crema_reviewers_1234). The Docker image is in the file oderu.zip which is part of the complete software of the first prototype of ODERU in the downloaded file ODERU_Prototype1.zip. Once deployed in the VM every required component for ODERU is in place and no external dependencies exists with the host OS. To install the software, the Docker image has to be downloaded, expanded, and built. Following these steps, the ODERU software is launched: zip x oderu.zip. cd oderu/oderu-app docker build -f Dockerfile -t oderu. docker run -p 8080:80 -t oderu For more information, please refer to the README.md file text in the main directory of the release. The ODERU answers to the external port The basic configuration is already present in the deployed Docker image. For a final release, some configurations will be available, for example to customise the locations of the MPM and CRI components / 22

14 The software modules for COP solving are included in ODERU_Prototype1.zip as separate zip files JaCoP-UC12.zip and shopst.zip. The content of JaCoP.zip and shopst.zip should be extracted and saved in an individual base directory named JaCoP-UC12 and shopst, respectively. The executable solvers in these directories are jacop.jar and shopst.jar, respectively. 3.3 ODERU Execution Once the ODERU component (Docker image) is deployed and launched, the ODERU REST API is exposed automatically through the port 8080 (see Section 3.2), waiting for incoming connections/requests. The installed COP solver JaCoP in the directory JaCoP-UC12 can be executed with the given CREMA use case specific COPs UC1-COP (see Section 5.1.2) and UC2-COP (see deliverable D5.9, Section 5.2.2) as input data as follows: For UC1-COP solving: javac -cp jacop.jar COP1.java java -cp.;jacop.jar COP1 For UC2-COP solving: javac -cp jacop.jar COP2.java java -cp.;jacop.jar COP2 The installed COP solver shopst in the directory shopst can be executed for approximated optimal job-shop scheduling with, for example, the Hurink benchmark as follows: java jar shopst.jar -b benchmarks\hurink_data\vdata\la40.fjs -r 10 -si 500 -tl 60 -disp RNDRND -c TOPC -ml 5 -gui true with parameters (see explanation in params_definition.pdf) -b path to test data file, otherwise a random scenario is generated -r number of simulated trading rounds -si -tl number of iterations per simulated trading round maximal execution time in minutes -seed basis of random number generation -disp disposition rule for initial planning, e.g.: RND: random, FASFS: first at shop first served, SPT: shortest processing time -c cost function, e.g.: -ml -gui TOPC: total operation completion date, TOPL: total operation lateness, TOPT: total operation tardiness, TOPSL: total operation slack time maximal number of trading levels shows GUI (true, false) 14 / 22

15 4 Limitations, Research and further Developments The first prototype of ODERU provides a complete set of functions for optimal semantic service-based implementation of annotated process models as specified in the deliverables D3.2 and D3.3 (see Section 2, Table 1), and software for solving process relevant constraint optimisation problems in the CREMA use cases at runtime. The improvements of the ORU part of the final prototype of ODERU to be developed until month M30 are as follows: Integration of the COP solving software modules with the component workflow such that the optimal service parameter values and bindings for an optimal execution of the (identified remaining part of the) process service plan are returned to the PRU. Interaction with the MON, MPM, BDA via the data stream engine of ODERU for leveraging actually detected changes of relevant service parameters for the reoptimisation of process service plans given by the PRU. Support of approval of re-optimised process service plans by a human user before they are returned to the PRU. 15 / 22

16 5 Application to Use Cases 5.1 Optimisation at Runtime in Use Case I The process models of the CREMA Use Case I are concerned with the maintenance of metal press machines by the user partners FAGOR and GOIZ (see deliverable D4.2, Annex 1). The execution of a maintenance process may fail due to the following reasons: The materials needed to carry out the maintenance action do not reach their destination, since they are, for example, retained in customs or even got lost during their transport The materials sent are not those that are needed to carry out the maintenance, since they have the wrong references, or the dimensions of the parts are different from those requested, or the parts do not fit with the machine The reason of the maintenance action is not correct and only discovered on arrival of the maintenance team (false alarm) Relevant services for maintenance became unavailable or their QoS description became invalid before their execution Any of these reasons causes the stopping of the execution of the maintenance process service plan by PRU. In this case, a specific program MPP for maintenance planning of the user partners is invoked in order to allow the user to change the requirements for maintenance. Functional optimisation. As at design time (see D5.7, Section 5.1.1), PRU calls ODERU for re-optimisation of the stopped process service plan. ODERU identifies the remaining part of the process service plan and computes a functionally optimal variant of it but with available services that are also currently leasable as reported by OSL on request. The first version of the ODERU component returns only this process service plan to PRU for further execution. Non-functional optimisation. In addition, as at design time, the COP solver JaCoP of ODERU can be used to compute an approximated optimal solution of the use case-specific UC1-COP with actual input data (see deliverable D5.7, Section 5.1.2). These input data include changes of user requirements made by the operator of the press machine with the MPP, and required actual data which is extracted by ODERU from the service descriptions (e.g., skills, location, special tools, travel costs). The MPP passes the changed user requirements to the PRU for its re-optimisation request for ODERU. The computed solution of the updated UC1-COP is returned used for determining the optimal service parameter values for executing the new process service plan by PRU (see D5.7, Section 5.1.2). 5.2 Optimisation at Runtime in Use Case II The process models of the CREMA Use Case II are concerned with the production of car exhausts by the user partner TCO (see deliverable D4.2, Annex 3). Functional optimisation. The execution of the exhaust production process may be stopped by PRU due to a failure of the welding robot service. In this case, PRU requests ODERU for a functional re-optimisation, which is then performed as at design time (see D5.7, Section 5.2.1) but with relevant services that are currently leasable. For example, the failed robot service is replaced in the new process service plan with another functionally optimal welding 16 / 22

17 robot service, and this re-optimised process service plan is returned to PRU for further execution. Non-functional optimisation. The non-functional optimisation of a stopped production process in batch mode aims at the maximisation of its OEE (Original Equipment Effectiveness) value. The COP solver JaCoP of ODERU can be used to compute an approximated optimal solution of the use case-specific COP (UC2-COP) with actual input data. These data (functions) are computed by TCO with monitored robot cell data. At TCO an engineer should solve the UC2-COP at the end or before the start of a new batch of the running exhaust production process in order to be able to work with the optimal process service parameters in the next batch. 7 The second prototype of ODERU will receive these data from TCO (IndustreWeb) for solving the respective UC2-COP variant dynamically via its RDF stream processing module. It uses the computed solution of the UC2-COP for determining the (non-functionally) optimal service parameter values for the execution of the process service plan. These optimal service variable assignments, data flow bindings, and the maximal OEE value will be returned together with the new process service plan to PRU for further execution. The engineer will have to approve this proposed optimal solution before its execution. Use case II specific constraint optimisation problem. The constituents of OEE are availability, performance and quality (see Figure 3), each of which defined in the following as individual objectives of the multi-objective COP in this use case. Figure 3: Constituents of OEE The process model for car exhaust production by the user partner TCO is described in deliverable D4.2 (Annex 3) in detail. In practice, the execution of the production process may fail due to the following reasons: (a) the torch is spattered, (b) the tooling is spattered, (c) the wire stick is melted, and/or (d) the torch is melted. Availability of the robot cell measures its operating time in relation to the planned production time. A setup and adjustment of the cell is not required, because the production batches deal with one particular type of exhaust only, and an equipment failure is captured in terms of the mean time before failure (MTBF) of the production line. In the following, it is assumed that no equipment failure occurs such that the availability of the robot cell is guaranteed but the related MTBF is maximised instead. The aim is to increase the difference between the actual batch production time and the point at which an equipment failure is expected to occur 7 Each batch may be considered as one execution of the process service plan with new material. 17 / 22

18 first, which, in turn, may require the clean-up and reset of the robot cell, thus reducing its availability and therefore the OEE value. 8 Performance of the robot cell measures a target cycle time of the welding robot in relation to the actual cycle time which is determined by the torch speed. Quality of the production measures the number of defective parts per million (DPM) and two types of defects (weld penetration, spatters). Every piece that shows any of such defect is rejected, thus reducing the production quality. Definition 1: (Constraint optimisation problem UC2-COP) Let I Î Ñ the welding current S Î [1/2,.. 2/3] the torch speed F Î Ñ the wire feed rate ',''()'*,- Heat density hd I, S =. where the constant is the weld penetration. The OEE constituents are defined as follows: Availability of welding robot in terms of its Mean-Time-Before-Failure (MTBF): MTBF I = min ( MTBF 78 I, MTBF 9: I, MTBF :8 I, MTBF :;8 I ) where MTBF 78 I = 40,41 + 1,02 I * 0, I F + 0, I ( is the MTBF for the wire stick, MTBF 9: I = 15,33 0,1465 I * + 0, I F 0, I ( MTBF for melted torch, MTBF :8 I = 932,6 8,664 I * + 0,02678 I F + 0, I ( MTBF for spattered torch, and MTBF :;8 I = ,29 I * + 0,0405 I F 0, I ( MTBF for spattered tooling. Regarding these partial definitions and intersection points, and MTBFtos(I) being negligible in practice, the MTBF is defined as follows: MTBF I = 40,41 + 1,02 I * 0, I F + 0, I ( I P 78,9: ,29 I * + 0,0405 I F 0, I ( P 78,9: < I P 9:,:8 932,6 8,664 I * + 0,02678 I F + 0, I ( I > P 9:,:8 In the next version of UC2-COP, the signature of MTBF will be extended with more independent variables (torch speed, wire feed) than just the current I. 8 Although in this first version of UC2-COP, the MTBF is considered instead of availability, and the values of both MTBF and performance are not in [0, 1] the term OEE (which value is in [0, 1]) is used in the following 18 / 22

19 Performance of welding robot: PERFORMANCE = T U V,W X T U = Z *,[ where σ ] denotes the target cycle time, and the actual cycle time is determined by the torch speed S in relation to an ideal speed represented by the constant 1.5. In the next version of UC2-COP, this formulation of performance will be improved. Quality of production: QUALITY = 1 ε where the error rate ε ε [0..1] is the number of defective parts per million (DPM) divided by 1M. The rate of defective parts per million is defined as DPM I; S = DPM 7m I; S + DPM 8 I; S with DPM wp for weld penetration 9 : DPM 7m I, S = I * I F + 10,62 I ( +147,1 hd I, S 1,765 hd I, S F + 0,00684 hd I, S ( I 200 hd I, S I * I F 10,61 I ( +147,1 hd I, S 1,765 hd I, S F + 0,00684 hd I, S ( I > 200 hd I, S I * I F + 10,62 I ( +256,5 hd I, S 2,292 hd I, S F 0,0067 hd I, S ( I 200 hd I, S > I * I F 10,61 I ( +256,5 hd I, S 2,292 hd I, S F 0,0067 hd I, S ( I > 200 hd I, S > 100 and DPM S for spatters: DPM 8 I; S = , I* I F + 1,731 I ( +2,862 hd I, S 0,02828 hd I, S F + 0, hd I, S ( The problem of maximising the OEE value of the exhaust production process is defined as follows: max q Availability x, Performance x, Quality(x) s.t. 120 I 250 current (in Ampere) 6 F 10 wire feed (in meter/sec) 1,2 S 2,3 torch speed (in meter/sec) MTBF I t mˆ; QUALITY 1 ε : where x denotes the set of parameters {I, W, S}, ε : ε [0..1] the accepted tolerance in quality, and t prod the production time required to finish the batch. The single-objective variant of the above COP with same constraint system is defined as follows: max x (w A *Availability(x) + w p *Performance(x) + w Q *Quality(x)), with w A + w P + w Q = 1. 9 For the UC2-COP demo version in the first prototype this DPM is restricted to its first case 19 / 22

20 Example of UC2-COP solution. In the example for Use Case II, the functionally reoptimised part of the process service plan includes the new welding robot service Start Production which implements the process task Execute product welding process (see Figure 4). The process model description also includes the associated optimisation problem UC2-COP and an input data set with which this problem has to be solved in order to obtain the optimal parameter values for executing the process service plan by PRU. Figure 4: Example of COP for Use Case II process model and returned optimal solution As mentioned above, the open-source COP solver JaCoP of the first prototype of ODERU can be used to compute an approximated optimal solution of the UC2-COP. As shown in Figure 4, for the given UC2-COP instance based on monitored robot cell data during one batch by TCO, JaCoP computes the maximal OEE value of 2.51 for the process service input parameter values 10 for F (WireSpeed), for I (ElectricityIntensity) and 1.2 for S (FeedRate/Torch speed rate). The second prototype of ODERU will return these values, the data flow bindings and the OEE value together with the process service plan to PRU. The engineer may approve the computed optimal service parameters for the process service plan to be executed for next batch of exhaust production. 20 / 22

21 21 / 22

22 References [N16] F. Y. Nedwed (2016) "Scheduling Optimisation in Flexible Job Shops with Simulated Trading for Agent-Based Cyber-Physical Production Systems" Master Thesis, Saarland University, Computer Science Department, Saarbrücken, Germany (in German) 22 / 22