Α Behavior Trees-based architecture towards operation planning in hybrid manufacturing

ABSTRACT

In modern manufacturing, the capability of process scheduling and task allocation is a major feature for the proper organization of complex production schedules. More particularly, the case of human-robot collaboration within assembly lines is considered as a quite challenging field, where an efficient process scheduling can reduce products’ delivery times, increasing in parallel its quality. The purpose of this paper is to propose an approach focusing on operation planning for Human-Robot Collaborative processes that consist of many tasks and multiple resources, such as the assembly of large-scale parts. The implementation of the Human-Robot Operation Planning (HROP) module is presented, which aim at the allocation of multiple operations between multiple and different types of resources. This development’s main pillar is a dynamic decision-making logic that combines both constraints, that exclude resources from the evaluation, as well as mathematical criteria, that provide finally a specific solution. The HROP particularity is that it is developed under the Behavior Trees (BT) architecture. For the validation of the proposed approach, a case study under a real industrial environment of the automotive industry is presented, based on the assembly of large-scale parts, such as buses, in a hybrid cell of both human operators and multi-type robots.

KEYWORDS:

• Human-Robot Operation Planning
• decision-making logic
• constraints and criteria
• Behavior Trees architecture

1. Introduction

The last trend in nowadays’ industry expresses an attempt to achieve high product customization by implementing flexibility and high reconfigurability. The smart factory represents a leap forward from more traditional automation to a fully connected and flexible system. In this direction, the integration of new technological systems can help to decrease product defects and the cost of reworking (Chryssolouris 2006). Whereas manufacturing systems are already mechanically assisted, semi- or even fully automated to a large extent, assembly process areas generally remain permeated by manual operations (Spena et al. 2016). The reason for this can be presumed in the fact that in assembly systems, the variant configuration takes place often and, therefore, work contents vary more frequently, showing a higher degree of flexibility (Takata and Hirano 2011).

In an attempt to deal with the requirements, being emerged during flexible assembly systems, in terms of combining automation and adaptation to changes in products and processes, production and academy have turned to the concept of Human-Robot Collaboration (HRC) in common workflows (Bouzakis, Konstantinos-dionysios 2014). The collaboration of humans and robots has been the topic of many studies, indicatively for the assembly in automotive industries, encountering several challenges through the improvisation of human operators (Tsarouchi, Makris, and Chryssolouris 2016a). Rather than removing humans from manufacturing, collaboration involves robots supporting humans, increasing at the same time the flexibility of collaborative layouts (Makris 2021; Thoben, Alexander Wiesner, and Wuest 2017). Traditional robots typically work in a separate space, while collaborative robots can work in the same space as humans, providing the capability of handling both small and large-scale parts (Arkouli et al. 2021; Chen et al. 2018). Nevertheless, fenceless and seamless coexistence creates the need of developing design tools and planning systems, while incorporating safety-induced restrictions for human workers, and efficiently taking into consideration their effect on the manufacturing processes of real industrial environments (Michalos et al., Seamless human robot collaborative assembly – An automotive case study, 2018).

With human-robot collaboration, companies are struggling to decide how to schedule tasks effectively, mainly due to the parameters which arise from this collaboration, such as production rate and efficiency, humans ergonomic issues, etc. By task scheduling, it is meant a combination of task allocation and task sequencing (Weßkamp et al. 2019). A scheduling system can be of great importance, providing an efficient adaptive and anticipatory fluency of action in human-robot teamwork, in terms of selecting the proper operations sequence and allocation to resources (Hoffman and Breazeal 2007). Up to now, research has been done on multi-criteria planning and the assignment of operations to production resources, either in automated manufacturing plants or in human-based production systems (Chryssolouris and Subramaniam 2001). It is widely accepted that through efficient task analysis and human-robot collaborative planning, assembly time and costs can be reduced in any type of system (Tan et al. 2010). However, it remains a challenge to handle the problem of responding to unexpected events during collaborative process execution, suggests a specific alternative of resources, and re-schedule the operations based on this suggestion.

The innovative contribution of this study is summarized as follows. The concurrent investigation and analysis of multiple and complex operations, as well as the taxonomy of resources co-existing in a flexible human-robot collaborative layout, are the two main pillars. For this taxonomy, constraints, such as resource availability, suitability, and human safety, as well as multiple criteria, such as time of task execution, labor cost, and human ergonomics, are evaluated. All these are combined for the creation of a model capable of assigning specific assembly operations to the most appropriate resource. Last but not least, the implementation of the proposed decision-making logic in a real industrial environment, such as the assembly of buses, under a module namely Human-Robot Operation Planning (HROP), will be the main purpose of the investigation. Through this case, a large-scale part is studied, where the process takes place in wide areas of many sub-assemblies and the module has to manage numerous complex tasks. In addition, the proposed model will be responsible to handle the integration of multi-type and multi-purpose robots, which may or not cooperate with humans or each other to deal with the requirements emerging in such a case, which will be further described in sections below. To achieve all these in a more scalable and modular way, the implementation of this approach under the Behavior Trees (BTs) architecture is proposed.

Briefly, this manuscript is structured as follows. In section 2 the relevant to the manuscript’s topic work that has been conducted, is presented. Section 3 describes the innovative proposed method for operation planning toward a human-robot collaborative layout and its main pillars. A case study from the automotive industry for the proposed model is presented in section 4. Section 5 analyses the tools to be used under this approach for its implementation, while in Section 6 the results of this implementation are presented. Finally, the authors present the study’s conclusions and their future actions in section 7.

2. Relevant work

In the following paragraphs, relevant work on planning systems for both robotic and human-robot collaborative cells is presented. Most of the decision-making methodologies that have been investigated, use multiple criteria, such as process execution time, technical capabilities of the robotic manipulators or human safety and ergonomic aspects, etc., in order to achieve an effective task allocation. A classification based on these criteria that they use for the planning will also take place. The variability of the criteria used in such a system can lead to a more efficient task allocation, mainly when they combined with the benefits that a digital twin can offer (Andronas, Kokotinis, and Makris 2020), by providing improved productivity, in terms of efficient use of machines, tooling, material and labor, consistent creation and application of process plans, as well as time and mental effort savings. Such criteria will also be used in this paper’s proposed approach to achieve task allocation and resource assignment.

There are several pieces of research in the literature dealing with the task allocation problem in robotic cells. An assembly paradigm that uses multi-purpose, industrial mobile robots capable of replacing any resource in an assembly line is presented by (Michalos et al. 2016). The system is supplemented with exchangeable grippers that allow the random routing of parts, as well as a coordination logic that allows the resources to generate and implement reconfiguration alternatives. Kousi et al. proposed a service-oriented architecture that would enable the dynamic scheduling of material supply operations in an assembly system of the automotive industry using Mobile Assistant Units (MAUs) (Kousi et al., Service oriented architecture for dynamic scheduling of mobile robots for material supply, 2016; Kousi et al., Short-term planning for part supply in assembly lines using mobile robots, 2016). This approach has been focused on the capability of MAUs for the transportation of boxes of consumables, and the resources’ selection was based on the transportation time and the reduction of traveling distance. The design and configuration of a real automotive assembly line of an under-body structure, consisting of various sub-assemblies, has been presented by (Michalos et al. 2015). In this research, multiple-user-defined criteria have been used related to the suitability of the resources, under technical aspects, their availability, as well as the investment cost and total energy consumption parameters. Another study has shown three different approaches to solving real industrial problems; Mathematical Programming (Linear Program), Industrial Practice (ERP – Enterprise Resource Planning), and a Manager Expertise approach, translated into heuristic rules (Carvalho, Fabius, and Rosana Beatriz 2012). Mathematical Program results have given a ‘near optimum’ value since calculations are made based on estimated set-up times aggregated to the processing times, while a better representation of set-up times has been reached through the MRP (Manufacturing Resource Planning) module.

