Implementation and Evaluation of Dynamic Task Allocation for Human–Robot Collaboration in Assembly

Abstract

Human–robot collaboration is becoming increasingly important in industrial assembly. In view of high cost pressure, resulting productivity requirements, and the trend towards human-centered automation in the context of Industry 5.0, a reasonable allocation of individual assembly tasks to humans or robots is of central importance. Therefore, this article presents a new approach for dynamic task allocation, its integration into an intuitive block-based process planning framework, and its evaluation in comparison to both manual assembly and static task allocation. For evaluation, a systematic methodology for comprehensive assessment of task allocation approaches is developed, followed by a corresponding user study. The results of the study show for the dynamic task allocation on the one hand a higher fluency in the human–robot collaboration with good adaptation to process delays, and on the other hand a reduction in the cycle time for assembly processes with sufficiently high degrees of parallelism. Based on the study results, we draw conclusions regarding assembly scenarios in which manual assembly or collaborative assembly with static or dynamic task allocation is most appropriate. Finally, we discuss the implications for process planning when using the proposed task allocation framework.

1. Introduction

Future manufacturing environments are characterized by workplaces in which human workers and robots work closely together [1]. The industrial assembly has a key impact on productivity and profitability of companies [2] and is to date still largely operated fully manually [3,4]. In view of increasing flexibility requirements due to individualized products, dynamically changing market demands, and shorter product life cycles [5], appropriate solutions to ensure companies’ efficiency and profitability must be implemented [6]. When effectively combining the strengths of humans and robots, productivity for small to medium batch sizes can be improved compared to purely manual assembly [7], while maintaining a higher degree of flexibility compared to fully automated systems [8]. Consequently, industrial assembly represents one of the main fields for the transformation towards hybrid workplaces in human–robot collaboration (HRC) [9,10].

From a human-centric perspective, which belongs to the key concepts for the evolution towards Industry 5.0 [11], particularly Operator 5.0 [12], employees working in such hybrid assembly workplaces should be supported in a meaningful way, with the aim of reducing monotonous, repetitive, or ergonomically unfavorable tasks to a minimum, and relieving the employees’ cognitive stress [13]. Therefore, the combination of information-based assembly assistance systems, which are already widely used in industrial manual assembly, with collaborative robots as a physical support system offers a promising solution approach for the design of hybrid assembly workplaces [14,15,16].

The aforementioned envisioned potentials of collaborative robots are reflected in a strongly growing market volume for collaborative robots [17]. The dominant industrial application is the field of assembly, which accounts for a share of more than 70% of collaborative robot applications [18] and is also the most studied area in HRC research [13]. The main tasks of collaborative robots are gripping, mounting or joining, quality control, pick and place, packing and palletizing, and machine loading [18,19]. Driving sectors are especially the automotive and electronics industries [13,18,20]. However, smaller companies in particular rarely use collaborative robots to date [21]. Moreover, in most industrial applications of collaborative robots, human workers and robots work in separate workspaces and do not collaborate closely together yet [18,22,23]. Here, two major topic areas were identified as challenges explaining this lack of application in which humans and robots share the same collaborative workspace, namely (1) safety aspects and (2) planning aspects [8,24].

This article addresses the planning challenge of task allocation, i.e., an effective division of labor between humans and robots. The allocation of tasks to humans or robots can be performed either statically, i.e., prior to task execution, or dynamically, i.e., in response to changes during the task execution [25,26]. In the literature, various methods for both static and dynamic task allocation have been proposed (see Section 1.2). However, on the one hand, apart from validating the principal functionality of the respective methods or evaluating them in simulation studies, no comprehensive evaluation in an experimental test setup has yet been conducted that systematically examines and empirically assesses the advantages and disadvantages of both approaches to task allocation. On the other hand, related approaches do not focus on an intuitive and integrated creation of the HRC assembly processes.

To overcome this research gap, this work presents on the one hand the development of an approach for dynamic task allocation as well as its implementation into a robot no-code programming framework, including the visualization of worker instructions and the assembly progress. On the other hand, it focuses on a systematic evaluation of the dynamic task allocation approach in comparison with static task allocation in a laboratory user study. The results of this article provide new insights about the most suitable task allocation mode for human–robot collaboration depending on the quality of the initial static planning, on the duration of possible process interruptions, and on the flexibility (in terms of parallelism and length) of the assembly process.

The remainder of this article is structured as follows: Section 1.1 and Section 1.2 provide an overview on HRC in assembly and related task allocation approaches for HRC, including their evaluation results. Based on this, a summary on the scope and contribution of the article is given in Section 1.3. Section 2 first describes the proposed methodology for dynamic task allocation including its integration into the no-code programming framework. Then, the user study design including the experimental setup and procedure of the study as well as the applied metrics and the evaluation procedure are presented. The results of the study are provided in Section 3 and are subsequently discussed in Section 4. Finally, Section 5 concludes this article by summarizing the main findings and provides an outlook on future research directions.

1.1. Human–Robot Collaboration

1.1.1. Challenges for Introducing Collaborative Robots

The potentials and expectations associated with HRC are an increase in quality, efficiency, flexibility, and productivity while improving ergonomic working conditions and reducing the repetitive workload [18,26,27,28]. However, several studies [8,22,24,29,30] also examined the challenges that still hinder the introduction of collaborative robots. An overview of the identified major challenges is collected in

Table 1. Key challenges in human–robot collaboration (HRC) identified in the literature and grouped into three categories: safety, planning, and technology. The original categories of challenges proposed by the respective references are indicated in italics. The challenge of task allocation is highlighted in bold in the referenced studies.

Category	[8,24] 1	[29]	[30]	[22] 2
Safety	Individual risk assessment Application of norms in practice Approval through inspecting authority	Safe interaction Safety standards Collaborative operating modes	Individual risk assessment Safety certifications are costly and time-consuming	Safety Application of norms in practice Individual risk assessment Human’s trust in robot Certification
Planning	Identification of suitable workstations Workplace design Task allocation among human and robot Quantification of effect on flexibility Quantification of effect on productivity	Intuitive interfaces Programming approaches Input modes Design methods Task planning and task allocation	Lack of professional expertise and robot programmers in SMEs Fragmentation of human tasks	Performance Limited speed Lack of quality checks Strategy Cost-effectiveness Identification of suitable workstations Task allocation among humans and robots Involvement and training Need for training and education of workers Involvement of operators Fear of being replaced
Technology	-	Design methods Control laws Sensors	Handling of unforeseen errors is costly	Smart technology Intelligent solutions for quality control Flexible robot movement between different workstations

¹ Extract of the top eight challenges for implementing HRC according to robot manufacturers. ² Focus on challenges reported from industry.

and classified into the categories of safety, planning, and technology (cf. [24]). Similar aspects were also reported in the vice versa study on success factors for the introduction of industrial HRC [31]. This article focuses on the identified challenge of appropriate task allocation (see Table 1).

1.1.2. Classification of Cooperation Levels between Humans and Robots

Figure 1 shows a classification of cooperation levels between humans and robots into five types—cell, coexistence, synchronized (also sequential cooperation [32]), cooperation, and collaboration—depending on the workspace, the task, and the required safety mechanisms [18,33]. Cellular operation represents the classical safety fence operation of industrial robots, which is used in fully automated processes, while the other types of collaboration are typically realized with collaborative robot systems.

