A knowledge-based system for automated architectural code checking

A knowledge-based system for automated architectural code checking C L Dym, R P Henchey, E A Delis and S Gonick Recent efforts to develop a knowledge-based expert system capable o f reviewing an architectural design for conformance with the Life Safety Code (LSC) o f the National Fire Protection Association are described. These efforts include the specification o f a frame-based representation of floorplans and the development of a rule-based representation of LSC requirements. The representation was developed to operate on top o f a geometrical database contained in a CA DD system, within which the expert system will be embedded. That part o f the LSC relating to egress requirements and fire protection in hospitals was selected as the particular domain for this prototype. The work reported has implications for the representation o f architectural information in the context of computer-aided design, as well as for the representation of legally mandated code requirements. computer-aided design, architectural design, knowledge-based system

This paper describes some recent efforts to develop a knowledge-based expert system, capable of reviewing an architectural design for conformance with the Life Safety Code (LSC) of the National Fire Protection Association I. This work was performed with the cooperation of a leading hospital architect and of Graphic Horizons Inc, who were interested in enhancing their Graph/Net computer-aided design and drafting (CADD) system with such a knowledgebased capability. The prototype system developed at the University of Massachusetts has been named the LSC Advisor. The system described here combines several different approaches to building expert systems, based on the extensive work in this field over the last several yearsa'3. In the LSC Advisor, symbolic programming (in Lisp) is closely integrated with rule-based and frame-based knowledge representations. One of the novel aspects of the system is its combination of complex geometrical calculations with an accessible, high-level approach to knowledge representation. The potential for a fruitful application of artificial intelligence techniques to architectural design has been explored previously 4. The Build system captured some aspects of an Australian building code in a Prolog-based representation s. The LSC Advisor represents an advance in the automation of architectural design. The prototype LSC Advisor addresses those LSC requirements which are relevant to the construction of new Departments of Civil Engineering and of Computer and Information Science, University of Massachusetts at Amherst, Amherst, MA

01003, USA

volume 20 number 3 april 1988

health care facilities. The requirements for such facilities include many - if not most - of the more general requirements that would be applicable to all types of buildings. Hospitals were chosen as the particular focus for this prototype because of their relative complexity (among all building types), and because a leading designer of medical facilities was willing to make available the expertise of his design team. Thus, because of the complexity and generality of the chosen domain, the expert system developed could serve as a template for similar systems that focus on other facilities such as jails, schools, etc. At the same time, exploiting and encapsulating the enthusiastically offered expertise of a team of experts satisfies one of the more important criteria of task selection and knowledge acquisition 3'6. The scope of the prototype has also been refined by a focus on those aspects of the LSC specifically relating to egress and fire protection features and equipment. Egress requirements specify the type and number of exits, and maximum distances from points in the building to the nearest exit. Fire protection features include, for example, the specification of minimum fire resistance ratings for walls and doors, depending on their location and use. Requirements on fire protection equipment include rules for specifying the number and locations of fire extinguishers and of exit signs. The egress and fire protection requirements were chosen for encapsulation in the prototype because they are central to the LSC and because violations in those areas are among the most expensive to remedy. The first two sections of this paper detail both the codechecking process which the prototype system is intended to automate and the knowledge acquisition phase of the project. The third section outlines the overall design of the LSC Advisor. The remaining sections describe the relevant representation and control issues, outline the travel distance algorithms, and evaluate the extensibility of the system to a more complex architectural c o d e - c h e c k i n g system. The results presented include the specification of a frame-based representation of floorplans and the development of a rule-based representation of LSC requirements. Several algorithms for analysing a floorplan's conformance with specific requirements were also developed.

THE LIFE SAFETY CODE AND A R C H I T E C T U R A L PRACTICE Prepared by the National Fire Protection Association, the Life Safety Code I is a document of hundreds of pages whose purpose is 'to establish minimum requirements that will provide a reasonable degree of safety from fire in buildings and structures'. Its requirements serve as a basis for building codes in many jurisdictions. At various stages

0010-4485/88/030137-09 $03.00 © 1988 Butterworth & Co (Publishers) Ltd

137

