Abstract


Despite their powerful core current applications in design decision 
support tools show great disparities in their problem representation 
and performance. Beside the development of new tools, research to 
support design decision making is directed at improving the available 
tools by attempting to emulate the human cognitive modelling process.

One of the most important issues in this field is the development of In-
telligent front ends. Intelligent front ends aim to support powerful but 
complicated and complex design decision tools by utilisation of recent 
advances in design theory and computer science research. Despite 
these advances the main problem in realising an intelligent design deci-
sion support tool is that of knowledge engineering.

This paper is a protocol of the development of a small piece of an intel-
ligent application for design decision support. It starts with an attempt 
to elaborate a definition and requirements for Intelligent front ends. 
Further, it will review some of the current issues in research, both, in 
terms of design and computing, and will develop these issues. A main 
part will be the application of the elaborated view in order to create a 
particular interface for the support of the design performance simula-
tion tool ESP using the prototype development of an Intelligent front 
end by Clarke et al. (1989). Some general strategies shall become obvi-
ous. Finally, the application will be discussed in terms of the possibili-
ties/necessities of further developments to the Intelligent front end. The 
problems encountered during this work will also be related to the cur-
rent research.



University of Strathclyde

Department of Architecture and Building Science

THE REALISATION OF CURRENT ISSUES IN KNOWLEDGE-BASED DESIGN 
RESEARCH BY USING INTELLIGENT FRONT ENDS

by Alexander Gyalokay


Presented in partial fulfilment of the requirements for the degree of
Master of Science
in Computer Aided Building Design


August 1991


The copyright of this thesis belongs to the author under the terms of the 
United Kingdom Copyright Acts as qualified by University of Strath-
clyde Regulation 3.49. Due acknowledgement must always be made of 
the use of any material contained in, or derived from, this thesis.


TABLE OF CONTENTS


1.	INTRODUCTION

2.	PROBLEM CHARACTERISTICS
2.1.	Human problem representation and computer interaction
2.2.	Task specification of Intelligent front ends
2.3.	Simulation as design evaluation

3.	CURRENT ISSUES OF KNOWLEDGE-BASED DESIGN RESEARCH
3.1.	Model conceptualisation
3.2.	Product modelling
3.3.	Prototypes and problem modelling
3.4.	Monitoring and user modelling
3.4.1.	Monitoring
3.4.2.	User modelling

4.	SOLUTION STRATEGIES IN ARTIFICIAL INTELLIGENCE RESEARCH
4.1.	Blackboard architecture
4.2.	Object-oriented programming paradigm

5.	REALISATION EXAMPLES
5.1.	Current status of the Intelligent front end
5.1.1.	The Blackboard
5.1.2.	The Forms package
5.1.3.	The Dialogue handler
5.1.4.	The Knowledge handler
5.1.5.	The User handler
5.1.6.	User conceptualisation
5.1.7.	The Appraisal handler
5.1.8.	The Data handler
5.1.9.	The Application handler
5.1.10.	The current status of the Intelligent front end
5.2.	Application of some issues
5.2.1.	Collecting concepts into meaningful chunks (meta-concepts)
5.2.2.	Knowledge bases as interface handler, input verifica-
	tion, providing defaults
5.2.3.	Communicating with non-human clients
5.2.4.	Realising prototyping
5.2.5.	Knowledge and providing defaults by inferences
5.2.6.	An intelligent information tool
5.3.	Problems and suggestions for further developments of the 
	application
5.3.1.	Problems encountered
5.3.2.	The Intelligent front end as a communication tool
5.3.3.	Use of the suggested environment
5.3.4.	Knowledge structuring

6.	CONCLUSION

APPENDICES

A	PROGRAM REFERENCE

B	REFERENCES



1	INTRODUCTION


Technological development in the building industry, particularly in the 
field of manufacturing, led to a rapid growth in the design constraints 
and regulatory which have to be managed during the design process. 
Developments in computer technology in the recent years are charac-
terised by advances in domain specific design tools, in workstation 
technology, and networking. Although very powerful in their core these 
tools are very difficult to handle, particularly in the broad field of de-
sign decision making.

Clarke (1991) characterises the problem of design decision making as 
follows:

"Firstly, engineering systems are complex mechanisms, involving 
non-trivial geometries, transient phenomena and the like, and there is 
a growing realisation that traditional design tools often possess an in-
appropriate technical resolution. Secondly, and particularly at the 
formative stages of the design process, there is a need for rapid feed-
back on the performance and cost profiles of design alternatives."

Thus it becomes desirable to provide frameworks which allow custom-
isation of the available modern design decision tools by ensuring crea-
tivity, pluralism, and expertise, and also to improve the design decision 
making activity by providing a better understanding of its complex na-
ture.

Several developments of these frameworks have been undertaken with 
different attitudes. Beside the attempt to develop a general design deci-
sion framework (Rutherford, 1990) the emphasis is particularly directed 
on the development of intelligent interfaces to support domain specific 
design tools (Clarke, 1989). These developments in computer interfaces 
have been aimed at reducing the disparity between the user's own or-
ganisation of a task and how that task is performed at the interface. The 
means employed to solve these problems are the utilisation of Human-
Computer Interaction techniques in connection with Knowledge-based 
systems and the research in design decision support by Knowledge-
based design systems.

On the other hand computer science has provided some new develop-
ments in order to cope with the application of computer technology. 
These are the object-oriented programming paradigm, advances in da-
tabase technology, blackboard architectures etc.

However, the knowledge engineer who is confronted with the task of a 
particular problem in engineering design will discover that the availa-
ble research work is mostly theoretical and that the computer basics 
which are applicable in the research field deal mainly with very low 
level aspects, serving computational organisation rather than being an 
aid to specific problems.

The focus of this work is an attempt to close the gap between research 
and application, elaborating schemes for application rather than at-
tempting to progress any research path.

In order to solve this problem I have firstly tried to define the problem 
in general. Then I reviewed some of the current issues in knowledge-
based design research and computer science, and developed these is-
sues further while keeping the intentions of Intelligent front ends in 
mind. In order to ensure applicability of the developed ideas I took an 
application in this research field, namely the Intelligent front end for 
the energy simulation package ESP. Here I will show some possibilities 
of applying the research issues by example. The main issue is to tackle 
application, rather than address any of the current software or hardware 
options. Finally, conclusions will be developed which shall serve the 
further development of the Intelligent front end and allow a re-defini-
tion of the problems. In the appendices practical development of this 
work is shown including, forms, form templates, knowledge bases and 
scripts.


2	PROBLEM CHARACTERISTICS


This section will give a short overview about the background research 
and development of Intelligent front ends. Firstly, some issues of basic 
research in design are discussed. Based on this initial discussion an at-
tempt to find a definition of Intelligent front ends is undertaken by re-
viewing recent literature. Finally, the research in design simulation 
tools is related to the general approach to support design by computers 
in order to elaborate presuppositions for the further consideration in 
this paper.


2.1	Human problem representation and computer interaction

"Cognitive modelling is analogic, presentational, holistic, integrative 
and based upon pattern recognition and pattern manipulation. Ration-
al thinking is digital, sequentational, analytical, explicatory and based 
upon categorisation and logical inference."

writes Bridges (1985) about human thinking related to design research. 
For purposes of discussion, it will be assumed that design contains both 
types of thought, the rational and the cognitive modelling.

Current research in design decision support tools is heavily involved in 
exploring the area of rationality in design. The few attempts to explore 
cognitive modelling by, for instance, neural networks are far from any 
practical application.

Hence, once a design decision tool is built we have still to fit it into the 
conceptual model of human thought: even of rational thinking and cog-
nitive modelling. Considering this process the focus of the discussion 
will be directed away from the concerns of internal organisation and to-
wards the problem of external appearance and the behaviour of such 
design resource. The performance of a design decision tool must meet 
the human cognitive model of the problem to ensure communication 
between user and design resource. This communication occurs by con-
ceptual mapping of the particular problem representations.

In order to enable mapping (or interfacing) we need some sort of feel-
ing or knowing about the structure of our cognitive models.


2.2	Task specification of Intelligent front ends

Sharratt (1991) defines an intelligent front end as

"... an interface which helps a user overcome their incomplete un-
derstanding of the computer system and in this support role, employs 
knowledge of the user, the user's tasks, the task domain and the style 
of interaction required by different users."

and provides thus a definition of the problem, which is rather technical 
in comparison with the aspects discussed in the previous chapter.

More generally, an Intelligent front end can be considered as an inter-
face which enables a human user to communicate with a computational 
resource in a manner he or his abilities of cognitive mapping are used 
to. That implies on one side that the human has to learn to use any 
knowledge resource as to communicate by language or drawing. On the 
other side he can ask for some concession like help, a concept level 
which is appropriate for him etc. (as mentioned in the definition by 
Sharratt).

Clarke et al. (1989) defines the role of Intelligent front ends as:

"An Intelligent front end has generally to support two fundamental 
problems; the quantity and nature of data being manipulated and the 
expertise and conceptual outlook of the user."

In contrast to these definitions which show clearly the intention of In-
telligent front ends Rutherford (1990) discusses some requirements for 
environments which provide intelligent design assistance by breaking 
down the definitions mentioned above. These environments:

o	"enable experts from different subdisciplines to access the function-
	ality of a comprehensive range of design tools,

o	isolate the user from low level aspects of CAD tool management,

o	provide mechanisms to access knowledge other domains,

o	provide intelligent, contextually relevant assistance,

o	facilitate the rapid integration of new and existing design methods,

o	automate the acquisition of knowledge,

o	allow the customising of existing design solution plans facilitating 
	rapid prototyping,

o	offer distributed/parallel processing support to speed a synthesis,

o	provide an open system architecture."


2.3	Simulation as design evaluation

Simulation as a particular type of design evaluation is an integral part 
of the design process. Hence, the particular characteristics of the design 
process also emerge in the support of design simulation. This assump-
tion underlies the strategies which are developed in this paper.

Research over the last 40 years has produced some models of the de-
sign process. These models were influenced by different attitudes. One 
of the most important attitudes is the degree of rationality inherent in 
design. In this paper it is presupposed that the design process is charac-
terised by a certain degree of rationality and logic, and, that there are 
problem areas in which this is well-defined.

