See discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/334164343

Agile Operational Behavior for the Control-Level Devices in Plug&Produce

Production Environments

Conference Paper · September 2019

CITATIONS

0READS

103

5 authors, including:

Some of the authors of this publication are also working on these related projects:

FRONTICS View project

Data Backbone View project

Kirill Dorofeev

fortiss

11 PUBLICATIONS   29 CITATIONS   

SEE PROFILE

Stefan Profanter

fortiss

18 PUBLICATIONS   119 CITATIONS   

SEE PROFILE

Pedro Ferreira

Loughborough University

24 PUBLICATIONS   123 CITATIONS   

SEE PROFILE

Alois Zoitl

Johannes Kepler University Linz

205 PUBLICATIONS   2,118 CITATIONS   

SEE PROFILE

All content following this page was uploaded by Kirill Dorofeev on 02 July 2019.

The user has requested enhancement of the downloaded file.

https://www.researchgate.net/publication/334164343_Agile_Operational_Behavior_for_the_Control-Level_Devices_in_PlugProduce_Production_Environments?enrichId=rgreq-23767efd599c3cbd838a051bc92f5406-XXX&enrichSource=Y292ZXJQYWdlOzMzNDE2NDM0MztBUzo3NzYxNTMxODI3NjUwNTZAMTU2MjA2MDc0NzM3NA%3D%3D&el=1_x_2&_esc=publicationCoverPdfhttps://www.researchgate.net/publication/334164343_Agile_Operational_Behavior_for_the_Control-Level_Devices_in_PlugProduce_Production_Environments?enrichId=rgreq-23767efd599c3cbd838a051bc92f5406-XXX&enrichSource=Y292ZXJQYWdlOzMzNDE2NDM0MztBUzo3NzYxNTMxODI3NjUwNTZAMTU2MjA2MDc0NzM3NA%3D%3D&el=1_x_3&_esc=publicationCoverPdfhttps://www.researchgate.net/project/FRONTICS?enrichId=rgreq-23767efd599c3cbd838a051bc92f5406-XXX&enrichSource=Y292ZXJQYWdlOzMzNDE2NDM0MztBUzo3NzYxNTMxODI3NjUwNTZAMTU2MjA2MDc0NzM3NA%3D%3D&el=1_x_9&_esc=publicationCoverPdfhttps://www.researchgate.net/project/Data-Backbone?enrichId=rgreq-23767efd599c3cbd838a051bc92f5406-XXX&enrichSource=Y292ZXJQYWdlOzMzNDE2NDM0MztBUzo3NzYxNTMxODI3NjUwNTZAMTU2MjA2MDc0NzM3NA%3D%3D&el=1_x_9&_esc=publicationCoverPdfhttps://www.researchgate.net/?enrichId=rgreq-23767efd599c3cbd838a051bc92f5406-XXX&enrichSource=Y292ZXJQYWdlOzMzNDE2NDM0MztBUzo3NzYxNTMxODI3NjUwNTZAMTU2MjA2MDc0NzM3NA%3D%3D&el=1_x_1&_esc=publicationCoverPdfhttps://www.researchgate.net/profile/Kirill_Dorofeev?enrichId=rgreq-23767efd599c3cbd838a051bc92f5406-XXX&enrichSource=Y292ZXJQYWdlOzMzNDE2NDM0MztBUzo3NzYxNTMxODI3NjUwNTZAMTU2MjA2MDc0NzM3NA%3D%3D&el=1_x_4&_esc=publicationCoverPdfhttps://www.researchgate.net/profile/Kirill_Dorofeev?enrichId=rgreq-23767efd599c3cbd838a051bc92f5406-XXX&enrichSource=Y292ZXJQYWdlOzMzNDE2NDM0MztBUzo3NzYxNTMxODI3NjUwNTZAMTU2MjA2MDc0NzM3NA%3D%3D&el=1_x_5&_esc=publicationCoverPdfhttps://www.researchgate.net/institution/fortiss?enrichId=rgreq-23767efd599c3cbd838a051bc92f5406-XXX&enrichSource=Y292ZXJQYWdlOzMzNDE2NDM0MztBUzo3NzYxNTMxODI3NjUwNTZAMTU2MjA2MDc0NzM3NA%3D%3D&el=1_x_6&_esc=publicationCoverPdfhttps://www.researchgate.net/profile/Kirill_Dorofeev?enrichId=rgreq-23767efd599c3cbd838a051bc92f5406-XXX&enrichSource=Y292ZXJQYWdlOzMzNDE2NDM0MztBUzo3NzYxNTMxODI3NjUwNTZAMTU2MjA2MDc0NzM3NA%3D%3D&el=1_x_7&_esc=publicationCoverPdfhttps://www.researchgate.net/profile/Stefan_Profanter?enrichId=rgreq-23767efd599c3cbd838a051bc92f5406-XXX&enrichSource=Y292ZXJQYWdlOzMzNDE2NDM0MztBUzo3NzYxNTMxODI3NjUwNTZAMTU2MjA2MDc0NzM3NA%3D%3D&el=1_x_4&_esc=publicationCoverPdfhttps://www.researchgate.net/profile/Stefan_Profanter?enrichId=rgreq-23767efd599c3cbd838a051bc92f5406-XXX&enrichSource=Y292ZXJQYWdlOzMzNDE2NDM0MztBUzo3NzYxNTMxODI3NjUwNTZAMTU2MjA2MDc0NzM3NA%3D%3D&el=1_x_5&_esc=publicationCoverPdfhttps://www.researchgate.net/institution/fortiss?enrichId=rgreq-23767efd599c3cbd838a051bc92f5406-XXX&enrichSource=Y292ZXJQYWdlOzMzNDE2NDM0MztBUzo3NzYxNTMxODI3NjUwNTZAMTU2MjA2MDc0NzM3NA%3D%3D&el=1_x_6&_esc=publicationCoverPdfhttps://www.researchgate.net/profile/Stefan_Profanter?enrichId=rgreq-23767efd599c3cbd838a051bc92f5406-XXX&enrichSource=Y292ZXJQYWdlOzMzNDE2NDM0MztBUzo3NzYxNTMxODI3NjUwNTZAMTU2MjA2MDc0NzM3NA%3D%3D&el=1_x_7&_esc=publicationCoverPdfhttps://www.researchgate.net/profile/Pedro_Ferreira29?enrichId=rgreq-23767efd599c3cbd838a051bc92f5406-XXX&enrichSource=Y292ZXJQYWdlOzMzNDE2NDM0MztBUzo3NzYxNTMxODI3NjUwNTZAMTU2MjA2MDc0NzM3NA%3D%3D&el=1_x_4&_esc=publicationCoverPdfhttps://www.researchgate.net/profile/Pedro_Ferreira29?enrichId=rgreq-23767efd599c3cbd838a051bc92f5406-XXX&enrichSource=Y292ZXJQYWdlOzMzNDE2NDM0MztBUzo3NzYxNTMxODI3NjUwNTZAMTU2MjA2MDc0NzM3NA%3D%3D&el=1_x_5&_esc=publicationCoverPdfhttps://www.researchgate.net/institution/Loughborough_University?enrichId=rgreq-23767efd599c3cbd838a051bc92f5406-XXX&enrichSource=Y292ZXJQYWdlOzMzNDE2NDM0MztBUzo3NzYxNTMxODI3NjUwNTZAMTU2MjA2MDc0NzM3NA%3D%3D&el=1_x_6&_esc=publicationCoverPdfhttps://www.researchgate.net/profile/Pedro_Ferreira29?enrichId=rgreq-23767efd599c3cbd838a051bc92f5406-XXX&enrichSource=Y292ZXJQYWdlOzMzNDE2NDM0MztBUzo3NzYxNTMxODI3NjUwNTZAMTU2MjA2MDc0NzM3NA%3D%3D&el=1_x_7&_esc=publicationCoverPdfhttps://www.researchgate.net/profile/Alois_Zoitl?enrichId=rgreq-23767efd599c3cbd838a051bc92f5406-XXX&enrichSource=Y292ZXJQYWdlOzMzNDE2NDM0MztBUzo3NzYxNTMxODI3NjUwNTZAMTU2MjA2MDc0NzM3NA%3D%3D&el=1_x_4&_esc=publicationCoverPdfhttps://www.researchgate.net/profile/Alois_Zoitl?enrichId=rgreq-23767efd599c3cbd838a051bc92f5406-XXX&enrichSource=Y292ZXJQYWdlOzMzNDE2NDM0MztBUzo3NzYxNTMxODI3NjUwNTZAMTU2MjA2MDc0NzM3NA%3D%3D&el=1_x_5&_esc=publicationCoverPdfhttps://www.researchgate.net/institution/Johannes_Kepler_University_Linz?enrichId=rgreq-23767efd599c3cbd838a051bc92f5406-XXX&enrichSource=Y292ZXJQYWdlOzMzNDE2NDM0MztBUzo3NzYxNTMxODI3NjUwNTZAMTU2MjA2MDc0NzM3NA%3D%3D&el=1_x_6&_esc=publicationCoverPdfhttps://www.researchgate.net/profile/Alois_Zoitl?enrichId=rgreq-23767efd599c3cbd838a051bc92f5406-XXX&enrichSource=Y292ZXJQYWdlOzMzNDE2NDM0MztBUzo3NzYxNTMxODI3NjUwNTZAMTU2MjA2MDc0NzM3NA%3D%3D&el=1_x_7&_esc=publicationCoverPdfhttps://www.researchgate.net/profile/Kirill_Dorofeev?enrichId=rgreq-23767efd599c3cbd838a051bc92f5406-XXX&enrichSource=Y292ZXJQYWdlOzMzNDE2NDM0MztBUzo3NzYxNTMxODI3NjUwNTZAMTU2MjA2MDc0NzM3NA%3D%3D&el=1_x_10&_esc=publicationCoverPdf

