Automotive CAE Integration.

(1)

Automotive CAE Integration

.

Requirements and Evaluation

.

of Interfaces

.

WHITEPAPER

(2)

Automotive CAE Integration

Requirements and Evaluation of Interfaces

Contribution of the working group “CAD / CAE Integration” at the steering committee 6 of the German automotive industry for the ProSTEP iViP project “Collaborative CAD / CAE Integration (C3I)”.

Stefan Bauer, AUDI AG

Jochen Boy, PROSTEP AG

Arnulf Fröhlich, PROSTEP AG

Matthias Grau, PROSTEP AG

Karl Gruber, AUDI AG

Uwe Krempels, Daimler AG

Thomas Merkt, Dr. Ing. h. c. F. Porsche AG

Katja v. Merten, BMW AG

Wolfgang Schlüter, BMW AG

Stefan Sebrantke, Volkswagen AG

Version 1.2, June 5, 2009 Status: Approved

(3)

Summary

This paper presents the essential analysis results of an activity currently carried out by a group of German automotive companies, with the focus to preserve an open, modular CAE process chain, which offers the opportunity to apply the “best tool in class” whenever desired. The groundwork for this is the definition of consolidated, standardized process modules and interfaces between those modules. The data formats currently in use at these interfaces were evaluated to identify candi-dates for standardization, which can be used as a basis for the intended modular approach.

Caused by consolidation processes in the software industry leading to more and more integrated software packages, users are afraid of restrictions with the openness of tools resulting in less free-dom to modularize and optimize their development processes. The automotive companies would like to see a modular fit between their tools and processes applied today with a clear functional separation - supported by formally documented interface protocols.

To address the various aspects of the topic the investigation covers tool vendors, standardization bodies as well as the involved automotive companies. In order to define functional modules, refer-ence processes have been developed for the different CAE disciplines (including FEM, CFD and MBS) and harmonized between the carmakers. The definition includes the identification of input and output for each module explicitly naming the requirements with regard to information exchange between modules. While the process description is used to identify software tools, the information exchange requirements indicate applicable exchange standards. Both, related software vendors and standardization bodies have been contacted and queried with regard to actual status and fu-ture developments.

Based on this information various tools and data formats currently used across the defined func-tional modules have been identified. They were then evaluated based on criteria defined by the carmakers based on their business process needs in order to determine the “best fit” data formats for the module interfaces. Discussions have been started with users and application experts to ensure practicability and acceptance of the resulting recommendations.

(4)

1 Introduction

Automotive companies constantly face the challenge to increase their efficiency and improve the quality of their products. Closely integrated with design, the disciplines of the development process aiming the dimensioning, simulation and validation of the product (CAE) are consequently identi-fied as areas that can significantly benefit from an increased flexibility in applying methods and tools and thus contribute to the overall goal by realizing improvement potentials. Due to the variety of simulation methods and the resulting heterogeneity of applied software tools achieving in-creased flexibility requires a tools-independent definition of functional modules. The definition of modules is done based on reference processes at the necessary level of abstraction.

Competition among software vendors today very often results in the acquisition of companies pro-viding tools with either overlapping or complementary functionality in order to gain market share. So far, this principle of "the survival of the fittest" does not sufficiently take into account user inter-ests but results in ever more comprehensive integrated software packages featuring insufficient openness for the application of 3rd-party tools. For the users who want to apply the "best tool in class" for a specific task it therefore becomes more and more important to understand the risks resulting from such a development and to express their requirements in a way that can be ac-cepted by software vendors.

To move into this direction a group of German automotive companies therefore teamed up to jointly address the CAD/CAE integration topic.

2 The “Big Picture”

To provide a basis for the communication about the comprehensive subject CAD / CAE integra-tion, a "birds eye view" on the field of investigation has been developed. The resulting high-level map is called "Big Picture".

Figure 1: The "Big Picture"

The "Big Picture" distinguishes data management systems (at the xDM tool layer) and data ma-nipulating systems (at the authoring tool layer). Each layer covers the different areas under inves-tigation: design (CAD, PDM/TDM1), simulation (CAE, SDM2) as well as physical test (CAT, TestDM3). Physical Testing is so far out of scope.

1

(6)

3 Defining Reference Processes and Functional Modules

The important starting point was an analysis of the actual development processes in and around the simulation area [1]. Special attention has been put on the pre-processing part because of its direct relation to the interface between CAD and CAE. The primary goals of the process analysis were to define reference processes at a suitable level of abstraction – not too detailed to allow harmonization across different companies but sufficiently detailed to show the main activity flow and allow identification of requirements and risks.

An important step towards abstraction is the definition of three main simulation disciplines:

• Structure (including crash, pedestrian protection, passenger safety, NVH, strength) • CFD (including aerodynamics, interior airflow, cooling cycle, combustion)

• MBS (including undercarriage, ride and handling, kinematics)

The fundamental result is the identification of functional modules coinciding with the main activities of the harmonized reference processes. The postulated coincidence of an activity and a functional module implies the existence of a defined information state between adjacent modules that can be transferred.

In addition to the widely used subdivision of the CAE process into the three main activities, pre-processing, solving, and post-pre-processing, it was found during the definition of the reference proc-esses that the pre-processing itself can be broken down into four functional modules, which were found to coincide across companies and disciplines. These are: data collection, data preparation and discretization, component assembly and solving model creation.

Figure 1 above gives an overview over the modules that have been defined, and the related inter-faces where defined information states are conveyed. These interinter-faces constitute the basis for the subsequent evaluation of data formats, concerning when in the process they are used, and which contents they have to transport. See section 3.3 for more information.

In addition, a number of requirements have been derived from the reference processes, which are described in section 4.

3.1 Modules in the xDM Tool Layer

The functional modules defined in the xDM Tool Layer (see Figure 1) provide structured access to information related to the development processes, process control and coordination as well was as data storage and administration. In the context of CAD/CAE integration in the automotive industry, the modules in focus are PDM, TDM and SDM.

3.1.1 Module PDM

Function

The PDM Module provides all functions which are needed to administer data in the context of the development process. This includes

• the complete technical description of the product • the capability to illustrate the progress of the project • and these across several development processes

