HELSINKI UNIVERSITY OF TECHNOLOGY Faculty of Information Processing Science

Juha Tiihonen Computer-assisted Elevator Configuration

Thesis submitted for official examination for the degree of Master of Science in Engineering in Espoo on June 1, 1994

Supervisor:

Professor Reijo Sulonen

Instructor:

Professor Reijo Sulonen

Preface This thesis was written as part of Data Management for Modular Products, a joint project of the Helsinki of Helsinki University of Technology and KONE Elevators with partial funding from the Finnish Technology Development Center (TEKES). The project is a part of SIMSON Technology Program of the CIM Development Program for Finnish Metal and Engineering Industry (FIMET). In practice the work was carried out at Helsinki University of Technology, Laboratory of Computer Science in close co-operation with KONE Elevators Engineering Systems, HES, and KONE Elevators Northern Europe, NEC. I want to thank professor Reijo Sulonen for his comments and the considerable amount of time he spent on reading and commenting the thesis. Tomi Männistö and Hannu Peltonen gave many valuable comments both on the contents and the language of the thesis. Thank you very much. Juha Mäkäräinen was my contact person at KONE Elevators. I want to thank him on for smooth co-operation and good ideas. Asko Martio provided the mental and economical sponsorship without which completing this work would have been impossible. Martti Sarjanen, Reijo Silvola and Erkki Kaukinen as KONE experts have used considerable time in helping me to acquire the knowledge required. Juha Mäkäräinen and Rauno Nousiainen gave me important information about the problem. I want to thank all of you. I want to thank Sami Jokela for his comments. I also want to thank all my colleagues for providing a very pleasant environment to work. Last but not least, I want to thank Marja for her loving support. Espoo 1.6.1994

HELSINKI UNIVERSITY OF TECHNOLOGY

ABSTRACT OF THE MASTERS’S THESIS

Author and name of the thesis : Juha Tiihonen Computer-assisted Elevator Configuration

Date :

01.06.1994

Faculty : Faculty of Information Processing Science Supervisor :

Professor Reijo Sulonen

Instructor:

Professor Reijo Sulonen

Number of pages : 136 Professorship : Tik-76 Information Processing Science

The main goal of this thesis was to study the product configuration problem of elevators. In product configuration, a customer specific design is created on the basis of customer requirements, an existing product architecture and existing components. Major tasks of product configuration are component selection and component parameter value determination. A prototype that configures pre-engineered Novel elevators was developed. The prototype was implemented using Design++, a product modeling tool of Design Power Inc. Design++ is described in some detail. Product configuration is a knowledge intensive task; maintenance of product configuration systems has proved to be difficult. One reason is that current product configuration tools do not support representation of product architecture, conceptual product structure, component interfaces and connections in natural way. Some preliminary ideas for enhancing product configuration modeling are described. It is concluded that it is practical to build product specific product configuration tools for pre-engineered elevators. Further research on the general product configuration problem is required. Keywords: Product Configuration, Design++, Product Knowledge Representation, Elevators

TEKNILLINEN KORKEAKOULU

DIPLOMITYÖN TIIVISTELMÄ

Tekijä ja työn nimi: Juha Tiihonen Tietokoneavusteinen hissien konfigurointi

Päivämäärä:

01.06.1994

Sivumäärä : 136

Osasto :

Professuuri :

Tietotekniikan osasto

Tik-76 Tietojenkäsittelyoppi

Valvoja :

Professori Reijo Sulonen

Ohjaaja:

Professori Reijo Sulonen

Työn päätarkoituksena oli tutkia hissien tuotekonfigurointiongelmaa. Tuotekonfiguroinnin tarkoituksena on suunnitella asiakaskohtainen tuote käyttäen lähtökohtana asiakkaan vaatimuksia, valmista tuotearkkitehtuuria ja olemassaolevia komponentteja. Tärkeimmät tuotekonfiguroinnin tehtävät ovat komponenttien valinta ja komponenttien parametrien arvojen määrittäminen Työssä kehitettiin prototyyppi joka konfiguroi esisuunniteltuja Novel hissejä. Prototyyppi kehitettiin Design Power Inc:n tuotemallinnustyökalulla Design++. Design++ kuvataan työssä melko yksityiskohtaisesti. Tuotteiden konfiguroiminen on tietämysintensiivistä toimintaa. Tuotekonfigurointijärjestelmien ylläpito on osoittautunut vaikeaksi. Eräs syy on se että nykyiset tuotekonfigurointityökalut eivät tue luonnollisella tavalla tuotteiden arkkitehtuurin, käsitteellisen tuoterakenteen, komponenttien rajapintojen ja komponettien välisten yhteyksien esittämistä. Työssä esitetään alustavia ajatuksia tuotteiden konfiguroinnin mallinnusmenetelmien parantamiseksi. Loppupäätelmänä esitetään että esisuunnitelluille hisseille on järkevää rakentaa tuotekohtaisia tuotekonfigurointijärjestelmiä. Jatkotutkimusta yleisen tuotekonfigurointiongelman ratkaisemiseksi tarvitaan. HAKUSANAT: tuotekonfigurointi, Design++, tuotetietämyksen esittäminen, hissit

Table of Contents 1 Introduction 1.1 Background 1.2 About KONE Corporation 1.3 The Product Configuration Problem 1.3.1 About Engineering Design 1.3.2 Product Configuration as Design 1.3.3 Definition of Configuration Tasks in Literature 1.3.4 Related Work 1.4 Goals 2 About Configuration Knowledge 2.1 Components 2.1.1 Fixed Components 2.1.2 Parametrized Components 2.2 Constraints 2.3 Cell 2.3.1 Motivation 2.3.2 Description of Cells 2.4 Ports and Connectors —Modeling Component Interfaces 2.4.1 Motivation 2.4.2 Overview of Ports and Connectors 2.4.3 Ports and Connectors—Some Details 2.4.4 Examples 2.4.5 About Design Alternatives 2.4.6 Some Problems 3 Elevator Domain 3.1 External Elevator Behavior and Architecture. 3.2 Technical Requirements for Elevators. 3.2.1 Total Travel Time, Waiting Time and Capacity 3.2.2 Safety 3.2.3 Reliability 3.2.4 Travel Convenience 3.2.5 Other Factors 3.3 Rope Elevator Architecture 3.3.1 Rope Elevators—Overall Structure 3.3.2 Novel Pre-engineered Elevator Architecture 3.4 Elevator Configuration 3.4.1 Overview 3.4.2 Organization. 3.4.3 Delivery Processes 3.4.4 Configuration Process in Practice 3.4.5 Differences of Delivery Processes 4 Design++ 4.1 Design++ Overview 4.1.1 D++ Background Information 4.1.2 About D++ Base Technology 4.2 The Basic D++ Concepts

1 1 1 2 2 5 7 9 12 13 14 15 15 18 20 21 22 24 24 26 28 33 36 39 42 42 44 44 46 46 46 47 47 47 55 55 55 56 56 56 60 63 63 64 64 65

4.2.1 Attributes and Facets 4.2.2 Components and Component Libraries 4.2.3 Product Structures in D++ —Models 4.3 About D++ Mechanisms 4.3.1 General 4.3.2 Determining the Value of an Attribute 4.3.3 D++ :? Reference Mechanism 4.3.4 The D++ Dependency Maintenance System 4.3.5 Component Connections 4.3.6 Control Representation 4.3.7 The D++ Reporting Facility 4.3.8 D++ CAD Link 4.3.9 D++ Relational Database Interface 4.3.10 The D++ User Interface 4.4 D++ Macros and Functions 4.4.1 Design Rule Macros 4.4.2 D++ User Functions 4.5 Conclusions 5 The Implemented Prototype 5.1 General 5.1.1 Goals 5.1.2 Development Environment 5.2 About the Development Process 5.3 Functionality 5.3.1 Partial elevator configuration 5.3.2 Performance 5.3.3 Assumptions 5.4 Knowledge Representation 5.4.1 Architecture 5.4.2 Overview of Knowledge Representation 5.4.3 Component Representation 5.4.4 Consistency Checks 5.4.5 Technical Specification Representation 5.5 Interfaces to Other Systems 5.5.1 Component Order Tool 5.5.2 ESKO Interface 5.6 An Example of a Component —ADX Level Doors 5.7 Metrics 6 Summary and Conclusions Appendix A: Design++ Reference Macros Appendix B: Design++ Model Functions Appendix C: Selection Tables

65 66 67 72 72 72 74 77 77 78 79 80 80 81 85 86 87 89 92 92 92 92 94 95 96 97 97 100 100 100 102 104 107 107 107 110 111 117 119 125 126 129

1 Introduction 1.1

Background

