Sub-

project 2

Development processes of the wire harness

Contact

Michael Buchta

Kromberg und Schubert GmbH

Mr Buchta is the head of technology und research management

The development process is considered to be the ‘cradle’ of the digital twin. The development of engines, for example, has only really taken off with the digital twin. Whereas a few thousand parameters were sufficient for engine development a few years ago, today there are several million that are mapped in the digital twin. The first data for the wire harness are also usually generated here, and they are increasingly expanded throughout the individual stages of the value chain. Sub-project 2 is concerned with transferring the procedures of the development process for the wire harness to the management shell. It explores cross-company data concepts and examines how collaborative development of the wire harness product can be implemented.

A characteristic feature of the wire harness is that each cable harness is unique. It is produced in batch size 1 and therefore bears the designation ‘custom wire harness’ (CWH). Because of the large number of variants, very little is automated and much of it is handmade. This is also reflected in the data exchange. This is supposed to change. The foundation for automation of the subsequent process steps all the way up to assembly can already be laid in the development phase. Sub-project 2 identifies the possibilities with which the subsequent production of the wire harness can be largely automated. It goes down to the level of work instructions for man and machine, the set-up procedures, recording of process and quality data, necessary skills and documentation. The trick here is to put together the various individual pieces of the mosaic, including from sub-projects 3 (production) and 4 (assembly), in such a way that they all add up to a robust single entity that all stakeholders want to work with.

Objective of the sub-project

Strictly speaking, the goal of this sub-project is to follow each individual step with a magnifying glass in order to describe the processes that take place in development. Necessary data from this project will be derived, described and implemented in sub-models. Subsequently, the results will be incorporated into an implementation concept that shows how the digital twin can be realised in the development of the wire harness.

Work priorities

Since engineering processes in the automotive industry are fundamentally collaborative, it must also be possible for the management shell to be created in a distributed manner and ultimately assembled. The engineering process already takes place digitally to a large extent.

However, dealing with the diversity of formats is a challenging task. It requires figuring out what data is collected, stored, passed on and how? In the reality of cable harness development, for example, you have circuit diagrams, cable harness lists, CAD formats. There are also many suppliers for a part or a component. The suppliers in turn have suppliers for plugs, grommets, sheathing, brackets, special cables. Therefore, it already takes an enormous amount of planning in the development phase, especially since changes have to be constantly taken into account.

Sub-project 2 is divided into five work packages:

  • WP2.1 Concept of collaborative data model
  • WP2.2 Single Point of Truth
  • WP2.3 Process description of wire harness development
  • WP2.4 Management shell sub-models
  • WP2.5 Digital twin implementation

Development of a generic process model

The capacities of the future production systems should be considered as early as the engineering stage so that, for example, the management shells of a wire harness can be compared with the management shells of the relevant factories.

A generic architecture model also needs to be generated to illustrate how the various management shells of the different IT systems can be linked.

Work status

Work package 2.1 Concept of collaborative data model:

The objective of this work package is to develop a data model that will enable different value creation participants to work together on one and the same product. Furthermore, the concept of the collaborative data model considers how the digital twin can be represented along the value chain. Data comes from many different stakeholders. It must be possible to receive and deliver this data in a standardised format. A prerequisite is that the information is machine-readable and does not contain free text – as in older file formats. The result should then be a management shell that contains data formats that are customary in the industry: KBL, VEC, JT, STEP. The Eclipse Dataspace Connector (EDC) is intended for cross-company data exchange because it offers uniform access control and management. The EDC makes it possible for data packages to be exchanged between the individual value chain partners and, for example, negotiate digital contracts. Ultimately, all participants should be able to use the data depending on their role or access allocation, giving users the authorisation to read, change or delete the data depending on what they need to implement a process.

Work package 2.2 Single Point of Truth:

This work package is dedicated to the question of who has the final truth for all intents and purposes in their data set. What is meant is a generally valid data set that can be relied upon and that is so correct as a source that all connected systems can be served from it. In the application case of the wire harness, this means: The specifications must always be the same for all suppliers, the processors and the OEM. It must be clear at all times where the latest data set of a specification is stored. This is especially true for the decentralised storage of data, which is supposed to be realised with the implementation of the management shell and the EDC. This does not require huge data dumps on which all the information is piled up. Instead, the idea is to store part of the information with the respective manufacturer (assembler, OEM) and then link it accordingly.

Work package 2.3 Process description of wire harness development

The third work package is the most extensive, because most of the data must be collected here. The first thing to do here is to define the typical processes in the development phase. A particular challenge is that each OEM likes to have its own tool landscape that is tailored to its internal processes. This can be their own cable colours for cables that are not covered by a DIN standard in terms of colour. The big task now is: Each individual process step must be analysed and divided into sub-process steps. It must be clarified what the input data requirements are and what output data is generated in each step. It must be possible to store specifications, such as the target data, in the management shell and to read the actual data there. Generally speaking, this should work with the usual data formats, such as CAD, KBL or VEC. However, the discussion goes beyond this objective if we take a look into the future and ask: What data formats will we use in the future?

Work packages 2.4 and 2.5 are still being worked on.

Next steps

One of the biggest challenges is to implement the development processes within sub-project 2. It is true that the project team is already investigating what a single management shell could look like. Nevertheless, they encounter quantities of data silos along the way that are optimised for their respective purposes but lack the connection to overarching modes of representation. This becomes particularly difficult when it comes to production. In other words, with the help of the digital twin, information is not only stored after development, but rather at the moment when components are actually produced. For example, the minimum and maximum crimping force must be defined, which is then compared with the actual value – namely with which force the contact was actually crimped in production. Such correlations can be described with software tools, some of which already exist.

The next specific steps will be to define the process for the wire harness development and to define a collaboration model for the development process. After that, the next step will be the partial models, which are currently being prepared: Work packages 2.4 ‘Management shell sub-models’ and 2.5 ‘Digital twin implementation’ have not been initiated yet, but should be ready by mid-2024.

As another aspect of the engineering process, the ‘design-to-cost’ factor as well as the fulfilment of ecological sustainability criteria must be taken into account. This specifically involves assessments and decision-making criteria, for example in the selection of materials, such as recycled materials.