Production process of the

wiring harness

Analysis of the wiring harness production, for the integration of a digital twin.

Contact

Dr. Salinas Segura

Lisa Dräxlmaier GmbH

Mr Salinas is Digital Transformation Specialist

Wiring harness production process

Development of an implementation concept for the integration of the digital twin into the value chain.

Automation and digitization are the two magic words that make the value chain fit for the future. One prerequisite for this is that the players involved in the value chain work together, sharing their data in a standardized way. The Asset Administration Shell concept is a promising approach to this. However, it cannot be grafted on anywhere, but requires painstaking detail work. An infinite amount of data must be collected, semantically described, and translated into data models that everyone in the value chain can use. And: Processes that have been carried out manually up to now have to be transferred into machine-compatible procedures. The only thing that is certain is that the wiring harness will always consist of cables, and it will always have many connectors.

The production of the wiring harness is the core business of the harness makers: The harness maker receives the cable drums, machines cut the cables to the appropriate lengths, and assemble connecting elements. In terms of the individual wire, the process runs fully automatically. All downstream processes are essentially manual, such as the assembly of the wiring harnesses - strand by strand. However, the production processes of the wiring harness comprise much more. For example, the preliminary products come from the wiring harness suppliers and the component manufacturers. The value chain extends from the OEM, who defines the specifications, to the producers of the automation systems and the tools.

Objectives of the subproject

This subproject (SP) involves analysing and defining processes down to the last detail and deriving the data requirements. In detail, it involves the following process steps:

  • Providing the engineering data
  • Matching the production resources
  • Controlling the production processes
  • Acquisition of production data

An example: What processes lead to a wire being connected to the contact? The steps of cutting, stripping, crimping, plugging are needed for this task. Or another example: To carry out the ultrasonic welding process step, the number of conductors and the welding specifics must be known. Each processing step must be documented. This includes input as well as output parameters. The focus is on questions such as: Which processes have been carried out and how? Have they been carried out successfully? Is the result OK? Is the quality really assured and comprehensibly documented for each individual production step? The planning goal is to determine the necessary data for the individual stations on the production side and to make them available in an interoperable or automated manner.

Work priorities

The main task is to analyse the current state. Another priority is to formulate the requirements for cross-company and digitalised production process of the wire harness. These requirements should then flow into the production process and thus ensure that the process itself is optimised and partial models for the Asset Administration Shell are developed. After all product and process data have been collected at the end, the production and product Asset Administration Shell s can also be merged for the first time. Ideally, with the help of metadata, a kind of ‘data dictionary’ can be developed that can be used over the entire wire harness life cycle. This leads to increased traceability and resilience within the supply chain.

Further focus areas are:

  • Integration of CAD data from the process and the Bill of Material (BOM)
  • Process description (Bill of Process, or BOP)
  • Connection and integration of the corresponding IT systems based on a PPR data model (product – process – resource)

SP 3 contains five work packages:

  • WP3.1 Analysis of requirements
  • WP3.2 Design of a reference model
  • WP3.3 Exploration of submodels for feedback data
  • WP3.4 Proof of concept
  • WP3.5 Validation of the principles

Work status

SP3.1 Analysis of requirements

The definition of the requirements resulted in more than 90 requirements, which were compiled in a list. The goal was to identify where the biggest problem areas currently are and how they can be solved by implementing a standardised digital twin. Ultimately, for the area of production processes, it is about providing the necessary information for the execution of production processes so that machines can start the processes in an interoperable and automated manner.

Moreover, with regard to the collection of requirements, a distinction was made as to whether the requirements need to be assigned to a process that is currently still taking place manually or whether it is already an automated process. Since all 90 requirements cannot be integrated, it must also be decided which are absolutely indispensable and which would simply be a possible, but not absolutely necessary, addition.

Currently, the project team is focusing on work packages 3.2 and 3.3.

SP3.2 Design of a reference model

In essence, it is about defining the interaction between Asset Administration Shell s, process steps in production and the heterogeneous IT landscapes. There are several possibilities: On the one hand, the Asset Administration Shell can be represented by the asset. This would then be an individual object, such as a wire or composite component. However, the Asset Administration Shell can also consist of an entire factory with the available machines and their capacities, which in turn also have a Asset Administration Shell . Figuratively speaking, this would be a kind of onion principle, because smaller Asset Administration Shell s are layered on top of each other, which then jointly contain the data of the factory.

Furthermore, the question of where the Asset Administration Shell is placed in the respective IT landscapes of the companies and how a Asset Administration Shell can be implemented in the life cycle of an asset is examined. The data streams at the stakeholders, for example at the manufacturers of the components and at the OEM, provide information about which data must be provided and how they can be linked with the data landscapes (MES, PLM, ERP) of the stakeholders. Many other systems can also play a role, especially in the heterogeneous IT system landscape of the stakeholders. The team came to the realisation that the IT landscape cannot be regarded as a blackbox, as originally planned. One thing is clear. A connecting point is needed because of the differences in the IT system landscapes. The idea is to insert a ‘data virtualisation layer’, which accesses and provides the data from the Asset Administration Shell . It also reads the company-related data from PLM, MES and ERP and makes it available. It is also important to clarify which requirements can be derived from it for the Asset Administration Shell itself.

SP3.3 Exploration of submodels for feedback data

WP3.3 is still partly in progress. In order to look at the production processes, the procedures on the machines were broken down to the individual operations, such as cutting a cable. Generally important features in cable cutting include the target and actual length of the cable, what input data is necessary in this case, and what output data is generated. This turned into a list that was continuously refined until it became a class diagram, which is now finished. Initial results show that a very large number of input and output parameters are needed. The resource, i.e. the machine on which the production was carried out, also plays a key role in the production process. Furthermore, additional information about the components must flow in from the peripheral equipment. In crimping, for example, information about the plug is needed. This makes it clear that access to the product Asset Administration Shell must also be possible at this point.

Ultimately, the goal is an information model that contains machine language. After all, semantic elements are indispensable if machines are to talk to each other in the future. These semantic elements can be stored in an information model so that it becomes clear what exactly is meant by an ‘actual length’ and much more.

Next steps

Next is the processing of SP 3.4/3.5.

SP3.4 Proof of concept: this is the first implementation of a digital twin.

SP3.5 Validation of the principles: the objective is to check whether the assumptions were correct and how the results can be interpreted. This all involves a lot of documentation.