2

SDM: Simulation Data Management

3

(7)

An important characteristic of this module is the capability to support collaborative engineering, across disciplines and also between different sites or companies, e.g. when cooperating with de-velopment partners and suppliers.

Tasks in the area of

• handling of data formats and conversions between those • configuration of variants

• development of prototypes

are typically lead by the PDM module.

Out of Scope

The PDM module does not cover

• functions concerning the bill of material • production / deployment control

• documentation of manufacturing and color variance

• requirements calculation, lifecycle management of parts for the fleet in operation • documentation of final approvals

• information specific to authoring tools

• support of concurrent engineering and design in context

• depending on the size of the company/department, PDM may cover parts of the TDM

func-tionality

• long-term archiving of data (e.g. due to legal requirements) • manipulation of user data

3.1.2 Module TDM

Function

In contrast to the PDM module, the TDM module primarily controls the management of information and data formats specific to the various authoring tools, including

• CAD geometry

• technical documentation

The TDM module thereby supports concurrent engineering in teams, and design in context. Out of Scope

The TDM module does not cover

• functions of the PDM module

• data management and process control across disciplines or development processes • long-term archiving of CAD data (e.g. due to legal requirements)

• manipulation of user data – these are usually not accessible for the TDM system

o exception: extraction of meta data to create or check in a container for user data (e.g. the CAD model)

(8)

3.1.3 Module SDM

Function

SDM tools – in the sense of ready-to-use after necessary customization, commercial-of-the-shelf products – are rather new. Their application in the development process currently often still is “un-der evaluation”. This is caused by a more or less obvious change of paradigms in the delineation and cooperation of design on one side, and layout / verification on the other. This process is char-acterized by the shifting of tasks from physical to virtual prototyping, which in turn created the need for structured simulation data management.

This need is also based on a number of other requirements emerging from the currently changing process and tool landscape. With the increasing availability of simulation capabilities, the amount of projects and data created therein is rapidly growing, making effective search and find routines necessary, e.g. to easily come up with comparison data. Automated processes and cooperation with partners outside the simulation department also demand for a structured SDM to guarantee access to the required data.

Consequently, the position of SDM within the xDM tool layer is not fixed yet, and may in future cover aspects of PDM as well as of TDM, possibly depending on the respective development process phase.

Where already implemented, SDM often takes on the role of a TDM for the CAE department un-derneath a “master” PDM system, and combines the two basic functionalities data management and workflow master (application process control).

The data management aspect covers typical functionalities, such as

• creation and maintenance of a product structure (here in the simulation context from a CAE

point of view)

• management of product data in the (simulation) context

o input data from other system domains (CAD, testing,…), as well as intermediate and end results from simulations and computation processes

o as copy or master record, or as a reference / link o comprehensible and retraceable

• Organization, storage, retrieval of and access to simulation data and their describing (meta)

data

• versioning of CAE information (creation of a CAE-specific development history)

The application process control serves two main purposes

• to create, execute and document simulation processes in a retraceable way (CAE workflow

management), e.g. to automate the process from solving to report creation.

• to include simulation activities into the product development process (process control and

integration)

These two basic functionalities are technically not required to be implemented in the same tool. For this reason the combination of data management and application control into one module is seen as critical with regard to the tasks at hand and the problem of vendor fixation (software suites). Future activities need to check whether the two functionalities should be separated into two modules, which would put the resulting interface between data management (“hard drive”) and application control (“batch file”) in focus.

Out of Scope

The SDM module does not cover

(9)

• the manipulation of simulation data contents (user data) – these are usually not accessible

for the SDM system

o exception: extraction of meta data to create or check in a container for user data (e.g. a file)

3.2 Modules in the Authoring Tool Layer

The modules within the Authoring Tool Layer serve the creation of primary (by creative activities) and secondary (by derivation from primary) product data. These modules cover specific functional-ities of the value-creating authoring tools, especially in the CAD and CAE domain.

3.2.1 Module CAD

Functions

Tools within the CAD module serve the creation of design information for products and their parts and assemblies, in the form of

• 2d views and drawings

• 3d models (surface, solids, wireframes) • topological (e.g. kinematic) connections • parametric data (material, thickness,...)

• conceptual data during early development phases

From a CAE point of view, the CAD module is the supplier of geometric information, both explicit and implicit, and therefore is in close interaction with the CAE modules Data Collection and Data Preparation on a functional as well as on a process level. Within the currently used tools, the bor-derlines between these functional modules are often obliterated. This includes the application of dedicated “CAD-like” tools to create concept data at the beginning of the development process, as well as the use of a classic CAD tool by a simulation engineer to roughly sketch a component for which no data is available yet.

Out of Scope

The CAD modules do not cover

• Preparation of geometry for CAE purposes (simplification, derivation) • Discretization of geometry (FE mesh creation)

3.2.2 Module CAE – Data Collection

Functions

The Data Collection module covers steps concerned with the gathering of input data. Input data include data from areas outside of simulation (e.g. geometrical data) as well as (intermediate) re-sults from other simulation disciplines or preceding computations.

In particular, CAE – Data Collection provides functions to

• identify the required set of user data, including

o geometrical data

o non-geometric data, e.g. material data, spring and dampener characteristics, stiff-ness, moments of inertia, test data, …

• collection of data from external departments and simulation teams (organizational view) • collection of data from external systems and data bases (system view)

(10)

• validation of the gathered data (e.g. by quality checks) and, if necessary, rejection of the

data in case applicable specifications and standards are not met

• extraction of identification data, meta data, keywords, … from user data • composition of data packages as input for the Data Preparation

All collected data – especially if a further preparation is not required – should be stored in the SDM system where they can be maintained and accessed by downstream processes.

Out of Scope

The module CAE - Data Collection does not cover

• any kind of manipulation of the gathered data in terms of preparation to carry out a

simula-tion, e.g. conversion or simplification

• persistent organization and storage of the gathered data

3.2.3 Module CAE – Data Preparation and Discretization

Functions

The module CAE – Data Preparation and Discretization covers all tasks to process the data gath-ered by the Data Collection in order to be used in a simulation. Depending on the nature of the input data, these tasks may be very different.

