VT: Expert Elevator Designer

1. VT: Expert Elevator Designer By Edwin P. Jacques

2. What does VT do? • System that performs the engineering task of efficient elevator system design. • Attempts to find best elevator design. • Find solution in reasonable amount of time. • Explains design decisions to a human operator.

3. Designing an Elevator • Characteristics of the problem: • Requirements for elevator design are numerous: • Meet customer’s functional specifications • Meet legal safety requirements • Minimize costs (initial and maintenance) • Many decisions are interrelated (many interactions) • Large number of potential parts combinations. • Large search space, can’t test all combinations • Implications for design of VT: • Must backtrack, because maintaining parallel potential solutions is unmanageable. • Must construct a solution, because testing for all possible cases is unmanageable.

4. Paradigms of VT • Construct an approximate solution and progressively refine it. • Make good guesses about what parts to select. • Incorporate domain-specific knowledge. • Apply knowledge to backtracking (domain-dependent backtracking), as opposed to MOLGEN. • Provide structure for domain-specific knowledge that reflects it’s function.

5. What VT Does: • Sources of Information • Customer requirements forms • Performance specifications, carrying capacity, speed, product selection (like light fixtures, etc.) • Architectural and structural design of the building • Wall-to-wall dimensions in the elevator shaft (hoistway), locations of rail supports, etc. • Architectural design of the elevator cabs, entrances and fixtures. • Knowledge about pieces of equipment and machinery that must be configured (supplied in read-only database). • Output • “Optimally” selected equipment necessary to design layout of elevator in the hoistway, meeting above requirements, and minimizing cost. • Explanation of all decisions.

6. Interface • Command-line, console. • Commands: • INPUT: enter information about contract • Can express certainty of data. • Overrides of input allowed. • Product may be temporarily unavailable. • Report of overrides kept for system maintenance. • RUN: Process input data • Optional Interactive mode asks for confirmation of each fix. • SHOW: Display results of a run • EXPLAIN: Explain results • SAVE/EXIT

7. Constraint Violation Report Fragment • Requirement violated: • The MAXIMUM-TRACTION-RATIO constraint was violated. The TRACTION-RATIO was 1.806591, but had to be <=1.783873. The gap of 0.2272000E-01 was eliminated by the following action(s): • Decreasing CWT-TO-PLATFORM-FRONT from 4.75 to 2.25 • Upgrading COMP-CABLE-UNIT-WEIGHT from 0 to 0.5E-01 • VT changed a value it estimated: • The CAR-RUNBY (estimated to be 6) has been changed to 6.125.

8. Overview: Construction • Start with approximate design, refine. • Forward-chaining (construction rules/heuristics). • Constraints specified as soon as required information available (data-driven). • Builds dependency network that records what values were used to obtain each value. • Sufficient to identify all contributors to violated constraint. • Can be used to determine potential points to backtrack • Domain expertise used to determine least costly change. • Demons check for constraint violations.

9. Overview: Handling Constraint Violations • From KB, determine what fixes are appropriate for this violation. • Fix selection • Try every fix at a given at highest preference level. • Try combining fixes at highest preference level. • Try all fixes at next preference level. • Try combining fixes at current preference level. • Try combining fixes at current preference level with changes of higher preference. • Keep going… • Determine if suggested fix violates a constraint on that parameter (optimization). • Forward-chain to determine any inconsistencies with applying the fix.

10. Steps • Machine-model step (p100) are construction rules. • Note the trace of values used to decide on other values. • Note the declarative trace. This facilitates explanation. • Propose-fix step (p101) • Rules to handle constraint violations • Note preference rating (fixed value) • If none of the fixes solves the constraint, a dead-end is reached.

11. Explanation Facility (p102) • Examines past decisions. • Find node in dependency network that recorded the decision. • If determine from formula • Display formulas and conditions in the system that made formula appropriate. • If method of calculation chosen because of pre-condition, explain pre-condition. • If database lookup • Explain which element in database was chosen and why. • Identifies “unusual” values, caused by: • Inconsistent input, unusual input, default input, fixed values • Depth indicates how far upstream the contributor is • Explains hypothetical reasoning to demonstrate alternative decisions.

12. Hypothetical Reasoning • “Why not” and “what if” • System is “re-run” with new suggested input to determine if suggestion is possible, and what would be the output. • “Why not” explanation • determines what could be done to obtain the desired result. • Explains if change is not optimal and why • These queries are nearly identical internally.

13. Results: • Westinghouse actually used it • but don’t know how much, • or if they still use it today. • Performance • Tested on a VAX 11/780, 20MB RAM (1986) • Took between 7 and 22 minutes to complete test runs by Westinghouse engineers • Thanks to Moore’s Law, today, a workstation in the same class would take 1/1000 the time (between .4 and 1.3 seconds!!!)

14. SALT: Knowledge Acquisition • Automated knowledge acquisition tool for propose-and-refine problem solvers. • Acquires knowledge • Generates knowledge base compiled into rules • Domain-specific knowledge for: • PROPOSE-A-DESIGN-EXTENSION • IDENTIFY-A-CONSTRAINT • PROPOSE-A-FIX

15. SALT: Continued • Built on a dependency network. Links represent • How contributors are combined • Specification of nature of restriction • Declaration of nature of proposed revision. • Enter knowledge piecemeal. • Keeps track of how pieces “fit” and warns where pieces might be missing.

16. SALT: Treating Trouble Spots • SALT determines all potentially harmful interactions between rules: • Premature dead-end • Infinite loop between counteracting rules (p107) • Special fixes to implement trouble spots • Premature dead-ends not a problem with VT (but is easily fixable by adding rules to try more expensive fixes) • Infinite loop dealt with by adding rules that deal with both constraints causing the loop simultaneously instead of one at a time.

17. Questions? ?