1. Federated Product Models for Simulation-based PLM
PDE 2005 The 7th NASA-ESA Workshop on Product Data Exchange (PDE)
April 19-22, Manufacturing Research Center, Georgia Tech, Atlanta, USA
Federated Product Models for Simulation-based PLM
Presenter:
Manas Bajaj1 –
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 © by Georgia Tech Research Corporation, Atlanta, Georgia USA. All Rights Reserved.
Developed by eislab.gatech.edu. Permission to use for non-commercial purposes is hereby granted provided this notice is included.

2. 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?

3. 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

4. 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

5. 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
Models of varying abstractions and domains
After Bajaj, Peak, & Waterbury

6. 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 …

7. 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?

8. 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

9. 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

10. 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

11. 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

12. 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?

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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)

19. 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.

20. 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).

21. 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)

22. 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?

23. 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)

24. 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)

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

26. 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

27. 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)

28. 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 …

29. Backup Slides

30. 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)

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

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