Agile Operational Behavior for the Control-LevelDevices in Plug&Produce Production Environments

Kirill Dorofeev∗, Stefan Profanter∗, Jose Cabral∗, Pedro Ferreira†, Alois Zoitl∗∗fortiss GmbH, Munich, Germany

{dorofeev, profanter, cabral}@fortiss.org†Wolfson School of Mechanical and Manufacturing Engineering Loughborough University, Loughborough, United Kingdom

p.ferreira@lboro.ac.uk‡fortiss GmbH, Munich, Germany / Johannes Kepler University, Linz, Austria

alois.zoitl@jku.at

Abstract—The ongoing manufacturing systems transformationfrom mass production towards mass customization requires moreflexible engineering solutions than the existing ones. The recentlyproposed control architectures target, among other plug-and-produce features, a reduction of configuration times. This isrelevant for building a new production line as well as forfaster reconfiguration when adding new hardware and productvariants to an existing manufacturing line. This paper identifiesoperational requirements for such reconfiguration scenarios andproposes a way to implement them using the concept of adevice adapter. The device adapter contains a device descriptionand constantly updates it following the reconfiguration changeshappening in a manufacturing system. This allows not onlyto detect the changes in the hardware, which appear in theproduction system, using the device discovery mechanisms butalso automatically adapt the software. Preliminary tests havebeen performed on a demonstrator that shows both virtual andphysical executions combined in a single system. The proposedsolution supports automatic hardware and software reconfigu-ration on-the-fly without a need to stop and restart the wholeproduction system.