A requirement for the implementation of a dynamic task allocation is the existence of a shared workspace, as both the human and the robot must be able to substitute their counterpart and perform the appropriate assembly work when the other is not available. Thus, due to the shared workspace, dynamic task allocation is feasible in the cooperation levels of synchronization, cooperation, and collaboration.

1.2. Task Allocation for Human–Robot Collaboration in Assembly

To address the challenge of task allocation, several methods were proposed, which can be classified into static or dynamic task allocation approaches [25,26]. Static task allocation mainly considers the planning phase (“offline”), dealing with the creation of a fixed task schedule prior to execution. For this, both planning methods and optimization algorithms have been proposed. Planning methods are either carried out manually, e.g., [26,27], or in conjunction with a planning assistance system, e.g., [35]. In such methods, the potentials of both resources are usually assessed first and then a process schedule is created using a task allocation logic based on the assessment. Optimization approaches automatically generate different allocation alternatives and select the one that best satisfies a cost function, e.g., [36,37,38]. In contrast, dynamic task allocation approaches, e.g., [39,40], consider the assembly execution phase (“online”) and focus on the (re-)allocation of tasks in the case of deviations from the initial assembly planning.

Table A1. Overview of related task allocation methods and their evaluation approaches. Task allocation methods that have been evaluated in user studies are highlighted in light grey.

No.	Ref.	Classification	Year	Proposed Task Allocation Approach	Evaluation Scenario	No. of Tasks	Evaluation Approach	Main Evaluation Result
1	[36]	static	2022	optimization algorithm for planning	Mold assembly use case including required tool changes (scenario extracted from online video)	13	Simulation-based evaluation comparing different assembly setups: - Manual; - Human–robot (H-R); - Human–two-robot (H-2R).	H-R/H-2R process: - Reduces time by 2/5% over manual assembly; - Reduces MSD risk from medium to low/negligible risk over manual assembly.
2	[35]	static	2019	planning method with guided assistance software	Industrial use case of linear actuator assembly	10	Demonstration of planning process	Validation of planning approach
3	[27]	static	2016	planning method	Industrial use case of aircraft fuselage shell element assembly	16	Demonstration of planning process	Validation of planning approach
4	[26]	static	2022	planning method	Industrial use case of touch-screen cash register assembly	35	Demonstration of planning process	Validation of planning approach
5	[41]	static	2018	planning method with simulation tool	Industrial use case of brake disc assembly	28	Demonstration of planning process Validation of planning result in simulation and laboratory setup	Validation of planning approachH-R process: - Increases total assembly time by 17% over manual assembly; - Improves ergonomics.
6	[37]	static	2022	optimization algorithm for planning	Laboratory use case of HDD disassembly	14	Demonstration of process planning algorithm for disassembly scenario with different processing periods	Validation of implemented optimization algorithm for task allocation
7	[38]	static	2018	optimization algorithm for planning with simulation tool	Industrial use case of a workplace in automotive final assembly line	14	Demonstration of task allocation algorithm in simulation	Validation of simulation tool and optimization algorithm for task allocationH-R process: - Reduces time by 25% over manual assembly.
8	[39]	dynamic	2019	reactive system for online execution	Laboratory use case of gearbox assembly	34	Demonstration of dynamic task allocation system for different workload limits	Validation of implemented system
9	[42]	dynamic	2018	reactive system for online execution	Laboratory use case of LEGO blocks assembly	12	Evaluation of different conditions of trust consideration in user study (20 subjects)	Validation of implemented systemTrust between H and R: - Positively influences satisfaction and cognitive workload; - Improves performance by up to 15%.
10	[44,66]	dynamic	2018	planning method with software support reactive system for online execution	Laboratory use case of flange assembly; industrial use case of snowplow mill assembly	26; 65	Demonstration of planning processDemonstration of dynamic task reassignment system	Validation of implemented system
11	[40]	dynamic	2021	reactive system for online execution	Laboratory pick-and-place packaging scenario	9	Demonstration of static and dynamic task allocation for delays: - Sslow human task execution; - Planning failures; - Occupied workspace.	Validation of implemented system
12	[67]	dynamic	2016	optimization algorithm for planning re-planning for online execution	Industrial use case of automotive hydraulic pump assembly	5	Demonstration of task allocation algorithm	Validation of implemented system
13	[68]	dynamic	2014	optimization algorithm for planning or online execution	Power module box assembly use case	18	Demonstration of task allocation optimization algorithm for human–two-robot assembly setup	Validation of implemented system
14	[43]	dynamic	2022	reactive system for online execution	Laboratory pick-and-place packaging scenario	24	Evaluation of static and dynamic task allocation in user study (14 subjects) with: - Component boxes on different heights (different physically demanding).	Validation of implemented system and fatigue estimation strategy Dynamic task allocation: - Reduces cycle time by 16% over static task allocation; - Reduces human fatigue.
15	[25]	dynamic	2018	reactive system for online execution	Laboratory use case of table assembly	6	Demonstration of dynamic task allocation system for human–two-robot assembly setup	Validation of implemented system
16	[69]	dynamic	2017	optimization algorithm for planning reactive system for online execution	Theoretical process; laboratory use case	8; 6	Simulation-based demonstration of planning system in human–two-robot setup Demonstration of dynamic task allocation system	Validation of implemented planning algorithm Validation of implemented system

in Appendix A provides an overview of related work on task allocation, including a short description regarding the type of the proposed approach. Further, details on the evaluation scenario, the evaluation approach, and the main results of the evaluation are presented. The vast majority of task allocation approaches in the related work only validate the general functionality of the proposed approach. However, only a few articles [36,38,41] evaluate their approach by comparing the resulting task schedules or the metrics of the actual assembly process execution with those of manual assembly. Moreover, effects of real-time execution arising from the assembly execution by different, also untrained persons, or from delays due to unforeseen events, are rarely taken into account. Instead of carrying out a user study with users being not familiar with the system, the proposed approaches are often either solely tested in simulation or by the respective authors themselves.

For considering these effects, only two references [42,43] conducted user studies for evaluation of their proposed approaches (highlighted in light grey in Table A1). From those, the study in [42] evaluates the implications of different trust levels on human satisfaction and assembly performance. Reference [43] proposes a dynamic task allocation system that aims at minimizing human fatigue and compares their approach with a static task plan in a user study.

1.3. Scope and Contributions of the Article

The dynamic task allocation system presented in this work differs from the approach in [43] by focusing on the dynamic reduction in cycle times, even in the case of unforeseen delays on the one hand and by integrating the approach into a block-based programming framework on the other. With the latter, we aim to address—in addition to the core subject matter of task allocation—the reported challenge of intuitive programming (cf. Table 1) and aim to enable easy transferability to different application scenarios. Thus far only very few approaches to task allocation utilize block-based or visual programming for task allocation, but hard-code the program for the specific application instead. We only identified one approach [30] that utilizes a BPMN-based drag-and-drop programming interface for defining tasks as either human or robot. However, these tasks are only assigned statically without a possibility for dynamic adaptation.

The dynamic task allocation system proposed in this article is therefore the first that integrates intuitive block-based programming with dynamic task allocation. The block-based programming facilitates planning and enables transferability to different use cases as well as different robotic systems.