CAD geometry needs to be prepared for CAE purposes, which includes

• simplification of the geometry (defeaturing: removal of blends, small holes, …) • derivation of bounding geometry, median planes, …

• supplementation of attributes and parameters • identification and selection of critical load scenarios • derivation of boundary conditions

• determination of connection information (welding spots,…) from CAD models

The processed geometry, as well as the kinematic and dynamic boundary conditions (loads) have to be discretized, which includes

• creation of FE meshes

• determination of mounting and transition criteria • discretization of component loads

Existing meshes (e.g. from preceding computations or tessellated models) have to adapted to the current requirements by

• adjustment of element aspect ratios (for meshes based on tessellated data) • completion of mesh topology (closing of holes and passages)

• modification and simplification (removal of details) of existing meshes

Analogue data will be digitized

• characteristic curves

• kinematic plans provided as parameter sets

It is import to ensure the manifold reusability of the processed data in all these tasks. Therefore, they will be stored and managed in the SDM system, tagged with the respective meta data.

(11)

Out of Scope

The module CAE – Data Preparation and Discretization does not cover

• the assembly of simulation meshes – all preparation steps do not change the composition

of the models

• the creation of loads

• the combination of FE meshes and loads into computable data sets

3.2.4 Module CAE – Component Assembly

Functions

The Component Assembly module provides the functionality to assemble the data prepared on a component level (e.g. individual FE meshes) to simulation-specific extents based on the planned investigation. This includes in particular

• the assembly of component meshes

• the supplementation of connection information and additional data at assembly level, e.g.

characteristic curves

• if necessary, fine-tuning of the meshes (e.g. to ensure compatible transitions at the mesh

boundaries)

• the synopsis of component loads to load cases

The “simulation assemblies” created this way should be stored in the SDM and associated with the respective node in the model structure.

Out of Scope

The CAE – Component Assembly module does not cover

• any kind of discretization (such as mesh creation, …)

• the combination of FE meshes and loads into computable data sets

3.2.5 Module CAE – Solving Model Creation

Functions

The CAE – Solving Model Creation covers all tasks necessary to create a computable data set (so-called „input deck“) according to the intent of the simulation, including

• assignment of loads

• association of load cases (unit loads, load case library) • completion of parameters

In addition, in order to create consistent solvable model, there need to be

• quality checks (e.g. adherence to specifications and requirements) • definition of solver-specific parameters and control sequences • test loops

The results should be stored and maintained in the SDM system, where they can be accessed by downstream processes.

(12)

Out of Scope

The module CAE – Solving Model Creation does not cover

• advance computations

• any optimization of the solver run (load balancing,…)

• composition of meshes or loads on component level to models covering a simulation extent

3.2.6 Module CAE – Solving

Functions

Before the actual computation (i.e. the solution of the problem described as a solving model) can be done, the following preparatory tasks are necessary in this context:

• loading the solving model (input deck) • advance computations

• adjustment of parameters

• optimization of the solver run (load balancing, …) • initiate the solver run

After completion of the solver run, the progress and result data will be stored locally as well as filed and maintained in the SDM system within the context of the input data.

Out of Scope

The CAE – Solving module does not cover:

• quality checks • test loops

3.2.7 Module CAE – Post-Processing

Function

The CAE Post-Processing module covers all tasks to process the progress and result data from the simulation run. This includes

• verification of validity and plausibility of the simulation • comparison of the result data with measured data

• filtering and visualization of results as tables, graphs, … (automated using templates or

manually)

• creation of reports

• conversion into secondary formats (e.g. motion result file to ASCII)

• In addition there is an increasing range of possibilities for software-supported results

inter-pretation

• draw conclusions from the results

Like the simulation results themselves, the information derived from them should be stored in the SDM system in the context of the input data to ensure referenceability and traceability.

Out of Scope

The CAE – Post-Processing module does not cover

(13)

3.3 Module Interfaces

The modules defined above share interfaces with each other. Besides the straightforward inter-faces for handing data down the regular CAE process chain (compare Figure 1), there are also comprehensive interfaces – for instance the SDM module needs to have access to each CAE module. It was also found that besides the main stream of information, there are also cases where certain data bypasses a module, thus creating a side path for the information.

The interfaces and information flow in focus of the further investigation are shown in Figure 2 for structure and Figure 3 for CFD below. A short designator is defined for each interface, which will be used for reference in section 6.

Figure 2: Module Interfaces Structure

(14)

4 Requirements for and Evaluation of CAE Data Formats

Each of the analysis areas produced a number of requirements representing the user perspective with regard to development process, applied software tools and data exchange protocols in order to achieve a modularized CAE system landscape. The results were categorized according to their importance for the achievement of the modularization goals.

The most important requirements driven by the CAx development process include for instance

• secure external data transmission

• binding specification of exchange interfaces

CAE software related requirements are lead by

• data quality (in terms of accessibility, integrity, relevance, correctness) • backwards-compatibility at format changes

The interface standard related requirements with the highest rating include

• no access restrictions to the specification • maturity of the standard

The assessment criteria reflect the requirements for the investigated data formats. The criteria can be separated into two groups:

• general criteria, valid for all module interfaces • interface-specific criteria

At first, all criteria and a valid value range for these were specified. During the course of the inves-tigation the necessity emerged to assess the formats not only with regard to correlation of scope, openness of the specification and circulation rate, but also include further criteria as well.

Next, weights were assigned to each criterion to define how much impact it will have on the total result. The interface-specific criteria were combined to a criterion “data scope” and weighted con-sistently. The weighting factors originally resulted as mean values of the companies’ prioritization. Regardless of an overall deviation of 5 % they represent a common requirement specification for the automotive industry. For a list of all applied criteria and their respective weights, see Table 1. Using the subset of criteria which had the highest weights while being practically rateable, the en-tirety of data formats found to be in use in the automotive industry was assessed in a first evalua-tion with the intent to limit the number of formats for closer investigaevalua-tion. Only the highest ranking formats for each interface, plus additional formats which were deemed of strategic importance, then underwent a detailed evaluation considering all criteria defined as well as further input from experts in that area. The tables in section 6 below only list the formats from this shortlist.

