1 Introduction

A Human–robot collaboration (HRC) system is a manufacturing support system that facilitate collaboration between human workers and robot(s) with the purpose of achieving effective manufacturing goals [1]. Full automation has limitations in achieving high flexibility with demand variability due to high complexity in control technologies and equipment. Application of an HRC system provides flexibility to meet rapidly changing demands more effectively through coexistence and collaboration of operators and robots compared to a full automation system consisting of only industrial robots [2]. Therefore, an HRC system becomes one of main focuses in the domain of industrial robots as a part of the strategy to Industry 4.0 while maintaining the current manufacturing structure [3]. The HRC system is currently being implemented for supporting manufacturing assembly in the way of assigning robots to perform repetitive tasks, material handling, and inspection [4]. In the HRC system, the roles of human operators and robots can be defined in advance based on the characteristics of the tasks. Let us consider an example of small batch operations that requires repetitive tasks to collect different parts according to the frequently changing demands. In such cases, if the robot moves to collect parts as stated in the production demand and the human operator performs the parts assembly, then unnecessary time for movement of the human operator can be reduced while focusing on the assembly process. Today, HRC systems are mostly applied to mass production. These systems are classified to have a low HRC level where industrial robots and human operators are separated by a fixed fence or a virtual fence. In addition, contact between them is strictly prohibited to keep operators safe [5]. Several levels of HRC systems are as shown in Fig. 1. The levels are classified based on the condition of safety fences and possibility of contact between robots and humans. Figure 2 shows a HRC system for a small batch assembly cell with a virtual fence in this study.

Fig. 1
figure 1

Classification of HRC levels

Full size image
Fig. 2
figure 2

An HRC system with a virtual fence

Full size image

This research considers a small-batch manufacturing cells making Make-To-Order (MTO) typed products. The HRC system has four cells for automated machining, inspection, tool-changing, and assembly by sharing a collaborative robot (cobot) and an assembly operator. Three main characteristics of the HRC system for small batch production with a virtual fence need to be considered as the following.

  1. 1.

    Changes of product demands. Products and parts as well as corresponding manufacturing processes in small-batch MTO production are frequently changed because of the fluctuation in customer demands. This may lead to delay or inefficiency in production. If the human operator does not receive any information on the parts delivered by the cobot in advance, or receives incorrect information, then the assembly operation cannot be performed in the right time, which may occur delay or failure of the assembly process.

  2. 2.

    Shared workplace. Because a human operator needs to share the workplace with a cobot, it is necessary for both operator and cobot to communicate each other regarding work orders or occupation of workplace to avoid any hazardous accident such as collision between them. For the case of having a fixed fence in the HRC system, however, such communication is not required because they do not share workplace. The cobot and the human operator must share commonly used information to ensure safe and efficient production such as workplace status, work orders to do, parts to be produced, etc.

  3. 3.

    Cost of a programming and setup time. It is necessary to program the cobot to respond to all possible cases including frequent changeover in product demands and process changes caused by collaboration with human operators. However, the frequent changeover in products or processes increases costs or time for setup and programming in the HRC system. The program of instructions for collaborative activities of a robot in mass production are usually predefined and fixed. However, frequent re-programming is required for cobots to meet the changes in customer demands in this research.

To tackle aforementioned problems, this paper proposes a Process Model based HRC system (PM-HRC) with a virtual fence that enables MTO processes responding to frequent changes in customer demands. In this paper, a virtual fence has been defined by developing and using an object recognizer including vision sensors to control cobot’s entry into a manual assembly station, hence any possible collision between the cobot and human hands can be avoided. The PM-HRC creates production data such as BOMs (Bill of Materials), assembly instructions, and control codes for cobots by using a model including information on products, processes and resources. Because the system distributes proper production data to operators and cobots at the desired processing stages, they can share the same data model that leads to increase in accuracy of works and the level of human safety.

2 Related Research

2.1 Human–Robot Collaboration (HRC) System

