Planning Meeting for Product, Lifecycle Management,

Planning Meeting for Product, Lifecycle Management,
and Systems Engineering Models May 20, 2003 NIST • Gaithersburg MD (via telecon) Elements towards Next-Generation Knowledge Representations and Product Modeling Techniques

See backup slides for other examples & references
Contents Purpose: Help identify comparison factors and encourage thinking about next-generation needs Multiple views in a knowledge representation Declarative thinking Object graph view of model interoperability Some factors for comparing knowledge representations Leveraging multiple standards Managing computing environments via systems engineering methods Elevated terminology & thinking See backup slides for other examples & references

Contents Multiple views in a knowledge representation
Human-sensible & computer-sensible Graphical, lexical, application-oriented Declarative thinking Multi-directional (non-causal) With derivable lower-level procedural approaches Object graph view of model interoperability Leveraging multiple standards Managing computing environments via systems engineering methods Elevated terminology & thinking Examples from Constrained Objects (COBs) & CAD-CAE Integration

COB Structure: Graphical Forms Tutorial: Triangle Primitive
a. Shape Schematic-S c. Constraint Schematic-S b. Relations-S Basic Constraint Schematic-S Notation d. Subsystem-S (for reuse by other COBs) Aside: This is a “usage view” in AP210 terminology (vs. the above “design views”)

COB Structure (cont.): Lexical Form Tutorial: Triangle Primitive
e. Lexical COB Structure (COS) COB triangle SUBTYPE_OF geometric_shape; base, b : REAL; height, h : REAL; diagonal, d : REAL; area, A : REAL; RELATIONS r1 : "<area> == 0.5 * <base> * <height>"; r2 : "<diagonal>**2 == <base>**2 + <height>**2"; END_COB; for reference: c. Constraint Schematic-S

Example COB Instance Tutorial: Triangle Primitive
Constraint Schematic-I Lexical COB Instance (COI) example 1, state 1.1 state 1.0 (unsolved): INSTANCE_OF triangle; base : 2.0; height : 3.0; area : ?; diagonal : ?; END_INSTANCE; state 1.1 (solved): area : 3.0; diagonal : 3.60; example 1, state 2.1 . state 2.1 (solved): INSTANCE_OF triangle; base : 2.0; height : 9.0; area : 9.0; diagonal : 9.22; END_INSTANCE; Basic Constraint Schematic-I Notation

Multi-Directional I/O (non-causal) Tutorial: Triangle Primitive
Constraint Schematic-I Lexical COB Instance (COI) example 1, state 2.1 state 2.1 (solved): INSTANCE_OF triangle; base : 2.0; height : 9.0; area : 9.0; diagonal : 9.22; END_INSTANCE; state 3.0 (unsolved): height : ?; area : 6.0; diagonal : ?; state 3.1 (solved): height : 6.0; diagonal : 6.32; example 1, state 3.1

COBs as Building Blocks Tutorial: Triangular Prism COB Structure
a. Shape Schematic-S c. Constraint Schematic-S b. Relations-S e. Lexical COB Structure (COS) d. Subsystem-S (for reuse by other COBs) COB triangular_prism SUBTYPE_OF geometric_shape; length, l : REAL; cross-section : triangle; volume, V : REAL; RELATIONS r1 : "<volume> == <cross-section.area> * <length>"; END_COB;

Example COB Instance Tutorial: Triangular Prism
Constraint Schematic-I Lexical COB Instance (COI) example 1, state 1.1 state 1.0 (unsolved): INSTANCE_OF triangular_prism; cross-section.base : 2.0; cross-section.height : 3.0; length : 5.0; volume : ?; END_INSTANCE; state 1.1 (solved): cross-section.area : 3.0; volume : 15.0; Basic Constraint Schematic-I Notation

COB Modeling Languages & Views
Structure Level (Template) Instance Level

Declarative thinking Object graph view of model interoperability Include connections with lower-level models & COTS tools Facilitate solution management & reasoning control Some factors for comparing knowledge representations Leveraging multiple standards Managing computing environments via systems engineering methods Elevated terminology & thinking Examples from Constrained Objects (COBs) & CAD-CAE Integration

Constrained Object Panorama for Multi-Fidelity CAD-CAE Interoperability Flap Link Benchmark Example