Criteria Explanation Weighting [%] Practically _rateable General criteria

1 Standardization Grade of standardization 11,6

2 Readability For humans readable, e.g. *.txt 6,4

3 Documentation Documentation of the data format available 12,1

(15)

5 Usage in module interface Quantity of usage in each interface 10,1

6 API available Toolkits for interface implementation avail-_able 9,1

7 Data compression Relation between file size of the single

format and any chosen reference format 3,0

8 Import/ Export time

Relation between Im. /Ex. time and Im. /Ex. time by using the proprietary format for the round 5 most important tool transitions

14,0

9 Encrypt ability Parts of the data content can be encrypted,

encoded 2,9

10 Modularity Parts of the data content can be encapsu-_lated 4,9

Specific data format criteria

11 Data content

(per module interface)

Data format contains an assortment of the following data types depending on the interface: Metadata Product structure Parameter Geometry FE-model FE-result Joining technique MKS-model MKS-result Media Table Template Diagram Document Plot Plot (3D) 14,3

Table 1: Evaluation Criteria

5 Criteria and Interpretation

This section provides an assessment of the evaluation with regard to plausibility and further use of the results, which will be given in detail in section 6.

5.1 Evaluation Criteria

Some criteria are not orthogonal, i.e. there are dependencies between them. For instance, the cri-teria “Standardization” and “Documentation” are partially related: a standardized data format is always documented, whereas a documented data format is not necessarily standardized.

(16)

There-fore, the current choice of criteria is intended, the partial interdependencies do not present a dis-advantage and could only not avoided with justifiable effort.

For a better overview, the criteria can be arranged in groups. The associated weights of the indi-vidual criteria will then be summed up within each group of criteria. The proposed grouping or re-quirements with the corresponding individual criteria along with the resulting total weighting can be seen in Table 2 below:

Group of Requirements Weighting

Openness of Format • Standardization • Readable Format • Documentation • Availability of APIs 39 % Functionality of Format • Data types • Modularity • Encryptability 22 %

Awareness level of Format

• Distribution in application • Usage in modules

22 %

Performance of Format

• Data compression • Import / Export time

17 %

Table 2: Groups of Requirements

The grouping introduced above illustrates that for instance the openness of a format plays an im-portant role. In addition, groups of direct and indirect requirement can be discerned. While open-ness, functionality and performance are direct criteria, the level of awareness for a format is an indirect criterion, from which further conclusions have to be drawn.

The fact that no K.O. criteria were defined also has a significant impact on the evaluation results. Hence, even if a data format does not support the required data types, this criterion affects the evaluation results only with its associated weight. If the same data format achieves a high score in other areas, e.g. because it is an open one, it may still reach a high score in total. In this case, an interpretation of the evaluation results is necessary (see 5.2).

5.2 Interpretation and Verification of Evaluation Results

Based on their practical rateability, no evaluation criteria for performance could be rated during the course of the project (see Table 1). For a better interpretation of the results it is helpful to compare the actual score with the maximal reachable score if the respective data format had fully met the criteria which were not rated directly. If this hypothetic score does not get ahead of the actual rank-ing based on the evaluated criteria, the respective format is out of the question for the considered interface. In this case, a closer investigation will not lead to useful results.

Altogether it needs to be said that the result of the evaluation renders a lead on applicable data formats for the respective module interfaces. The conclusion, that the highest scoring data format is automatically the strategically advisable format must not be drawn. There are two main reasons for this - the first one is the fact that the evaluation result contains uncertainties because of unrated criteria, such as. import and export time, or criteria which were rated only a high level. For

(17)

in-stance, the availability of an API for a format was rated, but not whether the API provides full ac-cess, or its quality, i.e. how it performs compared to the proprietary interface.

The second reason is that the result renders no information about how much effort would be nec-essary to compensate the deficits of the format so that it can be applied at the respective module interface without limiting its functionality. Not only the technical feasibility, but also the ‘political’ will of both the system vendors and the users is an important factor in this equation and can hardly be estimated in advance. Migration efforts are an additional aspect of this discussion.

5.3 Feedback on the Evaluation Results

In order to improve the plausibility of the results achieved after the initial evaluation, experts for the high-ranking formats including users and API vendors were asked for a feedback. The following, generally applicable statements were given:

• In the CFD discipline, there are a number of standardized formats, e.g. CGNS and HDF5,

which are rather common in the aerospace industry, but rarely used in the automotive sec-tor. However, these often are more of a programming language than a data exchange for-mat, and are maintained and applied by the user companies to their own needs, thus in a wide variety. This makes it difficult to establish a standard.

• System vendors usually prefer their own data format because they can optimize them for

performance and to support system-specific functionality. As a standard always has to make compromises to support various systems, some of these advantages would have to be sacrificed. There need to be good reasons for a vendor to implement a yet unsupported data format in his systems.

• Proprietary formats are also often used as a means of intellectual property protection. E.g.

if a specific formula is known to the system, it is sufficient to transfer the coefficients only. To make this calculation accessible to other systems, the formula itself would need to be transferred, too.

• Especially the interfaces of the CAE – Solving module pose the challenge that the physical

module used in the different solvers varies significantly, which is the primary reason for the wide variety of solving tools available nowadays. Conversions between these physical models are usually challenged with approximations and interpolations, thus a loss of quality in the results. This makes it difficult to define one data format as the preferred one in this case. A common challenge in most solver formats is to pass through data which is not di-rectly needed by the solver, but relevant for post-processing, such as master data.

• In general, an open format defining not only a data structure, but read and write routines as

well, would be a preferred solution. It could be supplemented with the required data types and subsequently widely used.

• Some API vendors also stated that the desire to have one (standardized) format per

mod-ule interface is not practical, because of the conflicting requirements accuracy, versatility, performance and maintainability. This format would need to provide a high level of quality and completeness, it has to offer sufficient performance when creating, writing and reading large amounts of data, and last but not least it has to be easy to implement and maintain, so that it can keep up with the ongoing development of CAE software, especially solvers.

6 Data Formats for Module Interfaces

One of the main tasks of the activity was to evaluate the data formats which are currently used throughout the CAE process, especially with regard to the newly defined functional modules (see section 3). The goal was to determine how these formats perform when compared against the re-quirements and criteria defined both in general and for each module interface in specific.

