Keywords

1 Introduction

Manufacturing enterprises are facing increasing uncertainty in demand and variety in product types. This implies an increasing need for “flexibility” in the structure and configuration of manufacturing processes [1]. To cope with this situation, Production Systems-of-Systems (PSoSs)Footnote 1 have to be effective, efficient, yet still flexible. One type of system that addresses the flexibility needs of modern manufacturing processes is “collaborative robotics systems” [2, 3]. In collaborative robotics, human and robots work together to execute a common task. The optimisation and control of processes involving human and artificial agents (i.e. a cobot) is a challenge nowadays faced by “smart manufacturing” enterprises [4]. Hence, interoperability and flexibility have to be assured in such novel socio-technical system-of-systems composed by the human system and the collaborative robot (cobot) system [5]. Moreover, future manufacturing jobs in smart production systems will require new technical skills from the operators to work as part of these novel socio-technical systems-of-systems at the production line.

In this research work, we discuss technologies and approaches, supporting process planning for the Operator 4.0 [6] interacting with a collaborative robotic system as part of a production system. This discussion is an extended version of our work presented at the IEEE International Conference on Intelligent Systems [7]. It has been extended and the overall human-robot collaboration is discussed as a “system-of-systems” within a production system that requires a “human-robot interoperability” approach.

2 Theoretical Foundations: Systems-of-Systems Interoperability

The term “system” has been coined in the General System Theory (GST) [8]. GST aims at supporting the identification of general principles that are valid for many different types of systems. In the GST, a system is a structure of connected elements; like in a production system where a production line, a manufacturing cell, or a workstation are a group of interrelated production resources. Each part, and therefore, the overall system shows a behaviour (i.e. producing a part, assembly, or final product). According to [9], a system is separated from the environment by a boundary or interface; a system (e.g. a workstation) fulfils one or more functions providing some outcome concerning its objectives; systems interact with the environment and other systems through interfaces (e.g. a human and a robot interact using a human-robot interface to become a team in a workstation); and the environment and other systems may influence the system’s behaviour and structure (e.g. the type of a manufacturing cell or production line). Moreover, the possibility of a system to change its behaviour allows a system to evolve from a given state to another one over time (e.g. a flexible or reconfigurable manufacturing cell or system [1]). A system may influence its environment in turn. The behaviour of a system is determined by the functions that the system executes (e.g. its production capabilities). A system has an objective that it wants to meet, its purpose (e.g. its production objectives).

In a system-of-systems, multiple systems act together, forming a “supra-system” (i.e. a production system can be composed by multiple production lines, with multiple manufacturing cells, with multiple workstations). It is important to understand that the systems forming a system-of-systems, remain independent. The systems still follow their individual purpose. The formation of a system-of-systems does not allow to integrate systems which would lose their own freedom and/or purpose. Systems in a system-of-systems may leave or join a system if it does not fit to their individual purpose. In this view, systems actively manage their own state. In case of high dynamics (e.g. due to frequent changes in behaviour) such system-of-systems may be seen as Complex Adaptive Systems (CAS) with many human and artificial agents interacting with each other [8]. Such is the case of flexible/reconfigurable manufacturing cells/systems [1].

A system-of-systems can be analysed from two points of views: (i) the resource point of view, and (ii) the interaction point of view. In this paper, our focus is the interaction point of view, which requires understanding to which degree the systems need to be “interoperable”.

An agent-based system is a system-of-systems where the agents have their individual goals. Some sort of negotiation needs to take place for cooperation and alignment of the activities of the agents. Often using some money or equivalent mechanism [10].

2.1 Interoperability of Interacting Systems

Before being able to choose a mechanism for coordination of systems in a system-of-systems (i.e. a production system-of-systems), the degree of coupling between systems needs to be considered, which is the focus of research of “enterprise interoperability”.

Recently, steps towards a formulation of enterprise interoperability using the GST as their baseline have been started [9, 11]. Special attention is being put to the gaps and barriers between systems interaction. Figure 1 presents the European Enterprise Interoperability Framework, where several areas of research have been marked in dark grey circles [4]. The semantic alignment in the middle relies on technical interoperability (i.e. syntax of data and transport). On the organisational level, process interoperability is important. Moreover, process interoperability can also be referred to as interoperability on a pragmatic level. The pragmatics relies on a common semantics. On this level also knowledge transfer between systems and actors is important [12].

Fig. 1.
figure 1