The dynamic task allocation methodology further differs from the related work approaches that mostly require an initial static process planning prior to execution, which is then adapted during execution in the case of plan deviations by flipping the task assignment. As such deviations occur frequently in high-mix, low-volume assembly, resulting in a high variability of the time spent on each task [44], we present a system that minimizes the initial planning effort by only requiring the task classification and the assembly priority chart as inputs to create a process flow. The process control and the task allocation are then performed automatically during task execution.

Within this article, we further intend to evaluate the effects of static and dynamic task allocation depending on planning quality, duration of delays, and the degree of process flexibility. For this, we propose an evaluation system and perform the evaluation in a comprehensive user study. By systematically investigating the dependencies on these aspects, we seek to derive a first recommendation regarding scenarios in which either static or dynamic task allocation is preferable.

2. Materials and Methods

The research work presented in this article is based on the Design Science Research (DSR) framework [45,46] and follows the DSR procedure model proposed in [46]. Figure 2 shows the contents of this article and links them to the phases of the DSR process. In addition, the methodological approach within the phases is briefly described and a reference to the individual sections of this article is given.

The following sections first shortly describe the software framework and the system architecture utilized for the implementation of the task allocation system (Section 2.1) to provide the overall context for understanding the system. Then, the designed planning procedure and the dynamic task allocation methodology as well as its integration into the software framework in terms of implementation details and user interface design are presented in Section 2.2. Finally, Section 2.3 presents details on the design of the evaluation study regarding the experimental setup, the implemented task allocation modes, the study procedure, the recorded parameters and metrics, as well as the data analysis.

2.1. Software Framework for Block-Based No-Code Programming

Based on the desire to ensure a broad usability of the envisaged approach for task distribution and an easy adaptation to different use cases or robotic systems, a visual no-code programming framework was chosen as a basis for the implementation of HRC task allocation. The framework ComFlow [47,48] satisfies these requirements by enabling an intuitive generation of process flows for various technical systems via a web-based user interface by means of system-specific functional blocks. Figure 3 shows the system architecture of the ComFlow software framework including the integrated module for task allocation proposed in this article. The framework consists of a server to which different technical systems can be connected, a process flow manager for creation and control of process flows, a digital twin for virtual testing of processes during the planning phase and real-time monitoring of systems during the execution phase, and the module for HRC task allocation, which is detailed in the following section. The process flow manager and the digital twin are both integrated into the web-based user interface, which can be accessed by different end-devices. The user interfaces comprise two views—a planning view (planning HMI) and an execution view (execution HMI)—as schematically illustrated in Figure 4.

For each technical system to be controlled, functional blocks are defined which map to control commands of the respective system, such as movement to waypoint or control of gripper. In addition, system-independent functional blocks can be created, which enable human interaction in terms of information provision and requests for confirmation on the one hand, or control the process flow, for example by means of and/or connections, pauses, or multi-output decision nodes. Using these functional nodes, the user can create process flows by drag-and-drop blocks and connect blocks to create the logical process sequence (see Section 2.2.3). The use of and nodes also allows easy synchronization between different systems, as these ensure that all connected preceding functional blocks have been completed.

Further details on the ComFlow software framework, including a research study validating the time-effectiveness and intuitive usability of the planning software, are provided in [47,48].

2.2. Dynamic Task Allocation Module

In the following, the proposed HRC task allocation module that enables the combination of flexible block-based programming with dynamic task allocation of assembly processes is explained. First, the indented planning process is described (Section 2.2.1), followed by an explanation of the proposed dynamic task allocation methodology (Section 2.2.2), and finally its implementation into the block-based software framework (Section 2.2.3).

2.2.1. Planning Procedure

This article primarily focuses on the real-world realization phase of the assembly planning process. Therefore, the following inputs are assumed to be given from assembly draft planning:

• Assembly priority chart;
• Task time estimation;
• Task classification.

The assembly priority chart (or assembly precedence graph) is a typical planning document that is created along the phases of the assembly planning process [49], regardless of whether it is a manual, hybrid, or fully automated assembly process. The task time estimation can be carried out with the help of different time determination methods. Depending on brownfield or greenfield planning, time measurement, MTM for human execution times, and MTM-HRC [50] for estimation of robot execution times can be used. The task classification contains information about whether a task can in principle be performed by the human, by the robot, or by both. In the following, we denote tasks that can only be performed by the human or by the robot, respectively, as tasks with unambiguous task classification. In order to systematically assess the information about task classification, various methods have been proposed in the state of research, such as [26,35] (see also Section 1.2).

Given these input data, the process for realization and execution of the assembly process covered by the system proposed in this article is shown in Figure 4. First, the planning or commissioning personnel creates the individual tasks of the process. These tasks each include the separate definition of the human and robotic commands necessary to complete the task by the respective resource. For the human, this is typically a set of informational assembly instructions in the form of textual description and a visual illustration. A sequence of motion and gripping activities is typically defined for the robot, for which the corresponding waypoints for the robot need to be taught initially.

After the creation of all sub-processes, the overall assembly process is created. This is performed by linking the individual tasks, which are represented as functional blocks (HRC nodes, see Figure 5), according to the given assembly priority chart. Finally, the task classification and time estimation are defined for each HRC node.

Once the process has been created, it can immediately be tested in simulation using the digital twin and then be executed on the real human–robot assembly station, all within the same software framework.

During execution, the ComFlow process manager ensures the execution of the generated process flow according to the priority constraints and communicates with the dynamic task allocation module for the assignment of tasks to a human or robot. Depending on the assignment, the respective defined execution sequences are retrieved, and the commands are sent to the robot or the worker instruction system for execution by the respective resource. After finishing an executed task, the completion of the task is reported to the process manager based on the robot status or by active confirmation from the worker. Afterwards, the next tasks are assigned until the entire assembly process is completed.

A conceptual depiction of the corresponding user interfaces for the realization and execution phase are shown in the lower part of Figure 4; further details on the actual implementation are given in Section 2.2.3.

2.2.2. Methodology for Dynamic Task Allocation

The task allocation module of the presented system architecture (see Figure 3 and Figure 4) implements the methodology for distributing tasks between humans and robots during execution of a created process flow. The proposed methodology for dynamic task allocation is described in the following.

During the above explained process creation, the individual HRC nodes are created and interlinked, and the properties of these nodes are entered via input masks. As shown in Figure 5, these properties cover information about the task classification, the estimated execution time of the task for humans and robots, and the priority of the task. The latter serves as an additional decision criterion to determine a suitable prioritization with regard to the execution sequence of tasks.

As schematically illustrated in Figure 6, the created overall assembly process consists of a set of tasks $T$. During execution, the tasks are executed progressively according to the precedence relationships and the task allocation logic until the process is terminated with the end node. During this, the states of the tasks change as follows (cf. Figure 6):

• Not executed—not yet available (remaining tasks; highlighted in gray);
• Not executed—available (currently available tasks T_av; yellow);
• In execution by robot (blue), or in execution by human (purple);
• Completed (finished tasks; green).

Figure 6. Schematic representation of a process flow during process execution with different states of tasks and task clusters highlighted.

Figure 6. Schematic representation of a process flow during process execution with different states of tasks and task clusters highlighted.