Index Terms—Reconfigurable Manufacturing Systems, Skill-Based Engineering, AutomationML, OPC UA

I. INTRODUCTION

The fast-changing market forces the manufacturing compa-nies to increase their production systems flexibility by intro-ducing new technologies and architectures at all control levels.The emergent control architectures aim at providing flexibilityby plug-and-produce features such as service discovery andautomatic software composition [1]. The flexibility require-ments can be divided into 1) product flexibility that enablesproduction of a huge number of product variants 2) technologyflexibility that eases the use of different technologies within theproduction process and 3) resource flexibility that empowersthe easy application of different assets within productionprocesses [2].

In traditional mass production, switching to a differentproduct variant usually requires either stopping to reconfigurethe equipment, or allocating specific production lines for

The research leading to these results has received funding from the Euro-pean Unions Horizon 2020 research and innovation programme under grantagreement No 680735, project openMOS (Open Dynamic ManufacturingOperating System for Smart Plug-and-Produce Automation Components).

each variant. However, a key part of smart-manufacturing isflexibility, allowing variants of a product to be made usingthe same equipment without the need to stop production andretooling. Flexibility includes the concepts of variable routing,where the products take the most efficient path through pro-duction machines at the current time, as well as order basedproduction, where the parts are only made in quantities andvariants specific to customer request.

This paper describes the set of operational requirements thatshould be fulfilled by the automation components on the field-device level in order to achieve the required flexibility and becapable of the reconfiguration on-the-fly. Further, we showhow to implement the proposed concepts using AutomationMarkup Language (AutomationML) and OPC Unified Archi-tecture (OPC UA). Furthermore, the running example is afully-functional demonstrator that combines both physical andvirtual executions and simulates the production of a complexproduct with multiple variants. A rich transportation network,where seven Automated Guided Vehicles (AGVs) ferry theproducts between the workstations over 32 different pathscomplements the demonstration complexity. While providinga clear benefit in reconfiguration effort and time, the per-formance comparison of our proof-of-concept implementationwith the legacy systems did not show a big overhead in theproduction throughput.

II. RELATED WORK

The key technologies that enable the reconfiguration inthe production systems are the open-architecture control andmodular machines, responsible for the reconfigurable softwareand hardware, respectively [3]. Mehrabi et al. [3] have alsooutlined the need for the methods enabling efficient and fast re-use of the automation components and their functionalities inthe Reconfigurable Manufacturing Systems (RMSs). One suchmethod is to semantically describe of the modules constitutinga production system and their functionalities [4] and to catalogthem. In process automation Module Type Packages (MTPs)are used to encapsulate the process modules functionalities andprovide it in the form of service to the rest of the system [5].The MTP manifest is modeled by means AutomationML thatis defined in IEC 62714 [6]. The information from MTP can

be shared between the automation modules throughout thesystem by communicating it by means of OPC UA. OPC UAallows representing the content of the MTP manifest in thenamespace of the module, enabling the modules discovery andinteraction [7].

The control software reconfiguration can be achieved byemploying the agent technology [8] that is successfully appliedfor reconfiguration scenarios on the system level such as over-all scheduling and planning. However, the current challengesin production flexibility include such application scenariosthat can be only solved by moving the intelligence awayfrom system level to the production stations [9]. If productionstations of different vendors shall interact seamlessly, the useof standardized and secure communication protocols, informa-tion models, and functional specifications is essential for theimplementation of this use case. Therefore, there is a need tohave a reconfiguration mechanism also at the lower componentsystem level. As the changes that occur at the component level,the whole system, as well as other interconnected systems,should be able to reconfigure themselves. The informationabout the current layout and operational state should beavailable at any time.

III. PROBLEM MOTIVATION

In order to sustain in the market conditions that are charac-terized by aggressive competition, the manufacturing systemsmust be upgradable and allow easy integration of the newfunctionalities and features. For dealing with such kind ofscenarios serves a paradigm of RMSs was proposed [10].RMS is a system that consists of hardware and softwaremodules that can be quickly rearranged or replaced. Re-configuration enables, in general case, adding, removing, ormodifying specific process capabilities, controls, software, ormachine structure. A RMS is characterized by 1) reductionof time for launching new systems and reconfiguring existingsystems, and 2) the rapid manufacturing modification andquick integration of new technology and/or new functions intoexisting systems [3]. We put even more strict requirements onthe production system under consideration. While producingdifferent product variants, the system should never shut downcompletely, allowing to deal with product customization andvarious plug&produce devices on-the-fly. Additionally, to havea lot of redundancy in the production scenarios, the system canhave a complex transportation network connecting differentworkstations constituting the system.