For Human-Robot Collaborative (HRC) applications, workflow and planning systems have been deployed, being able to dispatch and monitor tasks between operators and robots and ensuring smooth process execution on dynamic events. Nevertheless, in HRC cells the problem of assigning tasks to the resources is quite complex, mainly in cases that involve multiple human operators and/or robots. One of the main parameters that a decision-making logic examines during a task assignment is the capability of the resources to deal with a specific process in technical aspects, such as payload (Nikolakis et al. 2018) or reachability (Tsarouchi et al. 2016). In (Tsarouchi et al. 2017) an intelligent decision-making algorithm has been studied, allowing human-to-robot and robot-to-robot task allocation and cooperation in the same workspace. Mean flowtime and average resource utilization per task are the main criteria studied for generating alternatives. Kim et al. in (Yongho and Matson 2016) proposed a CPU scheduling-based algorithm to allow agents (humans, robots, and software agents) to perform rational decisions for the organization, using both technical and average resource utilization parameters. Tsarouchi (Tsarouchi, Makris, and Chryssolouris 2016b) showed a method for task planning in a hybrid assembly cell of the automotive industry, which includes both humans and robots (single and dual-arm) as cell resources, that results in a decrease in human participation and an increase of the dual arm use. This decision-making framework allowed for the human-robot task planning to be done in a short time and can be also used for re-planning. Another research has presented Human-Aware Task Planner (HATP) as a component of an architecture based on a Hierarchical Task Network (HTN) refinement, which performs an iterative task de-composition into sub-tasks until reaching atomic actions (Fiore, Clodic, and Alami 2014). This module is able to produce plans for the various participants, humans or robots, depending on their capabilities and their availability in the proposed cell of the furniture industry.

HRC workplace generation and task allocation focusing on ergonomics and safety aspects provide certain advantages such as the generalized unified model for active and passive resources, including both humans and robots, as well as working tables, fixtures, etc (Tsarouchi et al. 2016). Reduction of the traveling distance on human-robot collaborative cells is also an important aspect under the ergonomic criterion, mainly for humans (Conti, Varde, and Wang 2020). A method has been proposed for a virtual assembly cell, where a human operator and a dual-arm robot share assembly tasks and workspaces, focusing on human safety (Kousi et al. 2020; Tsarouchi et al. 2015). This method’s framework consists of an offline programming tool that exports data in a neutral XML format, allowing to use of the exported data without translating them into the robot controller programming language. Raatz et al. proposed a two-staged decision-making process aiming to achieve a desired capability-based task allocation that supports job satisfaction, considering both sensory and motoric strengths and ergonomic limitations of the human (Raatz et al. 2020). In (Evangelou et al. 2021) a human-centered approach is presented responsible for scheduling and assignment of assembly tasks to both humans and robots, including manufacturing throughput metrics, human RULA-based ergonomics (Michalos et al., Workplace analysis and design using virtual reality techniques, 2018), and safety distance. Anticipatory planning for human-robot teams has been implemented for enabling robots to work alongside humans in contextually rich environments to accomplish complex tasks (Koppula, Jain, and Saxena 2016). In this work, collaborative models have been used, following human habits and adapting robot policies based on the operations that can be performed by humans. Nikolakis et al. presented a method for scheduling shared human-robot tasks supporting online re-scheduling for unexpected situations and involving humans, robots, and/or human-robot teams (Nikolakis et al. 2018). In (Michalos et al., A method for planning human robot shared tasks, 2018), the determination of a solution to the planning of human-robot shared tasks has been conducted, proposing an innovative method that addresses both the layout and the task assignment problems, under a common search problem. Recently, an approach to determine task allocation by considering the actual capabilities of both humans and robots in order to improve work quality has been proposed (Ranz, Hummel, and Sihn 2017). It is based on a subsequent generic description of human and robotic capabilities, as well as a heuristic procedure that facilitates the decision-making process.

In addition to all the above, terms such as multiplicity of the resources and their role in a manufacturing system are introduced. In literature, common resources are distinguished between single, multiple, and/or team, the latter being a group acting co-ordinately and at the same time, and interacting with the environment and other resources in a specified way (Wang et al. 2017). Moreover, the role of the resources in a collaborative layout may not be the same. Most of the time, an agent in a system seems to be a human or a robot that executes a process (Kardos, Kovács, and Váncza 2016). However, a working environment also includes resources that are needed for production but do not take an active role, but they support another one for a specific task, as well as artifacts or resources with a passive role (e.g. stationary structures, tables, etc.) affecting viable solutions.

A brief classification of the aforementioned studies based on some characteristics of the resources in the workspace of each study, as well as the proposed metrics for assigning tasks to these resources, are provided. More specifically, the rows show a division of the various metrics that have been taken into consideration for the task allocation systems of the presented studies into constraints (Table 1) and criteria (Table 2) that will be also used by the proposed model of this manuscript. As for the columns, the type of cell is identified (HRC or robotic), and the role of the resources in the examined case studies (active or passive), as well as if the existence of passive equipment (tables, etc.) has been taken into account.

Table 1. Classification of relevant work based on the case study specifications and on the resources’ constraints.

Evaluation metrics		Resources’ profile in the layout
		Type			Role		Multiplicity
		Human		Robot/Machine	Active	Passive	Single	Multiple	Team