European Enterprise Interoperability Framework (EEIF) [4]

2.2 Interoperability Approaches, Timing and Barriers

Interoperability barriers are discussed in the domain of enterprise interoperability along the following dimensions [13]: (i) interoperability approaches (i.e. federated, unified, and tight integrated), (ii) interoperability timing (i.e. a priori/design-time solutions, and a posteriori/run-time solutions), and (iii) interoperability levels/barriers (i.e. legal, organisational (business, processes), semantic-conceptual, and technological). Furthermore, interoperability approaches can be classified according to their degree of coupling: (i) Systems are tightly integrated by definition. The elements of the system are dependent on each other. The breakdown of one element will lead to the breakdown of the overall system. (ii) A unified approach supports interoperability by establishing a common reference. Different systems can reference the common reference. Through this a layer of abstraction, a common layer for communication is established. This implies an additional indirection in the communication. The systems’ internal states and messages need to be translated into the common language. This supports the independence of the individual systems. Any system that is knowledgeable of this reference can participate in a system-of-systems. (iii) The most loosely coupled approach is a “federation” where the participating systems negotiate over the interfaces at run-time.

In integrated approaches (e.g. integrated manufacturing cells or systems), the interoperability is often established at design-time. This requires to anticipate problems and to overcome barriers before systems are built. Federated interoperability approaches establish interoperability at run-time. Such approaches allow reacting to problems after their occurrence in the running system (flexible or reconfigurable manufacturing cells or systems) [1].

The interoperability problems can occur on different levels of the enterprise. The system-of-systems discussed in the following includes human, robots for collaborative applications and artificial agents. Therefore, interoperability at the process level and unified interoperability are the most relevant.

3 Systems-of-Systems: Task and Resource Planning

To be able to plan “interaction” in systems-of-systems, both task and resource planning needs to be done. The resources are mostly discussed in the physical world in the EEIF framework in terms of organisation and process interoperability. Hence, to achieve self-organisation and self-maintenance systems; data, information and knowledge transfer is vital. One of the important interoperabilities to achieve this is the “semantic interoperability”. The complexity is to include both resource allocation and function allocation [14] in the planning system of different resources with different levels of automation (i.e. humans, machines, and robots). A lot of research is addressing the complexity of including skills to automatic systems [15,16,17].

3.1 Task and Resource Allocation in Systems-of-Systems (SoS)

Within the research field of human factors, two well-known approaches have been used for task and resource allocation: (i) HTA (Hierarchical Task Analysis) [18], and (ii) CTA (Cognitive Task Analysis) [19]. When comparing these two approaches, HTA focuses on the goal, while CTA uses a qualitative method mix (i.e. interviews and observation strategies) for capturing the knowledge that experts use for tasks operation [7]. Both methods aim at optimising the task allocation for human resources. In the context of balanced automation systems, where human and robots cooperate, optimisation does not only refer to time and costs dimensions but also to a “cognitive” dimension. Human operators’ cognitive load needs to be taken into account to provide a “good” plan. Cognitive overload and cognitive underload (i.e. boring tasks) both have an impact on the performance of the human operator. Interoperability in this context refers to the suitability of a process that a human operator has to execute. Allocation of tasks usually happens at “design-time”. This implies less flexibility and less resilience. To have an adoptable SoS, the optimisation needs to be executed more frequently than it is today. By using the semantic interoperability together with the organisational interoperability, data from the system in terms of deviation in cycle time can be used together with the information and knowledge transferring systems in the organisational interoperability. In our approach, the tasks are defined from a CAD model to a Bill-of- Material (BOM). A two-steps approach to optimise task allocation to resources have been identified, illustrated in Fig. 2 [14]: (Step 1) – Global optimisation, containing both tasks and resources and is product depended (i.e. what components will be assembled). A digital product is defined in the PLM system. The HTA is used to determine the Bill-of-Process (BOP) that is later used for instructions and orchestration; (Step 2) – Local optimisation is competence dependent: (Step 2a) Task allocation with resource alternatives – here, alternative resources (i.e. redundancy) are made. For the resource allocation and integration between humans and robots, five different scenarios, working individually or in teams has been identified by [20], which should be considered in (Step 2b) to plan for collaborative applications, as illustrated in the Fig. 2. The complexity (depth of the diagrams) increases a lot when both humans and robots are part of the same operation and task. The “competence” of the production resources can be pre-defined by using the ontology of S-BPM that will be discussed in Sect. 3.2.