In order to show the operational mechanism for such RMSon the device level we developed a demonstrator, whichis used as a running example in this paper. The demon-strator originates from the Open Dynamic ManufacturingOperating System for Smart Plug-and-Produce AutomationComponents (openMOS) research project. The main goals ofthe project were: 1) embedding plug-and-produce capabilitiesinto automation devices, robots and machines, 2) enablingvertical and horizontal connectivity between plug&produceautomation components and higher level control and businessfunctions, and 3) creating an easily extendable and adaptable

manufacturing operating system (MOS) that permits the easyintroduction of new products, work orders and changes inthe equipment and allows easy deployment of optimizationand changeover management strategies. To develop and testmost of the proposed features, as well as to examine thescalability of the solution, a demonstrator was developed thatimplements an ”openMOS-enabled” simulation environment.At its most basic, the demonstration has the following key re-quirements, derived from the use-case scenarios from multipleintelligent manufacturing scenarios among different industrysectors (electronics, white goods, automotive):

• Scalability - One feature that required testing is how thedeveloped Device Adapter (DA) cope with a large numberof workstations. Thus, openMOS should function withhundreds of devices, which consequently requires large-scale testing. This allows us to add and remove a largenumber of different workstations in the system on-the-fly.

• Plug&Produce - Associated with scalability, one of thekey tenets of openMOS is the ability for equipmentto be added or removed from the production system,without manual reconfiguration and system restart. Thisrequires sufficient numbers of each workstation type forproduction so that there always remains a possibility topick an alternative path to conclude the production. Theworkstations themselves must also be isolated from eachother, to allow them to be removed individually.

• Transportation - For plug&produce to be viable, materialflow within the system must not be workstation depen-dent. Should a workstation be added or removed, it mustnot only appear within the supply chain but must alsobe connected to the transportation network. Therefore aflexible transportation system is required to enable theconcepts.

• Product Variation - An essential requirement was tohave many workstations, which could be used to providethe multiple production lines required to allow productvariations. Therefore, the end product has been chosenspecifically to include multiple variants. It is a genericelectronic device assembled from four components: twocasing parts and two electronic internals shown in Fig. 1.In addition to the components, a gluing process is ex-ecuted to hold the parts together once assembled. Theproduct casing, internals, and gluing process can all bevaried, allowing for individual products to be customizedgreatly, with 18 variants overall.

• Optimization - The agent–based control system for open-MOS includes an optimizer which attempts to make theoverall system more efficient. For this optimizer to work,the stations must have tunable parameters, which can bemodified to alter overall material flow without stoppingthe system.

IV. CONCEPT

A reconfigurable manufacturing system is designed to caterto the situations where both system productivity and its abilityto deal with a rapid change in a structure are of great

Fig. 1. Production Process

importance [11]. A manufacturing system is composed ofequipment, including transport and workstations, containingmultiple sub-components. We propose an implementation ofsuch a reconfigurable manufacturing system by utilizing a con-cept of a skill [12] [13] as a way to normalize the functionalityof each device in a production system and provide a genericinterface to execute a production task. In the previous paper,we introduced a concept of a DA [14], a software wrapperthat allows a device to be seamlessly plugged in into anagile production environment. Each system component hasits capabilities modeled in the form of a skill. The proposedsystem architecture [15] is shown in Fig. 2, where the low-level devices being responsible for executing a production areconnected to their cloud representation, which main task canbe seen as the overall production optimization. This is achievedby constantly monitoring the data gathered from the devicesvia the DAs.

Fig. 2. System architecture

The device level requires atomic devices which are aggre-gated up to workstation level, the highest level of granularity.This means all devices internal to a workstation will requirecommunication with the ability to expose their skills to theupper level. This communication will be critical for the

performance of the system, as it implies the ability to executeskills, and therefore requires a higher level of priority. Eachdevice has a self-description that follows a common semanticmodel and provides, among other data, the information aboutits capabilities [16].

On the cloud level of the solution, there are two aspectsto consider: the cyber representations and the device data.The cyber representations are achieved through the agents,which are the counterparts for the highest level resources,namely the resource agent (workstation) and the transportagent. The agents require a direct connection to their physicalcounterparts, which will provide the ability to monitor thesystem and explore potential optimizations. These agents areexpected to interact with other agents to achieve their goals.It is important to note that agent to agent communication willnot go through the service bus but directly between the agentswithin the cloud. The device data for every device in a systemis stored in the cloud. This data can then be accessed by theagents on the cloud to inform their decision-making process.

The Manufacturing Service Bus (MSB), the middlewarelayer, provides a uniform communication mean for the wholesystem, enabling a mechanism for an easy component discov-ery, configuration, and interoperability.

We define four operational phases to achieve a runningPlug&Produce system [17]: Discovery, Configuration, Produc-tion, and Reconfiguration. In this paper, we concentrate onthe Reconfiguration phase and the tasks that arise when anew product is introduced into such a system or a worksta-tion/module is either plugged in or unplugged. In response tosuch changes the system should be capable of performing ajob change when new production task arrives, or if there is achange in communication parameters, or if there is a changein hardware setup. This allows rapid integration, adaptation ofdifferent devices and assembly stations.

The skills are defined in a device description file that servesas an input for a DA: each adapter is automatically generatedout of its description. The skills can be later matched withproduct definitions and, afterward, a skill sequence, needed forproduction, can be derived. Skills vary from atomic (elemen-tary skills, executed by single backend device) to composite(an ordered set of atomic or other lower-level compositeskills).

The execution of skills is performed by skill recipes. Arecipe is a parameterized executable instance of a skill thatfulfills a certain skill requirement. The process of matching theskill requirements defined by the product to skills offered bythe equipment will result in the creation of a skill recipe [14].