Many global markets are highly competitive. A company must be able to fill the increasing customer needs better and better. Customer needs can often be satisfied by selling a suitable “off-the-shelf” standard product. Flexibility of such products is not always enough to satisfy the customer needs. Another alternative is to manufacture a product according to customer specifications. Products manufactured to customer requirements always require some order bound work. In minimum, order bound work is just communicating some simple parameter values, like paint color of surface material to the manufacturing unit and, after manufacturing, delivering the manufactured customer specific product instance to the customer. At the other extreme, a genuinely unique one-of-a-kind product can be designed and manufactured. Product configuration is related to the delivery process of products that are manufactured to customer requirements on basis of an existing product architecture and existing components. Elevators are complex modular products. Each delivered elevator is assembled from parametrized components according to customer requirements. Building dimensions, customer selectable options and several internal constraints that limit valid designs and their optimality must be taken into account. The components that are used are complex. Therefore product configuration of elevators is a non-trivial problem. KONE elevators have released a family of pre-engineered elevators, namely the NOVEL family. They are volume products. This work examines the possibility of automating the configuration process of Novel Elevators.

1.2

About KONE Corporation

KONE Corporation was established in 1910 and had in 1993 sales of 10813 million FIM; and income before taxes and allocations was 430 million FIM. Average number of employees in 1993 was 20890. The stock is quoted on Helsinki Stock Exchange. The main divisions and their percentage of annual sales in 1993 were KONE Elevators 76%, KONE Cranes 18%, KONE Wood and other units 6%. Main market areas are European Union 55%, rest of Europe 17%, North America 13%, Asia and Australia 11%. Other areas form only 4% of sales. KONE Elevators is the biggest and most important division of KONE Corporation; now even more because KONE Cranes was divested in spring 1994. The number of employees 1

31.12.1993 was 16900. Sales in 1993 were 8258 million FIM. The main activities are elevator and escalator maintenance and modernization at more than 60% of sales. The main products of KONE Elevators are person-, bed-, goods- and hydraulic elevators; escalators and walkways. Their share of sales is less than 40%. The number of ordered new units wa 14800 and 15700 units were manufactured in 1993.

1.3

The Product Configuration Problem

1.3.1

About Engineering Design

Function of a product is what the product is supposed to do. Structure of a product tells from which parts, or components, it consists of. A correct design maps function to a realizable structure that is also good enough with respect to some optimality criteria. Many products are physical systems that have both internal and external behavior, that is, they are active in a way or another. Function of physical systems is achieved trough the structure behaving in a suitable way [Tong 92]. Most non-trivial products consist of components. By connecting suitable components in an appropriate way to each other and, sometimes, to the surrounding environment, the desired behavior results and the function is fulfilled. In other words, the product works. A completed product design tells from which concrete physical components the product consists of and how the components should be arranged and connected. It is not enough just to identify the components. Conceptual Product Structure and Architecture. Architecture of a product is the general arrangement using which the required external behavior can be produced. Conceptual product structure tells to which roles components must be selected or designed within an architecture so that their combined behavior produces the desired function. Architecture and conceptual product structure are abstraction levels between concrete components and desired function; conceptual product structure is part of architecture. Components can be fixed off-the-shelf components or parametrized components. Parameters affect or directly determine some properties of the component. Some typical parameters are surface finish color, dimensions, power, etc. When parametrized components are used, values to their parameters must be determined. Parametrized components must be manufactured to a particular order. The product design, or reports derived thereof, is used as a specification to manufacturing unit(s). Therefore the design must be complete enough. Complexity of design and size of the solution search space can vary a lot. Some factors to consider are whether the designer must • map function to behavior • map behavior to architecture and conceptual product structure

2

• • •

design new components to roles of conceptual product structure select components from existing ones determine parameter values of components

These concepts are best illustrated by an example. Example Function. Assume that it must be possible to transport persons, possibly in a wheelchair, between floors of a new building. It is decided that a product is needed; its function is to offer capability to transport persons, also to persons in a wheelchair, between floors. Mapping of Function to Behavior. One possible external behavior that implements the function is to arrange a plane or a car that moves between the floors. Persons can stand, or sit in a wheelchair, on the moving plane or bottom of the car. As a result of the movement, the passenger is transported from one floor to the desired plane. Assume that a vertically moving car is the external behavior using which we select to implement the requirement. The car can be moved vertically in many ways. Some alternatives are illustrated in figure 1.

A

Drum, motor and rope

B

C

Pulley, motor and rope

Hydraulic cylinder

Figure 1: Some Alternatives of Moving a Car Vertically Mapping of Behavior to Architecture and Conceptual Product Structure. Alternative A uses a drum, a motor that rotates the drum and a rope that winds around the drum. The car moves with the rope as the drum rotates. Alternative B uses a pulley, a motor that rotates the pulley, a counterweight and rope. Counterweight approximately balances the weight of the car. The whole weight of the car and the counterweight rest on the pulley. This creates enough friction so that the car moves with rotation of the pulley. Alternative C uses a hydraulic cylinder. As the hydraulic cylinder shrinks or expands, the car moves.

3

Roles of conceptual product structure in architecture A are a drum, a motor, a car and rope; alternative B needs a pulley, a motor, a counterweight, a car and rope. Roles of alternative C are a hydraulic cylinder and a car. Conceptual product structure is not yet a concrete description of product structure. It merely states to which roles actual concrete components are needed. Design of New Components. In this example it is assumed that no new components have to be designed because similar products are produced frequently. Therefore designs of suitable components exist. Component Selection and Parameter Value Determination. During sales customer requirements were mapped to an elevator with architecture and conceptual product structure B. The nominal speed was determined as 1.0 m/s and maximum load as 8 persons or 630 kg. For each role of the conceptual product structure suitable mutually compatible components that can meet the requirements and produce the desired function must be designed or chosen from existing ones. Clearly all components are not potential candidates to all roles; it is impossible to use a counterweight as a motor. An architecture may accommodate optional components that are not always required. Parameter values of the components must be determined. It is possible, even typical, that component selection and parameter value determination interact and are mixed so that there are no separate component and parameter value determination phases. Car type CA03 is a parametrized component, its bottom width can be 900 to 1300mm in 100mm increments, depth can be 1400 or 1600mm. It is determined that 1200*1400mm CA03 is suitable. The customer wants a deluxe interior decoration with teak wall panels. This brings the total weight of an empty CA03 car to 620 kg. Type and parameter values of the counterweight are determined on basis of maximum load and weight of the empty car. By experience and elevator domain knowledge, the weight of the counterweight should be about 935 kg (car weight + 50% of maximum load). A suitable amount of physically fitting counterweight filler plates are selected to achieve the required weight. Elevator motors have an integrated gear. Several gear ratios are available. The motor rotating speed is usually 1500 1/min when the input current is 50 Hz AC. The pulley is directly connected to output of the gear. Diameter of the pulley, gear ratio, and motor r.p.m. determine the achieved nominal speed. Maximum nominal load can be calculated on basis of maximum nominal load, gear ratio, motor power and pulley diameter. Maximum loads for each combination are listed in a table with entries to all possible combinations. The tables are used to select a suitable motor type, its gear ratio and pulley diameter. The selection is based on maximum load and the desired speed. From the table of motor MT02 it can be seen that MT02 with gear ratio 2/52, a 340 mm pulley and 6.0 kW type motor is optimal; it provides speed of 1.03 m/s for an elevator with load up to 630 kg. This is just enough to satisfy the need. 4

Amount of Unspecified Structure According to Tong and Sriram [Tong92] the unspecified structure, that is, the scope of design can be used to indicate complexity of design tasks Structure Synthesis Tasks. Scope of design is architecture and conceptual product structure. Even mapping from function to required behavior may have to be solved. The product can consist of any components that may exist or may have to be designed. Structure Configuration Tasks. In structure configuration tasks architecture and conceptual product structure are known and are not part of the design problem. Naturally, mapping from function to required behavior is outside the scope of design, too. Parameter Instantiation Tasks. In parameter instantiation tasks parametrised components have been selected. The design problem is to determine values to parameters. Creative, Innovative and Routine Design Control knowledge and methods determine what part of the design to address next and which methods or knowledge to use. Generative knowledge and methods generate new points in the design space, that is, carry the design forward. Design processes can be divided to routine, innovative and creative on basis of amount and quality of available generative and control knowledge [Tong92]. This division is generally accepted although there is argument about the exact definitions, see [Gero90]. Routine Design Tasks. In routine design tasks control is straightforward. Little or no search is required to select the next step is required. There is also enough directly applicable knowledge and methods to actually carry out the selected step. For example, all the variables and their applicable ranges, as well as the knowledge to calculate their values are directly available. Innovative Design Tasks. Innovative design tasks require problem solving to determine the next step or to carry it out. Application of directly available knowledge, that is knowledge available without problem solving, would produce unacceptable results. Creative Design Tasks. If unguided search through a large search space is the best control method available or the very design space has to be constructed using problem solving, the design process is creative. 1.3.2

Product Configuration as Design