(18)

As a first step, the major CAE systems and data formats in use in the automotive industry were collected in a survey and consolidated in a matrix. This table provided three views:

• Applications used per Module / Discipline

• Data Formats used per Module Interface / Discipline • Data Contents moved between Modules / Discipline

The applications used per module gave a rough estimate of how commonly used a data format is, as for instance a standard will typically be supported by more applications than a system-specific proprietary format.

The data formats used per module defined the base set of formats to investigate per module inter-face. These were filtered in a first evaluation by applying the generally applicable criteria. The higher ranking formats, which received at least half of the maximum score, then were evaluated in more detail, rendering the final score.

The data content per module interface view finally defined the “Data Content” criteria for the evaluation. Consequently this varies from interface to interface.

In short, for each of the module interfaces as defined in section 3, the test criteria as defined in section 4 were applied to all data formats currently in use at the respective module interface. The results are shown in the tables below. See Figure 2 and Figure 3 for an illustration and the naming convention of the interfaces.

The Data Types which are used to classify the information contents at the module interfaces, or the missing elements for a data format in the Gap Analysis tables below, are defined in Annex B:.

(19)

6.1 Data Collection – Data Preparation & Discretization

6.1.1 M_Structure_1

Figure 4: Tools, Data Formats and Data Types at M_Structure_1

Data format Criteria W e ig h ti n g [ % ] ST EP AP2 1 4 (. s tp , .s te p ) IG ES (. ig s , .i g e s ) VD A -F S ( .v d a , .v d a fs ) L S D y n a ( .k e y ) 3 D PD F ( .p d f) Ab a q u s I n p u t F ile ( .i n p ) J T ( .j t) PL M XM L ( .p lm x m l) Pr o /E G e o m e tr y ( .p rt ) C a ti a V5 ( .C AT Pa rt ) C a ti a V5 ( .C AT Pr o d u c t) 1 Standardization 12 116 58 116 0 116 0 116 58 0 0 0 2 Readability 6 64 64 64 64 0 64 0 64 0 0 0 3 Documentation 12 109 121 109 61 121 30 97 121 0 0 0 4 Spreading throughout the application 12 118 88 29 88 0 118 59 0 59 29 29 5 Usage in module interface 10 101 101 51 101 0 101 0 0 76 51 25

(20)

6 API available 9 46 46 46 46 82 0 46 46 0 0 0

7 Data compression 3 - - - -

8 Import/ Export time 14 - - - -

9 Encrypt ability 3 0 0 0 - 0 0 0 0 0 0 0

10 Modularity 5 49 49 24 49 49 49 49 49 24 24 24

11 Data content

(per module interface) 14 107 71 62 143 116 143 71 53 89 89 71

Metadata Product structure Parameter Geometry FE-model Joining technique Media Document Rating points 709 598 501 488 484 451 438 391 230 193 150

Maximum achievable points 879 768 671 687 654 621 608 561 400 363 320

Table 3: Results for Structure: Data Collection - Data Preparation

Data Format Necessary Extensions Recommendation

STEP AP214 FE Model Media

Usage in combination with a data format to transfer FE models (e.g. AP209).

Inclusion of media via external re-ferences LS Dyna (.key) Product Structure Media Documents Standardization

Consider only if the recom-mended combination of STEP AP209 and AP214 causes con-siderable problems in application.

Abaqus Input File (.inp) Product Structure Media Documents Standardization

Consider only if the recom-mended combination of STEP AP209 and AP214 causes con-siderable problems in application.

3DPDF Connection Information Standardization

(ongoing)

Is not a classic data exchange format in itself, but PRC geometry representation and data container

(21)

functionality make this an viable option for this module interface. Because of high effort necessary to implement this, consider only if the recommended combination of STEP AP209 and AP214 causes considerable problems in applica-tion JT FE Model Connection Information Media Documents Standardization (ongoing)

Visualization format. Because of the current geometry representa-tion and the missing FE model en-tities not applicable for this mod-ule interface.

IGES Connection Information Media

Documents

Outdated format, there not rec-ommendable as strategic format.

(22)

6.1.2 M_CFD_1

Figure 5: Tools, Data Formats and Data Types at M_CFD_1

Data format Criteria W e ig h ti n g [ % ] ST EP AP2 1 4 (. s tp , .s te p ) ST L ( .s tl ) N a s tr a n Bu lk D e c k (. b d f, . n a s , .d a t) Pr o /E G e o m e tr y ( .p rt ) C a ti a V5 ( .C AT Pa rt ) C a ti a V5 ( .C AT Pr o d u c t) 1 Standardization 12 116 58 0 0 0 0 2 Readability 6 64 64 64 0 0 0 3 Documentation 12 109 121 61 0 0 0

4 Spreading throughout _{the application} 12 118 59 29 59 29 29

5 Usage in module

inter-face 10 101 76 101 76 51 25

6 API available 9 46 91 0 0 0 0

(23)

9 Encrypt ability 3 0 0 - 0 0 0

10 Modularity 5 49 49 49 24 24 24

11 Data content

(per module interface) 14 95 71 95 48 48 0

Geometry

FE-model

Document

Rating points 697 589 399 207 152 79

Maximum achievable points 867 759 598 377 322 249

Table 5: Results for CFD: Data Collection - Data Preparation

STEP AP 214 FE -Model Usage in combination with a data format to transfer FE models (e.g. AP209, Nastran Bulk Data). IGES Document Capable of transferring geometry

and FE model information (both in limited scope depending on the processor).

Outdated format, therefore not rec-ommendable as a strategic format Nastran Bulk

Data

Document Openness & Standardization

Consider only if the recommended combination of STEP AP209 and AP214 causes considerable prob-lems in application.

(24)

6.2 Data Preparation & Discretization – Component Assembly

6.2.1 M_Structure_2

