Modular lightweight robot system for aircraft production using a generic OPC UA skill concept

Industry 4.0 marks the beginning of a digital transformation of the traditional manufacturing sector which will reimagine the way manufacturing is achieved [1]. This is not only essential to make the production setup more flexible, but also to make industries more competitive in the global market thereby achieving a paradigm shift in business operations and performance [2]. The 5-Layers Purdue model of the automation pyramid is becoming increasingly inaccurate and should be replaced in the long term by a fully connected network map for representing the concept of a smart factory [3]. According to this new network model, a strict separation between information technology (IT) and operational technology (OT) will also be avoided, enabling not just a vertical but also a horizontal machine-to-machine integration of a manufacturing system [4]. However, different manufacturers have developed devices with their own proprietary hardware communication interfaces, resulting in uncountable number of different protocols, bus systems, data formats and interfaces. Consequently, a lack of common standard communication interfaces between machines has resulted in compatibility issues when integrating machines and systems from different manufacturers into the same production environment.

A possible solution to these shortcomings is the application of a platform independent service-oriented architecture known as Open Platform Communications Unified Architecture (OPC UA) with its information modelling capability [5]. Furthermore, OPC UA has its own communication interface based on TCP/IP protocol for system interoperability between devices. Although OPC UA enables the definition of data types and uniform data access, the definition of the parameters and functionalities must be clearly described to ensure exchangeability of modules [4]. The potential of OPC UA was realized and demonstrated in [6].

Skills are solution-neutral capabilities offered by devices to execute a task, where solution-neutral means independent of manufacturer [7]. In order to define the parameters and functionalities of skills, the production process needs to be broken down into a generic description of the capabilities of individual components. A concept of how skills can be used not only in engineering, but also for field-level device control using OPC UA is proposed in [8]. The known related works only propose the OPC UA based skill concept by modelling the system architecture and implementing them at most for simple robot movements [9, 10].

In this paper, this concept was modelled, implemented using programming interfaces and demonstrated with a use case in a production-related environment consisting of a lightweight robot, stereo camera, drilling unit and other devices. Additionally, this work shows that the devices used for production do not matter as far as they offer skills to fulfil the capabilities needed for the use case.

The following section provides an overview of related work in the area of skill-based engineering and OPC UA. The system and the use cases are described in detail in Sect. 3. This is followed by the approach and the implementation in Sects. 4 and 5 respectively. Finally, the summary and outlook are mentioned in Sect. 6.

OPC UA provides a framework for industrial interoperability through inbuilt data modelling capability in the form of OPC UA Information Modelling. This brings structure to the system data being modelled and makes data interpretation easier for machines and humans. According to the Reference Architecture Model for Industry 4.0 (RAMI 4.0) described in [11], the OPC UA standard is considered to be the only recommended framework to ensure that all hardware and software devices within a network are able to exchange information via the TCP/IP protocol and new devices do not need to be reconfigured to interact. In addition to this, leading automation industry companies such as Siemens and Beckhoff, are already using OPC UA for standardized communication [4].

Using a robot instead of a machine in production requires a semantic model description of robots. A generic concept for robotics was defined by the Mechanical Engineering Industry Association (VDMA) and OPC Foundation in [12], which in fact is derived from the device information model [13]. Currently, the robotics information model contains only the asset management and runtime data of robotic systems, described as motion device systems in the specifications.

Some of the early works related to skill-based engineering in production include the work by Julius et al. in [14], where the product, process and ressource approach for defining the skills in AutomationML is proposed. Later, a skill taxonomy in terms of assembly technology by Hammerstingl and Reinhart is discussed in [7]. This work defines terms such as capability, basic skill and composite skill and proposes a methodology for derivation of skill parameters. In the work [15] by Malakuti et al., the challenges in industrial automation systems using the skill-based approach are addressed. This work lists lack of standardized softwares as one of the challenges to skill taxonomies. An overall skill-based Plug & Produce concept for robotic applications is proposed in [16], where Heuss et al. present a modular skill framework for robots using PackML and Robot Operating System (ROS) for assembly operations with lightweight robots. The authors here also talk about SkiROS; a ROS based software framework for planning and execution of robot tasks based on their skills [17]. However, this framework is dependent on ROS and lacks standardized interfaces for communication.