The concept of HRC in manufacturing assembly lines was first proposed by Colgate and Peshkin [6]. The HRC system combines human’s cognitive skill and robot’s consistency and accuracy to increase flexibility to deal with a wide variety of products and the frequent changeover in equipment initiating from the fluctuation in customer demands [7]. The application of an HRC system ensures reconfigurability and improves ergonomic factors especially for small batch production. At the same time, the HRC system incorporating with safety mechanism allows robots collaborate with human without any safety fence [8].

Most of the research related to the HRC system focus on the improvement of safety in the system. In order to design safe collaborative work cells, Michalos et al. [9] investigated multiple aspects of safety that should be considered during the design and deployment of human–robot collaborative work cells such as robot path and safety zone as well as control of robot movement by human. Corrales et al. [10] developed a human‐robot interaction system, which guarantees human safety by precisely tracking the complete body of human. Koppenborg et al. [11] conducted an experiment in virtual reality to investigate the effects of movement speed and predictability of a collaborating robot on the human operator. A hybrid cell of one-human one-robot model for the bin-picking problem in low-volume assembly consists of plan generation, system state monitoring, and contingency handling is suggested by Kaipa et al. [12] to enable safe and efficient HRC system. Antonelli et al. [13] discussed the issue related to working time including programming time and setup time between full automation, partial automation using HRC system, and manual process in a small batch production system. Pichler and Wögerer [14] as well as Makris et al. [15] implemented Augmented Reality (AR) system in the small batch manufacturing and heavy automotive industry, respectively. Both researches used AR device to allow information sharing between human and robot during the operation. Many researchers attempted to implement and verify the proposed concepts of HRC system by using simulation software such as visual components [16], Industrial Path Solutions (IPS) and Intelligently Moving Manikins (IMMA) [17], Tecnomatix Process Simulate [18].

2.2 Process Modeling for Manufacturing System

The process model defines the functions of tools that must be performed in order to engineer and integrate a production system. The objectives of process modeling in production system includes human understanding, process management and improvement, automated guidance and execution [19]. Process models can be applied as a tool for system design, communication, simulation and system analysis in a manufacturing system [20].

Some researchers focused on collaborative process modeling in manufacturing processes. Ryu and Yücesan [21] suggested Collaborative Process Modeling (CPM) to define inter and intra collaborative activities in manufacturing processes. The CPM provides a verification method of completeness of defined models by transforming the model into the Petri net. Lee et al. [22] proposed a Part-flow based Manufacturing Process Modeling (PMPM) method inspired by the CPM. PMPM is a manufacturing process modeling method to present collaborative activities, parts flow and changes, as well as resources at the same time. Product-Process-Resource (PPR) of the manufacturing process can be defined with the PMPM model. The PPR modeling concept is to define manufacturing engineering data divided into product, process, and resource to clearly present its characteristics and relationships [23]. The PPR is being applied to Automation Markup Language (ML), assembly automation and HRC system by integrating with knowledge-based, ontology and data exchange technologies [24,25,26].

Kim et al. [27] proposed Collaborative Product Life cycle Management (CPLM) for the automotive parts industry. The CPLM model is translated into eXtensible Markup Language (XML) schema from integrated meta models for the collaborative design process. Han et al. [28] proposed an integrated system for product-based manufacturing by using automatically extracted BOM from 3D Computer Aided Design (CAD) system. Awad et al. [27] added risk and safety concepts into traditional PPR model to perform risk assessment and to retrieve possible safety measures at the stage of HRC workplace design. Breton and Bézivin [29] defined model executability and proposed ontology based model transformation to generate skeleton codes by mapping into independent platforms.

In this paper, model extendibility and executability defined in the previous studies for manufacturing processes are applied to generate several types of manufacturing data (e.g., BOM, assembly instruction, robot control codes, and verification models).

3 Process Model Based HRC System (PM-HRC)

3.1 Problem Definition and Assumption

The HRC system for small batch production as in Fig. 2 can be defined as follows:

  • product: small batch product.

  • process: cell based process.

  • resource: single cobot, assembly operator and multiple tools.

  • production: make to order system.

  • cell: automated machining, assembly, robot tool changing, and inspection cells.