in the process of design and construction, and with varying degrees of formality, a new building is reviewed for its conformance with the Life Safety Code (LSC). Considerable expense may be entailed by the discovery of problems of nonconformance during or after construction, or even in the later stages of the design process. This is because it can be quite costly to retrofit a completed building, or revise an essentially completed design, to bring it into conformance with the code. It is both good design practice and economically sensible to consider a building's conformance with the LSC early in the design process, rather than waiting for a formal building inspection just before construction. To some extent this is done informally by the individual architect while the design is in progress. However, the requirements of the LSC are very detailed and vary depending on the exact construction and intended use of the building and its parts. Many architects are not familiar with all these details and lack either the time or the inclination to become familiar with them. Thus, many architects will rely on others, more expert in this area, to review their building designs for them. These experts, themselves usually architects, are relatively few in number and their time is not cheap. In these circumstances, an automated computer system that could expedite the process of reviewing a building design for problems of conformance with the LSC would be of some economic interest. It is also worth noting that a complete conformance review of a design of a complex facility such as a hospital takes as much as three or four man-months. The automation of this process, even to the extent of reducing it to an overnight batch process, as opposed to a real-time interactive process, will thus in itself produce considerable savings in time and money for architectural firms. The encapsulation of this knowledge in an expert system produces still another potential dividend in that the code checking can be done on a consistent and essentially error-free basis.

THE LSC REVIEW PROTOCOL To understand the code-checking process fully, the research team, acting as knowledge engineers, initiated a series of extended meetings with a small group of architects who were experts in the application of building codes, especially the LSC. These knowledge acquisition sessions were conducted in a manner consistent with earlier projects 6 which suggested that multiple experts be used and that the chosen experts be asked to do what they actually did, rather than explain their actions after the fact. In these sessions, one of the architects was presented with a floorplan that he/she had not seen before and asked to perform a review for conformance with LSC requirements, detailing what was being done at each stage. The knowledge engineering team took extensive notes throughout these meetings and then distilled them into a protocol for the LSC review process (see Figure 1). As refined by later discussion with the architects, the protocol provided a framework for organizing the expert system. This section provides an overview of the code-checking process modelled in the protocol. During review of a building design for conformance with the LSC, the architect works through the floorplans in a conventional order, from the basement to the top floor. Detailed drawings and other documents are referred to, as needed, to resolve questions arising from review of the floorplans. Occasionally a question will arise that will

] 38

Establish number of stories, siting, overall shape Establish occupancies Establish and check fire separation zones Establish types of construction Establish egress routes and check width Establish sprinkler presence or absence Establish and check hazardous areas Check enclosure of corridors Check type and number of exits Check travel distances Check for egress to grade Check widths of all doors Establish and check smoke zones Check finishes

FLqure 1. High level protocol for the code-checking process require the architect to trace a building feature from floorplan to floorplan. While it is possible to break the review process into a series of sequential steps, in practice, an architect may notice problems of areas of concern in almost any order. The individual steps in the protocol may thus not be independent and logical dependencies among the steps need to be identified. Generally, the occupancies - or size and type - of different parts of the building must be determined first because the safety requirements vary with the intended use. The division of the building into fire zones, which are separated from one another by wails serving as fire barriers, is generally the next major area of concern. Then egress routes from the building can be identified and their type, number, width and length can be checked against requirements. Other areas of concern include the enclosure of hazardous areas with fire barriers, the containment of smoke with smoke barriers and the use of appropriate finishes on corridor walls. The review process has three basic procedures that are repeatedly applied to different areas of the building and to different aspects of the design. They are: • identification of the parts of the building • selection of applicable provisions of the LSC • application of those provisions to a particular situation For example, an element of the design will be identified as a mechanical shaft forming a vertical opening in the floor or an area of patient bedrooms in a hospital. The expert will then select as applicable, a paragraph of the LSC specifying enclosure of such openings by walls with a twohour fire rating. Finally, the expert will apply that paragraph to this particular mechanical shaft by checking the fire ratings of all the wails enclosing the shaft. As noted above, the prototype LSC Advisor is mainly concerned with egress routes and fire protection features, but these are necessarily related to questions regarding occupancy, the presence of particular equipment such as sprinklers and exit signs, and the type of construction.