In order to deal with such problems March (1984) suggests a methodolo-
gy for rational design which is based on a `Production-Deduction-In-
duction' model (PDI-model). (Fig. 1)

This model emphasises the iterative character of design processes and 
the interaction of different types of reasoning during design rather than 
attempting to give a complete schedule of the design process (as for in-
stance by Pahl and Beitz, 1984).

"The design process in this model happens as a cyclic, iterative proce-
dure, PDIPDI... and so on, with constant refinements and redefinition 
being made of characteristics, design, and suppositions."(March, 1984)

Customising this model for our purposes we can encounter the issue of 
simulation as the design performance prediction. This allows the fol-
lowing conclusions:

o	Design performance prediction happens as a deductive reasoning 
	process.

o	Design performance prediction happens on the basis of a descrip-
	tion of the actual design state (product model) and a theory about 
	the prediction appraisal (domain knowledge). The product model 
	is a result of design production (abductive reasoning process) and 
	will be influenced thus by the design production process.

o	The result of the design performance prediction is used in the pro-
	duction process as design data, in the induction process as design 
	characteristics, and must therefore be differently interpreted.

By consideration of these facts in the context of simulation of design 
performance it can be suggested that:

o	The model of the design product produced by the designer under-
	lies every simulation, hence the simulation must be able to cope 
	with the same incomplete, abstract, and perhaps inconsistent 
	model of the design product as the designer does.

o	The knowledge which underlies the simulation must be compre-
	hensive enough to complete the model of the design product in 
	order to form a valid set of presuppositions for simulation. That 
	must include knowledge about how to cope with different design 
	models and levels of abstraction.

o	The elaborated performance must be interpretable in a free man-
	ner to enable its use as input for the design production process 
	and the elaboration of design rules.

o	The process of design simulation can be realised mainly by de-
	ductive reasoning processes.

In conclusion the characteristics of design performance simulation as a 
part of the design process necessitate a rather general discussion of de-
sign decision support in this paper. The integration of design simulation 
into the overall design process allows us to take the conclusions which 
are elaborated above as presupposed in this work.


3	CURRENT ISSUES OF KNOWLEDGE-BASED DESIGN RESEARCH


Current research in knowledge-based design support systems are main-
ly directed on the exploration of new strategies to represent external-
ised human knowledge in a more appropriate way. After a 
comprehensive elaboration of our common computing tools it appears 
as necessary to turn back and to look at our human skills in cognitive 
modelling and thinking. Using recent advances in psychology this re-
search provides some new approaches in representing the human prob-
lem solving activity, particularly in design.

This chapter outlines some of these issues in computer aided design re-
search in accordance to the problem of interfacing and design represen-
tation.


3.1	Model conceptualisation

"The fact is that our pure sensuous concepts do not depend on im-
ages of objects but on schemata. No image of a triangle in general 
could ever be adequate to its concept. It would never attain generality 
of the concept, which makes it applicable to all triangles, whether 
right-angled, or anything else, but would always be restricted to one 
portion of the concept." (Kant, 1781)

The representation of design knowledge is a fundamental problem in 
supporting design decision making by knowledge-based design sys-
tems. The knowledge to be represented is comprehensive and is of 
magnifold quality as the design process inherent.

One of the objectives of Intelligent front ends is the ability to cope with 
various users enabling every user to have his own perspective of the 
problem area (see chapter 2.2). Since different users may have very differ-
ent conceptual models of the problem space the separate representation 
of these conceptual models will be necessary. That implies that there is 
a conceptual model of the problem space which can be understood by 
each one of these different users. A conceptual model, common to all 
users of the problem space and the user's specific view must remain 
separated from one other. However the user must also be able to dy-
namically change his model during problem definition. (Fig. 2) 

Rutherford (1990) defines the elemental communication primitive as the 
concept and shows the following properties:

-	A concept is a sufficiently high level abstraction common in all de-
	sign areas.

-	Concepts are universal - they may be exchanged between sys-
	tems.

-	A concept may be interpreted differently between different systems.

-	A concept have many different representations depending upon the 
	contextual language employed.

-	Any system employing conceptual models is capable of represent-
	ing any product.

Further it is suggested that ambiguities between conceptual models (of 
users and the environment) can be resolved by re-description and re-
phrasing. Rutherford (1990) defines:

-	dynamic re-description by further conceptual decomposition (elabo-
	ration) or contraction,

-	dynamic re-phrasing by using different `words' or symbols to de-
	scribe or represent both meaning and value of a particular concept.

The careful separation of a common conceptual model and a user-spe-
cific view is fundamental to the requirements mentioned above because 
it has a strong influence on the demand of conceptual mapping. Gener-
ally, it is desirable to represent as many concepts as possible in a gener-
al model to ensure a common understanding of these concepts and to 
minimize conceptual mapping. These models must contain at least a set 
of concepts which are still able to represent a full description of the 
problem. However, different views multiply the number of different 
conceptual models and make this separation difficult.

The infinite number of possible perceptions of a building design im-
plies an endless number of building conceptual models. Thus generality 
of concepts may greatly vary.

Ayrle (1991) points out:

"In a problem space of limited complexity we can have unlimited 
competence in solving the problem - whereas in a problem space of 
unlimited complexity, we can always only have limited competence in 
problem solving."

Customising this idea the separation of common concepts and user spe-
cific models are only possible if the number of perceptions, i.e. users is 
limited.

By analysing conceptualisations of problem descriptions of a number 
of users a set of concepts can be elaborated which allows the complete 
representation of the problem and ensures the understanding of the spe-
cific view of each user. (Fig. 3)

An emerging problem, however, is that the set of common concepts 
does not necessarily form a complete hierarchy which is easily to map 
with the user's model.

MacRandal (1991) points out that it is very necessary to avoid any limi-
tations in the user's conceptualisation of the problem. That results in 
the necessity of conceptual mapping between different problem con-
ceptualisation which can be far more difficult as it is currently consid-
ered in the application of the Intelligent front end. This is particularly 
true if models are to be transferred into an entirely different context 
since a complicated mapping process will be necessary. The set of com-
mon concepts in a broad context will be a low level, elemental model 
rather than a high level concept model. Thus the process of conceptual 
mapping between two conceptualisations will consists of two stages. 
Firstly, a description must be broken down to the level of the common 
concepts and mapped with them. The second stage is the abstraction of 
a hierarchical model in terms of the second conceptualisation based on 
the common concepts. This second part of mapping is considered to be 
very difficult and is still not resolved satisfactory.

The process of elaboration of general concept models is closely related 
to the definition of a common product model in the building industry by 
using a similar approach and requirements (Bjork, 1991). Here, attention 
is paid to the elaboration of a complete hierarchical model to overcome 
the problem of conceptual mapping in dealing with models of design 
product rather than the entire design problem. However, product model 
standards are still under development. It would useful to apply the re-
sults of this research into the development of general concept models.

Once a general concept model is established and thus communication 
ensured all other concepts will become user-specific. They are easily 
handled by re-phrasing or re-describing general common concepts.

Strategies of semantic variation are elaborated by Rutherford (1990).


3.2	Product modelling

The previous chapter discussed the way in which the user structures his 
view on the design problem and which requirements have to be met to 
ensure communication. Discussion will now be focused on how the de-
sign product can be conceptualised efficiently and comprehensive.

In the product modelling approach a standardised way of product de-
scription is sought, especially if data has to be transferred to different 
applications or users. In the building construction process the efficient 
modelling of the building is necessary because the interchange of prod-
uct information between different contractors greatly influences the 
construction process.

Some research in this field has already been undertaken. A definition of 
a product model is provided by Bjork (1991):

"A product model as a general concept is a conceptual description of 
a product, capable of structuring all the information necessary for the 
design, manufacturing and use of that product."

During definition of a conceptual model for structuring all useful build-
ing design, production, and maintenance data, the following require-
ments have to be considered:

o	Comprehensiveness

o	Coverage of all stages in construction process

o	Avoiding redundant information

o	Independence from any output structures

o	Independence from software and hardware systems

Another approach is based on discussion of the design process. This 
process is considered as typical non-linear and usually based upon ab-
stract levels.

Bjork (1991) characterises design processes as following:

"A typical feature of any engineering design process is that the fea-
tures of the product can be dealt with on different levels of abstrac-
tions. The most typical design process is basically top down, where 
major design decisions lead to a further breakdown of the design 
space into subproblems, which may be subdivided into subproblems. 
It can be argued that the process is not usually linear, but a discus-
sion of the nature of the design process outside the scope of this pa-
per. Abstraction mechanisms can also work in both ways, top-down 
(specialization) or bottom up (generalization)."

A key issue in the design process is abstraction. During the design 
process the designer divides the building into meaningful systems and 
parts, and internal relations between this parts. An abstraction hierar-
chy can be seen as a tool to help the designer to deal with subdivision. 

Abstraction seems particularly important during the early stages of de-
sign. The designer deals mostly with higher level concepts which imply 
a great number of general but only a few concrete specifications. Using 
multi-level hierarchies it becomes possible to work with data from the 
briefing or sketch design phase and the detailed design phase in the 
same model.

Bjork (1991) suggests in the RATAS model a useful approach towards a 
building product model. (Fig. 4)

As well as an abstraction hierarchy Bjork also considered such issues 
as attributes, inheritance of properties, and relationships between ob-
jects.

In order to make an Intelligent front end robust and useful in a multi-
level design decision frame work it will be necessary to employ the 
common product model scheme in the conceptual model underlying the 
Intelligent front end. This will ensure full communication with all re-
sources in the building construction process.

However, Doster (1990) writes

"It is obvious that the necessary software tools for the creation of 
building product models is still not available. The available relational 
database models are only suitable with limitations."


3.3	Prototypes and problem modelling

Prototyping is mentioned by Gero (1990) as an important means of pro-
ducing design. The intention of these prototypes is to employ certain 
types of schemes in order to form a new design product. In this context 
a prototype is considered rather as a physical object which has to fulfil 
certain behavioural requirements.

In this paper the term prototype is used in a slightly different way 
which is however very closely related to the prototypes in sense of 
Gero (1990). In contrast to previous chapters the discussion is now di-
rected towards the issue of providing some aid for the designer in order 
that he may describe his problem. The form of the prototype will be 
view dependent and an active resource.

The starting point for discussion is quite similar to Gero's (1990) view 
point. Individual experiences are formed into generalised concepts at 
many different levels of abstraction. These concepts form classes 
which serve to infer properties from them. A schema is a conceptual 
structure for organising concepts or grouping of such design knowl-
edge. These conceptual schemata are called prototypes. It is an abstrac-
tion and thus a generalisation of concepts.

The individual experiences of designers are various. Only in a few cas-
es do they correspond to an object which appears in the product model, 
mostly they are only notions. In our artificial model of the problem 
space we are able to represent some specific aspects of the problem 
space depending on the type of our abstraction. These aspects are most-
ly bond to some of the physical objects in the design process. In order 
to aid the designer we have to provide a mechanism which allows him 
to use his past experience. However, the total number of ways possible 
to consider the problem space will not fit into any problem conceptuali-
sation.

The necessity to represent the designer's notion anywhere outside of 
our conceptual model leads to the following consideration. During de-
signing the designer does not work with his experience directly. The 
notion of that what he is thinking about does not fit into the actual mod-
el in terms of the same vocabulary (for instance draughting a plan of a 
building and thinking about the use of the building in a certain way). In 
order to resolve this inconsistency he shifts his notion down onto the 
level of the conceptual model and evaluates this notion in terms of the 
model (for instance, how much area will a certain function require and 
the evaluation of this problem being the use of a furniture stencil). In 
other words the designer works with his notions outside the model and 
shifts the notions down in order to evaluate particular aspect.

Therefore the notions of the designer need not be included in the prob-
lem conceptualisation, rather they have to be established as a kind of 
tool which enables the designer to work on his actual problem concep-
tualisation. These notions are considered as prototypes in this paper. 
They are not bond to any physical object but rather a very free collec-
tion of influences. (Fig. 5)

The use of these prototypes happens then as instantiation of their at-
tributes (in contrast to the suggestion by Gero where the entire proto-
type is instantiated). Using prototypes three types of activity can be 
distinguished in the same way as Gero (1990): prototype refinement, 
prototype adaption, and prototype generation.

Prototype refinement

Prototype refinement is the simplest and most common type of proto-
type use. Here a prototype is selected on the basis that its notion (or 
performance) matches the desired performance in a general sense. That 
involves instantiating of the variables and determination of its values. 
Routine design action can be supported by prototype refinement.

Prototype adaption

If a prototype is found inadequate in relation to a design criteria, the 
user may be able to adapt it to make it more useful by modifying the 
contained knowledge.

