Global Design and Manufacturing Companies spend a lot of time looking in the rear-view mirror relative to their product design and configuration requirements in order to determine what NOT to do in the future. A lot of time and money is spent tracking information related to design validation, testing and warranty data. Understanding history is important, it often repeats and the bad decisions of the past needs to be avoided.
But, what about the GOOD decisions that have been made, those are just as, if not more important to a design and configuration process! Where do those get stored?! How are they measured?! Most importantly, HOW ARE THEY ENFORCED?! Specifically, how do you help someone in a company make the RIGHT decisions, not just be fearful of repeating a BAD one?!
This is a complex problem for any Design, Engineering or IT Department. That problem gets even more complex when you are required to incorporate a 3D CAD (Computer Aided Design) systems into the mix. If 3D parts and assemblies do not physically connect together properly, or are never supposed to work logically together based on the customer application, you will lose business. The solution is to rethink the approach to how a company not only captures knowledge about failures, but also start to capture successes. The ultimate goal is to help design and engineering staff make the right decisions first, to guide them through valid relations and requirements with ease so they are never distracted by bad decisions - or forced to address a potentially bad decision before it is made.
This is where graph databases are poised to address a very complex problem in a simple and easy to understand way. There are two problems that come up from this:
1) how to document the relationships, rules, dependencies and logic in the graph structure, and
2) how to guide/navigate different role-specific-users through that process safely/accurately.
This presentation will cover the real-world complexities of defining, validating, documenting and enforcing mechanical 3D CAD product configuration rules and structures. Demonstrations of how different roles within the company (e.g. configuration manager, engineer, sales, etc.) can interface with the same graph database using multiple interfaces (e.g. thick client, thin and web) to be interactively guided to a proper solution the first time.
Unleash Your Potential - Namagunga Girls Coding Club
Knowledge, Graphs & 3D CAD Systems - David Bigelow @ GraphConnect Chicago 2013
1. Innovate. Share. Connect.
Chicago June 12-13
Knowledge, Graphs & 3D CAD SystemsKnowledge, Graphs & 3D CAD Systems
David Bigelow - Simplified Logic, Inc.David Bigelow - Simplified Logic, Inc.
4. Image Source: Max DeMarzi
Visualization HAS gotten better...
(for simple cases)
5. But still has a LOOOOOONG way to go...
(Huh?! Is this useful to the average person who is not a social or criminal scientist!?)
Image Source: gephi.org
6. Most Visualization looks exclusively in the PAST!
(The future starts by staring into the rear-view mirror?!)
Closeness of Data Points?
Clustering?
Connection Counts?
Overall Ranking?
Correlation?
Causation?
Trending?
Where used? Degree of Centrality?
7. Historical Data drives
future decisions,
policies,
and agendas!
BUT, it is typically
not actionable
in a timely manner.
(The “Big Data” Problem!?)
History is important!
(ok... duh!)
8. character credit: SouthPark.com - “underwear gnomes”
There has been an extreme focus on
collecting and controlling data...
(ummm.... “Phase 2” is like really important!)
9. You want to do amazing things?!
Figure out that “Phase 2” part out! (quickly)
graphic credit: SouthPark.com - “underwear gnomes”
14. A
Q
R
S
T
U
V
W
BuildOrder
Part Features & Operations
Structural
and / or
Geometric
Dependent
Relationships
Relationships
NOTE: This is Painful for Users!
Multiple Paths / Frustrations
to the SAME Geometric Results!
15. Part Design Automation
(graphs can help navigate data, but not great for automating)
Feature Instructions are
typically defined to a small
reference.
The Resulting Geometry
often is more complicated
than the instructions used to
create it.
19. A
B
C
A
Z
D
E
F
Component “C”
w/ Assembly References
to Assembly “E”
and Sub-Component “B”
Sub-Assembly “F”
Assembled to
Component “C”
Assembly Relationships
NOTE: ALL relationships must be
understood by the product data
management system!
20. THIS is a BIG PROBLEM!
EXPENSIVE, COMPLEX &
PROPRIETARY
Data Management Systems
Multiple Use-Cases for the
SAME DATA
(Manufacturing, Vendors, Customer, Publishing, ERP, etc.)
Sharing & Using
Information
with others is PAINFUL!
Embedded CAD Relationships
A
C
A
Z
D
E
F
B
32. This is a “Decision Framework”
3-Ring Binders!Excel Worksheets!
+
BUT... NOT VERY USEFUL!
33. Human “mobility” is a BIG problem...
Typically, the “data” stays...
(PDM, PLM, Excel Worksheets, Paper Notebooks, etc.)
I am out’a here!Promo!
The “new people” in a job are a huge variable...
Newbie!
(aggressiveness, competence, courage, communication skills, real-world experience vs. book smarts,
etc...)
34. Internal Memos
Warranty Info
Test Data
source: ibm.com
source: spacesaver.com
Design Standards
Customer Feedback
Competitive Analysis
Product Design & Configuration Knowledge
Comes from MANY Sources
35. Different Sources, Different
Databases, Different Users,
Different Applications, Different
Use Cases, Different Customers,
Different Needs, Different Life
Cycles, Different Security,
Different Sources, Different
Databases, Different Users,
Different Applications, Different
Use Cases, Different Customers,
Different Needs, Different Life
Cycles, Different Security,
This is where most I.T. Departments
seriously struggle!
36. Let Purpose-Built Solutions Work!
You can build an amazing Decision Framework from this...
But, information arrives and changes at different times...
Your NEW
“Decision Structure”