VDA Automatic Data Exchange 5600 of Product- and Metadata between OEM and Supplier PLM ... ·...

VDA Automatic Data Exchange of Product- and Metadata

between OEM and Supplier PLM Systems

5600

Abstract

The today’s data exchange of assemblies between OEM and supplier is usually characterized by many manual steps to prepare the data before sending and to process the data after receiving. The established as-is exchange typically synchronizes data only from the sender hard disc to the receiver hard disc without any interaction to the PLM systems of sender and receiver. The subsequent import of the (CAD-) data into the PLM systems today is performed manually, as well as the supplementation of required additional metadata.

Due to the fact of the constantly rising amount of transferred data and shortened update cycles, new concepts for automated data processing are needed. In addition the data quality and process reliability benefits from automatic data processing.

Collaboration between companies is currently being obstructed by uncoordinated processes or processes not optimized for a seamless automated data exchange.

The PLM2PLM group has defined three major use cases as the basis for coordinated processes in data exchange between OEM and suppliers. To avoid segmentation, caused by different customer specific requirements for the data exchange, this paper highlights general data exchange requirements for processes and systems.

version July 2016

Project group „PLM2PLM“ of VDA

Publisher: Verband der Automobilindustrie e. V. (VDA) Copyright Behrenstr. 35 Reprinting, even of sections, only possible 10117 Berlin with the approval of the publisher Tel +49 (30) 897842 -0 Fax +49 (30) 897842 -600 Mail: [email protected] Internet: www.vda.de

VDA Recommendation 5600

Automatic Data Exchange of Product- and Metadata between OEM and Supplier PLM Systems 2

Content

1 Introduction ............................................................................................................. 4

1.1 Scope and purpose .................................................................................................. 4

2 Considered data exchange scenarios ..................................................................... 4

3 Use Case description .............................................................................................. 5

3.1 Use Case 1a: Start of design process - Initial communication between supplier and OEM .............................................................................................................................. 5

3.1.1 Aim ...................................................................................................................................... 5

3.1.2 Description .......................................................................................................................... 5

3.1.3 Post conditions ................................................................................................................... 6

3.1.4 Diagram .............................................................................................................................. 6

3.2 Use Case 1b: Initial load of OEM data in supplier PDM system ............................ 6

3.2.1 Aim ...................................................................................................................................... 6

3.2.2 Actors .................................................................................................................................. 6

3.2.3 Preconditions ...................................................................................................................... 7

3.2.4 Description .......................................................................................................................... 7

3.2.5 Alternatives ......................................................................................................................... 7

3.2.6 Post conditions ................................................................................................................... 7

3.2.7 Diagram .............................................................................................................................. 7

3.2.8 Benefits ............................................................................................................................... 7

3.2.9 Notes .................................................................................................................................. 8

3.3 UC2: Continous Update Cycle ................................................................................. 8

3.3.1 Aim ...................................................................................................................................... 8

3.3.2 Actors .................................................................................................................................. 8

3.3.3 Preconditions ...................................................................................................................... 8

3.3.4 Description .......................................................................................................................... 8

3.3.5 Alternatives ......................................................................................................................... 9

3.3.6 Post conditions ................................................................................................................... 9

3.3.7 Diagram ............................................................................................................................ 10

3.3.8 Benefits ............................................................................................................................. 10

3.3.9 Notes ................................................................................................................................ 11

3.4 UC3: Update Design Context ................................................................................. 11

3.4.1 Aim .................................................................................................................................... 11

3.4.2 Actors ................................................................................................................................ 12

3.4.3 Preconditions .................................................................................................................... 12

3.4.4 Description ........................................................................................................................ 12

3.4.5 Alternatives ....................................................................................................................... 12

3.4.6 Post conditions ................................................................................................................. 12

3.4.7 Diagram ............................................................................................................................ 12

3.4.8 Benefits ............................................................................................................................. 13

3.4.9 Notes ................................................................................................................................ 13

4 Requirements ........................................................................................................ 14