The problem assumptions are defined as follows:

  • sharing the assembly cell between cobot and assembly operator with a virtual fence.

  • multiple tools for product handling and assembly for the cobot.

  • independent and different requirements of production orders.

  • changing processes according to the production requirements.

As described in Sect. 1, the HRC system for small batch production with a virtual fence has problems such as data integration issues due to frequent changes in demands, process recognition due to shared workplaces, and robot re-programming due to process changes. It requires process realization, integrated process operations between independent objects (i.e., the cobot and the operator), and accurate delivery of manufacturing data for execution by independent objects.

Figure 3 is a conceptual blueprint of the PM-HRC system. An object recognition function recognizes the process by detecting parts and the operator's hand in the workplace. A process model integrates assembly operations of a cobot and an operator by converting the process model into assembly data and operation codes. A system framework and main functions must be defined to implement the system.

Fig. 3
figure 3

Blueprint of the PM-HRC system

Full size image

3.2 System Framework and Components

The PM-HRC is a collaborative system for cobots and human operators, integrated by process models that define 4 M (man, machine, material, and method) information of manufacturing processes. The objectives of the system are to deal with worker safety and ergonomic issues and to respond quickly to change in customer demands while maintaining productivity and quality. It utilizes production information and analysis models transformed from the process model by adapting the independent template for model conversion. The concept of model-based integration is inspired by Model Driven Engineering (MDE) and Model Driven Development (MDD) which are widely used in software engineering and development [30]. The integration of the process model and transformed data has the advantages of flexibility and adaptability of technologies to be applied in the HRC system. The expected consequences of this research include quick response to changing customer demands, increase in reusability of engineering data, and improvement of system flexibility by reducing setup and programming time corresponding to the production requirements.

As illustrated in Fig. 4, the components of PM-HRC are defined in three categories: (1) physical components represented by rectangles, (2) functional components represented by circles, and (3) data models represented by cylinders. Physical components consist of an assembly worker, a product, a cobot, a mobile device for receiving assembly data, and a vision sensor for capturing human hands and products. Four work cells for machining, assembly, tool changing, and inspection are also included in the physical components.

Fig. 4
figure 4

Elements of the PM-HRC framework

Full size image

Functional components contain an object recognizer, a communicator, and a model converter. The object recognizer detects human hands and products captured by a vision sensor in the assembly cell. The model converter translates a process model by using an independent template to data. It generates assembly instructions, BOMs, robot control codes, referred to as manufacturing data, and verifies the model by mapping the process model with a predefined template. The communicator determines the status and progress of the processes in the assembly cell, and delivers manufacturing data to the appropriate physical components based on the production procedure.

Data models include a process model, assembly instructions, BOM, robot control codes, and a verification model. The process model has information on the sequence of activities, input/output parts, workers and tools. The assembly instructions have details on tasks and parts required for the operator to perform assembly processes. The BOM has the number of all parts required for making a finished product. The robot control codes are task instructions for the cobot to support the assembly worker. A verification model analyzes the robot control codes to evaluate both structural and behavioral safety and completeness of the cobot’s tasks.

As shown in Fig. 5, conceptual flows of products and data between components can be represented by using solid lines and dotted lines, respectively. Multiple process models can be used depending on the number of products. When a product is selected, the process model defined with 4 M information is delivered to the model convertor.

Fig. 5
figure 5

Conceptual flows of product and data between components

Full size image

The model convertor creates assembly instructions, BOM, robot control codes, and verification models, and transfers them to the communicator. Then the communicator defines the progress of the assembly cell based on the captured image data of products and worker hands, and distributes data models to the cobot and the assembly worker via mobile device.

The purpose of recognizing worker hands is to let the cobot detect the worker status within the shared workspace and decide the movement of products into the assembly cell. To do so, the images of the worker's hands and parts are first captured through the vision sensor.

3.3 Model Converter

