Automotive CAE Integration.

WHITEPAPER Automotive CAE Integration. Requirements and Evaluation. of Interfaces. 2009 AUDI AG BMW AG Daimler AG Dr. Ing. h. c. F. Porsche AG Volkswagen AG PROSTEP AG

Automotive CAE Integration 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 ii

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 candidates 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 freedom 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, reference 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 future developments. Based on this information various tools and data formats currently used across the defined functional 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. iii

Contents 1 Introduction... 1 2 The Big Picture... 1 3 Defining Reference Processes and Functional Modules... 2 3.1 Modules in the xdm Tool Layer... 2 3.1.1 Module PDM... 2 3.1.2 Module TDM... 3 3.1.3 Module SDM... 4 3.2 Modules in the Authoring Tool Layer... 5 3.2.1 Module CAD... 5 3.2.2 Module CAE Data Collection... 5 3.2.3 Module CAE Data Preparation and Discretization... 6 3.2.4 Module CAE Component Assembly... 7 3.2.5 Module CAE Solving Model Creation... 7 3.2.6 Module CAE Solving... 8 3.2.7 Module CAE Post-Processing... 8 3.3 Module Interfaces... 9 4 Requirements for and Evaluation of CAE Data Formats... 10 5 Criteria and Interpretation... 11 5.1 Evaluation Criteria... 11 5.2 Interpretation and Verification of Evaluation Results... 12 5.3 Feedback on the Evaluation Results... 13 6 Data Formats for Module Interfaces... 13 6.1 Data Collection Data Preparation & Discretization... 15 6.1.1 M_Structure_1... 15 6.1.2 M_CFD_1... 18 6.2 Data Preparation & Discretization Component Assembly... 20 6.2.1 M_Structure_2... 20 6.2.2 M_CFD_2... 22 6.3 Component Assembly Solving Model Creation... 24 6.3.1 M_Structure_3... 24 6.3.2 M_CFD_3... 26 6.4 Solving Model Creation Solving... 27 6.4.1 M_Structure_4... 27 6.4.2 M_CFD_4... 29 6.5 Solving Post-Processing... 31 6.5.1 M_Structure_5... 31 6.5.2 M_CFD_5... 33 6.6 Sidetracks... 35 6.6.1 Structure... 35 7 Conclusion and Outlook... 40 Annex A: References... 41 Annex B: Definition of Data Types... 41 iv

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 identified 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 increased 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 providing 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 interests 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 accepted 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 integration, 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 manipulating systems (at the authoring tool layer). Each layer covers the different areas under investigation: design (CAD, PDM/TDM 1 ), simulation (CAE, SDM 2 ) as well as physical test (CAT, TestDM 3 ). Physical Testing is so far out of scope. 1 TDM: Team Data Management 1

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, preprocessing, solving, and post-processing, it was found during the definition of the reference processes 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 interfaces where defined information states are conveyed. These interfaces 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 CAT: Computer Aided Testing 2

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 development 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 functionality 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) 3

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 under 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 characterized 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 underneath 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 long-term archiving of simulation data (e.g. due to legal requirements) 4

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 functionalities 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 borderlines 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) results 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, stiffness, 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) 5

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 simulation, 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 gathered 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. 6

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

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 interpretation 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 the preparation of results data as input for subsequent computation processes 8

3.3 Module Interfaces The modules defined above share interfaces with each other. Besides the straightforward interfaces 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 Figure 3: Module Interfaces CFD 9

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 investigation 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 consistently. 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 entirety of data formats found to be in use in the automotive industry was assessed in a first evaluation with the intent to limit the number of formats for closer investigation. 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 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 4 Spreading throughout the application Market penetration 11,8 10

5 Usage in module interface Quantity of usage in each interface 10,1 6 API available Toolkits for interface implementation available 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 10 Modularity Parts of the data content can be encrypted, encoded Parts of the data content can be encapsulated Specific data format criteria 2,9 4,9 Data format contains an assortment of the following data types depending on the interface: Metadata Product structure Parameter Geometry FE-model FE-result 11 Data content (per module interface) Joining technique MKS-model 14,3 MKS-result Media Table Template Diagram Document Plot Plot (3D) 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 criteria and Documentation are partially related: a standardized data format is always documented, whereas a documented data format is not necessarily standardized. There- 11

