Federated Product Models for Simulation-based PLM PDE 2005 The 7th NASA-ESA Workshop on Product Data Exchange (PDE) April 19-22, 2005 Manufacturing Research Center, Georgia Tech, Atlanta, USA Federated Product Models for Simulation-based PLM Presenter: Manas Bajaj1 – Manas.Bajaj@eislab.gatech.edu Co-Authors: Chris Paredis1, Tarun Rathnam1, Russell Peak2 1. G.W.Woodruff School of Mechanical Engineering 2. Manufacturing Research Center Georgia Institute of Technology Copyright © 1993-2005 by Georgia Tech Research Corporation, Atlanta, Georgia 30332-0415 USA. All Rights Reserved. Developed by eislab.gatech.edu. Permission to use for non-commercial purposes is hereby granted provided this notice is included.

Motivating Question Engineers… A Process for Simulation-based Design… work on specific views (mechanical, electrical, systems,…) of the product across its lifecycle specify processes for simulation-based design A Process for Simulation-based Design… involves a diverse set of tools that need to be integrated …and have corresponding knowledge representations (schema) How can we integrate and streamline this diversity in knowledge representation?

Contents Notion of Product View Federation in PLM Model-based Associativity in PLM Core Research Problems Federated Simulations – a similar research problem Background Similarities with Product View Federations Ontology-based Framework Creating Simulation Ontologies Integrating Simulation Ontologies in a Federation Ontology Common Representation Selection – algorithm overview Conclusion

Traditional Product View based on Engineering Domains Information across the domains is shared Manufacturing & Process Planning Electrical Product Data Management Evolving Car Model Mechanical Software IDE Systems Engineering Analysis

Models of varying abstractions and domains Model-based Associativity for PLM The notion of Product View Federations … Customer Requirements … … Abstraction Level Systems Engineering … Legend Rich models: Information objects Parametric relations Model interfaces: Fine-grained associativity relations among domain-specific models and system-level models … … Development Process … … … Product View Federations: “Systems of systems” model subgraphs for finding satisficing solutions Requirements Software Electronics Structures Human Interfaces … Domain 2004-09 Models of varying abstractions and domains After Bajaj, Peak, & Waterbury 2003-09

Product View Federation Example: PWB and Warpage Worthiness Product View Federation - Warpage Worthiness Context Product View – PWB metallization features and stackup Federate 3 Product: PWB Optimization Federates: Constituents of a federation. Play a specific role in the federation Information / Knowledge representation schema Federate 1 Warpage Profile Enriching Product Design, based on its warpage worthiness Analysis Building Block Model Idealized PWB (top view and side view) Federate 2 …

Product View Federates and Federation Core Problems How do we integrate the product view federates to create a product view federation? How can we formalize and to what degree can we automate the process of creating a federation?

Example End Product of Federation Development Process Multi-Representation Architecture Solution Method Model Y ABB SMM Analysis Building Block Context-Based Analysis Model F APM CBAM Manufacturing Product Model (e.g. STEP AP210-based) Solution Tools (ANSYS, …) Printed Wiring Assembly (PWA) Solder Joint Component PWB body 3 2 1 4 T Printed Wiring Board (PWB) Solder Joint Analyzable Product Model How can we formalize and to what degree can we automate the federation development process? Fine-grained parametric associativity

Contents Notion of Product View Federation in PLM Model-based Associativity in PLM Core Research Problems Federated Simulations – a similar research problem Background Similarities with Product View Federations Ontology-based Framework Creating Simulation Ontologies Integrating Simulation Ontologies in a Federation Ontology Common Representation Selection – algorithm overview Conclusion

Federated Simulations Similar Research Problem Group of simulations that exchange information with each other during their parallel execution ‘Federates’ = Discrete Event Simulations Message-based information exchange (Publish & Subscribe) To study the emergent behavior of large complex systems Several Coupled Subsystems Integrate sub-system level simulation models Federate Federate Federate Software Sim Live component Data Viewer Im going to begin by providing some context, as to the domain in which this research is rooted. Simulation to supported complex design Federated simulation for sub-system integration ‘Federate’ Sub-system level models exist. To study emergent behavior of system as a whole Typically, federate simulations are DEVS, or live components that behave in a similar fashion. Message based exchange through interface. Runtime infrastructure provides services to pass messages. Interface Specification Run-Time Infrastructure A distributed operating system providing distributed simulation services Figure taken from Fujimoto, 2000

Issues in Federated Simulation Several aspects to achieving interoperability Representational Compatibility Time Management Interface with RTI Common Information model Required Federate models employ disparate representations Transformation stubs for legacy simulations Simulator A Parameters State Simulation A Common Information Model Run Time Interplay The development and execution of these federated simulations is not a simple task. For federate simulations to interoperate, their advancement through time stamps must be synchronized so that messages are passed in correct transient fashion. Must build interface around the simulators so that they publish and subscribe information using RTI services Finally, there is the issue of representational compatibility. For consistent information exchange, a federation wide information model must be specified, which specifies how exchanges entities are represented. But federate representations of related entities are often not the same. They must either be modified so as to be consistent, or transformations around them (legacy) Transform Simulator A Parameters State Simulation B 2

Product View Federations and Federated Simulations A Comparison Federation created for integrating models and processes associated with different product views Federation created for enabling integration of discrete event simulations Federation is represented by an integrated information / knowledge schema Federation is represented by a Federation Ontology (FONT) Federates (geometric model, analysis model, etc.) are represented by their native information / knowledge schema Federates are represented by their individual simulation ontologies (SONTs) Mappings are created / specified amongst the participating information models Relationships are specified amongst the participating federates How can we formalize the federation development process and to what extent can we automate this process?

