Sub-

Objectives of the sub-project

This sub-project 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 management shell are developed. After all product and process data have been collected at the end, the production and product management shells 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)

Sub-project 3 contains five work packages:

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

Work status

WP3.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.

WP3.2 Design of a reference model

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

Furthermore, the question of where the management shell is placed in the respective IT landscapes of the companies and how a management 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 management 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 management shell itself.

WP3.3 Exploration of sub-models 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 management 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 work packages 3.4/3.5.

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

WP3.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.