The model converter extracts information from the process model and converts them to data models by using independent templates predefined. A process model is a reference model that clearly defines 4 M and related information of the manufacturing process, regarded as a meta-model to integrate the PM-HRC system. Independent templates, used for quick extraction of data models, can be defined as ‘skeleton without flesh and muscle’ in this paper. A template has a standard structure of data models without pre-defined parameters. The parameters containing information extracted from the process model complete the structure, which can be regarded as ‘flesh and muscle’. In short, the template (skeleton) derives the desired data model by mapping the parameters (flesh and muscle).

The model conversion methodology by using independent templates is shown in Fig. 6. The process model contains information on detailed production activities, and required resources as well as the number of parts. First, BOM is generated by combining information on parts flows and the number of parts required. The part flows and distribution of the number of parts are re-configured by considering collaboration between two objects, i.e., the worker and the cobot. BOM is used as a reference model for performing individual tasks and collaborative tasks. Table 1 shows an example of a BOM template, which include Level, Part ID, Part name, Quantity, and Unit. The information of the process model mapping to the template are part flows, part identification codes, the names of parts, the number of parts required, and part units. To build the BOM structure, the leveling of parts is important because the part level may represent brief precedence among parts. In the PM-HRC system, the BOM level is defined from the finished product to the initial parts in the processes based on the detail of activities in a top-down manner as shown in Fig. 7.

Fig. 6
figure 6

The independent template based model conversion

Full size image
Table 1 An example of the BOM template
Full size table
Fig. 7
figure 7

The leveling of BOM structure; An: nth activity (circle) and Pn: nth product (rectangle)

Full size image

Second, information on the part identification and sequence of activities are delivered to an assembly instruction template. Precautionary instructions are given to each part according to its identification. The worker can receive detailed information on the characteristics of the parts to be assembled and precautions for assembly operations via mobile devices. Table 2 shows an example of the assembly instruction template with data from predefined precaution and the process model.

Table 2 An example of the assembly instruction template
Full size table

Third, a control code model is generated to contain task control and scheduling information of the cobot. The template requires information on the part flows, the sequence of activities, and collaborative activities in the process model. Work instructions and corresponding information such as part delivery, tool changing and part recognition are delivered to the cobot for facilitating collaboration in assembly operations. The conversion algorithm to define a control code is illustrated in Fig. 8, consisting of three stages: data extraction, definition of the code template and parameters, and control code generation.

Fig. 8
figure 8

An algorithm for generating control codes for cobot

Full size image

Data extraction covers extraction and decomposition of activities including parts and tools data, and such information is utilized as parameters in the control code template. In the data extraction step, production activities have to be decomposed into a detail movement level in order to be mapped with code templates. In the code template and parameters definition, the minimum unit of action of the cobot and syntax of code for cobot movement is defined without parameters.

Table 3 shows an exemplary code template for a cobot. For example, the default requires parameters of a cobot position when the cobot is idle. Furthermore, the syntax of codes for the default action is defined in this step. The function of control code generation is to transform data extracted from the process model in compliance with the code template. When an activity is identified as a collaborative work then an IF phrase needs to be added to implement a virtual fence.

Table 3 An example of the cobot code template
Full size table

The algorithm configures the code structure based on the sequence of movement of the cobot. For example, if the cobot performs a bolting activity, predictable movements such as hand down, turning a bolt, and hand up can be decomposed from the bolting activity (refer to Fig. 9). The control codes for the bolting activity can be generated by using the code template, which includes decomposed activities (underlined), predefined parameters for cobot positions (italic), and data from the process model (bold) as illustrated in Fig. 9.

Fig. 9
figure 9

An exemplary generation of control codes

Full size image

The control codes generated by the algorithm, however, should be analyzed and verified before performing actual movements of the cobot. In this study, indirect mathematical verification of the control codes is performed by converting the process model into the Petri Net (PN) model. The PN model is known to have functions for structural and behavioral analysis such as reachability analysis and invariant analysis. The PN is a well-known modeling tool for system analysis, proven to be able to define manufacturing processes considering products and resources as well [31]. The representative advantage of PN is that it is easy to get mathematical representation of the model and analyze it by using structural and behavioral simulation. To analyze or verify the PM model a dynamic element, referred to as a token, is very useful [32]. The conversion algorithm to generate the verification model is illustrated in Fig. 10.

