Part 1. Constrained Objects Enhancing engineering design and analysis interoperability, Part 1. Constrained Objects First M.I.T. Conference on Computational Fluid and Solid Mechanics June, 2001 Miyako W. Wilson, Russell Peak, and Robert E. Fulton Georgia Institute of Technology Seamless communication between People, models, and tools This topic has 3 papers.

Motivation The need for a unified physical behavior modeling representation with the following characteristics Has tailoring for design-analysis integration including supports for multi-fidelity idealization, product-specific analysis templates, and CAD-CAE tool interoperability. Supports product information-driven analysis (I.e., supports plugging in detail design objects and idealizing them into a diversity of analysis models). Has computer-processible lexical forms along with human-friendly graphical forms. Represents relations in a non-casual matter (I.e., enables multi-directional combinations of model inputs/outputs). Capture engineering knowledge in a modular reusable form Constraint object take advantage of the followings techniques So our approach for solving this problem is constrained object.

Constrained Object (COB) Overview - Techniques Leveraged Object-oriented modeling [Lalonde & Pugh, et al.1990, Muller 1997] class vs instance inheritance Constraint graph techniques [Borning, et al. 1990] relations without fixed input/output direction Declarative knowledge representation (non-casual) Characterized by entities, attributes, and relations Constraint object take advantage of the followings techniques

COB Representation Components Users Definition Languages Graphical Representations Definition Languages Graphical Representations COB Meta Information Model Protocol Developers Highlight about this technique Meta Information Model Protocol

Example COB Structure (COS) Spring Primitive Figure Relations Traditional Form Constraint Schematic-S Spring L D F k 1 x 2 Subsystem View (for reuse by other COBs) COB spring ; undeformed_length, L₀ : REAL; spring_constant, k : REAL; start, x₁ : REAL; end, x₂ : REAL; length, L : REAL; total_elongation, ΔL : REAL; force, F : REAL; RELATIONS r1 : "<length> == <end> - <start>"; r2 : "<total_elongation> == <length> - <undeformed_length>"; r3 : "<force> == <spring_constant> * <total_elongation>"; END_COB; COS Language 7 attributes and 3 relations How Traditional Spring example fits to COB. Subsystem - encapsulate/ modular form inside the subsystem contains constraint schematic above.

Example COB Instance (COI) Spring Primitive Lexical COB Instance (COI) Constraint Schematic-I example 1, state 1.1 state 1.0 (unsolved): INSTANCE_OF spring; undeformed_length : 20.0; spring_constant : 5.0; total_elongation : ?; force : 10.0; END_INSTANCE; state 1.1 (solved): start : ?; end : ?; length : 22.0; total_elongation : 2.0; Basic Constraint Schematic-I Notation

Multi-Directional I/O (non-causal) Spring Primitive Constraint Schematic-I Lexical COB Instance (COI) Design Verification example 1, state 1.1 state 5.0 (unsolved): INSTANCE_OF spring; undeformed_length : 20.0; spring_constant : ?; start : 10.0; length : 22.0; force : 40.0; END_INSTANCE; state 5.1 (solved): spring_constant : 20.0; end : 32.0; total_elongation : 2.0; Design Synthesis example 1, state 5.1

COB Representation Traditional Form: Spring System System Figure Free Body Diagrams Variables and Relations System-Level Relations (Boundary Conditions) The spring example shows how COB can be used as analysis template. In this two spring system example shows Taking traditional problem and capturing knowledge in object oriented form Two springs connected in series, one end fixed to wall, other end has applied force. In order to analyze the system in traditional way, first the free body diagrams () are created. Then, the relations similar to the one in are listed so that the next step is to assign values and solve any unknown values. Spring 1 Spring 2

COB Representation Constraint Graph: Spring System L10 k1 L1 L1 L20 k2 x21 x22 F2 L2 L2 F1 bc4 r12 r13 r22 r23 bc5 bc6 bc3 r11 r21 bc2 bc1 x11 x12 u1 u2 P Spring 2 spring2 spring1 System level This slide shows Constraint network circle is variable box represent relation Blue areas shows spring1 and spring2 variable and relations that is repeated for both springs So opportunity to define modular reusable object Constraint Graph-S

COB Representation Extended Constraint Graph-S: Two Spring System One step is first attributes that belong to spring one and relations. Grouping Part of overall system Groups objects & relations into parent objects Object-oriented vs. flattened partial (BC relations not included)

COB Representation Constraint Schematic: Spring System Constraint Graph-S Constraint Schematic-S bc1 bc3 P bc4 F 1 k F 1 2 k 2 spring 1 r13 spring2 r23 x L spring1 Spring Elementary L D F k 1 x 2 11 1 x L D L 22 2 r11 D L 1 r21 2 r12 r22 x x 12 21 bc5 1 u L bc6 L 10 bc5 20 bc1 u u 11 = x 1 2 bc2 This Take use of the subsystem spring in the blue areas Spring is template and reusing here bc2 bc3 spring 2 Spring Elementary L D F k 1 x 2 bc4 P Encapsulated form (hides details) Template re-usage 1 2 u L + D = 2 u bc6