Two phases can be separated from the design process of products that are intended to be customized according to customer requirements. Product development phase is the actual design in which the product, or a family of products is designed. This design phase may leave some things open. The design is completed in order bound engineering, or product configuration phase. Product configuration phase takes a customer order as input and uses it as specification to complete the design.

5

There are two product configuration problems, general configuration tasks and pre-engineered configuration tasks. First general configuration tasks are described first. Shortly also pre-engineered design tasks are discussed. Design process of the product development phase may be a creative structure synthesis task. It also can fall to any of the less complex design categories. The purpose of this phase is to create the overall product design. Mapping of function to behavior, behavior to architecture and to conceptual product structure must be performed before end of this phase. Design of possibly required new components is also done during this phase. Selection of most important, or even all, components can, but does not have to, be performed. How far this process is taken depends on the situation. In many cases at least some component selections are made. Anyway, guidelines and instructions are, or at least should be created to help completion of the design in the configuration phase. When a customer order is processed, a product instance that is based on the product model is created. Its design is completed through guidelines and instructions created in the product design phase. Thus, product configuration deals with component selection and parameter value determination. A consistent design from existing components is produced. Product configuration is, or at least it should be, routine design. Problem solving should not have to be left to order bound engineering phase. Therefore only routine design should occur, innovative and creative design are too complex activities for order bound engineering. A product configuration task can be a pure structure configuration task, a pure parameter instantiation task or a combination of those. By definition, it should never be a structure synthesis task. With respect to other dimensions of design tasks [Tong92], configuration problems relate as follows. Gap in abstraction levels between specification and implementation is relatively short or non-existent. Complexity of interactions between subproblems should be low because product development phase handles such interactions. Amount and type of knowledge that a system user can provide depends on the situation. Pre-engineered Configuration Manual configuration work may take from minutes to days, sometimes even more. The amount of design left to the configuration phase varies considerably. Some products leave a lot of work to do in the configuration phase, some products leave little. Case: Elevators. Elevators have traditionally been designed so that a few different architectures are used. These architectures are quite stable. When new products are designed, new components are developed. For each delivery, a suitable architecture is selected. After that, components are selected and their parameter values determined. This is a general

6

configuration task that fits the definition of a routine structure configuration and parameter instantiation design. In practice this means that configuring a standard elevator may take from half a day to a few days. As a result, a lot of routine work must be done. Pre-engineering. Configuration tasks can be made easier by using pre-engineering. Preengineering means that partially ready configurations are designed. In them many or even most components have been selected and some parameter values determined. The customer can specify only things that are possible within limitations of the partially ready configurations. Therefore partially ready configurations must be designed and documented well. Good design is required to offer flexible enough and good enough alternatives that meet customer requirements while simplifying the delivery and configuration process. To actually aid the configuration process and to communicate capabilities of preengineered configurations, the documentation must be good. Case: Pre-engineered Elevators. In case of elevators pre-engineering means that families of similar elevators are created. Each family has many models. Each model is a partially ready configuration. Most components have been pre-selected and even some attribute values determined, separately for each model. When selling a pre-engineered product, a suitable model is selected and its open customizing options are determined. The generated specification is then used as input to rest of the configuration process. Due to decisions made in advance, the configuration process is much lighter than that of an ordinary elevator. It is substantially easier to build active computer support for pre-engineered configuration than for general configuration. The level of “understanding” that the system must have is considerably lower. 1.3.3

Definition of Configuration Tasks in Literature

Literature on product configuration tasks seems to be concentrated on describing applications that configure products. Quite little has been written on the very problem. Therefore good definitions seem to be quite rare. Some papers also describe actual configuration tools. Mittal and Freyman [Mitt89] A general configuration task is defined as: “Given: (A) a fixed, pre-defined set of components, where a component is described by a set of properties, ports for connecting it to other components, constraints at each port that describe the components that can be connected at that port, and other structural constraints (B) some description of the desired configuration; and (C) some criteria for making optimal selections.

7

Build: One or more configurations that satisfy all the requirements, where a configuration is a set of components and a description of the connections between the components in the set, or, detect inconsistencies in requirements.” MIttal and Freyman describe also a more restricted version of a configuration task. It seems to reflect reality better; it assumes existence of more knowledge. The assumed knowledge occurs in most practical situations. “Given: (A1) one or more functional architectures for desired configurations, each abstractly defined by functions {rf1, rf2, ..., rfn; of1, of2, ... ofm}, where rfi are always needed and ofj are optional; (A2) a fixed, pre-defined set of components, where a component is minimally described by a set of properties, ports for connecting it to components, constraints at each port that describe the components that can be connected at that port, and other structural constraints; (A3) a mapping from each function fi to components ci that are key components in providing fi and a description of other functions that are required by ci in order to function as fi ; (B) some description of the desired configuration, usually in the form of additional constraints on some fi or the associated components; and (C) possibly some criteria for making optimal selections. Build: One or more configurations that satisfy all the requirements, where a configuration is a set of components and a description of the connections between the components in the set, or, detect inconsistencies in the requirements.” Both definitions restrict configuration tasks to pure structure configuration tasks, i.e., they do not allow parametrized components. This is a severe restriction. Both definitions include the notion of ports as connection points through which components can be connected to each other in fixed and pre-determined ways. This is a very important observation. In our view, ports can be configurable, but only in pre-defined ways. See section 2.4 for more detailed discussion. Functional architecture represents the fact that certain functions must be provided by components in order to make the product work. Having key components to each function means that it is known which components could provide that function. This observation is natural. Architecture and product structure described in section 1.3.2 is not functional, instead it is component or component role oriented. It is expected that mapping from required functions to conceptual product structure is done before configuration process starts. In this sense our view seems to be more restricted. Mittal’s model can handle more easily the situation when a new component that can simultaneously supply functions of two or more components becomes available. According to our description, this would mean changing the conceptual product structure; according to Mittal nothing is actually changed in architecture.

8

Najmann and Stein [Najm92] Authors gives two formal definitions of configuration tasks. The central idea of their definition is the notion of functionality. A configuration problem is a tuple . Each functionality has a set of possible values. Each object can contain functionalities with a certain fixed value from the value set. Demands tell how much of each functionality should be provided. Test for each functionality describes whether demand for that functionality is fulfilled. The basic idea is quite close Heinrich’s resource based configuration model [Hein91]. This far described model is called M1. Their extended model M2 adds capability to state rules on number of allowable objects in a configuration. [2,A] ⇒ ([1,B] ∧ ¬[1,C]) ∨ [3,D] would mean that if two A’s are included in a configuration, then it must either have exactly one B and not one C, or, it must include three D’s. It is shown that both models are equivalent. Components are fixed components, parametrized components are not used. The definitions lack ports and architectures. Configurations are just collections of components, their connections are totally ignored. The models is suitable only for pure structure configuration tasks. It does not allow parameter instantiation tasks. Schreiber, Terpstra, Magni and Velzen [Schr94] Yet another working definition is given: “There exists a fixed set of potential components of the artefact to be configured. No creative design of components is done. The goal of configuration is twofold, namely 1. to select and arrange a set of components, and 2. to specify values for component characteristics (i.e. parameters) in such a way that the result meets the requirements and satisfies internal constraints.” The definition is used by its authors to distinguish between types of configuration problems, not as a general definition. Anyway, the definition contains both parameter instantiation tasks and structure synthesis tasks. It also mentions that identifying components is not enough because arranging them is required. In these respects the definition is quite close to our view because it is not restricted to pure structure configuration tasks. 1.3.4

Related Work

R1 Artificial intelligence has been used for product configuration tasks for quite a long time.

9

The first product configurator in literature is R1. It configured Digital Equipment Corporation’s VAX-11/780 computers, see [McDe81]. R1 was developed using OPS5 expert system shell which is a rule based forward chaining tool. All R1 knowledge is represented as production rules. A very significant portion of R1 knowledge was control knowledge. There rule space was large and unstructured; maintenance of the system proved to be very difficult [McDe93]. This is best indicated by the development group size, it grew from two in 1979 to 59 in 1989[Bark89]. Representing control knowledge in a production rule system is possible but not natural. Large knowledge bases that consist of production rules are very hard to maintain. There are at least two major reasons. One is that formulation of all knowledge to simple IF-THEN rules is artificial. The other is that such rule spaces lack encapsulation or other structure. VT VT [Marc92] is an OPS5 based system that configures elevators. Elevator configuration problem has been reduced to a dimensioning task [Schr94]. A dimensioning task is very similar to a parameter instantiation task. That is, only parameter values are unknown. All decisions are represented as attributes value of which should be determined. The product architecture and the resulting conceptual product structure let alone actual product structure are not modeled at all, the problem is flattened to a set of attributes. VT problem solving methodology is propose and revise with knowledge directed backtracking. Approximate design decisions and guesses are made through forward chaining. Verification is handled by constraints that are placed on attributes. Revise operations are suggested by constraint fixes. Much of the actual knowledge is expresses as constraint fixes. Constraints are evaluated as soon as all attributes that they refer to have been solved. If some constraints are violated, constraint fixes is tried. For each constraint, there may be a set of fixes. The fixes have severity ratings that tells roughly the harm associated with the fix; harm varies from “causes no problem” to “compromises system performance”, there are 12 harm ratings in total. All less harmful fixes and their combinations are tried before proceeding to more severe fix harm rating. VT maintains a dependency network between attributes so that values calculated on basis of a value that is later changed are removed. VT uses a knowledge acquisition tool SALT to maintain its rule-base. Sisyphus-93 The VT domain knowledge was described in [Yost92]. The description is strongly biased to propose and verify problem solving method. On basis of that information Sisyphus-93 contest was arranged to model the VT domain.

