Organisational and technical processes of manufacturing companies are becoming more and more complex while the pressure for exibility increases. The biggest challenge here is still the integration of different systems in a coherent transparent way. In order to further vertical integration in the automation pyramid, this paper presents a solution based on use BPM technology, more speci cally process modelling and execution based on BPMN to integrate shop oor with top level planning. Our full-stack solution is currently in active development with our customers. One main advantage is that through coherent usage of BPMN processes from top to bottom, all monitored data during execution can always be stored in the right context, which saves a lot of e ort compared to the state of the art in manufacturing systems.
In today's global competition, manufacturing companies must adapt their technical processes and resources to constantly changing conditions. Additionally the demand to smaller lot size is increasing and so higher exibility is needed. In this high mix low volume environment, the use of digital tools is becoming increasingly important. Data management in the factory relies on information ows that access di erent systems. The problem in many manufacturing companies is that most software tools are hard-coded stand-alone solutions with no or proprietary software interfaces. This poses a huge interoperability challenge. The lack of software interface compatibility makes data exchange between individual applications di cult and increases the e ort of integrating new systems. Tailor-made software solutions are often used for coupling the individual software solutions. This kind of hard-coded integration can usually only be maintained, changed and expanded by software developers. This leads to high maintenance costs due to the complexity. What instead is required is an infrastructure that enables e cient adaptation of system orchestration.
Current initiatives like Industry 4.0 (I4.0), Industrial Internet of Things
(IIoT) demand a fully connected environment consisting of so called
Cyberphysical Systems (CPS). CPS are objects consisting of a physical part with an
virtual representation which can communicate with other CPS over a partially
global network [
+ | | s s .{} + | | BPMNA/uPtroomceastsio-bnased
Enterprise ressource planning level Plant management level Process control level (CPoLnCt)rolelvel Field level
Automation Hierarchy
CPS-based Automation
The contribution of this paper is the centurio.work approach for
simplifying the integration of heterogeneous systems throughout the whole automation
pyramid, by utilizing a true service-oriented oriented approach and advances like
the BPMN [
In Sect. 2 we start out by describing currently existing standards and requirements on the shop oor (lower levels of the automation pyramid). In Sect. 3 we then describe the overall architecture of the system in relation to the shop oor requirements. In Sect. 4 when then describe how the architecture is adapted by our customers. 2
Modelling of Shop oor Processes
For orchestration of manufacturing di erent solutions are available. These
solutions typically depend on the hierarchy level in the automation pyramid [
One requirement of Cyber-physical Systems (CPS) based automation is the
need of orchestrating di erent services, which is implemented e.g. by the
Manufacturing Service Bus (MSB) [
Modular Secure Manufacturing Orchestration centurio.work was designed as an interoperability and integration framework for manufacturing companies. The motivation is bringing the exibility of Business Process Management Systems from the management level to the shop oor. Fig. 2 shows the architecture of the framework.
Prepare
Plan Cloud Services
Design Reason Process Design
Resource
Designer
M
Transportation Users / Operators Robots Machines
Shopfloor
OPC-UA MQTT HTTPS
Processes Execution Control Process Execution Data Provisioner
Feedback
Machines NC/Robot Programs
Tool Data
Orchestration Resources / IEC 62246
Data Aggregation TraannsdfoFrmilteartiinogn TraannsdfoFrmilteartiinogn
Utility Apps
DataAnalysis Business Inteligence BusinMesRsPInCteolningecntcoer
The centurio.work framework was designed from the ground up with security in mind. It groups applications into four contexts that are strictly separated and are allowed to either push or read data. The arrows represent the data ow between these contexts. While every component inside a context is intended to be replaceable, the arrows represent strictly de ned protocols, data formats and security mechanisms. Contexts which are not connected by arrows do not interact. Orchestration components are allowed to access Resources and can push information to Data Aggregation components. Data Aggregation components provide Data to Utility Apps but data change is not allowed.
The centurio.work framework stores static (design-time) information in the resource context. This information stems from various company systems and is ngerprinted upon insertion to be able to detect corruption and tampering.
For interacting with the shop oor (run-time) centurio.work supports di erent interfaces. For orchestration of shop oor equipment OPC-UA is preferred solution. OPC-UA has strong modelling capabilities and is an agreed-upon standard for European companies. So the shop oor equipment can o er their abilities as OPC-UA methods and static information as variables and properties. Therefore, we can utilize the client server paradigm and the built in security mechanisms of OPC-UA e.g. user authentication and certi cates.
Additionally MQTT support is built in because of its light-weight publish/subscribe mechanisms and the possibility to run on embedded systems. This is especially useful for high-performance data gathering.
The centurio.work Execution Engine itself is con gured to push data for certain topics to Data Aggregation components. In other words: it communicates with Data Aggregation Apps through a secure publish/subscribe mechanism. 3.1
There exist some basic types of resources, which may be utilized by the Orchestration components. The Processes which provide a logic for coordinating the interaction between di erent machines. They de ne sequences of interactions with decisions and parallel execution. Processes typically refer to other information Resources, such as speci c Machines, NC/Robot Programs, and Tool-Data. Process of course may also access this information a run-time, e.g. to decide which machine to utilize for a certain job.
The structure of the Resources container is based on the IEC 62264 [
This context is the sole context that is allowed to interact with the shop oor. It does so by utilizing processes, which in turn contain all information how to interact with machines for the purpose of production and for the purpose of monitoring. Currently three types of apps can exist in this context: (i) An Execution Control App which allows to start and modify processes at runtime in the case of errors (ii), an Execution Engine which enacts the processes and (iii) a Data Provisioner which acts as an e cient gateway for machines that have the capability to push sensor data to subscribers.
The Execution Engine in turn is the sole source of data that is available to Data Aggregation. It pushes all aspects of interaction with machines to these Data Aggregation components, which may (or may not) lter, transform or otherwise process and store this data. Data may be duplicated, as each Data Aggregation App serves one speci c purpose, and is to structure data for optimum performance and usability. 3.3
Data Aggregation Apps, may (or may not) lter, transform or otherwise process and store data. Each app is intended to implement its storage and an interface how to access this storage. Data Aggregation Apps may: (i) log the execution (ii) log / monitor the execution for possible security violations (Secure Logging), and (iii) calculate Key Performance Indicators (like Overall Equipment E ciency) of the equipment or the process. They may also (iv) aggregate data so that Utility Apps can e ciently perform their tasks. We use standards such as IEEE 18492016 XES 1 and tools such as In uxDB to allow for optimized access by Utility Apps implementing dash-boarding and data- and process analytics. 3.4
All other apps/functions are intended to run in this context. The basic functions of Utility Apps are to read data stored in Data Aggregation context. The Apps also can interact with each other and can additionally implement their own storage. A containerization salutation e.g. Docker is used to ful l these requirements and to increase the usability for customers.
These Apps are also the basis for improvement recommendation, which in some cases (e.g. optimizations for the invocation of machines) automatically ow back into to the Resources context, or be passed on as documents to humans which may decide how the process structure or its parameters can be changed. 4
Example Scenarios From Our Customers centurio.work was created as the result of feedback from our customers. In order to evaluate its applicability in an iterative manner, it is deployed in an increasing number of small and medium Austrian enterprises. Some use cases which have been developed and tested are described in the following. 4.1
As proposed in [
Typically we have di erent granularity on di erent levels in a manufacturing company (cmp. Fig. 3). This is represented in the automation pyramid as di erent levels which have di erent requirements on information, communication and data granularity. Approaches like the MSB use di erent modelling languages for the di erent levels. centurio.work uses BPMN for all levels, so we have a seamless modelling and process execution from business to shop oor.
Fig. 3 shows a common process in a company with di erent information granularity in each level. On the top level (ERP) the process owner only sees a process consisting of three tasks, order, produce and deliver. 1 http://xes-standard.org/ [Last accessed: 2018-04-12] ERP MES SCADA + ||| ||| Set-Up
Produce Logis c Part
s Order Produc on Distribu on s
Background +
Saw Part Turn Part Assembly
The production planning needs more information of the Production process. Thus the sub process is more detailed with additional information on how to get the raw material and how to set up the machine. A worker on the shop oor is involved in a subprocess with all tasks to produce individual parts. Additionally there are some background processes which for example gather sensor data from machines or calculate KPIs (cmp. Sect. 4.3). 4.2
Currently on the shop oor, human involvement is bound to hard-coded software on the machine. The big advantage of centurio.work is the independent coordination of human tasks with tasks from software systems or machines. A simpli ed process for setting up a machine (equip the machine with cutting tools) is displayed in Fig. 4. In the rst task the process interacts using a UI with the worker. After nishing the task the next process step is executed. All information which are displayed on the UI are de ned in the process task.
s ◤ Setup Machine While traditionally data is collected individually for each machine, and is contextualized as part of a data analysis, in the centurio.work framework all data is collected from a single source, the Process Execution component. There is always an explicit connection between all monitored data artefacts.
This holds true even when only soft integration is required: i.e. when machines are not actively triggered, but just passively monitored without any changes to shop oor at all. Fig. 5 shows a simpli ed version of the processes at our customers plant. One background process monitors the NC machines and if a NC Program is started it spawns a new instance of the machining process. The generated data is bu ered in the Data Aggregation context.
+ ||| s ||| {..} s ◤ Listen to NC start ◤ true (⭱) { Enterprise service bus (ESB) based systems provide the necessary ingredients, but require a lot of time and know-how to introduce, to con gure and to maintain and are thus are typically employed only by big companies. Smaller companies typically have home-grown solutions that work. { The shop oor is heterogeneous and machine manufacturers often still focus on building support for actively communicating with other machines into their proprietary software (resulting in a Mesh-Topology). Open, well documented interfaces for their own features are sadly still rare. { Although OPC-UA gains traction, its focus is on standardizing the metamodel how to interact with machines. While taking away some communication issues, all the semantic issues remain.
centurio.work focuses on solving the above challenges by (1) providing a set of standardized components which can be deployed without any con guration. All con guration is handled through modelling BPMN processes for improved usability. (2) Experience values and improvements can easily ow back into the stored processes, instead of owing back into con guration of individual components, or owing back into static code. This again is a main usability improvement for our customers. (3) The bus topology with a centralized Orchestration Engine, allows for all the usual advantages like standardized monitoring and security auditing.
centurio.work focuses on a plug&play infrastructure, while moving all complexity into easy to interact with BPMN processes.
Acknowledgements: 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.