Flexible High Diversity Design-Analysis Integration Phases 1-3 Airframe Examples: “Bike Frame” / Flap Support Inboard Beam Design Tools Modular, Reusable Template Libraries Analysis Modules (CBAMs) of Diverse Feature:Mode, & Fidelity MCAD Tools CATIA v4, v5 XaiTools Analysis Tools 1.5D General Math Mathematica In-House Codes Lug: Axial/Oblique; Ultimate/Shear Image API (CATGEO); VBScript Analyzable Product Model XaiTools 1.5D Fitting: Bending/Shear Materials DB FEA Elfini* MATDB-like 3D Assembly: Ultimate/ FailSafe/Fatigue* Fasteners DB FASTDB-like * = Item not yet available in toolkit (all others have working examples)

Usage of a COB-based Analysis Template CAD-CAE Interoperability during Lug Strength Analysis
CAD-CAE Associativity (idealization usage) Geometry Material Models Solution Tool Interaction Boundary Condition Objects (links to other analyses) Model-based Documentation Requirements

Convergence of Representations
Software Development (algorithms …) Database Techniques (data structure, storage …) Flow Charts ER OMT EER UML STEP Express Constrained Object - like Representations COBs, OCL, ... Constraint graphs Objects Rules Artificial Intelligence & Knowledge-Based Techniques (structure combined with algorithms/relations/behavior)

Declarative thinking Object graph view of model interoperability Include connections with lower-level models & COTS tools Facilitate solution management & reasoning control Some factors for comparing knowledge representations Leveraging multiple standards Managing computing environments via systems engineering methods Elevated terminology & thinking

Associativity = Relations among objects
Dimensions of Associativity Some Knowledge Representation Comparison Factors Associativity = Relations among objects r1 System Y a a System X r2 System Z b Operand representation: a, b Type: numeric, logical, string, …, general object Human-sensible vs. computer-sensible Computer-sensible: Flattened vs. object/feature-oriented Other facets: security, units, uncertainty, maturity, version history, (un)known/withheld, … Relation representation: r1, r2 Relation type: Math formula, geometric constraint, computable algorithm, computer system (e.g., FEA tool), higher order constraint, arbitrary human process, ... electrical circuits analogy

Dimensions of Associativity (cont.)
Relation representation (continued) Explicit vs. implicit vs. unrecognized vs. unknown Human-sensible vs. computer-sensible Computer-sensible: Dumb string vs. smart string vs. object/feature-oriented relation Level: instance, template (schema, structure), adaptable template Other facets: priority, (in)active, plus similar facets as operands Relation directionality Uni-directional vs. multi-directional vs. iteratively multi-directional Relation duration Continuous (“live”) vs. event-controlled Relation granularity Coarse vs. fine (macro vs. micro) Associativity graph type Declarative vs. procedural Cyclic vs. acyclic Variable vs. fixed topology

Declarative thinking Object graph view of model interoperability Leveraging multiple standards Managing computing environments via systems engineering methods Including versioning & configuration mgt. of meta-models, standards, and tools Elevated terminology & thinking

Instance Browser/Editor
Tool-Product Model Schema Relationships in a Standards-Based Engineering Framework Electrical CAD Tools Mechanical CAD Tools Systems Engineering Tools Eagle Pro/E Doors Traditional Tools Mentor Graphics CATIA Slate … AP210 AP203, AP214 AP233 Smart Product Model Building Blocks Models & meta-models International standards Industry specs Corporate standards Local customizations Modeling technologies: Express, UML, XML, COBs, … AP210 AP2xx XaiTools PWA-B LKSoft, … XaiTools PWA-B pgef EPM, LKSoft, STI, … STEP-Book AP210, SDAI-Edit, STI AP210 Viewer, ... Gap-Filling Tools PWB Stackup Tool, … Engineering Framework Tool Instance Browser/Editor

Primary Technologies for Schema-based Engineering Frameworks
Based on Engineering Framework Interest Group (EFWIG) s from (dated July 13, 2002 wrt PGPDM directions) and David Leal (dated November 26, 2002).

Declarative thinking Object graph view of model interoperability Leveraging multiple standards Managing computing environments via systems engineering methods Elevated terminology & thinking