10

Use of Common KADS methodology [Wiel93] in implementing the VT problem is described in [Schr94]. In their approach, KADS methodology is used to model propose and revise, or more accurately, propose, verify and modify problem solving method through KADS domain and model ontologies. DSPL In [Brow85] and [Brow89] the authors represent a generic tasks for solving routine design problems. A generic tasks is “an elementary combination of a problem, representation, and inference strategy”. Generic tasks are described in “Design Specialists and Plans Language”, DSPL. The first application of DSPL has been used from configuring air cylinders [Brow92]. To solve a problem in DSPL, a hierarchical collection of specialists are defined. Specialists are design agents that try to solve a part of the design, the top-level specialist is responsible for the whole tasks. Specialists can make design decisions in the current context. The current context is represented as a collection of attributes. Specialists can delegate parts of their design responsibility to specialists that are lower in the specialist hierarchy. Each specialist has a collection of plans. Plans consist of calls to specialists or to locally defined tasks. Each plan has a sponsor that can judge how viable the plan is in the current situation. Specialists have selectors that select from plans on basis of judgements of sponsors. Tasks consist of steps. A step can define a value to an attribute. Plans, tasks and steps can have constraints within their execution sequence, the constraints are evaluated only at those phases. There are mechanisms to represent constraint fixes, redesigners can catch constraint violations. In addition, there are failure-handlers. Plans, tasks and steps have a linear execution sequence that can be interrupted by failing constraints. That is, no control structures can be included. In our view, the notion of specialists that explicitly select plans for execution is attractive; DSPL seems to be quite an advanced system for representing control. Plakon Plakon is a kernel for application specific expert systems in planning and configuration tasks [Cuni89] [Cuni91]. Plakon has an inheritance hierarchy to describe components; the representation is framebased. A compositional part-of hierarchy is placed on top of the inheritance hierarchy. Using this hierarchy, product conceptual product structure can be represented and refined to actual product structure; support to step-wise refinement has been built into Plakon. A constraint network can be used both to determine values to attributes of components and to state consistency requirements. Constraints can be propagated to further limit the possible values. A developer controllable dynamic agenda within a blackboard architecture enables dynamic control of the design task. 11

In our view, the Plakon kernel seems to be the most advanced environment for product configuration tasks. Future work should include gaining deeper insight of Plakon.

1.4

Goals

The primary purpose of this thesis was to study the product configuration problem of complex modular products. KONE Elevators has released a series of pre-engineered elevators, namely the NOVEL family. Novel elevators are volume products. Using Novel as an example, feasibility of building elevator product configuration support was to be examined. Practical experiences of using a state of the art product modeling tool were to be acquired.

12

2 About Configuration Knowledge The output of the configuration task is a consistent design of a product assembled from components. The components are connected to each other in appropriate ways. The design is called a configuration. The configuration serves as input to a number of reports, including component order specifications. The specifications tell the component types to the manufacturing unit. The specification of a parametrized product also includes the parameter values for manufacturing the component to a particular order. The thesis is that current tools for product configuration tasks do not support directly some concepts that are inherently present at configuration problems. This leads to artificial formulation of the knowledge. Such artificially formulated knowledge is hard to maintain and visualize. Tools cannot “automatically” do some common checks that systems with better product configuration support could do. These checks are either not represented at all or the amount of “unnecessary” program code grows and further complicates the maintenance of the system and increases the development time. Overall, the clarity of configuration knowledge suffers. It is hoped that the maintenance of component and product information would be improved if the system supported directly some of the most important high level concepts found in actual configuration problems. Also, visualization of products through these concepts should become easier. Some of these high level concepts are identified and described. This discussion is intended as a description and elaboration of some observations made while building a prototype product configuration application. We do not describe complete mechanisms that could be directly implemented. Several open questions still remain. The validity of these ideas has not been verified. this chapter has the following contents. First, differences between fixed and parametrized components are addressed. In this context, some partially new concepts that support representation of configuration knowledge are presented. Many traditional systems used for product configuration offer object oriented features. Some systems also support also constraints. These, together with inheritance, are adopted as the basis for the following discussion. Traditional type-instance approach is assumed but nothing should prevent the use of the ideas in prototype-based approaches. Conceptual product structure is rarely represented in configuration systems. To describe it, concept cell is introduced. The concept requires still more work. Representation of conceptual product structure and its step-wise refinement in a similar way than in Plakon and the SAP configurator[] have given rise to some new ideas. Describing the new ideas is a subject left to future work.

13

One of the leading ideas is concretization of product configurations step by step. Abstract descriptions of products are transformed to more concrete ones during the product configuration process. In one way or another the components of a product must be connected together to form a purposeful whole. Such arrangement of components is described by product architecture. Most components have a well defined interface for component-to-component connections. Component compatibility is a major issue. Little support to represent component interfaces and compatibility is found in the current configuration tools. Ports and Connectors are introduced to describe some of these properties. Finally some alternative approaches and problems of the described approach are addressed. Nothing is said about the to representation of the configuration generation process and the procedures that determine values for parameters, select components, establish component connections etc. This is a subject for further research. Interesting ideas but possibly a bit too straightforward implementation are presented in [Brow85] and [Brow89].

2.1

Components

Primitive components are elementary building blocks of products. Elementary in this context means that the we are not interested in the internal structure of an primitive component although we might know something about it. For example, a complex product like a motor can in some configuration tasks be considered a primitive component. Even an abstract description of a set of similar motors with several models might be considered a primitive component. The choice of primitive components depends on the scope of the configuration task at hand. Primitive components can be connected to form higher level wholes. These can still be considered components. Eventually whole product is constructed from components and could be seen, in a sense, as one high level component. Difference between a product and a component is that of the view. The maker of an elevator may consider a motor a component. The maker of the motor may consider it as a product. Thus, instead of term component or product, a neutral term such as configuration object could be used. Term “component” is used to keep the discussion less abstract and due to the suitable meanings a reader might already have for the term. Often, components form families. A family is a collection of similar but in one or more aspects different entities. All the members of a family can usually be treated in the same way. Members of a family differ in size, capacity, speed, power, etc. properties. Thus, a component family is a collection of similar components which differ from each other in one or more aspects.

14

In the following discussion, attribute can describe any property of an object. Some attributes may have constant values. Other attributes are open and their value must be determined. Open attributes have quite often value classes that determine, possibly in quite a complex way, the values the attribute can have. The possible values can be further limited by constraints. Parameter is an open attribute needed for expressing an aspect of a component. Values of parameters must be determined before the configuration of the object can be considered complete. 2.1.1

Fixed Components

Fixed components are all alike from the viewpoint of their producer. Once the type of a fixed component has been identified, all its properties, attribute values and capabilities are known. Fixed components do not have any parameters. All the manufactured instances of a fixed component are equal. A fixed component does not have to be configured for manufacturing. Fixed components are often available off-the-shelf. For example, most highlevel components used for building modern computers (disk drives, CPUs, displays, extension cards) are fixed. Note that fixed components may have some user configurable options like dip switches of PC extension cards. Still, all fixed components are equal from the viewpoint of manufacturing. Descriptions or representations of fixed components are quite concrete, they can describe exact properties of the components, little or no variation possibilities needs to be described. Only user configurable fixed components may need descriptions of their configurable options. Fixed components can be stored as items in a product catalog or register. Many logistics and production control systems do not know the properties of such items; maybe just a textual description may be added. Each item has a unique item identification number. Some systems may have a capability to add attributes with fixed values A significant portion of the work in literature sees the configuration problem as selecting and connecting suitable fixed components from a component catalog. For example, computer configuration is this kind of a problem. [Mitt89] Components of a fixed component family differ from each other with respect to one or more attributes. For each combination of different attribute values, a separate fixed component is needed. With many varying attributes, each with many possible values, this leads to a combinatorial explosion. This implies the need of parametrized components. 2.1.2

Parametrized Components

Parametrized components have one or more parameters. A parametrized component describes a family of similar components. Members of the family differ from each other in aspects defined by the parameters. Parametrized components allow a single description of a whole range of components, a large family of components can be described by a set 15