fore, the current choice of criteria is intended, the partial interdependencies do not present a disadvantage and could only not avoided with justifiable effort. For a better overview, the criteria can be arranged in groups. The associated weights of the individual criteria will then be summed up within each group of criteria. The proposed grouping or requirements with the corresponding individual criteria along with the resulting total weighting can be seen in Table 2 below: Group of Requirements Openness of Format Readable Format Documentation Availability of APIs Functionality of Format Data types Modularity Encryptability Awareness level of Format Distribution in application Usage in modules Performance of Format Data compression Import / Export time Weighting 39 % 22 % 22 % 17 % Table 2: Groups of Requirements The grouping introduced above illustrates that for instance the openness of a format plays an important role. In addition, groups of direct and indirect requirement can be discerned. While openness, 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 ranking 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 in- 12

stance, the availability of an API for a format was rated, but not whether the API provides full access, 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 necessary 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 sector. However, these often are more of a programming language than a data exchange format, 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 directly 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 module 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 requirements and criteria defined both in general and for each module interface in specific. 13

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 interface. 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:. 14

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 Weighting [%] STEP AP214 (.stp,.step) IGES (.igs,.iges) VDA-FS (.vda,.vdafs) LS Dyna (.key) 3DPDF (.pdf) Abaqus Input File (.inp) JT (.jt) PLMXML (.plmxml) Pro/E Geometry (.prt) Catia V5 (.CATPart) Catia V5 (.CATProduct) 1 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 5 Spreading throughout the application Usage in module interface 12 118 88 29 88 0 118 59 0 59 29 29 10 101 101 51 101 0 101 0 0 76 51 25 15

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 references LS Dyna (.key) Product Structure Media Documents Consider only if the recommended combination of STEP AP209 and AP214 causes considerable problems in application. Abaqus Input File (.inp) Product Structure Media Documents Consider only if the recommended combination of STEP AP209 and AP214 causes considerable problems in application. 3DPDF Connection Information (ongoing) Is not a classic data exchange format in itself, but PRC geometry representation and data container 16

Data Format Necessary Extensions Recommendation 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 application JT FE Model Connection Information Media Documents (ongoing) Visualization format. Because of the current geometry representation and the missing FE model entities not applicable for this module interface. IGES Connection Information Media Documents Outdated format, there not recommendable as strategic format. Table 4: Gap Analysis for Structure: Data Collection - Data Preparation 17

6.1.2 M_CFD_1 Figure 5: Tools, Data Formats and Data Types at M_CFD_1 Criteria Data format Weighting [%] STEP AP214 (.stp,.step) STL (.stl) Nastran Bulk Deck (.bdf,.nas,.dat) Pro/E Geometry (.prt) Catia V5 (.CATPart) Catia V5 (.CATProduct) 1 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 5 Spreading throughout the application Usage in module interface 12 118 59 29 59 29 29 10 101 76 101 76 51 25 6 API available 9 46 91 0 0 0 0 7 Data compression 3 - - - - - - 8 Import/ Export time 14 - - - - - - 18

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 Data Format Necessary Extensions Recommendation 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 recommendable as a strategic format Nastran Bulk Data Document Openness & Consider only if the recommended combination of STEP AP209 and AP214 causes considerable problems in application. Table 6: Gap Analysis for CFD: Data Collection - Data Preparation 19