Data format Criteria W e ig h ti n g [ % ] L S D y n a ( .k e y ) ST EP AP 2 0 9 Ab a q u s I n p u t F ile ( .i n p ) N a s tr a n Bu lk D e c k (. b d f, . n a s , .d a t) M e d in a B in a ry I n p u t F ile ( .b if ) An s a 1 Standardization 12 0 116 0 0 0 0 2 Readability 6 64 64 64 64 0 0 3 Documentation 12 61 109 30 61 61 0 4 Spreading throughout the application 12 88 0 118 29 0 0

5 Usage in module

inter-face 10 101 0 101 101 101 76

6 API available 9 46 46 0 0 46 0

9 Encrypt ability 3 - 0 0 - - -

(25)

11 Data content

(per module interface) 14 143 143 143 143 143 107

Metadata

Geometry

FE-model

Joining technique

Rating points 551 526 504 446 374 207

Table 7: Results for Structure: Data Preparation - Component Assembly

Data Format Necessary

Extensions

Recommendation

LS Dyna (.key) Standardization Recommendation for use as proprie-tary format. If applicable, use STEP AP209 as standard.

STEP AP 209 - Recommended.

Abaqus Input File (.inp)

Standardization Consider only if the recommended formats LS Dyna and AP209 cause considerable problems in application Nastran Bulk

Data

Standardization Consider only if the recommended formats LS Dyna and AP209 cause considerable problems in application Medina Binary

Input File

Connection Infor-mation

Standardization

Consider if a binary format is pre-ferred for performance reasons.

(26)

6.2.2 M_CFD_2

Data format Criteria W e ig h ti n g [ % ] ST EP AP2 1 4 (. s tp , .s te p ) IG ES (. ig s , .i g e s ) ST L ( .s tl ) Pr o /E G e o m e tr y ( .p rt ) C a ti a V5 ( .C AT Pa rt ) 1 Standardization 12 116 58 58 0 0 2 Readability 6 64 64 64 0 0 3 Documentation 12 109 121 121 0 0

4 Spreading throughout _{the application} 12 118 88 59 59 29

5 Usage in module

inter-face 10 101 101 76 76 25

6 API available 9 46 46 91 0 0

7 Data compression 3 - - - - -

(27)

9 Encrypt ability 3 0 0 0 0 0

10 Modularity 5 49 49 49 24 24

11 Data content

(per module interface) 14 71 143 107 71 71

Geometry

FE-model

Rating points 674 669 625 230 150

Maximum achievable points 844 839 795 400 320

Table 9: Results for CFD: Data Preparation - Component Assembly

Extensions

Recommendation

STEP AP214 FE Model Usage in combination with a data format to transfer FE models (e.g. AP209, Nastran Bulk Data).

IGES - Capable of transferring geometry and FE model information (both in limited scope depending on the processor). Outdated format, therefore not rec-ommendable as a strategic format Table 10: Gap Analysis for CFD: Data Preparation - Component Assembly

(28)

6.3 Component Assembly – Solving Model Creation

6.3.1 M_Structure_3

Data format Criteria W e ig h ti n g [ % ] L S D y n a ( .k e y ) ST EP AP 2 0 9 Ab a q u s I n p u t F ile ( .i n p ) N a s tr a n Bu lk D e c k (. b d f, . n a s , .d a t) M e d in a Bi n a ry I n p u t F ile ( .b if ) An s a 1 Standardization 12 0 116 0 0 0 0 2 Readability 6 64 64 64 64 0 0 3 Documentation 12 61 109 30 61 61 0 4 Spreading

through-out the application 12 88 0 118 29 0 0

5 Usage in module

interface 10 101 0 101 101 101 76

6 API available 9 46 46 0 0 46 0

9 Encrypt ability 3 - 0 0 - - -

10 Modularity 5 49 49 49 49 24 24

(29)

(per module interfa-ce)

FE-model

Rating points 551 526 504 446 374 243

Table 11: Results for Structure: Component Assembly - Solving Model Creation

Extensions

Recommendation

LS Dyna (.key) Standardization Recommendation for use as proprie-tary format. If applicable, use STEP AP209 as standard

STEP AP 209 - Recommended.

Data

Input File

Standardization Consider if a binary format is pre-ferred for performance reasons Table 12: Gap Analysis for Structure: Component Assembly - Solving Model Creation

(30)

6.3.2 M_CFD_3

Data format Criteria W e ig h ti n g [ % ] ST L ( .s tl ) ST EP AP 2 0 9 1 Standardization 12 58 116 2 Readability 6 64 64 3 Documentation 12 121 109 4 Spreading throughout the application 12 59 0

5 Usage in module

inter-face 10 76 0

6 API available 9 91 46

7 Data compression 3 - -

8 Import/ Export time 14 - -

9 Encrypt ability 3 0 0

10 Modularity 5 49 49

(31)

Geometry

FE-model

Rating points 625 526

Maximum achievable points 795 696

Table 13: Results for CFD: Component Assembly - Solving Model Creation

Extensions

Recommendation

STEP AP 209 - Recommended. If necessary in com-bination with STEP AP214 should the AP209 geometry representation not be fully sufficient.

STL - Not recommended since both ge-ometry and FE model representation are most likely insufficient

Table 14: Gap Analysis for CFD: Component Assembly - Solving Model Creation

6.4 Solving Model Creation – Solving

6.4.1 M_Structure_4

(32)

Data format Criteria W e ig h ti n g [ % ] L S D y n a ( .k e y ) ST EP AP 2 0 9 Ab a q u s I n p u t F ile ( .i n p ) N a s tr a n Bu lk D e c k (. b d f, . n a s , .d a t) 1 Standardization 12 0 116 0 0 2 Readability 6 64 64 64 64 3 Documentation 12 61 109 30 61

4 Spreading throughout the

application 12 88 0 118 29

5 Usage in module interface 10 101 0 101 101

6 API available 9 46 46 0 0

9 Encrypt ability 3 - 0 0 -

10 Modularity 5 49 49 49 49

11 Data content

(per module interface) 14 143 143 143 143

FE-model

Rating points 551 526 504 446

Maximum achievable points 749 696 674 645

Table 15: Results for Structure: Solving Model Creation – Solving

Extensions

Recommendation

STEP AP 209 - Recommended

Data

Standardization Consider only if the recommended formats LS Dyna and AP209 cause considerable problems in application Table 16: Gap Analysis for Structure: Solving Model Creation – Solving