5 Summary ............................................................................................................... 15



Figures

Figure 1: Diagram of as-is UC1a .............................................................................................. 6

Figure 2: Diagram of as-is UC1b .............................................................................................. 7

Figure 3: Diagram of UC1b benefits ......................................................................................... 8

Figure 4: Diagram of as-is UC2 .............................................................................................. 10

Figure 5: Detail of as-is UC2 step "Create Data Package" ...................................................... 10

Figure 6: Detail of as-is UC2 step "Import PDM Data" ............................................................ 10

Figure 7: Diagram of UC2 benefits ......................................................................................... 11

Figure 8: Diagram of as-is UC3 .............................................................................................. 13

Figure 9: Diagram of UC3 benefits ......................................................................................... 13

Abbreviations, References

Term Explanation

OEM Original Equipment Manufacturer

Supplier Delivers assemblies as a part of the OEM product

PDM Implementor Forum Group of the ProStep i.V.i.P. organization

PDM-IF short for: Implementor Forum

Meta data Information describing parts and assemblies and their attributes

UC Short for: Use Case

Definitions

Term Definition

PDM Data PDM Data is the information describing a part or an assembly, it consists of meta data and corresponding CAD Data

Data Package Data package is a bundle of information. The package contains different types of data.

PDM Data Package PDM Data Package is a bundle of information. The package contains at least PDM Data (metadata and corresponding CAD Data).



1 Introduction

The today’s data exchange of assemblies between OEM and supplier is usually characterized by many manual steps to prepare the data before sending and to process the data after receiving. The automatic data exchange typically synchronizes data from the sender hard disc to the receiver hard disc without any interaction between the PLM systems of sender and receiver.

This paper defines use cases and requirements for the automatic data exchange between supplier and OEM. The data exchange covers not only the CAD data. To enable automatic imports into the PDM systems and to detect new, revised, updated and obsolete parts, it is essential to enable a metadata-based change of PDM data.

1.1 Scope and purpose

The project‘s goal is to develop use cases and recommendations for data exchange between OEMs and suppliers. However it does not want to create a new data exchange standard, but use already existing standards like STEP AP242.

The project PLM2PLM has elaborated requirements based on specific use case scenarios, defined in the next chapter. These use cases will be forwarded to the PDM Implementor Forum (PDM-IF) of the ProSTEP i.V.i.P. association. The PDM-IF shall discuss the presented requirements and elaborate implementations, develop prototypes and validate the practical usage. The PDM-IF consists of OEMs, 1st tier suppliers and PLM software vendors.

Expected benefits for OEM and supplier:

Definition of a common methodology for the automated data exchange between both parties

Flexible and sustainable methodology to adapt the data exchange

Reduction of manual steps in data exchange processes

High level of data quality resulting out of the reduction of manual steps

Reduction of time required to perform a data exchange job thanks to automated mapping of data

Usage of existing standards and recommendations

Usage of a neutral format and schema to describe the structure and meta data infor-mation of assemblies with reference to geometry information and other documents

Reliable automated differentiation of new/revised/obsolete parts as the basis for traceability and delta data exchange

Expected benefits for PLM software vendors:

Increased investment security for the developed products based on this recommenda-tion

Possibility to provide common data exchange solutions instead of specialized customer solutions

2 Considered data exchange scenarios

Data exchange scenarios considered in this document cover the main processes to handover data between automotive supplier and OEM and vice versa. The scenarios are divided in use cases reflecting different data exchange scenarios in the product development process.



Every use case describes in detail the exchange of parts and/or assemblies within the process of product development and manufacturing. The metadata connected with these (CAD-) parts and -assemblies is of high importance for ordering, filtering and managing the data. Until now only a minimum of metadata is transferred with the CAD files. This metadata is often transferred as a part of the CAD filename. Based on this, the metadata information is maintained manually in the supplier PLM system as well as in the OEM system, e.g. by resident engineers. This practice is time consuming, inconsistent and fault prone. In addition only a limited set of metadata can be coded inside a filename.

