1 Introduction

Production companies are in a difficult situation, as they face decreasing batch sizes, increasing variants, and reduced throughput time. Digitalization and smart factories (Schuh, Gottschalk, Nöcker, & Wesch-Potente, 2008; Westkämper & Zahn, 2009) are supposed to help solve these problems. Digitalization in particular is intended to increase the transparency of the company’s processes, traceability of the products, and productivity because of improved understanding of the processes.

However, in the real world, introducing changes to achieve these increases requires human resources (programmers and domain experts), a detailed action plan, and possibly interrupting production. While the benefits of digitalization can be significant, especially for small and medium-sized enterprises (SME), finding the time, money, and human resources to digitize can be difficult. Another issue concerns the gap between information systems and the shop floor (Rother & Shook, 1999)—the Business Manufacturing Gap (Gifford, 2007)—which is challenging to close, especially for highly customized production, as it requires programmers with intimate domain knowledge.

To overcome these problems the Workflow Systems and Technology (WST) Group at the University of Vienna is working with the CDP Center for Digital Production (CDP) GmbH on the centurio.work framework (Pauker, Mangler, Rinderle-Ma, & Pollak, 2018). In general, centurio.work is used to describe processes on the shop floor with BPMN, to enact these processes with a process engine, and to describe a step-by-step integration approach. The goal of the research presented in this chapter is to reduce the effort in integrating machines, humans, and information systems, particularly for SMEs, based on the centurio.work framework. The framework’s step-by-step integration approach facilitates:

  • Assessment of the current level of integration

  • A steady build-up of domain knowledge for developers

  • A way for developers and domain experts to cooperate through BPMN process models to produce reusable artifacts (process models) for evolving digitalization/automation efforts

  • The process of definition of milestones for evolving digitalization/automation efforts and structuring these efforts

The case presented in this chapter introduces the step-by-step integration approach based on the centurio.work framework. The chapter shows how the approach was applied to a real-world manufacturing scenario in a pilot factoryFootnote 1 that closely tracked the requirements of the CDP GmbHFootnote 2 partners, especially the EVVA Sicherheitstechnologie GmbH.Footnote 3 The chapter, therewith, serves as an example to show how innovative process technology inspires modern BPM approaches and how such technology can be put to action in order to realize important strategic objectives (vom Brocke, Mendling, & Rosemann, 2021).

Figure 1 depicts the layout of a robotized manufacturing cell scenario that consists of a cobot by Universal Robot (UR10e) (2), a Hyperturn65 Powermill (HT65PM) lathe by EMCO GmbH (1) and a custom-designed loading station (3).

Fig. 1
figure 1

Scenario layout

Full size image

This flexible manufacturing cell produces parts for mechanical locking systems. The product’s complexity is the result of its small tolerances and the customer-specific changes that lead to small lot sizes.

Section 2 describes challenges, as well as the methodological and technical frameworks that guide the development of our solutions. Section 3 describes the step-by-step plan of action when BPM technology is introduced to our partners and customers so we can have the flexibility to explore various degrees of automation and a safety net while we do so. Section 4 presents a set of process models that realize a subset of the scenario, the machining by a lathe and handling by a robot, including human interactions with the system. We conclude with lessons learned in Sect. 5.

2 Situation Faced

EVVA is one of Europe’s leading manufacturers of mechanical and electronic locking systems. Custom machines and custom assembly stations are used in producing these systems, as the production process is complex because of the use of proprietary interfaces for each kind of equipment and the high number of small parts that result in complex assembly. Everything is hierarchically structured based on the automation pyramid; that is, there is a strict separation between software that operates the machine, software that controls the sequence in which parts are made, and ERP-level information about orders. We chose a workflow-based orchestration to increase the level of digitalization in terms of seamless data exchange from work order to finished products. Because not all divisions in the company have the same digitalization level, a stepwise approach was needed:

  • Introduction of BPM notation and technology to provide a unified way of describing manufacturing orchestrations while not disrupting production, and introduction of stable production procedures

  • Expansion of domain knowledge among those who work with information systems (ERP, MES, CAD-CAM) and machines, which are often tailored to fit the items produced

  • Closing of digitalization gaps when dealing with human–machine interaction or external partners