(33)

6.4.2 M_CFD_4

Data format Criteria W e ig h ti n g [ % ] ST L ( .s tl ) ST EP AP 2 0 9 F lu e n t (. m s h ) C F X (. d e f) St a r C C M + ( .c c m ) St a r-C D ( .g e o m , .p ro b ) 1 Standardization 12 58 116 0 0 0 0 2 Readability 6 64 64 64 0 0 0 3 Documentation 12 121 109 61 0 - - 4 Spreading throughout the application 12 59 0 0 0 0 0

5 Usage in module

inter-face 10 76 0 0 0 25 0

6 API available 9 91 46 46 46 - -

9 Encrypt ability 3 0 0 - - - -

10 Modularity 5 49 49 49 49 49 49

(34)

FE-model

Rating points 660 526 361 237 217 191

Table 17: Results for CFD: Solving Model Creation – Solving

Extensions

Recommendation

Fluent (.msh) Standardization Consider only if the recommended format AP209 causes considerable problems in application

STL - Not recommended, since FE model entities probably insufficient in most application scenarios.

(35)

6.5 Solving – Post-Processing

6.5.1 M_Structure_5

Data format Criteria W e ig h ti n g [ % ] ST EP AP 2 0 9 L S D y n a ASC II D a ta b a s e Ab a q u s R e s u lt F ile ( .f il) L S D y n a B IN O U T (. b in o u t) N a s tr a n Pu n c h ( .p c h ) N a s tr a n f 0 6 ( .f 0 6 ) N a s tr a n X -Y Pu n c h ( .p c h ) L S D y n a D 3 PL O T (. d 3 p lo t) Ab a q u s O u tp u t D a ta b a s e (. o d b ) N a s tr a n O P2 ( .o p 2 ) Pa m C ra s h R e s u lt ( .d s y ) Pa m C ra s h T im e H is to ry (. th p ) 1 Standardiza-tion 12 116 0 0 0 0 0 0 0 0 0 0 0 2 Readability 6 64 64 64 0 64 64 64 0 0 0 0 0 3 Documenta-tion 12 109 61 30 61 61 61 61 61 0 61 61 61 4 Spreading throughout the application 12 0 88 118 88 29 29 29 88 118 29 0 0 5 Usage in module inter- 10 0 25 25 0 25 0 0 0 25 25 0 0

(36)

face 6 API available 9 46 0 0 46 0 0 0 0 0 0 23 23 7 Data com-pression 3 - - - - 8 Import/ Export time 14 - - - - 9 Encrypt ability 3 0 - - - - 10 Modularity 5 49 49 49 49 49 49 49 49 49 49 49 49 11 Data content (per module interface) 14 143 143 143 143 143 143 143 143 143 143 143 143 FE-result Rating points 526 429 428 386 370 345 345 340 334 307 275 275 Maximum achievable points 696 628 627 584 569 544 544 539 533 505 473 473

Table 19: Results for Structure: Solving - Post-Processing

Extensions

Recommendation

LS-Dyna AS-CII Database

Standardization Consider only if the recommended format AP209 causes considerable problems in application

Abaqus Input File (.fil)

LS-Dyna BI-NOUT

Standardization Consider in case a binary format is preferred for performance reasons Nastran Punch

(.pch)

Nastran X-Y Punch (.pch)

Nastran f06 Standardization Consider only if the recommended format AP209 causes considerable problems in application

(37)

Data Format Necessary Extensions

Recommendation

LS-Dyna D3PLOT

Standardization Consider in case a binary format is preferred for performance reasons Abaqus Output

Database (.odb)

Openness & Stan-dardization

Consider in case a binary format is preferred for performance reasons

Nastran OP2 Standardization Consider in case a binary format is preferred for performance reasons Table 20: Gap Analysis for Structure: Solving - Post-Processing

6.5.2 M_CFD_5

Data format Criteria W e ig h ti n g [ % ] ST EP AP 2 0 9 En s ig h t ( .c a s e ) En s ig h t ( .g e o ) 1 Standardization 12 116 0 0 2 Readability 6 64 64 0 3 Documentation 12 109 61 61 4 Spreading throughout the application 12 0 29 29

(38)

5 Usage in module

inter-face 10 0 0 0

6 API available 9 46 46 46

7 Data compression 3 - - -

8 Import/ Export time 14 - - -

9 Encrypt ability 3 0 - -

10 Modularity 5 49 49 49

11 Data content

(per module interface) 14 95 48 0

FE-result

Document

Rating points 479 296 184

Maximum achievable points 649 494 383

Table 21: Results for CFD: Solving - Post-Processing

Extensions

Recommendation

Ensight (.case) Document Standardization

Consider only if the recommended format AP209 causes considerable problems in application

(39)

6.6 Sidetracks

During the definition of the reference processes and functional modules, it was seen that in some cases there is information which will skip a module in the process – this usually refers to data that is collected in the beginning, but does not need to be prepared further before it is used in the CAE process. This results in additional interface which are not adjacent. For an illustration of these side-tracks, see Figure 2 and Figure 3.

6.6.1 Structure

6.6.1.1 M_Structure_S1: Data Collection – Component Assembly

Data format Criteria W e ig h ti n g [ % ] ST EP AP2 1 4 (. s tp , .s te p ) ST EP AP2 0 9 L S D y n a ( .k e y ) Ab a q u s I n p u t F ile ( .i n p ) N a s tr a n Bu lk D a ta ( .b d f, .d a t, . n a s ) M e d in a B in a ry I n p u t F ile (. b if ) C a ti a V5 ( .C AT Pa rt ) 1 Standardization 12 116 116 0 0 0 0 0 2 Readability 6 64 64 64 64 64 0 0 3 Documentation 12 109 109 61 30 61 61 0 4 Spreading

through-out the application 12 118 0 88 118 29 0 29

5 Usage in module

interface 10 101 0 101 101 101 101 51

6 API available 9 46 46 46 0 0 46 0

9 Encrypt ability 3 0 0 - 0 29 - 0

10 Modularity 5 49 49 49 49 49 24 24

11

Data content (per module interfa-ce)

14 71 143 107 143 143 143 71

Parameter