Furthermore, the number of data exchange cycles as well as its load is constantly rising. To be able to handle this increase, a higher level of automation is necessary. Based on an automated data exchange process the number of user-caused faults can be reduced. This way the whole process becomes more secure and reliable.

The automotive suppliers wish to agree on a standard procedure for the transfer and import of metadata. This standard procedure shall assure the automated import of at least the part name, the part number and the revision into systems at supplier and OEM.

It is assumed to take over the structure delivered by the OEM as it is. The use cases do not describe concepts for restructuring of exchanged structures between OEM and supplier.

The described data exchange scenarios cover the initial transfer and the update of already exchanged data. It is not this document’s purpose to define a cross company change management, but it should support such concepts by establishing an automated PDM data exchange.

3 Use Case description

3.1 Use Case 1a: Start of design process - Initial communication between supplier and OEM

3.1.1 Aim

This use case describes the initial communication in the design process of a new part involving both, the OEM and the Supplier.

3.1.2 Description

The process covered by this use case usually completely differs for each OEM and it bears numerous variations. It can involve digitalized PLM data from the very beginning or consist of handwritten and unmanaged documents and drawings.

Due to this reason the PLM2PLM project group does not consider UC1a within the scope of automatic data exchange improvement. The UC1a is listed here only to provide the completeness of data exchange scenarios.

No Name Description of Process Step Owner

UC1a-1 Info New Project OEM informs the supplier(s) about the start of a new project.

OEM

UC1a-2 Create Data Package

OEM creates initial data package defining ideas, design wishes, requirements and more. This package can contain documents of any kind and quality. Often no PDM data exists on OEM side which can be provided to the supplier.

OEM

UC1a-3 Receive Data Package

Supplier receives the package via data exchange tool. Package will be analyzed and processed manually and individually.

Supplier



UC1a-4 Create Design Supplier creates a design considering the received data. This can be complete new design information or the reuse and/or modification of already existing design information.

Supplier

UC1a-5 Create PDM Data Based on the created / modified design PDM data is typically created in the supplier PDM system. This data must not contain OEM specific information.

Supplier

UC1a-6 Freeze Data Supplier freezes the created design and PDM data (if created) in its own systems to be able to deliver this state to the OEM as an answer to the request.

Supplier

UC1a-7 Create Data Package

Supplier creates data package containing the created and freezes design and the respective PDM data.

Supplier

UC1a-8 Design OK? After receiving the supplier’s answer the OEM analyses design and decide about the fulfillment of expectations.

TRUE: UC1a-9 is next step

FALSE: back to UC1a-2 (New or updated requirements will be send to supplier)

A notification with feedback for the supplier should be send, if the processing of the received data failed on OEM side.

OEM

UC1a-9 Create PDM Data PDM data is created on OEM side and UC1b will be used in the data exchange scenario.

OEM

3.1.3 Post conditions

Followed by UC1b, if delivered design is OK.

3.1.4 Diagram

Figure 1: Diagram of as-is UC1a

3.2 Use Case 1b: Initial load of OEM data in supplier PDM system

3.2.1 Aim

This use case describes the initial transfer of a single part or an assembly from OEM to the supplier and the initial load into the supplier’s PDM system. It is desired that the initial mapping is performed as automated as possible.

3.2.2 Actors

OEM

Supplier



3.2.3 Preconditions

The OEM part or assembly does not exist in the supplier system. Particular subparts or subassemblies can already exist in the supplier system.

3.2.4 Description

After finishing the initial design process (see UC1a) the OEM delivers all information including design context to identify the new part or assembly uniquely in its own system. This PDM data has to be integrated into the supplier’s PDM system. To transfer the geometrical information the native CAD data or one of the neutral standards JT or STEP are used.


UC1b-1 Info: Created After creating the PDM data in OEM’s system the OEM informs the supplier that new PDM data for the project has been created. The PDM data should include ownership information highlighting which data is not allowed to modify and which data can / should be modified.

