centurio.work - Industry 4.0 Integration Assessment and Evolution Juergen Mangler1 , Florian Pauker2 , Stefanie Rinderle-Ma1 , Mathias Ehrendorfer3 1 University of Vienna, Faculty of Computer Science, Research Group Workflow Systems and Technology, Vienna, Austria, {juergen.mangler, stefanie.rinderle-ma}@univie.ac.at 2 EVVA Sicherheitstechnologie GmbH, Vienna, Austria, f.pauker@evva.com 3 CDP GmbH, Vienna, Austria, matthias.ehrendorfer@acdp.at Abstract. The introduction of Cyber-physical Systems (CPS) in the manufacturing domain leads to new concepts of how things such as ma- chines can interact. While on the traditional shop-floor the communica- tion is restricted by the strict concepts of the automation pyramid, in CPS everything can be connected to everything. While the connections between machines, computing resources and UIs (humans) can be explicit (i.e., semi hard-coded connections of components through a service bus), the alternative is a context of how things are connected, in order to foster maintainability and understandability as well as to enforce the notion of a loosely coupled system. Therefore, the Workflow Systems and Tech- nology Group of the University of Vienna in cooperation with the CDP GmbH is developing a process-based framework utilizing the BPMN no- tation for orchestration and control of manufacturing use-cases. This submission focuses on a 4-step integration approach which is intended to allow small and medium companies a defined evolution towards flexible and reliable digitalization and automation, utilizing BPM technology. In order to explain the ideas behind our approach, we present a real-world scenario realizing the interaction between a lathe, a robot and a loading station for an autonomous transport system, which is common for our partners and customers. 1 Introduction Production companies find themselves in a difficult situation. They are faced with smaller batch sizes, more variants and reduced throughput time. Digital- ization and smart factories [10,12] are supposed to be the catalyst to solve all these problems. Digitalization, in particular, is intended to lead to (i) a higher transparency of the processes in the company, (ii) better traceability of the prod- ucts, and (iii) increased productivity caused by a better understanding of the processes. Copyright © 2019 for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0). Juergen Mangler, Florian Pauker, Stefanie Rinderle-Ma, Mathias Ehrendorfer Yet in the real world introducing the changes to achieve features i) – iii) requires (1) human resources (programmers and domain experts), (2) a detailed action plan, and (3) to potentially interrupt the ongoing production. While the benefits of digitalization are potentially high, especially for small and medium enterprises (SME) it is hard to find the time, money and human resources to do so. A further issue is that the gap between information systems and the shop-floor [8] – the Business Manufacturing Gap [5] – proves hard to close, especially for highly customized production, as it requires programmers with intimate domain-knowledge. To overcome these problems the WST Group of the University of Vienna is working together with the CDP Center for Digital Production GmbH on the centurio.work framework [7]. The idea of the framework is to describe everything on the shop-floor with BPMN processes, to enact this processes with a process engine, and to describe a step-by-step integration approach. One major goal is to reduce the effort of integrating machines, humans and information systems, particularly for SME. For this, we developed the centu- rio.work framework and a step-by-step integration approach which allows for – Assessment of the current level of integration. – Steady build-up of domain knowledge for developers. – A means for developers and domain-experts to cooperate through BPMN process models, producing reusable artefacts (process models) for evolving digitalization / automation efforts. – Defining milestones for and structuring evolving digitalization / automation efforts. The case presented in this paper introduces the centurio.work framework and the connected step-by-step integration approach and how it is applied to a real-world manufacturing scenario deployed in a pilot factory1 , closely tracking the requirements provided by the partners of the CDP GmbH2 , especially the EVVA Sicherheitstechnologie GmbH3 . We are focusing on a robotized manufacturing cell, consisting of an industrial robot by ABB Ltd., a lathe by EMCO GmbH and a custom designed loading station. Additional elements in the cell (which are not discussed in this sub- mission) are a presetter by Zoller GmbH, a coordinate measuring machine by Micro-Vu Europe GmbH, a cobot by Universal Robot (UR) and an automated guided vehicle (AGV) from Neobotix GmBH. Figure 1 depicts the simplified layout of the scenario. The red area shows the machines covered in this paper. This flexible manufacturing cell produces a part called “GV12” which is part of a valve from a gas motor. The complexity of this product is caused by the small tolerances, which necessitates the complex overall scenario. In Sect. 2 we describe challenges as well as methodological and technical frameworks, that guide the ongoing development of our solutions. In Sect. 3 we 1 http://pilotfabrik.tuwien.ac.at/en/ 2 https://acdp.at 3 https://www.evva.com/int-en/ centurio.work - Industry 4.0 Integration Assessment and Evolution Measuring Machine AGV Robot Loading Robot Station Scenario Sub-set Presetter Lathe Machine Bar Loader Fig. 1: Simplified layout scenario describe the step-by-step plan-of-action when introducing BPM technology with our partners and customers, in order to give us the flexibility and a safety-net to explore various degrees of automation. In Sect. 4 we present a set of process models that realize a subset of the scenario mentioned above: the machining by a lathe and handling by a robot, include human interactions with the system. We conclude with lessons learned in Sect. 5. 2 Situation faced Based on the day-to-day work with our customers and partners, we abstracted the need for a step-by-step approach to digitalization, covering the following topics. We need step-by-step ... – ... introduction of BPM notation and technology, to introduce a unified way of describing manufacturing orchestrations, while not disrupting ongoing production as well as stable and working production procedures. – ... build-up of domain knowledge when working with involved information systems (ERP, MES, CAD-CAM) and machines, which are often tailored to fit the produced items. – ... closing of digitalization gaps, when dealing with human-machine interac- tion or dealing with external partners. This step-by-step approach is intended to ensure the natural evolution of how (1) processes and sub-processes are structured, and how (2) the functionality of individual task is defined. This is especially important, as digitalization should not be seen as a step a company takes, but as a progressive journey. While one task, for example measuring the quality of a produced part, might at first be performed by (a) a human, it might later be performed fully automatic by a (b) machine, and Juergen Mangler, Florian Pauker, Stefanie Rinderle-Ma, Mathias Ehrendorfer eventually be replaced by (c) a prediction algorithm which operates based on data collected earlier. In all these cases, the process model stays the same and the label of the task stays the same. But functionality realized by the task changes. The progress for this particular case thus might be from (a) Worklist component, to (b) OPC UA4 machine adaptor component, to (c) Data Analytics (DA) component. In order to design a robust system, it has to be taken into consideration that individual components might fail, e.g., when (c) has no access to data, because of some data collection problem, it might be very well necessary to switch back to (a). Also, situations where over-automation5 becomes a problem should be planned for. We thus conclude that digitalization/automation should be tackled as a step-by-step journey, where decisions can easily be reverted or circumvented until a suitable problem solution presents itself. Thus our ongoing work tries to standardize the digitalization journey, based on already available BPM technology, and based on standard digitalization mod- els and architectures such as [3], or [9]. In the remainder of this section we will describe components which are part of the scenario outlined in Sect. 1, as well as technologies, standards and methods which were considered. 2.1 BPMN-Based Automation As proposed by [4] CPS-based automation architecture will replace the automa- tion pyramid architecture (see Fig. 2). This new architecture can be seen as kind of network where different functions of the previous layers are connected. In the automation pyramid architecture only modules on neighbouring layers can com- municate with each other, which gives some kind of structure. This constraint does not exist in a CPS-based automation, so there is a need for some kind of other system which creates the context between the functions. Enterprise ressource planning level s ||| Plant management level {..} ||| + s Process control + level Control ||| ||| (PLC) level Field level BPMN/Process-based Automation Hierarchy CPS-based Automation Automation Fig. 2: CPS-based and BPMN based Automation [7] 4 https://opcfoundation.org/about/opc-technologies/opc-ua/ 5 https://www.businessinsider.de/tesla-robots-are-killing-it-2018-3 centurio.work - Industry 4.0 Integration Assessment and Evolution As presented in [7] a BPMN-based automation can be the solution. Fig. 2 shows the architecture. Processes seen as functions can be coupled and thus grant some context. This reduces the complexity and increases flexibility, transparency and maintainability. The result of this is centurio.work6 . centurio.work is an orchestration frame- work based on BPMN processes [7]. It allows context-based dynamic orchestra- tion of machines, humans and software services. These are the key features of highly adaptable manufacturing processes necessary for realizing a production based on Cyber-Physical Production Systems. 2.2 Information Systems Manufacturing companies are faced with numerous software solutions classified to their functionality. Fig. 3 shows the different systems from commercial process to technical processes. Commercial processes ERP FIN DIS PPS MES Customer Suppliers SCM Production CRP CAM / NC DMS CAD / CAE PDM PLM Technical processes Fig. 3: Required Software systems in a production company [6] Traditional systems are generally not yet prepared for the decentralization necessary for realizing self-controlling production with Cyber-Physical-Systems [11]. Solutions must become ”smarter” and more flexible. Additionally, the boundaries between the different systems are blurring. E.g. modern ERP systems are increasingly being given executive and controlling roles in addition to their production planning role. 2.3 Theoretical Framework Important for realizing a modern production is standardization, to combat a plethora of competing approaches and technologies. Fig. 4 shows the Reference 6 https://centurio.work Juergen Mangler, Florian Pauker, Stefanie Rinderle-Ma, Mathias Ehrendorfer Architecture Model Industry 4.0 (RAMI) standardized as DIN SPEC 91345 [3]. It is a three-dimensional map that describes a structured approach to the topic “Industry 4.0”. It has three dimensions, (i) the product life-cycle based on the IEC 62890, (ii) the hierarchy levels based on IEC 62264 and IEC 61512 and (iii) the functional hierarchy in the third dimension. Life C IEC 6 ycle & V vels 512 2890 alue Strea r chy Le IEC 61 m Hiera 264 / / 62 Business IEC Functional Information Communication Integration Asset Co Ente nnected Wor rpris Wor Stat k C e ld ion ente Typ Con rs e Field trol Dev Prod Dev ice Inst uct ice anc e Fig. 4: Reference Architecture Model Industry 4.0 [3] Our solution, centurio.work, is inspired by the design and realizes the run- time features formalized by RAMI. Type and Instance correlate with well-know BPM model and instance concepts. centurio.work offers services on the Busi- ness, Functional, Information and Communication layer. The top three levels are covered by a process engine, communication is realized by a set of reusable modelling artefacts (tasks) which implement standard protocols such as OPC UA, MQTT, REST or even proprietary protocols such as Siemens S7. These tasks can cover all hierarchy levels from Product to Connected World. The reason to imagine centurio.work in the context of RAMI is, that in modern manufacturing scenarios experts from different domains have to work together. RAMI provides the common vocabulary for people with different do- main knowledge to talk about a common goal. 3 Action Taken In order to tackle the needs mentioned in Sect. 2, we developed a step-by-step integration approach, which encompasses four evolution steps: 1. Soft Integration 2. Process Modelling 3. Augmentation centurio.work - Industry 4.0 Integration Assessment and Evolution 4. Control In the remainder of this section we will explain how going through these evolutions allows for a smooth realization of the scenario outlined in Sect. 1, Fig. 1. This section also explains process models contained in Sect. 4 which are the manifestation of the implemented scenario. 3.1 Evolution 1 - Soft Integration Evolution step 1 focuses on a soft integration approach. By design this step is intended to not disturb an existing production. The goal is to model and monitor what is going on on the shop-floor for individual easy to identify resources. This includes: a) Tracking new orders from an ERP system. b) Sourcing of material and scheduling of production resources from an MES system. c) Collecting data from all machines, robots and other equipment on the shop- floor. This will result in simple runnable process models that collect and structure data – in effect very similar to software like [1,2]. Most resources already log data into their own private data-tanks, the afore- mentioned software concentrates on providing adaptors to collect, combine and present data from these data-tanks. For our approach this is just a side-effect which materializes in Evolution 2. Instead of an ex-post view on data the goal is to drive production. The context for the collected data are processes, and in Evolution 1, the initial contextualization is done. Of course the challenge is to connect to custom developed and highly special- ized machines and writing the glue (adapter) software that realizes something such as the “Monitoring” depicted in Fig. 5. For this particular task, we experi- mented with OPC UA interfaces, as well as collecting data through the Siemens S7 communication protocol. The result is a set of standard tasks, that can be used and parametrized during modelling, and reused for future customers. 3.2 Evolution 2 - Process Modelling Evolution step 2 still focuses on not disturbing the manufacturing. The difference to the previous step is, that the focus is now on how the resources interact with each other. Main points which should be covered are: a) How are orders scheduled? b) How does the sourcing of material interact with the scheduling? c) Which machines participate in which order in the manufacturing of a part? Juergen Mangler, Florian Pauker, Stefanie Rinderle-Ma, Mathias Ehrendorfer The result is the knowledge of how things work together. The contextualiza- tion of existing data flows is now fully realized through BPM technology. The data in the private data-tanks is ignored, the data flowing through the process engine runs the process such as the one shown in Fig. 6b. In this evolution step the task “Manually Measure” seen in Fig. 6b is a mere placeholder for something that a human does. In this evolution, the process depicted in Fig. 6b checks if a human presses a button that starts the machine, and subsequently instantiates the collection process mentioned in Evolution 1. 3.3 Evolution 3 - Augmentation Evolution step 3 focuses on digitalization gaps on the shop-floor, i.e., mainly targets the interaction of humans with machines. As the processes passively monitor what is going on for the production of individual parts, it becomes possible to introduce active functionality. For example a machine operator might take notes on a piece of paper about the quality of produced parts, and later on write a document in his office that is sent to the customer as a protocol. Augmentation can take the form of placing a screen at the machine, where the user is asked to (1) directly input the data for each task with a keyboard, or (2) giving him a connected caliper to avoid keyboard input. Thus goals are: a) Establishing a set of supporting User Interfaces (UI). b) Setting up independent scheduling – model logic that shows e.g. machine setup UIs if necessary. c) Quality Assurance – capture data (e.g. notes) from part prototyping and production phases. d) Semantic Machining – capture information about repair of machines and machined parts. For all of these goals, the process models are to be extended. The desired result is to close existing semantic and digitalization gaps that are typically filled by humans and their knowledge. In this evolution step the task “Manually Measure” (cf. Fig. 6b) is replaced by a user interface which can be parametrized from the process model to collect certain indicators (e.g., the diameter of a produced part). 3.4 Evolution 4 - Control Evolution step 4 is the final expansion state of centurio.work. In this phase centurio.work assumes control of the manufacturing. Typical functions are: a) Management of software artefacts necessary for production e.g. NC-programs. b) Triggering the execution of production based on scheduling data. centurio.work - Industry 4.0 Integration Assessment and Evolution The result is that humans are guided and are supervising production, not driving it by their actions such as pressing buttons. As can be seen in the process presented in Fig. 6a the humans are scanning a product code to start produc- tion, “MT45 Start” is a sub-process that actively starts the machine, while in Evolution 3 it might have triggered an UI to tell the user to press that start button (in evolution 2 nothing of this existed). 4 Results Achieved The (BPMN) process models7 digitalization and automation effort of the real- world scenario presented in Sect. 1. Particularly, they realize the scenario de- picted by the red area in Fig. 1, i.e., the interaction between lathe, robot, and loading area. Fig. 5 shows how the process models presented in this section (see ) are connected, as well as for which evolution they have been created (see ). In order to see the interaction depicted in processes models, we also provide a video8 ., video which demonstrates the concepts explained below. Orders & Items Handling & Transport Fig. 6a Fig. 7 ≥4 ≥4 ≥2 ≥1 ≥1 Manufacturing Steps MI / HMI Monitoring Fig. 6b Fig. 5: Process Models: Connections & Evolution (Red Bubble) Fig. 6b shows which steps are necessary to produce on single GV12 item. It spawns sub-processes for a truing operation on the lathe, then shows a UI for manually measuring the parts, and finally collects data from an additional automatic measuring machine. In an Evolution 4 scenario, this a spawned by a process model such as Fig. 6a. In lower evolutions Fig. 6a did not exist, e.g. in Evolution 1 no human inter- action was modelled, but instead “MI / HMI” just detected he pressing of the start button on the lathe and then spawned “Monitoring”, as depicted in Fig. 5. Fig. 7, such as 6a, is a process that has been introduced much later, in Evolution 4. As depicted in 1, a robot picks produced items out of the machine, and puts it on a tray, to be transported to the manual measurement station, and subsequently to the automatic measurement station. 7 Please note the two differences to standard BPMN for the following figures: (1) the diagrams are auto-layouted by our designer to improve comparability between model versions, thus the labels are left of the task, not on the task itself; (2) conditions for decisions, are depicted by {..} on the edge to improve usability on touch screens 8 https://centurio.work/casts/gv12.mp4, Evolution 3 Juergen Mangler, Florian Pauker, Stefanie Rinderle-Ma, Mathias Ehrendorfer ◤ Scan GV12 s ◤ data.num > 0 && data.trays.any? (⭱) ◤ Get Machine State s ◤ exclusive {..} ◤ data.state == 'Cancelled' ◤ Spawn GV12 Production ◤ GV12 Turn ◤ MT45 Start ◤ Signal Machining End ◤ Wait For Machining End ◤ Manually Measure s ◤ GV12 MT45 Take Out s ◤ exclusive s ◤ Next Position on Tray {..} ◤ data.qc1_raw.inject(0){ ... } == 0 ◤ GV12 IRB2600 Put On Tray s ◤ Next QR ◤ Measure with MicroVu s (a) Coordinate Prod. & Robot Han- (b) Prod. One Single Item dling Fig. 6: Part Specific Processes It shows the interaction with a low-level robot-interface. Robot programs are managed and loaded from a GIT repository. This includes programs for extracting the part from the machine, and placing it on a tray, as shown in Fig. 6a, tasks “GV12 MT45 Take Out” and ”GV12 IRB2600 Put On Tray”. After the programs have been assembled they are load, started, and the robot is monitored until successful completion of the tasks. The robot handling is always to be triggered after the step “GV12 Turn” in Fig. 6b, thus “Signal Machining End” sends a message back to the process shown in 6a. 5 Lessons Learned BPM technologies proved very efficient for driving digitalization and automation efforts on the shop-floor. The strategic value as perceived by our customers is the high flexibility when combining different technologies (as required by a hetero- geneous shop-floor) while still providing maintainability and understandability of the resulting system. This maintainability and understandability is a direct result of (1) the expres- siveness of the BPMN notation, and the (2) use of process engine that allows domain-experts to directly try and modify models and see the effects in the real-world. centurio.work - Industry 4.0 Integration Assessment and Evolution ◤ data.state.to_s == "MotorsOn" && ... ◤ data.state.to_s == "MotorsOn"... ◤ data.state.to_s != "MotorsOn" ◤ data.urls.length > 0 (⭱) ◤ Assemble Porgram ◤ Set Fetch Endpoint ◤ Assign Program ◤ Fetch Program ◤ Set Program ◤ Check State ◤ Not started ◤ exclusive ◤ true (⭱) ◤ Logon ◤ Start s {..} {..} s {..} s s s s Fig. 7: Generic Machine-Tool and Robot Processes (1) While an exploratory digitalization and automation approach proved success- ful, it became clear that streamlining the exploration can yield many advantages: – Structured assessment of the current situation, regarding the integration of different machines, can highlight problem areas. – Monitoring the progress in terms of the proposed Evolution steps, gives a quick situation overview, and allows to efthe old UI drivenllocate existing human resources. For example Evolution step 1+2 are potentially require the most software development resources. – After achieving Evolution step 1, Data Analytics efforts can start. When looking at Fig. 5 it is important to note “Monitoring”, “Manufactur- ing Steps”, “MI (Machine Interface) / HMI (Human Machine Interface”, and “Handling and Transport” have not changed much after they have been created: – At first “MI” was directly linked to “Monitoring”. As for each order / item a specific NC Program is started, it is just necessary to monitor the start of that program. “Monitoring” never changed again. – “Manufacturing Steps” was then linked to “MI”, to track the multiple ma- chining steps in the sequence they occurred. – After that, “MI” was transformed to “MI / HMI”, and “Manufacturing Steps” was extended to include UIs for collecting manual measurements. – The introduction of “Order & Items” did free the user from pressing the button on the lathe, as the lathe is started automatically based on input from an ERP. But the “MI” part is still the same, because pressing the button physically, or triggering the machining through software is the same. – “Order & Items” was evolving over multiple iterations, with the introduction of new hardware. Juergen Mangler, Florian Pauker, Stefanie Rinderle-Ma, Mathias Ehrendorfer Also especially interesting for our partners proved, that versions of the func- tionality developed for tasks in Evolution 1, 2, 3, 4 still have their purpose as a fallback mechanism if problems during production occur. Easy switching back individual tasks from full automation to human work proved to be very trans- parent and simple to achieve, while introducing no additional complexity for the factory operators or the process models. While switching back, when done manually is time consuming, luckily it can be done through logic in the process. E.g. when the lathe can not be started automatically (error detection logic), the old UI driven sub-process can be spawned. Acknowledgments: This work has been partially supported and funded by the Austrian Research Promotion Agency (FFG) via the “Austrian Competence Center for Digital Production” (CDP) under the contract number 854187. References 1. MindSphere: The Cloud-Based, Open IoT Operating System, https://www. siemens.com/global/en/home/products/software/mindsphere.html, [Accessed 2019-02-15] 2. Predix Platform | GE Digital, https://www.ge.com/digital/iiot-platform, [Ac- cessed 2019-02-15] 3. DIN SPEC 91345:2016-04 Referenzarchitekturmodell Industrie 4.0 (RAMI4.0). Tech. rep., DIN Deutsches Institut für Normung e. V. (2016) 4. Bettenhausen, K.D., Kowalewski, S.: Cyber-physical systems: Chancen und Nutzen aus Sicht der Automation. VDI/VDE-Gesellschaft Mess-und Automatisierung- stechnik pp. 9–10 (2013) 5. Gifford, C.: The Hitchhiker’s Guide to Manufacturing Operations Management: ISA-95 Best Practices Book 1.0. ISA, Research Triangle Park, NC (Jun 2007) 6. Kletti, J.: Manufacturing Execution System-MES. Springer (2007) 7. Pauker, F., Mangler, J., Rinderle-Ma, S., Pollak, C.: centurio. work - Modular Se- cure Manufacturing Orchestration. In: Business Process Management Workshops. pp. 649–661. Lecture Notes in Business Information Processing, Springer, Berlin, Heidelberg (2018) 8. Rother, M., Shook, J.: Learning to See: Value-Stream Mapping to Create Value and Eliminate Muda : Version 1.3 June 2003: Value Stream Mapping to Add Value and Eliminate Muda. Lean Enterprise Institute,US, Cambridge, Mass, spi edn. (1999) 9. SCE-Cisco-IBM Sgra Team 2011: Smart Grid Reference Architecture. Interna- tional Business 1, 1–118 (2011) 10. Schuh, G., Gottschalk, S.F., Nöcker, J.C., Wesch-Potente, C.: Flexible Vernetzung statt starrer Integration : die Zukunft der digitalen Fabrik. wt Werkstattstechnik online 98(3), 127–131 (2008) 11. e. V. Fachverband Automation, Z.Z.E.E.: Industrie 4.0: MES – Voraussetzung für das digitale Betriebs- und Produktionsmanagement. Tech. rep., ZVEI - Zen- tralverband Elektrotechnikund Elektronikindustrie e. V. Fachverband Automation (2017), https://bit.ly/2HPPF6P, [Accessed 2019-05-31] 12. Westkämper, E., Zahn, E. (eds.): Wandlungsfähige Produktionsunternehmen: Das Stuttgarter Unternehmensmodell. Springer-Verlag, Berlin Heidelberg (2009)