Figure 7 shows the flowchart of the proposed methodology for dynamic task allocation. A more detailed version of the flowchart is provided in Appendix D in Figure A2. The variables are denoted as follows:

$T_{\mathrm{av}}$	Available tasks of current layer (see Figure 6, yellow);
$T_{\mathrm{av}}^i$	The $i$th task from available tasks $T_{\mathrm{av}}$ of current layer;
$n\left(T\right)$	Number of tasks $T$;
$L$	Classification of task—available resource labels are $\mathrm{H}$: human, $\mathrm{R}$: robot, $\mathrm{H}/\mathrm{R}$: human or robot;
$T_{\mathrm{av}, L=\left\{\mathrm{X}\right\}}$	Available tasks with resource label $\mathrm{X}$ (i.e., $\mathrm{H}$, $\mathrm{R}$, or $\mathrm{H}/\mathrm{R}$);
$P_T$	Priority of task;
$T_{\left\{\mathrm{X}\right\},\min }$	Task with minimal execution time among tasks with label $\mathrm{X}$;
$T_{\left\{\mathrm{term}\right\},P}$	Task with highest priority $P_{\min }$, i.e., minimum numeric value $P$, among tasks fulfilling the condition term;
$T_{\left\{\mathrm{XY}\right\},\mathrm{maxdiff}}$	Task with a maximum difference between the execution times of resources X and Y among tasks with label XY;
$t_{\left\{\mathrm{X}\right\}}\left(T\right)$	Estimated execution time of resource X (H: human or R: robot) for task T.

The general idea of the dynamic task allocation methodology is to iteratively (either continuously or after finishing a task) request all currently available tasks $T_{\mathrm{av}}$ and decide for these which task should be performed next by either the human or the robot. For this decision, the abovementioned properties of the HRC nodes are utilized. The decision for the assignment of tasks is conducted according to the following scheme:

• The availability of the resources is checked.
• For each available resource, the currently available task with an unambiguous, matching task classification and minimum execution time (see Equations (1) and (2) for calculation) is assigned.
• If no more tasks with unambiguous task classification are currently available, tasks which are eligible for both the human and robot are considered, and the task in which the particular resource has the highest advantage in execution time over the other (see Equations (3) and (4) for calculation) is assigned to the respective available resource.

As referenced above, the following formulas are used to determine the variables $T_{\mathrm{R},\min }$, $T_{\mathrm{H},\min }$, $T_{\mathrm{HR},\mathrm{maxdiff}}$, and $T_{\mathrm{RH},\mathrm{maxdiff}}$ used in the flowchart in Figure 7.

$$T_{\mathrm{R},\min }=\underset{T_{\mathrm{av}}^i\in T_{\mathrm{av}}}{\min }\left\{t_{\mathrm{R}}\left(T_{\mathrm{av}, L=\mathrm{R}}^i\right)\right\},$$

(1)

$$T_{\mathrm{H},\min }=\underset{T_{\mathrm{av}}^i\in T_{\mathrm{av}}}{\min }\left\{t_{\mathrm{H}}\left(T_{\mathrm{av}, L=\mathrm{H}}^i\right)\right\},$$

(2)

$$T_{\mathrm{HR},\mathrm{maxdiff}}=\underset{T_{\mathrm{av}}^i\in T_{\mathrm{av}}}{\max }\left\{t_{\mathrm{H}}\left(T_{\mathrm{av},L=\mathrm{H}/\mathrm{R}}^i\right)-t_{\mathrm{R}}\left(T_{\mathrm{av},L=\mathrm{H}/\mathrm{R}}^i\right)\right\},$$

(3)

$$T_{\mathrm{RH},\mathrm{maxdiff}}=\underset{T_{\mathrm{av}}^i\in T_{\mathrm{av}}}{\max }\left\{t_{\mathrm{R}}\left(T_{\mathrm{av},L=\mathrm{H}/\mathrm{R}}^i\right)-t_{\mathrm{H}}\left(T_{\mathrm{av},L=\mathrm{H}/\mathrm{R}}^i\right)\right\},$$

(4)

2.2.3. Implementation of Task Allocation Module into Software Framework

The conceptualized module for HRC task allocation was implemented and integrated into the ComFlow software framework as indicated in the system architecture shown in Figure 3. The backend implements the process logic including the task allocation algorithm and is developed with TypeScript and Node.js. It serves the frontend, which is developed with TypeScript and React. The systems used in this article (collaborative robot UR5e and two-finger gripper Robotiq Hand-E) communicate with the software framework via publicly available ROS (robot operating system) interfaces.

Figure 8 and Figure 9 show the user interface of the ComFlow framework with the implemented nodes for HRC task allocation. The task creation, i.e., the creation of HRC sub-processes, is depicted in Figure 8. The initial decision node switches the subsequent process sequence between human and robot depending on the final task assignment according to the higher-level task allocation algorithm. The sub-process is then saved by entering a name as well as selecting the process type sub-process. For creating the overall assembly process, the saved sub-process can then be selected as a sub-process node and added via drag-and-drop, as shown in Figure 9. The HRC sub-process nodes comprise the properties explained in Section 2.2.2.

An exemplary assembly process with multiple connected HRC nodes is shown in Figure 10. After saving the process with type selection process the user can switch into the process flow viewer intended for workers and start the process execution using the process control buttons (Figure 11). As explained in Section 2.2.1, the assembly instructions for the tasks assigned to the human are displayed in the lower part of the screen and the progress of the process is visualized in the process flow viewer by changing the status color of the individual blocks.

2.3. Study Design and Evaluation Methodology

To validate the implemented system as well as the proposed algorithm for dynamic task allocation on the one hand, and to evaluate the characteristics and effects of different types of task allocation on the other hand, a user study was designed. The study design and evaluation methodology are presented in the following, starting with the experimental setup (Section 2.3.1), the assessed aspects and collected data (Section 2.3.2), the procedure of the study (Section 2.3.3), and finally the approach for data analysis (Section 2.3.4).

2.3.1. Experimental Setup and Task Allocation Modes

For the study, a collaborative assembly station was set up (see Figure 12), consisting of a collaborative robot (Universal Robots UR5e) with a two-finger gripper (Robotiq Hand-E gripper), which is located in the center of the assembly station, a touch screen for displaying the previously described user interface, as well as areas for material supply and assembly. The material is provided in an orderly arrangement.

A warehouse for parts, in which screws are stored, is located near the assembly station. During the study, in different setups (more details in Section 2.3.3), too few screws are deliberately provided in the material supply at the assembly station in order to simulate a delay in the assembly process. The required time to retrieve screws from the warehouse is 30 s on average.

To address the potentials of assembly in human–robot collaboration, a component was designed for the study implementation whose assembly precedence graph has several process steps that can be executed in parallel. The component consists of two plates on which differently shaped and colored blocks are placed. The mounting of blocks on the plates is achieved by means of screw or magnetic connections (see Figure 13a). The plates preassembled with the blocks are then placed on top of each other and the correct fit is checked by visual inspection. A total of three components are available for the study, so that the degrees of freedom with regard to parallelism of the overall task can be adapted by simultaneously assembling multiple components. Figure 13b shows the three assembled components side by side; the assembly precedence graph for each component is shown in Figure 13c. The assembly of a single component comprises 16 process steps (pick-and-place tasks are counted as one task; the screwing tasks for the gray cuboid comprise bolting of two screws). With parallel assembly of three components, the total process therefore comprises 48 process steps.