Needed Shifts in Engineering Thinking
Traditional Viewpoint Information/Knowledge-based Modeling Viewpoint Math-based models of physical behavior Learn mathematics as a modeling language Information models of physical objects Includes math-based models of physical behavior, but in their richer context Learn information representation as another type of modeling language There are physical behavior analogies between different physical domains (e.g., electrical resistance and mechanical friction). Similar information structure analogies are appearing in different product domains (e.g., parts library and part-assembly usage relationships in both physical systems and virtual systems (e.g., software components)). Note: Information models have their roots in modern mathematics (e.g. set theory).

Needed Shifts in Engineering Thinking (cont.)
Traditional Computing Viewpoint Information/Knowledge-based Modeling Viewpoint Tool usage Data / files Data exchange Translators Single tools Drawings & documents Calculations Model creation & interaction (using tools) - knowledge capture Information models & knowledge representations (objects) Model connection, associativity, interoperability (often via equality relations) Interfaces Integrated submodels Views (submodels) connected to their richer models Usage of model operations Need to elevate the concepts and terminology Objects (having structure and operations) that are interrelated.

See backup slides for other examples & references
Summary Purpose: Help identify comparison factors and encourage thinking about next-generation needs Multiple views in a knowledge representation Declarative thinking Object graph view of model interoperability Some factors for comparing knowledge representations Leveraging multiple standards Managing computing environments via systems engineering methods Elevated terminology & thinking See backup slides for other examples & references

Other Slides for Reference

Procedural vs. Declarative Knowledge Representations
Procedural Representation Traditional programming: C, C++, Java, ... function definition: area area(base,height) return (0.5 * base * height); Declarative Representation Math solvers: Maple, Mathematica, ... relation definition: r1 r1(base,height,area): area :=: 0.5 * base * height; h b A = 1/2 bh A=3 area b=2 h=3 state 1 (function usage) b := 2, h := 3; A := area(b,h); status: A := 3; A A=3 r1 b=2 h=3 b :=: 2, h :=: 3, A :=: ?; status: A :=: 3 A r1 b h state 1 (relation usage) f :=: new instance of r1(b,h,A); state 2 (value change) h := 9; status: A := 3; A=3 b=2 h=9 intent A=9 r1 b=2 h=9 state 2 (value change) h :=: 9; status: A :=: 9 A=9 area b=2 h=9 A := area(b,h); status’: A := 9; A=6 r1 b=2 h=6 state 3 (I/O change) h :=: ?, A :=: 6; status: h :=: 6 state 3 (I/O change) A := 6; status: h := 9; A=6 b=2 h=9 intent ? How does one compute h given A, b ?

Students: Manas Bajaj, Injoong Kim, Greg Mocko Faculty: Russell Peak
Constrained Objects: A Knowledge Representation for Design, Analysis, and Systems Engineering Interoperability Students: Manas Bajaj, Injoong Kim, Greg Mocko Faculty: Russell Peak Objectives Contributions Chip Package Stress Analysis Template Develop better methods of capturing engineering knowledge that : Are independent of vendor-specific CAD/CAE/SE tools Support both easy-to-use human-sensible views and robust computer-sensible formulations in a unified manner Handle a diversity of product domains, simulation disciplines, solution methods, and leverage disparate vendor tools Apply these capabilities in a variety of sponsor-relevant test scenarios: Proposed candidates are templates and custom capabilities for design, analysis, and systems engineering To Scholarship: Develop richer understanding of modeling (including idealizations and multiple levels of abstraction) and representation methods To Industry: Better designs via increased analysis intensity Increased automation and model consistency Increased modularity and reusability Increased corporate memory via better knowledge capture Constrained Object (COB) Formulations Approach and Status Resources Needed XML UML Approach: Extend and apply the constrained object (COB) representation and related methodology based on positive results to date Expand within international efforts like the OMG UML for Systems Engineering work to broaden applicability and impact Status: Current generation capabilities have been successfully demonstrated in diverse environments (circuit boards, electronic chip packages, airframes) with sponsors including NASA, Rockwell Collins, Shinko (a major supplier to Intel), and Boeing. Templates for chip package thermal analysis are in production usage at Shinko with over 75% reduction in modeling effort (deformation/stress templates are soon to follow) Support for 1-3 students depending on project scope Sponsor involvement to provide domain knowledge and facilitate pilot usage COB-based Airframe Analysis Template Additional Information: 1. 2. Response to OMG UML for Systems Engineering RFI: 3. Characterizing Fine-Grained Associativity Gaps: A Preliminary Study of CAD-E Model Interoperability