Additionally, each DA has an execution table [16] thatstores the recipe execution sequence. The execution tablealso contains recipe-product relations that define the set ofinstructions to be executed for each specific product arrivingat a workstation. This serves as the basis for improvements bythe cloud optimization methods that may update the executiontables and, thus, change the execution logic on-the-fly.

The following list of DA operational requirements wasdefined for the reconfiguration phase:

• Semantic description of all elements should not onlycontain the hardware structure of a connected compo-nent and a list of its capabilities, but it also shouldbe re-adjustable to accommodate the changes, occurringin a system. This self-description is stored in the DAin form of a file and follows a generally acceptedcomponent description model. The proposed solutionutilizes AutomationML as a modeling language wherethe engineering information is stored following object-oriented principles. Such a description contains physi-cal and logical production system components as dataobjects encapsulating the different relevant informationaspects [18]. The device description follows the commonsemantic model and describes not only the hierarchicalstructure of a workstation or a transport unit but alsotheir skills, which can then be executed in order to fulfilla production task. A device adapter self-description isan aggregation of all lower-level components descriptionsthat constitute a workstation.

• (Un)plugging a workstation/module requires the corre-sponding DA and MSB adjustments including reflectingthe changes that happened in the self-description of aworkstation/module for traceability.

• DA standalone operation should be guaranteed evenif the connection to the optimization cloud is lost. Theproduction must not be stopped even if it is not runoptimally. The cloud, whenever it restores the connection,can reconfigure the production scenario afterward.

• Switching a module from one workstation to anothershould be possible in runtime. In this case, the systemafter discovering a change readjusts itself.

• Creation of new recipes for atomic/composite skills,editing recipes, and execution tables. It should bepossible to create new recipes or editing existing onesin order to either execute new production sequences, e.g.in the case of a new product or parameterize the existingsequences, e.g. to produce another product variant.

• DA orchestration of composite skills should enablea mechanism of on-the-fly reconfiguration of the skillsequences.

• Runtime production adjustments can be either de-manded by MSB or by the low-level device after exe-cuting some process step depending on its outcome. Anexample of the adjustments coming from the high-levelcould be a hardware change in the system setup so that theproducts need to be re-routed to another working stationto execute the whole process. An example of a later casecould be a product that should be processed differentlydepending on a test result done by a workstation.

• Skill interlocking should provide a mechanism to bufferthe skill calls and execute in a queue, one after another.This should be used when a composite skill sequencecontains a long-running process during the executionof which the next recipe call can be already started.Consider, for example, an AGV, which task is to bringthe products between a laser cutting, painting and gluing

stations. Assuming that the painting process takes sometime and is defined as a long-running, an AGV skillsexecution logic can be modeled as follows (see Fig. 3):

– The AGV receives a call to bring a product fromlaser-cutting station to a painting station and then toa gluing station.

– While it executes the transport task between a lasercutting and painting station, the next product arrives,demanding the same AGV to bring it along the samepath.

– After the first product arrives at the painting station,the AGV is able to start the second product execu-tion, while the first part is painting. It comes backto the laser cutting station, gets the second pruct andtransports it to the painting station. After arriving atpainting station the AGV unloads the second productfor painting and loads the first one, once it is ready.

– Finally, the AGV finishes the task for the first productand then gets back to finish the second one.

This allows having a more flexible execution logic, whichat the end saves time and costs, and deals with complexproducts.

• Scalability. The system should be scalable and caterto the setups consisting of virtual and physical stationsrunning together.

Fig. 3. Skills interlocking example

V. IMPLEMENTATION

The developed demonstrator, introduced in Section III, con-sists of eighteen simulated (four laser cutting, three painting,two 3Dprinting, two gluing, six joining and one labeling) anda real (gluing) workstations as well as seven simulated AGVs(see Fig. 4). The AGVs can bring the material between any twostations, without the restrictions of a fixed system, such as aconveyor belt. Each workstation has its DA, responsible for thesystem description and the corresponding skill execution. All

AGVs are controlled on the contrary by one DA introducinga device management layer. This demonstrates an ability tocontrol multiple resources from single DA.

Fig. 4. Demonstrator Layout

All the communications between the workstations and theMSB are done via OPC UA. The modeling capabilities ofOPC UA allow the devices to communicate the informationcontained in the device description AutomationML files witheach other in the runtime. Each DA after starting up, readsits own self-description file and generates an OPC UA serverout of it, following the OPC UA Companion specification”AutomationML for OPC UA” [19] [18].

A. Semantic description of all elementsThe self-description file for each device requires common

terminologies and concepts for both the Role Class andInterface libraries of the AutomationML file [20]. The firststep for defining the self-description file is to create the genericdevice description in the system unit class library and initializethe available skill types and interfaces. Once this is done,one can simply create an instance of a generic device in theInstance Hierarchy to define the specific device. This nodeis communicated to the next hierarchical level where it isaggregated, and so on until reaching the highest level ofgranularity (workstation or transport). It is also important tonote that a device description has approved recipes that can beused to fulfill requirements, from both products and compositeskills.

Each skill has a state machine that identifies if the skill iseither in Ready, Executing or Error state. The MSB, beforetriggering a skill, checks if the DA is ready for execution and,if so, triggers the production. All the information, defined inAutomationML description is passed up to the cloud-basedsystem towards having a virtual representation of an I4.0-compliant component.