Prototype generation

Prototype generation will occur if neither a refinement, by acceptance 
of the defined state, nor an adaption, by changing the defined state, is 
satisfactory. Prototype generation implies a degree of abduction be-
cause the designer must express his ideas from the start (in terms of vo-
cabulary and relationships).

The form of prototypes discussed here focused on the behaviour of an 
entity. In terms of Gero it represents a subset of Gero's intention which 
emphasises interpretation and interpretive knowledge during neglect of 
aspects of its vocabulary.


3.4	Monitoring and user modelling


In the current application of the Intelligent front end some user stereo-
types are suggested in order to provide different approaches to the area 
of problem description. These stereotypes differ more-or-less only in 
the conceptualisation of the problem definition. However, putting the 
Intelligent front end in the context of a multi-level design decision 
framework means that many users must be handled. Users differ in 
their ability to access the product model or design resource. The con-
cept of handling different users of a common design resource will be 
considered under the term `monitoring'.


3.4.1	Monitoring


"... each view is not just a subset, but contains semantic information 
via the relations setup among the data object by the individual." (Vi-
dovic, 1990)

Monitoring is the establishment of the relationship between a user and 
a design resource.

The user may be any human user or any design resource. The design re-
source consists of conceptualisation of the problem world and domain 
knowledge dealing within these models.

The relationship between user and design resource is characterised by 
the user and his intention. Generally a monitor has to fulfil the follow-
ing requirements.

o	The monitor enables the user to view the design model and re-
	source as required.

o	The monitor enables the user to access the design model or re-
	source as required.

o	The monitor limits the user as little as possible.

Each user is mostly interested only in certain objects classes, rela-
tions, and attributes. In order to limit the data to be considered views 
are used. Views are attached to specific subdisciplines, design stag-
es, and abstraction levels. (Bjork, 1991)

The particular form of view or access may differ for different users. 
The characteristics of the user dealing with the relationship between a 
particular user and a design resource are held in the user model (see 
chapter 3.4.2). The user model and the actual requirements of the user are 
applied in order to establish a monitor for communicating with a design 
resource. User's requirements may vary when the user changes his fo-
cus of interest from one object inside the design world to another.(Fig. 6)

The quality of a monitor also possesses some active aspects. That ena-
bles on one hand scheduling the design or problem definition process 
by directed monitoring which may provide an additional support of the 
design process. However, beside these advantages there is also the dan-
ger of limiting the freedom of the designer.

An example which shows a broad application of the monitor concept is 
ARMILLA (Drach et al., 1990). Here the monitor concept is based on spe-
cial windows which allow every user a certain view on the data model. 
The number of windows is not limited and every window can show 
parts of the data model by using iconography depending on the infor-
mation demand and the design possibilities of the design level. Every 
window is associated with a number of interactive tools which realise 
access to the data model and change the actual view. These tools con-
trol data representation and allow the user to build up and/or edit the 
product model.


3.4.2	User modelling

As already mentioned different users are interested in different views of 
the product model. To handle these different attitudes user models are 
introduced in which all relevant characteristics of the user are collected.

Wahlster and Kobsa (1989) provide a convenient definition of user mod-
els:

An user model is a knowledge source in natural language systems 
which contains explicit assumptions on all aspects of the user that 
may be relevant to the dialogue behaviour of the systems. These as-
sumptions must be separable by the system from the rest of the sys-
tem knowledge.

The user modelling process itself may happen in two different ways. 
Firstly, the user is initially assessed by making some assumptions about 
his/her characteristics. This assumptions relate to

o	the user's domain knowledge,

o	the user's familiarity with the environment,

o	the user's goal,

o	and the user's belief about some individual facts.

The second method of user modelling is to employ a user modelling 
component acting incrementally to construct a user model (Wahlster and 
Kobsa, 1989). In practice both ways can be used together (Clarke et al., 
1989).

In order to handle different users it is suggested that user stereotypes 
are initially set (Rich, 1989). Clarke (1989) divides the user in the applica-
tion of the intelligent front and for the support of ESP into three types 
(designer, engineer, modeller) according their degree of model abstrac-
tion and typical problem definition skills, but keeps the possibility of 
defining any other user open (for instance student). Further a break-
down orthogonally to the user type is suggested to cope with different 
levels of user's expertise (expert, novice).

By developing the Intelligent front end towards a general design deci-
sion support framework the number of different users would rapidly ex-
pand. To handle these users the breakdown into stereotypes is very 
convenient. Basic assumptions can be made about user characteristics, 
and in the context of building design the criteria for these are:

o	the user's goal, the well defined task of the user in the overall de-
	sign process which possesses the acknowledgement of all other 
	users working in the environment,

o	the user's responsibility, the scope of rights and duties in the de-
	sign process which serves the determination of the range of ac-
	cess to the product model enabled for the user (reading, writing, 
	etc.),

o	the user's domain knowledge, the concept level that the user is ac-
	customed to work on and the domain knowledge which is ap-
	plied.

o	the stage of the design process, the concept level the user is used 
	to work on in a particular design stage caused by altering the view 
	of the designer during the design process.

A further aspect in discussion of the development of the environment is 
the possible existence of non-human users (see chapter 5.2.3). If an oth-
er software environment is used to control the application of the intelli-
gent front end an additional user model must be applied to handle its 
method of communication and different terminology. However, these 
user models are likely to be less ambiguous than a human model.


4	SOLUTION STRATEGIES IN ARTIFICIAL INTELLIGENCE RESEARCH


This section will review some advances of recent research in artificial 
intelligence, with two intentions.

Firstly, artificial intelligence research provides solution strategies for 
problem with the characteristics in which we are interested, because the 
research is aimed at supporting higher complicated human processes 
such as design. Secondly, advances in artificial intelligence are in them-
selves important and have influenced human problem solving process 
by offering new strategies and models.


4.1	Blackboard architecture

"Blackboards, of all the tools available in artificial intelligence, offer 
the most potential for realizing such a (intelligent problem solving) 
system." (Hallam, 1990)

The blackboard system approach is aimed at the support of problem 
solving activities. Problem solving activities depend at any stage on the 
state of the problem solving process. Any problem solving system has 
to determine its schedule, the resources it employs, and influences 
which will initiate a re-schedule process of the system. A solution to 
this control problem is fundamental to intelligent behaviour (Hallam, 
1990).

The blackboard model consists of three major components: knowledge 
sources which embody experts, the blackboard (a structured database), 
and a control regime. (Fig. 7)

The blackboard stores all information relevant to the problem solving 
process. Structuring the blackboard is possible by partitioning it into 
meaningful, task-specific areas. Partitioning reflects typical systems of 
hierarchical organisation and is intended to facilitate control, allowing 
the system to focus attention on parts of the facts base. Focusing will be 
determined by control knowledge.

Knowledge sources contain expert knowledge. By customising the vo-
cabulary of the blackboard in order to ensure communication the 
knowledge sources do not need to be uniform. They are independent 
from each other and may be developed and added to as desired during 
their use. Knowledge resources may work in parallel and can respond 
to changes on the blackboard. They may embody multiple search strat-
egies, non-uniform knowledge representations, and contradictory and 
conflicting knowledge.

"The key property of a blackboard system is its ability to direct its at-
tention to different tasks according to certain explicit control heuris-
tics." (Coyne et al., 1990)

The control regime monitors the blackboard and determines actions to 
take at each stage. That includes the choice to invoke actions according 
a particular blackboard state, and to engage an appropriate knowledge 
resource in order to solve the problem.

A key question in blackboard systems is the solution to the problem of 
maintaining consistency in the blackboard. Inconsistency may easily 
occur when several clients are communicating simultaneously with the 
blackboard. Thus it is a main issue of the blackboard control regime to 
maintain the consistency of the blackboard and conceptual model.

In order to resolve the problem of maintaining consistency two strate-
gies are suggested: Consistency maintenance by maintaining the cur-
rent problem solving context and assumptioned-based truth 
maintenance. These issues are further elaborated by Hallam (1990).

Some of the potential advantages of blackboard systems are:

o	The use of independent knowledge resources allows structuring 
	and use of different types of representation mechanisms accord-
	ing the type and availability of the knowledge being coded.

o	The explicit discussion of control in a blackboard allows it to in-
	clude general task-nonspecific problem solving knowledge, thus 
	enabling flexible reasoning control.

o	The structured approach to knowledge representation allows rea-
	soning in different concept levels, and thus on very high level.


4.2	Object-oriented programming paradigm

The object-oriented programming paradigm represents one of the most 
modern schemes of organising software solutions. It offers comprehen-
sive schemes for the solution of problems in common programming 
and artificial intelligence. Hence, the object-oriented programming par-
adigm should be included in the consideration of applications of 
knowledge-based design systems.

Because of an increasing demand in software strategies for engineering 
and design and the growing size of applications, the demand for new 
principles for software structuring has become important. These princi-
ples include such issues as:

o	the scope of procedures, libraries etc.,

o	the meaningful structuring of an application supporting mainte-
	nance, team work, etc.,

o	software efficiency by re-use of source code.

The solution to these problems is an abstraction of the considered items 
into objects. Essentially, the abstraction is a behavioural rather than a 
structural abstraction (King, 1989), and deals therefore with the manipu-
lation of data.

An object comprises all the influences which give it its functionality, 
such as procedures, libraries, macros, etc. In order to increase efficien-
cy further strategies are employed, for instance, instantiation of objects, 
generic classes of objects, inheritance of properties through classes, dy-
namic binding of procedures according the object type they are work-
ing with. The strategy of the paradigm is particularly obvious during 
instantiation. Here, the filling of an instance variable is only possible by 
procedures owned by the object.

Nierstrasz (1989) emphasises that this has to be seen as broad approach 
and it is not bound on a certain feature. In comparison with the schemes 
of data representation in artificial intelligence (for instance frames) the 
object-oriented paradigm shows several similarities which are caused 
by common intent. Hence, it will be useful to employ these schemes in 
the development of knowledge-based design systems not only in the fi-
nal computation but also during the initial structuring process within 
the application problem.

A full survey of the object-oriented programming paradigm is shown 
by Nierstrasz (1989).


5	REALISATION EXAMPLES


In this section examples of the realisation of design decision support in 
the scheme of Intelligent front ends are shown. Strategies are devel-
oped which show how the theoretical approaches were established (as 
discussed in the previous sections) inside a recent development of an 
Intelligent front end by Clarke et al. (1989). In order to ensure applica-
bility of the strategies shown an example is taken from the current ap-
plication of the environment used in energy simulation. In conclusion 
the problems encountered while working with the Intelligent front end 
and ideas for further development are discussed.

The current application of the environment as design evaluation tool 
deals with the energy behaviour of a building by using the energy simu-
lation tool ESP (Clarke et al., 1991). This reduces the necessary model of 
the design process to a subset. However this subset still represents a 
typical building design model where the emphasis is redirected away 
from a very detailed spatial description (as common in architecture) to-
wards the energy issues. These concerns have mostly direct relation-
ships to the initial design model as for instance function and casual 
gains, or wall structure and thermal behaviour of the wall. Thus the 
problems of energy simulation and design in general are very similar in 
structure (as already discussed in chapter 2.3).


5.1	Current status of the Intelligent front end

The Intelligent front end consists of several modules which are organ-
ised around a central communication module, the blackboard. The mod-
ules work asynchronously by interacting with the blackboard. (Fig. 8)


5.1.1	The Blackboard

The blackboard is the centre of the current Intelligent front end system. 
It has two major functions. Firstly it stores the current state of the prob-
lem definition as input by the user or inferred by the knowledge han-
dler. That means it embodies the current storage of the product model. 
Secondly it acts as a communication centre for various clients.

Data storage

The fundamental blackboard information unit is a tuple of the form:

	concept < tab > value

Tuples can be meaningful to one or more clients depending on their 
purpose. They are stored on named areas which can serve as a means of 
structuring and operate like an independent blackboard. Such areas can 
have various function e.g., communication, storage etc. In the current 
application of the intelligent front end the tuples are used in the follow-
ing structure:

	concept		who_set		key_list	value.

The who_set key serves the relationship of the concept and the con-
cept history. Actually the keys have the values user_set or kb_set 
(for knowledge base set). These keys are necessary to control access to 
the concept. In contrast to the user the knowledge base can not over-
write any user entry. During the further development of the intelligent 
front end further types of keys may be established to control other ac-
cess mechanisms (for instance knowledge deduced by reasoning during 
data consistency checking). The key_list contains keys for further 
determination of the concept.

Client communication

Communication occurs via different blackboard areas. To organise this 
the blackboard uses different communicative protocols with each cli-
ent. Thus the client can ask for a tuple explicitly, or can ask the black-
board to keep them informed about any change in a particular 
blackboard area.


5.1.2	The Forms package

The task of the forms package is to manipulate sets of graphical forms 
which represent to the user a conceptual model of the problem and ena-
ble the user to enter concept data. Therefore it provides the facility to 
create interface structures (forms) which represent graphically the char-
acter of the problem, broken down into meta-concepts and finally con-
cepts.

The forms package is characterised by

o	the ability to collect concepts in meta-concept which are easily to 
	distinguish by graphical means and which may be nested,

o	the customising of graphics and/or text for description of particu-
	lar concepts,

o	the description and limitation of possible concept interaction 
	(type limitations),

o	the rapid feedback of user queries by providing help messages, 
	concept descriptions etc.

However, the forms program does not impart any meaning to user en-
try.

The forms package is designed to operate on the basis of commands re-
ceived from external processes. This enables intelligent control of the 
forms by focusing/hiding of concepts or dynamic replacement control-
led by the Intelligent front end.


5.1.3	The Dialogue handler

The dialogue handler is responsible for managing all user interaction 
and implementing the appropriate level of communication. Therefore it 
passes information from any user to the dialogue area of the Black-
board and posts entries from other blackboard clients back to the user.

Thus the dialogue handler runs the forms package (as the common user 
interface) and any other user interaction program (for instance maps 
etc.). In order to maintain independence from any program, the dia-
logue handler deals with generic requests and converts these into the 
syntax required by the interacting program.

This neutral language contains (Clarke et al., 1989):

new_dialog			Switch to a new interaction program

tell_user			Inform about a concept content

suggest_user			Suggest user an appropriate default value

offer_user			Present options to the user

focus_user			Direct user to a new meta-concept

unfocus_user			Finish a meta-concept

ask_user			Request a particular concept

unask_user			Withdraw the request

new_query			Ask an unexpected question.


5.1.4	The Knowledge handler

The knowledge handler controls the user dialogue, and collects and val-
idates user entries using several independent knowledge bases. There-
fore the knowledge handler is an autonomous inference engine and is 
based on PROLOG. For every concept name posted to the knowledge 
handler a predicate exists which is used as a goal for inference. This 
predicate invokes new actions including posting operations.

The knowledge bases are associated with certain meta-concepts. These 
meta-concept are user and design level dependent. Additionally knowl-
edge bases are available which offer general knowledge useful for all 
users. However, the question of the difference between user dependent 
knowledge and user independent domain knowledge will be discussed 
later in this section.

User inputs are managed by knowledge bases in the current Intelligent 
front end. User entries recognised by the forms package are piped to the 
user user_dialog area by the dialogue handler in the form:

	user_dialog	concept		value

and monitored further by the knowledge handler. The knowledge han-
dler transforms this format into the predicate:

	concept(value).

This predicate is set as a goal and verified by the knowledge base.

As well as communicating with the user via dialogue handler the 
knowledge handler also communicates with the blackboard. The black-
board area u_cpt exists to represent the user's problem definition sta-
tus. The predicates uset and kset post data to this area. Therefore the 
knowledge handler transforms the data from PROLOG syntax into the 
blackboard syntax.

In order to simplify knowledge handling the PROLOG inference en-
gine contains a set of tools. These tools mainly organise the interaction 
with different blackboard areas. Since the blackboard is developed to 
be as general as possible it initially does not contain structure or mean-
ing. To achieve structured, meaningful access to the blackboard the 
knowledge base has to convert the data piped to and from the black-
board into a format which is meaningful in the context of the developed 
environment. These tasks are mainly organised by the knowledge base 
kb_initial which contains the main tools of the inference machine 
i.e. interface organisation, focusing and defocusing, changing user 
models, consultation of further knowledge resources, and supply of 
some further built-in utilities (Clarke et al., 1989). The careful develop-
ment of these tools is essential to every application of the Intelligent 
front end.


5.1.5	The User handler

The user handler has simply to set and update the appropriate user con-
ceptualisation according the current user type and level.

Every user conceptualisation is represented as a complete set of forms 
(or other user interaction types), the associated knowledge bases, par-
ticular appraisal scripts, and a project history in form of a project col-
lection. These conceptualisations are stored in the UNIX environment 
in a subdirectory which has the same name as the user type and a stand-
ardised format. All user conceptualisations are stored in the subdirecto-
ry uc (user conceptualisation). Access to valid conceptualisations is 
achieved by a symbolic link which is also contained in uc and points to 
the valid subdirectory e.g.:

	uc	->	IFE_home/lib/uc/architect

This link can be re-established by the user handler in order to change 
the user type at run time.

The user handler is controlled by a knowledge base.


5.1.6	User conceptualisation

Three different user stereotypes are currently conceptualised in the In-
telligent front end:

The Designer	deals typically with early stages in the design process 
		and is characterised therefore by abstract concepts, lack 
		of understanding etc.

The Engineer	is the complement of the stereotype above. He works 
		with very detailed knowledge about task and model.

The Modeller	needs almost direct access to the functionality of the en-
		vironment caused by the typical size of problem defini-
		tion which he is confronted with. All assistance with 
		data preparation is desirable.


5.1.7	The Appraisal handler

The appraisal handler holds the strategies which are customised by the 
user in order to run application programs. These appraisals are repre-
sented by discrete, parameterised UNIX shell scripts (or appraisal defini-
tion scripts). Therefore the application program must be able to be run 
by UNIX standard input and also the procedural character of shell 
scripts must be comprehensive enough to achieve this.

The appraisals which are run by the knowledge bases are related to the 
blackboard. Communication with the application program occurs via 
an appraisal area in the blackboard. This area intentionally offers the 
same range of communication as the dialogue handler on the user side 
of the environment. Thus, an intelligent support of appraisal scripts by 
knowledge bases is possible despite the procedural characteristic of the 
appraisal scripts (see chapter 5.3.2).


5.1.8	The Data handler

The data handler creates application specific data-sets from the problem 
definition area u_cpt by utilisation of UNIX awk-scripts. These awk-
scripts define primitives in order to simplify partially complicated com-
munication processes with the blackboard. The scripts which run data 
extraction employ these primitives to extract blackboard information 
and any other parts of the UNIX environment to create the necessary 
file format. The orchestration of these different processes is controlled 
by the data handler (see chapter 5.2.3).

Awk-script interpreter lines (Clarke et al., 1989):

# a query of the u_cpt area of the Blackboard for the 
data associated with "no_zones"
/^%/			{ print "echo \"query	u_cpt	"
			  for (i = 4; i <= NF; i++ )
			 	print "	" $i
			  print "\" >&1; read junk junk"
			  for (i = 4; i <= NF; i++ )
				printf " junk"
			  printf " " $2 " <&0\n"
			  next
			}

Because of the general approach to the user conceptualisation of the 
problem description it is possible to extract the blackboard content into 
any format compatible with the problem conceptualisation (see chapter 
3.1).


5.1.9	The Application handler

The application handler currently fulfils the task of the dialogue handler 
on the application side of the Intelligent front end by running applica-
tions. It passes information about the data definition set and the chosen 
appraisal script to a UNIX shell where the script is executed.


5.1.10	The current status of the Intelligent front end

The application of the Intelligent front end for energy simulation is not 
complete but does offer a wide range of possibilities for its use (Clarke et 
al., 1991).

The establishment of a conceptual model of a problem through the In-
telligent front end requires the development of specific tools, particu-
larly in the field of knowledge handling. The PROLOG inference 
machine customises the definition within the basic knowledge base 
kb_initial. These are dependent partially on the conceptual model 
chosen and therefore require a special quality (see paragraph 5.1.4 and 
5.3.1).


5.2	Application of some issues

In the following chapter it will be shown how to apply the aspects men-
tioned in section 3 in the scheme of the Intelligent front end. The em-
phasis of this chapter lies on the straight-forward realisation of the 
schemes rather than on a complete development.

As an example for this paper the definition of zone usage for ESP simu-
lations is taken in order to show a broad range of possibilities of how to 
improve problem definitions. This problem area does not show many 
geometrical aspects because the intention of the author is to discuss ab-
stract concepts rather than the elaboration of how to handle 
complicated issues (like spatial geometry). Thus it is the authors belief 
that the chosen problem area shows characteristic problems in design 
evaluation.

All of the examples shown are developed in order support the user 
model `engineer' (but are also able to support any other user conceptu-
alisation). That is caused mainly by two reasons. Firstly, the user model 
`engineer' is characterised by relative clear intentions which are closely 
related to the application program. Additionally the user model is 
known to the author, therefore a study of user types is not required (and 
would not fit in the time scale of this work). Secondly, handling of 
higher concepts which are remote from the vocabulary of the applica-
tion requires comprehensive inference in order to re-product concepts 
in different conceptual levels. Inferences on that scale are research is-
sue in themselves. It should be noted that the solutions described in this 
paper contribute to the completion of the Intelligent front ends energy 
performance simulation functionality.


5.2.1	Collecting concepts into meaningful chunks (meta-concepts)

"... memory organizes tokens into clusters or chunks that have one 
or more common relationships binding them together." (Akin, 1986)

Every user of a design resource has his own conceptual model of the 
problem space. The characteristics of these conceptual models were al-
ready discussed in chapter 3.1. Once the user specific conceptual model 
is elaborated it must be represented inside the Intelligent front end. If 
the user is confronted with a completed application in his field of inter-
est he must be able to recognise his concept model within the applica-
tion. The recognition process depends mainly on two criteria, the visual 
appearance of the conceptual model and its dialogue.

In contrast to the application dialogue which is organised mostly by 
knowledge bases the visual appearance of the Intelligent front end can 
be realised by using different means. In terms of the computer resource 
used to interface with the user, the only requirement is set by the neces-
sity to talk with the Intelligent front end via Dialogue handler using a 
neutral language (see chapter 5.1.3.).

However, the most important means of interfacing with the user in the 
current version of the Intelligent front end is the forms package.

The forms package offers different methods of graphical representation 
of concepts on the screen. In order to meet different conceptual models 
or views that the user is accustomed to, concepts can be described al-
pha-numerically, graphically, etc. Rutherford (1990) also developed 
schemes to express different degrees of possible response using spe-
cially designed graphical concepts fields.

In the current Intelligent front end concepts are initially handled as in-
dependent from each other. But the user often considers these concepts 
as inherent in his conceptual mode only in relation to certain other con-
cepts. Separated concepts are thus meaningless and may lead to misin-
terpretation. The relationships between concepts and the conceptual 
hierarchy must therefore be visible within the Intelligent front end.

The forms package offers some functionality to meet these require-
ments. It is possible to collect concepts in meta-concepts (forms). 
Meta-concepts can be handled by the forms package as one and may be 
distinguished by using different background shades. The relationships 
between concepts inside a grouped meta-concept must be expressed by 
appropriate graphical arrangements. In order to avoid overloading of 
the user with more of the conceptual model as he can handle, concepts 
and meta-concepts may be hidden/focused at run-time.

The forms package also allows rapid user feedback by offering active 
help response and type checking.

The example shown in this work is characterised by the following 
structure. The energy unit in the context of ESP energy simulation is 
the zone. A zone must be described in terms of geometry, construction, 
and usage. The usage of an ESP zone as part of the building specifica-
tion has its an own form (meta-concept) in the Intelligent front end in 
which all zone utilisation issues are addressed. This form can be ac-
cessed by a button which is situated on the building specification form. 
Zone usage has to be recognised as containing two parts, the casual 
gains and the airflow acting in a zone. Both are still quite complex and 
not necessarily strongly related to one another. They are therefore rep-
resented by two further meta-concepts which can be accessed by but-
tons in top of the usage form.)

Specification of airflow is broken down into two subproblems, the ex-
pected default airflow in the zone and the definition of control. Both ar-
ranged with the same importance on the form and framed to hold their 
respective concepts together. The definition of the default airflow is 
broken down into three standard day types (weekday, saturday, sun-
day). The appearance of concept fields for each of the three day types 
would overload the user by displaying too many similar optional con-
cepts at the same time. Therefore, the default airflow definition is repre-
sented only once but closely related to a concept of great visual 
importance outside the airflow default definition form which deter-
mines the current day type. Airflow control is independent from the day 
type and thus positioned with the same importance. Since a change of 
the airflow control type changes the meaning of the airflow control def-
inition concepts (no control means that control items are unnecessary) 
the airflow control definition form will be hidden or focused. (Fig. 9)

The breakdown of the casual gains form is very similar to that of air-
flow. Here we deal with different definition possibilities rather than 
with different problems. These possibilities are listed from the top to 
the bottom. Concepts which change the forms definition (like the day 
type) or tools which are applicable to all of the concepts are situated at 
the top of the form in order to show their importance and scope (see par-
agraph 5.2.4). (Fig. 10)

All concepts and meta-concepts are equipped with a description and a 
help window. If there are any restrictions in the user response of a par-
ticular concept then the user is offered valid possibilities in the menu 
field of a concept (see paragraph 5.2.4, Fig. 12). If a particular aspect is to be 
defined by multiple entries, tables are created in scroll areas which 
show initially only the most common number of concept lines.

Rutherford (1990) develops of other communication types such as maps, 
etc.

In conclusion, the careful breakdown of the problem, the choice of the 
appropriate input mechanism, and the arrangement of these into a 
meaningful visual appearance are fundamental to the understanding of 
the problem, and must appear similar to the human problem conceptu-
alisation.


5.2.2	Knowledge bases as interface handler, input verification, 
	providing defaults

As mentioned in the previous paragraph the knowledge bases are re-
sponsible for the dialogue of the Intelligent front end. In order to 
achieve intelligent response the knowledge bases have to represent do-
main and domain independent knowledge. The main issues are input 
verification, user feedback, and the provision of defaults. Additionally 
the knowledge bases provide control of the forms package and thus of 
the human-computer interaction.

Physically the interaction of the user via forms package or similar tool 
is achieved by sending concept entries in the structure:

	concept <tab>	value

This tuple is transformed by the knowledge handler into a PROLOG-
predicate of the format:

	concept(value).

and set as a PROLOG-goal. The verification of this goal by associated 
knowledge bases embodies intelligent response to the user interaction 
(see paragraph 5.1.4).

The knowledge bases associated with a form must contain a predicate 
for every concept field on the form, to allow a response to all user in-
put. Responses can vary according to the meaning of the concept ad-
dressed. They can be divided into the following groups:

o	Controlling user interaction:

-	Control
-	Updating
-	Feedback	
-	Tailoring user interaction

o	Semantic response to the user input:

-	Input verification	
-	Input interpretation	
-	Model interaction	

o	Information providing:

-	Knowledge providing
-	Default providing	

The different types may be mixed or nested.

A standard input predicate which covers these actions could looks like 
the following:

concept (_Value) :-
	retrieve_current_state (_State_values),
	verify_input (_Value),
	interprete_input (_Value, _Interpretation),
	invoke_control (_Interpretation),
	interact_model (_Interpretation),
	provide_information (_Interpretation),
	feedback_user (_Interpretation),
	update_user (_Interpretation),
	tailor_user_interaction.

The tasks which are contained in this predicate result from the current 
development of the Intelligent front end, particularly from the concep-
tual model in the blackboard. The current blackboard entries are mean-
ingless. However, by customising the blackboard as a central unit it 
will be possible to control the conceptual model independently from 
the user's conceptualisation of the problem. Thus, input verification, 
consistency checks, and conceptual mapping could be realised by creat-
ing blackboard clients which were user model independent and hidden. 
The knowledge bases discussed in this paragraph would be a pure form 
of the monitor concept (see also chapter 3.4) and would not contain any 
user independent domain knowledge.

Control

Control predicates have to provide user and knowledge base with infor-
mation about the current state of the system. Firstly, there are actions 
which focus the discussion depending on the input by asking for con-
cepts or focusing on meta-concepts. A second type of control is the set-
ting of statements inside the local knowledge base. This is particularly 
important where concepts or predicates are used within different meta-
concepts.
Example of a predicate with mainly control function:

b_u_airflow(on):-
	asserta(active_concept(u_airflow)),
	tell_usr(b_u_cgain,off),
	focus_concept(usage, u_airflow),
	u_airflow(initialize).

Updating

During determination of the problem the user often changes the prob-
lem field in which he is working in order to compare data, look at bor-
der conditions etc. The input process is mainly successive, and some 
sessions are needed to fill out a meta-concept completely. Every re-fo-
cus process requires information about the current state of the black-
board. The refresh predicates used for this purpose have to comply with 
the following aims: retrieving the blackboard content according the 
current meta-concept, and informing the user about the status and value 
of the concepts.

These refresh predicates should be available at different levels, the low-
est level being the concept level. A couple of standard refresh predi-
cates are available as utilities (see appendix). It should also be possible to 
refresh every meta-concept by calling just one predicate. This predicate 
should scope the entire meta-concept, and may be nested. A standard 
name should be used to access it.

Example of updating predicates (calling and called predi-
cate), the calling predicate infers by recognition of the cur-
rent meta-concept the refresh predicate of the meta-concept:

u_current_zone(_Zone_number):- 
	zone_num(_Zone_number),
 	asserta(status(old)),
 	asserta(curr_zone(_Zone_number)),
 	uset(curr_zone,_Zone_number),
 	( active_concept(_Concept),!,
 	 _Refresh =.. [_Concept,refresh],
 	 _Refresh
 	 ;
 	 true
	).

u_cgain(refresh):-
 	curr_zone(_Zone_number),!,
 	load_z_name(_Zone_number),
 	refresh_c_values(_Zone_number).

Feedback

Feedback should inform the user about all essential requirements and 
the meaning of current input concepts according the user level and 
type. This includes error messages, warnings, and guidance for more 
complicated user interactions.

Example of a feedback predicate:

feedback(u_airflow_sel, novice):-
	chat_usr([
	`This button switches the focus of discussion to',
	`the air flow concern of the occupancy patterns',
	`of the building. Two subsidary forms will be',
	`offered to describe the airflow and the control',
	`of the airflow.',
	`']).


Input verification

Balachandran (1991) defines verification of design as the process of 
checking the completeness, consistency, and correctness of the design 
against a given set of requirements. In our example input verification is 
generally to divide into two groups; type checks and model consistency 
checks. The first aspect looks for an answer to the question: `Does the 
input fit in the current concept?' (for instance the limitations of a time 
input between 0 and 24). Thus it can be ensured that the intention of the 
concept are fulfilled by the user input process. The second aspect 
touches the relationships in the currently instantiated model. In the 
product model some relationships between data items are essential for 
the maintenance of the meaning of the entire model (see chapter 4.1). In 
order to maintain these relationships the user entry is verified during in-
put. The verification process consists of predicates which control the 
meaning of particular relationships in the model. Violating these rela-
tionships invokes a reaction in order to maintain their consistency (as 
discussed in chapter 4.1). Normally, this takes the form of the rejection of a 
user entry combined with appropriate user feedback. The strict use of 
this scheme ensures that the application of the Intelligent front end can 
only create a `sensible' problem definition.

Example of input verification by type checking:

verify_time(_Concept,_Time):-
	_Time >= 0,
	_Time =< 24;
	 (
	 _Time < 0,
	 ask_usr(_Concept, 0),
	 feedback(time_lt_0)
	 ;
	 ask_usr(_Concept, 24),
	 feedback(time_gt_24)
	 ),!,
	 fail.

Example of input verification by consistency check:

verify_consistency(_Value,_Relation,_Related_cpt,_R_
key):-
	\+ known(_Related_cpt,_R_key,_R_value)
	;
	known(_Related_cpt,_R_key,_R_value),
	_Term =.. [_Relation,_Value,_R_value],!,
	_Term.

verify_consistency(_,_,_,_):-
	feedback(consistency_clash),!,
	fail.

Example of one of the relationships used in the model:

gt(_A,_B):-
	_A > _B.
lt(_A,_B):-
	_A < _B.


Input interpretation


As mentioned in chapter 3.1 semantic re-description and re-phrasing 
are used to support user interaction. That necessitates the transforma-
tion of user entries into concepts relating to the conceptual model and 
also the reversal. The process of reproduction is considered here as se-
mantic interpretation.

Example of input interpretation:

`couple_index$'(_N,_Value):-
	curr_zone(_Zone),
	day_type(_Day_type),
	(couple_type(_Zone,_Day_type,_N,_Type)
	 ;
	 asserta(couple_type(_Zone,_Day_type,_N,temp)),
	 _Type = temp
	),
	tell_usr([`couple_type$',_N], _Type),
	( _Type == temp ,
	uset(couple_index_d1,[_Zone,_Day_type,_N], 0),
	uset(couple_index_d2,[_Zone,_Day_type,_N],_Value);
	uset(couple_index_d1,[_Zone,_Day_type,_N],_Value),
	uset(couple_index_d2,[_Zone,_Day_type,_N],0)
	).


Model interaction


Model interaction is the saving and retrieving of data items into or from 
the conceptual model stored in the blackboard. That is supported by the 
a standard set of interaction predicates which simplify model interac-
tion.

The current scope of available tools to handle concept values in a com-
prehensive manner is limited. During further development of the Intel-
ligent front end several keys which define concepts will become more 
important (see paragraph 5.3.1), and will necessitate further advances of 
these tools. (This has become already obvious during the preparation of 
this work.) (See paragraph 5.2.4.)

Examples have already been shown.

Knowledge and default providing

In order to become efficient any application of the Intelligent front end 
should be able to access comprehensive software tools which support 
the problem definition e.g. database management systems and expert 
systems. These tools provide deep knowledge enabling further specifi-
cation of concepts by relating the model to a larger design context. This 
offers additional support to user.

The interaction with the software environment (i.e. the tools which ena-
ble domain specific help) is mainly achieved by scripts as discussed lat-
er. Any information predicates have to communicate with this 
knowledge in order to put sensible user information together. The user 
is offered information simply by dialogue or by user feedback relating 
to a concept field, e.g. pull down menus, default values etc.

An example will be shown in the paragraph 5.2.5.


5.2.3	Communicating with non-human clients

Beside the human user the Intelligent front end has also communicate 
with other clients within the computer world. These clients are initially 
the same as the human client. Therefore it may be required that com-
munication is enabled which is characterised by incompleteness, 
switched focus, and different concept levels. Mostly, however, software 
clients require a fixed data format and a specific sequence. This results 
in two general approaches for communication with non-human clients:

1.	Treating all clients (human and non-human) in the same manner, 
	that means in the current Intelligent front end that every commu-
	nication will be verified by a knowledge base. That offers the 
	broadest range of communication for all types of clients.

2.	Built special tools to cope with the specific features of software 
	clients. These tools have only some of the capabilities mentioned 
	above, but they are easily to establish, for instance by scripts etc.

In the current Intelligent front end the second approach is used mainly. 
The software communication is organised by the application handler. 
The application handler runs applications by the use of UNIX shell 
scripts. The method of running applications by shell scripts is possible 
because of the strong procedural character of most of the application 
programs. However, it is necessary to ensure that the application pro-
grams may be run by UNIX standard input. The current appraisals are 
coded in shell scripts. These appraisals can be very complex and em-
ploy a broad range of software tools, for instance, the ESP energy sim-
ulation engine bps.

As well as running several appraisals specific scripts organise the `cus-
tomising' tools supporting the Intelligent front end application. These 
tools can be divided into two groups, the main group consisting of 
those tools concerned with the extraction of the conceptual model from 
the blackboard controlled by the building model handler.

In order to establish interchangeability of the zone usage definition 
within the Intelligent front end and ESP, the following functionality 
must be present:

o	Extraction of the blackboard content into an appropriate file for-
	mat (usually the ESP zone operation file format),

o	Loading the content of such file back into the blackboard model.

Therefore, two scripts have been developed. The first script write_-
operation_file is run by the building model handler using an awk 
pattern script.

Example from the zone usage extraction script:

% name = z_name user_set $i
 "${name}"

The second script is a normal UNIX shell script which communicates 
with the blackboard as a client. The communication is invoked by the 
knowledge handler tool:

to_bb(new_client,read_op,read_op,_File,_Zone).

Example from the zone operation retrieving script:

read line
echo "u_cpt z_name kb_set $nz $line"
read nc line
echo $nz $nc $line | awk 
	`{ print "u_cpt u_control_type_n user_set "$1" "$2
 	   print "u_cpt upper_control_limit user_set	"$1" "$3
	   print "u_cpt lower_control_limit user_set	"$1" "$4
	 }' 

In order to enable a broader support of the user, additional scripts be-
come necessary. These scripts enable access to other tools within the 
software environment, in this case the event profile database manage-
ment tool pro. In relation to paragraph 5.2.4 these scripts have to con-
trol:

o	the extraction of the contents of the event profile database for use 
	in the casual gain definition form menu (read_profile_data-
	base),

o	the extraction of the contents of one event profile for use in the 
	breakdown facility (read_1_profile),

o	the definition of an event profile in the event profile database.

However, the use of scripts enables communication between Intelligent 
front end and application programs only on a certain level, i.e. running 
scripts or reading from the blackboard. If a more comprehensive dia-
logue is required the first method should be used. This is an interesting 
area, especially where the dialogue has to cope with incomplete knowl-
edge in the blackboard or where further interaction depends on the sen-
sible analysis of the response by other clients.


5.2.4	Realising prototyping

As already mentioned in chapter 3.3 prototyping is understood as a way 
of describing a problem or element within the conceptual model in the 
context of this paper.

Problem description by prototyping takes place using three different 
methods; prototype refinement, prototype adaption, and prototype gen-
eration. In realisation of the prototype idea within a computer aided de-
sign system the appearance of the prototype idea is more important to 
the user than any internal representation (see also chapter 3.3). Thus exist-
ing standard prototypes of any form (databases etc.) should be readily 
offered by the Intelligent front end.

In the following example ESP's standard event profiles database sys-
tems is used to illustrate this. The event profiles are prototypes of the 
building occupation and usage reflecting changes of behaviour with 
time (Clarke et al., 1991), i.e. the fulfilment of a casual gain over a day. In 
order to form a casual gain by use of an event profile the profile is to 
multiply by the 100% casual gain values. This process can be consid-
ered as prototype use or refinement. Even if the event profile does not 
exactly fit in the context of the simulation, it can be used as a guide. 
That means that intervals will be deleted and time entries changed, in 
other words the prototype will be adapted. If ESP is used in an entirely 
new building context then new profiles will have to be created as easily 
as possible. It is already shown that while using event profiles all three 
types of working with prototypes are desirable. Therefore, to create a 
good problem definition environment for ESP it is required to access 
the event profiles as a kind of prototype. To offer the user these three 
possibilities the casual gain definition concept has been designed in a 
standard form with two tools to help more complex problem descrip-
tion. In the standard case the user chooses one of the event profiles of-
fered in the pop-up menu (Fig. 12). These event profiles are the 
descriptions of the event profiles database elements as already used in 
ESP. The Intelligent front end will read these entries directly from the 
database using the script read_profiles_database (paragraph 5.2.3) 
every time the user activates the usage meta-concept or changes the 
event profiles database itself. Thus the user is able to work with event 
profiles which he has designed possibly by himself or by using some of 
the application tools.

If the user wants to define an event profile more accurately then he may 
use the breakdown facility. Here he is enabled to define the time in 
which a casual gain is acting by stating the start and end time. Thus a 
refinement or an adaption of the event profiles is possible by addition of 
new periods of casual gain activity. If the user wants to change a proto-
type but he is not sure about the particular appearance of the event pro-
file then a complete line defined by an event profile can be shifted down 
into the breakdown facility. That implies that the Intelligent front end 
reads the contents of the event profile from the database and recalcu-
lates the user entries for the new concept field. (Fig. 13)

In order to enable prototype generation of event profiles access to pro - 
the event profile database management program of ESP will be offered. 
This is achieved by using an additional form and knowledge base 
which interacts with pro. After using this facility the pop-up menu of 
the event profile field is updated. (Fig. 14)


5.2.5	Knowledge and providing defaults by inferences

Knowledge and default providing is an essential tool inside the Intelli-
gent front end application. The realisation of this issue is shown by em-
ploying a small rule-based system.

The search for new information in the problem space is mainly data 
driven. The design space (or in this case the simulation space) is nar-
rowed down to an unambiguous problem description. In earlier stages 
the instantiation of concepts led to a few conclusions. Providing default 
values is thus limited to a very `superficial' default. During the problem 
description process new concepts will be instantiated and new conclu-
sions become possible. The defaults inferred on the basis of a more 
complete model have thus a better quality than the very first. This in-
creasing strength can lead to conclusions which express aspects of con-
sistency inside the model. Such conclusions are no longer simply 
default or user information but valuable instantiating inferences which 
provide fundamental user support.

The development of inferences can be illustrated by the following ex-
ample; the suggestion of surface constructions during definition of the 
zone construction.

Example of default providing predicates in pseudo code:

- Inference which `reverses' the current construction, a process necessary 
  when different zones of the same construction are connected:
infer_surface_construction(_Surface, _Construction, conclusion):-
	vertical (_Surface),
	touching_surface_of_other_zone (_Surface, _Touching_surface),
	construction ( _Touching_surface, _Wall),
	turn_around (_Wall, _Revers_wall),
	_Construction is _Revers_wall.

- Inference of any default wall construction:
infer_surface_construction(_Surface, _Construction, suggestion):-
	vertical (_Surface),
	touching_surface_of_other_zone (_Surface, _Touching_surface),
	default_inner_wall (_Wall),
	_Construction is _Wall.

- Inference of any default conctruction:
infer_surface_construction(_Surface, _Construction, suggestion):-
	vertical (_Surface),
	default_vertical_wall (_Wall),
	_Construction is _Wall.

- Predicate for calling default suggestions for one zone:
suggest_constructions (_Zone_number):-
	number_surfaces (_Zone_number, _Number),!,
	repeat, gen_inter(_N,1),
	(
	 infer_surface_construction (_N, _Construction, _Inference),
		( _Iference == suggestion ->
		 suggest_user (construction, _Construction)
		 ;
		 kb_set (construction, _N, _Construction),
		 tell_user (construction, _Construction),
		 feedback (necessary_conclusion)
	), _N =:= _Number, !.

Some aspects which play a role within constraint based reasoning proc-
ess are shown by Gyalokay (1991).

Shaviv (1991) distinguishes three different types of design parameter de-
faults in the context of energy simulation:

1.	Case-specific defaults dependent on some special conditions and 
	further divided into climate dependent and non-climate dependent 
	parameters,

2.	Combined Case-specific defaults tested by simulation evaluation 
	which have a great influence on the energy performance and are 
	very sensitive to other design parameters,

3.	Arbitrary design parameters which do not have a great influence on 
	energy performance.

This distinction underlays the scheme to use an energy simulation tool 
as an active design tool rather than a design evaluation tool. This slight-
ly changes the role of providing defaults within the Intelligent front 
end. Default would be provided, not to complete a problem description 
for simulation, but rather to emulate a design advisory system in the 
sense of an expert system.

In the context of the Intelligent front end it will be convenient to distin-
guish these possibilities physically. Defaults which support the simula-
tion are part of the user specific view and a result of the intentions of 
the user (preparing an design performance simulation). Suggesting ap-
propriate design solutions supports design production and underlays 
more productive characteristics in the design process. These could be 
related to a new user conceptualisation. The knowledge about the de-
sign domain itself could be held in a separate expert system to be con-
sulted by the Intelligent front end.


5.2.6	An intelligent information tool

As well as providing intelligent defaults and user information it is de-
sirable to offer the user knowledge in an appropriate format. That is 
particularly valid for such knowledge which already forms higher com-
plicated concepts and can not be represented in one concept field com-
prehensively.

In these cases it is convenient to provide a tool which offers knowledge 
and enables its selection, edition, and preparation, and finally organises 
its representation in the related input concepts. The visual form and the 
method of use can easily be inferred by analysing some common tools 
familiar to us, e.g. calculator, sketchbook etc.

The example chosen aids the description of casual gains in the casual 
gain definition form. These are characterised by a particular gain type 
and some quantitative values describing their thermal influence. These 
values are usually relative unknown to the user, but often the user 
knows how to describe the casual gain by considering entities (like 
worker etc.). Here again the idea of a prototype appears which the user 
can use to define his problem. The way chosen to represent these proto-
types are slightly different from the previous method. The entities used 
in this problem may vary in different design tasks. Because it is thought 
that the user will change the data items often he is offered the entity as 
information in a separate concept field. Here the data items can be 
changed, prepared, and moved after preparation in a chosen concept 
field (or line) directly. To allow movement different modes are enabled 
(supersede, add). The movement or `pipe' mechanism itself possesses 
some intelligence and avoids operations which are not consistent to the 
previously defined model (for instance adding different gain types to 
another). (Fig. 15)

Example of a predicate which pipes calculator data into the 
chosen concept field:
`cd_gain_marker$'(_N,on):-
	curr_scheme(_Scheme),!,
	response_cd(_Scheme,_N),
	tell_usr([`cd_gain_marker$',_N],off).

response_cd(calc,_N):-
	calc_mode(supersede),!,
	mult(_Mult),
	type(_Type),!,
	`cd_gain_type$'(_N,_Type),
	sensible(_Sensible0),
	_Sensible is _Sensible0 * _Mult,
	`cd_sensible$'(_N,_Sensible),
	latent(_Latent0),
	_Latent is _Latent0 * _Mult,
	`cd_latent$'(_N,_Latent),
	radiant(_Radiant),
	`cd_radiant$'(_N,_Radiant),
	convective(_Convective),
	`cd_convective$'(_N,_Convective).

In order to aid the provision of knowledge to the user it is suggested 
that frame tools are used operating in a specific domain knowledge bas-
es. These tools infer the content of a concept using inheritance, default 
values, and if-needed rules. The sequence of search can be directed by 
ordering the rules.

This idea is tested by a primitive frame manager. The following PRO-
LOG code shows the inference rule used to find a requested value (after 
a suggestion by Coyne et al., 1990).

Predicate for searching for a frame slot:

%% get a value
fget_z( _Frame, _Slot, _X):-
 fgetclasses( _Frame, _Classes),
 aux_fget_z( _Classes, _Slot, _X).

aux_fget_z( [], _, unknown):-
 !.
aux_fget_z( [_H|_T], _Slot, _X):-
 fget( _H, _Slot, value, _X),
 _X \== unknown, !.
aux_fget_z( [_H|_T], _Slot, _X):-
 fget( _H, _Slot, if_needed, _Y),
 _Y \== unknown, !,
 _Term =.. [_Y, _X],
 call(_Term).
aux_fget_z( [_H|_T], _Slot, _X):-
 fget( _H, _Slot, default, _X),
 _X \== unknown, !.
aux_fget_z( [_|_T], _Slot, _X):-
 aux_fget_z( _T, _Slot, _X).

The casual gain calculator tool can be accessed from the casual gain 
definition form. It is applicable to all types of casual gains definition 
and therefore situated at the top of the meta-concept.


5.3	Problems and suggestions for further 
	developments of the application

5.3.1	Problems encountered

During the work in this environment some problems were encountered. 
These problems are characteristic for developments of an application 
using the Intelligent front end rather than problems within the Intelli-
gent front end itself.

First, the means of communication with the blackboard defined in the 
knowledge base are not as comprehensive as required. The storage and 
retrieval of concepts containing more than one key within the black-
board was not possible. That is caused by the different formats used by 
the blackboard and the knowledge handler to represent concepts (in the 
blackboard lists cannot be stored). Thus a further development of the 
predicates which realise this communication will be necessary but was 
not possible within the time scheme of this work. This development 
must enable the storage of concept with an unlimited number of keys 
and values.

Secondly, when particular appraisal or data extraction scripts are in-
voked they have to recognise the problem definition status. In the cur-
rent status of the Intelligent front end application this is achieved by 
direct communication between the script and the u_cpt blackboard 
area which contains the conceptual model. This communication consist 
of queries which are piped to the blackboard and appropriate black-
board responses, i.e. the values of the concepts requested. However, if a 
particular concept is not instantiated the blackboard will not response 
to the query. That leads to the failure of the script and thus of the task. 
Since appraisal scripts are essential for the successful implementation 
of the Intelligent front end application, this represents an important lim-
itation within the environment.

Initially, there are two solutions to this problem. Firstly, it could be en-
sured that a comprehensive set of concepts are always instantiated cus-
tomising a kind of completeness predicates before an appraisal or 
building model extraction script is run. However, this would schedule 
the user to some extent and exclude the possibility of automatic infer-
ence of defaults etc. The second approach to the solution is the unifica-
tion of the method of handling blackboard clients. Thus the method of 
handling the human user by verifying his entries using knowledge bas-
es would also be applied to the application side of the development. 
Any query concerning the conceptual model in the blackboard would 
first go to a knowledge base which asks the blackboard itself about an 
entry and then offer further possibilities if the blackboard request fails. 
These responses can contain such actions as the initiation of inference 
for defaults etc., the controlled abort of the script, or the initiation of an 
user dialogue in order to resolve the problem. This scheme implies that 
as well as the human user the appraisals also possess knowledge bases 
which embody the appraisal script's conceptual model of the problem 
status. This will be further developed in paragraph 5.3.2.

Thirdly, the reasoning processes in the current application of the Intelli-
gent front end has grown rapidly during the development of the appli-
cation. There are two reasons for this. The basic tool ESP which is 
being interfaced by the Intelligent front end is very complex and thus 
the knowledge base is of considerable size. That leads to delays in the 
user access. Secondly, the development of the Intelligent front end to-
wards an intelligent tools requires the implementation of some schemes 
which are complex such as consistency maintenance and expert sys-
tems. These systems multiply the number of inferences required sub-
stantially. In order to cope with these problems it will be necessary to 
direct the discussion towards issues of increasing efficiency of the cod-
ed problem and its maintenance.


5.3.2	The Intelligent front end as a communication tool

The implementation of the Intelligent front end represents a typical in-
terface between a human user and an application program. The envi-
ronment, however, shows possibilities which are much wider.

The problem of intelligent response to support non-human clients will 
now be discussed. Since non-human clients need intelligent response 
just like the human user, the methods of interaction between clients and 
environment can be unified into one scheme which supports both hu-
man (by running the forms package etc.) and non-human interaction 
(by running appraisal scripts). This presupposed that the tool is capable 
of intelligent interaction, and can communicate with the dialogue area 
of the blackboard via dialogue handler. The dialogue entries in the 
blackboard are verified by knowledge bases which are associated with 
the client and initiate appropriate actions.

Considering the environment the following properties can be outlined:

o	The central unit of the environment, the blackboard, is able to 
	communicate with as many clients as desired. It possesses meta-
	knowledge to control these clients.

o	Since possessing a neutral language the dialogue handler is able 
	to communicate with every application program which shares this 
	language.

o	The knowledge handler is able to logically map every conceptual 
	model using the PROLOG language.

By applying these properties the environment is able to accommodate 
as many tasks (or job, clients, etc.) as desired.

The environment represents a system which contains a certain problem 
definition status. The clients which interact with this system represent 
active forces which change the model. The system itself possesses 
knowledge about how to establish interaction with particular clients. 
This means the possibility that the system can run a client to achieve a 
certain aim.

Such a model has the following advantages:

o	since it can communicate with every client its knows or is told 
	about and it can establish an unlimited number of interactions,

o	since every interaction is `intelligent' (by applying knowledge 
	bases) a meaningful dialogue in both directions is possible (the 
	system can answer a query with a query for further specification),

o	the human user can be substituted by any environment which em-
	ulates a human user.

The discussed systems can therefore be a node in a distributed design 
framework containing more than one of these systems.

In order to fit the parts of the current Intelligent front end into this 
scheme an imaginary model is suggested. (Fig. 16)

The parts of this environment contain the following features:


Client handler

The client handler embodies all knowledge about clients. This includes 
knowledge about 

o	how to choose a client according a certain goal. That is knowl-
	edge which is represented for non-human clients in the appraisal 
	handler (for different assessments different scripts will be used
	to run the ESP environment). The method used to interface with the 
	human client is currently predefined by use of the forms package 
	(and some other tools). The system views the human clients only 
	as a tool which is run by the forms package etc.

o	how to run a client physically, that knowledge is currently con-
	tained by the application handler,

o	which knowledge base to establish in order to set up meaningful 
	communication, this is currently done by the user handler but 
	only for human users.

The aim of the client handler is to establish interaction with clients by 
using its knowledge about them.

Dialogue handler

The dialogue handler does not only interact with the forms package in 
the proposed environment but with every abstract client.

Knowledge handler

Different knowledge handlers contain various knowledge associated 
with various users. This means that every input will be verified by a 
knowledge base which expresses the special view of that user. This en-
larges the potential of non-human clients which were until now only 
able to interact with the blackboard. Thus, it becomes possible to infer 
certain information by using the domain knowledge of the environ-
ment.


5.3.3	Use of the suggested environment

The suggested development of the Intelligent front end towards a mul-
ti-usable communication environment offers various application possi-
bilities within design computation. Some of these will now be 
discussed.

Intelligent front ends

The issue of intelligent front ends is already discussed in the previous 
chapters. The main intentions are the intelligent support of the problem 
definition and analysis of problems which are supported by applica-
tions behind the front end.

Intelligent monitors

The issue of an intelligent monitor differs only slightly from the intelli-
gent front end. The emphasis here lies in producing a certain type or 
standard of output rather than to support the problem definition itself. 
Sharratt (1991) points out that in current research more attention is paid 
to the support of user input than the intelligent preparation of applica-
tion outputs.

Intelligent design shift tools

The intelligent design shift tool supports mainly the work with the sys-
tem in the context of a distributed design framework. The support hap-
pens as a response to interaction with several clients. In order to resolve 
problems emerging in the blackboard the system responses with intelli-
gent interaction to its clients. It further possesses the knowledge to em-
ploy (start) new clients to shift a particular blackboard status onto other 
levels. Problems which can not be resolve in the scope of the system 
are posted back to the initiator, i.e. the human user in the environment. 
The entire process leads to a development of the problem (or product) 
as represented in the blackboard.

Intelligent communication tools

If the above mentioned scheme of an intelligent design shift tool is ap-
plied in a distributed framework which is control by human users the 
system becomes an intelligent communication manager. Unresolved 
problems will be posted back into the system in order for them to be re-
solved by a user (designer) using available resources. The system will 
post its problem to any resource which is able to communicate mean-
ingful about this issue. By using the monitor scheme (see chapter 3.4) 
only these systems able to solve the problem will respond. The in the 
user model fixed responsibility and scope determine which systems re-
spond to a particular problem, i.e. designers or engineers who are work-
ing in a suitable context. Thus, if the system does not possess enough 
knowledge to resolve the problem by itself it communicates to an ap-
propriate designer (resource).


5.3.4	Knowledge structuring

Sharratt (1991) mentions the separation between intelligent interfaces 
and knowledge-based systems as one of the general problems encoun-
tered in his survey.

The knowledge contained in the system has various characteristics. 
Firstly, there are the user-specific items, knowledge about mapping 
which plays a role only for the user who specified it. Further, there are 
tools in the current environment which are generally interesting to all 
users. Every user accesses a certain type of domain knowledge depend-
ing on the area they are working in which aids his work. Finally the 
user employs deep knowledge models in the form of expert systems 
etc. The amount of knowledge which is handled during definition of a 
problem grows quickly and is difficult to manage.

It order to resolve the problems of knowledge management it is sug-
gested that the knowledge is structured hierarchically. Every user pos-
sesses not only his own knowledge base on conceptual mapping but has 
additionally access to several domain knowledge bases. Access can be 
organised either directly by consulting the particular knowledge base or 
by starting on inference machine (knowledge handler) which runs the 
inference and posts the result back to the user.


6	CONCLUSION

In the beginning of this paper it was asked whether the Intelligent front 
end environment is able to support design in terms of recent research. 
Surely, the direct transformation of these research issues into the sys-
tem appears difficult because of the complex nature of the research. By 
developing these issues and relating them to our problem space, valid 
means can be provided in order to support design decision making. 
These strategies need not to be as complex and comprehensive as the 
research issues but are oriented rather towards the fulfilment of our cur-
rent tasks, to apply methods currently available in our software envi-
ronment (and not called by great names such as artificial intelligence 
etc.).

To focus discussion this paper has used energy performance simulation 
as its primary example. The results show that it is possible to establish 
to some extent an intelligent interface within the Intelligent front end 
scheme. Thus, the application in the area of zone use definition for ESP 
simulation is now included in the prototype development of the Intelli-
gent front end supporting ESP. However, the main interest of this work 
is the elaboration of strategies, problems, and suggestions for further 
developments rather than the application of a particular problem itself. 
Strategies and suggestions are shown in section 5. The advances in re-
cent research which were reviewed during the development of these 
strategies provided some useful ideas. In order to apply them in support 
of the application they had to be transferred into the application area by 
including them in the development. Missing in the recent research has 
been the development of aids to help create a well-structured model of 
the design problem as is necessary during application. Research con-
cerning this problem, referring to a product model standard (Bjork, 
Gielingh), has just started.

Beside these issues a general view on the problem space was developed 
during preparation of this paper.

Finding solutions to the following problems is fundamental to the ap-
pearance of the Intelligent front end interface:

1.	Structuring. The elaboration of the common conceptual model is 
	essential to ensure a full problem representation and communica-
	tion within the environment.

2.	User modelling and control. The user models have to be carefully 
	and comprehensively developed considering of the user's goal, 
	his responsibility in the design process, and his familiarity with 
	the environment. A balance of control between user and environ-
	ment must be set according to the user model (more control by the 
	environment in case of a novice users or tutorial system, but more 
	control for the user in the case of an expert).

3.	Knowledge capture. The quality of an intelligent interface de-
	pends on the knowledge it contained. This knowledge has to be 
	comprehensive and accurate.

In order to meet the requirements emerging from these problems an ap-
plication development should contain a preliminary survey concerning 
the following objectives:

o	in which way should the representation and communication of 
	concepts happen in order to ensure equal meaning to different cli-
	ents participating in the design process,

o	how does the user communicate with the product model,

o	how design knowledge (algorithms, simulation, etc.) is accessed 
	by different users during the design process,

o	and how different individual user views are characterised.

Pursuing the solutions to such problems and recent research enables the 
development of an interface that helps users to deal with varying engi-
neer and design vocabulary in a complex design context. To give users 
who are not familiar with computer environments access to the broad 
underlying functionality of comprehensive design tools means to pro-
vide fundamental support of the design process by shifting computer 
technology from the research environment into the professional design 
office environment.


APPENDICES


A	PROGRAM REFERENCE

The following program reference shows the developed part of the Intel-
ligent front end for the support of zone usage definition for ESP simula-
tions. All examples if not stated are the development of the author built 
up upon the current version of the Intelligent front end. The examples 
shown are integrated into the Intelligent front application. The source 
code has been archived by Professor Joe Clarke (ESRU, Department of 
Architecture and Building Science, University of Strathclyde).


A.1	The usage meta-concepts


The definition of zone usage concern has been broken down into the 
following structure. (Fig. 17)

The meta_concepts are implemented in form of forms templates, 
knowledge bases, and scripts.

The files containing the meta-concept mentioned above can be 
found in the Intelligent front end directory (IFE_home) under the user 
conceptualisation engineer (form templates, knowledge bases) or in the 
subdirectories for tools (scripts).


B	REFERENCES

AKIN O
Psychology of Architectural Design
London: Pion, 1986

AYRLE H
XNET2 - Methodogical Design of Local Area Networks in Buildings
In: Proceedings of the CAAD futures `91, edited by Schmitt G
Zurich: ETH Zurich, 1991, pp. 407-414

BALACHANDRAN M, ROSENMAN A, GERO J S
A knowledge-based approach to the automatic verification of designs from CAD 
databases, Working paper
Sydney: University of Sydney, 1990

BARR A, FEIGENBAUM E A
The handbook of Artificial Intelligence, Vol. 2
Los Altos, California: W. Kaufmann, 1982

BIJL A
On knowing - feeling and expression
In: Proceedings of the CAAD futures `91, edited by Schmitt G
Zurich: ETH Zurich, 1991, pp. 143-160

BJORK B C
A proposed structure of a building product model
In: CAD, volume 21, no.2, Feb. 1989, pp. 71-78

BJORK B C
Intelligent Front-ends and Product models
In: Artificial Intelligence in Engineering, volume 6, no.1, Jan. 1991, pp. 46-56

BRIDGES A H
Any Progress in Systematic Design, A revised version of a paper first presented at 
CAD Futures, Delft, 1985
Glasgow: University of Strathclyde,
Department of Architecture and Building Science, 1990

CLARKE J A
Energy Simulation in Building Design
Bristol & Boston: Adam Hilger Ltd., 1985

CLARKE J A, MacRANDAL D, RUTHERFORD J H
The application of Intelligent knowledge-based Systems in Building Design
Glasgow: Final Report for Grant GR/E/18018, 1989

CLARKE J A, HAND J, STRACHAN P, HENSEN J
ESP manual
Glasgow: ESRU, University of Strathclyde, 1991

CLARKE J A
Intelligent Front-Ends for Engineering Applications, Guest Editorial
In: Artificial Intelligence in Engineering, volume 6, no.1, Jan. 1991, pp. 2-5

CLARKE J A, MacRANDAL D
An Intelligent front end for computer aided building design
In: Artificial Intelligence in Engineering, volume 6, no.1, Jan. 1991, pp. 36-45

CROSS N (ed.)
Developments in Design Methodology
Chicester: John Wiley&Sons, 1984

CROSS N
Engineering Design Methods
Chicester: John Wiley&Sons, 1989

COYNE R D, ROSENMAN M, RADFORD A D, BALACHANDRAN M, GERO J
Knowledge-based Design systems
Reading: Addison Wesley, 1990

DOSTER A, WERNER H
Objektorientierte Modellierung einer wissenbasierten Benutzungsoberflaeche im 
konstruktiven Ingenieurbau
In: KI-Forschung im Baubereich, edited by Gauchel J
Berlin: Verlag Ernst&Sohn, 1990

DRACH A, GAUCHEL J, HOVESTADT L
ARMILLA - ein Intelligentes Designwerkzeug fuer die Layoutplanung von 
Leitungsnetzen in hochinstallierten Gebauden
In: KI-Forschung im Baubereich, edited by Gauchel J
Berlin: Verlag Ernst&Sohn, 1990

DYM C L, LEVITT R E
Knowledge-based systems in engineering
New York: McGraw-Hill, 1991

ENGLEMORE R, MORGAN T
Blackboard systems
Reading: Addison Wesley, 1989

FLURSCHLEIM Ch H
Industrial Design in Engineering
London: Springer, 1983

FORSYTH R
Expert Systems - Principles and case studies
Chapman and Hall Computing, 1990

GERO J S (ed.)
Artificial intelligence in engineering: design
Computational Mechanics, 1988

GERO J S, ROSENMAN M A
A conceptual framework for knowledge-based design research at Sydney 
University DCU
In: AI in Design, edited by Gero J S
Springer 1989

GIELINGH W
General AEC Refernce Model GARM
Draft paper of ISO TC 184/SC4/WG1
Delft: 1988

GYALOKAY A
cm - an essay about knowledge-based information systems
Glasgow: Project, University of Strahclyde, 1991

HALLAM J
Blackboard architectures and systems
In: Artificial intelligence: concepts and applications in engineering,
edited by Mirzai A R,
Cambridge, MA: Chapman and Hall, MIT Press, 1990, pp.35-63

HUTCHINGS A M J (ed.)
Edinburgh PROLOG user's manual
Edinburgh: University of Edinburgh, AI Applications Institute, 1986

JONES J C
Design Methods: Seeds of Human Futures
Chichester: John Wiley&Sons, 1980

KALAY Y E
Computability of Design
New York: John Wiley&Sons, 1987

KANT I
Critique of pure Reason (reprint 1781)
New York: Anchor books, Garden City, 1980

KING R
My cat is object oriented
In: Object-oriented concepts, databases, and applications,
edited by Kim W, Lochovsky F H,
Reading, MA: Addison Wesley for ACM, 1989, pp. 23-30

LAWSON B
How designers think
Butterwoth 1990

LOGAN B S
The structure of design problems
Thesis, Department of Architecture and Building Science,
Glasgow: University of Strathclyde,1987

MacRANDAL D
Internal discussion about the development of the Intelligent front end
Glasgow: University of Strathclyde, July 1991

MARCH L
The logic of design
In: Developments in Design Methodology, edited by Cross N,
Chicester: John Wiley&Sons, 1984

MILLER R U (ed.)
Artificial intelligence applications in engineering
SEAI Technical Publications, 1988

MIRZAI A R (ed.)
Artificial intelligence: concepts and applications in engineering
Cambridge, MA: Chapman and Hall, MIT Press 1990

MITCHELL W J
The Logic of Architecture: Design Computation and Cognition
Cambridge, MA: MIT Press, 1990

MUSTOE J E H
Artificial Intelligence and its application in architectural design
Thesis, Department of Architecture and Building Science,
Glasgow: University of Strathclyde,1990

NIERSTRASZ O
A survey of object-oriented concepts
In: Object-oriented concepts, databases, and applications,
edited by Kim W, Lochovsky F H,
Reading MA: Addison Wesley for ACM, 1989, pp. 5-22

PAHL, BEITZ
Engineering Design
Berlin: Springer 1984

PENTTILA H, Bjork B C
Data Structures in Computer Aided Building Design
VTT-Helsinki: 1989

RICH E
Stereotypes and User modeling
In: User models in Dialog systems, edited by Kobsa A, Wahlster W,
Berlin: Symbolic Computation, Springer 1989

RUTHERFORD J H
An intelligent design support environment
Thesis, Department of Architecture and Building Science,
Glasgow: University of Strathclyde, 1990

RYCHENDER M D (ed.)
Expert Systems for Engineering Design
San Diego: Academic Press, Inc., 1988

SCHMITT G
Microcomputer Aided Design for Architects and Designers
Chicester: John Wiley&Sons, 1988

SIMON H A
The Science of the Artificial (2nd edition)
Cambridge, MA: MIT Press, 1982

SHARRATT B
Intelligent interfaces: the IMPACT survey
In: Artificial Intelligence in Engineering, volume 6, no.1, Jan. 1991, pp. 5-22

SHAVIV E, PELEG U J
An Integrated KB-CAAD System for the Design of Solar and Low Energy 
Buildings
In: Proceedings of the CAAD futures `91, edited by Schmitt G
Zurich: ETH Zurich, 1991, pp. 427-443

SRIRAM D (ed.)
Artificial Intelligence in engineering: tools and techniques
Computational Mechanics, 1987

STERLING L, SHAPIRO E
The Art of PROLOG - Advanced Programming Techniques
MIT Press, 1987

VIDOVIC N
Design Framework Toolkits for concurrent Engineering Environments
Pittsburgh: EDRC, Carnegie Mellon University, 1990

WAHLSTER W, KOBSA A
User models in Dialog systems
In: User models in Dialog systems, edited by Kobsa A, Wahlster W,
Berlin: Symbolic Computation, Springer 1989

WINSTANLEY G
Artificial intelligence in engineering
Chicester: John Wiley&Sons, 1990
