A CAE Data Model for Simulation Frameworks
Ken Versprille, Ph.D., PLM Research Director, CPDA Michel Vrinat, Senior Analyst, CPDA

Collaborative Product Development Associates, LLC (CPDA), 222 Grace Church Street, Port Chester, NY 10573, specializes in collaborative research, documenting and analyzing PLM trends in engineering, manufacturing, and technical computing.

Authors’ Note: Ongoing research into the topic of CAE Data Model Management is of particular interest relative to Dassault Systèmes’ announcement of SIMULIA, “a new unified, open platform supporting all simulation domains.”

Simulation and analysis are too often performed in isolation, lacking sufficient collaboration from the IT infrastructure. Moreover, current approaches with simulation tools tend to isolate disciplines from each other — a serious shortcoming. Firm coordination would provide major benefits as most simulation and analysis targeting a manufacturing process cover the same system or part, share data, and often involve mutual dependencies on the results.

CAE solutions and CAE data management need to be re-architected to take into account a new paradigm: CAE Data Model management. The scope extends well beyond file management, input data deck concepts, and the sequential execution of software codes. It requires data management at a fine-grain level, the management of processes such as analysis methodology. Most of all, new approaches must capture and leverage engineering knowledge.

Simulation and analysis present major opportunities for reuse with high returns, based on fully leveraging the time and efforts of experts, and capturing their knowledge in formalized processes and templates for use by production engineers and designers.

The CAE Data Model has to be built on three main layers:

• The analysis abstract model
• The analysis physical model
• The analysis execution model

The most important concept of a CAE Data Model is the level of abstraction and the richness of the information to be captured. It includes project and part identification, performance requirements, geometric model references, rules that apply (from methodology regulations or industry), objectives of the analysis, and the identification of miscellaneous data sources (loads, physical properties, material characteristics).

The abstract model represents the invariant of the analysis work that can be performed across all expert domains, and across all codes. It includes input as early as the conceptual phase on performance requirements and functional specifications. The company know-how, the definition of rules and methodology, and constraints that define the valid domain are all represented there. The analysis information refers to a particular product type, as represented by the product definition, reference geometry, analysis assumptions, loads, or materials.

The physical model layer represents an instantiation of the abstract model for a particular set of geometrical values as defined by a meshed or idealized representation, and/or non-geometrical values such as loads, material, boundary conditions, and the choice of analyses to be run.

The execution layer translates the physical model into the format required for execution by a particular solver.

ISSUES WITH CURRENT INITIATIVES

Most vendors concentrate on CAE data management, as distinct from the CAE Data Model. While the effort supports a necessary function, it is not enough to meet customer expectations in term of benefits and KPIs (Key Performance Indicators). CAE data management will reduce significantly the time wasted by engineers searching for information, and the work wasted using incorrect data. It will not, however, cover the more strategic issues and challenges of reusing past design and analysis work, standardizing analysis, and streamlining simulation and analysis across disciplines for the complete product development cycle.

Several leading-edge end users have initiated ambitious and costly projects to address the simulation and analysis with new approaches. These efforts drive in the right direction – defining a CAE Data Model up front, before specifying any analysis data, to capture the context for the analysis, the type of part to be checked, the analysis process that applies, and all the physical and environment information necessary for execution. That approach capitalizes on a company’s know-how, and brings major benefits in terms of the development cycle time and the quality of the design.

However, the solutions currently being developed by end users are not mainstream. They represent prototypes that have yet to reach large-scale deployment, or they are primarily pilots applied on very specific parts and analysis. In all cases, end users’ developments have not been built in close cooperation with the major suppliers.

Several difficult issues have not yet been addressed, due to the complexity of the solution. A more complete solution could only be developed with the close cooperation and long-term support, both technical and economic, of PLM vendors. The main issues that require such cooperation include:

• Idealization of CAD models for analysis: This is preliminary to discretization and meshing. It requires a strong understanding and control of geometric tools. CAD tools have all the required capabilities, but it is not practical for the end user to get involved at this level. Industry- or company-specific rules and generic models should be defined by end users.
• Building and maintaining a complex data model: To represent the complete analysis structure of a car or an aircraft requires very strong and reliable tools for data modeling, relationship and dependencies management, as well as configuration and change management. Most of the commercial PDM tools will be able to support a complex data model, with minimal customization and adaptation.
• Integration with multiple tools: One of the most cumbersome tasks downstream in the analysis process relates to the generation of the data format required by the different solvers. Some companies are using several hundreds of formats. This may be simplified by the use of standard formats or format generators that vendors may want to provide.
• The need for support along the lifecycle: The combination of data modeling, configuration management, and change management over the product development lifecycle is generally not addressed. This is also an area where end user “in-house” code would not be appropriate, considering the availability of fully supported functions in commercial products.

This universal skeleton of a data model can be described in XML, for implementation on any PDM system supporting XML schema. The schema has to be extensible so that additional components may be defined to match the specific structure of the actual project.

The major objects and containers defined in this schema include:

• The overall topology of the product – structure and type of parts
• The characteristics of assemblies, sub-assemblies, and parts
• Part type in terms of family group, standard reference, or generic part reference
• Relationship and dependencies – part to part, part from/to assembly, or part from/to other information container

From this high-level, abstract model, a number of intermediate steps must be covered to get to a final data input set for a solver. The CAE Data Model needs to support:

• For model idealization
• Access to a library of generic parts with pre-defined idealization processes that can be applied to actual part geometry
• Access to idealization rules and parameters to facilitate manual idealization
• Management of the resulting data and its relationship with the source reference model
• For meshing or discretization
• Automated meshing based on parameters associated with the part in the CAE Data Model and specifying, e.g., mesh type, density, and size
• Access to rules and parameters to facilitate the meshing of the model
• Management of the resulting data and its relationship with the source reference model
• Analysis methodology and solver selection
\
• Automated selection based on rules and part types
• Manual selection based on specific part characteristics
• Loads selection and final load case data definition
• Access to description of the vector load force, or field array value, for example, or a pointer to a load description in an external database
• Selection of the load cases based on rules that vary by project, methodology, or regulations
• Distribution of the loads characteristics onto the idealized model
• Mapping of the load to the model, after idealization and discretization have been completed
• Formatting to match the solver requirements
• Extraction of material characteristics from the external database, and formatting to match the idealized model
• Assignment of material based on rules and part type
• Access to material characteristics, or a pointer to a material database
• Distribution of the material characteristics onto the idealized or discretized model

When going down to a lower level of detail describes the information, such as geometry, meshing, material characteristics, physical properties, loads, and boundary conditions, available standard descriptions such as STEP AP209, AP203, and AP214 may improve efficiency. This would not require full implementation of the standard, with its complete formalism, unless appropriate. For example, it might not be supported by the PDM or authoring tool. The standard at minimum provides a ready reference, a library to tap, to save time and avoid re-inventing a long list of basic sets of information.

The integration within a particular PDM tool can be done through its API, and preferably through web services when available

To cover the different functions of the CAE Data Model, it is necessary to host it in a CAE framework that will provide the following services:

• Common services
• Data structure representation and browsing
• Visualization that supports the geometry, numerical values, and graphics
• Search functions for fields, semantics, and links
• Formatting data for import/export
• Style sheets for reporting
• Engineering unit conversion
• Advanced services
• Lifecycle support
• Change management
• Impact analysis
• External database references
• Input parameters or variables
• Reporting data
• Idealization standards
• Methodology templates
• Analysis templates
• Reporting templates

One very important issue to deal with in the definition of the CAE Data Model is the line between public and confidential information. What could be made standard, or commercially available, versus what represents a company-specific competitive advantage?

The companies that implement the CAE Data Model along the lines described will potentially benefit from a tremendous competitive advantage, as far as simulation and analysis reliability and cycle time are concerned. At the same time, they must avoid developing it alone, at the risk of being locked into a dead end; they should instead drive vendors to develop a fully supported commercial offering.

How much could be, or has to be, provided by vendors as a technology for companies to implement their CAE Data Model? Is the concept itself such a competitive weapon that no one will share with others any ideas, pitfalls, or benefits? What is the role of AP209 as a standard for data description?

This remains to be clarified and creates real issues. But the opportunity now remains open to those willing to take the first step in the open, and initiate the momentum necessary to make the CAE Data Model a practical and efficient approach.