Overall, this enables an automatic generation of the exe-cutable skills that can be triggered via OPC UA out of theAutomationML system description.

B. (Un)plugging a workstation/moduleRe-configuration requires the detection of newly plugged

in devices and downtime of already registered devices. To be

able to detect new devices on the network, it is required toimplement a discovery mechanism for OPC UA servers. TheOPC UA specification [21] describes the necessary OPC UAservices for the automatic discovery of other OPC UA serverson the network. The concept of using Local Discovery Serverswith Multicast Extension (LDS-ME) was previously describedin [22].

LDS-ME provides basic functionality to find other OPC UAservers on the network using multicast DNS [23]. As soon asa new device is plugged in, it announces itself on the network.Within seconds all other LDS-ME servers on the network arenotified. We are using this announced information to forwardit to the DA implementation, which can handle new devicescorrespondingly.

One major issue in this implementation is the detectionof device unplugging or shutdown. If a device is suddenlyoffline, the DA on the other end should be able to discoverthis new state and either redirect tasks to other devices ornotify the MSB about the missing device. A device maybecome offline due to different reasons. It may simply beshut off in a graceful way by, e.g., using the device’s userinterface. In this case, the device is still able to unregisteritself from other DAs. If the device has a hard failure or thenetwork connection is interrupted, the device can not send anunregister message, therefore other devices need some kind ofheartbeat implementation to detect this downtime. The OPCUA specification defines a timeout of 10 minutes: if a devicedoes not send a new register request every 10 minutes, itshould be removed from the known devices. This interval of 10minutes can be quite high for specific use-cases. Therefore weimplemented an extension to the OPC UA discovery processwhich is able to detect a device downtime within less than asecond.

This is achieved by implementing an additional heartbeatcommunication channel via User Datagram Protocol (UDP).As soon as a device registered itself with another DA, anadditional heartbeat connection is opened, where both devicessend a heartbeat every 250 milliseconds. It is necessary to useUDP since Transmission Control Protocol (TCP) communi-cation is bound to a specific connection where messages areautomatically cached by the operating system. If one of thetwo ends does not receive a new heartbeat message within 600milliseconds, the network connection is defined as broken. Inthis case, the OPC UA discovery process is notified aboutthe lost connection. The DA implementation will then benotified through the same API as if the device would unregisteritself. Reusing the OPC UA discovery interface allows usto transparently implement the heartbeat and adapt it to therequirements of the corresponding network connection.

C. Switching a module from one workstation to another

A heartbeat mechanism described above can be used forexample in the following scenario: if a module that providesan auxiliary functionality is shared between two workstations,its presence at one workstation and absence at another canbe automatically detected. For instance, in our demonstrator,

Fig. 5. Device adapter functionality to support dynamic reconfiguration

a painting station can have a quality checking camera thatcan be connected either to one or another virtual gluingworkstation. It monitors only one workstation at the sametime, therefore, whenever, it is connected to a workstation,this workstation provides not only Gluing skill but alsoGluingWithQualityCheck skill, whereas another gluingworkstation is only capable of Gluing. Whenever the LDS-ME server of the workstation DA detects a newly registeredcamera server, it extends its description with the skills definedin the camera’s self-description file and communicates thenew capabilities to the MSB by triggering it, notifying thechanges done in the workstation setup (see Fig. 5). TheMSB re-browses the OPC UA namespace of the DA andgets the information about newly available skills. Reversely,if the device is unplugged after the heartbeat detects it, it iscommunicated to the higher-level OPC UA LDS-ME server,the device is unregistered and its functionality is removed fromthe corresponding workstation. The MSB is notified again and,after re-browsing the workstation DA namespace, it adjustscorrespondingly.

D. Creation of new recipes for atomic/composite skills, editingrecipes and execution tables

The device description for a workstation, which is createdduring the Engineering Phase contains a predefined set of

the atomic skills, provided by the devices that constitute aworkstation and some composite skills for the productionprocesses known at the engineering time. However, agilemanufacturing demands the mechanisms that allow to rapidlyreact to the changes in the production tasks, happening whilethe system is in operation. That requires the scenarios whereeither the existing production sequences are changed or newcomposite skills are introduced. This includes the parameterediting of existing sequences, for example, to execute a newproduct variant (having a new case color). Moreover, it ispossible to create new combinations of skills to produce acompletely new product, for example, an electronic devicewithout a casing (in our demonstrator this will mean omittingthe 3DPrinting skills). In this case it is essentially important tokeep the documentation up-to-date, saving all new parametersand newly created skills. Therefore, once a new compositeskill or an edited skill is sent to a DA either via the systemHuman-Machine Interface (HMI) or from the higher-levelManufacturing Execution System, the DA is updating itsAML description, writing back new parameters and/or newcomposite skill steps. Afterward, it generates a new OPC UAserver out of it exactly as it does it during the startup andnotifies the MSB about the changes being made so that theupper control level can re-browse the new data and get theexecuted updates. The overall process is shown in Fig. 5.

By doing it that way, the information is kept up-to-date oneach level of the running system. If the module fails for somereason, after its restarting, it will appear in the system withthe last working configuration, without need to parameterizethe module again manually.

E. DA standalone operation

After the MSB gets the initial process configuration fromthe cloud or system HMI, it deploys the configuration downto the device adapters. If then the connection to the cloud isbroken, the DA continues its operation executing the existingrecipes and ensuring the system operation even without thecloud connection. Thus, the agent cloud can be seen optionalfor the system operation, however, its presence is crucial forthe system optimization and constant improvement.

