- Email: [email protected]
Architecture of an expert-system-based code-compliance checker
Architecture of an expert-system-based code-compliance checker V i c t o r E. S a o u m a and S a u r i n e M . Doshi Department of Civil Environmental and Architectural Engineering, University of Colorado, Campus Box 428, Boulder, CO 80309-0428, USA M i c h a e l Pace US Army Corps of Engineers, Waterways Experiment Station, Vicksburg, MS, USA (Received December 1988)
ABSTRACT This paper reports the development of an expert-system-based code-checking framework which 'certifies' compliance of a design with appropriate code provisions. As a 'test-bed' for this prototype, reinforced concrete design compliance with most of the ACI-318 code provisions (found in Chapters 8 to 12 of Reference 1)is selected. A comprehensive and user-friendly framework is developed through various modules. First initial data entry is performed either interactively during the consultation, or through a spreadsheet (Lotus 123) input. Then consultation with the knowledge based expert system is greatly enhanced by a powerful user interface with such capabilities as: arbitrary provision checking, display of code provision, and editing of input data. Finally a report summarizing the consultation (including the original input data, tabulation of the most relevant internally-computed variables, and list of code provisions which are either satisfied or violated) is generated. The knowledge base development resulted in both a critical evaluation of the code, and the generation of an exhaustive tree representation of the rules and design variables. It was found that this initial prototype could be of practical engineering relevance, that its architecture could be adopted for applications other than the one used, and finally that it could serve as an initial configuration for a quality assurance program for design in general. INTRODUCTION In most, if not all, engineering and technical disciplines the designer is confronted with the task 0952-1976/89/010049-0852.00
© 1989PineridgeLtd
of certifying the compliance of a given design with prevailing codes. A professional engineer (PE) may need to verify a design before he/she can legally sign a set of drawings, a plumber may need to verify that a certain installation complies with city regulations, or an engineer hired by a lawyer may be searching for evidence of malpractices in possible code violations during court litigations. In each one of those cases, the engineer would like, ideally, to check all appropriate code provisions. As we all know this can be a formidable task, which could greatly benefit from automation. Thus, through the proper implementation of such an automated procedure for code checking, a Quality Assurance program could be developed. Formal representation of design standards can be traced back to some of the pioneering work of Fenves 2 in which Decision Logic Tables (DLTs) were first introduced. DLTs have been subsequently used by Fenves et al. to represent the AISC code, and by Noland 3'4 to represent the ACI-318 code. Processing, DLTs required a special driver, such as those originally written by Goel and Fenves 5, or Lopez. In a recent work Garrett 6 used a DLT representation of the AISC code as a module in a steel structures design program. While DLT representation of design codes remains a very attractive approach, its main disadvantage is that it requires special 'drivers' for actual code checking. Those drivers have been developed for mainframe computers, and can be quite expensive to acquire/operate. In recent years, the pre-eminence of DLTs for code checking has been overshadowed by the 'explosion' of workstations, and PC-based expert system shells (whose conceptual roots could be traced back to DLTs). As knowedge based expert systems have been extensively used in numerous recent engineering applications, no description of expert systems will be undertaken in this paper, other than to mention that expert systems operate on ill-structured, non-deterministic, qualitative information (such as codes). This is to be contrasted with the quantitative algorithmic knowledge with which engineers have been for too long accustomed. Expert systems can be broadly subdivided into two categories: those using a forward-chaining, and those using a backward-chaining inference process. While the former is well suited for design purposes, the latter is known to be more appropriate for diagnostic purposes such as code verification. Expert systems for code verification have already Eng. Appli. of AI, 1989, Vol. 2, March
49
An expert-system-based code-compliance checker." V. E. Saouma et al.
been used to Rosenman 7's who developed a prototype to test the feasibility of representing the Australian Building Code System in a knowledge base.
v t~ t=--v ~ i ~ n tim
i, th. l.~,.~ *~. r sho~.s~ sl.an?
I
II~Ku t iii i
I~ lwt4Pl~al sl-.~tttt.al p4wtll d l ~ l l l l e d t o ~lst t h s totall l a t 4 l ~ l I o ~ l s ?
OVERVIEW OF SYSTEM Having found that the intellectual process by which an engineer verifies compliance of a design with a given code provision closely parallels the backwardchaining inference process, an expert-system-based approach was selected for code validation. As a test-bed for our implementation, reinforced concrete design validation with the ACI-318-87 code 1 was selected. More specifically, major portions of Chapters 8 to 12 were identified, and a knowledge base developed accordingly. At this stage it should be pointed out that our overall approach to the problem is quite general and is by no means restricted to the concrete design example selected. To properly exploit the expert system shell, while its intrinsic limitations are accounted for, the overall system was broken into three interconnected modules, as shown in Figure I.
I
I" m
r,----!. ~
,.,~T - OUIIq~A~T
IIn
-
uliq~
Figure 1 Overall system
50
architecture
Eng. Appli. of AI, 1989, Vol. 2, March
1.3 s~xlmm r ~ t l o a ( ~ t =lder~?
to txlal
1o~ c-
we=
tlw N r v l c ; e loads In ~ o ~ k l v , c e ultl~r" II'-Q I
Figure 2
Example o f a s p r e a d - s h e e t entry
1. A spreadsheet preprocessor for data entry. 2. The knowledge base and user-interface for data processing, and actual checking. 3. A postprocessor to organize and summarize the consultation results.
Preprocessor for data entry Following field testing of the first program prototype, it was found that there was a general reluctance to use it in light of the excessive amount of data the user would have to supply to the expert system (ES), interactively through its user-interface. As such a preprocessor for data entry was developed, it was found that a spreadsheet could provide an ideal environment for this task, as the user can easily overwrite listed default values which differ from his/her current design in the spreadsheet cells. During data presentation, the variable definitions are listed in column A, default entries in column B, and the legal range of responses in column C, as in Figure 2. Following completion of the 220 entries, the contents of column B are simply printed into a disk file. Subsequently a cache generation program (123TOM1) would read this ASCII file, into a dummy cache which would be loaded by the expert system shell. By loading this file, the ES would thus find all the variables it needs for code verification, and will not need to request information from the user. Selection of this form of data entry is optional, and is recommended only for those consultations in which all code provisions are to be verified. As will be shown below, this is one of three possible options for consultation.
An expert-system-based code-compliance checker: V.E. Saouma et al.
User interface and knowledge base processor In our implementation, both the user interface and knowledge base are 'coded' within MI*, and will be addressed separately.
bdlt b I R mupql,h
~
ll,,-==~
im~ ¢mevwmw {Pmelo{Im
lii~ lqbllqiow Iko~ios
M H h N W hta NuOm) WU.,8 , q , ~ MJPI.
User-interface As its name implies, the user-interface controls all communication between the inference engine and the user. The user-interface is primarily responsible for two essential tasks: F
1. Data entry, and explanation. 2. Operation support.
( V A R I A B L E - N A M E ) , which poses the question to the user when a specific query (for variable-name) is to be made by the system. 2. LEGALVALUE(VARIABLE-NAME),which provides a set of legal entries by the user. This can be a lower and upper bound for numerical values (integers and/or reals), or a limited set of textual responses. 3. E X P L A N A T I O N ( V A R I A B L E - N A M E ) , which provides additional explanation for the user should he question the need for the system to have a particular variable defined (that is if he responds with a why). 1. Q U E S T I O N
Figure 3 shows a simple example of user-interface entry.
/*
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Date: 1/23187 { Chocked by: V.E.S
....................................................
*/
quostion(cleax.ep~u.foo%) • 'What i s t h e c l e a r span o f t h e member in f e e t ? ' legalvals(cleaor_epan_£eot) = nmlber(0.0,50.0).
oxplanation(cloar_spaa_faet)= ' C l e a r spam i s needed f o r a p p r o x i m a t e moment c a l c u l a t i o n ' .
Figure 3
~
•
=
Figure 4
Data entry. Throughout the consultation, the user is expected to provide some responses to queries from the inference engine. In order to 'shelter' him from ambiguous and unclear 'questioning' by the program (such as Enter value of clear_span_feet), a user-interface was developed. Through it three metacommands have been associated with each variable:
W r i t t e n by: S.N.D
.
Example of user-interface entry
* A PC-based expert system shell marketed by Teknowledge Inc., Pale Alto, CA.
.
,=
Operation support
Operation support. Following preliminary field evaluation of the first prototype, it was found that for the program to be well accepted by engineers it would have to provide numerous support features for the user and be as 'user-friendly' as possiblet. This was made possible through extensive usage of 'pull-down' menus (see Figure 4). Some of the major features of the operation support include: 1. Introductory on-line help, explaining use of the program. 2. Automatic menu display, in which legal responses for a particular question are displayed. The program will automatically reject any non-legal entry. 3. Possibility to associate a certainty factor with a piece of input data. 4. Explanation, i.e. text display to show why the system needs a particular value. 5. Code display. At any time the user can request the program to display either the current code provision being checked, or an arbitrary provision of interest. The code is stored within an ASCII disk file which allows the user to edit it for inclusion of his/her own textual clarifications. 6. Editor, which enables the user either to re-enter a previously specified incorrect variable, or to restart a consultation in which only selected variables have been altered (a situation which often arises in revised designs). 7. Saving of the consultation in a disk file.
~' Contrary to our initial expectation, actual development of the knowledge base represented only about half of the effort, with the remaining portion spent in continuously refining the 'user-friendliness' of the program through the user interface, the pro, and the postprocessors.
Eng. Appli. of AI, 1989, Vol. 2, March
51
An expert-system-based code-compliance checker: V E Saouma et a l
Knowledge base The knowledge base was subdivided into two compartments:
8.5.1 Written
by:
5.M.D
Date:
I0/20/86
I Checked by: V . E . S
......................................................
*/
aci-a-8-5-t:
1. High-level rules which control the flow of operation of the code checking module. 2. Low-level rules which are specific to the selected code. In this implementation they are all related to the ACI-318 design code.
High-level rules. High-level rules are codeindependent, and simply control the overall flow of operation. They are themselves subdivided into different categories:
if u n i t _ v e i g h t . c o n c r e t e . l b p e r c u f
and s t r e n g t h _ o f . c o n c r e c e . k s i
52
Eng Appli of AI, 1989, Vol 2, March
• FK
and FK*1000.0 • FC and s q r t ( F C ) • A and t o l e r a n c e = TOL and 57.0*A • EC and = o d u Z u s _ o f _ e Z a s t l c l t y . c o n c r e t e _ u s e d . k s £ a n d p e r ( E C , E C U S E ~ ) = TEMP
= ECUSEK
a n d TF.J4P < TOL
then a c i - 8 - S - t
= satisfied.
Figure 5
1. Control of the type of desired checking: (a) Exhaustive checking in which all code provisions represented in the knowledge base are to be verified. In the light of the large amount of data which has to be provided for a given design, the data entry portion of the user interface is deactivated, and data are expected to be provided through the spreadsheet-based preprocessor. (b) Selective checking of a limited portion of the knowledge base. Through this option, the user can select a 'pre-packaged' set of rules which has to be checked often. There can be one or more sets of such rules. In our application, we have grouped two selective options: 'Quick Beam Check' and 'Quick Column Check' which perform a limited and rapid check of a given design. Typically, those rules are the ones which would be routinely verified in a design process. (c) Arbitrary checking of any rule represented in the knowledge base. Through this option the user can randomly select any rule of the knowledge base for verification. 2. Tolerance control. As numerical values are to be compared throughout the consultation, a certain tolerance margin is to be specified by the user. 3. Flow control of the knowledge bases. As the size of the knowledge base can be quite large, and cannot be entirely loaded, it has to be partitioned and dynamically loaded into memory as the need arises. 4. Rules and metacommands associated with the support for the operation support previously described and screen display. 5. Rules associated with the interface with external modules for extensive numerical operations, and which are more efficiently written in an algorithmic language such as C or Fortran.
= WC
and we <= 150.0 and WC >= 145.0
Example of a l o w - l e v e l rule
Low-level rules. Low-level rules are those rules which are specific to the code being implemented. Thus, each code provision would have one or more associated rules in the knowledge base. For increased clarity, all rule labels are identical to the code provision numbers. Figure 5 is an example of a low-level rule.
Report generator post-processor Following its completion, there is a need to provide the user with an exhaustive (and 'readable') summary of the consultation. In light of some of the limitations of an expert-system shell, it was found that the most appropriate approach would be to dump the cache into a disk file at the end of a consultation. Subsequently, an external code for report generation would run independently after accessing this file. The generator would provide a concise tabulation of: 1. All user-supplied input data. 2. Selected internally-computed design variables. This would enable the user to compare the hand-computed ones with the ones internally evaluated by the program. 3. List of all code provisions which are: (a) Satisfied. (b) Violated. (c) Not applicable. (d) Not yet implemented. This report constitutes a complete 'diagnosis' of the prescribed design. CODE E V A L U A T I O N In developing the knowledge base of a design code,
An expert-system-based code-compliance checker: V. E. Saouma et al.
the knowledge engineer is continuously challenged to clearly and unequivocally interpret all of its provisions. As most codes are written by large committees, and are the result of a natural evolution throughout many years of revisions and updates, it is only natural that such a task would uniquely qualify the knowledge engineer to provide some constructive criticisms. For the specific implenientation reported here, two levels of complexities have been encountered: 1. Textual complexity, which includes specification location and terminology. 2. Logical complexity, under which falls the interconnectivity and redundancy of specifications. These issues are discussed at length below in relation to the ACI code.
Textual complexities The difficulties encountered by code users due to textual complexities are basically those of inconsistencies, nebulousness, and lack of options. A lack of consistency in the structure of the code system is also noticed. Textual organization complexity inhibits a user's ability to locate all requirements which apply to a given design. Thus the organizational complexity and the underlying network of cross-references found in the code underlies the difficulties in using such a code. For example, both Sections 8.8 and 10.13 address column design and yet are situated in different places in the code. While it is not a major factor in the textual complexity, the terminology or phraseology used to express requirements and other provisions in the code leads to ambiguity and misunderstanding. This confusion could be avoided if more concise phrasing was employed while writing the code. As such, it is very difficult to comprehend the full impact of certain provisions. For example, Provision 10.2.4 has very complicated terminology making it difficult to comprehend its total impact. More detailed proposals to aid more accurate and consistent expression of the code in future revisions have been described in detail by Harris and Wright 9, and by Fenves 1o
Logical complexity Design standards are logical systems in that the user is required to make a comparative study. Specific values of variables associated with a given design are compared to values presented in the
standards, in order to determine the applicable outcome. The lowest level of complexity occurs when an outcome can be determined on the basis of a single comparison. However, it is often necessary to make several comparisons before determining an outcome. In such cases the number of possible logical alternatives increases dramatically, and accurate determination of the applicable outcome becomes increasingly difficult. Several different aspects of logical complexity are given below. First, there is a total lack of consistency in the structure of the code system in reference to priorities and their weightings. It is often difficult to find which code (rule or specification) has priority in a project. Many times it is inevitable for the user to take the most restrictive code requirement and use it as a base. For example, the two provisions, 8.1.1 and 8.1.2, give the user an option to choose from two methods but do not state which method would be preferable under any particular set of circumstances. A second source of logical complexity is the interconnectfvity of provisions. The ACI code is subdivided into parts, chapters, sections, and paragraphs in a manner which basically isolates provisions according to topic. Within a given paragraph, logical complexity is often not a major concern, although it is quite significant. In many instances, however, several or all paragraphs within a section are interrelated, leading to extremely complex situations. In those cases, various interrelationships occur between conditions. Thus the response to one given condition may define the response to others and/or cause other conditions to become inapplicable. For example, section 9.3.2 calculates the strength reduction factor {} which is again used in sections 10.3.1 to 10.3.3 for moment calculations. Thus, inevitably, section 9.3.2 dictates the outcome of moment calculations in section 10.3.1. Lastly, it has also been noted that there are certain specifications in the code which, though worded in a completely different manner as compared to each other, convey the same intrinsic meaning. This means that if one of the provisions is satisfied then the other is also satisfied. For example, provisions 11.1.2 and 11.1.2.1. If provision 11.1.2 is satisfied then 11.1.2.1 is also satisfied. Complexities, both textual organization and logical, tend to inhibit full and accurate utilization of design standards. Organizational complexity leads to difficulties in locating reciuirements and to the possibility that all applicable requirements may Eng. Appli. of AI, 1989, Vol. 2, March
53
An expert-system-based code-compliance checker." V. E. Saouma et al.
not be implemented. Logical complexity can cause difficulty in accurate identification and checking of applicable requirements with an attendant chance of error. Both forms of complexity can have the effect of discouraging full use of design standards because it may be considered to be too timeconsuming. Thus, it is very important that certain changes be made in the inherent procedure of writing the specifications or the code. Hence it is thought appropriate that certain recommendations be made here in order to increase code usefulness. TREE STRUCTURE GENERATION OF CODE PROVISIONS Following the knowledge base development of a design code, it was realized that one could easily exploit the tracing mechanism inherent to a backward chaining inference engine, to generate a set of trees and tables which would graphically display the interconnectivities and cross-references of all the rules and variables. Thus the following 'by-products' to our development were generated: 1. Tree structure of all the code rules as shown in
e¢i=10-2-1 aci-10-2~2 acto10=2-3 act=10=2-4 a¢t=10-2-5 aci=10-2-6 a¢i-10-2-7
a¢i-10-2-7-1
a¢to10-2-7-2 aci-10-2=7-3 a¢i-10-3=1 act-10-3-2
->ac£-10-2-7-3 ->act-10-3-1
I ->aci-10-3-3 I ->aci-10-2-7-3
aci-I0-3-3
I ->aci-10-2-7-3
aci=10-4-1 a¢i-10-4=2 a¢t-10-5-1
I ->a¢i-10-3-3
a¢i-10-6-5 act-10-6-6
I->act-8-10-2 I->a¢¢-8-7-1 I->a¢i-8-7-2
Figure 7 Table of 'pre-rules' aci-11-3-1-1 <---laci-11-1-1 <---laci-11-3-1 <---la¢i-11-3-2-2 <---laci-tl-S-5-2 <---ta¢i-t1-S-5-3 <---la¢i-11-5-5-5 <---laci-tl-S-6-t
Figure 6. 2. Table of all the rules needed to be evaluated prior to the evaluation of a specific one, or 'pre-rules' (Figure 7). The right-hand entries must be verified before the corresponding left-hand ones. 3. Table of all the rules which are affected by a given one, or 'post-rules' (Figure 8). Verification of the rules shown on the left column is going to affect the outcome of the corresponding rules shown in the right column.
I->aci-10-2-7-1 1->aci-10-2-7-3 ->aci-10-3-1
aci-11-3-Io2 <---laci-11-t-1 <---lact-11-3-1 <---la¢i-11-3-2-2 aci-11-3-1-3 <---laci-11-1-1 <---laci-11-3-1 <---la¢i-11-3-2-2
CHAPTEIt 10 I ---a¢t-10-2-1 I---a¢t-10-2-2 1- - - a ¢ t - 1 0 - 2 - 3 I---act-10-2-4 I ---a¢t-10-2-S I ---a¢t-10-2-6 ---a¢t-10-2-7 I .......... act-10-2-7-1 I I---eeL-IO-2-7-3 I I---eci-t0-3-t ---a¢t-10-2-7-1 I ---t¢i-10-2-7-3 I ---a©t- 10-3-1 ---a¢i-10-2-7-2 ---a¢i-10-2-7-3 I---act-lO-3-t I ---a¢t-10-3-2 I I ---a¢i-10-3-3 I I---a¢1-10-2-7-3
Figure 6
54
Portion of the tree structure for all code rules
Eng. Appli. of A=, 1989, Vol. 2, March
a¢i-11-3-1-4 < - - - la¢1-11-1-1 <--- la¢t-11-3-1 <--- laci-11-3-2-2 <---It¢t-11-5-5-3 < - - - I t¢t- 11-S-S-S <---Iici-11-6-1 < - - - t l c t ' - 11-6-S •< - - - l a ¢ t - 1 1 - 6 - 6 <--- la¢i-11-6-9-1
Figure 8 Table of 'post-rules'
4. Table of all the rules which use a specific variable (Figure 9). The variables in this case are the internal ones used in the knowledge base. It is evident that
with the help of such
An expert-system-based code-compfiance checker." V. E. Saouma et al. sptcing.shear.reieLtOrCemen¢_used.inch <..- a¢i-11-1-1 <--- aci-11-S-4-1 <... Itci-11-$-4-2 <..- a¢i-11-5-4-3 <... aci-ll-5-8-S <-.. aci-11-5-6-1 <--. =ci-11-S-6-2 <--. sci-11-S-6-8 < . . . a c i - 11-6-5 <--. a¢i-11-6-9-1
spam_tpprox~ately_equtl= <---lac3-8-3-3
span_len~h_f eet <---laci-10-6-6 <---1a¢i-8-10-2 <---la¢i-8-10-3 <---laci-8-10-4 <---laci-8-7-1
special_inves¢isations.done <---la¢i-10-6-5 st eeZ.sl;rain.lLlt/aate.load <--- laci-10-2-4
sCra~.proporCiona I _dlstance.neutra1_axis
provisions 8.5.2 and 8.1.1. At an initial glance there appears to be no interconnectivity between these provisions. However, after some thought one can come to the following conclusion: 'Provision 8.1.1 defines the type of the member, whether prestressed or not. Thus, in effect it also defines the reinforcement type. Thus, if the member is nonprestressed then the reinforcement is also nonprestressed. Now, provision 8.5.2 deals with the modulus of elasticity of nonprestressed reinforcement and so it follows that the two provisions are interconnected.' Another example is the interconnection between ACI provisions 10.5.1 and 10.3.3. Again, at an initial glance there appears to be no relation between the two. However, after giving it some thought the following connection appears: 'Provision 10.5.1 performs the minimum reinforcement check and for doing so it requires the value of p which is computed in provision 10.3.3 and thus the two provisions are related'.
<--- I aci- 10-2-2
Figure 9 Tables of rules affected by a given variable
S U M M A R Y AND R E C O M M E N D A T I O N S FOR FUTURE ENHANCEMENTS information, not only would code revision be greatly facilitated, but (more importantly) code verification also. Thus those tables c~in also have an important pedagogical value. Despite their relevance, great care must be exercised in properly interpreting the previously discussed tables/trees. Upon closer examination with direct reference to the ACI code some apparent inconsistencies emerge. The tree structure reflects inter-connections between the various code provisions and should be interpreted as such. Instead of viewing it as, say, one rule or provision calling another provision, it should be viewed as a plain and simple inter-connection between the provisions, such that a change to one of the provisions may or may not induce a change in the connected one. Secondly, while going through the tree structure, one comes across certain connections which are very obvious and shallow. However, there are also certain connections which are not obvious and thus very deep, and some thought may be required to understand the reasoning process behind such connections. It is these types of connections which ought to be the primary concern of any code reviewing committee. • An example of a deep connection in our implementation is the connection between ACI
This paper has described the construction of a PC-based expert system for reinforced concrete design checking against the ACI 318-83 code provisions. The developed system consists of a knowledge base representing most of chapters 8-12 of the ACI code. Methods to facilitate data input and to summarize the conclusions of the consultation have been developed. It was found that for such a system to be accepted by engineers, a greater than expected emphasis must be placed on the user-interface. Finally, several observations concerning the complexity and ambiguity have been made. Following this easy implementation, current work is under way to: 1. Complete implementation of all the rules found in ACI 318-87 chapters 8 to 12. 2. Implement the knowledge base within a more powerful expert system shell (S1) which could run both on personal computers (with 2 Mb of extended memory) as well as on Unix workstations. 3. Make this knowledge base an integral part of a more general design program, such as those developed by Saouma et al. T M and Jones and SaoumaX3. Eng. Appli. of AI, 1989, Vol. 2, March
55
An expert-system-based code-compliance checker: V. E. Saouma et al.
ACKNOWLEDGEMENTS The authors wish to express their appreciation to the US Af'rny Corps of Engineers for funding under contract No. DACA39-86-K-0011. The assistance of Mr Mike Jones and Dr Mike Sikiotis in developing the knowledge base, and its review, is gratefully acknowledged. Finally, the authors would like to thank the Building System Task group for its numerous and constructive comments during early evaluation of this program, and Dr Radhakrishnan, chief of the Information Technology Laboratory for his enthusiastic support and encouragement.
REFERENCES ACI 318-1983, Building code requirements for reinforced concrete (ACI-318-83), American Concrete Institute, Detroit, MI (1987) 2 Fenves, S. J., Goel, S. K. and Gaylord, E. H., Decision table formulation of the AISC specification, Civil Engineering Studies, Structural Research Series No. 347, University of Illinois (1969) 3 Noland, J. L., Formulation of decision logic tables and their application to engineering specifications, Ph.D. thesis, University of Colorado, Boulder (1975) 1
56
Eng. Appli. of AI, 1989, Vol. 2, March
4 Noland, J. L., Decision logic table formulation of ACI 318-77 building code requirements for reinforced concrete for automated constraint processing, Technical Report ATC-86-5, prepared for the Department of the Army, US Army Corps of Engineers (July 1986) 5 Goel, S. K. and Fenves, S. J., Computer aided processing of structural design specifications, Civil Engineering Studies, Structural Research Series No. 348, University of lllinois, Urbana, IL (1969) 6 Garrett, J. H. and Fenves, S. J., A knowledge-based standards processor for structural component design~ Engineering with Computers, 2, pp. 219-238 (1987) 7 Rosenman, M. A. and Gero, J. S., Design codes as expert systems. Computer-Aided Design, 17(9), (1985) 8 Rosenman, M. A., Gero, J. S. and Oxman, R., An expert system for design codes and design rules, Applications of Artificial Intelligence to Engineering Problems (1986) 9 Harris, J. R. and Wright, R. N., Organization of building standards: Systematic techniques for scope and arrangement, NBS Building Science Series 136, National Engineering Laboratory, National Bureau of Standards, Washington, DC (1981) 10 Fenves, S. J., Rankin, K. R. and Tejuja, H. K.. The structure of building specifications, Building Science Series 90, Center for Building Technology, Institute for Applied Technology, National Bureau of Standards, Washington, DC (1976) 11 Saouma, V. E., Sikiotis, E. and Flango, R., Computer aided analysis and design of reinforced concrete buildings, Concrete International, 7(6), pp. 25-30 (1985) 12 Saouma, V. E., Sikiotis, E. S. and Commander, B., Integrated structural design system~ Interim Report to the US Army Corps of En#ineers (1988) 13 Jones, M. S. and Saouma, V. E., Prototype hybrid expert system for R/C design, Journal of Computing in Civil Engineering, ASCE, 2(2), pp. 136-143 (1988)
ABSTRACT This paper reports the development of an expert-system-based code-checking framework which 'certifies' compliance of a design with appropriate code provisions. As a 'test-bed' for this prototype, reinforced concrete design compliance with most of the ACI-318 code provisions (found in Chapters 8 to 12 of Reference 1)is selected. A comprehensive and user-friendly framework is developed through various modules. First initial data entry is performed either interactively during the consultation, or through a spreadsheet (Lotus 123) input. Then consultation with the knowledge based expert system is greatly enhanced by a powerful user interface with such capabilities as: arbitrary provision checking, display of code provision, and editing of input data. Finally a report summarizing the consultation (including the original input data, tabulation of the most relevant internally-computed variables, and list of code provisions which are either satisfied or violated) is generated. The knowledge base development resulted in both a critical evaluation of the code, and the generation of an exhaustive tree representation of the rules and design variables. It was found that this initial prototype could be of practical engineering relevance, that its architecture could be adopted for applications other than the one used, and finally that it could serve as an initial configuration for a quality assurance program for design in general. INTRODUCTION In most, if not all, engineering and technical disciplines the designer is confronted with the task 0952-1976/89/010049-0852.00
© 1989PineridgeLtd
of certifying the compliance of a given design with prevailing codes. A professional engineer (PE) may need to verify a design before he/she can legally sign a set of drawings, a plumber may need to verify that a certain installation complies with city regulations, or an engineer hired by a lawyer may be searching for evidence of malpractices in possible code violations during court litigations. In each one of those cases, the engineer would like, ideally, to check all appropriate code provisions. As we all know this can be a formidable task, which could greatly benefit from automation. Thus, through the proper implementation of such an automated procedure for code checking, a Quality Assurance program could be developed. Formal representation of design standards can be traced back to some of the pioneering work of Fenves 2 in which Decision Logic Tables (DLTs) were first introduced. DLTs have been subsequently used by Fenves et al. to represent the AISC code, and by Noland 3'4 to represent the ACI-318 code. Processing, DLTs required a special driver, such as those originally written by Goel and Fenves 5, or Lopez. In a recent work Garrett 6 used a DLT representation of the AISC code as a module in a steel structures design program. While DLT representation of design codes remains a very attractive approach, its main disadvantage is that it requires special 'drivers' for actual code checking. Those drivers have been developed for mainframe computers, and can be quite expensive to acquire/operate. In recent years, the pre-eminence of DLTs for code checking has been overshadowed by the 'explosion' of workstations, and PC-based expert system shells (whose conceptual roots could be traced back to DLTs). As knowedge based expert systems have been extensively used in numerous recent engineering applications, no description of expert systems will be undertaken in this paper, other than to mention that expert systems operate on ill-structured, non-deterministic, qualitative information (such as codes). This is to be contrasted with the quantitative algorithmic knowledge with which engineers have been for too long accustomed. Expert systems can be broadly subdivided into two categories: those using a forward-chaining, and those using a backward-chaining inference process. While the former is well suited for design purposes, the latter is known to be more appropriate for diagnostic purposes such as code verification. Expert systems for code verification have already Eng. Appli. of AI, 1989, Vol. 2, March
49
An expert-system-based code-compliance checker." V. E. Saouma et al.
been used to Rosenman 7's who developed a prototype to test the feasibility of representing the Australian Building Code System in a knowledge base.
v t~ t=--v ~ i ~ n tim
i, th. l.~,.~ *~. r sho~.s~ sl.an?
I
II~Ku t iii i
I~ lwt4Pl~al sl-.~tttt.al p4wtll d l ~ l l l l e d t o ~lst t h s totall l a t 4 l ~ l I o ~ l s ?
OVERVIEW OF SYSTEM Having found that the intellectual process by which an engineer verifies compliance of a design with a given code provision closely parallels the backwardchaining inference process, an expert-system-based approach was selected for code validation. As a test-bed for our implementation, reinforced concrete design validation with the ACI-318-87 code 1 was selected. More specifically, major portions of Chapters 8 to 12 were identified, and a knowledge base developed accordingly. At this stage it should be pointed out that our overall approach to the problem is quite general and is by no means restricted to the concrete design example selected. To properly exploit the expert system shell, while its intrinsic limitations are accounted for, the overall system was broken into three interconnected modules, as shown in Figure I.
I
I" m
r,----!. ~
,.,~T - OUIIq~A~T
IIn
-
uliq~
Figure 1 Overall system
50
architecture
Eng. Appli. of AI, 1989, Vol. 2, March
1.3 s~xlmm r ~ t l o a ( ~ t =lder~?
to txlal
1o~ c-
we=
tlw N r v l c ; e loads In ~ o ~ k l v , c e ultl~r" II'-Q I
Figure 2
Example o f a s p r e a d - s h e e t entry
1. A spreadsheet preprocessor for data entry. 2. The knowledge base and user-interface for data processing, and actual checking. 3. A postprocessor to organize and summarize the consultation results.
Preprocessor for data entry Following field testing of the first program prototype, it was found that there was a general reluctance to use it in light of the excessive amount of data the user would have to supply to the expert system (ES), interactively through its user-interface. As such a preprocessor for data entry was developed, it was found that a spreadsheet could provide an ideal environment for this task, as the user can easily overwrite listed default values which differ from his/her current design in the spreadsheet cells. During data presentation, the variable definitions are listed in column A, default entries in column B, and the legal range of responses in column C, as in Figure 2. Following completion of the 220 entries, the contents of column B are simply printed into a disk file. Subsequently a cache generation program (123TOM1) would read this ASCII file, into a dummy cache which would be loaded by the expert system shell. By loading this file, the ES would thus find all the variables it needs for code verification, and will not need to request information from the user. Selection of this form of data entry is optional, and is recommended only for those consultations in which all code provisions are to be verified. As will be shown below, this is one of three possible options for consultation.
An expert-system-based code-compliance checker: V.E. Saouma et al.
User interface and knowledge base processor In our implementation, both the user interface and knowledge base are 'coded' within MI*, and will be addressed separately.
bdlt b I R mupql,h
~
ll,,-==~
im~ ¢mevwmw {Pmelo{Im
lii~ lqbllqiow Iko~ios
M H h N W hta NuOm) WU.,8 , q , ~ MJPI.
User-interface As its name implies, the user-interface controls all communication between the inference engine and the user. The user-interface is primarily responsible for two essential tasks: F
1. Data entry, and explanation. 2. Operation support.
( V A R I A B L E - N A M E ) , which poses the question to the user when a specific query (for variable-name) is to be made by the system. 2. LEGALVALUE(VARIABLE-NAME),which provides a set of legal entries by the user. This can be a lower and upper bound for numerical values (integers and/or reals), or a limited set of textual responses. 3. E X P L A N A T I O N ( V A R I A B L E - N A M E ) , which provides additional explanation for the user should he question the need for the system to have a particular variable defined (that is if he responds with a why). 1. Q U E S T I O N
Figure 3 shows a simple example of user-interface entry.
/*
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Date: 1/23187 { Chocked by: V.E.S
....................................................
*/
quostion(cleax.ep~u.foo%) • 'What i s t h e c l e a r span o f t h e member in f e e t ? ' legalvals(cleaor_epan_£eot) = nmlber(0.0,50.0).
oxplanation(cloar_spaa_faet)= ' C l e a r spam i s needed f o r a p p r o x i m a t e moment c a l c u l a t i o n ' .
Figure 3
~
•
=
Figure 4
Data entry. Throughout the consultation, the user is expected to provide some responses to queries from the inference engine. In order to 'shelter' him from ambiguous and unclear 'questioning' by the program (such as Enter value of clear_span_feet), a user-interface was developed. Through it three metacommands have been associated with each variable:
W r i t t e n by: S.N.D
.
Example of user-interface entry
* A PC-based expert system shell marketed by Teknowledge Inc., Pale Alto, CA.
.
,=
Operation support
Operation support. Following preliminary field evaluation of the first prototype, it was found that for the program to be well accepted by engineers it would have to provide numerous support features for the user and be as 'user-friendly' as possiblet. This was made possible through extensive usage of 'pull-down' menus (see Figure 4). Some of the major features of the operation support include: 1. Introductory on-line help, explaining use of the program. 2. Automatic menu display, in which legal responses for a particular question are displayed. The program will automatically reject any non-legal entry. 3. Possibility to associate a certainty factor with a piece of input data. 4. Explanation, i.e. text display to show why the system needs a particular value. 5. Code display. At any time the user can request the program to display either the current code provision being checked, or an arbitrary provision of interest. The code is stored within an ASCII disk file which allows the user to edit it for inclusion of his/her own textual clarifications. 6. Editor, which enables the user either to re-enter a previously specified incorrect variable, or to restart a consultation in which only selected variables have been altered (a situation which often arises in revised designs). 7. Saving of the consultation in a disk file.
~' Contrary to our initial expectation, actual development of the knowledge base represented only about half of the effort, with the remaining portion spent in continuously refining the 'user-friendliness' of the program through the user interface, the pro, and the postprocessors.
Eng. Appli. of AI, 1989, Vol. 2, March
51
An expert-system-based code-compliance checker: V E Saouma et a l
Knowledge base The knowledge base was subdivided into two compartments:
8.5.1 Written
by:
5.M.D
Date:
I0/20/86
I Checked by: V . E . S
......................................................
*/
aci-a-8-5-t:
1. High-level rules which control the flow of operation of the code checking module. 2. Low-level rules which are specific to the selected code. In this implementation they are all related to the ACI-318 design code.
High-level rules. High-level rules are codeindependent, and simply control the overall flow of operation. They are themselves subdivided into different categories:
if u n i t _ v e i g h t . c o n c r e t e . l b p e r c u f
and s t r e n g t h _ o f . c o n c r e c e . k s i
52
Eng Appli of AI, 1989, Vol 2, March
• FK
and FK*1000.0 • FC and s q r t ( F C ) • A and t o l e r a n c e = TOL and 57.0*A • EC and = o d u Z u s _ o f _ e Z a s t l c l t y . c o n c r e t e _ u s e d . k s £ a n d p e r ( E C , E C U S E ~ ) = TEMP
= ECUSEK
a n d TF.J4P < TOL
then a c i - 8 - S - t
= satisfied.
Figure 5
1. Control of the type of desired checking: (a) Exhaustive checking in which all code provisions represented in the knowledge base are to be verified. In the light of the large amount of data which has to be provided for a given design, the data entry portion of the user interface is deactivated, and data are expected to be provided through the spreadsheet-based preprocessor. (b) Selective checking of a limited portion of the knowledge base. Through this option, the user can select a 'pre-packaged' set of rules which has to be checked often. There can be one or more sets of such rules. In our application, we have grouped two selective options: 'Quick Beam Check' and 'Quick Column Check' which perform a limited and rapid check of a given design. Typically, those rules are the ones which would be routinely verified in a design process. (c) Arbitrary checking of any rule represented in the knowledge base. Through this option the user can randomly select any rule of the knowledge base for verification. 2. Tolerance control. As numerical values are to be compared throughout the consultation, a certain tolerance margin is to be specified by the user. 3. Flow control of the knowledge bases. As the size of the knowledge base can be quite large, and cannot be entirely loaded, it has to be partitioned and dynamically loaded into memory as the need arises. 4. Rules and metacommands associated with the support for the operation support previously described and screen display. 5. Rules associated with the interface with external modules for extensive numerical operations, and which are more efficiently written in an algorithmic language such as C or Fortran.
= WC
and we <= 150.0 and WC >= 145.0
Example of a l o w - l e v e l rule
Low-level rules. Low-level rules are those rules which are specific to the code being implemented. Thus, each code provision would have one or more associated rules in the knowledge base. For increased clarity, all rule labels are identical to the code provision numbers. Figure 5 is an example of a low-level rule.
Report generator post-processor Following its completion, there is a need to provide the user with an exhaustive (and 'readable') summary of the consultation. In light of some of the limitations of an expert-system shell, it was found that the most appropriate approach would be to dump the cache into a disk file at the end of a consultation. Subsequently, an external code for report generation would run independently after accessing this file. The generator would provide a concise tabulation of: 1. All user-supplied input data. 2. Selected internally-computed design variables. This would enable the user to compare the hand-computed ones with the ones internally evaluated by the program. 3. List of all code provisions which are: (a) Satisfied. (b) Violated. (c) Not applicable. (d) Not yet implemented. This report constitutes a complete 'diagnosis' of the prescribed design. CODE E V A L U A T I O N In developing the knowledge base of a design code,
An expert-system-based code-compliance checker: V. E. Saouma et al.
the knowledge engineer is continuously challenged to clearly and unequivocally interpret all of its provisions. As most codes are written by large committees, and are the result of a natural evolution throughout many years of revisions and updates, it is only natural that such a task would uniquely qualify the knowledge engineer to provide some constructive criticisms. For the specific implenientation reported here, two levels of complexities have been encountered: 1. Textual complexity, which includes specification location and terminology. 2. Logical complexity, under which falls the interconnectivity and redundancy of specifications. These issues are discussed at length below in relation to the ACI code.
Textual complexities The difficulties encountered by code users due to textual complexities are basically those of inconsistencies, nebulousness, and lack of options. A lack of consistency in the structure of the code system is also noticed. Textual organization complexity inhibits a user's ability to locate all requirements which apply to a given design. Thus the organizational complexity and the underlying network of cross-references found in the code underlies the difficulties in using such a code. For example, both Sections 8.8 and 10.13 address column design and yet are situated in different places in the code. While it is not a major factor in the textual complexity, the terminology or phraseology used to express requirements and other provisions in the code leads to ambiguity and misunderstanding. This confusion could be avoided if more concise phrasing was employed while writing the code. As such, it is very difficult to comprehend the full impact of certain provisions. For example, Provision 10.2.4 has very complicated terminology making it difficult to comprehend its total impact. More detailed proposals to aid more accurate and consistent expression of the code in future revisions have been described in detail by Harris and Wright 9, and by Fenves 1o
Logical complexity Design standards are logical systems in that the user is required to make a comparative study. Specific values of variables associated with a given design are compared to values presented in the
standards, in order to determine the applicable outcome. The lowest level of complexity occurs when an outcome can be determined on the basis of a single comparison. However, it is often necessary to make several comparisons before determining an outcome. In such cases the number of possible logical alternatives increases dramatically, and accurate determination of the applicable outcome becomes increasingly difficult. Several different aspects of logical complexity are given below. First, there is a total lack of consistency in the structure of the code system in reference to priorities and their weightings. It is often difficult to find which code (rule or specification) has priority in a project. Many times it is inevitable for the user to take the most restrictive code requirement and use it as a base. For example, the two provisions, 8.1.1 and 8.1.2, give the user an option to choose from two methods but do not state which method would be preferable under any particular set of circumstances. A second source of logical complexity is the interconnectfvity of provisions. The ACI code is subdivided into parts, chapters, sections, and paragraphs in a manner which basically isolates provisions according to topic. Within a given paragraph, logical complexity is often not a major concern, although it is quite significant. In many instances, however, several or all paragraphs within a section are interrelated, leading to extremely complex situations. In those cases, various interrelationships occur between conditions. Thus the response to one given condition may define the response to others and/or cause other conditions to become inapplicable. For example, section 9.3.2 calculates the strength reduction factor {} which is again used in sections 10.3.1 to 10.3.3 for moment calculations. Thus, inevitably, section 9.3.2 dictates the outcome of moment calculations in section 10.3.1. Lastly, it has also been noted that there are certain specifications in the code which, though worded in a completely different manner as compared to each other, convey the same intrinsic meaning. This means that if one of the provisions is satisfied then the other is also satisfied. For example, provisions 11.1.2 and 11.1.2.1. If provision 11.1.2 is satisfied then 11.1.2.1 is also satisfied. Complexities, both textual organization and logical, tend to inhibit full and accurate utilization of design standards. Organizational complexity leads to difficulties in locating reciuirements and to the possibility that all applicable requirements may Eng. Appli. of AI, 1989, Vol. 2, March
53
An expert-system-based code-compliance checker." V. E. Saouma et al.
not be implemented. Logical complexity can cause difficulty in accurate identification and checking of applicable requirements with an attendant chance of error. Both forms of complexity can have the effect of discouraging full use of design standards because it may be considered to be too timeconsuming. Thus, it is very important that certain changes be made in the inherent procedure of writing the specifications or the code. Hence it is thought appropriate that certain recommendations be made here in order to increase code usefulness. TREE STRUCTURE GENERATION OF CODE PROVISIONS Following the knowledge base development of a design code, it was realized that one could easily exploit the tracing mechanism inherent to a backward chaining inference engine, to generate a set of trees and tables which would graphically display the interconnectivities and cross-references of all the rules and variables. Thus the following 'by-products' to our development were generated: 1. Tree structure of all the code rules as shown in
e¢i=10-2-1 aci-10-2~2 acto10=2-3 act=10=2-4 a¢t=10-2-5 aci=10-2-6 a¢i-10-2-7
a¢i-10-2-7-1
a¢to10-2-7-2 aci-10-2=7-3 a¢i-10-3=1 act-10-3-2
->ac£-10-2-7-3 ->act-10-3-1
I ->aci-10-3-3 I ->aci-10-2-7-3
aci-I0-3-3
I ->aci-10-2-7-3
aci=10-4-1 a¢i-10-4=2 a¢t-10-5-1
I ->a¢i-10-3-3
a¢i-10-6-5 act-10-6-6
I->act-8-10-2 I->a¢¢-8-7-1 I->a¢i-8-7-2
Figure 7 Table of 'pre-rules' aci-11-3-1-1 <---laci-11-1-1 <---laci-11-3-1 <---la¢i-11-3-2-2 <---laci-tl-S-5-2 <---ta¢i-t1-S-5-3 <---la¢i-11-5-5-5 <---laci-tl-S-6-t
Figure 6. 2. Table of all the rules needed to be evaluated prior to the evaluation of a specific one, or 'pre-rules' (Figure 7). The right-hand entries must be verified before the corresponding left-hand ones. 3. Table of all the rules which are affected by a given one, or 'post-rules' (Figure 8). Verification of the rules shown on the left column is going to affect the outcome of the corresponding rules shown in the right column.
I->aci-10-2-7-1 1->aci-10-2-7-3 ->aci-10-3-1
aci-11-3-Io2 <---laci-11-t-1 <---lact-11-3-1 <---la¢i-11-3-2-2 aci-11-3-1-3 <---laci-11-1-1 <---laci-11-3-1 <---la¢i-11-3-2-2
CHAPTEIt 10 I ---a¢t-10-2-1 I---a¢t-10-2-2 1- - - a ¢ t - 1 0 - 2 - 3 I---act-10-2-4 I ---a¢t-10-2-S I ---a¢t-10-2-6 ---a¢t-10-2-7 I .......... act-10-2-7-1 I I---eeL-IO-2-7-3 I I---eci-t0-3-t ---a¢t-10-2-7-1 I ---t¢i-10-2-7-3 I ---a©t- 10-3-1 ---a¢i-10-2-7-2 ---a¢i-10-2-7-3 I---act-lO-3-t I ---a¢t-10-3-2 I I ---a¢i-10-3-3 I I---a¢1-10-2-7-3
Figure 6
54
Portion of the tree structure for all code rules
Eng. Appli. of A=, 1989, Vol. 2, March
a¢i-11-3-1-4 < - - - la¢1-11-1-1 <--- la¢t-11-3-1 <--- laci-11-3-2-2 <---It¢t-11-5-5-3 < - - - I t¢t- 11-S-S-S <---Iici-11-6-1 < - - - t l c t ' - 11-6-S •< - - - l a ¢ t - 1 1 - 6 - 6 <--- la¢i-11-6-9-1
Figure 8 Table of 'post-rules'
4. Table of all the rules which use a specific variable (Figure 9). The variables in this case are the internal ones used in the knowledge base. It is evident that
with the help of such
An expert-system-based code-compfiance checker." V. E. Saouma et al. sptcing.shear.reieLtOrCemen¢_used.inch <..- a¢i-11-1-1 <--- aci-11-S-4-1 <... Itci-11-$-4-2 <..- a¢i-11-5-4-3 <... aci-ll-5-8-S <-.. aci-11-5-6-1 <--. =ci-11-S-6-2 <--. sci-11-S-6-8 < . . . a c i - 11-6-5 <--. a¢i-11-6-9-1
spam_tpprox~ately_equtl= <---lac3-8-3-3
span_len~h_f eet <---laci-10-6-6 <---1a¢i-8-10-2 <---la¢i-8-10-3 <---laci-8-10-4 <---laci-8-7-1
special_inves¢isations.done <---la¢i-10-6-5 st eeZ.sl;rain.lLlt/aate.load <--- laci-10-2-4
sCra~.proporCiona I _dlstance.neutra1_axis
provisions 8.5.2 and 8.1.1. At an initial glance there appears to be no interconnectivity between these provisions. However, after some thought one can come to the following conclusion: 'Provision 8.1.1 defines the type of the member, whether prestressed or not. Thus, in effect it also defines the reinforcement type. Thus, if the member is nonprestressed then the reinforcement is also nonprestressed. Now, provision 8.5.2 deals with the modulus of elasticity of nonprestressed reinforcement and so it follows that the two provisions are interconnected.' Another example is the interconnection between ACI provisions 10.5.1 and 10.3.3. Again, at an initial glance there appears to be no relation between the two. However, after giving it some thought the following connection appears: 'Provision 10.5.1 performs the minimum reinforcement check and for doing so it requires the value of p which is computed in provision 10.3.3 and thus the two provisions are related'.
<--- I aci- 10-2-2
Figure 9 Tables of rules affected by a given variable
S U M M A R Y AND R E C O M M E N D A T I O N S FOR FUTURE ENHANCEMENTS information, not only would code revision be greatly facilitated, but (more importantly) code verification also. Thus those tables c~in also have an important pedagogical value. Despite their relevance, great care must be exercised in properly interpreting the previously discussed tables/trees. Upon closer examination with direct reference to the ACI code some apparent inconsistencies emerge. The tree structure reflects inter-connections between the various code provisions and should be interpreted as such. Instead of viewing it as, say, one rule or provision calling another provision, it should be viewed as a plain and simple inter-connection between the provisions, such that a change to one of the provisions may or may not induce a change in the connected one. Secondly, while going through the tree structure, one comes across certain connections which are very obvious and shallow. However, there are also certain connections which are not obvious and thus very deep, and some thought may be required to understand the reasoning process behind such connections. It is these types of connections which ought to be the primary concern of any code reviewing committee. • An example of a deep connection in our implementation is the connection between ACI
This paper has described the construction of a PC-based expert system for reinforced concrete design checking against the ACI 318-83 code provisions. The developed system consists of a knowledge base representing most of chapters 8-12 of the ACI code. Methods to facilitate data input and to summarize the conclusions of the consultation have been developed. It was found that for such a system to be accepted by engineers, a greater than expected emphasis must be placed on the user-interface. Finally, several observations concerning the complexity and ambiguity have been made. Following this easy implementation, current work is under way to: 1. Complete implementation of all the rules found in ACI 318-87 chapters 8 to 12. 2. Implement the knowledge base within a more powerful expert system shell (S1) which could run both on personal computers (with 2 Mb of extended memory) as well as on Unix workstations. 3. Make this knowledge base an integral part of a more general design program, such as those developed by Saouma et al. T M and Jones and SaoumaX3. Eng. Appli. of AI, 1989, Vol. 2, March
55
An expert-system-based code-compliance checker: V. E. Saouma et al.
ACKNOWLEDGEMENTS The authors wish to express their appreciation to the US Af'rny Corps of Engineers for funding under contract No. DACA39-86-K-0011. The assistance of Mr Mike Jones and Dr Mike Sikiotis in developing the knowledge base, and its review, is gratefully acknowledged. Finally, the authors would like to thank the Building System Task group for its numerous and constructive comments during early evaluation of this program, and Dr Radhakrishnan, chief of the Information Technology Laboratory for his enthusiastic support and encouragement.
REFERENCES ACI 318-1983, Building code requirements for reinforced concrete (ACI-318-83), American Concrete Institute, Detroit, MI (1987) 2 Fenves, S. J., Goel, S. K. and Gaylord, E. H., Decision table formulation of the AISC specification, Civil Engineering Studies, Structural Research Series No. 347, University of Illinois (1969) 3 Noland, J. L., Formulation of decision logic tables and their application to engineering specifications, Ph.D. thesis, University of Colorado, Boulder (1975) 1
56
Eng. Appli. of AI, 1989, Vol. 2, March
4 Noland, J. L., Decision logic table formulation of ACI 318-77 building code requirements for reinforced concrete for automated constraint processing, Technical Report ATC-86-5, prepared for the Department of the Army, US Army Corps of Engineers (July 1986) 5 Goel, S. K. and Fenves, S. J., Computer aided processing of structural design specifications, Civil Engineering Studies, Structural Research Series No. 348, University of lllinois, Urbana, IL (1969) 6 Garrett, J. H. and Fenves, S. J., A knowledge-based standards processor for structural component design~ Engineering with Computers, 2, pp. 219-238 (1987) 7 Rosenman, M. A. and Gero, J. S., Design codes as expert systems. Computer-Aided Design, 17(9), (1985) 8 Rosenman, M. A., Gero, J. S. and Oxman, R., An expert system for design codes and design rules, Applications of Artificial Intelligence to Engineering Problems (1986) 9 Harris, J. R. and Wright, R. N., Organization of building standards: Systematic techniques for scope and arrangement, NBS Building Science Series 136, National Engineering Laboratory, National Bureau of Standards, Washington, DC (1981) 10 Fenves, S. J., Rankin, K. R. and Tejuja, H. K.. The structure of building specifications, Building Science Series 90, Center for Building Technology, Institute for Applied Technology, National Bureau of Standards, Washington, DC (1976) 11 Saouma, V. E., Sikiotis, E. and Flango, R., Computer aided analysis and design of reinforced concrete buildings, Concrete International, 7(6), pp. 25-30 (1985) 12 Saouma, V. E., Sikiotis, E. S. and Commander, B., Integrated structural design system~ Interim Report to the US Army Corps of En#ineers (1988) 13 Jones, M. S. and Saouma, V. E., Prototype hybrid expert system for R/C design, Journal of Computing in Civil Engineering, ASCE, 2(2), pp. 136-143 (1988)