The setup of the study’s assembly processes with the developed system follows the implementation and planning process shown in Figure 4. First, the input data are collected. In addition to the assembly precedence graph explained above, the required assembly times for each process step were estimated. Human process times were measured by observing the average process time for manual assembly execution of the first three authors of this paper. The assembly times of the robot for performing each sub-process were recorded. It is noteworthy that the human has to walk around the assembly station for executing the assembly steps for the top plate, which results in significantly faster execution times by the robot for these process steps. Additionally, the individual process steps were classified with respect to their executability by humans or robots. The classification of the assembly process steps is based on the criteria catalog proposed in [51]. Due to the relatively low automation complexity of the pick-and-place tasks (picking of rigid components in an ordered material supply as well as joining with tolerance requirements > 1 mm), these tasks were all classified as suitable for both robots and humans. As the robot is solely equipped with a two-finger gripper without the possibility of hardware reconfiguration, screwing tasks were classified as only executable by human workers. The same applies to the inspection process step, as the robot is not equipped with a vision system for optical inspection.

Next, we created the sub-processes with the respective task sequences for the human and the robot (cf. Figure 8). For the robot tasks, the required waypoints to pick-and-place each block and each top plate onto the bottom plate were taught by guiding the robot in free drive mode physically into the desired position. Then, a name was defined, and the waypoint was saved in the robot system dashboard of the ComFlow process flow editor.

After all HRC sub-process nodes were created, the assembly processes for one component, three components, and for the different task allocation modes, respectively, to be investigated in the study were created and saved (see, e.g., Figure 10 for the created assembly process of one component in dynamic task allocation mode). We defined the following four different task allocation modes that are investigated in the study:

• Manual assembly
  Execution of the assembly process exclusively by humans. For this purpose, all HRC process nodes are classified as “human” and thus the corresponding worker assembly instructions are displayed on the screen for all steps.
• Collaborative assembly—static task allocation with asymmetric planning
  Execution of the assembly in human–robot collaboration, with an intuitive distribution of the tasks between the resources. Here, the human takes over all assembly operations of the bottom plate and the robot executes all assembly operations of the top plate. Since the bottom plate requires additional screwing tasks, parallel sequences of different lengths are created, which is why the mode is referred to as static-asymmetric in the following for simplicity. The individual HRC nodes of the assembly process are each classified as either human or robot during process creation to allow no flexibility in task assignment. Additionally, the order in which the tasks are performed is fixed.
• Collaborative assembly—static task allocation with time-optimized planning and iterative, experimental fine-tuning
  Execution of assembly in human–robot collaboration, with planning of task assignment based on the estimated task times, followed by testing and experimental fine tuning of the order of the sub-processes by the first three authors. Here, the robot additionally takes over the placement of the blocks on the right bottom plate, thus the estimated times of the parallel assembly sequences are harmonized. This task allocation mode requires a higher planning effort and is called static in the following.
• Collaborative assembly—dynamic task allocation
  Execution of the assembly in human–robot collaboration, where the task allocation decision is made dynamically according to the approach for dynamic task allocation described in Section 2.2.2. The sub-processes, which can be executed in any order, are therefore not defined with a fixed sequence, but are created in parallel in accordance with the assembly precedence graph in Figure 13c. The decision about the task sequence, i.e., the selection of the sub-process to be executed next in each case, is therefore also made automatically following the logic of the explained dynamic task allocation approach. However, we set a priority P of one to three for the bottom plate preassembly tasks so that the algorithm prefers to assemble the bottom plates from left to right. The classification of the individual sub-processes is set according to the information about the executability of the step by the respective resource (human, robot, or human/robot for tasks that can be executed by both resources). The cognitive planning effort in this task allocation mode is therefore quite low, since only the input data need to be entered into the user interface.

A simplified illustration of the resulting task sequences in the different collaborative task allocation modes is shown in Figure 14 for the assembly of three components in parallel.

The manual assembly is used as the baseline mode to evaluate the general benefit of human–robot assembly in the use case scenario and is only performed for the assembly of one component. With the two different static task distributions, an indication of how the dynamic task allocation mode compares to a naïve or an optimized static planning is made possible, especially in light of different execution speeds of different subjects. Due to the longer process length, the difference in task sequence between static mode with naïve, asymmetric planning and static mode with detailed iterative planning is only significant when three components are assembled, which is why this is only examined in the setup with three components.

2.3.2. Metrics and Data Collection

For the evaluation study, the independent and dependent variables were defined as shown in Figure 15. The study aims to examine how the different modes of task allocation explained above affect the various qualitative and quantitative aspects relevant in collaborative assembly. Moreover, the influence of a parallel assembly of multiple components (process flexibility) as well as the influence of process delays are investigated. In addition to these aspects, the proposed overall system is evaluated with respect to usability, trust in robot, information quality, and qualitative feedback.

In accordance with [52], the relevant variables in the context of collaborative human–robot assembly were classified into the aspects of effectiveness, efficiency, and satisfaction listed in ISO 9241-11 [53]. Beyond the variables proposed by [52], we have added a number of metrics for the aspect of efficiency that quantitatively evaluate HRC performance (HRC fluency [54]), as well as various investigated variables with respect to user satisfaction (or human factors, cf. [55]).

Table 2. Overview of investigated variables, utilized metrics, and the approach for data collection.

Evaluation Aspect	Variable	Metrics	Symbol	Data Collection
Effectiveness	Process effectiveness	Task completion rate	$\mathrm{TCR}$	notes during study
		Number of errors	$n_{\mathrm{err}}$	notes during study
Efficiency	Process efficiency	Process time	$t_{\mathrm{process}}$	process data logging
	HRC performance efficiency	Number of human tasks	$n_{\mathrm{H}}$	process data logging
		Number of robot tasks	$n_{\mathrm{R}}$	process data logging
		Human wait time	$t_{\mathrm{H}, \mathrm{wait}}$	process data logging
		Robot wait time	$t_{\mathrm{R},\mathrm{wait}}$	process data logging
		Concurrent activity time	$t_{\mathrm{HR},\mathrm{concurrent}}$	process data logging
User satisfaction (human factors)	Workload	NASA Raw TLX	$\mathrm{RTLX}$	questionnaire
	Fluency and satisfaction	Fluency score	$\mathrm{Fluency}$	questionnaire
		Satisfaction score	$\mathrm{Satisfaction}$	questionnaire
	User preference	Preferred task allocation mode	-	questionnaire
	General system assessment	System usability scale score	$\mathrm{SUS}$	questionnaire
		Trust evaluation score	$\mathrm{Trust}$	questionnaire
		Quality of provided information	$Q_{\mathrm{info}}$	questionnaire
		Qualitative feedback	-	free text input
		Suggestions for improvement	-	free text input

provides an overview of the variables examined with the utilized metrics and the respective approach for data collection.

The required data are collected from three sources: First, notes are taken by the study coordinator regarding successful process completions as well as errors during assembly. Second, the timestamps of the start and end times of all sub-processes including the final assignment to human or robot are saved in an automatically generated process log file. This can be used for detailed process evaluations regarding the analysis of the efficiency aspects. Third, questionnaires with radio buttons and free text input fields are used to investigate the evaluation aspect of user satisfaction.