Constraints	Availability	(Nikolakis et al. 2018) (Tsarouchi et al. 2017), (Fiore, Clodic, and Alami 2014), (Nikolakis et al. 2018) (Michalos et al. 2018),		(Michalos et al. 2016) (Michalos et al. 2015), (Carvalho, Fabius, and Rosana Beatriz 2012 (Nikolakis et al. 2018), (Tsarouchi et al. 2017) (Fiore, Clodic, and Alami 2014), (Nikolakis et al. 2018) (Michalos et al. 2018),	(Michalos et al. 2016) (Michalos et al. 2015), (Nikolakis et al. 2018), (Tsarouchi et al. 2017) (Fiore, Clodic, and Alami 2014), (Nikolakis et al. 2018) (Michalos et al. 2018),	(Michalos et al. 2016)	(Michalos et al. 2016) (Nikolakis et al. 2018), (Tsarouchi et al. 2017) (Fiore, Clodic, and Alami 2014), (Nikolakis et al. 2018) (Michalos et al. 2018),	(Michalos et al. 2015), (De Carvalho, Fabius, and Rosana Beatriz 2012) (Nikolakis et al. 2018),	(Michalos et al. 2016) (Michalos et al. 2015), (Tsarouchi et al. 2017) (Nikolakis et al. 2018),
	Suitability(Technical aspects)	(Nikolakis et al. 2018) (Tsarouchi et al. 2016), (Tsarouchi et al. 2017) (Yongho and Matson 2016), (Tsarouchi, Makris, and Chryssolouris 2016b) (Fiore, Clodic, and Alami 2014), (Kousi et al. 2020) (Raatz et al. 2020), (Nikolakis et al. 2018), (Michalos et al. 2018) (Wang et al. 2017),	(Michalos et al. 2016) (Kousi et al. 2016), (Kousi et al. 2016) (Michalos et al. 2015), (Carvalho, Fabius, and Rosana Beatriz 2012) (Nikolakis et al. 2018), (Tsarouchi et al. 2016) (Tsarouchi et al. 2017), (Kim and Matson Tsarouchi et al. 2016) (Tsarouchi, Makris, and Chryssolouris 2016b), (Fiore, Clodic, and Alami 2014) (Kousi et al. 2020), (Raatz et al. 2020) (Nikolakis et al. 2018), (Michalos et al. 2018) (Wang et al. 2017),		(Michalos et al. 2016) (Kousi et al. 2016), (Kousi et al. 2016) (Michalos et al. 2015), (Carvalho, Fabius, and Rosana Beatriz 2012) (Nikolakis et al. 2018), (Tsarouchi et al. 2016) (Tsarouchi et al. 2017), (Kim and Matson Tsarouchi et al. 2016) (Tsarouchi, Makris, and Chryssolouris 2016b), (Fiore, Clodic, and Alami 2014) (Kousi et al. 2020), (Raatz et al. 2020) (Nikolakis et al. 2018), (Michalos et al. 2018) (Wang et al. 2017),	(Michalos et al. 2016) (Kousi et al. 2016), (Kousi et al. 2016), (Tsarouchi et al., Tsarouchi et al. 2016) (Wang et al. 2017),	(Michalos et al. 2016) (Nikolakis et al. 2018), (Tsarouchi et al. 2016) (Tsarouchi et al. 2017), (Yongho and Matson 2016) (Fiore, Clodic, and Alami 2014), (Kousi et al. 2020) (Raatz et al. 2020), (Nikolakis et al. 2018), (Michalos et al. 2018) (Wang et al. 2017),	(Kousi et al. 2016)(Kousi et al. 2016), (Michalos et al. 2015) (De Carvalho, Fabius, and Rosana Beatriz 2012), (Nikolakis et al. 2018) (Tsarouchi, Makris, and Chryssolouris 2016b), (Kousi et al. 2020), (Nikolakis et al. 2018) (Wang et al. 2017),	(Michalos et al. 2016) (Michalos et al. 2015), (Tsarouchi et al. 2017), (Nikolakis et al. 2018) (Wang et al. 2017),

Table 2. Classification of relevant work based on the case study specifications and on the resources’ assigning criteria.

Evaluation metrics		Resources’ profile in the layout
		Type		Role		Multiplicity
		Human	Robot/Machine	Active	Passive	Single	Multiple	Team
Criteria	Operating Cost Aspect	(Tsarouchi et al. 2016) (Kousi et al. 2020), (Nikolakis et al. 2018) (Michalos et al. 2018),	(Michalos et al. 2015) (De Carvalho, Fabius, and Rosana Beatriz 2012), (Tsarouchi et al. Tsarouchi et al. 2016) (Kousi et al. 2020), (Nikolakis et al. 2018) (Michalos et al. 2018),	(Tsarouchi et al. Tsarouchi et al. 2016) (Kousi et al. 2020), (Nikolakis et al. 2018) (Michalos et al. 2018),	(Tsarouchi et al. Tsarouchi et al. 2016)	(Tsarouchi et al. 2016) (Kousi et al. 2020), (Nikolakis et al. 2018) (Michalos et al. 2018),	(Michalos et al. 2015), (Kousi et al. 2020) (Nikolakis et al. 2018),	(Michalos et al. 2015) (Nikolakis et al. 2018),
	Execution time aspect	(Nikolakis et al. 2018) (Tsarouchi et al. 2017), (Yongho and Matson 2016) (Tsarouchi, Makris, and Chryssolouris 2016b), (Conti, Varde, and Wang 2020) (Kousi et al. 2020), (Raatz et al. 2020) (Evangelou et al. 2021), (Koppula, Jain, and Saxena 2016) (Nikolakis et al. 2018), (Michalos et al. 2018) (Ranz, Hummel, and Sihn 2017), (Wang et al. 2017) (Kardos, Kovács, and Váncza 2016),	(Michalos et al. 2016) (Kousi et al. 2016), (Kousi et al. 2016) (Michalos et al. 2015), (Nikolakis et al. 2018), (Tsarouchi et al. 2016) (Tsarouchi et al. 2017), (Kim and Matson Yongho and Matson 2016) (Tsarouchi, Makris, and Chryssolouris 2016b), (Fiore, Clodic, and Alami 2014) (Conti, Varde, and Wang 2020), (Kousi et al. 2020) (Raatz et al. 2020), (Evangelou et al. 2021) (Koppula, Jain, and Saxena 2016), (Nikolakis et al. 2018) (Ranz, Hummel, and Sihn 2017),,, (Wang et al. 2017) (Kardos, Kovács, and Váncza 2016),	(Michalos et al. 2016) (Kousi et al. 2016), (Kousi et al. 2016) (Michalos et al. 2015), (Nikolakis et al. 2018), (Tsarouchi et al. 2016) (Tsarouchi et al. 2017), (Kim and Matson 2016) (Tsarouchi, Makris, and Chryssolouris 2016b), (Fiore, Clodic, and Alami 2014) (Conti, Varde, and Wang 2020), (Kousi et al. 2020) (Raatz et al. 2020), (Evangelou et al. 2021) (Koppula, Jain, and Saxena 2016), (Nikolakis et al. 2018) (Michalos et al. 2018), (Ranz, Hummel, and Sihn 2017), (Wang et al. 2017) (Kardos, Kovács, and Váncza 2016),	(Michalos et al. 2016) (Kousi et al. 2016), (Kousi et al. 2016) (Wang et al. 2017),	(Michalos et al. 2016) (Nikolakis et al. 2018), (Tsarouchi et al. 2017) (Kim and Matson Yongho and Matson 2016), (Conti, Varde, and Wang 2020) (Kousi et al. 2020), (Raatz et al. 2020) (Evangelou et al. 2021), (Koppula, Jain, and Saxena 2016) (Nikolakis et al. 2018), (Michalos et al. 2018) (Ranz, Hummel, and Sihn 2017), (Wang et al. 2017) (Kardos, Kovács, and Váncza 2016),	(Kousi et al. 2016) (Kousi et al. 2016), (Michalos et al. 2015) (De Carvalho, Fabius, and Rosana Beatriz 2012), (Tsarouchi, Makris, and Chryssolouris 2016b) (Kousi et al. 2020), (Nikolakis et al. 2018) (Wang et al. 2017),	(Michalos et al. 2016) (Michalos et al. 2015), (Tsarouchi et al. 2017), (Nikolakis et al. 2018) (Wang et al. 2017),
	Ergonomics/Human safety	(Tsarouchi et al. 2016) (Conti, Varde, and Wang 2020), (Tsarouchi et al. 2015) (Kousi et al. 2020), (Raatz et al. 2020) (Evangelou et al. 2021), (Koppula, Jain, and Saxena 2016) (Nikolakis et al. 2018), (Michalos et al. 2018), (Ranz, Hummel, and Sihn 2017) (Kardos, Kovács, and Váncza 2016),	(Tsarouchi et al. 2016) (Conti, Varde, and Wang 2020), (Tsarouchi et al. 2015) (Kousi et al. 2020), (Raatz et al. 2020) (Evangelou et al. 2021), (Koppula, Jain, and Saxena 2016) (Nikolakis et al. 2018), (Michalos et al. 2018), (Ranz, Hummel, and Sihn 2017) (Kardos, Kovács, and Váncza 2016),	(Tsarouchi et al. 2016) (Conti, Varde, and Wang 2020), (Tsarouchi et al. 2015) (Kousi et al. 2020), (Raatz et al. 2020) (Evangelou et al. 2021), (Koppula, Jain, and Saxena 2016) (Nikolakis et al. 2018), (Michalos et al. 2018), (Ranz, Hummel, and Sihn 2017) (Kardos, Kovács, and Váncza 2016),	(Tsarouchi et al. 2016)	(Tsarouchi et al. 2016) (Conti, Varde, and Wang 2020), (Tsarouchi et al. 2015) (Kousi et al. 2020), (Raatz et al. 2020) (Evangelou et al. 2021), (Koppula, Jain, and Saxena 2016) (Nikolakis et al. 2018), (Michalos et al. 2018), (Ranz, Hummel, and Sihn 2017) (Kardos, Kovács, and Váncza 2016),	(Kousi et al. 2020) (Nikolakis et al. 2018),	(Tsarouchi et al. 2015) (Nikolakis et al. 2018),

The contribution of the proposed model is to combine some of the aforementioned decision-making metrics, under the concept of flexible assembly of large-scale parts, being able to address cases of complex workspaces. The particularities of large parts, e.g. geometrical complexity, rigidity, weight, and inaccurate processes for each sub-assembly lead to various challenges that need to be met (Z. Arkouli et al. 2021). Such challenges can be the complex process planning and the variable operator’s allocation, the increased demands on product quality and time savings, as well as the seamless human-robot co-existence. The assembly of high customized sophisticated parts often involves product modifications leading to frequent re-scheduling (Estévez, Rodríguez, and Ayesta 2018), needing also strict setup times and high accuracy in each task executed (Rochow et al. 2015). In an effort to address all the potential difficulties and challenges, a methodology will be presented in the next section, for the proper taxonomy of the existing resources in a flexible HRC layout and taking into consideration multiple criteria and constraints for the evaluation of this workplace layout. The integration of multi-type and multi-purpose robots in collaboration with human operators will be investigated. Beyond the state-of-the-art, the innovation of this manuscript is the fact that the proposed model and the whole decision logic will be developed under the architecture of Behavior Trees (BT), which is a powerful tool for task-switching and decision-making that is receiving an increasing amount of attention in robotics. Recent research is beginning to explore areas such as learning (Nicolau et al. 2017), planning (Emily, Best, and Hollinger 2021), and control (Prezas et al. 2022; Ögren and Sprague 2022).

3. Approach and module concept

As it is aforementioned, this paper aims at the dynamic scheduling of human-robot collaborative activities under a shared environment for the complex assembly process of large-scale parts. For this reason, a module will be proposed in this section under the name of Human-Robot Operation Planning (HROP). HROP developing approach consists of the following main pillars:

• A hybrid hierarchical model that combines both a five-level facility hierarchy and a four-level workload analysis, being able to address the task allocation in human-robot collaborative layouts.

• A decision-making logic for the operations to be assigned to specific resources. This framework will combine constraints, that exclude some resources from the calculations, as well as a multi-criteria assessment of the remaining alternatives. Constraints will be based on the availability and suitability of resources, mainly in technical terms, as well as human safety, while the detailed calculations of the examined criteria will focus on time, cost, and ergonomics evaluation.

• The development of the overall model under the Behavior Trees (BT) architecture, providing dynamics to the whole process plan of HRC layouts, in terms of adjusting the planning in real-time based on the users inputs and needs. BTs can facilitate the user for online re-scheduling of the process or task allocation, by adding, removing, and/or updating any operation, based on each job’s specific features. It is also easier to monitor the resources availability, without having to make hard-code changes.

3.1. Hierarchical model

In the proposed approach, a hierarchical representation of production planning is adopted, for both facility and workload, which is presented in Figure 1. The facility model consists of a five-level analysis, while the workload model of a four-level. More particularly at the top of the facility model, the factory takes place. An assembly factory consists of several assembly lines, which have a more specific job to execute. This job is the beginning of the workload model. Subsequently, these assembly lines may include one or more stations, where the abovementioned job is separated into processes of the assembly. When all the processes are completed, then the job is done. Each one of these stations involves a number of available resources, in terms of human workers and/or robots that are registered at the beginning of the timeline. These available resources are responsible for executing more complex activities or tasks, in order to complete a process. In the end, at the bottom level of the described workload model, there is a list of operations that will be assigned to specific resources, based on the results coming from a multi-criteria decision-making logic. Based on this selection, each specific resource has some actions to execute the corresponding operation. HROP module is focusing on the task level and below in the workload hierarchical model, examining the available resources and proposing the more satisfactory one based on the criteria examined.

Figure 1. Workload and facility hierarchical model.

3.2. Decision-making logic for offline process scheduling

The assignment procedure of the operations to the various resources of the examined layout is the main goal of the proposed developing module. The design of an assembly line is subject to a multi-criteria decision-making logic, where in some cases these criteria cannot easily be compared with each other

In general, there are four classes of manufacturing attributes to be considered when making manufacturing decisions, cost, time, quality, and flexibility (Chryssolouris 2006). These classes manifest themselves, depending on the particular problem, specific objectives, and goals. These attributes will also be used under Human-Robot Operation Planning (HROP), for the evaluation and the selection of a resource or combination of resources to execute a task.

3.2.1. Constraints evaluation

For the planning time to be reduced, a filtering of the existing resources is being applied. In the beginning, the proposed algorithm will check the possibility of an operation being allocated to a specific resource, in terms of its existence in the area where the operation will be executed. In addition, each time that a new operation is examined, the availability constraint is checked again. After that, a suitability evaluation of each available resource for the examined operation will take place. Under this suitability evaluation, several aspects will be investigated, focusing on the resources’ technical capabilities or skills for the operation execution. These suitability constraints will be based on the payload of resources, as well as their capability to reach every point of the handled part. Then, a safety constraint is examined, focusing on human needs, for an operation to be safe for a human. In the end, the final assignment of the operations to the appropriate resources, according to a multiple criteria decision-making logic will be implemented. In Figure 2 the flow chart of each operation examination algorithm is presented.

Figure 2. HROP algorithm flow chart for the examination of each operation.

3.2.1.1. Availability constraint for resources examination

Assembly of large-scale parts is a complex process, which consists of several operations, either under preparatory work or work that is needed for the installation of the various sub-assemblies. Such an assembly process can unfold over a wide area, including different lines and stations. However, one of the main challenges that are observed under this separation of the overall facility is to define each time which resource is available in each of these stations.

Many previous studies of production or academy have focused on human-robot collaborative layouts, either simple or quite complex ones. By simple, it is meant a layout when the sequence of operations is executed in a common area and it is known that all the resources (human(s) and/or robot(s)) are located inside this area. On the other hand, a more complex situation can consist of numerous operations that take place in different areas, as well as, a collaborative layout to include humans and a variety of robotic resources, such as high-payload robotic manipulators, mobile lightweight robots, etc. Thus, it is obvious, that it would be time-consuming for the planning algorithm to take into consideration all the layout resources and the possible combinations of them, each time that a specific task is examined. For instance, a steady high-payload collaborative robot cannot be in different areas during operation execution and it is time and programming-consuming to consider it for all the tasks of the assembly process.

Under this concept, it is important for the proposed decision-making algorithm, as a first step, to define the location where each operation will be executed, as well as the resources that are available for this location. For this reason, it is important to have as input information from both operations and resources databases. This information would be the data required with respect to the product assembled, in terms of the name of an operation and its ID number, which indicates in which area or station it belongs, as well as, the available resources registered each time in each specific station. In this way, each time that an operation is examined, some possible resources will be excluded for its execution, making the following multi-criteria decision-making evaluation model faster, since fewer alternatives are examined. Moreover, due to the high flexibility of a complex human-robot collaborative layout, the real-time update of the resources’ status (location, availability, etc.) is considered mandatory for enabling fast decision-making in real production lines.

3.2.1.2. Suitability constraint for resources examination

After defining the possible resources that can be examined for the assignment of each operation, a first assessment of the suitable resources follows. Under this assessment, the user of the HROP module would be able to allocate the operations between some possible alternatives of resources in a static way, excluding not suitable ones by considering different variables. This has to be done by properly considering both the strengths and the constraints of humans and robots, according to the different capabilities that each resource provides. Figure 3 presents an example of a task assigned to the potential alternatives of resources in a human-robot collaborative layout. More specifically, this layout includes two human operators, a high-payload robot, and a lightweight collaborative one. The goal of the suitability, and subsequently of the safety constraint, is to examine all these resources, in terms of single humans or robots, and in a future study all the resource alternatives, adding also the collaboration of human-robot and robot-robot.

Figure 3. Example with the possible alternatives of resources for suitability constraint check.

The most common skills that a resource should have in order to be considered as a suitable choice for the execution of a specific operation are its capability of lifting the parts/tools that are used, or of reaching all the points needed for the operation, or the ability to move within the area of the operation to transfer various parts, etc. For the evaluation of the suitability constraint, one basic value that has to be taken into consideration is the payload of each resource, comparatively with the weight of the parts or tools used for a specific operation. In addition, the reachability of the resources is calculated, since a suitable resource should be able to reach all the points of the processing part. In the end, the mobility of the resources, in terms of their capability of moving inside the area, is taken into consideration, as an auxiliary ability of some resources to reach each point of the examined operation’s area. Figure 4 presents the analysis of the suitability constraint regarding these values.

Figure 4. Suitability constraint algorithm workflow.

For the implementation of this suitability evaluation, two main types of inputs are needed, the operations’ particularities and specifications and the resources’ capabilities and skills. By operation’s particularities and specifications is meant some requirements that an operation may include, such as the tools that are used and the parts that are handled for each operation, their dimensions, and weight, as well as the type of each operation. Most of this input data is coming from the scenario description and an operation and resources’ performance analysis, in terms of recommendations for the resources’ placement into the entire layout. All these operation requirements have to be taken into account along with the resources’ capabilities and skills and be compared with them to consider a resource as suitable for an operation.

3.2.1.3. Safety constraint for resources examination

After some resources are considered as ‘suitable’ mainly from a technical field of view, it is now the turn of the safety constraint to be examined, which is mainly focused on human evaluation. Under this constraint, it is examined if the nature of the operation could threaten human safety, human health, and production environment integrity or if it involves areas where robotic resources can hurt humans in close collaboration. For the health and occupational safety part, a crucial role has the residual risk, in terms of risk remaining after all possible protective measures have been implemented, such as harmful effects of parts and/or tools materials. These harmful effects will be provided as input through the category and the type of the part/tool. In addition, under this constraint, each operation is examined if it is considered repetitive in the whole process or not. In the case of a repetitive operation, it is assigned to robots. As for the danger of close human-robot collaboration, the minimum distance of human and robotic resources comparatively with the distance which the corresponding ISO specifications recommend and the confined spaces are examined. In Figure 5, the analysis of the safety constraint algorithm is presented.

Figure 5. Safety constraint algorithm workflow.

After the examination of all these constraints, some resources will have been excluded for the final multi-criteria evaluation. In this way, each time the overall decision-making algorithm can run faster, aiming at the real-time planning of the whole process.

3.2.2. Multi-criteria evaluation

The main contribution of the proposed model is finally to assign each operation to a resource. A manufacturing decision-making logic is basically the selection of values for certain decision variables related either to the design or to the operation of a manufacturing process, machine, or system. Such a decision-making process is based on performance requirements, which specify the values of the relevant manufacturing criteria.

In this study, the selection of a resource, between the available and the suitable ones, for the execution of each operation, is examined under three aspects. These aspects are related to the cost of a resource to execute an operation, the time needed for the execution, and the comfort or ergonomic factors that focus on the collaboration of the resources. Thus, although cost-and-time-related attributes remain extremely important for any manufacturing decision, emphasis must also be placed on finding quantitative definitions for quality of operations execution, so that appropriate trade-offs among the different classes of manufacturing attributes can be established to achieve a comprehensive treatment of the complex assembly problem.

3.2.2.1. Operating cost aspect

Costs related to manufacturing encompass a number of different factors, such as investment cost or cost of a resource during the execution of an operation, etc. The proposed decision-making logic is focused on the operating expenses of a resource. The operating cost criterion (Equation 3) is estimated as the sum of the operating expenses for each operation and each resource of the studied layout. Two separate formulas are used for estimating the cost for humans (Equation 1) and robots (Equation 2):

(1) $\mathit{O}{C}_H^i=\frac{\mathit{Dail}{\mathit{y}}^{\mathit{\hspace{0.17em}}}\mathit{salary}}{\mathit{Workin}{g}^{\mathit{\hspace{0.17em}}}\mathit{Time}}\cdot \left|T_C^i-T_S^i\right|$(1)

(2) $\mathit{O}{C}_R^i=E_R\cdot C_E\cdot \left|T_C^i-T_S^i\right|$(2)

(3) $\mathit{OC}={\sum }_{i=1}^k\left[\mathit{O}{C}_R^i+\mathit{O}{C}_H^i\right]$(3)

where, OC_H, OC_R are the operating expenses for each of the k resources, humans and robots, respectively, for an operation, OC is the total operating expenses per cycle time (day), T_Cⁱ is the completion time of operation i, and T_Sⁱ is the starting time of the same operation that is assigned to a resource. Daily salary and daily working time are pre-defined, E_R is the average energy consumption (kWh) per robot which is affected by the robot status each time (e.g. idle, resting, moving), its payload and the energy efficiency indicator that each resource is characterized, as it has been analyzed in literature (Michalos et al. 2015; Michalos, Makris, and Chryssolouris 2008). In the end, C_E is the cost of 1 kWh for the robot energy consumption.

3.2.2.2. Execution time aspect

In manufacturing systems, time attributes refer to how quickly a manufacturing system can respond to changes in design, volume demand, etc., and to how quickly a product can be produced by the system, in terms of the time needed for the execution of a specific process (Chryssolouris 2006).

For this reason, it is important to take into consideration the execution time needed for a series of operations, in order to reach the final order demands. The cycle time criterion is considered as the total duration of an operation execution per cycle time, T_H, in seconds. This criterion is calculated as the absolute value of the arithmetic difference between the starting time T_Sⁱ of each of the n operations and the completion time T_Cⁱ of the same operation, based on its assignment to a possible resource in a specific production cycle (Equation 4):

(4) $T_H=\left|T_C^i-T_S^i\right|$(4)

3.2.2.3. Comfort & ergonomics aspect

As for the ergonomics evaluation during operation execution, several metrics can be taken into account as presented by (Arkouli, Michalos, and Makris 2022) who have listed the most popular methods and tools currently used in the manufacturing field for ergonomics evaluation. In the proposed approach, an important criterion that is also placed under the ergonomics aspects is the covering distance criterion. This criterion is calculated by the following equation (Equation 5):

(5) $\mathit{D}={\sum }_{i=1}^n{d}_{\mathit{total}}$(5)

where d_total is the total distance covered by a resource for each of the n operations, in order to carry a part and/or tool and to execute a process or to make an assembly. Again this criterion will be used by the proposed model to evaluate a better total plan under human ergonomics.

3.2.2.4. Normalization and utility value

It is difficult to simultaneously optimize all the criteria of the above-mentioned aspects. The overall outcome of a manufacturing decision is rather governed by trade-offs between these different manufacturing attributes. Assessment of these trade-offs requires a means of quantitatively evaluating each attribute. For this reason, Chryssolouris et al (Chryssolouris 2006). provided a calibration method for determining suitable values given the desired trade-off between decision quality and computational burden as expressed in terms of numerical weights. According to this method, a negative exponential distribution is used, which levels off at the alternatives with the highest utility values. For the resources to be compared, based on their criteria values, a matrix containing the different design alternatives, as rows and the calculated criteria values as columns, can be created. Normalization of these values needs to take place, to reach a final cumulative score. This normalization is carried out for criteria that should be maximized (Equation 6) or minimized (Equation 7):

(6) ${\hat{C}}_{\mathit{ij}}=\frac{{\mathit{C}}_{\mathit{ij}}-C_j^{min}}{C_j^{max}-C_j^{min}}$(6)

(7) ${\hat{C}}_{\mathit{ij}}=\frac{C_j^{max}-C_{\mathit{ij}}}{C_j^{max}-C_j^{min}}$(7)

where C_ij is the consequence value of alternative i with respect to criterion j and ${\hat{C}}_{\mathit{ij}}$is the normalized value of C_ij.

The final selection of the resource is based on the total score (utility value U_i) of each alternative, calculated as the sum of the products obtained by multiplying the normalized criteria values by a weight factor assigned to each criterion (Equation 8):

(8) $U_i={\sum }_{j=1}^n{w}_c{\hat{C}}_{\mathit{ij}}$(8)

where w_c is the criterion’s weight factor and n is the total number of the criteria used. The weight factors w_c are represented on a scale between 0 and 1 and denote the relative importance of each criterion to the user. Alternatives with higher utility values are preferable over the ones with low utility values. With the use of this utility function, the process is enhanced as it allows the assessment of the performance to be broken down into elements which were evaluated individually (Michalos et al. 2015).

3.3. Behavior trees architecture for a dynamic task planning

The particularity and the main contribution of this study is the integration of the Behavior Trees (BT) architecture, aiming for dynamic and modular task planning. Under the term ‘dynamic’ task planning, BTs provide a real-time adjustment of the planning in human-robot collaborative and industrial layouts, mainly in unforeseen cases. An unforeseen case can be considered when a human resource cannot execute an operation for personal reasons (e.g. illness, etc.) or a robotic resource faces a malfunction and has to be replaced. In such cases Behavior Trees facilitate the planner to make quick changes for a specific operation or a sequence of operations, and not for the whole process, by monitoring the availability of all the resources and by updating the evaluation and the final assignment. Moreover, Behavior Trees are visually intuitive and easy to design, test, and debug, and provide more modularity, scalability, and reusability than other behavior creation methods. Furthermore, a Behavior Tree can be a proper way to design the switching between multiple operations and between multiple autonomous devices, such as robots. It consists of behaviors or nodes connected to each other in the form of a tree, starting with a single root node. BTs can help in creating an efficient method of designing complex algorithms and systems that are both modular and reactive, such as the planning algorithm for complex layouts of numerous operations and resources. Modularity means the degree to which the components of a system can be separated into individual blocks and then recombined, while reactivity implies the ability of an algorithm to react to changes efficiently.

Behavior Trees can be used to design a highly responsive robotics system. Robots programmed with behavior trees prove highly beneficial as cobots as they can react and respond effectively to their environment. In an example of a robot executing an operation in an HRC environment, a Finite State Machine (FSM) would execute the operation unstoppably, even though the end result will remain incomplete. It may not pause its execution or at least it will need to take into account a lot of safety parameters, if an employee comes in its path or if the operation has an error due to a robot malfunction. This results not only in the loss of productivity for that instance but also can cause a butterfly effect and result in more inefficiencies. On the other side, the same robot designed with behavior trees is highly modular and reactive. The operations of the robot are carried out or aborted according to ticks, which depend on the leaf node’s return statuses. In more detail, these leaf nodes provide running status if its execution has not finished yet, success if it has achieved its goal, or failure otherwise. In simpler words, in an emergency case, such as the existence of an obstacle in the robot’s path, it stops with the assigned operation and returns to a safe position. A safe position, in this case, can be waiting for another resource to solve the problem or returning to the assembly line and alerting the system about the incident to provide another solution.

For Human-Robot Operation Planning (HROP) module, the main reasons for which BTs have been selected over FSMs, are analyzed below. First of all, they facilitate the developer by providing tools, such as Groot (Han et al. 2021), for easy graphical representation of large models, such as the planning of HRC layouts of multiple operations and multiple resources. In this way, it is easier for the user to understand the corresponding workflow and the order that the hard-coded scripts are implemented, as well as the condition or constraint that is executed by providing the running, success, or failure status. As for the last status indication (‘failure’), it helps the developer to understand where is the error, not only a technical one but also a logical one. State transitions in FSMs, by comparison, are harder to understand both in their textual and graphical representation (Colledanchise and Ögren 2017). An other equally important reason for the selection of the BT architecture is that they are more expressive than the FSMs, as the existing software functionalities and components are easier to read and be combined in order to express more complex flows. It is also easy to add, remove and/or update an operation in the whole process, mainly during the online process execution just by updating the input data files (.json) of the HROP module. In this way, the developer or an inexperienced user is not needed to make big changes in the hard code and build again the whole application.

The last reason that Behavior Tree architecture can be appropriate for the problem that this manuscript tries to face, in contrast with the FSM approaches, is that BTs are intrinsically hierarchical since it is possible to compose complex behaviors including entire trees as sub-branches of a bigger tree. In Figure 6, an example of the Behavior Trees integration in the HROP module is visualized. As it is aforementioned, the HROP module is focusing on the task and operation level of the workload hierarchical model, examining the available resources and proposing, in the end, one. According to this, each task is separated into more operations. At the beginning of each operation, the constraint evaluation takes place. The constraint evaluation needs at least one resource to get over all the constraints, in order to continue with the multi-criteria evaluation. Subsequently, there is a fallback node (a box containing the label ‘?’) to proceed with the evaluation of the specific resources. Fallbacks are used when a set of actions represent alternative ways of achieving a similar goal. Thus, the Fallback node routes the ‘Ticks’ to its children from the top until it finds a child that returns either ‘Success’. It returns ‘Failure’ only if all its children return ‘Failure’. In our case, his fallback node is used to proceed with the multi-criteria evaluation in three different cases, when only robots are available, only humans, or both. The reason for this is that in each one of these cases, different criteria may be examined, as well as it aims at a faster planning time since there is no need for all the resources to be evaluated. After finding in which of these three cases the operation belongs, the multi-criteria evaluation of the remaining resources follows, and in the end the operation assignment.

Figure 6. Example of Behavior Tree based on the proposed hierarchical model and HROP approach.

4. Automotive case study

A case study scenario was inspired by a real manufacturing system in the automotive industry. According to this scenario, an innovative way of assembling large-scale parts for the automotive sector is studied, and more particularly the preassembly of buses where the need for the proper allocation of multiple and multi-type resources is pervasive (Z. Arkouli et al. 2021). Briefly, this case study consists of numerous parts (steel profiles and frames, windows), numerous tools (cleaning and welding tools, glue dispenser) and different kinds of tasks (welding long profiles, lifting heavy windows, gluing complex paths of windows, etc.).

The whole scenario studied is divided into two different areas or stations. In the first one, the preparation and the welding of a series of steel profiles/panels take place. In this station, steel frames are transferred, pre-treated, and welded to each other, to be assembled on the entire bus. For this task, operators are working mainly on horizontal structures. In the next station, the installation of windows on the bus is conducted. In this station, firstly, glue is dispensed on the contour of the heavy windows (weight greater than 25 kg), which then are installed on the painted bus. The task is completed with the inspection of the windows to be aligned, as well as for any potential damage incurred during the task execution.

Currently, all the processes are conducted by human workers, who are responsible to transfer and weld the steel profiles/panels in station 1, as well as for the gluing and installation of the windows on the bus in station 2. These tasks are considered non-ergonomic since it is quite repetitive and tiring for human workers to travel long distances in order to transfer and weld steel frames. In addition, the lifting and the pressure needed for the installation of the windows is also an important issue, as more human operators may be needed for transferring and gluing of windows, and a great workload for their installation on the vertical area of the bus

The detailed list of all these operations, as well as the area/station where each of them is executed, is presented in Table 3. More specifically, the preparation of the steel frames and the windows installation in the preassembly phases of buses are listed in this table. Twenty-six operations have been separated into two stations, where the first one is about the welding of three steel profiles/panels (10 operations) and the second one consists of the gluing and assembly of three windows on the painted bus (16 operations). Mainly, in the first station, lightweight tools will be used, such as a cleaning spray, a measuring tape, a marker, and a welding tool. The workspace is a horizontal table, as it is above mentioned. As for the second station, again some lightweight tools are used, such as again the cleaning spray for the windows preparation and a glue dispenser for their gluing, as well as a light sensor for the area inspection. On the other hand, there are also heavy windows that are handled (weight greater than 25 kg). HROP will take into account all these tools and the available resources’ specifications, especially under the suitability constraint evaluation, to exclude some resources which are unable to execute the corresponding operations.

Table 3. List of operations and working areas for the bus preassembly case.

Working area	Operation description
Station 1 – Welding of steel profiles/panels	1.1	Place the 1^st steel profile/panel on the horizontal table	1.5	Clean the steel profiles/panels with a cleaning spray	1.9	Weld the 3^rd steel profile/panel
	1.2	Place the 2^nd steel profile/panel on the horizontal table	1.6	Measure and mark the area for welding	1.10	Clean the entire steel frame with a cleaning spray
	1.3	Place the 3^rd steel profile/panel on the horizontal table	1.7	Weld the 1^st steel profile/panel
	1.4	Bring the tools for the steel frames preparation	1.8	Weld the 2^nd steel profile/panel
Station 2 – Assembly of windows on the bus	2.1	Bring the 1^st window	2.7	Clean the 2^nd window with a cleaning spray	2.13	Dispense glue on the 3^rd window
	2.2	Clean the 1^st window with a cleaning spray	2.8	Dispense glue on the 2^nd window	2.14	Install the 3^rd window on the bus
	2.3	Dispense glue on the 1^st window	2.9	Install the 2^nd window on the bus	2.15	Check for the alignment of the 3^rd window
	2.4	Install the 1^st window on the bus	2.10	Check for the alignment of the 2^nd window	2.16	Inspect the entire bus for potential damages
	2.5	Check for the alignment of the 1^st window	2.11	Bring the 3^rd window
	2.6	Bring the 2^nd window	2.12	Clean the 3^rd window with a cleaning spray

In Figure 7, an example of the described case study of the automotive industry is presented, based on the aforementioned four-level hierarchical workload model. At the top of this model, a specific job has to be made inside an assembly line, by means of executing the assembly of a specific kind of bus with a specific VIN (Vehicle Identification Number). Subsequently, in the various stations of the assembly line, the job is separated into processes of the assembly, where in this case study, they are analyzed into the preassembly of components on the bus. A more detailed description of this process follows, where the available resources for each station are responsible to execute more complex activities or tasks, in terms of preparation of the steel frames and the windows assembly on the painted bus. After that, there is a list of operations for a specific resource defined each time from the HROP module. For instance, in the preparation of the steel frames task, some of these operations include the cleaning, measuring/marking, and welding of the steel profiles/panels, while under the windows assembly task, some of these operations include the cleaning, the gluing and the installation of the windows. In the end, each specific resource has some actions to execute an operation. For example, for the execution of the glue dispensing operation, selected resources should bring the glue dispenser, test the glue, and finally place the glue on the windows’ contour.

Figure 7. Case study analysis based on the workload hierarchical model.

The envisaged solution proposed for this scenario involves Human-Robot collaborative tasks. The overall layout of this case will consist of multi-type and multi-purpose robots, working together with multiple human operators in a common area. Lightweight robotic manipulators, placed on a mobile platform, provide the capability to execute operations that need traveling large distances or repeatability, such as providing tools or welding of steel frames. As for human workers, they may be responsible for operations of high dexterity and intelligence, or operations that are difficult to be done by robots, such as accurate preparation of the steel profiles/panels. As for station 2, in operations where the handled parts or tools are quite heavy, high-payload robotic resources would be a more valuable solution instead of human workers. The proposed layout for each station is visualized in Figure 8.

Figure 8. Proposed layout and available resources for the case study.

5. Implementation of the HROP module

For the Human-Robot Operation Planning (HROP) implementation, the proposed decision-making logic, and the final operations assignments to specific resources, two components have been developed, namely the back-end and the front-end components. The back-end component has been implemented in C++ and it is based on the Behavior Trees (BT) architecture. BT has mainly been selected because of the easiness for the developer to understand and separate the whole process, as well as the execution or potential errors during development through the graphical representation of Groot, as it is visualized in Figure 9. This back-end application runs in an Ubuntu Linux 20.04.4 LTS virtualized environment with the latest C++ 9.4.0 version.

Figure 9. Graphical representation (Groot) of the studied case Behavior tree (up), and analysis of a specific operation (down).

As for the front-end component, a graphical representation of the result Gantt chart has been created. This component was programmed using C# and the graphical result has been created in Unity 2020.3.22f1. The whole program was run on a mid-range computer (Intel i7 –10,750 H, 16 GB GDDR6 6GB RAM, GTX1660 Ti). Figure 10 shows an example of a Gantt chart created after the running of the application into a virtual environment.

Figure 10. Gantt chart visualization into Unity.

Subsequently, the user has to import the specifications of the several alternatives, such as speed, payload, and reachability, and assign the list of the operations to the corresponding possible alternatives. For the input data required for the HROP module, 4 (.json) files are used, which are directly connected to each other and their logical data models are presented in Figure 11. The first one contains information about the operations such as each operation number id, a short name, and a detailed description, the list of actions needed to be possessed by a resource for the completion of the operation, the resource to execute the specific operation, the starting time and the duration, as well as some precedence constraints, in terms of the execution of the operation by the same resource from a previous one, or the need of executing this operation strictly sequentially with a previous one. The second.json file provides information about the registered resources in the specific assembly line, that is a number id and its name, its type (H for humans resources and R for robots), and its availability, i.e. A and N for available or not resources, respectively, in a specific station. During the calculation of the plan, the availability of resources that are allocated for an operation turns currently not available (CN), until they will be again available for another operation. After the availability field, some specifications of the resources are needed, in terms of their payload, velocity, reachability, and mobility). In the end, the current position and rotation are provided. The next one consists of a list of the actions needed for the execution of the various operations. For each action, a number id, its name, and a detailed description are provided, as well as the type of the action. Then, the tools which are needed for this action and the workspace that they will be used are reading. The last input data is about the tools (welding tool, glue dispenser, etc.) that are used for an operation or the parts (frames, windows, etc.) and are handled during its execution. For each one of these tools/parts, its number id, and name are provided as well as its category, that is some specific properties of each part/tool, such as its harmful to human materials, etc. Furthermore, its weight and dimensions are provided, as well as, the ids of the subparts that it consists of. In the end, position and rotation information is provided.