OEM

UC1b-2 Download Data The supplier downloads CAD data and metadata (“PDM data”) from OEM system.

Supplier

UC1b-3 Receive Data PDM data is transferred to supplier system.

A notification with feedback for the OEM should be send, if the processing of the received data failed on supplier side.

Supplier

UC1b-4 Import Data The received PDM data is imported into supplier PDM system.

Supplier

3.2.5 Alternatives

No alternatives.


No post conditions.

3.2.7 Diagram

Figure 2: Diagram of as-is UC1b

3.2.8 Benefits

The expected improvements would result from optimizing step “UC1b-4 – Import Data” as shown in Figure 3. In today’s practice this step is characterized by a high level of manual work



and missing metadata information. A higher level of automation will ensure data consistency and lead to a faster and less fault prone data exchange.

To achieve these benefits the following conditions have to be fulfilled:

The OEM shall use either STEP or JT to describe the metadata for the data transfer

The OEM shall ensure the availability of file name, part number and revision as distinct metadata attributes.

The OEM shall include ownership information in the PDM data, highlighting which data is not allowed to modify and which data can / should be modified.

The supplier has to assure that all existing structures within his system also provide the mentioned attributes in terms of being able to perform the required mapping.

The supplier should provide notification methods so that in case of failure during the import process there is the possibility to react and ideally fix the failed import.

Figure 3: Diagram of UC1b benefits

3.2.9 Notes

No additional notes.

3.3 UC2: Continous Update Cycle

3.3.1 Aim

This use case describes the continuous update cycle of already exchanged data. Updates on existing data are performed by the supplier and will be delivered to the OEM.

3.3.2 Actors

OEM

Supplier

3.3.3 Preconditions

The data already exists in the supplier system and an update of this data is available.

3.3.4 Description

The supplier updates his own data. A new revision of an existing part is created and processed internally. Afterwards the new revision is sent to the OEM and imported into the OEM’s systems. On OEM side, the data will be evaluated and the result will be sent back to the supplier and imported into his system.




UC2-1 Create Revision Supplier creates revision of part or assemblies and updated the necessary information to fulfill the OEM requirements for the new revision.

Supplier

UC2-2 Freeze Data The new revision will be frozen in supplier PDM system to be able to send it to the OEM.

Supplier

UC2-3 Create Package A new data package containing the updated revision is created.

Supplier

UC2-4 Send Package Supplier sends the package to OEM. Supplier

UC2-5 Receive Package PDM data is transferred to OEM system.

A notification with feedback for the supplier should be sent, if the processing of the received data failed on OEM side.

OEM

UC2-6 Import Data The received data is analyzed and imported into OEM system. This activity can be done by the supplier (resident engineer) or by the OEM.

OEM/Supplier

UC2-7 Freeze Data After analyzing, the OEM freezes the data in its system to create a new release.

OEM

UC2-8 Download Release Level

The release information is sent to the supplier. OEM

UC2-9 Import Data The received release information is imported into supplier system.

A notification with feedback for the OEM should be sent, if the processing of the received data failed on supplier side.

Supplier

UC2-10 Freeze Data The supplier also freezes the data based on the given release information.

Supplier

3.3.5 Alternatives

The revision contains a new sub part which does not exist in OEM PLM system yet. In this case we use UC1b to exchange the new sub part. In UC1b the new sub part is first created in OEM PLM system and afterwards transferred to the supplier in order to create the relation between the new supplier sub part and the OEM part.


No post conditions.



3.3.7 Diagram

Figure 4: Diagram of as-is UC2

Figure 5: Detail of as-is UC2 step "Create Data Package"

Figure 6: Detail of as-is UC2 step "Import PDM Data"

3.3.8 Benefits

To have a better view of the expected improvements a detailed view inside the steps “UC2-3 - Create Package” and “UC2-9 – Import Data” is shown in Figure 7.



Figure 7: Diagram of UC2 benefits

Expected benefits of step “UC2-9 – Import Data”