Two questionnaires were prepared for the metrics to be collected qualitatively by user survey. The first questionnaire contains the dependent variables, which are depending on each task allocation mode (NASA raw TLX [56,57], fluency [54], and satisfaction [58]). The second questionnaire contains the general system evaluation variables (trust [59], usability [60,61], information quality [62,63], preferred task allocation mode, and qualitative feedback as well as demographic information and technical affinity [64]), and is surveyed at the end of the study session. A detailed listing of the questionnaires can be found in Appendix C. The two questionnaires were prepared with Google Forms.

2.3.3. Procedure of User Study

The study was conducted with a total of 20 subjects. The composition of the subjects regarding demographics, background experience, and technical affinity is presented in Section 3. For anonymization purposes, all subjects were assigned with identification numbers (IDs), which are exclusively used during the evaluation. Subsequently, the subjects were randomly divided into four user groups, in which the duration of the process delay differs (no delay, 30, 60, and 90 s delay). Furthermore, the order of the task allocation modes (manual, static-asymmetric, static, and dynamic) was randomly selected for all subjects, whereby care was taken to ensure that each mode came first, second, third, and last, respectively, with equal frequency. This was performed to reduce the influence of learning effects. After an initial pilot test, individual appointments were arranged with all 20 subjects, spread over a period of two weeks. The study was conducted by a study coordinator with the assistance of a supporting person in order to quickly perform disassembly and reset of the initial situation between the individual runs.

The study procedure for all subjects, with a duration of about 1.5 h each, is shown in Figure 16 and described in the following: First, an introduction to the context and the course of the study was given by the study coordinator. Here, it was explicitly pointed out that the study coordinator was not the person responsible for the development of the overall system or the study design to ensure honest and critical feedback from the subjects. In addition, the voluntary nature of participation was emphasized and a consent form for participating in the study was signed by the subject. This was followed by a short familiarization phase with the user interface, in which the main areas for visualization and information provision as well as the button for confirming completed process steps were shown. Moreover, subjects were instructed to carefully follow the assigned tasks and assembly instructions displayed on the screen, and to confirm each task upon completion.

After that, the assembly process was performed in the first task allocation mode according to the random, subject-dependent order. Within each task allocation mode, the assembly was performed first with one and then with three components (in the manual and static-asymmetric mode, only one component and three components, respectively, were assembled). An exemplary illustration of a complete process flow of collaborative assembly execution is shown in Appendix B. By starting the assembly process execution, automatic data logging of the process times and final task assignments takes place. Depending on the duration of the delay, the screws initially available in the assembly station were deliberately too few, so that the subject had to collect the screws needed from the warehouse during the assembly process either once (30 s delay), twice (60 s delay), or twice with an extended pause, instructed by the study coordinator (90 s delay). After completing the assembly runs in the respective mode, the subject was asked to complete the short questionnaire (see Appendix C.1). Meanwhile, the study support person restored the initial state of the experimental setup.

The other three task allocation modes were performed in the same way. In total, six assembly runs were carried out by each subject. After completing all assembly runs, the final questionnaire (see Appendix C.2) was filled out by the subject.

2.3.4. Data Analysis and Evaluation Process

The data analysis and evaluation are composed of two parts. First, the process log files of the assembly execution were evaluated (the raw files can be found in the Supplementary Materials). For this purpose, an evaluation script was implemented in a Jupyter notebook. In addition to the total process time, this script calculates the number of human and robot tasks, the idle time of the human and robot, and the concurrent activity time of the two resources (time during which both the human and the robot perform a task in parallel) based on the individual sub-process timestamps and the information about the final task assignment. Additionally, Jupyter notebook was used to generate the graphs and Gantt charts presented in Section 3. Second, the evaluation of the questionnaire responses was conducted using Microsoft Excel. The individual scores were calculated according to the explanations in Appendix C on the procedure for the respective score assessment.

3. Results

Details on the composition of the 20 subjects participating in the user study in terms of gender, age, education, experience in the field, and technical affinity are shown in

Table 3. Demographic and experience data for the subjects in the user study: (a) gender information; (b) age information; (c) vocational education information; (d) previous experience in manual assembly, use of assistance systems in industrial contexts, and programming or working with collaborative robots; (e) technical affinity information.

(a) Gender		(b) Age		(c) Vocational Education		(d) Experience		(e) Technical Affinity
F	25%	20–24	40%	Academic	50%	Assembly	60% 1	ATI score
M	75%	25–29	40%	Undergraduate	50%	Assistance systems	40% 1	4.74 ± 0.68
N/D	−/−	30–34	10%			Collaborative robots	25% 1
		35–49	10%

¹ Subjects with response of 4 or higher on 5-level Likert scale.

. The subjects, who were unfamiliar with the system, are composed of academics and undergraduates. They have a rather high technical affinity, and more than half have prior experience in the field of assembly.

The results of the investigated variables in the study are reported in the following sections, presented in the order of the evaluation aspects as listed in Table 2.

3.1. Effectiveness

All subjects were able to successfully complete all assembly runs of the study (process completed and components correctly assembled), i.e., $\mathrm{TCR}=100\%$.

During the assembly process, however, some of the subjects made mistakes (hereafter referred to as errors) that were either corrected immediately (e.g., picking up the wrong part) or were not relevant to the successful completion of the assembly (e.g., joining and screwing were performed in immediate succession, without confirmation in between). We categorized the errors into three types—picking errors (e.g., wrong part gripped), assembly errors (e.g., wrong task performed), and operator interaction errors (e.g., forgotten confirmation).

During the total of 120 runs, a total of 36 errors occurred, which were composed as follows: $n_{{\mathrm{err}}_{\mathrm{picking}}}=10$; $n_{{\mathrm{err}}_{\mathrm{assembly}}}=14$; and $n_{{\mathrm{err}}_{\mathrm{confirmation}}}=12$. The errors made by the individual subjects mainly occurred in the first two runs of the study, which can be explained by learning effects. Other errors are evenly distributed across the runs and subject groups, implying that neither the task allocation mode nor the duration of delays have a significant effect on the number of errors. Most errors resulted from inattentive observance of the assembly instructions. As all errors were either uncritical for a successful component assembly or were noticed and corrected by the subject itself, they had no effect on the $\mathrm{TCR}$. However, they do have relevance against the background of quality assurance.

3.2. Efficiency

For a better understanding of the following analysis results regarding the evaluation aspect of efficiency and to illustrate exemplary process flows, Figure 17 shows the Gantt charts for the assembly of one component and three components, respectively, in the different task allocation modes of the study for an exemplary subject. Delays of sub-processes due to the necessity to collect screws from the warehouse for further assembly execution are shown hatched.

3.2.1. Assembly Process Time

An overview of the resulting mean assembly process times for the different task allocation modes is given in

Table 4. Overview of mean process times per task allocation mode and duration of the delay. The task allocation mode with minimum process time is highlighted in bold for each setting.

		Process Time in s