Fig. 10
figure 10

An algorithm for generating verification model in a form of PN

Full size image

To make the control codes data of activities, parts, and tools are required. For the transformation of collaborative activities for building up a PN model, the Marked Graph Building Block (MGBB) method [21] is applied in this research. Figure 11 shows PN elements for representing a collaborative activity based on MGBB concept. In the collaborative activities, transitions, places, and tokens indicate activities (actions), queues (states), and tools or parts required (currently being processed), respectively. As shown in Fig. 11, one collaborative activity can be represented with the nested PN block, where dummy places are added to meet constraints of the PN structure. Parts and tools are represented by the colored tokens.

Fig. 11
figure 11

PN elements to represent collaborative activities with colored tokens

Full size image

For example, if there are two different parts (e.g., PR and PB) in the same workplace then the positions of PR and PB can be represented by using the hatched token and the filled token, respectively. When the condition of each transition is met, the transition is fired, which means that the activity is finished, and tokens are moved to the next possible places.

4 Case Study

In the case study, object recognition, conversion of a process model and simulation for PM-HRC system are performed. The purpose of the case study is to verify the proposed PM-HRC system and to demonstrate the quick responsiveness of the system to the process change. In addition, adaptability of the system to the frequently changing demands in small-batch production is examined in a safe environment. The case study considers a PM-HRC system to make a plastic mold, which consists of typical machining and assembly processes with small batches. The main procedure to be done in this section is the followings:

  1. (1)

    Object recognition.

  2. (2)

    Conversion of a process model.

  3. (3)

    Operation of the PM-HRC system.

The function of object recognition is to detect worker hands and parts within the virtual fence and to define current working progress. Moreover, this function ensures the safety of the human operator by preventing the collision with the cobot. Conversion of a process model is a function to automatically generate BOM, assembly instructions, control codes for the cobot, and a verification model. The operational model of the PM-HRC system is implemented by using a simulation program. To verify responsibility of the PM-HRC system, codes generated manually and codes converted automatically from the process model are compared when the production order changes.

4.1 Object Recognition

Human safety is most important in the HRC system especially when there is no fixed safety fence. Because of the movement of the cobot in the assembly cell, there is a possibility that human hand may collide with the cobot, which causes injury to the assembly worker. Because the interaction point is in worker hands, hand detection is considered in this study. The most common gestures are selected for training the hand detection when the worker picks up a part as shown in Fig. 12. The result of detection is sent to the communicator to control the entry of the cobot into the assembly cell.

Fig. 12
figure 12

Four different possible gestures (approach, reach, hold and pick) to handle parts during assembly operations

Full size image

The BOM model is assumed to have five types of parts: core plate, upper plate, low base, ejector, and return pin. The robot collects all parts required to assemble the mold and delivers them to assembly workspace at once. Therefore, the first step is to recognize the model to move all parts required to the assembly workspace before assembly operations start, as shown in Fig. 13a. The model recognition is based on the identification of parts combination. In other words, different models have different combinations of parts. Figure 13b shows the results of part recognition during assembly operations to identify each part to be assembled according to the sequence of it. The assembly sequences are represented with step numbers as well as the part ID in the figure. The recognition of a single part is also important for the worker to identify the part required in each step and to avoid unnecessary part measurement or mistakes caused by wrong information. In this paper, plastic blocks are used to represent parts of a mold because of unavailability of the actual mold components.

Fig. 13
figure 13

a Model recognition results; b part recognition results

Full size image

We used the edge detection function provided by MATLAB 2018 for training and detecting hands and parts. Even though YOLO (You Only Look Once) [33] and Region-based Convolutional Neural Network (R-CNN) [34] are powerful and robust, and might be applied in this system, such models are too much heavy for our problem. Therefore, such models are proper to solve more complicated and large problems.

4.2 Conversion of a Process Model

In this study, a virtual mold-making processes are modeled following the method of PMPM [27], which originally consists of 6 notations for indicating processes and 10 notations for describing parts. However, only 6 notations are used in our study for the simplicity as in Table 4. Activity name, activity ID and resource ID are defined in notation of both normal and collaborative activity.