OVERALL DESIGN OF LSC ADVISOR The LSC Advisor is intended to function in concert with an architectural CADD system. (In fact, as noted above, the LSC Advisor was implemented to operate with designs

computer-aided design

Life Safety Code Violation for the Building: Sprinklers are required and need to be added. Detailed Life Safety Code Violations for Building: **Note: Sprinklers were assumed to be present.** Object

Description

STORYI

Exit doors not remote enough (85.0 < 90.60905 feet).

FRZN91 FRZN91 FRZN91 FRZN91

FRZN102 Fire rating Fire rating Fire rating

FRZNI02 F RZN 102 F RZN 102

Exit doors not remote enough (11.18034 < 40.804413 feet) Fire rating of wall opening too low: DOOR85 Fire rating of wall too low: WALL11

ROOM2000 ROOM2000 ROOM2000 ROOM 180 VERTICAL_OPEN ING3

Room > 1000 sq ft needs more than 1 exit access door. Inroom travel distance 50.91169 > 50.0 feet at (2 70). Should have 2 qualified egress door(s). Only has 1. Fire rating of wall opening too low: DOOR89 Fire rating of the wall opening too low: DOOR84

CORRIDOR1 CORRIDOR2 CORRIDOR2

Corridor too narrow (6.0 < 8.0 feet) at (1.30.0 112.0) Corridor too narrow (6.0 < 8.0 feet) at (46.0 104.0) Corridor too narrow (6.0 < 8.0 feet) at (46.0 64.0)

WALL79 WALL68

Fire rating should be 2 hours. Actual rating: I Fire rating should be 2 hours. Actual rating: I

DOOR86 DOOR154 DOOR153 DOO R1000 DOO R1000

Vision panel required for horizontal exit. Door swings 1.0 feet too far into CORRIDORI. Door swings 1.0 feet too far into CORRIDORI. Max legal distance to exit = 150.0 feet. Actual = 182.0 Leaves of patient room must be ~> 44.0 inches: 42.0 in.

CORRIDOR_NODE978 CORRIDOR_NODE985 CO RRI DOR_ NODE1001 CORRIDOR_NODE999

Dead end of 56.0 feet > allowed 30.0 feet. Dead end of 126.0 feet > allowed 30 feet. No exit sign visible from this point (]08.0 118.0) No exit sign visible from this point (43.0 72.0)

not large enough to serve as area of refuge. of wall opening too low: DOOR79 of wall too low: WALL66 of wall too low: WALL79

Figure 2. Typical floorplan conformance report produced within the Graph/Net environment.) After a building design has been developed using the CADD system, the LSC Advisor assists the architect in making sure that the floorplans are consistent with some of the more important fire safety regulations. The primary input to the LSC Advisor is a file (knowledge base) that contains information describing a single floor of a building. The primary output of the system is a list of aspects of this floorplan that do not conform to requirements of the LSC. An example of such a list is displayed in Figure 2. The processing performed by the LSC Advisor can be divided into two main phases: a precalculation phase and a code application phase. The precalculation phase makes extensive use of algorithms written in Lisp and of 'if/then' rules that are fired with a forward-chaining strategy. The code application pllase uses only rules so that the applications of the LSC will be transparent to the user. In the precalculation phase, measurements on the floorplan are made and certain implicit relationships among floorplan objects are made explicit. For example, travel paths from rooms to exits are determined and their lengths are measured. The creation of links between fire zones and the rooms they contain is an example of making explicit a relationship which, at the start of processing, was only

volume 20 number 3 april 1988

implicit in the coordinates of the objects involved. The results of the precalculation phase are stored in memory as additional frames, slots and slot values in the same knowledge base that holds the original input data. In the code application phase, the rule interpreter is instructed to apply all appropriate rules to the facts that have been accumulated in the floorplan knowledge base. Most of the rules correspond directly to a requirement stated in a paragraph of the LSC. Where a problem is found, the 'then' clause of a rule places a string describing the problem in a special slot of the object involved. For example, the string 'Firerating of 1.5 hours too low, should be > 2 hours' might be attached to a frame representing a wall. These strings form the basis of the list that is the output at the end of the code-checking process. It has already been noted that the LSC review process can be thought of as having three distinct aspects: identification of building elements; selection of applicable requirements; and application of selected requirements. It is important to understand how these three activities have been addressed in the design of the LSC Advisor. For the most part, the identification problem has been left up to the user of the CADD system that acts as the front end to the LSC Advisor. The CADD system user must explicitly identify the floorplan's different elements, i.e.

139

the rooms, doors and walls. This can be accomplished partly by using specialized drawing functions provided by the CADD system and partly by following certain conventions with regard to the use of symbols and the organization of the floorplan into layered drawings. The user must also select room labels from a special list so that occupancy can be properly determined. This should allow an automatic translation of the CADD database into the framebased representation of the floorplan that the LSC Advisor can analyse. The process of selecting applicable requirements from the LSC is handled mainly by putting the necessary clauses into the antecedents of the rules that represent the LSC requirements. It is also handled implicitly in the chosen knowledge representation in a way that facilitates the handling of objects as groups. This is done by representing all objects of the same types as instances of a class, e.g. all rooms are instances of the class ROOMS, all doors are instances of the class DOORS, etc. The application of requirements to particular building elements is also implemented by the insertion of appropriate clauses in the rule antecedents. Many aspects of the application of LSC requirements have been implemented through algorithmic procedures in the precalculation phase. For example, travel distances are measured in the precalculation phase. However, the determination of the required travel distance and the comparisons of the actual distances to those specific requirements are performed by rules in the code application phase. The precalculation phase also contributes to the process of identifying building elements when it makes explicit certain relationships that are only implicit in the original input data. An example is the determination that a particular door provides a means of egress from a particular space. This fact is determined by a Lisp-based geometrical procedure and made available to the rule interpreter through the frame system. The firm integration of a rule-processing system with a frame system is crucial to the success of this approach since a common data structure allows the sharing of data, or facts, among both rule-based and algorithmic procedures. As a consequence of the desire to integrate rules, frames and algorithmic procedures, the prototype LSC Advisor was implemented in Intellicorp's Knowledge Engineering Environment (KEE). The hardware platform was the Texas Instruments (TI) Explorer I workstation.

