Development process of the

Objective of the subproject

Strictly speaking, the goal of this SB 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 submodels. 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 Asset Administration 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.

SP 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 Asset Administration Shell submodels
• 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 Asset Administration Shell of a wire harness can be compared with the Asset Administration Shell of the relevant factories.

A generic architecture model also needs to be generated to illustrate how the Asset Administration Shell of various 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 an Asset Administration 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 Asset Administration 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 subprocess 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 Asset Administration 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.

Expected results

One of the biggest challenges is to implement the development processes within SP 2. It is true that the project team is already investigating what a single Asset Administration 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 ‘Asset Administration Shell submodels’ 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.