COB-based Libraries of Analysis Building Blocks (ABBs)
Continuum ABBs Extensional Rod Material Model ABB 1D Linear Elastic Model modular re-usage Torsional Rod

Flap Link Example Parametric Design Description
Extended Constraint Graph COB Structure (COS)

Representing External Tools as COB Relations Parametric FEA Model
FEA Tool

Constrained Object (COB) Representation Current Technical Capabilities - Generation 2
Capabilities & features: Various forms: computable lexical forms, graphical forms, etc. Enables both computer automation and human comprehension Sub/supertypes, basic aggregates, multi-fidelity objects Multi-directionality (I/O changes) Reuses external programs as white box relations Advanced associativity added to COTS frameworks & wrappers Analysis module/template applications (XAI/MRA): Analysis template languages Product model idealizations Explicit associativity relations with design models & other analyses White box reuse of existing tools (e.g., FEA, in-house codes) Reusable, adaptable analysis building blocks Synthesis (sizing) and verification (analysis)

Constrained Objects (cont
Constrained Objects (cont.) Representation Characteristics & Advantages - Gen. 2 Overall characteristics Declarative knowledge representation (non-causal) Combining object & constraint graph techniques COBs = (STEP EXPRESS subset) (constraint graph concepts & views) Advantages over traditional analysis representations Greater solution control Richer semantics (e.g., equations wrapped in engineering context) Unified views of diverse capabilities (tool-independent) Capture of reusable knowledge Enhanced development of complex analysis models Toolkit status (XaiTools v0.4) Basic framework, single user-oriented, file-based

An Introduction to X-Analysis Integration (XAI) Short Course Outline
Part 1: Constrained Objects (COBs) Primer Nomenclature Part 2: Multi-Representation Architecture (MRA) Primer Analysis Integration Challenges Overview of COB-based XAI Ubiquitization Methodology Part 3: Example Applications Airframe Structural Analysis (Boeing) Circuit Board Thermomechanical Analysis (DoD: ProAM; JPL/NASA) Chip Package Thermal Analysis (Shinko) Summary Part 4: Advanced Topics & Current Research

Techniques for Complex System Representation & Model Interoperability (CAD-CAE) a. Multi-Representation Architecture (MRA) b. Explicit Design-Analysis Associativity c. Analysis Module Creation Methodology This is a one-slide overview of our X-Analysis Integration Techniques for CAD-CAE Interoperability work. Motivation Linking design and analysis models is profoundly different than typical data integration tasks in that it requires multidirectional heterogeneous transformations - transforming one or more types of information (e.g., design geometry and materials) into a different type of information (e.g., an idealized finite element model) and vice-versa. Today such idealization transformations are usually not articulated in any form, much less captured as computable CAD-CAE associativity (Figure 5a), thus seriously limiting automation and knowledge capture. The integration challenge is further complicated in that a given type of product can have numerous types of analysis models that vary in discipline, resolution, application, and fidelity [Peak 1993; Peak et al. 1998]. We believe this diversity makes the gap between design and analysis too large for a single-span integration bridge. a. Multi-Representation Architecture (MRA) The multi-representation architecture (MRA) (portion a) of this slide) is the conceptual foundation of an X-analysis integration (XAI) [1] methodology based on object-oriented patterns that naturally exist in engineering analysis processes. It is particularly aimed at design-analysis integration in CAD/CAE environments with high diversity (e.g., diversity of parts, analysis discipline, analysis idealization fidelity, design tools, and analysis tools) and where explicit design-analysis associativity is important (e.g., for automation, knowledge capture, and auditing). In this context, analysis means simulating the physical behavior of a part or system (e.g., determining the stress in a circuit board solder joint). The MRA has been conceived with intermediate representations as stepping stones to achieve the flexibility and modularity dictated by the above needs. Employing an object-oriented approach, these intermediate representations are naturally groupings of concepts that occur between traditional design and analysis models. The MRA is particularly aimed at capturing reusable analysis knowledge at the preliminary and detailed design stages. In the MRA conceptual architecture, solution method models (SMMs) are object-oriented wrappers around detailed solution tools that obtain analysis results in a highly automated manner. They support white box reuse of existing tools (e.g., FEA tools and in-house codes) within an integrated framework (Figure 6, Figure 9). Analysis building blocks (ABBs) represent analytical engineering concepts as semantically rich objects independent of solution method and product domain. ABBs generate SMMs based on solution technique-specific considerations such as symmetry and mesh density. Analyzable product models (APMs) represent design-oriented details, providing a common stepping stone to multiple design tools and supporting multi-fidelity analysis idealizations [Tamburini, 1999]. Finally, context-based analysis models (CBAMs) explicitly represent the fine-grained associativity between a design model and its diverse analysis models (i.e., between ABBs and APMs). CBAMs are also known as analysis modules and analysis templates. This list summarizes these representations (starred items are implemented as COBs per below): Analysis building blocks (ABBs) * · Represent analysis concepts as reusable, modular, adaptable objects Analyzable product models (APMs) * · Include multi-fidelity idealizations and multi-source design data coordination Context-based analysis models (CBAMs), a.k.a. analysis modules and analysis templates* · Contain explicit associativity relations with design models and other analyses Solution method modules (SMMs) · Support black box reuse of existing tools (e.g., FEA tools and in-house codes) · Support for design synthesis (sizing) and design verification (analysis) b. Explicit Design-Analysis Associativity The right side of b. illustrates these concepts via a solder joint analysis example [Peak et al. 1998]. Due to the coefficient of thermal expansion mismatch between the printing wiring board (PWB) and component, the solder joint deforms under thermal loads. The goal of this analysis model is to compute the resulting strain in order to estimate solder joint fatigue life. The left side shows design-related details of APM entities: the cross-section of a component, a PWB, solder joints, and epoxy. The assembly of these entities is another APM entity, a PWA component occurrence, c. On the right, the ABB is a generic analysis system, Plane Strain Bodies System, that can be used in analyses for multiple types of products. The CBAM, Solder Joint Plane Strain Model, contains associativity linkages, i, which indicate how the APM design entities are idealized as homogeneous plane strain bodies in the ABB. For example, linkage 1 explicitly specifies that the height of ABB body1, h1, equals the total height of the component, hc (a geometric idealization, 1, of the detailed APM component entity). Linkage 2 similarly specifies the material model for body1. While the top half of b) shows this design-analysis associativity informally, the lower one is a constraint schematic - a structured information model that specifies all associativity linkages. As constrained objects, these product-specific analysis models also have underlying lexical forms. Implementation of MRA concepts as COBs Constrained objects (COBs) (lower half of b) support the MRA to address the specific needs of engineering analysis integration for simulation-based engineering (SBE), including virtual prototyping, knowledge-based engineering (KBE), and CAD-CAE interoperability. The capabilities of this representation include: · Various information modeling forms: computable lexical forms (including STEP EXPRESS) and graphical forms to aid both computer automation and human comprehension · Object constructs: sub/supertypes, inheritance, basic aggregates, and multi-fidelity objects · Multi-directionality (I/O change) · Wrapping external programs as white box relations XaiTools FrameWork™ is a second-generation Java-based toolkit for XAI that supports constrained objects (COBs) for implementation of MRA concepts. The current tool architecture (Figure 4) supports: · Integration with representative CORBA-based analysis tools: FEA (Ansys) and general math (Mathematica) · Integration with representative design tools: geometric CAD (CATIA), electrical CAD (via STEP AP210), and libraries (e.g., materials and fasteners) · COB navigation/browsing tools and basic editing tools · COB-based analysis module libraries · Usage of Mathematica as the primary constraint solver c. Analysis Module Creation Methodology The MRA ubiquitization process (Figure 1) is a knowledge capture technique for transforming physical behavior research and design standards into catalogs of ready-to-use analysis modules [Peak et al. 1999a]. Working with designers, analysts identify commonly needed analyses and implement them as CBAM templates. Ubiquitous analysis then involves the regular usage of such analysis module instances to support product design. Example industrial applications include PWA-B thermomechanical analysis, electronic packaging thermal resistance analysis and thermomechanical analysis, and airframe structural analysis. Product domain-specific applications such as XaiTools PWA-B™ and XaiTools ChipPackage™ have been built upon this general-purpose foundation. End Notes [1] X = design, manufacture, sustainment, and other lifecycle phases. Contact us or see for further information including toolkits and short courses.