of parameters. The number of different combinations may, of course, be arbitrarily large depending on the nature and number of parameters. Descriptions or representations of parametrized components are initially more abstract than those of fixed components. A set of configuration possibilities, for example parameters and their allowable values, must be described. During the configuration process parameter values are resolved and the component description becomes more concrete. The configuration of a parametrized component cannot be considered complete if any parameter values have not been determined; the component description is still too abstract for manufacturing. Eventually, a concrete configuration with assignments to all parameters should be produced. Identity of parametrized components is fundamentally different from traditional items. A parametrized component and its properties cannot be uniquely identified by a component identifier. Also the open parameter values must be known. Many components of some modular products are parametrized by the very nature. Elevators, for example, are built from parametrized components. Parametrized Components Relieve Combinatorial Explosion and Add Product Flexibility The number of parameter value combinations for each component may be quite large or even infinite as some parameters can be real numbers. In many cases, is not practical to try to enumerate all the possible attribute value combinations and to give each of them a unique item identifier for inclusion in a traditional component catalog. Parametrized components add flexibility to products. It is possible to make customized or semi-customized products according to customer requirements. The products can be adapted to different situations in a way that is not possible with fixed components. For example, there are a few dozens main components in an elevator. Each of them has a few or, quite often, dozens of parameters. Each parameter typically has several possible values. The number of fixed components needed for meeting equal level of flexibility would be excessive. Using Parametrized Components Parametrized components must usually be manufactured to an order, because all the possible parameter value combinations cannot be kept in stock. Each configuration determines values for parameters in a suitable way with respect to that configuration. The instances of parametrized components are later manufactured to that particular order. In contrast, fixed components can be ordered or manufactured without specifying any parameters because they do not have any. Of course, parametrized components may, and very often do, have fixed attributes. The fixed attributes are common properties of all the components in the family. Parameters are key information needed by manufacturing to tailor the component to the current situation.

16

Some open parameters may depend on each other. Some of them become determined by the value of other parameters. Some combinations of parameter values may not be allowed. Parameters can be classified to three categories: 1) input parameters are always given directly by the user, 2) output parameters are always calculated on the basis of other parameters and 3) input-output parameters can be calculated or given directly depending on the situation. Selecting Parametrized Components It can be more difficult to search for suitable parametrized components than to search for suitable fixed components. For example, a door with a clear opening width of 1000mm is needed. One cannot search for a door component with 1000mm as the value of its width attribute. Instead, one must search for doors with a width parameter that can be configured to 1000mm. This is complicated further by the fact that some parameter values depend on each other. For example, it is possible that all parameters cannot be configured to their upper bounds simultaneously. In general, parametrized components are more difficult to select and use than fixed components. To see whether a parametrized component is usable in a given situation, one must test if valid values for the parameters can be determined and whether the component can be connected in an appropriate way. Thus, a valid component selection can only be done by trial and error. In practice, components are very often well designed in the sense that if the component meets the main selection criteria, the component will fit. This is an important property of components, which should be considered by component design teams even more. Parametrized Components in the Logistics Chain Parametrized components require a more complex ordering and engineering process than fixed components. Each parametrized component must be configured for each order separately. It is not enough to identify just the model of a component; component parameters must also be determined. This parameter value information must be communicated through the logistics chain to the manufacturing unit. Communicating values of parameter values of parametrized components is a problem for traditional logistics systems. Thus parametrized components require more sophisticated order processing tools than traditional components. As an example, the SAP configurator creates a unique temporary identifier for each component instantiated. The other parts of the SAP R3 logistics system understand quite little about the created configuration. Still, the statuses of configured components can be tracked in the traditional way. The components are handled as “black boxes”. A few main characteristics of a configured component can be assigned by the configurator to an appropriate textual description field [Tiih93].

17

2.2

Constraints

The concept of constraints is well known. Some systems use constraints as the primary form of knowledge representation. This paper does not contribute any new ideas about constraints. The short discussion is intended to remind the reader about constraints and some aspects of constraints encountered in some configuration problems. Often constraints involve only attributes. A constraint expresses a relation between attributes. A particular combination of values for the attributes either satisfies or does not satisfy the constraint. For example: • a + b < 100 • a=b • a = oneOf(A,B,C,D) • 0 30m or • this component may only be used with component X. Thus, constraints state some conditions that must be met. In the configuration domain, constraints represent conditions that cannot be violated; otherwise the configuration would not be valid. In constraint satisfaction systems, constraints are the primary format for knowledge representation. Constraints may be placed on attributes only. Sometimes only equality constraints are allowed. Constraint satisfaction systems try to find such values for the attributes involved that no constraints are violated. For most practical purposes, constraints are an integral part of an environment for manipulating product configurations. However, constraints are by no means the sole means of representing configuration knowledge. The most important purpose of constraints is to enable “automatic” consistency checks or, even better, automatic assignment of values to constrained parameters. The following discussion about component compatibilities, connectability, etc., could be modeled as constraints. However, a more powerful and concrete, although less general, approach is chosen for representing some common classes of constraints encountered in product configuration tasks in a more natural way that can also be visualized more easily.

18

Constraint Posting As the configuration process proceeds, more knowledge of the configuration is acquired. For example, components are selected and their parameter values calculated. Many components have constraints that define how they can be used in terms of restrictions on their parameter values. Also, some component or parameter selections restrict the legal values for some of the component’s own or some other component’s parameters. Components may limit which components are usable with them. As more is known, fever parameter values, value combinations and component selections are legal. There should be a mechanism to support this. One possible way is constraint posting. Constraint posting means that constraints are dynamically injected into the system. As a result, new constraint instances are created. Constraint posting aids in describing the dynamic phenomena. Some constraints may have to be removed if a selection is cancelled or a parameter value changed. Constraint posting seems to be a fundamental feature of configuration process. It may be difficult to model dynamic changes through a static set of constraints. Soft Constraints Some constraints are stricter than others. Constraints may therefore need a strength classification. If all constraints cannot be met, stronger constraints must be satisfied before weaker ones. Weak constraints describe recommendations while strongest constraints represent absolutely required facts. Division to hard and soft constraints may be enough in many cases. Hard constraints can never be violated. Soft constraints can be violated if “absolutely necessary”. Soft constraints are often related to some hard constraints. Thus, soft constraints are one way of describing and finding good solutions. The difficulty of knowing when to violate some soft constraints and, doing so, which ones to break, may make the inclusion of soft constraints to configuration systems impractical. For example, there may be some economical or technical costs or harms associated with violations of soft constraints. Weighing them against each other may be difficult. At least current constraint satisfaction (sub)systems are probably unable to handle such situations correctly. Soft constraints may have to be modeled implicitly through a configuration process that produces only values that fulfill soft constraints. Constraint Fixes It should be possible to attach corrective operations to constraints. It is quite often known what should be done if a constraint is violated. This information is modeled in some systems [Marc92] as constraint fixes. A constraint fix is simply a procedure for modifying 19

the current design in a way that hopefully improves the design in general and removes the constraint violation in particular. Constraint fixes can be seen as a form of knowledge directed backtracking. They are often used with propose and revise methods. The VT system classifies each constraint fix to one of 12 groups. The groups describe how significant effects the fix has on the overall configuration, ranging from “causes no problem” to “compromises system performance”. All less significant fixes and their combinations are tried before more significant ones. Constraint fixes are an useful feature that should be supported by a configuration environment. Value Classes D++ [D++2] supports value classes that restrict legal values of an attribute. They can be seen as constraints on a single attribute. Using value classes the type and allowable value of an attribute can be restricted in quite flexible way. D++ 2.1 supports the following elements for building value classes • data type restrictions (any number, integer, float, string, symbol or list); • membership of a class or membership of any descendant class; • one of enumerated choices; • range of numbers; • any item not in value class; • any item not one of enumerated set; • intersection of two value classes • union of two value classes; • list of items of a value class. Value classes proved to be useful. D++ does not have documented ways of changing value classes dynamically, neither is constraint posting with value classes possible.

2.3

Cell

A cell is an instantiation requirement of a component. Often, there is a group of components one of which must exist in a product. Cells describe which such groups exist. Cells form the conceptual product structure. Conceptual product structure is a description of a product in a more abstract level than the actual components, it describes which components the product conceptually consists of. In other words, there are some conceptual, generalized roles or functions each of which eventually needs a concrete component. Cells describe these. Many components may be viable choices for each such role or function. Conceptual product structure is part of product architecture. The concept cell was first introduced in [Mäkä93]. For example, a hard disk may be needed in a computer. Hard disk is a conceptual entity that is needed in the computer. This is descried by a cell that can accommodate a hard disk, or more precisely, an instance of a hard disk model. As such, the cell is a conceptual repre-

20