Supplier part names and revision information should be automatically mapped to OEM part names and revision information based on data stored in the supplier PDM system

Supplier metadata (relevant attributes) should be automatically mapped to OEM metadata

Today’s manual OEM specific activities should be replaced by an automated and unified process to provide PDM data to partners

Data Package sent to OEM should contain OEM metadata and corresponding CAD data

Expected benefits of step “UC2-3 - Create Package”

QChecker is used twice today, on supplier side during export and on OEM side during import. Should be used only once, e.g. only on supplier side, during import on OEM side the process will trust already checked data.

Data Package received from supplier should contain OEM metadata and correspond-ing CAD data

The OEM shall include ownership information in the PDM data, highlighting which data is not allowed to modify and which data can / should be modified.

Data received from the supplier should be automatically imported into OEM system. Resident engineers should only check the imported data for correctness.

Metadata is updated automatically in the system of the OEM because it is delivered in a processible format.

Today’s manual OEM specific activities should be replaced by an automatic and unified import process of PDM data in OEM systems

3.3.9 Notes


3.4 UC3: Update Design Context

3.4.1 Aim

This use case describes the data exchange of updates in the OEM design context (successive cycles). This requires an initial transfer according to UC1. It includes the upload/import of data, which has been updated by the OEM, to supplier system.



3.4.2 Actors

OEM

Supplier

3.4.3 Preconditions

Design context was already transferred and imported to supplier system according UC1b.

3.4.4 Description

OEM has updated the design context. In addition, certain design requests and other constraints, like ‘allowed materials’ or ‘weight’, can be defined by the OEM. This update must be transferred to the supplier. The supplier imports the updated information into his system and checks the impact on the own product data. If the supplier data needs to be modified, the modification will be performed and transferred according to UC2 to the OEM.


UC3-1 Design Context Change Info

Information from OEM to Supplier that the design context of a part has changed. The PDM data should include ownership information highlighting which data is not allowed to be modified and which data can / should be modified.

OEM

UC3-2 Download Design Context Data

Supplier downloads the new data package.

A notification with feedback for the OEM should be sent, if the processing of the received data failed on supplier side.

OEM/Supplier

UC3-3 Import Design Context Data

Supplier imports the new data package into his system.

Supplier

UC3-4 Freeze Design Context Data

Supplier freezes the data. Supplier

UC3-5 Design relevant? Supplier decides whether the design update is relevant for their own product information.

Supplier

UC3-6 Design Change Supplier makes design changes. Supplier

3.4.5 Alternatives

No alternatives.


If updated design context has an impact on supplier’s product data, this UC is followed by UC2 to transfer updated supplier data to OEM.

3.4.7 Diagram



Figure 8: Diagram of as-is UC3

3.4.8 Benefits

Figure 9: Diagram of UC3 benefits

The expected benefit results from modifying step “UC3-3 – Import Design Context Data”.

Based on the benefits of the initial import (UC1), the update of design context data can also be performed by providing the metadata information and establish an automated import with mapping of the OEM data to the supplier data. Real performance benefits would be achieved by sending only the changed delta instead of the full design context or by calculating the delta with an import tool.

For some cases the relevance of the changes can be evaluated automatically. If manual evaluation is necessary, the standardized import can /shall provide a better basis for the user’s decision. This includes sensible notifications and reports about the detected changes.

To achieve these benefits the following conditions have to be fulfilled:

The OEM has to assure that the update-Import follows the same standards as the Initial-Import performed in UC1.

The OEM shall include ownership information in the PDM data, highlighting which data is not allowed to be modified and which data can / should be modified.

The supplier has to develop a notification-System, supporting him in performing the remaining manual steps. This can include a pre-evaluation and suggestions of further actions.

The data format has to allow for a Delta-Import

3.4.9 Notes




4 Requirements

Use Case / Process Step

Description of Requirement Owner of data

General Use already existing standard file formats (e.g. STEP AP242) to describe the metadata and its referenced (native) geometry