Circuit Board Design-Analysis Integration Electronic Packaging Examples: PWA/B
Pro AM Design Tools Modular, Reusable Template Libraries Analysis Modules (CBAMs) of Diverse Mode & Fidelity ECAD Tools Mentor Graphics, Accel* Analysis Tools XaiTools PWA-B General Math Mathematica STEP AP210‡ GenCAM**, PDIF* Solder Joint Deformation* 1D, 2D, 3D FEA Ansys PWB Stackup Tool XaiTools PWA-B Analyzable Product Model PWB Warpage XaiTools PWA-B 1D, 2D Laminates DB Materials DB PTH Deformation & Fatigue** 1D, 2D

Iterative Design & Analysis PWB Stackup Design & Warpage Analysis
Pro AM PWB Stackup Design Tool 1D Thermal Bending Model Quick Formula-based Check Layup Re-design PWB Warpage Modules Analyzable Product Model 2D Plane Strain Model Detailed FEA Check 1 Oz. Cu 2 Oz. Cu Tetra GF 3 x 1080 2 x 2116

PWB Warpage Modules a.k.a. CBAMs: COB-based analysis templates
PWB Thermal Bending Model (1D formula-based CBAM) Usage of Rich Product Models APM PWB Plane Strain Model (2D FEA-based CBAM)

