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 • Motivation:The 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. Design has the greatest effect on total cost

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

8. The feature ontology tree The feature property panel The Designers’ Workbench (1) The drawing with feature markers

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

10. 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.

11. The Taxonomy tree List of Keywords The Central Panel Screenshot of ConEditor’s GUI The Result Panel Tool Bar

12. 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)

13. 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

14. Constraints in Tabular Form

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

16. Planned System Architecture

17. 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

18. 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.

19. 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”

20. 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))

21. Subsumption Constrain each s inSled_kite such that has_size(s) = “standard” to have kite_line_strength(has_kite_line(s)) >= 15 Constrain each c inConventional_sled_kite such that has_size(c) = “standard” to have kite_line_strength(has_kite_line(c)) >= 15

22. Subsumption Constrain each s in Sled_kite such thathas_size(s) = “standard” or has_size(s) = “large” to have kite_line_strength(has_kite_line(s)) >= 15 Constrain each s in Sled_kite such thathas_size(s) = “standard” to have kite_line_strength(has_kite_line(s)) >= 15

23. Inconsistencies: Contradiction Constrain each k in Kite such that has_wind_condition(k) = “strong” and has_type(k) = “stunt” to havekite_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 havekite_line_strength(has_kite_line(k))<90

24. 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)

25. THANK YOUQuestions/Discussion