Acquisition and Maintenance of Constraints in Engineering Design

1
Acquisition and Maintenance of Constraints in
Engineering Design

• By
• Suraj Ajit
• Supervisor Prof. Derek Sleeman

2
Presentation Overview

• MotivationThe Designers Workbench
  (Overview)
• ConEditor
• Maintenance of Constraints (Issues/problems)
• Proposed Solution/System
• Summary/Status
• Questions/Discussion

3
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 retrieve
• Multiple designers working on same engine
• decisions made by one designer can have hidden
  implications
• Many thousands of standard parts and features
• Allows designer to focus on more important issues

4
Scenario 1 Overlooking rules

• O-ring failure, causing in-flight shutdowns
• Cause in certain conditions, o-rings can become
  twisted during assembly disassembly

5
Scenario 2 Too many cooks...

• Designers working on turbine blades decide to
  change the shaft diameter
• Leads to problems for other designers working on
  other parts connected to the shaft

6
Scenario 3 Lost rationales

• A rule states that the total load on a bearing
  must be lt 125 tonnes psi
• But the reason for this rule has been lost...

(Image from www.duratrax.com)
7
Scenario 4 Bending the rules

• Parts that rotate relative to each other must be
  ? 5mm apart
• But experienced designers can bend this rule in
  some conditions

(Image from www.grc.nasa.gov )
8
Design has the greatest effect on total cost
9
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

10
The Designers Workbench (1)
The drawing with feature markers
11
The Designers Workbench (2)
If a constraint is violated, the affected
features are highlighted
and a report is generated
12
The Designers Workbench (3)
The user can view documents underlying the
constraints
13
The Designers Workbench (4)
By adjusting property values, the user can
resolve the violations
14
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!

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

16
Screenshot of ConEditors GUI
The Result Panel
Tool Bar
17
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 by Domain Expert (in
CoLan)
The Designers Workbench
CoLan to CIF(XML)
18
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)) gt
  operating_temp(f)

CoLan version
19
Constraints in Tabular Form
20
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)

21
Planned System Architecture
22
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

23
Maintenance of Constraints (Issues/Problems)

• A Classic example
• DEC, Digital Equipment Corporation A Large
  computer manufacturer
• R1/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.

24
Proposed Solution/System

• Capture 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

25
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))

26
Subsumption

• Constrain each s in Sled_kite
• such that has_size(s) standard
• to have kite_line_strength(has_kite_line(s)) gt
  15
• Constrain each c in Conventional_sled_kite
• such that has_size(c) standard
• to have kite_line_strength(has_kite_line(c)) gt 15

27
Subsumption

• Constrain each s in Sled_kite
• such that has_size(s) standard or
• has_size(s) large
• to have kite_line_strength(has_kite_line(s)) gt
  15
•  
• Constrain each s in Sled_kite
• such that has_size(s) standard
• to have kite_line_strength(has_kite_line(s)) gt
  15
•  

28
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))gt90
• 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))lt90

29
Inconsistencies Contradiction

• Constrain each k in Kite
• such that
• density(has_material(has_cover(k))) gt 0.5
• to have has_level(k) beginner
•  
• Constrain each k in Kite
• such that
• density(has_material(has_cover(k))) lt 0.5
• to have has_level(k) beginner

30
Inconsistencies Redundancy

• Constrain each c in Conventional_sled_kite
• such that has_size(c) standard
• to have kite_line_strength(has_kite_line(c)) gt
  15
•  
• Constrain each t in Traditional_delta_kite
• such that has_size(t) standard
• to have kite_line_strength(has_kite_line(t)) gt
  15
•  

31
Inconsistencies Redundancy

• Constrain each k in Kite
• such that has_level(k) beginner
• to have name(has_material(k)) rip-stop
• nylon
•  
• Constrain each k in Kite
• such that has_class(k) beginner
• to have name(has_material(k)) rip-stop
• nylon

32
Generalisation/Fusion

• Constrain each c in Conventional_sled_kite
• such that has_size(c) standard
• to have kite_line_strength(has_kite_line(c)) gt
  15
•  
• Constrain each m in Modern_sled_kite
• such that has_size(m) standard
• to have kite_line_strength(has_kite_line(m)) gt 15

33
Generalisation/Fusion

• Constrain each s in Sled_kite
• such that has_size(s) standard
• to have bridle_length(has_bridle(s)) gt 3
  has_height(s)
• Constrain each s in Sled_kite
• such that has_size(s) small
• to have bridle_length(has_bridle(s)) gt 3
  has_height(s)
•  

34
Summary/Status

• 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)

35
THANK YOU Questions/Discussion
36
Related Work/Bibliography (Selected)

• Soloway, E, Bachant, J. and Jensen, K. (1987)
  Assessing the Maintainability of XCON in -RIME
  Coping with Problems of a very Large Rule Base
  Proceedings of the Sixth Int. Conf. on Artificial
  Intelligence, Seattle, WA Morgan Kaufman, Vol
  2824-829
• Bultman, A., Kuipers, J. and Harmelen, F. v.,
  Maintenance of KBS's by Domain Experts The Holy
  Grail in Practice, Thirteenth International
  Conference on Industrial Engineering
  Applications of Artificial Intelligence Expert
  Systems IEA/AIE'00, 2000
• Janet E. Burge D. C. Brown (2000) " Reasoning
  with Design Rationale", Artificial Intelligence
  in Design '00, J. Gero (Ed.), Kluwer Academic
  Publ.

37
Related Work/Bibliography (Selected)

• J. Burge, D.C. Brown, "Rationale Support for
  Maintenance of Large Scale Systems", Workshop on
  Evolution of Large-Scale Industrial Software
  Applications (ELISA), ICSM '03, Amsterdam, NL,
  2003
• Myers, K., Zumel, N. and Garcia, P., Automated
  Capture of Rationale for the Detailed Design
  Process, Proc. of the 11th National Conf. on
  Innovative Applications of Artificial
  Intelligence, CA, 1999, pp. 876-883
• Bracewell, R. H., Ahmed, S. and Wallace, K. M.,
  DRED And Design Folders, A Way of Capturing,
  Storing and Passing on, Knowledge Generated
  During Design Projects, Design Automation
  Conference, ASME, Salt Lake City, Utah, USA, 2004

38
Related Work/Bibliography (Selected)

• Carnduff, T. W. and Goonetillake, J. S., Managing
  Configuration with Evolving Constraints in Design
  Databases, Second International Workshop on
  Evolution and Change in Data Management (ECDM
  2002), Tampere, Finland, 2002
• BRACEWELL, R.H. and WALLACE, K.M. (2003) 'A tool
  for capturing design rationale' in ICED03,
  Design, Stockholm, Sweden, 185-186
• Regli, W. C., Hu, X., Atwood, M. and Sun, W., A
  Survey of Design Rationale Systems Approaches,
  Representation, Capture and Retrieval,
  Engineering with Computers An Int'l Journal for
  Simulation-Based Engineering, special issue on
  Computer Aided Engineering in Honor of Professor
  Steven J. Fenves, 2000, vol. 16, pp. 209-235,
  2000