Table 4 The example notations of the PMPM
Full size table

The activity name is a description of the activity, and the activity ID (A0) is an identification to check the higher level activity. Resource ID indicates actor(s) and resources. For example, Wx (Ty) means that worker x performs a normal activity using tool y. A black shadow behind activity notation indicates the activity has detailed (decomposed) activities defined inside. Part start/beginning and end/termination have a part ID (ax) to identify and to trace part flows in addition to the assembly status.

The PMPM representation of mold-making processes are illustrated in Fig. 14. The first activity is a machining activity (A0) conducted by a cobot (w1) using a griping tool (t1) without any collaboration. Five parts including core plate (a1), upper plate (a2), low base (a3), ejector (a4), and return pin (a5) are delivered to the machining activity by the cobot. The cobot feeds parts to the assembly cell using the griping tool (t1). The cleaning, bolting, and fitting are collaborative activities with nested activities. Ejectors (a4) and return pins (a5) skip the cleaning and bolting activities. The finished mold (a0) can be acquired when the inspection activity is successfully done.

Fig. 14
figure 14

The artificial process of a mold assembly modeled on PMPM

Full size image

As mentioned before, the BOM can be generated from the PMPM model by re-allocating and re-configuring data according to the sequence of activities [35]. Figure 15 is an example of the BOM structure generated by using template information (Table 5) and PMPM (Fig. 14).

Fig. 15
figure 15

The BOM generated by using the template and PMPM

Full size image
Table 5 The BOM template with data from the PMPM in Fig. 14
Full size table

The assembly instruction for the bolting activity (D0) is represented in Fig. 16. Activity name, ID, type, subject, procedure, and part name can be filled by the BOM template. Part specification, precautions, and detail images are data from predefined precaution and the process model.

Fig. 16
figure 16

The assembly instruction for the bolting activity

Full size image

The assembly instruction with the result of part recognition are sent to the worker via mobile devices. Figure 17 shows the example of the control codes for the robot (w1) to change a tool and perform bolting a1 in activity D0. Bold characters in an example of control codes for the bolting activity are parameters defined in the PMPM. Because all operations and parameters required are not synchronized completely when the flows of activities or parts change, manual debugging is essential at of current state of the research. Verification of complex processes and various products is also required.

Fig. 17
figure 17

An example of control codes for the bolting activity

Full size image

Figure 18 depicts the PN model converted based on the proposed algorithm, and the result of invariant analysis for boundedness and liveness are shown in Fig. 19 to verify the control codes in Fig. 17.

Fig. 18
figure 18

The PN model converted for T3 bolting activity

Full size image
Fig. 19
figure 19

The result of invariant analysis of the PN model

Full size image

The results show that the PN model is proved to be live and bounded, which means the model is structured well and stable to use.

4.3 Operation of the PM-HRC

We have used a simulation tool, referred to as Visual Components 2014, to determine how effective the proposed PM-HRC system is in terms of changes in production requirements compared to a common HRC system. Comparison of modeling, programming, and execution times between two considerable scenarios are conducted with simulation models.

  1. (A)

    The common HRC system with manual programming for batch generation, task generation, and task allocation.

  2. (B)

    The PM-HRC system with manual process modeling and semi-automated programming for batch generation, task generation, and task allocation.

In the scenario of the PM-HRC system, time for manual modeling by using PMPM method is additionally needed, but the programming time can be reduced because some parts in the program are converted from the PMPM model compared to the scenario of the common HRC system. For example, the simulation codes are automatically generated based on the PMPM. However, parameters for parts and activities have to be synchronized between objects in the simulation by manually.

The PM-HRC system developed by using the simulation tool is shown in Fig. 20. An assembly, inspection, machining cells are defined as workplace objects, and one worker, one cobot and, four assembly tools are defined as resource objects. Furthermore, task and signal controllers are added to distribute and manage tasks. Operation codes for the simulation model are generated in eXtensible Markup Language (XML) format from the PMPM modeler (refer to Fig. 21).