Figure 11. Input data (logical data models) about Operations, Resources, Actions, and Tools.

After collecting all the aforementioned input data, scheduling of settings has to be conducted, such as search parameters and evaluation criteria, in order to adjust the preferable operation assignment. One of the most important steps of the proposed development is the scheduling of the evaluation criteria weights, in terms of importance. For now, these weights are hard-coded modified and in a next step, a GUI will be developed, providing all the implemented criteria, and the opportunity for the user to select the corresponding weight value for the utility value calculation. For the calculation of execution time, times resulting from simulation through RViZ, are compared with the manual times provided by the end-user and the corresponding ones that are calculated from the resource velocities.

6. Results and discussion

Human-Robot Operation Planning (HROP) running results for the operations analyzed in the previous section of the automotive case study are presented in this section. A detailed assignment of the operations is created for both the ‘welding of steel profiles/panels’ task of station 1 and the ‘assembly of windows on the bus’ task of station 2. For the execution of these tasks, 2 humans and 3 robots have been evaluated, whose profiles are presented in Table 4.

Table 4. Human and robotic resources profiles.

Resources’ profiles
Id	0	1	2	3	4
Name	‘Tom’	‘Racer7–14’	‘Racer5-0-80’	‘Adam’	‘AURA’
Type	‘H’	‘R’	‘R’	‘H’	‘R’
Payload (kg)	15	5	5	15	170
Speed (m/s)	1	0.6	0.5	0.7	0.5
Reachability (m)	10	1.43	0.8	10	2.8
Mobility	TRUE	TRUE	TRUE	TRUE	FALSE