F. Runtime production adjustments

This is a mechanism needed for the on-the-fly recipesconfigurations when the whole composite recipe should bechanged in response to the process outcome during the execu-tion. As an example for this use-case serves a quality checkscenario, when a camera at the gluing station detects a defectin a gluing process, the gluing station DA gets this informationand should be able to change the following sequence of thecomposite recipe execution in order to stop the production ofthe affected part. To implement such a scenario, the executiontables contain a list of possible next recipes to execute. TheDA, based on the process outcome, can then choose the nextrecipe to execute from this list and notify the MSB aboutthe next process steps by writing the chosen recipe to theNextRecipeToExecute column in the execution table (seeFig. 6). This allows us to deal with the product quality checksscenarios, namely if during the production the product failssome quality test and could be then sent again to the previousworkstations in order to be reworked if that is possible.

Fig. 6. Runtime adjustments using device adapter execution table.

G. Skill interlocking

As it is described earlier in Section IV requires a semaphore-like mechanism for the skill execution logic. The skill threadusing the same resource must wait until the semaphore’svalue is positive, then change the semaphore’s value bysubtracting one from it. When it is finished the thread changesthe semaphore’s value by adding one to it. To realize this,we add a separate LongRunningProcess state to the skillstate machine that identifies a long-running process in acomposite skill. While executing such a lingering skill, theother resources, responsible for the skill executions, can bereleased for executing another skill calls. We add a buffer ofthe skill calls, where we store the limit number of the skillcalls that are arriving, while the other skill instance is alreadyexecuting, blocking the immediate execution of the next call.Additionally, we add a semaphore variable that is controllingthe number of skills using the resource. In the example inFig. 3 the overall interlocking functionality works as follows:

• Product1 triggers the execution of the task recipe. Thetask consists out of laser-cutting, then transporting theproduct to the painting station, then painting, transportingthe product to the gluing station and, finally, gluing.For simplicity, we assume that in this example there isonly one AGV, which is responsible for transporting theproducts between the stations.

• When Product1 is executing the recipe, it decrementsthe semaphore value, setting it to zero, identifying that itwill block for its execution the AGV resource.

• While Product1 is executing, the next call for Product2arrives, but, since there is no free resource available andthe semaphore value is not positive, this call is saved ina buffer queue.

• When Product1 arrives at the painting station, whichis defined as a long-running skill, the state ma-chine of the highest-level Task skill is set to theLongRunningProcess state and releases all other re-sources, responsible for this composite skill execution,incrementing their semaphore values.

• After the AGV is released, it reads the next skill call,which is stored in the buffer queue and executes theProduct2, bringing it from the laser-cutting to the paint-ing station. Product2 takes the semaphore and releasesit as soon as the product arrives at the painting station.

• As Product1 is ready to leave the painting station, itblocks the AGV again by decrementing the semaphore.Then the process is finished for the Product1 at thegluing station and AGV brings the second product tofinish the executed task for it as well.

This interlocking mechanism is especially useful for trans-port skills as it is shown in Fig. 3. Note, that we additionallyrestrict the interlocking to be executed only if the producttypes that require the same skill execution is the same to avoidbottlenecks in the skill queues. That means that interlockingis only possible for the products of the same types that needthe same skill sequences to be executed. The type check is

done via the ProductTypeIdentifier that is specified in theproduct description AutomationML file.

H. Scalability

The demonstrator includes 20 DAs running in parallel andcommunicating with each other over the MSB. Even thoughin this case all DAs are running on a similar hardwareplatform, the other project demonstrators successfully provedthe concept of running the same wrapper code on top ofmultiple various control-level devices [14].

VI. CONCLUSION

In this paper, we demonstrated how a device adapter, asoftware wrapper that enables an integration of the automa-tion devices – both brown- and green-field – into the agileproduction environments. We have put the strong operationalrequirements in order to achieve the required level of flexibilityin the use-case scenarios. As a result, we have implemented thedemonstrator that simulates an agile production line consistingof a relatively large number of the workstations, havinga complex transportation system and producing a complexproduct with multiple variants. We have shown that the DAsupports the overall system flexibility on the component levelby keeping the system description updated, allowing dynam-ical device discovery mechanism, reattaching the modulesand switching them between different workstations, supportingsoftware reconfiguration, runtime product adjustments, andcomplex execution scenarios. It is worth to mention that theperformance tests comparing the openMOS approach with thelegacy systems showed that the overhead in the productionthroughput is not more than 1.5% [15] of the production cycle.

We have implemented the DA using the AutomationML forthe engineering phase and OPC UA for the runtime phase.The prototype implementation is open sourced1. It containsnot only the DA source code but also the examples of theAutomationML models for several workstations.

REFERENCES

[1] V. Vyatkin, “Software engineering in industrial automation: State-of-the-art review,” IEEE Transactions on Industrial Informatics, vol. 9, no. 3,pp. 1234–1249, Aug 2013.

[2] D. Wünsch, A. Lüder, and M. Heinze, Flexibility and Re-configurabilityin Manufacturing by Means of Distributed Automation Systems anOverview, 2010.

[3] M. Mehrabi, A. Ulsoy, and Y. Koren, “Reconfigurable manufacturingsystems: Key to future manufacturing,” Journal of Intelligent Manufac-turing, vol. 11, 08 2000.

