Exercises on "Elevator design"

Background: These exercises are based on material from a case study jointly carried out by many knowledge engineering research groups all over the world. See the International Journal of Human-Computer Studies, Volume 44, No. 3/4 (March/April 1996) for more information. 

Exercise A: context modelling (organization-task-agent models, Ch. 3)

This exercise assumes you have read Ch. 3 of the KE&M book, called The Task and its Organizational Context. Read the problem statement carefully and fill in the following worksheets:

1. OM-1: characterize the problems and solution(s) stated in the text. Think also about the "invariant" part of the organization: external actors, goals, mission, etc. There is not enough information in the text about this, but you can make some "educated guesses".
2. OM-2: describe the organization process in the future situation.
3. OM-3: describe the tasks in the process (see OM-2) in more detail through this worksheet.
4. OM-5: try to give an indication of both the technical and business feasibility. Also discuss briefly the proposed action and the expected impacts.  As part of the study of technical feasibility, it is useful to establish the task type associated with elevator design.
5. TM-1+2: describe the design task for standard elevators in more detail plus the associated knowledge items.
6. AM-1: fill in the worksheet AM-1 for the agents that will take on the liaison role and the use/maintenance role.

Exercise B: initial domain schema (knowledge model, Ch. 5)

This exercise assumes you have read Ch. 5 of the KE&M book on Knowledge Model Components. Read the results of the interview with the expert carefully, and construct an initial domain schema.

The elevator-design application

Problem statement

A company specializes in the construction of elevators for buildings. The company is organized in a number of departments. The three main departments involved in this study are the sales department, the design department and the production department.
The design department is suffering from a chronic lack of adequately trained  personnel. The sales department suffers from this, because they are dealing with customers that complain about the long periods required to make a tender. For such a tender the availability of a design is mandatory, because it provides the basis for the cost calculation. Interviews with the design department have revealed that about 90% of the elevator design is actually "standard stuff", meaning that the design is based on relatively simple variations on a standard elevator design. Therefore, the head of the design department has proposed to construct a software system that should be able to automatically propose an elevator design in such a standard situation. The human designers could then concentrate their efforts on the difficult 10% of non-standard designs.

A tender consists of a fixed set of information items:

• A technical description of the building involved, describing the building dimensions, data about the elevator shaft, etc.
• A list of the requirements of the customer with respect to the elevator, e.g. the number of persons, the desired speed, facilities in the elevator cab, color preferences.
• The elevator design which consists of  a number of technical drawings and a list of components.
• A cost calculation including component costs, labor costs, costs of building adjustments (if required), etc.

The procedure for constructing a design  in the future situation (i.e. with a system for generating standard designs) is envisaged by the company to be something like the following. The sales department passes the customer information to a (newly appointed) liaison person of the design department. This liaison person decides whether the design can be handled by the system. If the answer to this question is "yes", the sales department can expect a speedy response (probably within two working days). For the use and maintenance of the elevator design system a new organizational role is defined. Both the liaison role and the use/maintenance role should typically be fulfilled by existing personnel of the design department with the required expertise, e.g., social skills.
In the case of non-standard elevator design (e.g., an abnormal elevator shaft), the design will need to be constructed "manually". The expectation is that in the new situation this can also be done much quicker because of the work load reduction for the designers. A delivery time of seven working days on average is estimated to be feasible. A list of factors that influence the complexity of non-standard design still needs to be worked out.

Results of a focused interview with a domain expert

In this interview the knowledge engineer has tried to get a more detailed insight into the structure of domain knowledge used for designing elevators. The scope of the interview is limited to the standard designs. It turns out that there are indeed a number of standard (or skeletal) elevator designs that are used by the experts as a basis for the design process. The company has a database of elevator components that can be used in such standard elevators. For each component (e.g., a cab or hoist cable) the designer chooses a number of "models", for example, hoist cables with different diameters. Each component has a number of parameters that describe component-related values (such as weight, price, physical dimensions). Most parameter values are fixed when a component model is chosen (e.g. the price).

The expert is able to name at least four types of domain knowledge that is used in the design process:

1. There appear to exist a number of formulas such that existing design values can be used to compute a new part of the design (a component choice or a parameter value). These formulas are often based on physical laws. For example, the weight of the counterweight can be computed from the weight of the frame plus the weight of the ballast (including the plates placed in the frame).
2. The experts use preferences to choose a component in cases where no other design knowledge dictates a choice. Each preference typically has a name (e.g. "lowest costs") and/or is associated with an ordinal scale of preferences. Preferences with a higher value are considered more important.
3. The experts use the term "constraint"  to point to limitations on the choice for a certain component given the choice for other components. For example, the weight of the elevator cab limits the choice of the hoist cable. Each constraint has a domain-specific name that is supposed to be indicative of the types of demands the constraint is based on. An example of such a constraint name is "maximum traction ratio of the hoist cable".
4. When a design problem occurs, for example if a violation of a constraint indicates that the design should be changed, the designers use so-called "fixes" to modify the design. Each fix links a specific constraint with an ordered set of modification operations (e.g., upgrading a component), that can be used to solve the problem caused by the violation.