Introduction

“Joining Process” is a generic container aimed at encapsulating various types of process definitions needed in a joining system. It ranges from a “simple joining program” to a “complex joining process with sub-processes”.

Each such joining process should be able to generate corresponding results.

Example – Single Processes:

In this scenario, it provides the possibility to send or receive the joining processes from a joining system and execute the joining processes. The outcome of the executed processes will be represented as Results.

Example – Combined Processes:

In this scenario, a Joining process describes what should be done on a particular level of the system. It should have the capability to delegate sub-processes to controllers that can perform the joining operation without connectivity (Example: Radio shadow). When the connection is reestablished, the controllers report the corresponding results to the primary controller which combines the various results and reports the total result.

Note:

• This specification does not define the content of joining process(es). It is assumed that the joining process is retrieved from the joining system or created using another system such as a configuration application.
• This specification describes how a joining process is managed i.e., sending, and receiving a joining process.

Types of Joining Processes

Joining Processes can be classified in two different ways as given below.

• “Joining program” is an atomic process to perform a joining operation.
• “Combined process” is a group of joining processes to perform combination of various sub-processes.

Joining program is the lowest level of description to perform a specific joint where it is autonomously managed by the system.

Example: It is executed from the trigger press until the joining operation is completed.

A “single result” is generated for each execution of a joining program.

On the most abstract level, everything, except the atomic process, is just grouping operations together in different ways in many different layers when assembling a product. This requires a flexible model for different customer needs with respect to process control.

A combined process can be any of the following:

• A “Job” is a collection of sub-processes which could also include a sub-job.
• A “Batch Process” is a “Job” where all the operations are atomic and use the same joining program, and the operations are executed sequentially.
• Example: The process of sequential assembly of two or more joints using the same program.
• A “Synchronized Process (Sync)” is a “Job” where all the operations are executed in parallel by separate tools (spindles).
• Example: In a fixtured system which consists of multiple spindles, the PLC sends a synchronized process to the Joining Process Controller to manage which spindles should run. When the execution is completed, then a combined result is sent back to the PLC.
• A “Stitching Process” is a “Job” where several “Synchronized Processes” are done in a sequence.

Joining Process and Result Mapping

A result is mapped to a corresponding joining process. Figure 22 describes following examples.

• Examples:
• Result (Single) is mapped to a Joining Program.
• Result (Batch) is mapped to a Joining Batch.
• Result (Job) is mapped to a Joining Job.

Figure 22 – Joining Process and Result Model Mapping

Joining Process Use Cases

The following are few use cases which describes various types of jobs in a joining system.

Note: Quality Process and Vision process are not defined in this specification. The purpose of the below examples is to describe the flexible usage of the joining process model and result model which covers various combination of processes and corresponding outcome from different domains.

Imagine a station in a car manufacturing plant.

• On the left side of the car,
• a few joints need to be performed with the Joining Tool.
• the outcome should be validated with a wrench.
• On the right side,
• another batch of joints need be performed.
• the outcome should be validated by a wrench.
• the outcome should be validated by a vision system.
• The left and right side of the car should be handled by two different operators independently in parallel.
• The operators can occasionally enter radio shadow but should still be able to carry out their tasks.
• The MES want to control the station as one unit and get the total result when all is done. 

Figure 23 describes an example “Combined Process” (Job 1) with the following sub-processes.

• A “batch” joining process for joining two fasteners. (Batch 1)
• A “quality” process to validate the outcome. (Quality Process 1)
• A nested “joining process” (Job 2) with
• a “batch” of three joining operations. (Batch 2)
• a “quality” process. (Quality Process 2)
• a “vision” process. (Vision Process)

• “Combined Process” (Job 1) is done when all the sub-processes (Batch 1, Quality Process 1, Job 2) are done.
• “Combined Process” (Job 2) is done when all the sub-processes (Batch 2, Quality Process 2, Vision Process) are done.

Figure 23 describes the outcome from the “Combined Process” (Job 1) execution. The outcome is sent as a total result (Job Result) to the MES system.

Figure 23 – Joining Process and Result Model Mapping Example

Imagine a plant with an automated assembly line, which is directed by an MES (Manufacturing Execution System) and operated by line/cell controllers (PLCs). The joining system is controlled by a PLC.

The MES directs the joining process of individual joints via PLCs, but the handling of results.

• is limited via traditional communication channels, like fieldbus networks.
• relies on propriety data channels that require different implementations depending on the manufacturer.

This use case can be applicable for the following communication setup:

• Joining system with OPC UA and fieldbus interfaces.
• Joining system with only OPC UA.

OPC UA interface and optionally an existing fieldbus network.

• The MES controls the flow of parts via
• OPC UA
• PLCs and their fieldbus interfaces (if available)
• The MES/PLC sends the product/part identification (e.g. VIN), joining program and start signal via
• OPC UA
• Fieldbus
• The joining system performs the joining operation.
• The MES systems receive the (extensive) joining result via OPC UA, including the joint identification.

The result received by the MES contains the following:

• the simple result one would expect from a fieldbus interface.
• the extensive result, containing optionally individual step results and/or trace data representing the whole joining process.
• the product/part identification, allowing the MES to relate a set of results to specific parts and/or the individual joint.

Furthermore, the result is delivered in a standardized way, which is shared by different manufacturers.