This step-by-step approach helps to ensure the natural evolution of how processes and subprocesses are structured, and how the functionality of individual tasks is defined.

This approach is especially important, as digitalization should be seen as a progressive journey, not as a single step a company takes. While one task, such as measuring the quality of a produced part, might at first be performed by a human, it might later be performed fully automatically by a machine, and eventually be replaced by a prediction algorithm that 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 the functionality realized by the task changes. Therefore, the progress in this particular case might be from a human’s worklist component, to an OPC UAFootnote 4 machine adaptor component to a data analytics component.

The design of a robust system must consider that individual components might fail, such as when a data analysis component has no access to data because of a data collection problem, in which case it might be necessary to switch back to the human. Situations in which over-automationFootnote 5 becomes a problem should also be planned for. Thus, addressing digitalization/automation should be a step-by-step journey in which decisions that result in problems can easily be reverted or circumvented until suitable solutions are found.

Our ongoing work seeks to standardize the digitalization journey based on available BPM technology and standard digitalization models and architectures like those in DIN Deutsches Institut für Normung e. V. (2016) and SCE-Cisco-IBM Sgra Team_2011 (2011).

The remainder of this section describes components that are part of the scenario outlined in Sect. 1, along with the technologies, standards, and methods we considered.

2.1 BPMN-Based Automation

As Bettenhausen and Kowalewski (2013) proposed, CPS-based automation architecture will replace the automation pyramid architecture (Fig. 2). This new architecture can be seen as a kind of network in which the functions of the previous layers are connected. In the automation pyramid architecture, only modules on neighboring layers can communicate with each other, which gives it some kind of structure. However, this constraint is not present in CPS-based automation, so there is a need for another kind of system that creates the context between the functions.

Fig. 2
figure 2

CPS-based and BPMN-based Automation (Pauker et al., 2018)

Full size image

As presented in Pauker et al. (2018), BPMN-based automation can be the solution (Fig. 2). Processes that are seen as functions can be coupled, thus granting some context that reduces complexity and increases flexibility, transparency, and maintainability. The result is centurio.work,Footnote 6 an orchestration framework based on BPMN processes (Pauker et al., 2018) that allows context-based dynamic orchestration of machines, humans, and software services. Highly adaptable manufacturing processes that are necessary for realizing a production based on cyber-physical production systems are characterized by being:

  • Context-based: Information from various software systems (e.g., ERP), sensors, and the manufacturing machines, are used at run-time.

  • Dynamic: Different subprocesses can be in place for machines that do the same thing, but have different hardware and interfaces.

  • Orchestrated: BPMN processes are annotated with all necessary information (i.e., links to interfaces and necessary parameters) so the model can be enacted directly in a process engine.

  • Human-involved: Specialized worklist components deal with a variety of settings, such as hazardous environments that can only be operated with protective gear.

2.2 Theoretical Framework

Standardization is key to realizing a modern production process to combat a plethora of competing approaches and technologies. The Reference Architecture Model Industry 4.0 (RAMI) standardized as DIN SPEC 91345 (DIN Deutsches Institut für Normung e. V., 2016) is a three-dimensional map that describes a structured approach to the topic “Industry 4.0.” The three dimensions are the product life cycle, based on the IEC 62890; the hierarchy levels, based on IEC 62264 and IEC 61512; and the functional hierarchy.

Our solution, centurio.work, is inspired by the design of RAMI, where type and instance correlate with well-known BPM models and instance concepts. centurio.work offers services on the business, functional, information, and communication layers. The top three levels are covered by a process engine, while communication is realized by a set of reusable modeling artifacts (tasks) that implement standard protocols like OPC UA, MQTT, and REST, and proprietary protocols like Siemens S7. These tasks can cover all hierarchy levels from “product” to “connected world.”

The reason for imagining centurio.work in the context of RAMI is that, in modern manufacturing scenarios, experts from a variety of domains have to work together. RAMI provides the common vocabulary so people whose domain knowledge differs can talk about a common goal.

3 Action Taken