Example Chip Package Products Source: www.shinko.co.jp
Quad Flat Packs (QFPs) Plastic Ball Grid Array (PBGA) Packages Wafer Level Package (WLP) Glass-to-Metal Seals System-in-Package (SIP)

Flexible High Diversity Design-Analysis Integration Electronic Packaging Examples: Chip Packages/Mounting Shinko Electric Project: Phase 1 (production usage) Design Tools Modular, Reusable Template Libraries Analysis Modules (CBAMs) of Diverse Behavior & Fidelity Prelim/APM Design Tool Analysis Tools XaiTools ChipPackage XaiTools ChipPackage General Math Mathematica FEA Ansys Thermal Resistance Analyzable Product Model 3D PWB DB XaiTools Materials DB* Thermal Stress EBGA, PBGA, QFP Basic 3D** Basic Documentation Automation Authoring MS Excel ** = Demonstration module

Typical Issues: Knowledge Representation, Inter-Model Associativity (Model Interoperability)
CAD Model bulkhead assembly attach point CAE Model channel fitting analysis material properties detailed design geometry idealized analysis geometry No explicit fine-grained CAD-CAE associativity inconsistency automation little knowledge capture analysis results

Flexible High Diversity Design-Analysis Integration Phases 1-3 Airframe Examples: “Bike Frame” / Flap Support Inboard Beam Design Tools Modular, Reusable Template Libraries Analysis Modules (CBAMs) of Diverse Feature:Mode, & Fidelity MCAD Tools CATIA v4, v5 XaiTools Analysis Tools 1.5D General Math Mathematica In-House Codes Lug: Axial/Oblique; Ultimate/Shear Image API (CATGEO); VBScript Analyzable Product Model XaiTools 1.5D Fitting: Bending/Shear Materials DB FEA Elfini* MATDB-like 3D Assembly: Ultimate/ FailSafe/Fatigue* Fasteners DB FASTDB-like * = Item not yet available in toolkit (all others have working examples)

Explicit Capture of Idealizations (part-specific template adaptation in bike frame case)
Idealized Features in CAE Model G2 Detailed Features/Parameters Tagged in CAD Model (CATIA) zf yf te yf yf xf zf xf cavity3.base.minimum_thickness b xf cavity3.width, w3 zf cavity 3 yf rib9 xf G1 rib8 Tension Fitting Analysis = t8,t 9 rib8.thickness rib9.thickness Often missing in today’s process Gi - Relations between idealized CAE parameters and detailed CAD parameters G1 : b = cavity3.inner_width + rib8.thickness/2 + rib9.thickness/2 G2 : te = cavity3.base.minimum_thickness