FE-model

Rating points 674 526 515 504 475 374 176

Maximum achievable points 844 696 714 674 645 573 346

(40)

Data Format Necessary Extensions

Recommendation

STEP AP 214 FE Model Not recommended due to limited FE model representation

Data

Input File

Standardization Consider in case a binary format is preferred for performance reasons Table 24: Gap Analysis for Structure: Data Collection - Component Assembly

6.6.1.2 M_Structure_S2: Data Collection – Post Processing

Data format Criteria W e ig h ti n g [ % ] ST EP AP2 1 4 (. s tp , .s te p ) ST EP AP2 0 9 L S D y n a ( .k e y ) Ab a q u s I n p u t F ile ( .i n p ) L S -D y n a ASC II D a ta b a s e Ab a q u s R e s u lt F ile ( .f il) L S D y n a B IN O U T (. b in o u t) N a s tr a n Pu n c h ( .p c h ) N a s tr a n f 0 6 ( .f 0 6 ) N a s tr a n X -Y Pu n c h ( .p c h ) L S D y n a D 3 PL O T (. d 3 p lo t) N a s tr a n O P2 ( .o p 2 ) Ab a q u s O u tp u t D a ta b a s e (. o d b ) C a ti a V5 ( .C AT Pa rt ) 1 Standardization 12 116 116 0 0 0 0 0 0 0 0 0 0 0 0 2 Readability 6 64 64 64 64 64 64 0 64 64 64 0 0 0 0 3 Documentation 12 109 109 61 30 61 30 61 61 61 61 61 61 0 0 4 Spreading throughout the application 12 118 0 88 118 88 118 88 29 29 29 88 29 118 29

5 Usage in mod-_{ule interface} 10 101 0 101 101 25 25 0 25 0 0 0 25 25 51

6 API available 9 46 46 46 0 0 0 46 0 0 0 0 0 0 0

7 Data compres-_sion 3 - - - -

8 Import/ Export

(41)

9 Encrypt ability 3 0 0 - 0 - - - 0 10 Modularity 5 49 49 49 49 49 49 49 49 49 49 49 49 49 24 11 Data content (per module interface) 14 29 57 0 0 57 29 57 57 57 57 57 57 29 0 FE-result Template Diagram Document Plot Rating points 631 441 408 362 344 314 300 285 260 260 255 221 220 104 Maximum achievable points 801 611 607 532 542 513 499 484 458 458 453 420 419 274

Table 25: Results for Structure: Data Collection – Post-Processing

Extenstions Recommendation STEP AP 214 FE Results Plot Diagram Template

Not recommended due to limited FE model representation

STEP AP 209 Plot Diagram Template

Recommended. If needed, use ex-ternal references to plots and dia-grams.

LS Dyna (.key) FE Results Plot Document Diagram Template Standardization

Not recommended due to limited ca-pability to represent FE results. May require further review.

Abaqus Input File (.inp) FE Results Plot Document Diagram Template Standardization

Not recommended due to limited ca-pability to represent FE results. May require further review.

(42)

Data Format Necessary Extenstions Recommendation LS-Dyna AS-CII Database Diagram Template Document Standardization

May require further review.

Abaqus Result File (.fil) Diagram Template Document Plot Standardization

LS-Dyna BINOUT Diagram Template Document Standardization

Consider in case a binary format is preferred for performance reasons. May require further review.

Nastran Punch (.pch) Diagram Template Document Plot Standardization

Nastran X-Y Punch (.pch) Template Document Plot Standardization

Nastran f06 Diagram Template Document Standardization

LS-Dyna D3PLOT Diagram Template Document Standardization

Nastran OP2 Diagram Template Document Plot

Standardization

(43)

Data Format Necessary Extenstions Recommendation Abaqus Output Database (.odb) Diagram Template Document Plot

Openness & Stan-dardization

Table 26: Gap Analysis for Structure: Data Collection – Post-Processing

6.6.1.3 M_Structure_S3: Data Preparation & Discretization – Solving Model Creation

For this module interface, the same data formats are recommended as for the M_Structure_1 in-terface, see section 6.1.1.

6.6.1.4 M_Structure_S4: Solving Model Creation – Post Processing

For this module interface, the same data formats are recommended as for the M_Structure_1 in-terface, see section 6.1.1.

6.6.1.5 M_CFD_S1: Data Preparation & Discretization – Solving

For this module interface, the same data formats are recommended as for the M_CFD_4 interface, see section 6.4.2.

(44)

7 Conclusion and Outlook

Based on the identified module interfaces and the evaluation, data formats were rated concerning their usability at each of the module interfaces. Based on agreed criteria, formats were first pre-selected, then evaluated in detail at each of the 16 interfaces. Finally, the results were summarized and contemplated concerning plausibility and stability. Gaps were identified which would need to be closed to fully fulfill the requirements at each interface for the highest rated formats.

The most outstanding conclusion from these results was the fact that in most cases, there is not one format which can fulfill all given requirements. That makes either extensions to the best fitting data formats necessary, or several complementary data formats have to be used jointly. Exten-sions to existing formats – both standards and proprietary – are usually burdened with high finan-cial and time efforts, as well as restricted by organizational and market boundary conditions. This poses the question if the desire to have a monolithic data format, which fulfills all requirements for a given interface, is necessary and success-oriented.

As an alternative, it might turn out to be a promising approach to investigate which data types can be transferred separately, and which are closely coupled. Based on that, modular data formats can be defined, where a best-fit is defined for given subsets of the data types at an interface. This would also consider the fact that many data types occur at several interfaces, even though the overall scope of the interface might be different.

Further investigations of which way will be the best to reduce the number of used data formats as much as possible will be in the focus of future activities.

An entirely different, but also important aspect is that of performance. There was a discussion in how far binary formats have an overall advantage over ASCII files. In addition, the implementation of the processor to import and export a certain data format from and into a given application is an-other point to consider. Practicability in application covers even more aspects, ranging from file sizes (relevant for transfer times) to the granularity of access provided by APIs. Further review of the recommended data formats to these respects is recommended by both key users and API vendors. The so far achieved evaluation results conclusions shall be seen as an invitation for fur-ther discussion.