In Table 5 this task allocation is presented, providing for each operation, its number and name, the resource selected for its execution, as well as the time limits of the operation (starting and ending time) and its duration.

Table 5. Operations assignment table for welding of steel profiles/panels (Station 1) and assembly of windows on the bus (Station 2) tasks.

Operation no.	Operation name	Resource	Starting time	Duration	Ending time
Welding of steel profiles/panels task
1	Place the 1st steel profile/panel on the horizontal table	‘Tom’	0.00	30.00	30.00
2	Place the 2nd steel profile/panel on the horizontal table	‘Adam’	0`.00	42.86	42.86
3	Place the 3rd steel profile/panel on the horizontal table	‘Tom’	30.00	30.00	60.00
4	Bring the tools for the steel frames preparation	‘Racer7–14’	0.00	30.61	30.61
5	Clean the steel profiles/panels with a cleaning spray	‘Tom’	60.00	80.00	140.00
6	Measure and mark the area for welding	‘Tom’	140.00	50.00	190.00
7	Weld the 1^st steel profile/panel	‘Racer7–14’	190.00	16.30	206.30
8	Weld the 2^nd steel profile/panel	‘Racer7–14’	206.30	24.48	230.78
9	Weld the 3^rd steel profile/panel	‘Racer7–14’	230.78	12.64	243.42
10	Clean the entire steel frame with a cleaning spray	‘Tom’	243.42	110.00	353.42
Assembly of windows on the bus
1	Bring the 1^st window	‘AURA’	0.00	18.46	18.46
2	Clean the 1^st window with a cleaning spray	‘Tom’	18.46	40.00	58.46
3	Dispense glue on the 1^st window	‘Tom’	58.46	100.00	158.46
4	Install the 1^st window on the bus	‘AURA’	158.46	18.07	176.54
5	Check for the alignment of the 1^st window	‘Tom’	176.54	15.00	191.54
6	Bring the 2^nd window	‘AURA’	176.54	17.78	194.31
7	Clean the 2^nd window with a cleaning spray	‘Tom’	194.31	50.00	244.31
8	Dispense glue on the 2^nd window	‘Tom’	206.30	120.00	364.31
9	Install the 2^nd window on the bus	‘AURA’	364.31	18.55	382.86
10	Check for the alignment of the 2^nd window	‘Tom’	382.86	15.00	397.86
11	Bring the 3^rd window	‘AURA’	382.86	21.20	404.06
12	Clean the 3^rd window with a cleaning spray	‘Tom’	404.06	45.00	449.06
13	Dispense glue on the 3^rd window	‘Tom’	449.06	110.00	559.06
14	Install the 3^rd window on the bus	‘AURA’	559.06	15.61	574.67
15	Check for the alignment of the 3^rd window	‘Tom’	574.67	15.00	589.67
16	Inspect the entire bus for potential damages	‘Tom’	574.67	120.00	709.67

Based on these results some important conclusions arise. For the first task, about the ‘welding of steel profiles/panels’, two mobile robots and two human operators with different velocities are considered available. When the suitability constraint is evaluated for the first operation of bringing the steel profile/panel, due to the payload, robots are excluded and these tasks are assigned to humans. After that, for transferring lighter tools, all resources are suitable, based on their payload, but this operation can also be executed in parallel with the previous ones and the availability of humans is ‘Not available’ during their execution. For this reason, this operation is assigned to the faster mobile robot. Similarly, all the other operations are planned. Finally, under the first task and for the welding operations, all the resources are overcoming the constraints of availability and suitability. However, for the welding tool, as an input in the ‘category’ field, the string ‘chemicals’ has been defined, thus humans now are excluded from these operations. In this way, welding operations are assigned to the ‘Racer7’ mobile robot, which in our case, it has been considered the faster one.

For the second task, about the ‘assembly of windows on the bus’, two human operators with different velocities and a high-payload collaborative robot (AURA) are considered available. This time, most of the operations have the precedence constraint that they have to be executed strictly sequentially with the operation that they are connecting. Almost all the operations can be executed by both human operators and the robots, but the ones for handling heavy parts, i.e. bringing and installation of windows (weight greater than 25 kg), have to be executed by the high-payload robot (‘AURA’). All the other tasks are executed by humans since they are considered faster than the robotic ones based on the cycle time criterion. In addition, from the humans, according to the provided resources’ profiles, it seems that ‘Tom’ is faster than ‘Adam’, thus the rest of the operations are preferred to be assigned to ‘Tom’. Last but not least, for inspection operations, high reachability is needed in order to scan the entire bus. For this reason, in the suitability constraint, the ‘AURA’ robot is excluded from the multi-criteria evaluation.

As it is aforementioned, the HROP module is implemented under Behavior Trees architecture for three main reasons, in contrast with the FSMs, the useful graphical representation, the fact that BTs are intrinsically hierarchical and their easiness to be updated. In addition, previous research and approaches (Michalos et al., Multi criteria assembly line design and configuration – An automotive case study, 2015;) (Michalos et al. 2016) showed that the time required for the algorithm to derive the assembly lines’ configuration and generate the plan was some seconds (30 s for 38 tasks in the first case and 10 s for approximately 80 tasks in the second one) for all of the experiments executed, while the simulation of each configuration took (on average) 5–10 min in order to provide the results. Both of the studies above were based on the Intelligent Manufacturing Planning and ConTrol (IMPACT) approach (Chryssolouris 2006). On the other hand, it is difficult to make a direct comparison between different methods of literature, since date of the respective cases studies are missing. Nevertheless, implementing the proposed module under the Behavior Trees (BT) architecture and testing different number of operations, showed that HROP planning time can be considered somehow scalable. Figure 12 12 presents the different times emerged for planning 5, 26 (proposed case study), 40, 80 and 100 operations. As it is presented, the HROP planning time increases somehow proportional the more operations are planned. However, the planning time of the proposed module seems to be quite short without running the discrete event simulation (less than 1 s), even if much more operations are examined.

Figure 12. Planning time scalability examination for different number of operations.

As for the cases where the operations are simulated, in case that robot resources are available for evaluation, the planning time is quite a bit longer (about 3–4 min), as it is presented in Table 6 below.

Table 6. Human and robotic resources profiles.

Examined implementation scenario	Overall execution time (secs)		HROP planning time (secs)
	Welding of steel profiles/panels task	Assembly of windows on the bus	Welding of steel profiles/panels task	Assembly of windows on the bus
All constraints checked	353.42	709.67	94.63	112.28
No safety constraint (all resources available)	340.00	709.67	95.31	112.28
Only humans are available (no safety constraint)	414.24	–	0.05	–
All operations sequential	440.00	741.08	102.00	112.19

One more profit of implementing the whole HROP model under the BT architecture is that it facilitates users to make quick changes in all the data used, such as operations constraints, resource specifications, tools needed, etc. For instance, what if all the operations need to be executed by human operators, or what if each operation is strictly sequential to a previous one or there is no need to take into consideration the human safety constraint? Will there be a change in the execution time of the entire task or in the planning time of the HROP module? In Table 6, the calculation of the overall execution time of each task for the above-mentioned cases is recorded, as well as a calculation for the HROP planning time, running in parallel the discrete event simulation of the proposed case study in full robot speed. In Figure 13 a comparison of these calculations is visualized, using four different scenarios, the one where all the aforementioned constraints are examined, no safety constraints are taken into consideration, only humans are available and all the operations have to be strictly sequential.

Figure 13. Comparison of the different scenarios for a) overall task execution time and b) HROP planning time.

As for the overall execution time of the tasks, for the ‘Welding of steel profiles/panels’ task, the quickest planning scenario seems to be the one where the human safety constraint has not been taken into consideration, which is logical since the previous harmful operations will be executed by human operators which are faster. On the other hand, the slowest scenario is the one where all the operations will be executed strictly sequentially and not in parallel, where the cycle time criterion becomes more important. Almost the same conclusions arise for the ‘Assembly of windows on the bus’ task, but this time the planning of the manual execution has stopped, since the suitability constraint cannot allow human operators, as a single resource, to execute tasks that need high payload, such as the ones of handling the heavy windows. In a future study, this problem will be solved, by evaluating also the collaboration of the resources for a specific operation.

In the comparison of the HROP planning times between the different scenarios, some important conclusions are also drawn. This time, all the durations, that all available resources are evaluated, are close to each other, and this is logical since almost the same number of operations are simulated. However, the planning duration for the manual execution scenario is quite lower than the other ones, according to the results presented in the table, since no operations have to be simulated and only input data are used. As for the planning times of the second task, they seem to be a little higher than the first one, since the second task consists of more operations than the ‘Welding of steel profiles/panels’ task. Again this time, for the ‘Assembly of windows on the bus’ task, the planning of the manual execution has stopped, due to the suitability constraint.

As it is aforementioned, two main benefits that provide the Behavior Trees architecture are modularity and reactivity. In our case, these are very important and useful, because of the complexity of the process and the multiplicity of the resources. So for instance, if a robot breaks down, such as ‘Racer7–14’ for the ‘Welding of steel profiles/panels’ task during the real-time process execution, there is no need to run again the whole planning scenario. Modularity provides the ability to separate all the operations as a different node or tree and in such an emergency case, through reactivity, the specific resource will be not taken into consideration for the specific operation. Thus, only this operation will be simulated and planned again, using this time the updated available resources.

7. Conclusions and future steps

This manuscript introduced a novel approach, focusing on the investigation of complex processes in Human-Robot Collaborative (HRC) layouts and aiming at creating valuable plans for resource allocation. A dynamic decision-making logic has been proposed combing both constraints, that exclude some resources, and mathematical criteria that are used for the detailed calculation of a satisfactory solution. The most important innovation of this development is the building of the model under the Behavior Trees (BTs) architecture, aiming at a more dynamic, modular module that focuses on its usage also during real-time process execution for plan rescheduling. Subsequently, a complex case study of the automotive is used to demonstrate the approach, which is focused on the assembly of large parts and more specifically on the preassembly phase of buses. This case study consists of numerous sub-assemblies that need complex process planning, that takes into consideration both human-centered parameters, such as reduction of physical and mental effort and time savings, as well as the increased demands on the product and process quality. It contains operations that both need to be executed exclusively by humans and the ones that, based on the HROP evaluation are better to be executed by robots. The presented results show that the HROP module takes all of these under consideration.

An important limitation of the proposed approach is that it is difficult to run the entire evaluation of HROP in real-time. This means that a first evaluation of the whole process has to take place, calculating the overall plan. In real-time, it can replan only a node or a smaller tree, making good use of the modularity and reactivity benefits of Behavior Trees architecture. In addition, in the current implementation, the evaluation of the HRC quality is limited and the module is not examining if an operation is better to be executed by a single resource or by human-robot collaboration.

Future work involves the implementation of the Human-Robot Operation Planning (HROP) module in even more complex case studies, that consist of many tasks with even more operations. In addition, the integration of more types of resources, mainly robotic ones, with different specifications is an important next step. Another important addition to a next study would be the implementation and enhancement of all the constraints and criteria proposed in this manuscript, as well as the development of a GUI for the HROP module and the addition of interaction with the user tab. The integration of more ergonomic criteria is also an ongoing work aiming at a more human-friendly planning framework. Furthermore, the planning time has to be fastened, since it depends on the number of operations that are simulated and it may last a long time. Last but not least, a Human-Robot Collaboration – Quality Index (HRC – QI) will be implemented, aiming at the calculation of the HRC quality for a whole industrial process, by using metrics that will help to cover more aspects related to human-robot collaboration. The integration of the proposed HROP development is examined under the PENELOPE project.

Acknowledgements

This research has been supported by the European project “PENELOPE Closed-loop digital pipeline for a flexible and modular manufacturing of large components” (Grant Agreement: 958303) funded by the European Commission”.

Disclosure statement

No potential conflict of interest was reported by the author(s).