Fig. 20
figure 20

The simulation model for the PM-HRC

Full size image
Fig. 21
figure 21

The PMPM modeler

Full size image

When the PM-HRC system is to be implemented in real domain, the BOM, generated by the PMPM modeler, is delivered to the worker as well as the cobot for supporting collaboration. However, the BOM is used as a batch generation code for feeding parts to workplace objects in the simulation model. The assembly instruction is unitized as the worker instruction codes. Table 6 shows the comparison results regarding average programming time after 10 times of simulation for scenarios (A) and (B). The times for process modeling and batch generation are for building the PMPM model and for generating part information, respectively in the simulation model. Task generation is to generate codes containing information of tasks performed by the worker and the cobot. Task allocation defines the sequence of tasks, the work tools, input/output parts, etc. The time for simulation execution means the time to complete all assembly activities for three batches.

Table 6 The experiments summary
Full size table

Total times of (A) and (B) are 65.02 and 41.83 min, respectively. This reveals the simulation model of the PM-HRC system is able to respond 35.7% faster than that of the common HRC system when a new demand arrives. Figure 22 shows (a) a total time graph per each test (total of 10 tests), (b) the graph indicating the cumulative sum of total time, and (c) and (d) are task generation and allocation times corresponding to the number of parts, respectively. Even though the total time for the common HRC decreases with an increasing number of tests as seen in Fig. 22a, it is always longer than that for the PM-HRC in the whole experiment. From this result, we can foresee that the total time in the common HRC system will increase when customer demands change. In contrast, the PM-HRC system can be in a stable state in spite of changes in customer demands. In the common HRC system, as shown in Fig. 22b, the ratios of task generation (TG) and task allocation (TA) are 48% and 43%, respectively, and sum of two ratios reaches 91% of the total time.

Fig. 22
figure 22

Comparison results between two scenarios

Full size image

However, the sum of ratios including TG and TA in the PM-HRC system decreased to 77%. Furthermore, Fig. 22c, d show that the programming time in the common HRC system increases rapidly as the number of parts increases in a batch. Therefore, the PM-HRC system is more effective in a small batch production when customer demands change frequently.

However, the complexity of the process model may lead to lower readability and cause other problems in model conversion. Currently, we confirmed that the generation of control codes and verification models were valid when we considered eight pieces of automated equipment, one cobot, and one worker to produce 14 products with 18 activities in the processes. However, additional experiments and verification are necessary in further researches to find possible limitations from model complexity, programming, and model conversion. Dealing with more activities such as in-process decision and rework activities also needs to be taken into account for further study.

5 Conclusion

In this research, we first considered the following issues occurred in small-batch production of MTO typed products while focusing on the assembly worker;

  • Ergonomics problems caused by repetitive tasks.

  • Assembly quality problems caused by inaccurate data.

  • Frequent changeover in product demands and process changes.

An HRC is one of the potential solutions to solve aforementioned problems. The main concern to implement the HRC system is human safety. To ensure the safety when the worker shares the workplace with the cobot, therefore, this study proposed a PM-HRC system including object recognition and the concept of a virtual fence. To tackle quality issues, caused by inaccurate data, in assembly operations, we proposed a concept of process model-based data integration. The object recognizer and the communicator in the PM-HRC system provide reliable and valid assembly data to the worker at appropriate assembly procedures. The PM-HRC system obtains an additional solution for the production and process changeover. The process model immediately creates assembly instructions, BOM, robot control codes, and verification models by mapping independent templates with predefined algorithms. This makes the system promptly respond to frequent changes in product demands and processes. We conducted comparative analysis of the PM-HRC system with the common HRC system by using simulation models. From the results, we can conclude that the PM-HRC system has better performance than the common HRC system with regards to task generation and task allocation time.

There are still deficiencies regarding consideration of process complexity, manual debugging, and manual parameter synchronization. Therefore, further researches are necessary for the construction of robust control codes and for the synchronization of parameters. Limitations on the model conversion when the model includes complex processes and products should be properly addressed in further researches as well.