Task Allocation Mode	Components	Delay = 0 s	Delay = 30 s	Delay = 60 s	Delay = 90 s
Manual	1	192.6 ± 55.4	254.0 ± 6.7	251.4 ± 49.2	279.6 ± 50.2
Static		153.0 ± 7.3	183.2 ± 31.0	209.6 ± 9.9	233.6 ± 17.4
Dynamic		152.0 ± 37.7	191.0 ± 18.6	208.2 ± 3.5	241.6 ± 24.8
Static (asymmetric)	3	431.6 ± 78.1	442.8 ± 73.5	477.0 ±55.5	510.8 ± 60.6
Static		452.8 ± 108.6	484.0 ± 72.7	427.6 ± 25.9	467.2 ± 63.5
Dynamic		363.4 ± 69.0	422.2 ± 57.5	410.6 ± 28.8	447.6 ± 35.6

, clustered by the number of components and the duration of the delay.

As follows the assembly process times for one component from Table 4, the execution of the assembly in human–robot collaboration reduces the cycle time in the user study by 19.2% in dynamic mode and 20.4% in static mode compared to manual assembly. For the assembly of one component, the assembly process times for the static and dynamic task allocation mode are similar.

The potentials of dynamic task allocation only take effect when the degree of parallelism of the overall process is higher, i.e., when three components were assembled in the study. The process time decreases by 10.2% on average compared to static task allocation with optimized planning and by 11.7% on average in comparison to static-asymmetric task allocation (i.e., with an intuitive, simple planning of the task assignment), when using dynamic task allocation. This relationship also becomes evident from the graphical illustration in Figure 18.

The effects of the duration of delays in the different task allocation modes are shown in Figure 19 for the assembly of three components. In general, the total process time increases with increasing delay duration in all modes. The delay was set at the beginning of the parallel sequences of the total process in all runs (cf. Figure 17). Due to the limited number of subjects per delay group, however, no reliable statement can be drawn here about the ability of the different task allocation modes to compensate for delays in terms of cycle time, and thus remains a subject for future research.

3.2.2. Quantitative Assessment of HRC Performance and Fluency

Figure 20 shows the results of the quantitative analysis of the key performance indicators (KPI) for HRC performance and HRC fluency (number of human and robot tasks, human and robot idle time, and concurrent activity time) for the different task allocation modes, depending on the duration of the process delay.

Considering the number of tasks allocated to the human and to the robot, it is evident that in both static task allocation modes—due to their static nature—the number of tasks remains constant regardless of the duration of delays. In the dynamic mode, a reduction in the human tasks in favor of the robot can be observed with increasing delay time of the human tasks. Compared to static task allocation, this results in lower waiting times of both resources as well as in a higher concurrent activity time, which even increases with longer delays. On the one hand, this validates the functionality of the proposed dynamic task allocation approach. On the other hand, as all variables relevant for HRC fluency achieve better results, a quantitatively better HRC fluency of the dynamic task allocation mode, compared to the two static task allocation modes, can be concluded.

3.3. Human Factors and User Satisfaction

The evaluation of the data collected by means of questionnaires is presented in this section—first for the metrics depending on the task allocation mode (Section 3.3.1), followed by the metrics for evaluating the developed system itself (Section 3.3.2).

3.3.1. Variables Depending on Task Allocation Mode

An overview of the results for workload, fluency, and satisfaction is shown in

Table 5. Assessment results for workload, fluency, and satisfaction for the different task allocation modes.

Data	Manual	Static (Asymmetric)	Static	Dynamic
NASA RTLX score − (adjective rating)	17.7 ± 7.1 (medium workload)	12.5 ± 2.6 (medium workload)	11.3 ± 4.1 (medium workload)	18.5 ± 7.6 (medium workload)
Fluency score +	-	3.5 ± 0.9 1,2	3.5 ± 0.8 1,2	3.7 ± 0.8 1,2
Satisfaction score +	-	3.6 ± 0.6 1	3.9 ± 0.4 1	4.4 ± 0.2 1

¹ Mean response on 5-level Likert scale. ² The point value of questions with a reversed scale was reversed for uniformity and consistency of the score. ⁺ Higher value indicates better score. ⁻ Lower value indicates better score.

for the different task allocation modes. Regarding the workload, the interpretation of the RTLX score shows a medium-level workload (see [65] for summary on interpretation of the NASA TLX score) perceived by the subjects in all setups. In both static task allocation modes, the workload is lower than in manual task allocation and dynamic task allocation modes. An examination of the answers to the individual questions shows that this is mainly due to the higher mental workload in both cases, due to the higher pace of the task in the case of dynamic task allocation, and due to the need for harder work to accomplish performance in the case of manual assembly.

The subjective evaluation of HRC fluency shows almost identical fluency in both static task allocation modes, while in the dynamic task allocation mode, fluency was reported to be slightly better (cf. Table 5). When analyzing the feedback in detail (see Figure 21a), the intelligence of the robot, the perception of the robot as a team partner, and the flexible reaction to process changes are rated significantly better in the dynamic task allocation mode. However, the need of the human to adapt their own movements to the robot is rated worse in dynamic task allocation. This can be explained by the less clearly defined sequence of robotic tasks resulting in less predictable robot movements.

The satisfaction assessment reveals a significantly higher satisfaction score in the implemented approach for dynamic task allocation, where in particular the satisfaction with the resulting task assignment is markedly perceived best (cf. Figure 21b).

Figure 22 shows the subjective user preference regarding the preferred mode of task allocation. A clear preference for the dynamic task allocation can be observed, which is judged as the preferred mode by 75% of the subjects.

3.3.2. General Assessment of the System

In

Table 6. General system assessment: (a) system usability; (b) quality of provided information; (c) subjects’ readiness for permanent system usage; (d) trust in robot.

(a) Usability		(b) Quality of Provided Information		(c) Permanent Use of System 2		(d) Trust
SUS score	79.4 ± 12.5	Correctness and completeness	4.5 ± 0.9 1	Yes	85 %	Trust score	43.3 ± 4.1
Acceptability rating	Acceptable	Relevance and timing	4.25 ± 0.8 1	No	5 %
Adjective rating	Good	Understandability and comprehensibility	4.2 ± 1.0 1	Not sure	10 %
		Easy and quick information extraction	3.5 ± 1.3 1

¹ Mean response on 5-level Likert scale. ² Subjects’ response to question “Would you use the system permanently?”.

, an overview of the resulting scores measured for general system assessment, i.e., system usability, information quality, trust in robot, and the subjects’ feedback about their willingness for permanent usage of the system for collaborative assembly are given.

The developed system achieves an SUS score of 79.4, which is interpreted as a grade A⁻, i.e., a good system usability (see [61]). The quality of provided information achieves high feedback in terms of accuracy, relevancy, and representation. Despite an acceptable score, needs for improvement were identified in the ease of information extraction. This was also mentioned by some subjects in the suggestions for improvement.

In terms of trust in the robot, a high score of 43.3 was achieved. According to [59], this is an almost optimal trust result, as the score is high, but not too close to the maximum value of 50, which would indicate that the subjects are overly relying on the robot, potentially leading to complacency.

Finally, this positive overall assessment of the developed system was further confirmed by the statement of 85% of the subjects who can envision a permanent use of the system for collaborative assembly, indicating a good system acceptance.

4. Discussion