FONT Development Problem in Federated Simulations An Example Two simulations model Equivalent Concepts Disparate Names Different Information (3D v/s 2D) Different Representations (foot v/s meter) O Vehicle A Position (2D) D 2D X (meter) Y (meter) O Car A Location (3D) D 3D X (foot) Y (foot) Z (foot) Sim. Model A Sim. Model B ? To demonstrate a case where federate simulations have disparate representations, consider the following example…. 4

Use Ontologies to describe information and knowledge content in simulation models Sim. Model A Objects Events Simulation Ontology A Objects Events Simulation Ontology B Sim. Model B Objects Events Federation Ontology Transform Transform Runtime interplay

Ontology-Based Framework: Capture and Reuse Knowledge Defined for each Federation: - Extensible Defined once for each Simulation: - Reusable - Extensible Generated Automatically Federation Ontology FONT Simulation Ontology Simulation Ontology Common Schema SONT A Objects Events SONT B Objects Events Transformations SONT A SONT B Generated Automatically Defined Once Meta-Ontology Object Event Attribute Relationship

Contents Notion of Product View Federation in PLM Model-based Associativity in PLM Core Research Problems Federated Simulations – a similar research problem Background Similarities with Product View Federations Ontology-based Framework Creating Simulation Ontologies Integrating Simulation Ontologies in a Federation Ontology Common Representation Selection – algorithm overview Conclusion

Semantic Technologies: Ontology-based Framework as a Protégé Plugin Meta-Ontology for Federate Simulations Meta-classes for Objects, Events and Datatypes Meta-classes for attributes Protégé Plugin Interface Reusable Definitions (for example - Units) Meta-classes for relationships

Relationships Specified Amongst Participating SONT Objects Instances of relationship class Specify a match (to/from) Mapping (function to/ function from) I Relationship_Instance S From = Vehicle To = Car From = Position To = Location Function_To = TBD Function_From =TBD D 2D A X (meter) Y (meter) 3D X (foot) Y (foot) Z (foot) O Vehicle Position (2D) Car Location (3D)

Creating Relationships Amongst SONT Objects in Protégé Ontology Framework Click on the + buttons to populate the From field and the To field of this relationship. Select SONT_1_Car and SONT_2_Bus. The order of selection doesn’t matter.

Creating Relationship between SONT Attributes in Protégé Ontology Framework Similarly, create a SONT-SONT Attribute relationship instance between Location attribute (of SONT_1_Car) and Position attribute (of SONT_2_Bus).

Generation of Common Representation (Schema) in the Federation Ontology Vehicle A Position (2D) Car Location (3D) Select Common Object Define Transformations O Vehicle A Position (2D) Car Location (3D) Common Obj. Common Attr. (3D) I Relationship_Instance S From = Vehicle To = Common Obj I Relationship_Instance S From = Position To = Common Attr. Function_To = 3D Position_to_Common_Attr (2D input) Function_From =2D Common_Attr_to_Position (3D input)

Common Representation Selection Selected as one of SONT representations ‘Lossiness’ of transformation = loss of information Select representation leading to fewest lossy end-to-end transformations A Position (2D) Point (3D) Location (3D) A Position (2D) Location (3D) Point (3D) ?? Which should be selected as common?

Common Representation Selection Position (2D) Point (3D) Location (3D) Selected from SONT representations ‘Lossiness’ of transformation = loss of information Select representation leading to fewest lossy end-to-end transformations Algorithm: Directed, weighted graph representation Shortest path algorithm (Dijkstra, 69) Minimize total sum of all transformations 2 101 100 1 Total Distance = 204 Total Distance = 103 A Position (2D) A Common (2D) A Point (3D) A Location (3D) A Position (2D) A Common (3D) A Point (3D) A Location (3D)

Generate Transformations Generate Sequence of transformations Follow shortest path to/from common representation Instantiate user-provided Java routines (Java routines could be generated automatically for equivalence relationships – future work) A Position (2D) Point (3D) Location (3D) A Position (2D) A Common (3D) A Point (3D) A Location (3D)

Generate Common Representation (Schema) using Protégé Ontology Framework Click on the IDSim Tab Click on Generate button to create the COMMON REPRESENTATION

Viewing the Common Representation Schema in Protégé Ontology Framework Common object has been created with a common attribute. The common object corresponds to the common representation amongst SONT_1_Car, SONT_2_Bus and SONT_3_Vehicle objects. The common attribute corresponds the common representation amongst Position, Location and Track attributes. Relationships have been created between the common object and SONT objects

Viewing Attributes in the Common Representation Schema Double click on the common attribute and view top level slot The common attribute is of type 3D-Coordinate. This means that the Location attribute was selected as the common representation amongst Position, Location and Track attributes Relationships have been created between the common attribute and the SONT attributes (Position, Location and Track)

Conclusion Product View Federation and Federated Simulation are engulfed with similar research problems on representational compatibility of federates Solution approach employed for common representation selection in Federated Simulations can be extended to Product View Federations Rationale for common representation selection can be extended Minimal Lossiness of Information  current criteria Maximum Content Coverage …

Backup Slides

Populating transformation functions in attribute relationships 25.a. Click on C to create a new instance of Function From (this is a function that transforms the To field of the relationship to the From field of the relationship) 26.b. Fill in the transformation routine. This function is not lossy because a 3D coordinate is transformed to a 4D coordinate. 25.b. Fill in the transformation routine. This function is lossy because a 4D coordinate is transformed to a 3D coordinate. 26.a. Click on C to create a new instance of Function To (this is a function that transforms the From field of the relationship to the To field of the relationship)

Viewing XML Schema for FONT objects, events and relationships 61. Viewing the XML serialization of FONT objects. Open file named, “common.xsd”

Viewing XML Schema for FONT datatypes 62. Viewing custom datatypes serialized as XML. Open file named datatypes.xsd