Fig. 2.
figure 2

Task and resource allocation

3.2 Message-Based Systems Used for Interaction Between Resources

To increase flexibility during task execution and to increase the interaction between the resources, message-based systems can be used. S-BPM (Subject-oriented Business Process Management) is an approach that mixes message-based systems with process-based systems [21]. At its heart, it is a communication-oriented approach. Two subjects are modelled that exchange messages, called: “business objects”. The subject is similar to a process-oriented role. A subject is responsible for the execution of a part of the process. The S-BPM modelling language separates the two points of view in two diagrams. [7]. Coordination and interoperability of human and robots are through communication. Here, the interaction is driven by messages exchange. These messages trigger a certain behaviour, which then can result in a particular action or another message being sent [22]. Multi-Agent Systems (MAS) [10], and Actor-based Systems (ABS) [22] are a particularly well-known approach where agents are interacting through sending and receiving messages. Taking the term “skill”, it is possible to implement different subject-behaviours for different skills. The other subjects in a process are not influenced when the same message-based interaction protocol is executed. However, the human may be guided by the workflow system implementing the S-BPM workflow according to different levels of automation. Skills can be modelled as subjects. In this approach, skills are not static properties of an actor but define the behaviour. Having predefined processes that determine the behaviour support “design-time planning” for a structured process. While this reduces flexibility, it also reduces the complexity. Dynamics is introduced when at “run-time”, a different subject-behaviour is executed (e.g. because a different operator with a different skill is collaborating with the robot).

3.3 Interaction Between Humans and Robots

After determining the details of the interaction and establishing interoperability on the process level, the technology on the interface between systems needs to be determined. The Operator 4.0 typology provides several technologies that support the interaction of humans and robots [6]. Only the relevant ones have been selected. The technology used will be the interface through which the interaction happens. As such, the kind of message exchanged will depend on technology as well. In some cases pressure sensors with trigger events (i.e. simple messages): (i) Operator + Exoskeleton = Super-Strength Operator – The robotic system directly supports the worker in her/his doing. The message exchange happens through sensors. Messages as such are simple. Here the response time is essential; (ii) Operator + Augmented Reality = Augmented Operator – The interaction will be visible on the Augmented Reality (AR) technology. This allows reaching message exchanges in both directions; (iii) Operator + Wearable Tracker = Healthy Operator – Trackers may be used as sensors that trigger events. These events (again) can be used as messages for the interaction protocol between subjects; and (iv) Operator + Collaborative Robot = Collaborative Operator – The robot itself may be equipped with sensors that may be capable of understanding natural language. In this solution, a technology used for the interaction might be needed so that the operator knows the next position and task that the robot shall do and vice versa. For robotic tasks planning it has been extended by a skills/competency matrix to better support human operators in planning [23].

3.4 Orchestrating the Planning in Process-Oriented Systems

Resource planning is often done for the implicit “happy” path only. Unexpected events (e.g. running out of materials, machine break-down) require ad-hoc replanning and design time solutions have no flexibility, and therefore no resilience. For more robust plans, the number of alternative resources (i.e. humans as well as robots) that need to be included needs to be higher. To increase the predictability of a system-of-systems, process-based systems have been created. Process models and process management supports the orchestration of an integrated system. In our approach, the PTC IIoT platform ThingWorx (TWX) is used for orchestration and cellular management [24] as illustrated in Fig. 3.

Fig. 3.
figure 3

Orchestration and cellular management between resources and systems

The orchestration is used as a simple MES (Manufacturing Execution System) that listens to the current situation regarding the product, components, and task allocation. Furthermore, the “thing” also keeps tracks of the assets and the resources. To create an SoS ecosystem, interoperability across platforms must be enabled. Such interoperability will let developers create applications by combining data from multiple platforms [24]. Further research will be to connect the actor-based system with the orchestration of the ThingWorx platform to increase the interaction between resources with higher levels of automation, both physical and cognitive by combining different platforms.

4 Conclusions

In this work, we focused on process interoperability of socio-technical systems-of-systems. The described approach makes use of the skills and capabilities of human and artificial agents. Multiple instruments have been aligned to support the Operator 4.0. First tasks are assigned to resources, for optimisation a priority with respect to the level of automation is determined. The skills also determine the detailed interaction on process level between the participating systems (i.e. human and artificial agents). Finally, we also determine the technologies used on the interface between the human and the robot.