Product Lifecycle Management — Realizing the Promise of CAE: Faster, Better, Cheaper Designs

by Malcom Panthaki, Founder and Chief Executive, Comet Solutions, Inc. & Don Brown, Founder and Chairman, D.H. Brown Associates Inc.

Abstractions and Tool Independent Languages to Support Virtual Prototyping

We believe that analysts have worked at the wrong level of abstraction. They've worked directly with the individual analysis tools, learning a particular language, locking them into the particular jargon of each.

The bottom line, true virtual prototyping environments, the ability to model every aspect of complex systems and simulate the performance on the computer, still represents a myth. Lots of folks claim they have a virtual prototyping environment, but they're limited in scope. Despite over 30 years of CAE development, the tools have not delivered on the promise of virtual prototyping the ability to simulate any engineering system, at any level of model fidelity or accuracy, from abstract, high level, conceptual modeling all the way down to full, 3-D meshes supporting direct analysis.

Problems with the CAE Status Quo

• Many narrow, specialized tools, each with their own language, abstractions and data formats
• Thin GUIs/scripts "manage" the Application Zoo (changes to the process, engineering systems, physics or tools are manual, tedious and costly)
• Optimization and uncertainty quantification - primary goals of any engineer - are not integrated into the design/ analysis environment
• No unified, tool-independent interface to specify models and simulation operations
• Minimal support for linking simulation data to the rest of product definition data and design decisions
• Tools that support integration between systems level analyses and detailed, 3-D geometry/mesh-based analyses are, at best, ad hoc
• The Design Process is not captured as data with links to both the design and simulation data
• Limited tools for parametric modeling
• Dealing with complex multi-physics models with varying degrees of model fidelity at the component level is manual, tedious and costly, when possible
• Minimal support for large, distributed teams of designers/analysts and distributed model and results data that are in multiple formats
• Limited tools for the efficient management of simulation models and results
• Software and controls are not simulated

What are the consequences? Full systems analysis, when possible, requires special programming for each case. Multi-physics environments are severely constrained.

Doing CAE business as usual is no longer either acceptable or necessary. You folks ought to demand more.

What should virtual prototyping really be? The environment should support simulation of system behavior at all levels of model fidelity, going all the way from back of the envelope, conceptual calculations and models, to functional defined interactions that may employ spreadsheets, down to fully detailed 3-D analyses with finite element meshes. There should be a rapid performance assessment of design tradeoffs, rapid inexpensive searches of the design space using optimization, stochastic analysis, and the support of heuristic design rules. Software's an important component of these complex systems and must be covered along with the hardware. In short, the technical environment should support all desired physics, and their interaction, and all desired levels of model fidelity.

Rapid, inexpensive extensibility represents a critical requirement and objective. Finally, and most importantly, reuse must be readily facilitated for all existing geometric models, all meshing, and extended to the visualization and analysis tools. The environment should bring the broad tool set all together carefully under one roof.

Under development since 1994, the Computational Modeling Toolkit, or CoMeT, Provides a framework that will support the creation of virtual prototyping environments.

CoMeT supports the tools and abstractions that capture the engineering analysis process, the steps involved in running analyses. These must be and are closely linked with all of the models and the simulation results that the process itself generates. The solution must remain independent of the tools employed to solve the CAE problems.

Key Solutions

• Provide tools and abstractions to capture the Engineering Analysis Process in data, linked to the CAE Models and simulation results
• Provide a single, extensible, tool-independent interface (language) to specify all CAE processes (tasks) and models
• Provide a single, extensible CAE Model that serves the needs of all CAE analyses - for any level of model fidelity, any physics, and any numerical techniques
• Provide efficient management, query and data mining tools for the avalanche of distributed CAE data and results
• Provide integrated tools for optimization, parametric studies, uncertainty quantification and software controls/simulation
• Support Libraries for CAE process/ component reuse - the capture/retention of corporate CAE knowledge

…And all of this, independent of the underlying simulation tool and its results, or the abstractions and formats, while still relying on all the existing CAE tools.

Second, we provide a single, extensible, and tool independent interface or language, that supports the specification of all CAE tasks and modeling operations. Third, all results reside in a single, unified, and extensible data model that can capture all CAE models for all physics, at any level of model fidelity, using any numerical techniques available to solve the problem.

All of these solutions are supported, independent of the underlying simulation tool, the format of the results, and the abstractions and formats for inputting information, while still facilitating the use of all of the tools.

CoMeT also supports the creation of site-specific abstractions for analysis. Engineers may work in a language that facilitates development in their particular environment, and each site has its own types of objects that it prefers. This flexibility extends to dynamic types that allow users to work with geometry, meshes, fields, etc., regardless of their underlying format. In these cases, XML supports the flexibility needed for dynamic types.

As a primary technical goal, a unified data model in CoMeT supports a level of abstraction once removed from the actual numerical models built with specific analysis tools. The basic model does not tie to any particular set of tools that may link tightly to solve any specific problem. Rather, the neutral formats may map to myriad extensions. Also, the basic skeleton is not physics specific. By building on very general concepts, such as "fields", the huge mass of specific requirements for individual design environments can be met with incremental dynamic extensions, adding only the new attributes that build on the established definitions. That extensibility also minimizes the duplication of code defining common behavior, common structures, or common concepts applying to processes.

Multi-physic support includes extensible types that may be added to the system dynamically. The extensibility mechanism may be data driven. In other words, new types of objects may be added to the environment without having to write new code. Indeed, the very structure of the model, how it's put together, is specifiable in data including both the definition of the components, as well as how they fit together. That flexibility, and the separation of component definition, structure, and behavior promotes reuse.

Considering the basic elements of the data model itself, a small set of statically defined objects form the core or the skeleton of the model. They support the flexibility to define whatever dynamic types may be required for specific analyses that attach to the skeleton to enrich it, to add new data, and to add new meaning to the skeleton itself.

Neutral abstractions support maximum flexibility for extensions. Basic elements define the skeletal structure - parts, material specifications, and the material model as an example. The flexibility of the definition of those concepts with "neutral abstractions" determines the range of design environments that can be readily supported. An important tradeoff, the amount of information that can be appropriately abstracted in the definitions determines the amount of data that is not continuously duplicated with extensions to dynamic entities, thereby minimizing overheads.

Generic data structures and operations need to serve these key abstractions. In design, there's an unbounded number of external formats that must be read from, and written to, various types of geometry formats, various types of mesh formats, various types of field formats. However, the system must shield users from the complexities and inefficiencies of dealing with these multiple formats. The notion of neutral abstractions serves the purpose.

Overall, CoMeT is a framework supports the creation of true virtual prototyping environments, helping to realize the promise of CAE. By providing information faster to the decision-makers, they can make better decisions and make them faster. Ultimately, CoMeT supports faster, better, and cheaper designs.

This executive summary, as well as the full report, are both derived from Malcolm's presentation at D.H. Brown Associates, Inc.'s latest annual conference, Implementation Roadmap. Those interested in the full report should contact lilyb@dhbrown.com.