COB Representation Constraint Schematic-S: Spring System Analysis Primitives with Encapsulated Relations spring 1 Spring Elementary L D F k 1 x 2 System-Level Relations (Boundary Conditions) bc5 1 u bc1 11 = x bc2 bc3 spring 2 Spring Elementary L D F k 1 x 2 bc4 P 1 2 u L + D = 2 u bc6

COB Representation COS Language: Spring System Constraint Schematic-S COB spring_system ; spring1 : spring; spring2 : spring; deformation1, u₁ : REAL; deformation2, u₂ : REAL; load, P : REAL; RELATIONS r1 : "<spring1.start> == 0.0"; r2 : "<spring1.end> == <spring2.start>"; r3 : "<spring1.force> == <spring2.force>"; r4 : "<spring2.force> == <load>"; r5 : "<deformation1> == <spring1.total_elongation>"; r6 : "<deformation2> == <spring2.total_elongation> + <deformation1>"; END_COB; r1-r3 relations in spring COB is not needed included in spring_system COB. R1-r6 relations in spring system COB are the boundary conditions

COB Representation COB Instance (COI): Spring System COI Language Constraint Schematic-I state 1.0 (unsolved): INSTANCE_OF spring_system; spring1.undeformed_length : 8.0; spring1.spring_constant : 5.5; spring2.undeformed_length : 8.0; spring2.spring_constant : 6.0; load : 10.0; deformation2 : ?; END_INSTANCE; state 1.1 (solved): spring1.start : 0.0; spring1.end : 9.818; spring1.force : 10.0; spring1.total_elongation : 1.818; spring1.length : 9.818; spring2.start : 9.818; spring2.force : 10.0; spring2.total_elongation : 1.667; spring2.length : 9.667; spring2.end : 19.48; deformation1 : 1.818; deformation2 : 3.485;

COB Representation Lexical and Graphical Views COB Structure (COS) COB Instance (COI) Constraint Schematic-S Subsystem -S view COB Instance(COI) Language Extended Constraint Graphs-I Constraint Schematic-I STEP Part 21 200 lbs 30e6 psi 100 20.2 in R101 COB Structure (COS) Language I/O Tables Object Relationship Diagram Constraint Graphs-S Purpose of different views Each view enphasize different aspect to help human understanding Text form enable computer processing Extended Constraint Graphs-S HTML Express-G STEP Express HTML Constraint Graph = Constraint Network

COB Representation Components (see Wilson,2000) Users Definition Languages Graphical Representations Definition Languages Graphical Representations COB Meta Information Model Protocol Developers Highlight about this technique Meta Information Model Protocol

COB Meta Information Model & Protocol Generic Nature Metadata Meta Information Model Protocol Generic Data COB Structure Definition Data COB Instance Definition Data COS COI Information model is higher level mode for COS and COI allow to describe structure object and specific instance of objects any COBs in general The protocol operates on any cobs for manipulation Specific Structure Data Specific Instance Data Definition Languages 10.0 20.0 5.0 22.0 2.0 32.0 Example: L k x 2 F D 1 Graphical Representations

XaiTools ™ X-Analysis Integration Toolkit Java COB Definition Files Solvers COB Instances Structures Constraint Network Constraint Solver Mathematica FEA ANSYS COB Meta Information Model -> classes COB Protocol -> methods (API) API COB based Design/Analysis Tools Generic Viewer

Engineering Service Bureau Using Internet/Intranet-based Analysis Solvers Thick Client Architecture Users Engineering Service Bureau Client PCs Host Machines Thick Client CORBA Daemon XaiTools Iona orbixdj CORBA IIOP CORBA Servers Internet XaiTools Ansys Solver Server XaiTools Ansys Solver Server XaiTools Math. Solver Server XaiTools Ansys Solver Server Part of implementation, solvers can be accessed through over internet using Middelware tech. June’99-Present: EIS Lab - Regular internal use U-Engineer.com - Demo usage: - US - Japan Nov.’00-Present: Electronics Co. - Began production usage (dept. Intranet) Future: Company Intranet and/or (commercial) - Other solvers FEA Solvers Ansys Internet/Intranet ... Math Solvers Mathematica

XaiTools ™ COB Browser Spring System Functionality: View Change value Change I/O Activate/Disactivate relations This show Like oo spread sheet. This shows one of tool which has the functionality as shown. Look at detail in later

Constrained Object (COB) Representation Capabilities & features: Various forms: computable lexical forms, graphical forms Sub/supertypes, basic aggregates, multi-fidelity objects Multi-directionality (I/O change) Wrapping external programs as white box relations Analysis module/template applications (XAI): 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) General information modeling capability Apply to Analysis integration Part2 talk more

Constrained Objects (cont Constrained Objects (cont.) Representation Characteristics & Advantages 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 view of diverse capabilities Capture of reusable knowledge Enhanced development of complex analysis models