Acquisition and Maintenance of Constraints in Engineering Design By Suraj Ajit Supervisor: Prof. Derek Sleeman

Presentation Overview Motivation:The Designers Workbench (Overview) ConEditor Maintenance of Constraints (Issues/problems) Proposed Solution/System Summary/Status Questions/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 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

Scenario 1: Overlooking rules O-ring failure, causing in-flight shutdowns Cause: 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 diameter Leads to problems for other designers working on other parts connected to the shaft

Scenario 3: Lost rationales A rule states that the total load on a bearing must be < 125 tonnes psi But the reason for this rule has been lost... (Image from )

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 )

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

The Designers Workbench (2) If a constraint is violated, the affected features are highlighted… … and a report is generated

The Designers Workbench (3) The user can view documents underlying the constraints

The Designers Workbench (4) By adjusting property values, the user can resolve the violations

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 ConEditors GUI The Taxonomy tree List of Keywords 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 by Domain Expert (in CoLan) CoLan to CIF(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 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.

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

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_kite such that has_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 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

Inconsistencies: Contradiction Constrain each k in Kite such that density(has_material(has_cover(k))) > 0.5 to have has_level(k) = beginner Constrain each k in Kite such that density(has_material(has_cover(k))) < 0.5 to have has_level(k) = beginner

Inconsistencies: Redundancy Constrain each c in Conventional_sled_kite such that has_size(c) = standard to have kite_line_strength(has_kite_line(c)) >= 15 Constrain each t in Traditional_delta_kite such that has_size(t) = standard to have kite_line_strength(has_kite_line(t)) >= 15

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

Generalisation/Fusion Constrain each c in Conventional_sled_kite such that has_size(c) = standard to have kite_line_strength(has_kite_line(c)) >= 15 Constrain each m in Modern_sled_kite such that has_size(m) = standard to have kite_line_strength(has_kite_line(m)) >= 15

Generalisation/Fusion Constrain each s in Sled_kite such that has_size(s) = standard to have bridle_length(has_bridle(s)) >= 3 * has_height(s) Constrain each s in Sled_kite such that has_size(s) = small to have bridle_length(has_bridle(s)) >= 3 * has_height(s)

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

Questions/Discussion THANK YOU Questions/Discussion

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

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

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, 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 , 2000