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