PARAMETRIC MODEL ASSEMBLING
Martin Th. van Hees
Delft University of Technolo2-,
Ship Hydromechanics Laboratory
Library
Mekelweg 2, 2628 CD Delft The Netherlands Phone: +31 15 27868-'3 - Fax: +31 15 27818.EXPERT GOVERINEu
0QUAESTOR:
EXPERT GOVERNED PARAMETRIC
MODEL ASSEMBLING
S tell ingen
behorende hij het proefschrifi
'QUAESTOR:
EXPERT GOVERNED PARAMETRIC MODEL ASSEMBLING
Delft. 10 februari 1997
teruggebracht tot het verzarnelen en onderhouden van modelfragmenten en hunt eigenschappen. Het samenvoegen tot modellen, traditioneel een programmeeractiviten. kao op eflectieve wijze worden gegeneraliseerd, watoloor men zich kan concentreren op kwaliteit
en geldigheid van de modelfragmenten (dit proelschrifr)z We hese!' ikkenover meerIbmikbare kennis dan we \veto'.
3 De grote uitdaging voor de kennistechnologie is °in optimaal gebruik It maken van de sterke
Izzinten van mens en machine. Door de mens Met al leen als gebruiker tc beschouwen maw ook als uiterst hmikbaar onderdeel van een kennissysteem kunnen krachtige en flexibele
oplossingen worden gerealiseerd.
.4. De eerste grate spraakverwarring is ontstaan tijdens de bouw van' de Toreg van Babylon., de tweede is ontstaan na de komst van de computer.
5 I leu ontwikkelen van kennissystemen lijkt op het restaureren van klassieke automobielen: het gain langzaam. her vraagt precisie en werkelijk goede onderdelen zijii vaak mocilijk Ice
vinden.
Als je de enige bent die een hepaald probleent tot ten oplossing hein gebrachi, zijir er drie mogelijkheden: a) het probleem is zeer ingew ikkeld, b) de kosten-baten verhouding van een
oplossing is te ongunstig, ol c) er is geen probleern.
Her verzlient aanbeveling om opnieuw cell filmktunng in te voeren die oils gaat lbeschermeo
tegen de gruweljoumalistiek van de televisiejoumaals.
Dc Nederlandse overheid ziet een helangrijke 'won van belastinginkomsten over het hoofd; op
nicuwe computers kan behalve BTW ook nog accijns worden geheven overecnkomstig met die op alcoholische drank, met als valide argument de vergelijkbare verslavende invloed die
er vanuit yaw.
'9. De term ouderschapsverlof is verkeerd omdat deze suggercert dat je in dat geval op kantoor
bent terwijI anderen voor je kinderen zorgen.
10 Ecn ztanzienlijke reductie van het wagenpark en van: !het file prohleern kan worden bcreikt
QUAESTOR:
EXPERT GOVERNED PARAMETRIC
MODEL ASSEMBLING
PROEFSCHRIFT
ter verkrijging van de graad van doctor aan de Technische Universiteit Delft,
op gezag van de Rector Magnificus Prof. dr. ir. J. BIaauwendraad in het openbaar te verdedigen ten overstaan van een commissie
door het College van Dekanen aangewezen. op maandag 10 februari 1997 te 1130 uur
door
Martin Theodoor VAN HEES
scheepsbouwkundig ingenieur geboren te Den Haag
Prof. ir..I. Klein Woud, Faculteit der Werktuigbouwkunde en Maritierne Techniek, Technische Universiteit Delft
Prof. dr. H. Koppelaar, Faculteit der Technische Wislcunde en Informatica,
Technische Universiteit Delft
Samenstelling promotiecommissie: Rector Magnificus, voorzitter Prof. ir. J. Klein Woud Prof. dr. H. Koppelaar Prof. ir. A. Aalbers Prof. dr. J.M. Akkermans Prof. dr. ir. F.W. Jansen Prof. dr. P. Sen
Dr. ir. R.A. Vingerhoeds
Technische Universiteit Delft, promotor Technische Universiteit Delft, promotor
Technische Universiteit Delft Universiteit Twente
Technische Universiteit Delft University of Newcastle (UK) Technische Universiteit Delft
ISBN: 90-75757-04-2
Aan mijn ouders4.,
Sylvia,
The Concise Oxford Dictionary, 0 Oxford University Press 1964, 1976
QUAESTOR, title of a magistrate of ancient Rome. The earliest quaestors had juridical powers, hut as the finances of Rome increased in complexity, two quaestors were appointed by the consuls (highest chief magistrates) to control the public treasury. After 447 BC the quaestors were elected annually by the legislative body known as comitia tributa. In 421 BC the office was opened to the plebs (common people) and the number of quaestors was raised to four. As the Roman Republic gained control of Italy and more provinces were acquired. additional quaestors were elected as financial assistants to the military commanders and provincial governors. Under Julius Caesar in the first century BC, there were 40 quaestors. The Emperor Augustus later reduced the number to 20. the usual number for the duration of the Roman Empire. 'Quaestor', Microsoft Encarta, 1993 Microsoft Corp., 1993 Funk & Wagnall's Corp.
CONTENTS
PREFACE INTRODUCTION 3 Sc NOTATION CONVENTIONS . . .5 2., AN ADVENTUROUS VOYAGE,.".;45;: .
..771.
itinerary .72.2. Destination and Departure .110
2.3. Navigation
...
.152.4. Cross-roads and Choices... .16
2.5. Arrival? .22
NUMERICAL DESIGN MODELLING., 3.1. Modelling: Why and What?
3.2. Focus of Representation
3.3. Representation Schemes
. ...
283.4. Modelling: Applied Languages and Tools 37
15. What is Available? 43
36. The Missing Link: Model Assembling 45
DESIGN PROBLEM SOLVING IN NAVAL ARCHITECTURE 47
4.1. Design Practice: Reasoning and Modelling 47
4.2. Numerical Conceptual Design: The Concept Exploration Model . 51
43. Beyond Concept Exploration Models 52
KNOWLEDGE & KNOWLEDGE ACQUISITION ., . .55
5.1. Knowledge Used in Parametric Modelling
... ... ....
555.2. (Deriving) RELATIONs and CONSTRAINTs
...
5.3. TELITAB: A Generic Parametric Data Format . . .61
QUAESTOR: AN INTRODUCTION . .
61.
The System . . .u ' 69.
6.2. User Interface .. .Y 9.4Y,
77762
6.3. Tasks and Competence 6.4. Expert Questions
6.5. A Simple Application Example ...._ IPe ern . .81
6.6. The Concept Variation Model .. . 86
6.7. CVM Development Aspects .90 25 25 27 58 69
PARAMETRIC MODELS: THE PARTS 93
7.1. Domain Description and Data Model 93
7.2. Control Knowledge 96
7.3. Syntactic Elements and Aspects 103
PARAMETRIC MODELS: THE ASSEMBLING 113
8.1. Development strategy 113 8.2. Inferences 115 8.3. Solver Strategies 128 IMPLEMENTATION ASPECTS 133 9.1. Data Management 133 9.2. Interpreter 138 9.3. Recursion 143 9.4. Performance Issues 144 QUAESTOR APPLICATIONS 147 10.1. SUBCEM 147
10.2. The TROIKA Mine Sweeper 150
1 I. DISCUSSION AND CONCLUSIONS 155
11.I. Focus and Perspective 155
1 1 .2. Conclusions 160
APPENDIX A:
Glossary of Terms 161
APPENDIX B:
On Merging Numerical and Functional Design Knowledge 169
Bibliography 177 List of Figures 183 List of Frames List of Tables Summary 186 Samenvatting 188 Acknowledgement 190 Curriculum Vitae 192
... ...
....
...
...
... . . . .. ... ...
.... ,...
. ......,
. .184 .185PREFACE
The work presented in this thesis started from the observation that in conceptual design of ships many alternative solutions have to be considered. For this purpose, vital and time consuming sub-tasks performed are the knowledge acquisition, i.e. gathering and structuring the relevant knowledge and the numerical modelling of conceptual design aspects. My primary target was to gain understanding of the
nature of numerical design knowledge and of the design modelling task and to develop a general purpose approach and tool, named QUAESTOR.
The basic idea was simple enough, but making these ideas work and fulfil a need has been the primary challenge and drive for this work. This thesis attempts to summarise and formalise what has been done and to present the main aspects and ideas that evolved during this development.
QUAESTOR is a knowledge-based system that assists the designer with knowledge and experience management, numerical (design) modelling and computations and is applied in the domain of conceptual ship design.
INTRODUCTION
The primary aim of this work is to support ship designers in the early phase of design by improving access to and control over design related knowledge. Access to and control over numerical and non-numerical design knowledge are considered premises for successful and efficient design modelling activities. The results of this work apply to other engineering fields as well. Real world cases are selected
from conceptual naval ship design to illustrate the problem domain. The key problem addressed is model assembling, i.e. to collect and arrange numerical
model fragments into decision support and analysis models. The conceptual basis and technical details of the knowledge-based system QUAESTOR are presented. QUAESTOR performs the task of numerical model assembling not autonomously but
in co-operation with the designer. The guiding principles
are that design
(modelling) is a learning process and that the role of a designer is to makedecisions [Mistree. 1990] and that the modern approach towards design is based
on systems thinking and using computers as partners in the design process [MacCallurn, 1985 and Smith, 1992].
The impact of automated modelling on design in general is addressed, focusing on the assembling problem in depth. It is the author's opinion that computer assisted assembling of numerical problem representations is one of the key issues in any attempt to advance this type of design as a professional activity. The research for
this thesis is performed bottom-up. It is observed that the application of the
knowledge-based approach of this thesis has large impact on the way designers apply and manage their knowledge during the design process.
In chapter 2 the problem of ship design is described in some detail. As an
introduction to the subject, a brief historical overview is provided guiding the reader along some important steps taken and choices made during the development of QUAESTOR. The development strategy is briefly discussed. Finally, in which way is the ship design process affected by the application of this tool?
Chapter 3 places my tool within a wider scope of tools and approaches in naval architectural and engineering design; which representation schemes are and can be used in numerical design modelling, which tools and languages are available for that purpose and which are actually used in reality? Various literature sources on design modelling, originating from engineering sciences and computer science are used to position the modelling strategy that has been developed. We arrive at the viewpoint which is the central issue of this thesis: solving a generic numerical design modelling problem.
In chapter 4 the process of reasoning in conceptual design
is addressed.Traditional tools for conceptual design are discussed. A
knowledge-basednumerical modelling strategy is introduced and compared with the traditional design modelling practice as described in this chapter, both in terms of application and model development.
Chapter 5 presents the primary forms of knowledge, their coherence, structure and acquisition. A generic numerical data format is introduced.
Chapter 6 provides an introduction to QUAESTOR. Theglobal system architecture and the primary system components are presented. An example is given in the form of a highly simplified conceptual ship design model. Finally, the knowledge-based design model or Concept Variation Model is introduced.
Chapter 7 introduces the numerical parametric domain. The structure and
properties of the model fragments are discussed and the
extracted controlknowledge is described. Finally, some syntactic and semantic aspects of the
instruction set are discussed. Simple examples are used to support the elucidation. Chapter 8 presents an in-depth description of the model assembling process and the (numerical) strategies involved in executing the assembled models. Some attention is paid to the development strategy of this process.
Chapter 9 addresses general implementation aspects and some particular ones of the primary system functions.
In chapter 10, my contribution to ship design and analysis is elucidated by two real world applications in naval ship design.
In chapter 11 the model assembling technique is reviewed in terms of limitations and focus for further research and development. An extension of the application domain is proposed by introducing functional design aspects which is discussed in more depth in Appendix B. Other discussed aspects are user friendliness and user
competence and the notion of input driven modelling. Finally, I present the
principal conclusions and insights that were obtained in this work.
In Appendix A. a glossary is provided of the most frequently used terms and
1.
NOTATION CONVENTIONS
Once a word has been allowed to escape, it cannot be recalled,
Horace, Epistles
In case a generally known concept is used in this thesis, its common name is
applied in the text, for example 'parameter' is a concept with a well defined and generally accepted meaning. In such cases normal print without capitals is used.
Throughout this thesis the terms 'relation' and 'constraint' are used to indicate different concepts in the literature review, design theory and in the developed
knowledge-based technique and are used in normal print in case the meaning is related to the subject of the paragraph. The notation RELATION and CONSTRAINT is used (Times Roman small capital letters) if referred to the named concept in the
developed software. Another example of a named concept is REFERENCE,
indicating the name of the slot containing information in text format in a
knowledge base. Terms beginning with capital letterrefer to named components of the developed technique, e.g. 'Modeller' to indicate the reasoning mechanism of the program.
The applied font is Times New Roman. In all cases where values, expressions, parameters, data types, syntactic elements and control attributes are indicated, the
Courier New font is applied, often in a slightly adapted character size. Values
can be numerical, e.g. 0 . 3 54, the Boolean TRUE or FALSE and for expressions DETERMINEDorPENDING.
Although this work primarily deals with numerical expressions, only very few of them are found in the text. The only purpose of these few and often extremely
simple examples is to elucidate the mechanisms and inferences involved in
numerical modelling, i.e. to show the steps in the modelling process. Therefore, a list of symbols is not considered appropriate, the parameters used in the examples are described locally in context.
AN ADVENTUROUS' VOYAGE
What is a greater challenge: to accomplish a journey around the worldor to build ashipfarthat purpose?
Andre Citroen
What does a technical person do if frequently confronted with similar problems? This chapter tells the story of a class of problems, its identification, the desire for additional tools, the steps towards a solution and finally of the tool which is obtained. The problem is parametric modelling in naval architecture and the steps are the development of a tool for this purpose: a knowledge-based system. Finally, in which way is the design process affected by the application of this tool?
2.1.
Itinerary
In 1983, after finishing a degree in Naval Architecture at the Delft University of Technology, I started my career at a shipyard design office. My first assignment was the conceptual design of a 1200 ton naval submarine. After this project I have been involved in variety of ships and conceptual designs. An important lesson learned in this period is that experience is important, but even more important is having good access to the accumulated knowledge of the yard and supporting
knowledge infrastructure. The availability and accessibility of this knowledge at the shipyard was rather limited, not least due to the fact that the most experienced senior designer retired two months after my arrival. Another lesson was that the variety of problems to be solved in such an environment is tremendous. A bright
spot, however, was the fact that similarities seemed to exist between these
problems and the approach to solve them.
Departing from practical, experience with software development for solving (in particular) numerical problems I started to use the similarities between the various problems. I came up with the idea that a method or a tool could enable me the use
of an intelligent 'book shelf', in other words: put knowledge in the form of
procedures and data on the shelf and make the shelf answer any question which is
embedded in this collection of knowledge. Inquiries at that time about the
existence of such tools did not reveal any name of a software system supporting, this task in a way meaningful to naval architecture.
In 1986 I became project manager in the Ship Powering Department of the
Maritime Research Institute Netherlands (MARIN). Important aspects of this work 2.
were industrial consultancy and the interpretation of results of model experiments.
It appeared to me that the accessibility and availability of knowledge in this
environment and the flexibility of its application for every-day problems are of similar importance. The approach towards problem solving which had taken shape in my mind at the yard seemed to be fully applicable to an important proportion of the knowledge domain dealt with at MARIN.
An important part of my work as naval architect consists of the formulation, gathering and application of design knowledge, either in the form of numerical methods or as non-formal heuristic rules. Since computers are well capable to perform calculations I concentrated on the numerical aspects of design. The design problems referred to in the sequel are therefore mainly computational problems.In the process of numerical design problem solving a number of steps can be distin-guished:
defining the problem
collecting data related to the problem
choice of the rules (e.g. numerical expressions) and facts which describe the problem area
checking the applicability and validity of these rules
assembling a numerical model computing/iterating towards results checking the realism of the results obtained
Although the computer considerably facilitates the application of numerical expressions and methods in the design process, still considerable effort is involved to incorporate them into computer programs and in the maintenance of these programs.
In comparison with other technical disciplines, empirical calculation methods are
often used in naval architecture. In spite of the significant progress in several
areas, the large number of sub-areas of high physical complexity remains a
characteristic of naval architecture. This forces the use of simplified parametric representations, particularly in the early design phase. Another characteristic is the availability
of such knowledge in
literature and company records. The conventional approach to make these methods available for practical application is either to use paper and a calculator or to write a dedicated computer program forIn this conventional approach, some fundamental problems continue to exist: Most computer programs are 'black boxes', not supporting or stimulating the understanding of the user ('input' is provided, 'output' is obtained). The experience of the designer does not affect the results obtained.
The 'knowledge' of the problem domain is integrated in the program. Programming
experience isrequired to modify any partofthe knowledge in the program and in the wayit is
appliedin the program.
In most cases a limited number of calculation methods is available in the form of a computer program. These programs are developed to perform certain tasks in a fixed sequence with
fixed input and output. If input is not available in the proper format hardly any means are
availableto either convert the input into the correct format or to derive the missing input in an
automated way. Additional calculations, either manual or by computer are often necessary.
These aspects are considered as disadvantages of the conventional approach which
basically means computer programs solving one particular problem for one
particular set of input. These programs contain knowledge which may be used to solve other problems in a similar context or which are even instances of (parts) of other computer programs. My aim is to facilitate the application of numerical and related knowledge in a design and engineering environment. In such environments many different design and analysis problems are attacked by using the same set of numerical models and model fragments.
To illustrate the disadvantage of the conventional approach imagine a computer program predicting the required propulsive power at a given ship speed. If the effect of hull form coefficients or dimensions on the installed power are to be explored in the conceptual design phase, the program has to be used several times with varying input. Parameter variations requiring some input related to other design aspects that imply further (manual) calculations are common practice in design. This is hardly attractive in case these various aspects cannot be evaluated in a concurrent way.
Another example is the design of the propeller. The prediction program determines the optimum pitch and diameter of the propeller whereas one might wish to know the propulsive performance achieved with a given propeller (i.e. with fixed pitch and diameter). The latter cannot be obtained since input and output, as well as the algorithm of the prediction program are fixed. The program implicitly contains all knowledge required to solve that problem but the fixed input and output does not allow it.
Concluding: a drastic improvement of the flexibility of the numerical modelling of design problems was desired. The question was whether or not the following could be achieved:
To capture design rules separate from a problem based algorithmic context, together with background knowledge and pragmatic rules about their application. Can these rules and knowledge become explicitly available for solving computational problems?
2.2.
Destination and Departure
The problem definition is to develop a computer program enabling a designer to efficiently use several different calculation methods in varying sequences and with varying starting points. This program should support a highly flexible use of these methods. After an initial study of literature and/or company records, users (e.g.
naval architects) should be able to store the calculation method (i.e.
the knowledge) in a kind of database for immediate use. The system should make itpossible to solve any problem fitting in these knowledge components. The
following section provides a summary of the problem as formulated in 1987 at the start of this thesis work.
My experience in the field of ship design and consultancy and the use of
computers for this purpose made clear that up to 1987 not much progress had been
made in 'computerising' conceptual ship design. Conceptual design was an activity based on experience and intuition in which a variety of tools were
sequentially applied.
I learned that a designer employs in the conceptual phase of design:
Literature data Handbooks
Company records (such as previous designs)
Experience
Numerical methods
In 1987, the application of computers in the early design phase was restricted to analysing properties of the design and to drawing. Nowadays, integrated systems are available in the domain of ship design in which a large number of analysis and prediction tools are integrated and are using a common data base [Andrews, 1992]. However, CAD systems are still hardly used in the conceptualphase of the design;
Destination and Departure simply because they require a design to make analyses and predictions. This
implies that major decisions about e.g. main particulars must be taken beforehand. Nowadays, CAD tools are emerging which can be used in these earlier phases of
design. An example is the L/GRAND system, developed on the basis of an
associative geometric modelling system [Laansma, 19951. Although these systems potentially improve the productivity of a designer, they provide limited support in finding and validating main particulars using knowledge of the ship's life cycle.. The main particulars and/or clear and unambiguous design constraints are assumed, to be known at the start.
The engineering or detailed design phase is a substantial cost factor in the
realisation of a maritime structure. This is the primary reason for the existence of
large and advanced engineering packages that deal with modelling, materials
management and production. In view of the achieved gain of time, these systems are considered to be essential means of production, similar to welding and flame. cutting equipment.
Until 1987 only few computerised methods have been proposed for the conceptual phase of the design and this situation has not changed much after that. A pragmatic reason is that the conceptual design forms only a negligible proportion of the total costs and effort involved in the realisation of the maritime object. For a typical
naval ship building program, e.g. a series of two frigates, the approximate
expenditure is 1% in conceptual design phase, 5% in engineering design and 94% in construction. The percentages only apply to platform design and construction, weapon systems are not included in these figures. So, from a merely economical point of view major investments in instruments that facilitate this design phase are hard to defend. However, the major reason for this lack of conceptual design tools.
is their high complexity, due to the fact that procedures and the sequence of
decisions in conceptual design are not fixed at all. An important motivation for developing such tools is their contribution to design quality. In the early phase
major design decisions are taken that finally affect the building costs and the
operational and economical value of the object [Meek, 1992]. These decisions often have to be taken on the basis of limited knowledge of the solution space. It is generally recognised that in the early design phase 80 percent of the realisation cost are fixed whereas in the detailed design only about 20 percent is affected (the '80/20 rule [Gutierrez-Fraile,
1993]). The importance of design
in earlyIn Figure 2.1 two cost lines are drawn for typical high cost shipbuilding projects. The line representing the actual expenditure shows that in a project most of the money is spent in later phases where actual building activities occur. The other cost line represents the cost fixed by design decisions. The third line represents the level of design knowledge which purpose is to show that the designer is forced to
take design decisions (Influence on ship cost line) before he has the required
knowledge. An effective design model should be able to improve on this situation. 100%
Time
Figure 2.1: Cost and knowledge as a function of time
Summarising, effects of decisions taken in an early design phase often are becoming clear in a later design phase (see I Meek, 19921 for a number of
examples). In most cases, it is then difficult or even impossible to introduce major changes in the concept. Using the computer as a real 'partner' in the conceptual design of arbitrary ship types is still hardly possible although various 'partnership' approaches have been pursued by researchers since the late seventies, [MacCallum, 1985-1990, Mistree, 1988, Brown, 1989, Bremdal, 1985]. Existing computerised solutions for concept design were developed for particular vessel types such as bulk carriers or dry cargo ships [Georgescu,1989].
In the traditional approach towards design one tends to select the first alternative fulfilling the requirements. Design optimisation is mostly restricted to specific details and is not performed for the concept as a whole.
The efficiency and quality of the output of the design process can be improved in different ways. In the first place we can improve the tools for the job. Above, we
Destination and Departure
have stated that the accessibility of available design knowledge in different forms
is of great importance to designers. In the second place, we can analyse the
taxonomy of the design process and the applied forms of knowledge and extract
the logic and mechanisms behind the reasoning process. These mechanisms
implemented in computer software can be applied for design decision support.
Creativity plays a major role in conceptual design and is hardly supported by existing software. Developments should focus on tools which support and
stimulate this typical human capability. It is carefully concluded that, in view of the apparently limited number of standard methods and techniques (implemented
in computer software), design in this phase is an 'art', being according to the
Oxford Dictionary: Skill, especially human skill as opposed to nature. Apart from this somewhat early conclusion, the observations supported the idea that at least one important design sub-task, being the use of numerical formulations, may be facilitated in case it is approached from a more 'systems thinking' point of view.
An artefact is considered to be a system that can be described through a number of attribute/value combinations, viz. quantities (dimensions, masses) and qualities (colour, material). On the other hand, in many cases qualities can be expressed as numbers which can be stored and used as quantities.
In this simplified world all systems can be described through parameters. Between
these describing parameters relationships exist which may be expressed in a
numerical form. These expressions can be logical, compelling ('hard' or based on physics) or empirical ('soft') and can be written as equality or inequality. In the simplest case an unknown parameter in an expression being an equality can be
solved in case the other parameters in the expression are known and if the
expression is assumed to be valid. To determine whether expressions (equalities and inequalities) are TRUE or FALSE can be done in case all parameters in the expression have known (DETERMINED) values.
In the design of complex systems many of such relationships are involved:
empirical, physical and spatial ones, as well as (legal) regulations, constraints and
requirements. Requirements and constraints can often be represented in a numerical form, either by equalities or inequalities. To improve the overall picture of the design process it is attractive to obtain an inventory of design parameters and the relationships between them. For instance from technical literature and previous designs a storehouse of such information can be retrieved. In this thesis numerical expressions are referred to as 'RELATION'. Each RELATION should be stored together with a reference in which the origin (author. which regulatory
body, when issued, etc.) is provided, its formulation expressed in parameters from the inventory and some attributes (hard/soft), values and dimensions of the applied parameters, etc.
It is essential to know whether a RELATION, i.e. numerical model (fragment) is applicable for the current case. Therefore, it should be possible to attach to any
RELATION (equality) one or more relationships, being either equalities or inequalities which express the 'applicability' or 'validity' of the RELATION(s) to
which is referred. In the sequel these relationships expressing the validity of RELATIONs are referred to as CONSTRAINTs.
The term CONSTRAINT is preferred although it is in conflict with the meaning of the word in some literature sources [Leler, 1988, Guesgen, 199211. A CONSTRAINT is viewed as a limitation on the validity of the producer of the value of parameters (i.e. the RELATION). A CONSTRAINT is eitherTRUE or FALSE and DETERMINEDor
PENDING. A constraint with the meaning validity' is sometimes referred to as
second order constraint [Leer, 1988].
Without additional means it is impossible for a designer to have a clear overview of all available numerical relationships. Theoretically speaking it is possible to incorporate all these RELATIONS into a single computer program. However, this computer program will be large, complicated and expensive to develop, manage and maintain. It is not difficult to imagine the advantages of having these RELATIONS immediately available for use. If values or estimates of all computable, yet unknown design parameters can be obtained on any moment during the design, decision support is considerably improved.
To enable this availability of (design) relations and parameters an information system is desired. The following sections provide a summary of some important choices, decisions and findings in the course of building a system called QUAESTOR which enables storage, maintenance and application of design knowledge in the indicated ways.
Navigation
2.3.
Navigation
QUAESTOR was designed in two main components. The first component is the knowledge Editor containing all facilities dealing with storage, maintenance and retrieval of relevant design knowledge. The second component is the numerical Modeller, containing the numerical and 'intelligent' components of the program, i.e. which also is able to work with knowledge retrieval facilities. The Modeller requires functionality from the Editor meaning that in terms of development, a large overlap exists between the two main functions of the system, in particular by virtue of a common interface.
These two desired system functions were clear from the beginning and remained
unaltered. The challenge was to build a system for which no examples were available. By developing components which were definitely required and by
obtaining detailed insight in their properties and interactions, the outline of the
final system became clear in the course of time. The limits of four successive
generations of PC's have been an important stimulus to remain on track, since it limited the attraction of taking cross-roads to goals not leading to the final one: a system which can support the numerical design modelling task.
A typical engineering approach is to start with a description of a system on
functional and conceptual level (what should the system be able to do and what will it look like?). Subsequently decompose the system in components, develop the
components and assemble them into a working system. Finally the system's performance should be tested. The approach is basically top-down: a general
solution
is found and components are specified that help meet the overall
expectations (a bottom-up approach to problem solving is to decompose the
problem and find solutions at a detailed level [Hagen, 1993]). Prototyping as a means to gain insight in the problem domain, solutions and the behaviour of users is a widely recognised developmental strategy, particularly for early development stages. It is also suitable for more advanced development stages although it then is
difficult to manage. Case studies are performed to extract knowledge about
behaviour and competence of users and of software. User feedback obtained from numerous prototypes (in fact intermediate versions) has been the primary driver for the development since the first working prototype [Brouwer, 1990]. Concluding, the development approach of QUAESTOR is defined as Top-down Prototyping.
2.4.
Cross-roads and 'Choices!
QuAEsTOR has been developed between early 1987 and 1996. The first three years
were spent with exploring the knowledge domain, developing a suitable data structure and data management system. In this period also initial versions of
important system functions such as screen managers, formula parser, interpreter
and solver were built. Since departure in
1987 a record was kept of most
development aspects and decisions made. By consulting this project dossier a
selection has been made of key decisions and ditto aspects which had large impact on the final result.
Knowledge domain
The basic assumption is that numerical relationships (referred to as RELATIONS) can be used to fix the connection between quantities (referred to as parameters) which describe the system or design at hand. RELATIoNs can be used to compute values of parameters on the basis of values of other parameters. RELATIONs can be active in a solution in case its validity is checked and found true. The (numerical) validity is expressed by zero or more CONSTRAINT(s). These RELATIONS, parameters and CONSTRAINTs are considered to form a network. RELATIONs are
assumed to be continuous functions if they are used Two Way, i.e. as equation. Discontinuous RELATIONs can mainly be used One Way, i.e. as function or Two Way within a particular interval, fixed by CONSTRAINTS.
Multi Case
in the domain of engineering and design it is important to compare alternative solutions. This means that the system should be able to generate output of multiple cases on the basis of one or more varying input parameter(s). These Cases are not necessarily computed from the same system of equations since that can change due to RELATIONS becoming invalid. This decision greatly affected the design of the workbase (storage of problem related data), of the Modeller (which performs the actual reasoning) and of the numerical data model. This decision has complicated the development considerably but it has been found to be one of the key features of the program. It was rapidly decided to apply only double precision numbers and
no reals or integers. Although initially various types were considered, this distinction appeared to be a complicating factor and of limited practical value. The single generic data structure (TELITAB) is applied throughout the program (see section 5.3).
Cross-roads and Choices
Ill. Language and hardware
In 1987 my experience in computer languages was confined to ALGOL60,
FORTRAN77 and BASIC. ALGOL60 was outdated, FORTRAN77 is a language
for mainly computational purposes and offers limited flexibility in string manipulation. Being familiar with GW-BASIC from the early days of personal computing, the decision to apply one of the at that time new, structured BASIC's
was easily made (Borland Turbo BASIC). The powerful and above all simple string manipulation of BASIC made it very suitable for my purpose. One of its important features is the ability to use strings as dynamic arrays which can be
extended and reduced without reallocation (see section 9.1). The drawback, however, was that in the early nineties the support of BASIC by the software
industry seemed to evaporate. An attempt to perform an automatic BASIC to C translation failed because of the excessive use of string operations and recursion which was clearly beyond the limits of the equivalent operations programmed in C as provided in the object library of the translator. BASIC has made a come-back in Microsoft's Visual Basic (MVB) which is increasingly applied by the software
industry. A conversion from Turbo Basic to MVB has been successfully
performed. This removed important limits with regard to memory use and code size. Obviously, the applied hardware is the PC under MS-DOS. This choice, mainly imposed by availability has forced developments towards optimisation of speed and code size.
IV. Interface design
At the time of departure, character-oriented user interfaces were state-of-the-art. A non-windows solution has been developed, consisting of a screen for database management, a number of lists for parameters and expressions and a cell-oriented workbase manager which presents the problem related input and output. The basic concept of the interface has not changed since 1989. Imposed by code and memory limits, the same interface components are used for database maintenance, browsing and the dialogue. The key issues in the development of the interface have been:
to present or make all knowledge accessible which is relevant at a particular moment
(white-box approach)
to provide extensive browser functions, also during a dialogue to enable maximum ability to interfere during a dialogue
Database design
An important starting point for the development was the desire to integrate
knowledge management with its application. Initially it was attempted to store the
knowledge in sequential, ASCII-type tables according to a simple relational database concept. Any attempt to perform reasoning activities with such database
concepts failed, simply because they were too slow to be practical. It finally
became clear that the network-type knowledge could only be used efficiently in
the case where it is stored in a database organised as a network. The database
finally became a set of free format interconnected binary records enabling high
performance queries. This database system was the key element required for
building an inference engine (Modeller) that performs reasoning tasks within acceptable response times.
Apart from performance aspects, hardware
limits in terms of available free
memory have also been driving factors during the development of the database system. In view of these limits and the desire to manage and use large networks, both network database and computed results were moved to the disk. The disk is used as virtual memory thus trading memory against speed.
Parser and knowledge quality control
To avoid errors and inconsistencies in the knowledge base a parser and syntax checker have been developed. The parser separates the expression in string format into a sequence of numbers, parameters, operators and functions and maintains the pointers between the new expression and parameters in the knowledge base vice versa and introduces new parameters in the knowledge base, if necessary. The syntax checker is able to detect the most obvious errors in numerical expressions
such as number of parentheses and their nesting. Also, the combination and
sequence of numerical and relational operators and the availability of numerical data to which is referred by special functions (section 7.3) are checked. Since QUAESTOR deals with numerical expressions there is a serious risk on redundant information, dependency between RELATIONS which may lead to singularities in the matrix representing (a part) of the assembled model. Upon entering a new RELATION, the user interface presents all RELATIONS which can be used to produce
the same value(s) as the newly provided
(or modified) one, allowing theknowledge engineer to check for possible redundant data. In addition to this. the Solver is capable to report dependent RELATIONS in a template to the user which then can take appropriate measures to remove the redundant information from the knowledge base.
Cross-roads and Choices
Interpreter
For the purpose of executing numerical models two possibilities are available. The
first one is to translate the RELATIONs and CONSTRAINTS selected from the knowledge base into conventional computer code (e.g. FORTRAN)
and to
compile and subsequently link this code with a multipurpose solver. This approach
has been applied by [Bras, 1992, Smith, 1992 and Vingerhoeds, 19901 The
drawback of this approach is that it is extremely difficult to properly code the
applicable constraints and control knowledge: the symbolic level (i.e. the modelling process) is in this case completely separated from the numerical level
(be.the numerical solver). This means that during execution of a model no access is provided to the Modeller and a user interface isnot available for the purpose of reporting problems or for adaptation of models on the basis of intermediate results. The latter requires that control and execution of the actual calculations should be performed by a solver, controlled by the Modeller through interpretation instead of
batch compilation and execution. The interpreter should be able to evaluate clauses of numerical expressions (RELATIONS and CONSTRAINTS)and is invoked by the Solver which controls the overall solution process. Another advantage of the interpreter-approach is that special functions (e.g. table interpolation or selection)
can be implemented (and used) relatively easy which is not the case if code
generation is applied. The interpreter which forms part of the QUAESTOR shell code
has full access to data stored in the knowledge base or produced by satellite
applications. In section 9.2 the interpreter is discussed in more detail. Modeller
The reasoning mechanism or Modeller is the 'intelligent' part of the program and is able to check validity, propose RELATIONS, ask input (values of parameters), compute (solve set of equations by invoking the Solver) andpresent results. Basic decisions on the functionality of the system are embedded in the architecture of the Modeller. The system should operate as assistant in the assembling of models (white-box approach). This is preferred above searching solutions for problems without user interference (black-box approach). However, it should be possible to operate in both modes. This approach ensures maximum flexibility and a relatively simple domain description will suffice. Specific,more 'human' knowledge which is difficult to capture in a knowledge base, is explicitly supplied by the user or implicitly through his decisions. This necessarily means that the user may have an important influence on the assembling process. This simplification in terms of knowledge domain is more or less outweighed by the increased complexity of responding properly on input or stimuli provided by 'unpredictable' humans. It
appeared to be difficult to avoid failures and to pinpoint weaknesses in the code of the Modeller. The user may perform actions or provide input under a variety of
inevitably untested conditions. Many of such weaknesses became clear in applications of users not being the developer since the latter bypasses many
obstacles without even realising it. An important milestone was the development
of functions which can determine dependencies between parameters in an assembled numerical model or template. The application of these functions
simplified and improved the efficiency of recalculation for other input and of multi-case calculations.
In section 8.2 the inferences performed by the Modeller are presented.
Solver
The Solver is a routine which computes a solution of the non-linear model or
template generated by the Modeller. Although a separate routine, the Solver is developed parallel with the Modeller. Important aspects of the Solver are speed and robustness. Since use is made of an interpreter which is slow if compared to compiled code, the efficiency of the iteration process has obtained much attention. The nucleus of the Solver is a relatively simple (quasi) Newton Raphson (NR) method [Hinton]. The solver computes a Jacobean around intermediate sulutions which is solved by Gaussian elimination until a particular accuracy is obtained (see section 8.3 for a discussion of the criteria for convergence). The Modeller provides systems of equations (RELATioNs) extracted from the assembled template to the Solver. An important step was the introduction of symbolic substitution or term rewriting [Leler, 1988], reducing the number of degrees of freedom of the problem by substitution. The Solver is also able to recognise strong components [Serrano, 19921. A strong component is a sub-system of equations or a cycle that exist in the template and which can be solved independently of the rest of the template. These cycles are split off from the template and solved separately as
sub-systems of equations. This makes the size of the template virtually unlimited. The strategies applied by the solver are discussed in more detail in section 8.3.
Interface to satellite application programs
In the course of the development of QUAESTOR it became clear that by storing analysis methods only in the form of RELATIONS and CONSTRAINTs, knowledge
bases become large and difficult to use
and maintain. Another obvious disadvantage of that approach is the effort involved in the transformation ofCross-roads and Choices
subsequently in testing their integrity and problem solving qualities. In addition, methods may become 'white boxes' in undesirable cases. To confront a designer during a dialogue with highly complex regression polynomials or neural networks
may not improve
his understanding of the problem domain.Instead of
transforming the method into RELATIONS, analysis programs are used directly. The input of the analysis program is defined in the knowledge base as a FORTRAN type function call. On the basis of this call the interpreter prepares the input file,runs the application and retrieves the requested parameter value from the
program's output. The function call is a common QUAESTOR function which
produces a single number as result. In this way satellite applications can be used as common RELATIONs which also means that potentially input and output can be reversed. i.e. by providing (multiple) result(s) QUAESTORcan compute value(s) of missing (PENDING) input variable(s).
By a consistent application of the generic TELITAB data structure (see section 5.3) in the input and output of these satellites, the interfacing can be realised without much effort. This principle appeared to be the key towards design models which unite a high degree of complexity with good maintainability. Another advantage is that by interfacing with a well defined and simple file structure the development effort and responsibility can be distributed and no particular computer language is prescribed. It also limits the development effort since existing analysisprograms can be used without significant adaptations. The generic data exchange files of the applications can also be used as a standard in conventional environments and is adopted by MARIN as standard exchange format between user interfaces and calculation programs.
Xl. Accuracy management
Although the concepts of expected and acceptable accuracy are important to any designer 'MacCallum, 19901 they are in practice often difficult to quantify, simply because this kind of knowledge is generally not (made) available. Due to this I have deliberately neglected this subject in QUAESTOR. Inmy view the results of any modelling activity should be judged by the designer
on the basis of his
professionalism and experience. It is the professionalism of the designer and not the degree of sophistication of the software that ensures the quality of the design and of the design model. Insight in the robustness of the solutions can also be obtained by performing sensitivity analyses with the uncertain parameters in the model.
2.5.
Arrival?
In 1992 a prototype of QUAESTOR became available with acceptable performance and sufficiently robust to be applied for pilot applications. The first and thus far most ambitious application is developed within the scope of the SUBCEM project [vdNat, 1993-1996]. Early 1993 QUAESTOR was introduced at the Royal Netherlands Navy (RN1N). The concept design of the TROIKA mine sweeping system was the first RN1N application [Wolff, 1994] and is discussed in section 10.2. Nowadays many QUAESTOR applications in naval ship design exist and the embedded approach is adopted as the spine of the Future Reduced Cost Combatant (FRCC) study performed by the RN1N within the scope of the NATO Maritime Operations 2015 project [Keizer, 1994-1996 and vHees, 19941. The feedback obtained from these applications has been extensive. Literally hundreds of smaller and larger problems have been reported and solved and a large number of system functions have been developed on the basis of suggestions of designers using the system. For a developer it is quite exceptional that users are prepared to accept
flaws in a software system they apply in their daily practice. More common reaction in such cases is irritation and refusal to use it any further. Although
numerous improvements were incorporated in the basis of these pilot applications, the basic concepts of the system and of the underlying approach have not changed
since the introduction of the first prototype in 1990.
Within a relatively short period of time the tool has been adopted by the RN1N for a variety of design applications. A logical question is why, what does it add to
already available tools? A senior designer' at the RNIN gives the following
explanation:
For the RN1N, a primary application of this system is its 'interfacing'-ability. Analysis programs and methods dealing with particular aspects and properties of the design require input which is retrieved from the current description of the design. These analysis models originate from various specialised sources. Prediction tools for e.g. ship hydrodynamics are provided by MARLN, for signatures and operational aspects by the Physics Electronics Laboratory TNO/FEL and of vulnerability aspect by the Prince Maurits Laboratory TNO/PML. We are able to retrieve and organise this input since we are managing all information about the current status of the design and of the relations that exist between design parameters. These relations can vary from case to case. QUAESTOR
provides storage and maintenance facilities for the concept description and the relations
I) IL R. Zuiddam, Ministry of Defence, Royal Netherlands Navy, Directorate of Materiel,
!existing between design parameters. The shell assists by gathering and converting the user input into input required by the applicable analysis models by interpreting the relations or by retrieval of input from a database. While using analysis programs in design we often desire (slightly) different output and/or are we capable to provide (slightly) different input.
Due to its capabilities QUAESTOR acts as interface 'between our input and these programs
vice versa and thus allows us to use these analysis models and link them together in the
way we desire. The application, input and output varies from case to case and depends on the context of the problem. Parameter variations and problem (input/output) reversal, i.e.
What-If questions are very important in design.
These applications are beyond my initial aims of El987 (section 2.2) which were mainly method management and applications on a detailed level and hardly on the level of overall 'conceptual design lvHees, 1994
The rule-based properties and the subsequent improvements and extensions have made it suitable for integrating large numbers of analysis tasks into systems for conceptual design. In the chapters 6 and le these conceptual design models and
their development aspects are discussed.
Thus far the development of QUAESTORdemonstrated that:
the problem of automated parametric model assembling is more complex than is expected on the basis of the simple domain description
Cal a dialogue system is difficult to test, often fuzzy error reports are received
lel a time consuming test/refinement cycle can hardly he avoided.
close co-operation with a small group of motivated users is a prerequisite 'improvement remains possible
3.
NUMERICAL DESIGN MODELLING
Prove allthings; hold fast that which is good.
KJV 1 Thessalonians, 5:21
In technical disciplines that deal with large and complex systems, a design by simulation-approach is often followed with an emphasis on quantitative forms of knowledge. Simulation is toimitate conditions of (situation, etc.) with a model fir convenience or training. In case systems, subjected to financial or physical
limitations, need to be optimised for particular tasks, a parametric approach is often
followed. The obvious advantage of parametric representations is that the merits of multiple solutions can he studied without a need for building physical prototypes. These models can provide decision support to a designer in an efficient and cost effective manner and help him to gain understanding of the domain. In case the artefact is highly complex, the initial numerical model may be a simple one and can be made increasingly accurate in the course of the design process. The modelling then becomes a learning process. The following sections provide a frame of reference in terms of applicable knowledge representation schemes, tools and
techniques in numerical design modelling and their relation with QUAESTOR. Finally
we arrive at the viewpoint which is the central issue of this thesis: solving a generic
numerical modelassemblingproblem.
AL Modelling: Why and What?
Simulation is applied in those cases in which it is difficult to study the reality. Examples are the simulation of the dynamic positioning of a tanker during loading crude oil from a storage tanker or the manoeuvrability of ships in a future harbour.
Knowledge of the behaviour and operational
limits of these systems, e.g.
maximum wind speed and wave height at which an operation can be performed limit accident risks. Simulation saves also cost involved in possible modifications to be introduced in the object after completion.
The basis for simulation is a model of the reality. This model can be a physical model but it can also be a numerical model, being a simplified description of a system to assist calculations and predictions. A model in it simplest form is an equation describing e.g. the relation between the power transmission through a shaft, the rate of revolutions and the torque. This relation is given in the form:
This 'numerical model' makes it possible to calculate the torque in a propeller
shaft, required for computing e.g. the shaft diameter on the basis of an allowed maximum torsion stress. To enable this calculation it is required to provide input
to the model: the Rotation_Rate and the current Power setting. The units of the values need to correspond, i.e. the Torque should be defined in kNm, the
Power in kW and the rotation rate in l/s.
In engineering disciplines the numerical modelling of physical systems and
simulations with such models have become kernel activities. In order to establish
capacities, weight, stiffness, dimensions and cost, assumptions are made with regard to boundary conditions, properties of the components, materials and
environments. In many cases some form of numerical modelling is performed to justify particular choices and decisions.
Physical systems and processes are modelled in different ways, depending on the required level of detail and on the aspects on which is focused. Systems interact
with the environments in which they operate, systems may be the carrier of
processes. What is being modelled, the system in terms of pipes, beams, pumps or is it the process or 'program' which is running on the system? These processes can be static or dynamic and probabilistic aspects may be involved. Modelling may be
performed for various reasons, ranging from determining the feasibility of a particular artefact in terms of cost, mass, dimensions, etc. to checking the performance in a varying environment as for the above storage tanker. Such
simulations provide indirect input to the design of the system.
By nature, physical systems are dynamic or static which is reflected by the applied
numerical model. Subsequently, numerical models are either deterministic or
probabilistic. A deterministic description requires absolute values of positions,
power, motions, either static or in time, whereas a probabilistic description is provided in terms of statistical parameters, e.g. the probability that certain limits are exceeded within a given time frame. In this work only deterministic views on
systems and processes are addressed. From a pure numerical modelling perspective, the position is taken that time can be treated as any other variable so that static and dynamic numerical models can be dealt with in a similar manner. In section 7.3 the basic principle is elucidated with a simple mathematical pendulum.
In the phase in which a concept of a future physical system is established, it is both common and useful to apply an abstract representation of the concept and of the knowledge involved. According to [Newell, 1982] representation is the sum of knowledge and access to that knowledge. Representations vary per knowledge
Focus of Representation
domain. In general the more abstract a system or process description is, the easier it should be to manipulate it, viz, to modify, to extend or to reduce a description. For example, a block diagram of an hydraulic system is easier to adapt than its detailed engineering layout drawing. Depending on the phase of a design, usually
a level of abstraction is intuitively selected in harmony with the available
knowledge and with the desired ability to manipulate the model in that phase of the design.
3.2. Focus of Representation
From research in Artificial Intelligence originate three basic approaches in reasoning about physical systems [Top, 1993]. The three approaches emerged from research to formalise human common-sense reasoning processes and are
considered as levels in which physical systems are being abstracted and
manipulated in engineering sciences. In this thesis, the position is taken that these three levels are passed in the course of a design process.
IL Device-centred
According to this view the behaviour of a physical device can be inferred from 'its, structure. Here, three types of structural elements are distinguished, viz, materials,, components and conduits (that transport material, energy or information between components). Device components are connected via relations. Given a configuration of device 'elements, the behaviour of the system as a whole can be determined. This approach requires a device-level description which, in terms of design, is the output of the process. An example is the product model of a Diesel engine in a CAD system,.
Process-centred
The process-centred approach takes as primitives physical processes that induce
state changes in the system. Important notions in this theory are views and
processes. Views provide a (static) description of physical objects and their states, by specifying to which objects the view applies, under what conditions it is active, and by giving relations between the parameters that are valid in that situation. Processes are described in a similar manner, but in addition they contain so-called influences which indicate what causes parameter values to change, thus specifying
the dynamic aspects of a
system. This approach requires a process-level description. In terms of the design, a process is an intermediate level whichrunning. The process-level behaviour is used to infer (parts of) the device level description. In the case of the Diesel engine we will use a description, or rather
simulation of the combustion process to infer, e.g. bore and stroke, cooling
requirements and turbo charger arrangement.
III. Constraint-centred
This approach takes a mathematical rather than a physical stance, since it directly starts from the system (differential) equations, and then yields the corresponding possible system states by employing a numerical solver. In this solver, the quantity space for search of a solution could be bounded. Dynamic behaviour is captured
by applying differential schemes. This approach requires a constraint-level
description. In design, we consider the constraint-level description as the most suitable form in the conceptual phase. In that phase we have the least device-level knowledge of the artefact and the constraints are used to find entries in the process and device levels. Case-based reasoning, is a common strategy in this level. Based on generalised (device-level) knowledge of Diesel engines, main particulars are estimated of an engine which should operate within given limits of e.g. power, revs, weight and fuel consumption.
In design we are interested in quantities which means that in the above three
approaches the relations and constraints are numeric by nature. In particular the
process and constraint-level descriptions can be merged into a numeric-level
description which is covered by my knowledge-based approach.
The device, process and constraint level descriptions are applied by engineers to manipulate concepts. The manipulation of the artefact description (later I will apply the term Concept Description) is the key to performing What-If inquiries: what are the consequences of this solution for the overall system performance? The creative opportunities enclosed in such abstractions are invaluable.
Summarising, in the realisation of an artefact, the representation is selected which expresses the aspects which are the focus of manipulation. In practice this means also that different tools are selected for different design phases.
3.3.
Representation Schemes
In the sequel a summary is provided of knowledge representations which are either commonly applied or suitable for conceptual purposes in engineering sciences and which have or can be given numerical properties.
I. Formulae, constraints and equations
A prmula ('mathematic rule or statement in algebraic symbols') is a numerical representation of one parameter into others.
Thrust = Resistance! (1 - Thrust_Deduction)
Thrust can be computed (i.e. the formula can be used) in case Resistance
and Thrust Deductionare known.
The given formula can be considered as a constraint (limitation imposed on
motion or action'), i.e. a limitation on the value of the applied parameters. In other
words, the above (equality) constraint is fulfilled in case Thrust equals
Resistance/ (1 - Thrust_Deduction). In that case the Boolean value of the '=' operator isTRUE.
The expression can also be viewed as an equation ((Math) Formula affirming
equivalence of two expressions connected by the sign =' ) which can be solved. In case Thrust_Deduction and Thrust are known Resistance can be
solved.
Numerical representation in formulae is attractive in view of its expressiveness.
Many attributes of physical systems can be assigned numerical values, even
qualitative attributes can be expressed in numbers, e.g. a colour or component number referring to particular lists of colours and components. Apart from the numerical knowledge it represents, formulae provide the means to propagate
cause and effect through a model and even to reason about the structure of the system from which the parameters in the formulae are attributes. An example is to
evaluate the effect of re-sizing a particular system component on the overall
system performance (such as speed, cost, motions, power, etc.). A DETERMINED
value of a particular attribute may serve as trigger for decisions, the same applies
for not having a value,
i.e. the value being PENDING. Variables in designconstraints (with either PENDING or DETERMINED values) can connect concepts
with each other. Simple formulae may already contain or express much more
knowledge about design concepts and their coherence than the simple calculate value:... task. This numerical form of knowledge plays an important role in the understanding and manipulation of design concepts.
People involved in engineering clearly perform some kind of reasoning with
numerical expressions, simply because more knowledge is captured in, or related to expressions than the purely procedural number processing aspect. Apart from a Representation Schemes
simple value and the ability to calculate values, parameters and the expressions in which they are applied can capture knowledge about the behaviour and structure of physical systems. Through expressions, parameters connect concepts and are
used in engineering to jump from one concept to another.
In design it is common to apply the term 'constraint' for RELATION. A constraint is viewed as a limitation of the values of a set of design parameters, imposed in the form of an expression The constraint is satisfied in case a set of parameter values is found fulfilling the relational and/or logical operators in the expression. Within the context of QUAESTOR I prefer the term RELATION since it relates parameters to each other. Whether or not the RELATION is applied or active depends on the problem at hand. A RELATION should be considered as a stand-alone procedure linking one parameter with a value or one or more other parameters. Activating i.e. introducing the RELATION into the template requires decisions and/or other forms of knowledge. An active RELATION (viz, selected for solving a particular problem) can be considered as a constraint in the above, usual meaning.
'Production miles
Apart from being a constraint or part of a system of equations, an active RELATION is also a Production Rule: the value of one particular parameter is produced by 'firing' this RELATION, either explicitly by assigning the value of the right clause to the parameter in the left clause, or implicitly by solving the system of equations in which it is included. The production rule paradigm is a model for human reasoning and captures an expert's experience and causal reasoning strategy. A large number of domains exist in which knowledge can be captured in this way and it forms the basis of the first generation of expert systems [vdRee, 1994]. Production rules consist of an antecedent part which includes the conditions to be fulfilled prior to execution and a consequent part stating the actions to be performed:
IF conditioni s) THEN' action (1:51
The advantage of production rules is the simplicity, the resemblance to human reasoning and the fact that rules can be added or removed without much effort.
The result of the action ( s ) is called Conclusion. If condition ( s ) are
viewed as validity, formulae, equations and constraints can be considered as
Numerical Production Rules from which the value of one of the parameters is, the conclusion. This notion forms the basis of QUAESTOR.
In QUAESTOR, a RELATION is a simple mathematical expression in the form
Representation Schemes
A CONSTRAINT is an expression which may include the relational operators <, >, = and the logical operatorsAND, OR, XOR, EQVand IMP. CONSTRAINTscan either be
TRUE or FALSE, and DETERMINED or PENDING. CONSTRAINTS are the
condi t ion(s) in the numerical production rules represented in the knowledge'
base by the following implicitIF. . THEN. . ELSEIF . ENDIFclause:
IF (Condition I = TRUE) THEN RELATION A can be used
ELSE IF (Condition II = TRUE) THEN RELATION B can be used
END IF
I I 0: Semantic nets
Semantic nets describe a domain by means of a graphic structure consisting of nodes or objects which are interconnected by arrows or relationships. Semantic nets
are developed to capture knowledge as an hierarchical
structure. Arelationship can be for instance an Is_a 'relationship. Two forms of knowledge are captured in this way:
To fix that a class of objects is a sub-class of another class of objects, e.g.:
A ship is a
floating structureTo fix That an object belongs to a particular class of objects,
TheQE II
is a ship
Properties of objects that are higher in the hierarchy are transferred to objects lower in the hierarchy, i.e. objects inheritproperties of their super classes (the QE:
II is a
,flowing structure). Figure 3.1 shows an example of the hierarchy ofcomponents in a building.