The conducted user study demonstrated the potentials of HRC for assembly processes that allow a certain degree of parallelism in the execution of sub-processes. Within the study, we found a reduction in cycle time of approximately 20% compared to manual assembly. This is relatively consistent with the results of [38], who reported a reduction in cycle time of approximately 25% for a similar amount of process steps (16 tasks in [38]; 14 tasks in conducted study for assembly of one component). Another interesting finding is that dynamic task allocation can only exploit its potential at a certain degree of parallelism (process flexibility) in the assembly process to outperform static task allocation. Assembly processes that do not have these degrees of flexibility may be adapted through the parallel assembly of a higher number of components. This also avoids the reported problem of operators having to adjust their movements, as the resources can perform their respective tasks in parallel on several components, which in turn reduces cycle time by reducing waiting times.

Both the quantitative and qualitative results of the study further indicate a better fluency of the HRC assembly when using dynamic task allocation. In particular, in the event of delays during the process execution of one resource, the other resource is not forced to wait, but can instead continue with the execution of remaining unfinished tasks. This is especially reflected in a significantly higher concurrent activity time in dynamic task allocation compared to static task allocation. This characteristic also enables dynamic task allocation—for processes with a correspondingly large number of sub-processes that can be executed by both humans and robots—to flexibly adapt to the individual worker, independent of its task execution performance, without the need for specific planning or programming. Consequently, even performance fluctuations during the day can be compensated.

Furthermore, some subjects also commented that they were stressed if the robot had to wait for them, which underlines the importance of a high concurrent activity time and a low robot wait time.

In terms of quantitative analysis, there remains a need for research to investigate how exactly delays in the process can be absorbed by each task allocation mode. A study specifically designed for this purpose should be conducted as future research, which systematically takes into account different time points of interruption during the process with a large number of subjects and even considers longer durations of delay than 90 s.

A reduction in the planning effort can generally be noted when using dynamic task allocation with the presented system. For realizing assembly processes in this task allocation mode with the proposed software framework, only a transfer of basic input information (process times, assembly priority graph, and task classification regarding the feasibility for execution by humans or robots) is required, which is typically available or would also have to be collected as a first step in static planning. Compared to static task allocation, neither detailed prior process scheduling nor an experimental fine-tuning of the planned processes are required.

With regard to the repeatability of the conducted study, identical conditions can be maintained with respect to the experimental setup and study procedure. Due to the characteristics of a user study, the individual absolute execution times and answers to the questionnaires depend on the respective performance of each subject, or their current daily form. Nevertheless, considering the number of subjects, it can be assumed that the core results found would remain the same overall if the experiment were repeated.

Limitations of the study particularly include the influence of learning effects, which will have occurred within the study despite randomized selection of the execution order of task allocation modes in the individual runs. Further, the study was conducted with users with an academic background who, despite their prior experience, should rather be considered as novice workers in assembly. Thus, performance and subjective perception from expert users working in industrial assembly might differ. Moreover, due to the comparatively simple assembly component, occurring worker errors did not affect the overall task completion rate. Therefore, we propose to conduct a separate study on the assembly of many components one after another over a longer period to investigate if the greater variance in task execution under dynamic task allocation affects the number of worker errors.

In the conducted study, some subjects already mentioned less monotonous work in the dynamic task allocation mode. With the abovementioned long-term study, a more profound evaluation of the effects of different task allocation modes on the monotony of assembly work over a longer period of time would be possible.

From the results of the general investigation of the developed block-based HRC task allocation system, a positive assessment can be derived. However, various suggestions for improvement were provided by the subjects: Regarding the interaction modality, some subjects suggested an acoustic signal when assigning a new task to the human. In addition, a more intuitive form of visualization of the assembly instructions, e.g., by projection directly onto the worktop, was proposed. Furthermore, an automatic, camera-based recognition of completed steps was mentioned as desirable. In terms of collaboration with the robot, the ability of the robot to dynamically avoid crossing trajectories on the one hand and the projection of the robot’s planned trajectories into the workspace on the other hand were suggested.

Additional potential for further development of the presented overall system for dynamic task allocation arises with regard to the observability and stability in the event of robot malfunctions. The state transition in a function block from “in execution” to “completed” is to be regarded as a black box during execution. Only as soon as the human confirms the successful completion or the robot reports the task-completed state, the state transition to “completed” occurs. In this way, the overall assembly process is controlled by means of the created process graph in combination with the task allocation decision methodology as well as the operator feedback inputs, or robot state messages. Dynamics that arise within the function blocks during execution are not explicitly considered. Some of these dynamics, such as interfering trajectories of humans and robots, often result in delays of the respective function block and are therefore implicitly taken into account by the dynamic task allocation approach when assigning the next tasks. However, limitations arise in certain situations: In the implemented algorithm, currently, no handling of error states within the individual function blocks is taken into account, i.e., if the robot fails during a task execution, the function block cannot transition to the completed state, so that the overall assembly process does not terminate. The same applies to human process execution: Here, the correct confirmation of all executed process steps is relied on. Incorrect confirmations or execution of other process steps than assigned lead to incorrect assumptions of the system about the progress and the state of the overall process, resulting in the inability to assign the correct next process steps. Continuous observation of the process execution by means of a camera system in combination with appropriate algorithms for activity recognition and progress monitoring could enable the observability within the function blocks. This would allow an early reaction to emerging problems and therefore offers potential for further research activities. In this context, another planned enhancement for the system is to implement a dedicated error handling output for each function block. This output is intended to be activated only in the event of an error during the function block execution (in the simplest case, e.g., via an adjustable timeout value per function block) and then trigger correspondingly connected subsequent functions in reaction to the error.

Regarding the choice between manual assembly and collaborative assembly with static or dynamic task allocation, the following can be stated as a rough indication from a process perspective: In strictly sequential assembly processes, where there is also no possibility or intention for parallelization, manual assembly is often the most suitable. With increasing parallelism, e.g., through preassembly of sub-assemblies, and increasing degrees of freedom in the process, either static task assignment or, in the case of large degrees of process flexibility, dynamic task allocation should be preferred. The latter is also recommended with regard to higher HRC fluency, especially if process delays are expected to occur regularly during assembly.

5. Conclusions

This article presented an approach for dynamic task allocation and its implementation into a block-based software framework for integrated process creation and execution. By combining intuitive block-based programming with the proposed dynamic task allocation approach, which requires only basic information input, we facilitate both the creation and planning of dynamic HRC processes as well as their adaptation to different use-cases. The proposed dynamic task allocation approach is evaluated in an extensive user study and compared to manual assembly as well as collaborative assembly with static task allocation. With the design of the evaluation study, we suggest a comprehensive systematic framework for evaluation of HRC assembly processes. The user study resulted in new insights for collaborative robotics concerning the potentials of dynamic task allocation. For one thing, dynamic task allocation reduces the overall cycle time compared to both manual assembly and static task allocation, given a high degree of parallelism in the assembly processes. For another, it increases HRC fluency in general and, in particular, in the event of deviations or delays during the assembly process.

In our future research, we aim to further assist both the planner and the operator by implementing an automatic import function for the planner that creates the dynamic HRC process based on the process input data to further simplify and quicken the process creation. For improved support of the operator, we focus on the implementation of the suggestions for system improvement obtained in the user study.

Further research needs are a long-term study of dynamic task allocation over multiple weeks with expert workers in real industrial environments, the investigation of the influence of different time points of process delays, and the analysis of errors in different task allocation modes for complex industrial components.