Upload
jessica-parrish
View
224
Download
4
Tags:
Embed Size (px)
Citation preview
Acquisition and Maintenance of
Constraints in Engineering Design
BySuraj Ajit
Supervisor: Prof. Derek Sleeman
Presentation Overview
Motivation:The Designers’ Workbench (Overview)ConEditor Maintenance of Constraints (Issues/problems)Proposed Solution/SystemSummary/StatusQuestions/Discussion
The Designers’ Workbench(David W. Fowler et al.)
Assists designers by checking designs Easy to overlook rules
Design rules (and their rationales) often difficult to retrieveMultiple designers working on same engine decisions made by one designer can have hidden
implications
Many thousands of standard parts and featuresAllows designer to focus on more important issues
Scenario 1: Overlooking rules
O-ring failure, causing in-flight shutdownsCause: in certain conditions, o-rings can become twisted during assembly & disassembly
Scenario 2: Too many cooks...
Designers working on turbine blades decide to change the shaft diameterLeads to problems for other designers working on other parts connected to the shaft
Design has the greatest effect on total cost
The Designers’ Workbench (Features)
Designs are represented using an ontology
Design rules are implemented so that they can be checked automatically
Feedback is given to the designer about the violated rules
The Designers’ Workbench (1)
The drawing with feature
markers
The feature ontology tree
The feature property panel
Problems
• The Designers’ Workbench needs constraints.
• Currently, a KE interviews designers...
• ...and studies documentation...
• ...and then implements the constraint using RDQL/Prolog.
• A tedious, error-prone task!
!
??
ConEditor
Aim: to provide designers with an intuitive way to capture/input and maintain the constraints themselves.
Designers will have control over the definition and refinement of constraints greater trust in the resulting constraint checks.
Screenshot of ConEditor’s GUI
The Taxonom
y tree
List of Keyword
s
The Central Panel
The Result Panel
Tool Bar
Functionality
Classes, subclasses and properties are extracted from the domain ontology and listed as a taxonomy (in the form of a tree)
A constraint expression can be created by selecting entities from the taxonomy tree and combining them with a pre-defined set of keywords and operators from a high level constraint language CoLan
Input using ConEditor
byDomain Expert
(in CoLan)
CoLan toCIF(XML)
The Designers’Workbench
A sample constraint
“Each concrete feature must have a material that can withstand the environmental temperature”
Constrain each f in Concrete Feature to have max_operating_temp(has_material(f)) >= operating_temp(f)
CoLan version
Constraints in Tabular Form
Preliminary Evaluation (Field Trials at Rolls Royce, Derby)
Summary: GUI seems to be simple, user friendly
and fairly intuitive to use Controlled Acquisition Scenario Followed all the steps but felt the need
for some training Design Standards Group (has
responsibility)
Planned System Architecture
Maintenance of Constraints (Issues/Problems)
Constraints might: only apply in certain conditions evolve become redundant require revision have no documentation
Maintenance is an expensive and important task that can be complex
Maintenance of Constraints (Issues/Problems)
A Classic example:
DEC, Digital Equipment Corporation: A Large computer manufacturerR1/XCON: An Expert System to automate configuration of computers (1980)Need for maintenance:
Computer industry is highly innovative: new components
Yearly 40% of rules are rewritten Rules are complicated Interaction between rules is extremely complicated “It did the work of 75 people but it took 150 to
maintain it”
Support and use of XCON was stopped in the early nineties.
Proposed Solution/SystemCapture and represent the context of a constraint as an “application condition” along with the constraint Detect subsumption, contradiction, redundancy, etc. between constraints and their “application conditions” against the domain ontology (verification and validation)Use the “application conditions” to provide more support to maintenance (query facility) Record versions of constraints and their “application conditions”
Application conditions example(empirical studies on kite design)
Constrain each k in Kite
such that has_type(k) = “Flat” and has_shape(k) = “Diamond”
to have tail_length(has_tail(k)) = 7 * spine_length(has_spine(k))
Subsumption
Constrain each s in Sled_kite
such that has_size(s) = “standard”
to have kite_line_strength(has_kite_line(s)) >= 15
Constrain each c in Conventional_sled_kite
such that has_size(c) = “standard”
to have kite_line_strength(has_kite_line(c)) >= 15
Subsumption
Constrain each s in Sled_kitesuch that has_size(s) = “standard” orhas_size(s) = “large”to have kite_line_strength(has_kite_line(s)) >= 15
Constrain each s in Sled_kitesuch that has_size(s) = “standard”to have kite_line_strength(has_kite_line(s)) >= 15
Inconsistencies: Contradiction
Constrain each k in Kite
such that has_wind_condition(k) = “strong” and has_type(k) = “stunt”
to have kite_line_strength(has_kite_line(k))>90
Constrain each k in Kite
such that has_wind_condition(k) = “strong” and has_type(k) = “stunt”
to have kite_line_strength(has_kite_line(k))<90
The Designers’ Workbench – tool to support designers (Motivation)
ConEditor – tool to capture and maintain constraints (Done)
Preliminary Evaluation at Rolls-Royce (Done)
Capture and Use of “application conditions” to support maintenance (Doing)
Full Scale Evaluation (To be done)
Summary/Status
THANK YOU
Questions/DiscussionQuestions/Discussion