LIFE SAFETY CODE REPRESENTATION As noted previously, many of the requirements of the LSC are represented in the LSC Advisor in the form of 'if/then' rules. Paragraph by paragraph, the text of the LSC is translated, as directly as possible, into the language recognized by the rule processor. Paragraph 6-2.2.51 will serve as an example of the translation of text into a rule. It reads: 'Every opening in a firebarrier shall be protected to limit the spread of fire and restrict the movement of smoke from one side of the fire barrier to the other. The fire protection rating for opening protectives shall be as follows: (a) 2-hour fire barrier - I and Y2 hour fire protection rating; (b) l-hour fire barrier - I hour fire protection rating when used for vertical openings or ~ hour fire protection when used for other than vertical openings.'

140

Part (a) has been translated as: IF:

(AND

THEN: (AND

(?ZONE IS IN CLASS FIRE_ZONES) (THE REQUIRED_ENCLOSURE_RATING OF ?ZONE IS 2) (THE BOUNDARY OF ?ZONE IS ?WALL) (THE WALL_TYPE OF ?WALL IS INTERIOR) (AN OPENING OF ?WALL IS ?OPENING) (LISP ( < (THE RATING OF ?OPENING/ 1.5))) (A LSC_PROBLEM OF ?ZONE IS "FIRE RATING OF WALL OPENING TOO LOW: ?OPENING" (A LSC_PROBLEM OF ?OPENING IS "FIRE RATING SHOULD BE 1.5 HOURS. ACTUAL RATING: ?RATING"))

The first clause focuses attention on fire zone objects in the knowledge base. The second clause further focuses attention on those fire zones that have required enclosure ratings of two hours. The next three clauses retrieve data about the walls of the fire zones and the doors (?OPENINGS) within these walls. The sixth (and last) clause compares the fire resistance of the doors with the minimum legal rating of 1.5 hours. The value of the REQUIRED_ ENCLOSURE_RATING slot will have been determined by the previous firing of other rules. The doors are in violation of Paragraph 6-2.2.5 if their fire rating is less than 1.5 hours. One (early) implementation of the LSC Advisor incorporated the logic of the LSC requirements in the same Lisp functions that perform the necessary measurements or calculations. However, a rule-based representation proved to have several advantages. One advantage is mainly organizational: the LSC requirements are kept separate from a description of how to measure them, allowing these issues to be cleanly separated during both development and validation. A related advantage is that the rule-based representation encourages the developer to keep the representation of any particular requirement at the same high level of abstraction that appears in the original text. Also, it is easier to understand when a particular requirement will be enforced if all the preconditions for the firing of a rule are in one place (as opposed to having the logic spread out through multiple computer programs). However, all the advantages just mentioned are really subsidiary to the more general point that the rule-based representation of the LSC is expected to be easier to maintain over time. The use of a pseudo-natural language for expressing the rules also opens up the possibility of more direct participation by a domain expert in the development and testing of the system.

FLOORPLAN REPRESENTATION This section provides an overview and rationale for the flame-based representation of floorplans used in the LSC Advisor. Complete details of the floorplan representation are available in the LSC Advisor Programmer's Manual 7. The floorplan representation developed for the LSC Advisor is intended to: •

facilitate description of all the objects in a typical fioorplan or blueprint • enable reasoning about these objects in the context of analysing and applying the LSC • provide an economic and efficient implementation for these descriptive and reasoning tasks Inasmuch as the typical objects in a floorplan (e.g. fire zones, rooms, doors, walls, etc.) are fairly abstract, a rulebased approach in and of itself would not provide an adequate representation. This is because rule-based systems typically do not provide a way to describe objects with a

computer-aided design

Table 1. Frame representation for an instance of the class FIRE_ZONES Slot

Value

CORNER

(# # # #

EXTERIOR_NODES

[Unit [Unit [Unit [Unit

: CRNR99 BUILDINGS] : CRNR104 BUILDINGS] : CRNR94 BUILDINGS] : CRNR32 BUILDINGS])

( # [Unit #[Unit # [Unit # [Unit

: CRNR97 BUILDINGS] : CRNR102 BUILDINGS] : CRNR92 BUILDINGS] :CRNR37 BUILDINGS])