sentation of the need of an instance of a hard disk model. The viable choices for the contents of the cell may be all the concrete hard disk models or a suitable subset of those. In routine configuration design problems, such as standard elevators or elevators assembled from standard parts, the conceptual product structure is well known. In a way, cells are generalizations of several actual components. Component base classes in a possible implementation that uses inheritance to describe common properties of components are also generalizations but in a different sense. Cells describe the conceptual product structure. Inheritance of component descriptions cannot describe this, because the existence of a base class does not imply the need to instantiate one of its children to a certain place in the conceptual product structure. 2.3.1

Motivation

Conceptual Product Structure is Usually Well Known The conceptual product structure of a product to be configured is to some degree known before any particular components have been selected to the concrete delivery. The conceptual product structure may extend because selected components may bring in their own conceptual product structure. Thus, the conceptual product structure may extend hierarchically. Still, the conceptual structure can be considered known at some level. This is assumed to be true for configuration problems and is taken as the basis for the following discussion about cells. Assume that the problem is to configure simple personal computers from standard parts. The conceptual structure of the computer might be: a base unit, a keyboard, a display unit and an optional mouse. The base unit’s conceptual structure includes a motherboard, RAM memory, hard disk(s), floppy disk(s), a video card, a disk controller, a case etc. An important part of the configuration task is to select suitable components for each such conceptual role. Cells represent the conceptual structure of products. In the computer example, there might be cells for a base unit, a keyboard, a display unit and a mouse. The base unit’s representation might have cells for the case, motherboard, hard disk(s) etc. It depends on the case whether the base unit’s cell structure should be described in a separate component or as a part of the computer structure. Elevators and Conceptual Product Structure For example, there are some alternative conceptual product structures in the elevator domain. They depend on some major design decisions such as roping ratio and machine room location. However, when the important decisions have been made, there is a fixed conceptual structure to be filled in with suitable components.

21

About the Relationship of Conceptual Product Structure and Functions of the Product Relationship of conceptual product structure and functions of a product may be more or less direct. Some functions correspond directly to one component. Several functions may be implemented by one component. Sometimes one function may require several components. In configuration problems, functions have been mapped to conceptual product structure in the product design stage. There may be a limited set of alternative conceptual product structures corresponding to different required functions or different mappings from functions to conceptual product structure. For practical reasons, the number of alternative conceptual product structures is typically quite small. Step by Step Concretization of Product Structure Component selection refines conceptual product structure to concrete components, that is, cells are filled with components. Concretization of a product structure is a process that creates a concrete description of a product from an abstract one. First, cells describe the conceptual product structure. Component selections to cells make the product more concrete, it is known which components are actually used. Determining parameter values of components makes the description even more concrete. Discussion about the Conceptual Product Structure Should be Possible Cells enable discussion about conceptual product structure. Cells enable manipulation of conceptual product structure even when no components have been selected. Conceptual product structure can be visualized through cells and the configuration environment could “know” and display for which cells components have already been selected and for which the selection must still be done. Hierarchically organized collections of cells are possible. Also, components selected into cells may themselves have cells. Thus, a tree-like conceptual product structure results. Actual components selected into cells represent the concrete product structure or bill of materials (BOM). Surprisingly, configuration systems do not seem to support knowledge about conceptual structure of products. Therefore, the concept of cell is introduced. 2.3.2

Description of Cells

Cells are Named Placeholders for Components A cell is a placeholder for a component in a conceptual product structure. Thus, a cell represents a component selection and instantiation that must be performed during the configuration process. A cell may be filled or empty. An empty cell has no component in it. A filled cell has an instantiated component in it. When a component is instantiated, it is placed as the contents of the cell.

22

Cells are named. Cell contents may be found using the cell name. For example, cell “motherBoard” could indicate that an instance of some mother board class is needed. Once a mother board instance for that cell is created, it is placed as the contents of that cell. Using cell name “motherBoard” one can find which mother board has been selected, if any. Cells Facilitate References to Conceptual Product Structure One can refer to a cell before a component into that cell has been selected. References to empty cells are needed, for example, for representing required component connections or for constraint posting. When creating a description of a product or a non-primitive component, it is usually known which cells have components that should eventually be connected together. Using cell names, such requirements can be placed on the cells before knowing their actual contents. This is discussed further in section "Hanging Connectors— Expressing Compatibility Requirements" on page 31. Filling in a cell with a component may instantiate some new constraints that arise from the properties of the selected components. The constraints may affect the possible contents of one or more cells. These constraints could be attached to appropriate empty cells through constraint posting and be taken into account when filling those cells. These constraints are hanging constraints. After a cell has been filled, hanging constraints are bound to the components and their attributes. Should the component selection change, the binding must be established with the new selection. For this purpose cells may provide a convenient approach — components can be referred to using their cell, not the exact component. Cells Know Their Possible Contents A cell knows with which components it can be filled. For each cell, there is a set of components that can potentially be used to fill it. For example, for a motherboard of a computer only motherboards are potential candidates, one does not have to consider mice or hard disks for the contents of that cell. In practical implementations this could be indicated by restricting the cell contents to appropriate branches of component inheritance hierarchy, as a fixed list of enumerated components or as an arbitrary predicate that could refer to ports (see section 2.4) and fixed attributes of components. A combination of the previous should also be possible. This means that at least in some cases, when no better information is available, the possible components could be instantiated and tried. Or, the user interface could list the candidates for manual selection. Cells may be Active or Inactive Each cell always has activity status. Activity status is one of active, inactive or unknown. Eventually, each active cell must contain an instance of a component. A configuration is incomplete if an active empty cell exists. Thus, active cells determine the effective 23

conceptual product structure. An instantiated component may exist only in an active cell. This is an important feature that traditional systems do not offer. An inactive cell represents a part of conceptual product structure that is not needed in the current situation. Some products may have alternative, mutually exclusive conceptual product structures. The excluded cells are inactive. The whole structure under an inactive cell is considered inactive. In some cases the activity status of a cell may be unknown which indicates that the possible need for a component is not yet known.

2.4

Ports and Connectors —Modeling Component Interfaces

2.4.1

Motivation

Components are Connected to Form a Purposeful Whole Components are included in a product to perform one or a few functions or to offer some resources to be used by other components. Thus, a fundamental feature of products is that their components are connected to form a purposeful whole. Components can be connected in numerous ways. Connections may be physical or logical. Each connection has semantics associated with that particular type of connection. Component Compatibility is a Major Issue Naturally, connected components must be compatible. Compatible, in this context, means that logical or physical characteristics of the components must match in such a way that a valid connection that produces desired results can be established. It is an error if components cannot be connected as required. In parameter instantiation tasks the unspecified structure is a set of parameter values of already selected parts. Structure configuration tasks are a bit more general design tasks in which the unspecified structure is a configuration of parts of pre-determined type and connectors of pre-determined type. Structure synthesis tasks are the most general design tasks where the unspecified structure could potentially be any composition of any parts. The parts do not even have to exist [Tong92]. In our view, structure synthesis tasks are usually too general to qualify as configuration tasks. Component compatibility is a major issue in structure configuration tasks. It practically no issue in parameter instantiation tasks. Current configuration systems can quite well handle parameter instantiation tasks. Many elevator configuration tasks are structure configuration tasks. Some configuration tasks of well pre-engineered elevator models fit, with some exceptions, to the definition of parameter instantiation tasks. Therefore, handling component compatibility was not a 24

major issue in the implemented prototype. However, handling orders that “almost” comply with the pre-defined product models is a major problem, because the task is no longer a pre-engineered one. There is little hope to deal with such situations if the product model and the components used contain only information needed for pre-engineered cases. Therefore, even pre-engineered products benefit from more accurate modeling. Modeling component connections is a major subject in product configuration. It is closely related to compatibility of components. Resource-based Configuration [Hein91] describes a resource-based paradigm for configuring technical systems. Components are modeled as entities that produce and consume resources. Besides resource production and consumption, little else is modeled. There are arbitrarily many resource types. The basic idea is to balance the production and consumption of each resource type so that there is enough production for each resource type to balance consumption. Some resources may be shared and some must be reserved for only one consumer. Each consumer knows its behavior in this respect. Besides a provision for exclusive resources, all resources are considered global. The paradigm is easy to understand and describes some phenomena in a natural way. According to the article, the approach has been successfully used for a number of prototype configuration systems for configuring programmable logic controllers. Maintenance of component knowledge has proved to be easy because only simple component descriptions are needed. After first prototypes, the basic paradigm has been extended to handle local resource balancing. Handling hierarchically structured complex components has proved to be difficult and future work is directed towards solving the problem. In our view, resource-based paradigm seems to be useful. However, treating resources as global seems to cause some problems. Therefore, a mechanism that allows directing the resources would be more useful. If conveniently possible, a product configuration system should support the basic idea of resource-based paradigm. Scope of Component Information Component information can be divided into two groups based on its scope. Private information is internal to the component, it is not needed outside the component itself. Interface information is information that should be visible outside the component. Interface information could further be classified to public and protected information. Public information is globally visible. Protected information is visible to the component itself and its components. Note that his definition of protected information is different from that in C++. The scope of protected information in C++ is determined by inheritance, the scope of protected defined here is determined by product structure. In the following discussion, existence of protected information is ignored to simplify things. 25