We develop a step-by-step integration approach that has four evolution steps: soft integration, process modeling, augmentation, and control. With each step, control over the production process increases, and more domain knowledge is made explicit by BPMN models. Each of the four evolution steps follows the BPM life cycle (Dumas, La Rosa, Mendling, & Reijers, 2013).

The remainder of this section explains how going through these evolutions facilitates the smooth realization of the robotized manufacturing cell scenario outlined in Sect. 1 and shown in Fig. 1. This section also explains the process models discussed in Sect. 4, which are the outcomes of the implemented centurio.work scenario.

3.1 Evolution 1: Soft Integration

Evolution step 1, soft integration approach, is intended not to disturb current production but to model and monitor what happens to easy-to-identify resources on the shop floor. This step includes tracking new orders from an Enterprise Resource Planning (ERP) system, sourcing materials and scheduling production resources from a Manufacturing Execution System (MES), and collecting data from all machines, robots, and other equipment used on the shop floor.

This step results in simple, runnable process models that collect and structure data, similar to software like MindSphereFootnote 7 and the Predix Platform.Footnote 8 Most resources already log data into their private data-tanks, while the MindSphere and Predix provide adaptors with which to collect, combine, and present data from the data-tanks.

A side effect that materializes in evolution step 2 is that the context for the collected data is processed in evolution step 1. The challenge is to connect to custom developed and highly specialized machines and to write the adapter software that realizes something like the “monitoring” depicted in Fig. 3. For this particular task, we experimented with OPC UA interfaces and collected data through the Siemens S7 communication protocol. The result is a set of standard tasks that can be used and parametrized during modeling, and reused for future customers.

Fig. 3
figure 3

Process models: connections and evolution (Red Bubble)

Full size image

3.2 Evolution 2: Process Modeling

Step 2 still avoids disturbing production. The difference from step 1 is that step 2 focuses on how the resources interact with each other by determining how orders are scheduled, how the sourcing of material interacts with its scheduling, and which machines participate in what order in the manufacturing of a part.

The result is extensive information about how things work together. With this step, the contextualization of existing data flows is fully realized through BPM technology. The data in the private data tanks is ignored, as the data flowing through the process engine runs processes like the one shown in Fig. 4b. In this evolution step, the task “manually measure,” as illustrated in Fig. 4b, is a placeholder for something that a human does. In this evolution, the process depicted by “AZ32 G2 Turn” in Fig. 4b checks whether a human presses a button that starts the machine and then instantiates the collection process in evolution step 1.

Fig. 4
figure 4

Part-specific processes. (a) Coordinate production and robot handling. (b) Producing a single item

Full size image

3.3 Evolution 3: Augmentation

Step 3 focuses on digitalization gaps on the shop floor, so it targets mainly interactions between humans and machines. As the processes passively monitor the production of parts, introducing active functionality becomes possible. For example, a machine operator might take notes on a piece of paper about the quality of the produced parts, and later write a document on a computer that is sent to the customer as part of a protocol. Augmentation can take the form of placing a screen at the machine where the user inputs the data for each task using a keyboard or giving the user a connected caliper to avoid keyboard input. The goals are to establish a set of supporting user interfaces (UIs), set up independent scheduling-model logic that shows, for example, machine set-up UIs if necessary, ensuring quality by capturing data (e.g., notes) from part-prototyping and part-production phases, and capturing information about the repair of machines and machined parts (semantic machining). The process models are extended to capture all of these goals. The desired result is to close the existing semantic and digitalization gaps that are typically filled by humans and their knowledge.

In this evolution step, a user interface that can be parametrized from the process model to collect certain indicators (e.g., the diameter of a produced part) replaces the “manually measure” step (cf. Fig. 4b).

3.4 Evolution 4: Control

Step 4 is the final expansion state of centurio.work, as it is in this phase that centurio.work assumes control of the manufacturing. Typical functions are managing the software artifacts that are necessary for production (e.g., NC-programs) and triggering the execution of production based on scheduling data.

The result is that humans are guided and that they supervise production, rather than driving it with their actions, such as pressing buttons. As the process presented in Fig. 4a shows, humans scan a product code to start production—“HT65PM Start” is a subprocess that starts the machine—while in evolution step 3 the process might have triggered a UI to tell the user to press that start button. (In evolution step 2, no UI existed).