Today’s Fitting Catalog Documentation from DM 6-81766 Design Manual
Calculation Steps Categories of Idealized Fittings Angle Fitting Channel Fitting End Pad Bending Analysis Channel Fitting Bathtub Fitting

Channel Fitting Casing Body*
Modular Fitting Templates Object-Oriented Hierarchy of Analysis Building Blocks (ABBs) ABB: - independent of specific products - usable on many designs ABB * = Working Examples Specialized Analysis Body Specialized Analysis System Fitting Casing Body Fitting Washer Body Fitting Bolt Body* bolt washer Fitting System ABB casing load P Channel Fitting Casing Body* Open Wall Fitting Casing Body ) , ( 1 e r R f K = Fitting End Pad ABB Fitting Wall ABB ) , ( 2 w e t f K = Bathtub Fitting Casing Body Angle Fitting Casing Body Fitting End Pad Bending ABB 2 1 e be ht P C f = Fitting End Pad Shear ABB* e se t r P f 2 p = Open Wall Fitting End Pad Bending ABB Channel Fitting End Pad Bending ABB* ) , min( wb wa w t = p b a R + = ) , ( 1 3 h b r f K = 2 d f R e + - = C = K ( 2 e - t ) 1 3 b C = K K 1 1 2

Channel Fitting System ABBs
End Pad Bending Analysis End Pad Shear Analysis ABB = analysis building block

“Bike Frame” Bulkhead Fitting Analysis Template Using Constrained Object (COB) Knowledge/Info Representation ) , ( 1 3 h b r f K = 2 1 e be ht P C f = e se t r P f 2 p =

Object-oriented spreadsheet
Bike Frame Bulkhead Fitting Analysis COB-based Analysis Template - in XaiTools Focus Point of CAD-CAE Integration Detailed CAD data from CATIA Library data for materials & fasteners Idealized analysis features in APM Object-oriented spreadsheet Modular generic analysis templates (ABBs) Explicit multi-directional associativity between detailed CAD data & idealized analysis features

Cost of Associativity Gaps Reference: http://eislab. gatech
Categories of Gap Costs Associativity time & labor - Manual maintenance - Little re-use - Lost knowledge Inconsistencies Limited analysis usage - Fewer parts analyzed - Fewer iterations per part “Wrong” values - Too conservative: Extra part costs and performance inefficiencies - Too loose: Re-work, failures, law suits Initial Cost Estimate per Complex Product (only for manual maintenance costs of structural analysis problems)

Information Capture Gaps: Content Coverage and Semantics
Existing Tools Tool A1 ... Tool An Legend Content Coverage Gaps “dumb” information capture (only human-sensible, I.e., not computer-sensible) Smart Product Model Building Blocks Models & meta-models International standards Industry specs Corporate standards Local customizations Modeling technologies: Express, UML, XML, COBs, … Content Semantic Gaps Example “dumb” figures

Summary Tool independent model interoperability
Application focus: analysis template methodology Multi-representation architecture (MRA) & constrained objects (COBs): Addresses fundamental gaps: Idealizations & CAD-CAE associativity: multi-fidelity, multi-directional, fine-grained Based on information & knowledge theory Structured, flexible, and extensible Improved quality, cost, time: Capture engineering knowledge in a reusable form Reduce information inconsistencies Increase analysis intensity & effectiveness Reducing modeling cycle time by 75% (production usage)

For Further Information ...
Contact: Web site: Publications, project overviews, tools, etc. See: X-Analysis Integration (XAI) Central Engineering Framework Interest Group (EFWIG) XaiTools™ home page: Pilot commercial ESB: Internet-based self-serve analysis Analysis module catalog for electronic packaging Highly automated front-ends to general FEA & math tools

Planning Meeting for Product, Lifecycle Management,

Similar presentations

Presentation on theme: "Planning Meeting for Product, Lifecycle Management,"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Planning Meeting for Product, Lifecycle Management,

Similar presentations

Presentation on theme: "Planning Meeting for Product, Lifecycle Management,"— Presentation transcript:

Similar presentations

About project

Feedback