Interface information may be needed in component selection or by other components. Interface information may also be used for adapting other components to be usable with the component. Information dealing with connection interfaces is naturally interface information. Note that one of the underlying assumptions is that component information can to some extend be treated as data. For example, searching for potentially suitable components from existing ones using component interface information should be possible. Summary of Motivation Current configuration shells known to the author do not offer direct support for modeling • component connections, • compatibilities between components, • resource-based configuration (except those mentioned in [Hein91]) and • interface information distinguishable from private information. Many listed properties must be modeled as general constraints, if the system offers any, as executable program code or as attribute values of components. Rule based systems may represent the information as production rules. The interface, connection and compatibility information as well as resource production and consumption become hidden in the program code. Little “automatic” compatibility checking is possible. Visualization is difficult. Domain experts that are not software professionals cannot verify the correctness of the knowledge due to the obscured representation format. Better support for modeling component interface features directly is needed. The following discussion describes one approach to modeling component connections, resource production and consumption, component compatibilities and, to some degree, other component interface information. Hopefully quite a remarkable portion of component interface knowledge could be modeled by concepts “Port” and “Connector”. 2.4.2

Overview of Ports and Connectors

Ports describe interface properties of components. A connector can connect two or more ports. Ports and connectors are typed objects. The semantics of each port and connector depends on its type. Components include ports to describe their interface properties. Only components can contain ports. The host component or host of a port is the component that contains the port. Thus, a port describes some interface features of its host. Component connections are represented with connectors between their ports. Components connect to other components only through their ports and the mediating connectors. No ports can be directly connected without a connector.

26

A connector type can be used to connect only some port types. The type and number of ports connected by a connector depends on the type of the connector. For each connector type the number and type of ports connected is fixed. Most practical connectors probably connect only two ports. There may be many connector types that can connect to a port type. A component may have several ports, even many ports of a type are allowed. A component may participate in many connections simultaneously. The simultaneous connections may take place through one or more ports, depending on the number of ports and how many components can be connected by the ports. Direct references to attributes of other components should be replaced by ports and connectors whenever possible to maintain a “clean” interface. Port and connector definitions would probably form an inheritance hierarchy. The concept of ports has been briefly introduced in [Mitt89] from which the term been taken. Mittal’s discussion does not include connectors as separate objects. All the details and other semantics are author’s. See Figure 2, "Ports and a Connector" on page 27 for an example of a simple binary connection with two ports and a connector.

A Component Connection A

B

An instance of port type 1 in component A An instance of port type 2 in component B An instance of a connector that can connect port types 1 and 2

Figure 2: Ports and a Connector

27

Fundamental Properties of Ports and Connectors As mentioned, ports and connectors are typed objects. Port type definitions can introduce port attributes and port constraints. Connector attributes and connector constraints are declared in connector type definitions. Connectors know with which port types they may be connected. Connectors may access attributes of the ports to which they are connected. It is safe to access port attributes because the type of the port is known. Of course, a connector instance knows the ports to which it is connected. It is possible to put hanging connectors on cells. Hanging connectors represent requirements to establish connections during the configuration process. A connection point of a connector expresses the type of a port that can be connected. Connection point has a reference to the actual connected port, if any. Also, a reference to the cell containing the component with the port is maintained. There is exactly one connection point for each port to which the connector can connect. All connection points of a connector do not have to be alike. This enables an instance of a connector to connect to different port types simultaneously. Port instances know which connector instances are attached to them. A port instance knows how many connectors may be simultaneously connected to it. The legal number of connections is called the arity of the port. The number of connected connectors must be between the legal minimum and maximum values. Some ports may have constraints on the type of connectors that may be connected to them. This way ports can expect some properties from the connected connectors. This enables using mechanisms for retrieving attribute values from connectors and setting constraints on connector attributes. By default, ports do not care which types of connectors may be connected to them. Whether knowledge about allowed connector types should be implemented using the general constraint mechanism or whether a more direct mechanism that completely prevents even temporarily attaching illegal connector types should be used is a minor subject for further research. Ports are tuples of . The representation assumes that possible compatible connector requirements are represented as constraints. If this is not the case, an extra entity might be needed in the tuple. Connectors are tuples of . An extra activity flag may be needed to facilitate hanging connectors. Hanging connectors will be described later. Connection points are tuples of . 2.4.3

Ports and Connectors—Some Details

Visibility of Ports and Connectors

28

Ports are visible to the rest of the system, including other components and all procedures. Thus, ports are a mechanism for representing public information. Connectors might be visible to other components only through the ports that they are connected to. Connectors must be visible to some procedures. Each port type and each connector type has its associated semantics. The semantics is not “understood” by the system. A port can be seen by the host component containing the port like record variables in traditional programming languages. A component declares that it includes a port and names it. The port’s “record” becomes included. Attributes of a port are accessible to the host component in the familiar “portname.attibute” notation. It might be a good idea to isolate ports so that they cannot access their host components directly. Such isolation prevents other components from seeing the internal structure of the component through the interface. Thus, some encapsulation is forced. On the other hand, some flexibility may be lost. Application Specific Ports and Connectors A configuration environment could pre-define some common port and connector types. It is, however, impossible to define “all” port types and to know their semantics in advance. Application specific port types are inevitable and even desirable. The set of port types and connector types can be extended during application development. In practice, many port and connector types are defined together to achieve desired results. Definition of port and connector types should be done very carefully. The created port and connector types should be general enough but still easy to use. Creating port and connector types “ad hoc” may result in a system where no ports and connectors are reusable. Port and Connector Attributes Both port and connector type definitions may, and usually do, declare attributes. Attributes describe some properties of the port or connector in greater detail than just the type. As a reminder, attributes were discussed in section 2.1 on page 14. Possible values of open attributes tell something about the configurability of the port. Possible values are often described using value classes and constraints. When open attributes are concretized to actual attribute values, these values describe with which parameters the port or connector has been configured. Note that the attributes of a port do not usually model the properties of an established connection. These are typically modeled by connectors.

29

For example, a component producing power could calculate its maximum output and place the value to an attribute of the output port. Connector attributes might describe, for example, a physical interface dimension selected or flowing electrical current. As an example of a port with several attributes, consider a port describing a power plug. It might have values for the maximum allowable power, voltage, interface dimension of the plug etc. Connector and Remote Port Access Mechanism A port may access properties of attached connectors if it knows their type. Thus the attribute names can be known. The other ports to which a port is connected to through connector(s) are remote ports. A general mechanism for accessing attributes of remote ports through connectors should be provided. This, of course, also requires knowledge of the type of the remote port. Also, a mechanism for getting the identity of the host component of a remote port could be useful for many purposes. Access mechanisms for connectors and remote port attributes through a connector can eliminate many direct component-to-component references. The port and connector mechanism reduces direct references also through eliminating references that are needed to find other component’s properties for determining their compatibility and connection parameters. It is hoped that this improves maintainability of the knowledge. Ports and Connector Constraints Port constraints can access attributes of the port. If a port knows the type of attachable connectors, the constraints may also access their attributes. Therefore, a port is able to express requirements for the connections. Some port constraints may be used to limit the type of ports that can be attached to them. This provides the knowledge for connector types needed for other constraints. Because these constraints are special in this respect, it may be necessary to treat them in a special way. An alternative to special treatment is to add to port representation knowledge of allowed connector type or types. Connector constraints may specify, for example, which values some port attributes may have so that the connection can succeed. A typical constraint might state that attribute A of the port at connection point P1 and attribute B of the port at connection point P2 have same values. Connector constraints may refer only to attributes of the ports that they connect to and to own attributes of the connector. Port Arity A port may be exclusive or shared. Only one connector may be attached to an exclusive port. Several connectors may be attached to a shared port. For example, a component

30

producing electricity can have several connected devices. A hole for a screw can accommodate only one screw. An obligatory port requires at least one attached connector to the port. An optional port allows one or more connectors but does not require any. For example, assume that a component must be mounted through a mechanical fixing. The component includes an obligatory port. If there is no connector attached to the port, it is known that the component has not been mounted. Arity combines and generalizes connectability requirements of a port. Arity describes the legal number of connectors as minimum and maximum number of attached connectors. Maximum can be infinite which means unlimited number of connectors. Minimum can be zero which means that no connectors are required. Legal arity can be changed dynamically at run-time. The following table describes possible arities as combination of minimum and maximum arity. 0 ≤ Μ ≤ Ν ≤ +∞. Min

Max

Interpretation

0

1