6.2 Data Preparation & Discretization Component Assembly 6.2.1 M_Structure_2 Figure 6: Tools, Data Formats and Data Types at M_Structure_2 Criteria Data format Weighting [%] LS Dyna (.key) STEP AP 209 Abaqus Input File (.inp) Nastran Bulk Deck (.bdf,.nas,.dat) Medina Binary Input File (.bif) Ansa 1 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 5 Spreading throughout the application Usage in module interface 12 88 0 118 29 0 0 10 101 0 101 101 101 76 6 API available 9 46 46 0 0 46 0 7 Data compression 3 - - - - - - 8 Import/ Export time 14 - - - - - - 9 Encrypt ability 3-0 0 - - - 10 Modularity 5 49 49 49 49 24 24 20

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 Maximum achievable points 749 696 674 645 538 406 Table 7: Results for Structure: Data Preparation - Component Assembly Data Format Necessary Extensions Recommendation LS Dyna (.key) Recommendation for use as proprietary format. If applicable, use STEP AP209 as standard. STEP AP 209 - Recommended. Abaqus Input File (.inp) Consider only if the recommended formats LS Dyna and AP209 cause considerable problems in application Nastran Data Bulk Consider only if the recommended formats LS Dyna and AP209 cause considerable problems in application Medina Binary Input File Connection Information Consider if a binary format is preferred for performance reasons. Table 8: Gap Analysis for Structure: Data Preparation - Component Assembly 21

6.2.2 M_CFD_2 Figure 7: Tools, Data Formats and Data Types at M_CFD_2 Criteria Data format Weighting [%] STEP AP214 (.stp,.step) IGES (.igs,.iges) STL (.stl) Pro/E Geometry (.prt) Catia V5 (.CATPart) 1 12 116 58 58 0 0 2 Readability 6 64 64 64 0 0 3 Documentation 12 109 121 121 0 0 4 5 Spreading throughout the application Usage in module interface 12 118 88 59 59 29 10 101 101 76 76 25 6 API available 9 46 46 91 0 0 7 Data compression 3 - - - - - 8 Import/ Export time 14 - - - - - 22

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 Data Format Necessary 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 recommendable as a strategic format Table 10: Gap Analysis for CFD: Data Preparation - Component Assembly 23

6.3 Component Assembly Solving Model Creation 6.3.1 M_Structure_3 Figure 8: Tools, Data Formats and Data Types at M_Structure_3 Criteria Data format Weighting [%] LS Dyna (.key) STEP AP 209 Abaqus Input File (.inp) Nastran Bulk Deck (.bdf,.nas,.dat) Medina Binary Input File (.bif) Ansa 1 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 5 Spreading throughout the application Usage in module interface 12 88 0 118 29 0 0 10 101 0 101 101 101 76 6 API available 9 46 46 0 0 46 0 7 Data compression 3 - - - - - - 8 Import/ Export time 14 - - - - - - 9 Encrypt ability 3-0 0 - - - 10 Modularity 5 49 49 49 49 24 24 11 Data content 14 143 143 143 143 143 143 24

(per module interface) FE-model Rating points 551 526 504 446 374 243 Maximum achievable points 749 696 674 645 538 442 Table 11: Results for Structure: Component Assembly - Solving Model Creation Data Format Necessary Extensions Recommendation LS Dyna (.key) Recommendation for use as proprietary format. If applicable, use STEP AP209 as standard STEP AP 209 - Recommended. Abaqus Input File (.inp) Consider only if the recommended formats LS Dyna and AP209 cause considerable problems in application Nastran Data Bulk Consider only if the recommended formats LS Dyna and AP209 cause considerable problems in application Medina Binary Input File Consider if a binary format is preferred for performance reasons Table 12: Gap Analysis for Structure: Component Assembly - Solving Model Creation 25

6.3.2 M_CFD_3 Figure 9: Tools, Data Formats and Data Types at M_CFD_3 Data format Criteria Weighting [%] STL (.stl) STEP AP 209 1 12 58 116 2 Readability 6 64 64 3 Documentation 12 121 109 4 5 Spreading throughout the application Usage in module interface 12 59 0 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 11 Data content 14 107 143 26

(per module interface) Geometry FE-model Rating points 625 526 Maximum achievable points 795 696 Table 13: Results for CFD: Component Assembly - Solving Model Creation Data Format Necessary Extensions Recommendation STEP AP 209 - Recommended. If necessary in combination with STEP AP214 should the AP209 geometry representation not be fully sufficient. STL - Not recommended since both geometry 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 Figure 10: Tools, Data Formats and Data Types at M_Structure_4 27