[4] A. Perzylo, S. Profanter, M. Rickert, and A. Knoll, “OPC UA NodeSetOntologies as a Pillar of Representing Semantic Digital Twins ofManufacturing Resources,” in Proceedings of the IEEE InternationalConference on Emerging Technologies And Factory Automation (ETFA),Sep. 2019.

[5] J. Bernshausen, A. Haller, T. Holm, M. Hoernicke, M. Obst, andJ. Ladiges, “Namur Modul Type Package Definition,” atp magazin,vol. 58, no. 01-02, pp. 72–81, 2016.

[6] International Electrotechnical Commission (IEC, “Engineering data ex-change format for use in industrial automation systems engineeringAu-tomation Markup LanguagePart 1: Architecture and general require-ments, , International Standard, Rev. 2.0, IEC 62714-1,” InternationalElectrotechnical Commission (IEC, Tech. Rep., 2018.

1https://github.com/openMOS/deviceAdapter

[7] S. Wassilew, L. Urbas, J. Ladiges, A. Fay, and T. Holm, “Transformationof the NAMUR MTP to OPC UA to allow plug and produce for modularprocess automation,” 09 2016, pp. 1–9.

[8] W. Lepuschitz, A. Zoitl, M. Valle, and M. Merdan, “Toward self-reconfiguration of manufacturing systems using automation agents,”Systems, Man, and Cybernetics, Part C: Applications and Reviews, IEEETransactions on, vol. 41, pp. 52 – 69, 02 2011.

[9] “Structure of the Administration Shell. Continuation of theDevelopment of the Reference Model for the Industrie 4.0 Component.”accessed: 2019-03-20. [Online]. Available: https://www.plattform-i40.de/I40/Redaktion/EN/Downloads/Publikation/structure-of-the-administration-shell.pdf? blob=publicationFile&v=5

[10] Y. Koren, U. Heisel, F. Jovane, T. Moriwaki, G. Pritschow, G. Ulsoy, andH. Van Brussel, “Reconfigurable manufacturing systems,” CIRP annals,vol. 48, no. 2, pp. 527–540, 1999.

[11] Y. Koren, The global manufacturing revolution. Product-Process-Business Integration and Reconfigurable Systems, 2010.

[12] J. Pfommer, M. Schleipen, and J. Beyerer, “Configuration model forevolvable assembly systems,” in IEEE 18th Conference on EmergingTechnologies & Factory Automation (ETFA), 2014.

[13] P. Ferreira and N. Lohse, “Configuration model for evolvable assemblysystems,” in 4th CIRP Conference On Assembly Technologies AndSystems, 2012.

[14] K. Dorofeev, C.-H. Cheng, M. Guedes, P. Ferreira, S. Profanter, andA. Zoitl, “Device Adapter Concept towards Enabling Plug&ProduceProduction Environments,” in Proceedings of the IEEE InternationalConference on Emerging Technologies And Factory Automation (ETFA),Sep. 2017.

[15] F. Miranda, R. Martins, K. Dorofeev, V. Gentile, P. Ferreira, andM. Guedes, “Towards a Common Manufacturing Service Bus to EnableFlexible Plug-and-Produce Automation,” in ISR 2018; 50th InternationalSymposium on Robotics, Jun. 2018.

[16] P. Danny, P. Ferreira, K. Dorofeev, and N. Lohse, “An Event-BasedAutomationML Model for the Process Execution of Plug-and-ProduceAssembly Systems,” in IEEE 16th International Conference of IndustrialInformatics (INDIN), Jul. 2018.

[17] T. Arai, Y. Aiyama, Y. Maeda, M. Sugi, and J. Ota, “Agile assemblysystem by plug and produce,” CIRP Annals-Manufacturing Technology,Dec. 2000.

[18] M. Schleipen, A. Lüder, O. Sauer, H. Flatt, and J. Jasperneite, “Re-quirements and concept for Plug-and-Work,” Automatisierungstechnik,vol. 63(10), pp. 801–820, Jun. 2015.

[19] “Companion Specification AutomationML for OPCUA,” accessed on 2019-03-25. [Online]. Available:https://opcfoundation.org/news/opc-foundation-news/bridging-the-gap-between-communication-and-semantics-for-industrie-4-0-companion-specification-automationml-for-opc-ua/

[20] “Whitepaper AutomationML Part 1 - Architecture and general re-quirements.” [Online]. Available: {https://www.automationml.org/o.red/uploads/dateien/1417686950-AutomationML%20Whitepaper%20Part%201%20-%20AutomationML%20Architecture%20v2 Oct2014.pdf/}

[21] OPC Foundation, “OPC UA Specification Part 12: Discov-ery,” OPC Foundation, Tech. Rep., 2015. [Online]. Avail-able: https://opcfoundation.org/developer-tools/specifications-unified-architecture/part-12-discovery/

[22] S. Profanter, K. Dorofeev, A. Zoitl, and A. Knoll, “OPC UA for Plug &Produce: Automatic Device Discovery using LDS-ME,” in Proceedingsof the IEEE International Conference on Emerging Technologies AndFactory Automation (ETFA), Limassol, Cyprus, Sep. 2017.

[23] S. Cheshire and M. Krochmal, “Multicast DNS,” Internet Requests forComments, RFC Editor, RFC 6762, February 2013, accessed on 2019-03-25. [Online]. Available: http://www.rfc-editor.org/rfc/rfc6762.txt

View publication statsView publication stats

https://www.researchgate.net/publication/334164343