4 Results Achieved

The two main results are that domain knowledge that was available only in nondescriptive form or on software with no source available was made explicit through BPMN process models,Footnote 9 and that, instead of each machine having its own data collection and the data being cleaned, transformed, and loaded into a database ex-post, now all data is collected through the process engine, already cleaned, contextualized, and ready for analysis. As data collection is a byproduct of process execution, all changes to the processes automatically yield updated data streams for analysis without requiring additional effort or changes. Thus, in-situ analysis and real-time data presentation can be performed, creating a powerful driver for future innovation efforts.

Figure 3 shows how the process models presented in this section are connected, as well as for which evolution they were created. We also provide a videoFootnote 10 that demonstrates the interactions depicted in the process models.

Figure 4 shows two examples of how process models can be used to orchestrate a shop floor. Figure 4a depicts a process that was introduced in Evolution 4, showing how a robot chooses produced items out of the machine and puts them on trays to be transported to the measurement station.

Figure 4b shows the steps for producing a single AZ32 G2 item, which is produced on the lathe machine. The process spawns subprocesses for a truing operation, then shows a UI for manually measuring the parts, and finally collects data from an automatic measuring machine. Evolution step 4 spawns a process model like that shown in Fig. 4a. In lower evolution steps, Fig. 4a would not have been possible as, for example, in evolution step 1 no human interaction was modeled. Instead “MI/HMI” detects that the start button was pressed on the lathe and then spawns “monitoring,” as depicted in Fig. 3.

Figure 5 shows the interaction between the process and a low-level robot-interface. Robot programs, including programs for taking the part out of the machine and placing it on a tray, as shown in Fig. 4a, are managed and loaded from a GIT repository. After the programs have been assembled, they are loaded and started, and the robot is monitored until successful completion of the tasks. The robot-handling is always triggered after the step “AZ32 G2 Turn” (in Fig. 4b), so “signal machining end” sends a message back to the process shown in Fig. 4a.

Fig. 5
figure 5

Generic universal robot process

Full size image

5 Lessons Learned

After using the stepwise approach, we learned three main lessons: (a) using BPMN as modeling notation provides a better understanding of the processes on the shop floor, (b) increasing the degree of automation does not mean developing everything new because many artifacts can be reused, and (c) the stepwise approach offers a fallback mechanism from less automated process execution.

BPM technologies proved efficient for driving digitalization and automation efforts on the shop floor. Its strategic value is the high level of flexibility achieved when technologies are combined (as required by a heterogeneous shop floor) while retaining maintainability and understandability in the resulting system. Therefore, maintainability and understandability are direct results of the expressiveness of the BPMN notation and the use of a process engine that allows domain experts to try to modify models directly so they can see the effects in the real world.

While an exploratory digitalization and automation approach proved successful, it became clear that streamlining the exploration can have advantages:

  • Structured assessment of the current situation regarding the integration of machines can highlight problem areas.

  • Monitoring the progress in terms of the proposed evolution steps gives a quick situation overview and allows efficient allocation of human resources. For example, evolution steps 1 and 2 may require more software-development resources and domain experts than the other steps do.

  • After achieving evolution step 1, data analytics efforts can start.

As Fig. 3 suggests, many processes have not changed much since they were created. “MI (Machine Interface)” was first directly linked to “Monitoring.” Since for each order or item, a specific NC Program is started, it is necessary only to monitor the start of that program, so “Monitoring” never changed again. The introduction of “Order and 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 unchanged because pressing the button physically and triggering the machining through software are the same. “Order and Items” evolved over multiple iterations with the introduction of new hardware.

Particularly useful was proving that versions of the functionality developed for tasks in evolution steps 1–4 still have their purpose as fallback mechanisms if problems occur during production. Easily switching individual tasks from full automation back to human work proved to be transparent and simple to achieve while introducing no additional complexity for the factory operators or the process models. While switching back to manual processes is time-consuming, it can be done through logic in the process, such as when the lathe cannot be started automatically (error-detection logic), in which case the old UI-driven subprocess can be spawned.