UC1b-1 Providing metadata with all relevant information (OEM part name, revision, and characterizing attributes) of parts in common standard file format (e.g. STEP AP242). It is not sufficient to deliver these attributes only as part of the CAD file name.

OEM

UC1b-1 Providing CAD data (Native, JT or STEP). The CAD files must be in sync with metadata information and must be referenced by metadata information.

OEM

UC1b-2 Package containing metadata and referenced CAD files must be automatically sent to supplier by using a data exchange tool OR notification must be sent to supplier to download package from data exchange platform.

OEM

UC1b-4 PDM system or data exchange tool must automatically map the OEM naming and numbering to supplier schema.

Supplier

UC1b-4 PDM system or data exchange tool must automatically import PDM data and CAD files into supplier system.

Supplier

UC1b-4 PDM system or data exchange tool must automatically detect and reuse already existing data in supplier system during import of data.

Supplier

UC1b-4 PDM system or data exchange tool must store OEM naming and numbering information in supplier system for later reuse.

Supplier

UC2-3 PDM system or data exchange tool must automatically map the supplier naming and numbering schema to OEM specific information based on store information.

Supplier

UC2-3 PDM system or data exchange tool must automatically map additional metadata to OEM specific information based on store information.

Supplier

UC2-4 Providing metadata with all relevant information (OEM part name, revision, and characterizing attributes) of parts in common standard file format (e.g. STEP AP242). It is not sufficient to deliver these attributes only as part of the CAD file name.

Supplier

UC2-4 Providing CAD data (Native, JT or STEP). The CAD files must be in sync with metadata information and must be referenced by metadata information.

Supplier

UC2-3 and UC2-5

QChecker should only run once on either supplier side or on OEM side. Process definition should trust already executed QChecker runs.

OEM Supplier

UC2-6 PDM system or data exchange tool must automatically import PDM data and CAD files into OEM system.

OEM



UC2-6 PDM system or data exchange tool must automatically detect and reuse already existing data in supplier system during import of data.

OEM

UC3-1 Providing meta data with all relevant information (OEM part name, revision, and characterizing attributes) of parts in common standard file format (e.g. STEP AP242). It is not sufficient to deliver these attributes only as part of the CAD file name.

OEM

UC3-1 Providing CAD data (Native, JT or STEP). The CAD files must be in sync with metadata information and must be referenced by metadata information.

OEM

UC3-1 Provided data should contain only the changed delta. At least in the metadata the changed information must be marked.

OEM

UC3-2 Package containing metadata and referenced CAD files must be automatically send to supplier by using a data exchange tool OR notification must be send to supplier to download package from data exchange platform.

OEM

UC3-3 PDM system or data exchange tool must automatically map the OEM naming and numbering to supplier schema.

Supplier

UC3-3 PDM system or data exchange tool must automatically import PDM data and CAD files into supplier system.

Supplier

UC3-3 PDM system or data exchange tool must automatically detect and reuse already existing data in supplier system during import of data.

Supplier

UC3-3 PDM system or data exchange tool must store OEM naming and numbering information in supplier system for later reuse.

Supplier

5 Summary

The PLM2PLM group has defined three major use cases as the basis for coordinated processes in data exchange between OEM and suppliers.

In the today’s situation of these use cases many manual steps have to be handled.

In terms of being able to handle the constantly increasing amount of exchanged data, a higher level of automatization during the data exchange is necessary. Process robustness and data quality will also benefit from this automatized data exchange.

The PLM2PLM group has identified and highlighted benefits for each of the three use cases. The main improvement will be the step from ‘exchange of CAD data’ towards an ‘exchange of PDM data’. Being able to automatically map OEM and supplier metadata is the foundation for an automated import into OEM/supplier PDM system.

VDA Automatic Data Exchange 5600 of Product- and Metadata between OEM and Supplier PLM ... ·...

Documents

Transcript of VDA Automatic Data Exchange 5600 of Product- and Metadata between OEM and Supplier PLM ... ·...