Skill modelling approach together in conjugation with OPC UA is presented in [18] and [19] where, for the first time, OPC UA Programs are referred with skills. A skill can be modelled into an OPC UA Program using the finite state machine. Some of the works also provide insights on the application part of the skill-based engineering. [8] shows an example application using skills on a field device level. A simple solution for flexible modern industrial automation systems with skills and OPC UA state machine is presented by Sidorenko et al. in [20]. However, this approach still suffers in standardization and modularity. Some works presented by Profanter et al. in [9] and [10] were based on these standards and were developed to integrate the skill concept for simple applications like pick and place using robots. These works display a very detailed skill model for robots based on OPC UA by providing a good ontological description of robot skills and are implemented for three different cobots using OPC UA program state machines.

Our work is based on Profanter et al. in [9] and [10], where the concept of skill state machines, compromising of basic and composite skills, is extended and implemented for a full-fledged use case in a production-related environment. This was achieved by developing a modular architecture for an overall system and the same was validated for a lightweight robot system, where all the involved partners with their modules successfully demonstrated the interoperability of the overall system.

To ensure that the development is not only applicable in a laboratory environment, a complex use case from the aviation industry was chosen for validation. The use case deals with vertical tail plane (VTP) component of an airplane, which can be seen in Fig. 1. The use case comprises of holes to be drilled on the component with the help of a drilling template and a drilling unit which are carried out normally by technicians. However, in the project Commands2 under grant ZW 1 80154419, it is implemented with the help of lightweight robots.

The process flow is as follows: The technician begins to assemble the drilling templates. After the first drilling template has been mounted, the robot system can be initialized. The robot system moves to the machining position while the technician mounts another drilling template. A camera based referencing system is mounted on the mobile platform and determines the relative pose between robot system and drilling template. Now the end effector can be moved by the robot in front of the drill bush. Another measuring system, located at the end effector, measures its position to the selected drill bush and the perpendicularity to the template. After the robot has compensated for the positioning error, the concentric collet nose on the drilling machine can be guided into a drill bush in the drilling template. High precision is required here, as both components have tight tolerances. An expanding mandrel is used to lock into the drill bush. A forward movement of the nose allows to push the part and clamp the stacks. The drilling machine is then positioned and fixed and the drilling process can begin. Process forces that occur are diverted into the template. After the drilling operation has been performed on requested bushings, the drilling template can be dismounted. During the activities, the worker is guided through the process with augmented reality glasses.

The robotic system for the template drilling process consists of different modules, which are shown in Table 1.

One of the main challenges for the mentioned use case in Sect. 3 is to divide the production process into subprocesses and restructure them in the form of basic and composite skills as well as resources. While the modules such as a drilling unit or stereo camera need to be integrated for the current use case, the overall system should be modular enough to adapt to changing subsystems. Such systems have an added advantage of being able to be used for multiple use cases which is the idea of the Plug & Produce concept. After going through the state of the art and current challenges in the industry, a modular skill-based OPC UA architecture for future production is proposed.

The main concept behind structuring OPC UA nodesets is to keep the architecture modular and scalable. In order to have a modular software architecture, the OPC UA namespaces are structured at first as depicted in Fig. 2. The figure shows four groups: the entity, the process dependent namespaces and the two partner-specific namespaces. The UA Namespace from the OPC Foundation forms the base. The Common Skills Namespace, where our uniform skill is defined is based on the UA Namespace. In addition, general skills related to production are defined in this namespace, such as the movement skill AbsoluteCartesianMove. The standard UA Device Integration (DI) Namespace is derived from UA Namespace and is independent of the Common Skills Namespace. This all together forms a basic entity of common skills irrespective of the use case where they will be used. All further namespaces are only dependent on the basic entity consisting of the three namespaces. Both the DI Namespace and the Skill Namespace of the entity can be expanded in separate groups. Partners can thus develop their modules and reuse them in further applications without dependency on process-specific or other namespaces except to the entity.

From the process point of view, each skill defined in the above namespaces has its own finite state machine. A finite state machine represents an abstract software machine that has the ability to switch between a finite number of states, but only one state can be active at any given time. The states are representing the status of a program, which defines the software logic executed by the state machine. Every state change (transition) has an effect by triggering specific parts of the software. In the context of OPC UA, the Specification Part 5: Information Model [21] implements the model of a finite state machine in the OPC UA information model by defining the abstract object type FiniteStateMachineType. While FiniteStateMachineType is the base object type for all state machines which explicitly define the possible states and transitions, the derived ProgramStateMachineType, defined in OPC UA Specification Part 10: Programs [22], specifies a statemachine with four states: Ready, Running, Halted and Suspended, as visualized in Fig. 3.