Optional, exclusive. 0 or 1 connectors allowed.

0

N

Optional, shared. 0..N connectors allowed.

1

1

Obligatory, exclusive. Exactly 1 connector required.

1

N

Obligatory, shared. 1 .. N connectors required.

M

N

Obligatory, shared. M..N connectors required. Table 1: Interpretation of Port Arities

Port definition may state the possible arity. Host component of a port may restrict the arity further. Hanging Connectors—Expressing Compatibility Requirements Connectors can be inserted in a conceptual product structure. This creates a hanging connector. This happens normally during product model development. Hanging connectors express requirements for connectability. Attaching a connector between empty cells means that the components that are selected to the cells must be compatible. The components are compatible if the hanging connector can be placed on ports of the actual components that are eventually selected. For example, a hanging instance of connectorE is placed between cells Cell5 and Cell3. Instances b and d of component types B and D are selected as the contents of Cell3 and Cell5, respectively. It is an error if connectorE cannot been established between the ports of b and d. The error indicates that instances b and d are not connectable in the required way. They are incompatible with respect to the required connection.

31

It should be possible to attach several alternative connectors between cells. Alternatives allow several connector types each of which can handle one kind of a connection. If the selected components cannot be connected by any of the possible connectors, they are considered incompatible and the configuration is in error. Representation of hanging alternative connectors requires at least an activity flag to the each alternative connector so that the other connectors that are not currently used can be ignored. Allowing alternative connectors makes using simple connectors easier. One of the alterative simple types can be used. A connector type should probably model only one class of physical connection types. Thus, there is no arbitrary need to represent all the possible connection types using only one connector type. This would lead to very complex connection types that would probably be unusable. An example of a simple mechanical connection type is nut and bolt join. Using complex connections that could model “all mechanical connections” would probably cause a connector type that is very awkward to use. Connectors and Ports as Specialized Constraints Connectors and ports can be seen as specialized constraints. They constrain the valid connections of components. Connection requirements are common in actual components. These constraints are naturally described by port arity. Ports and connectors are active. Thus the system “automatically” knows that the configuration is not complete if a port with no or too few connectors are found in some components. The same applies to hanging connectors. If a hanging connector with an empty connection point is found, the configuration is incomplete. If ports with too few connections are found, the system may find from its “connector dictionary” the connector types that could be attached to the empty port simply by comparing the port types. The system or more probably the user of the system would select the suitable one. The other ends of the found connector types could then be matched against ports of instantiated components in order to find suitable other ends for the connector. However, connectors should in most practical applications be placed hanging on cells so that neither unguided search for components with suitable ports nor run-time connector instantiation takes place. If port polymorphism is allowed, port type comparison is a bit more complicated. Port polymorphism in this context means that subtypes of a port may be used instead of the more general type. Suitably formulated combinations of ports and connectors can model consumption and production of resources and their balancing. Compared to ideas of [Hein91], the resources modeled through ports and connectors do not have to be global. Consumers can, and actu-

32

ally must, be directed to certain producers trough connector instances. Ports and connectors can be used as resource production and consumption constraints. Some Properties of a System With Described Concepts A configuration tool that supports ports, connectors, cells and constraints can represent, among others • The conceptual product structure described by cells in a natural way. • Using active cells, the system knows if some components have not been selected. • A set of possible components can be proposed for selection because cells know their possible contents. • Component compatibility requirements can be described by hanging connectors. • Component interfaces, component compatibility and connection requirements can be represented and checked with ports • Violated constraints can be noticed without writing any extra program code for actually performing the checks No current system supports concepts of ports, connectors and cells. They have not been implemented in any system known to the author. There is still some open questions that must be solved. 2.4.4

Examples

Examples of Using Ports If a component has an external connection capability, the component includes a port that describes that type of capability. The component defines the actual attribute values of the port from the possibilities of the port. The component may also constrain the possibilities further in order to let the procedure that determines actual connection attributes to establish suitable values for the connector and the port. If the component requires that it must be connected trough a port, it just declares that the port is obligatory, that is, sets a suitable arity. If a port produces a resource, a port describing that kind of resource production is included. The component probably calculates the maximum producible amount and assigns that to an attribute of the port. The arity of the port is assigned appropriately. The port probably has a constraint that makes sure that the producible amount is not exceeded. If a port consumes a resource it includes a port that describes the consumption of that resource. The amount of consumption is calculated to an attribute of the port. A connection through that port is made obligatory to guarantee that appropriate amount of the resource is really delivered to the component. The port type might include a constraints for suitable connector and its attribute values.

33

If a port has a certain other interface properties, it can express them by including an appropriate port that describes that property. A common interface property is compatibility with some components. See Example: Representing Component Compatibility on page 34. Resource consumption and production is further discussed in Example: Representing Resource Production and Consumption on page 34. Example: Representing Component Compatibility Among the most common dependencies between components is that component X declares that it must be used with component Y or with one of a limited set of components. For example, a component states that it is usable only with Gatto hoisting machinery. To represent basic component compatibility, each component should always have an instance of predefined “type” port. Port “type” would have an attribute, say, “myComponentCompatibilities” that lists symbols that describe component compatibilities of that component. Items of the lists are component identifiers. The port is declared as optional shared (0..∞) so that no attached connectors are required. Including the port effectively publishes the compatibilities of the component. Components that want to be used only with certain component types include a “requiresComponent” port. The “requiresComponent” port is declared as obligatory and its attribute “compatibleComponents” contains the component identifiers that are allowable components with that component. A connector “typeRequirement” can join a “type” port and a “requiresComponent” port. Its connector constraint states that the intersection of type port’s myComponentIDList and requiresComponent port’s compatibleComponents is not empty. The system can detect if the compatibility requirement is not met. Assume that a new component that is compatible with the old one is introduced. It can list the identifiers of old component type in MyComponentCompatibilities list of its the type port. No changes in the code of the depending components are needed because the interface remains the same. The port and connector model adds a level of indirection into the system and helps the maintenance burden. See Figure 3, "Representing Compatibility with some Components" on page 35. It is difficult to give good examples because we do not want say anything about how to represent procedures or methods for actually determining attribute values and how to control the flow of the configuration process. The syntax was developed for the example and there is no commitment to it. Example: Representing Resource Production and Consumption A power source and a power consuming device must be connected. There are three types of electrical power connectors, ISO1, PLUG2 and DIN3.

34

// Gatto and MR12 are symbols. //The example assumes that there is no need to declare symbols PORT type myComponentCompatibilities: listOf(symbol) end PORT PORT requiresComponent suitableComponents: listOf(symbol) endPort CONNECTOR TypeCompatibility JOINS p1:type; p2:requiresComponent; CONSTRAINT compatibilityCheck: not(null(intersection(p1.myComponentCompatibilities, p2.suitableComponents))); END COMPONENT Gatto ... PORTS type(minArity=0, maxArity=maxint, myComponentCompatibilities=list(GATTO, MR12)); ... END COMPONENT requiresGatto ... PORTS requiresComponent(minArity=1, MaxArity=1, suitableComponents=list(GATTO)); END

Figure 3: Representing Compatibility with some Components A power source has 4 physical output electricity outlets. Any number of them may be occupied. Any power outlet type may be selected, but all the outlets must be of the same type. The total power may be at most 2800W. The previous description indicates an optional shared port with arity of 0..4. The port has a constraint on the total connected power, no more than what is producible by the power source may be consumed. The constraint is attached to appropriate attribute of the producer so that the actual value can be changed if it happens to depend on the actual configuration. A smallMotor, a power consumer requires 500W power. This indicates an exclusive obligatory port. The requirement to get enough power is expressed by a port constraint stating that the maximum power that can flow through the connector is equal to the consumers’s maximum power input. The PowerConnector combines a power producer and a power consumer port. The connector requires that the physical connectors at both ends of the connection are of the same type. The power transmitted through the connection is irrelevant to the connection itself, but a suitable value might be assigned through the equivalency constraint at the consumer. This requires that constrain propagation would be supported. 35

An example code is represented in Figure 4, "Representing Resource Production and Consumption" on page 36. Some problems are illustrated by this example. They are discussed further in section 2.4.6. Note that the syntax is invented just for the example. There is no commitment to this actual syntax. enum PowerConnectorType={ISO1, Plug2, DIN3} PORT PowerSourcePlug maxPower : 0..pinf; type : powerConnectorType; CONSTRAIN maxPowerConstraint: connectorType(PowerConnection)and sum(getConnectionAttributes(power)) 2895 mm. ‘-’ if none, otherwise length in mm. WALLPANEL-HEIGHT = ROOM-AVAILABLE-FOR-DOOR - HEIGHT - 240. Knowledge derived from SO information.

WALL-TO-SLAMP-POSTDISTANCE: (UNION INTEGER (ONE.OF -))

Must be given when ordering, if = nr-ropes-now ropes-min) (