GROSS_AREA

(2408.0)

OCCUPANT-LOAD

(6200.0)

SUBSPACES

(ROOM180 ROOM151 ROOM152)

ZONE_CORRIDORS

(CORRIDORI CORRIDOR2)

ZONE_DOORS

(DOOR79 DOOR86 DOOR89 DOOR88 DOOR155 DOOR154 DOOR153 DOOR90)

ZON E_ EX ITS

(DOOR79 DOOR86)

ZONE_EXIT_SIGNS

(EXIT_SlGNI EXIT_SIGN3 EXIT_SIGN4)

REQUIRED_ENCLOSURE _ RATING

1.5

NET_AREA

(1956.0)

LSC_ PROBLEM

Nil

Table 2. Frame representation for an instance of the class WALLS Slot

Value

CORNER

(#[Unit:CRNR113 BUILDINGS] #[Unit:CRNR112 BUILDINGS] # [Unit : CRNR139 BUILDINGS] # [Unit : CRNR138 BUILDINGS])

WALL_TYPE

Interior

RATING

2.0

LSC_PROBLEM

Nil

WALL_OPENING

(DOOR153)

large number of often complex attributes. Thus, in the tradition of object-oriented programming 2'a-11, a framebased representation was used for the floorplan and its attendant objects. In a frame system, a single frame can be used to describe a single object and its attributes. Since many objects are similar both in their attributes and the way that these attributes are calculated or otherwise obtained, it is useful to think in terms of 'classes' of objects, these classes can then have both 'subclasses' and 'superclasses'. In such a frame representation, subclasses 'inherit' all the attributes of their superclasses (or parent classes). For example, in the present domain, the superclass SPACES is used to organize building stories, fire zones, smoke zones, rooms and corridors. All members of the class SPACES have the same general attributes: DOORS, NET_AREAS, GROSS _ A R E A S , BOUNDARY_WALLs, and a R E Q U I R E D ENCLOSURE_RATING. Rooms are then defined in this representation as having all the attributes of spaces plus

volume 20 number 3 april 1988

Table 3. Frame representation for an instance of the class DOORS Slot

Value

CONNECTED_SPACE

(ROOM105 CORRIDOR3)

CONNECTIONS

(CORRIDOR_NODE6])

COORDS

((39 30))

RATING

2.0

SWINGS_INTO

(CORRIDOR3)

LSC_PROBLEM

Nil

TRAVEL_DIS_TO- EXIT

(39.0)

WALL