To change between these states, ProgramStateMachineType defines a set of legal transitions, represented by instances of the TransitionType. These transitions are then triggered by OPC UA service requests and cause a TransitionEvent. Depending on the current and the next state of the state machine, specific software logic is executed. Apart from defining states and transitions, executable skills of a device represented in the OPC UA address space need to be configurable to specify the execution of the skill depending on the use case. Therefore, the ProgramSkillStateMachineType, derived from the ProgramStateMachineType is defined, which additionally implements an InputParameterSet node for storing all variables representing input data. All further defined skills in this paper are derived from the ProgramSkillStateMachineType, implementing the exact same states, transitions, etc.

In addition to basic skills of a field device, the skill concept can also be used to describe higher-level skills of a device system using OPC UA state machines. For this purpose, cascaded execution of several skills is utilized to describe more complex motion sequences known as composite skills. These skill compositions can consist of both basic skills and other composite skills.

An example of a composite skill can be described using the commonly known Pick-and-Place task to be performed by a robotic system consisting of a lightweight robot and a gripper tool. By combining the basic skills “Moving” and “Gripping” of both devices, as shown in Fig. 4, the system can offer a higher-level “Pick-and-Place” skill via OPC UA interface. In this way, composite skills can be adapted and modified to fit the overall process for a use case.

All partners of the Commands2 project modelled an OPC UA interface in order to integrate their modules into the overall system. For this, a standardized approach and tools for working with relevant OPC UA information models were communicated in advance. Apart from that, the modelling approach was also addressed in particular the exchange of data between all project partners. Additionally, the terminology for file names as well as OPC UA specific terms were defined in order to structure the creation and management of data.

In order to simplify the manipulation and exchange of information models, the OPC UA modelling editor SiOME is used. SiOME is the abbreviation for Siemens OPC UA Modeling Editor and represents a software tool to create, modify and export OPC UA information models. To enable easy data exchange and versioning of information models, the Git framework was used.

To implement the required software components for the skill-based approach described in Sect. 4, interface classes considering two different programming languages were prepared for implementing the logic of the state machines. These included the asynchronous Free OPC UA Python library¹ and the C++ library open62541². These libraries already support many functionalities of the OPC UA protocol including an implementation of the client-server model as well as OPC UA service requests which were required to implement the ProgramSkillStateMachine. However, the choice of the programming language and interface is completely free as far as the OPC UA standards are ensured. The main purpose for providing interfaces in this project was solely to speed up the implementation process and share experiences.

In this article, the implementation of an OPC UA-based skill concept is presented. The underlying concept is explained and validated using a modular lightweight robot application in an aircraft production environment (see Fig. 10). All modules necessary for the use case could be realized with the skill concept, so that all modules communicate uniformly via an OPC UA interface and offer their skills as services within the production network.

The namespace structure presented in Sect. 4 enables the inheritance of elements and type definitions from the respective parent namespaces. Child namespaces can thus adopt data structures and interfaces, which in principle enables interchangeability of modules and devices, as well as skills and skill definitions. However, this interchangeability is limited to the scope of the parent namespaces. Reusability thus depends on the scope of the namespaces in which they are distributed as standards. The dissemination of these standards can be industry-specific through UA Companion Specifications, vendor-specific or application-specific. To achieve the greatest possible compatibility, existing standards from the namespaces with the larger scope should therefore be adopted if they are available. Since there is currently no standardized skill interface with which basic functionalities can be mapped, it is proposed that these be included in a UA standard specification in accordance with the proposed Common Skills Namespace.

The definition and semantics of basic skills need to be evaluated and could be based on standard taxonomies such as VDI 2860 [24] and DIN 8580 [25] for manufacturing and handling processes as suggested in [7]. This allows inter-company compatibility and thus more flexible and quickly adaptable systems. In addition, the development of skill interfaces should be further simplified and the advantages for both device manufacturers and integrators must be worked out.

Possible future developments could include the use of discovery functionalities so that endpoints to the OPC UA servers of the individual modules no longer have to be defined. Instead, required capabilities would be requested and the modules that can provide the capabilities would connect automatically.