deriving a product model from heterogeneous processes ghang lee, ph.d. research scientist, college...
TRANSCRIPT
Deriving a Product Model from Heterogeneous Processes
Ghang Lee, Ph.D.
Research Scientist, College of ArchitectureGeorgia Institute of [email protected]
NASA-ESA PDE 2005 Workshop
Georgia Tech, April 22, 2005
Product Modeling
IntegratedAAM
Application Activity Model
ARM
Application Reference Model
Process Modeling
Current product modeling practice
Problems
Company A (or Application A) Company B (or Application )
A single unified IDEF0 model
Uniqueness of different processes
Description on specific information items
Product Modeling
IntegratedAAM
Application Activity Model
ARM
Application Reference Model
Process Modeling
weak linkstatic modeling
No rigorous method to checkthe completeness of an ARM Committee
Review
update
review
Motivations
Long Modeling TimeNo validation method
Goals
Provision of logical and scientific foundation and methods for constructing efficient and practical product models
Reduction of the time and cost of developing and updating a data model from 3-10 years to 1-2 years
A Proposed Approach
GTPPM: Georgia Tech Process to Product Modeling
Domain Experts Product modeling experts
Requirements Collection & Modeling (RCM)
Logical Product Modeling (LPM)
A product model
Process A
Process B
Process C
Info. Set A
Info. Set B
Info. Set C
UoD
System Architecture
Local terms Local terms
Sharable, machine-interpretable terms
Product Model
Process Modeling Module
ProductInformationSpecificationModule
Logical Modeling Module
(optional)
Integration / Normalization
Challenge
How to maintain the consistency between the information items collected from different processes
A
Ten-speed bike
B
Ten speed-bikes?
Four-level consistency assurance methods Semantic level Syntactic level Information flow level Data model level
Semantic level
The ‘Nym’ Principle: No synonym, no homonym
ten-speedten
bikespeed-bike motorcycle
bicycle
No homonym! No synonym!
Syntactic level
ten-speedten
bikespeed-bike
Product and Modifier
Product Information(Information Construct (IC))
Product Modifier
speedbike
(is modified by)
Product Information Specification (PIS) Constituents
1
(ABS)Product
(ABS)Token
DecomposedProduct (DP)
Specialized Product(SP)
(ABS)Modifier
Modifier Entity (ME)
1
Modifier Attribute(MA)
1
Entity
1
(ABS)Type
1
modifier S[1:?]
attribute S[0:?]
*is_linked_to S[0:?]
PIS Elements
EXPRESSElements
Specialization
Decomposition
Association
Product Information Specification (PIS) Rules Rule 1: {x | x x E}
Rule 2: IC P – M
Rule 3: M M –ME | M –SME | M –MA | NULL
Rule 4: P P – SP | P – DP | NULL
Rule 5: DP DP – DP′ | DP – SP | NULL
Rule 6: SP SP – DP | SP – SP′ | NULL
Rule 7: ME ME –SME | ME – ME |ME – MA | NULL
Rule 8: SME SME – SME | SME – ME | SME – MA | NULL
Ref: G. Lee, C.M. Eastman and R. Sacks, Grammatical rules for specifying product information to support automated product data modeling (in review), Advanced Engineering Informatics (2004).
Example
A beam, which is a kind of member, is a part of a structure. It’s made of a material. The material has strength
IC
M
DP
MA
member
M
material
SP
beam
P: structure
strength
DP: member
Structure+member*beam+material{strength}
DecompositionAssociation
Specialization
Consistent Information Flow
Input
Passed-Through
Modified
Generated
AvailableInformation
ProvidedInformation
INPUT OUTPUT
Remaining
Available Input Information
Upstream Information Source of A
U1
U2
Available Information Ia Iuo1 Iuo2 U{x| output(up(A), x)} {u, v, w, x, y, z}
Iuo2 {v, x, y, z}
Iuo1 {u, v, w}
{u,v,x,y,z}A
Input Output w: unused information
{u, v, w, x, y, z}
Required Output Information
Downstream Information Source of A
{s,t}
{t, z}
{x, w}
{v, y}
{x, y}
{p, q, r}
{q, r}
{m, s, t, z}A
OutputInput
Input1 {x, y, t, z}
Input2 {q, r, s, t}
D1
D2
p, v, w, m: unused information
{s,t}
{z, t}
Required Output Information Iro U{x| input(dn(A), x)} – {U{x| output(up(dn(A)), x)} - U{z| output(A, x)}}
{s, t, z}
Remedies
Adjustment of information items Adjustment of flows Adjustment of activities
Consistency in a data model
Process A
Process B
Collected Information Constructs (ICs)
: token
Information construct (IC)
Restructured/Normalized as a Product Model
Conflicts
A Basic Principle for conflict resolution
“More semantics”
Example
Problem
Solution
A B
A
B
(a)
(b)
Design Pattern 8: A conflict between a subtype and a property
A B
B
A
B
Implementation
EXPRESS MS Visio Add-on GTPPM®
Schedule Pieces to Fabrication Areas
Post daily schedule
8:Prepare Molds
11:Fabricate
14:Weld Shop
31:Shipping
Set daily schedule (Day 1- 14)
Schedule shipping (up to 100 loads a day)
Production Facilities
Production Facilities
39:Prepare cages & rebars
44:Finish
Request from site
Update
Shipping Request
FB
DAILY SCHEDULE
SHIPPING SCHEDULE
Current Status
Experimentation with the fourteen North American precast concrete companies
Deployment in several construction IT-related research projects at CMU, Purdue, U. Florida, and Teeside Univ. (UK), Israel Institute of Technology
Future Work & Possible Extension Further development with the ISO STEP
committees Possible extensions
Project/Product lifecycle management (PLM) Workflow management Business process reengineering Conformance class development Product model update Automated data translator development