( # ]Unit: WALLI03 BUILDINGS)]

EXIT-PATH

(DOORI04 CORRIDOR_NODE45 COR RI DOR_ NODE43 CORRIDOR_NODE47 DOOR86)

attributes that are specific to rooms alone (e.g. INROOM _TRAVEL_DISTANCE, NUMBER_OF_REQUIRED _ EX ITS, etc.). The rule displayed in the previous section (derived from Paragraph 6-2.2.5 of the LSC) contains an implicit example that can be used to illustrate how a frame representation enables reasoning about symbols or objects. That rule is concerned with the fire resistance rating of a door in a wall intended to serve as a fire barrier. Given that a floorplan contains thousands of objects, it is obviously important that its representation should facilitate rapid and efficient identification of the door(s) in question. How does this happen here? The process begins by the identification of all 'instances', or specific cases, of fire zones that are direct descendants of the class FI RE_ZONES (see Table I). This could be a list of objects with between two and five entries. As the class FIRE_ZONES is itself a subclass of the class SPACES, it has a 'slot' for the attribute BOUNDARY which lists all the walls that make up the boundary of the fire zone. This list of walls, with anywhere from four to 30 entries, is used first to eliminate exterior walls from the list. This is done by excluding those with the value EXTERIOR in their WALL_TYPE slot. Now, the class WALLS (see Table 2) contains the slot W A L L _ OPENING which holds all the DOORS (see Table 3) in a given wall, so that it is possible to identify all of the specific doors to which Paragraph 6-2.2.5 applies. The RATING slot of each door so identified can now be examined and the relevant rule applied. The 'inheritance lattice' that is used in the LSC Advisor to represent the various kinds of objects (and their classes, etc.) that can occur in a floorplan is displayed in Figure 3. The class frames are organized into a single hierarchy of subclasses of the class of FLOOR_PLAN_OBJECTS. Examples of subclasses of F L O O R _ P L A N _ O B J ECTS are WALLS, ROOMS, CORRIDORS, and EXIT_SIGNS. A subclass in the LSC Advisor has all the slots of its superclasses, as well as some more slots which are applicable to it but not to other subclasses of the superclass. The only slot which all the objects have in common is LSC_ PROBLEM, which is defined in the F L O O R _ P L A N _ OBJECTS class frame. One of the immediate subclasses of FLOOR_PLAN_OBJECTS is NODES, which defines a COORDS slot for storing a single (x,y) location. The subclasses of NODES include CORNERS and EXIT_SIGNS.

141

FLOOR_PLAN_OBJECTS I

I I F,Xt . s I I [ EX'T-S'GNS 'l

I

I

i,WALL_OPEN'NGS I [C,OnRIDOR_NODESI

IcoR/ERsl

I I IW'NDOWSl

I

[ VISION-PANEL I

I

[SP,~ "ES I

[ PARTITIONS I

I wA''J°'"Ts

I VmTUAL-WALLSl

I

I I STORIESI I

1

I VERTICAL OPEN'NGS-II

I

IHAZARDOUS I lARVAS -I

I

I F'RE-ZONEsl

l

ISMOKE_ZONEsl

Figure 3. Inheritance lattice for the floorplan representation One significant advantage of this hierarchical representation of the different types of objects in a floorplan is that general operations can be defined on a superclass. These operations will then work correctly on any object that is an instance of one of its subclasses. For example, a generic Lisp function that requires access to a COORDS slot can be defined for the superclass NODES; it will then work equally well, and without modification, for instances of CORNERS and EXIT_SIGNS. The attachment of a Lisp function to a slot of a superclass and its activation by message passing is an example of method inheritance in the tradition of object-oriented programming 1°. Additionally, many of the same economies can be derived when the operations are defined separately from the objects, either Lisp source files or in the form of 'if/then' rules.

TRAVEL DISTANCE ALGORITHMS The precalculation phase of the LSC Advisor includes numerous algorithms needed to check a design's conformance with specific LSC requirements. The most interesting (and complex) are those which measure travel distances between points in the building and the building's exits. These are outlined briefly in this section. The LSC sets maximum limits on the travel distances from the doors of rooms to the nearest exit. Such limits are here referred to as corridor travel distances. The LSC also sets maximum limits on the distance from points in a room to the nearest door that leads into a corridor. Additional requirements set maximums for the sum of the inroom and corridor travel distances. The LSC specifies that corridor travel distances must be measured along the centreline of the corridor. Thus, a significant part of the travel distance algorithm is devoted to tracing the centrelines of corridosr. This is accomplished by (geometrically) projecting points from one side of the corridor to the other to form line segments and then taking

142

the midpoints of the segments to be points along the centreline of the corridor. This procedure gives reasonable results for any corridor of polygonal shape. As a preliminary to forming the centrelines of the corridors, the two ends of the corridor must be identified. This is not trivial in an irregularly shaped corridor. The pair of corridor walls whose midpoints are most distant from one another are taken to be the ends of the corridor. The distance involved is not a simple geometrical distance; rather, it is the distance along the shortest path through the interior of the corridor. To compute this shortest path a connected graph (see Figure 4(a)) is formed of points along the edge of the corridor that are visible from one another (in the sense that a line from one to the other does not cross any of the corridor walls). Then, a carefully optimized depth-first search of the connected graph is used to identify the shortest path (Figure 4(b)) between each pair of wall midpoints. Once all the corridors' centrelines have been formed, another connected graph is formed of nodes representing the building's exits, the doors for each room, and points along the centrelines of the corridors. A shortest-path algorithm determines the shortest distance from each room's doors to the nearest exit. Finally, each room must be examined to see if any points in it are too far from its doors. Points along the edge of the room that are visible to one another are connected into a graph as was done for corridors. In many cases, it suffices to check the travel distances from the doors to each corner of the room. However, in some rooms with multiple doors, points along a wall may be further from the doors than any corner. The algorithm detects when this may be the case and recursively creates additional points to check until either an excessively distant point is found or it can be determined that no such point

exists. The results of these algorithms are stored in the frame

computer-aided design

I a

b

Figure 4. Connected graph and shortest path for corridor travel distances system where they are available for evaluation by the rules that determine what the LSC travel distance limits are for each room.

CONTROL ISSUES The LSC review process is to a large extent amenable to implementation as a series of steps that follow one another in an order determined by a standard protocol. The precalculation phase consists of a set of Lisp algorithms and some 34 precalculation rules derived from the LSC. These precalculation rules are used with the algorithms to provide additional information for the floorplan representation. They represent requirements needed by the code application rules, but they do not themselves flag code violations. The code application phase has also been implemented using a set of rules. The collection of some 36 rules in this phase, however, are then fired with a forward-chaining strategy to identify and flag code violations. This partitioning of phases, algorithms and rules has resulted in a prototype system with more than adequate performance. Despite the apparent simplicity of the result, significant effort has gone into achieving an acceptably fast system. Much of this effort has of course been directed towards the specific geometric algorithms used in the precalculation phase. However, some more genera] techniques that were tried and rejected should be reviewed here. An early version of the system used backward-chaining to control the application of the rules. Simply switching to a forward-chaining strategy made a dramatic improvement in the speed of the system. That early version of the system also made extensive use of demons to do much of the processing that is now done in the precalculation phase. When a value of a slot was needed to determine if a particular rule should fire, a Lisp function was activated to calculate the slot value for the particular object in question. Switching to a strategy in which all slot values were precalculated for all objects before the rule system was started up also contributed to a reduction of the overall processing time. It turns out in the LSC Advisor that nearly all the slot values for all the objects in the floorplan, of which there are some 2000, need to be calculated before the process is complete. Thus, the 'on-demand-only' nature of demons provides absolutely no leverage in this situation, and so the cost of demon processing is avoided here altogether. Additionally, and probably most significantly, efficiency was

volume 20 number 3 april 1988

gained by processing objects in groups rather than as individual objects. Another reason, albeit not the major one, that precalculation has proved more efficient than demons in this situation is that paging could be avoided by applying the same piece of code to a large number of related objects in a tight loop, rather than interspersing calls to other routines. Neither of the aforementioned rationales would apply, however, if slot values needed to be calculated for only a small number of the objects. The basic reason for this is that the LSC review process is really an exhaustive search for any possible problems in the building design. All objects on the floorplan must be checked for every problem they could possibly have. This is quite a different situation from a typical diagnostic task in which search is guided by a few symptoms or complaints. The need for exhaustive search also explains why the goaldirected processing of a backward-chaining strategy, with its higher overhead, did not pay off. A goal-directed search through a knowledge base is useful when a single or best result is desired. In this case, however, all problems, however minor, must be found. This evaluation may be biased by the fact that the prototype system focused on one particular type of occupancy, hospitals, and its associated requirements. A more goaldirected approach to control could prove useful if the different types of occupancies have requirements relating to building attributes that must be measured or calculated in unique ways. However, experience to date indicates that, for the most part, different occupancies simply have different specific requirements relating to a common base of attributes that are measured in a standard way. This perception is reinforced by the fact that the text of the LSC is itself organized into a few general chapters that apply to all occupancies, followed by individual chapters that provide more detailed or more restrictive requirements for each occupancy. Thus, it is more likely that in the more general case forward chaining would still be used, but together with meta-rules that would be used to activate rule classes for the different occupancies.

A U N I F Y I N G DATABASE It should be noted that the floorplan information represented in the LSC Advisor goes well beyond the purely geometric data that is the province of the typical blueprint. Typically, detailed information on construction

143

Patient

d Laboratory

LJ

P

Stairway

n I

Patient bedroom

,

13

Wait

Elevator

Patient bedroom

L ~

bedroom

1

Lockerroom

Figure 5. Representative floorplan examined by the LSC Advisor materials, wall finishes, and product names for prefabricated items must be obtained by reference to other documents, either detailed drawings or materials lists. However, since information from all these sources is needed for detailed LSC review, a representation that could unify these diverse types of information had to be developed. Unifying this diverse data with a single representation represents a significant step forward beyond most of the CADD systems used by architects today, in which there are no unified databases for materials and floorplans. In the original version of the Graph/Net system, on top of which the LSC Advisor was built, there were unique identifiers in the materials or finishes databases and individual records for objects such as doors and rooms. Floorplans, however, were generated by use of a drawing program which maintained a separate database of lines, arcs and text strings. This graphical database contained no explicit indication, for example, as to which lines were meant to be understood as representing the two sides of the same doorway. This information is (subconsciously) deduced by the architect looking at the complete drawing, based on general knowledge about how to interpret blueprints. Conversely, while materials and finishes databases may contain some dimensional information, they typically contain no information about the positions of objects relative to one another. While developing a computer system which could auto-

144

matically recognize the individual elements of a standard floorplan by interpreting the patterns of lines, arcs and text strings would be an interesting and challenging task, it was not the problem addressed here. Therefore, as input to the LSC Advisor, a floorplan representation has been specified in which geometrical information is explicitly related to high-level objects such as walls and doors, requiring that the architectural CADD system provide such a unified description of the building. Development is underway of a new version of Graph/Net which will have this capability. EXTENSIBILITY

The prototype LSC Advisor can complete egress and fire protection analysis of a representative floorplan (see Figure 5) in about one hour on either the TI Explorer I or the Sun 3/160. Thus, the performance of the current system on the representative floorplan is encouraging, but testing on a larger version of the LSC Advisor (with, say, 200-300 rules) is necessary. An interface between the LSC Advisor and Graph/Net is being developed to make this possible. The prototype LSC Advisor incorporates the requirements of several dozen paragraphs out of a document that has several hundred pages. While these paragraphs were carefully selected to capture some of the most important

computer-aided design

and representative LSC requirements, the extensibility of the system to accommodate a more substantial portion of the LSC is clearly something of an open question. There are three main issues regarding the extension of the system to encompass more of the LSC. One is the degree to which growth of the rule base degrades system performance. An estimate of this effect should be possible after the addition of a modest number of new rules. A more difficult question concerns the labour-intensive nature of the knowledge engineering effort. The most time-consuming part of the development process has been the specification of an appropriate representation in terms of frames and slots, and the development of geometric algorithms to fill in some of the slot values. Once a convenient representation for the needed information is available, the translation of text into rules is fairly readily accomplished. This leads to the conclusion that extending the prototype to cover similar requirements for other occupancies should be relatively easy. However, extending the system to analyse aspects of the building design that are not currently captured in the floorplan representation may take considerable effort, depending on the magnitude of the requisite changes in the representation. The third issue regards the availability of data for analysis by the LSC Advisor. Many of the paragraphs of the LSC specify requirements that concern details of objects that do not show up on a floorplan. Requirements concerning the construction of ceilings and floors is an example. The knowledge base of the LSC Advisor would have to be expanded to incorporate information from other types of drawings to handle those parts of the LSC. A related issue is the incorporation into the system of three-dimensional spatial reasoning so as to accommodate considerations driven by interactions between floors. Such interactions are caused by stairways and elevator shafts, ventilation and plumbing runs, proximity requirements, and so on. The extension of the LSC Advisor to three dimensions would require significant effort.

CONCLUSIONS This paper has described the development of a knowledgebased expert system that examines a hospital floorplan for conformance with some of the key provisions of the Life Safety Code of the National Fire Protection Association. Thoughtful approaches to the representation of the floorplans and of the LSC requirements were critical to the success of this prototype. The question of the precise degree of extensibility of the system is the main outstanding research issue. Due to considerations of data availability and the labourintensive nature of knowledge engineering, a system that can check a complete building design for conformance with all LSC requirements is clearly a long way off. The usefulness in the real world of an extended LSC Advisor will depend on the existence and identification of some reasonably compact subset of the LSC requirements that cap-

volume 20 number 3 april 1988

tures in the design process a large percentage of the LSC's potential economic impact.

ACKNOWLEDGEMENTS The authors are pleased to acknowledge the contributions of Clifford D Stewart, AIA, our leading domain expert, and Mary M Cancian of Graphic Horizons, Inc, who was instrumental in grounding us to the realities of Graph/Net and its applications. Financial support was provided by Graphic Horizons and by Amerinex Artificial Intelligence, Inc, Amherst, MA, USA.

REFERENCES 1

Lathrop. J K (ed) Life safety code handbook 3rd edition, National Fire Protection Association, Worcester, MA, USA (May 1985)

2

Bobrow, D G, Mittal, S and Stefik, M J 'Expert systems: perils and promise' Comm. ACM Vol 29 No 9 (September 1986) pp 880-894

3

Dym, C L 'Issues in the design and implementation of expert systems' Artificial Intelligence for Engineer-

ing Design, Analysis and Manufacturing Vol 1 No 1 (December 1987) pp 3 7 - 4 6

4

Gero, J S, Radford, A D, Coyne, R and Akiner, V T 'Knowledge-based computer-aided architectural design' in Gero, J S (ed) Knowledge engineering in computeraided design Elsevier Science Publishers BV (NorthHolland) 1985

5

Rosenman, M A, Gero, J S and Oxman, J 'An expert system for design codes and design rules' in Sriram, B and Adey, R (eds) Applications of artificial intelligence in engineering problems Vol II Springer-Verlag (1986)

6

Mittal, S and Dym, C L 'Knowledge acquisition from multiple experts' AI Magazine Vol 6 No 2 (1985) pp 32-36

7

Henchey, R P and Gonick, S Documentation for the LSC Advisor Graphic Horizons, Inc, Cambridge, MA, USA (September 1987)

8

Goldberg, A and Robson, D 5malltalk-80, the language and its implementation Addison-Wesley, Reading, MA, USA (1983)

9

Bobrow, D G and Stefik, M J 'Perspectives on artificial intelligence programming' Science Vol 231 (28 February 1986) pp 951-957

10 Stefik, M ] and Bobrow, D G 'Object-oriented programming: themes and variations' AI Magazine Vol 6 No 4 (1986) pp 40-62 11 Wegner, P 'Varieties of object-oriented programming' Technical Report No CS-86-25 Brown University Department of Computer Science (December 1986)

145