Criteria Data format Weighting [%] LS Dyna (.key) STEP AP 209 Abaqus Input File (.inp) Nastran Bulk Deck (.bdf,.nas,.dat) 1 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 7 Data compression 3 - - - - 8 Import/ Export time 14 - - - - 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 Data Format Necessary Extensions Recommendation LS Dyna (.key) Recommendation for use as proprietary format. If applicable, use STEP AP209 as standard STEP AP 209 - Recommended Abaqus Input File (.inp) Consider only if the recommended formats LS Dyna and AP209 cause considerable problems in application Nastran Data Bulk 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 28

6.4.2 M_CFD_4 Figure 11: Tools, Data Formats and Data Types at M_CFD_4 Criteria Data format Weighting [%] STL (.stl) STEP AP 209 Fluent (.msh) CFX (.def) Star CCM+ (.ccm) Star-CD (.geom,.prob) 1 12 58 116 0 0 0 0 2 Readability 6 64 64 64 0 0 0 3 Documentation 12 121 109 61 0 - - 4 5 Spreading throughout the application Usage in module interface 12 59 0 0 0 0 0 10 76 0 0 0 25 0 6 API available 9 91 46 46 46 - - 7 Data compression 3 - - - - - - 8 Import/ Export time 14 - - - - - - 9 Encrypt ability 3 0 0 - - - - 10 Modularity 5 49 49 49 49 49 49 11 Data content 14 143 143 143 143 143 143 29

(per module interface) FE-model Rating points 660 526 361 237 217 191 Maximum achievable points 830 696 560 436 628 603 Table 17: Results for CFD: Solving Model Creation Solving Data Format Necessary Extensions Recommendation STEP AP 209 - Recommended Fluent (.msh) 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. Table 18: Gap Analysis for CFD: Solving Model Creation Solving 30

6.5 Solving Post-Processing 6.5.1 M_Structure_5 Figure 12: Tools, Data Formats and Data Types at M_Structure_5 Data format Criteria Weighting [%] STEP AP 209 LS Dyna ASCII Database Abaqus Result File (.fil) LS Dyna BINOUT (.binout) Nastran Punch (.pch) Nastran f06 (.f06) Nastran X-Y Punch (.pch) LS Dyna D3PLOT (.d3plot) Abaqus Output Database (.odb) Nastran OP2 (.op2) PamCrash Result (.dsy) PamCrash Time History (.thp) 1 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 4 Documentation Spreading throughout the application 12 109 61 30 61 61 61 61 61 0 61 61 61 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 31

face 6 API available 9 46 0 0 46 0 0 0 0 0 0 23 23 7 8 Import/ Export time 3 - - - - - - - - - - - - 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 Data Format Necessary Extensions Recommendation STEP AP 209 - Recommended Data compression LS-Dyna AS- CII Database Consider only if the recommended format AP209 causes considerable problems in application Abaqus Input File (.fil) Consider only if the recommended format AP209 causes considerable problems in application LS-Dyna NOUT BI- Consider in case a binary format is preferred for performance reasons Nastran Punch (.pch) Consider only if the recommended format AP209 causes considerable problems in application Nastran X-Y Punch (.pch) Consider only if the recommended format AP209 causes considerable problems in application Nastran f06 Consider only if the recommended format AP209 causes considerable problems in application 32

Data Format Necessary Extensions Recommendation LS-Dyna D3PLOT Consider in case a binary format is preferred for performance reasons Abaqus Output Database (.odb) Openness & Consider in case a binary format is preferred for performance reasons Nastran OP2 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 Figure 13: Tools, Data Formats and Data Types at M_CFD_5 Data format Criteria Weighting [%] STEP AP 209 Ensight (.case) Ensight (.geo) 1 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 33

5 Usage in module interface 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 Data Format Necessary Extensions Recommendation STEP AP 209 - Recommended Ensight (.case) Document Consider only if the recommended format AP209 causes considerable problems in application Table 22: Gap Analysis for CFD: Solving - Post-Processing 34