- Email: [email protected]
Rule-based applications for checking standards compliance of structural members
Building and Environment, Vol. 25, No. 3, pp. 235-240, 1990. Printed in Great Britain.
0360-1323/90 $3.00+0.00 © 1990 Pergamon Press ple.
Rule-Based Applications for Checking Standards Compliance of Structural Members PAUL M A R K EVANS* The Computer Group of Skidmore, Owings & Merrill began investigating the use of knowledge based systems in 1986. The structural programmers saw a great need for more extensibility, flexibility, and maintainability in programs for designing and checking code compliance of structural members. The resulting development effort brought about the design and implementation of a shell known as the Rule-Based Calculator. Five member design applications have been built with the Rule-Based Calculator. These include steel beam/columns, steel base plates, steel panel zone connections, concrete beams, and concrete columns. At the time of writing, these five applications near the end of testing and will soon be released for general use in the design studios. Herein, we document the reasons for this approach and our observations on the implementation process and its results.
of load combinations different than those specified by the ACI standard.
INTRODUCTION THERE WAS no single date or event which marked the decision to pursue knowledge-based systems in SOM structural computer applications. Instead, it was an evolving response to the problems of providing member design software for seven structural engineering offices designing some of the most challenging of building projects for sites around the world. It is worth noting that the source code for member design amounted to less than 5% of the total code for all structural applications. Despite its relatively small volume, it became apparent that we could never provide member design capabilities with the same level of quality and flexibility through traditional programming methods.
(2) Design standards are revised periodically. The major codes, such as ACI and AISC [2], undergo major revision at regular six year intervals, with minor annual ones. For those writing software of commercial quality, there is much more involved than reading the new standard, editing a few lines of F O R T R A N , and recompiling it. First, the revised code may not be adopted by governing jurisdictions for a substantial period of time, and may not be adopted at all by others. A developer faces critical and difficult decisions about the timing and number of upgrades to be released. Secondly, the changes to the standard and their side effects must be discovered. These effects usually fall into one of two categories. They are either subtle but far reaching, or drastic changes from the previous standard. Far reaching changes must be located throughout a large body of source code. Some will always be missed and can only be found through extensive testing. More drastic changes may require complete rewrites of parts of the source code. Inevitably, this work is performed by someone other than the original programmer and new errors are introduced.
THE NATURE OF THE BEAST Though smaller, member design applications present far more complex problems than either structural modelling, analysis, or data management. The difficulty lies not in their implementation but in the very nature of the beast. The characteristics of the problem which cause the most difficulty can be summarized as follows. (1) Materials, methods and standards of design differ from site to site. On the whole, the ACI 318-83 Building Code Requirements for Reinforced Concrete [1] are widely accepted. However, regional differences do exist. Our Los Angeles office, for example, has often been required to provide calculations for a set
(3) Despite their best efforts to be unambiguous, the standards are subject to multiple interpretations, often within a particular office. Section 10.8.4 of the ACI concrete standard is a good example of this. For column design, it permits a reduction of the computed gross area if it is much larger than the loads require. This paragraph is valuable because if effectively permits a reduction of the minimum reinforcement requirement from 1% to 0.5%. However, the ACI standard does not specify where the
* Formerly an Associate with the Computer Group of Skidmore, Owings & Merrill, Mr. Evans has now founded his own consulting group and can be contacted at Evans Software Consulting, Inc., P.O. Box 10511, Chicago, Illinois 60610, U.S.A. 235
236
P. M. Evans reduction in section is to be taken when computing its bending strength. In our Chicago office alone, several interpretations existed. As a result, two versions of the concrete column design program were implemented with two different interpretations.
(4) In some situations, the standards are incomplete and opinions about the unspecified areas differ from one engineer to another. Such gaps are often filled by "current practice" or advanced theories. These solutions vary from practice to practice and are subject to change more often than the accepted standards. For example, application of the AISC interaction equations to columns in unbraced building frames is problematic where the restrictions of the effective length nomograph are not exactly satisfied. Substantial theories have been advanced and most major offices have a procedure for dealing with the situation. However, because they do not want to set a precedent, our engineering staff would not include any such procedure in software that will be distributed outside of the firm. (5) The documentation requirement for member design programs is significantly greater than that of other engineering software. In our own experience, our inability to satisfy the engineering user's need for very detailed documentation forced us to spend a great deal of time fielding user questions. Often, it has been necessary for a member of the programming staff to spend hours reading FORTRAN source code to determine how an intermediate value was computed or whether a specific requirement was addressed. While these characteristics seem obvious to the practising structural engineer, they are frustrating and unacceptable to the software developer. On the other hand, the engineering user looks at the software that he has traditionally been given and sees unacceptably low levels of flexibility, extensibility, and maintainability. The licensed user of a purchased design program can neither fix known bugs nor extend the functionality or applicability of the program. The program author embeds individual interpretations or assumptions that remain hidden from the engineer. Even if they are fully documented, the end user cannot change them. Other than tricking the program by doctoring his input values, the engineer cannot adapt a program to his own practice. Traditional design programs rarely offer the flexibility to be used under multiple jurisdictions or standards. When used by multiple design offices, or even multiple engineers, the programs cannot accommodate differences in interpretations or varying serviceability requirements. Unfortunately, there is a very close match between the characteristics of the member design problem and the shortcomings of the traditional high level compiled language applications environment. Maintenance or enhancement is restricted to the owner of the source code, and then at considerable delay. Secondly, the strategies, heuristics, and assumptions upon which the software is based are not explicitly stated even in the source code.
They are only partially stated in the documentation or other material external to the program. IS T H E R E A B E T T E R WAY? We became constantly aware of the need for a better solution to this problem. We needed an automation technique that somehow managed to put the engineering aspects of the problem back into the hands of the end user. We wanted to give the user the ability to study and add to or modify the engineering embodied in the program so that it could accommodate his needs. Even if making such changes required a sophisticated user, it would be a strong step in the right direction. In addition, we believed that the end user would be willing to sacrifice significant runtime performance if his engineering needs were better accommodated. Our beliefs were reinforced by computing activity in the structural engineering group. Long ago, we installed personal computers in the structural studios. Each was installed with a group of software packages including our member design programs, a communications package, and a spreadsheet. On their own, the engineers soon learned how to utilize the communications package to download files of forces and geometry from the modelling systems on the VAX or the IBM RT workstations and load them into spreadsheets. Soon, they had developed spreadsheets for selecting governing members and formatting the information into input files for the member design programs. The next step was obvious to them. They formulated spreadsheets to perform their own member designs. The spreadsheets became common tools, passed around and modified from project to project. It seemed apparent to us that the engineers valued the ability to control their own design procedures more than the convenience and speed of integrated design software running on faster hardware. The spreadsheet environment provided them with the desired flexibility and extensibility, but it clearly did not address the issues of documentation, user support, nor maintainability. Complicated spreadsheet formulae, with little potential for mnemonic variable naming, would prove to be even harder to maintain and support in the long term. We needed a system that was as flexible and open as spreadsheets; had appropriate "hooks" to permit integration with the modelling, analysis, and data management tools ; was self documenting ; and was as fast and reliable as traditional compiled programs. WE PROPOSE A SOLUTION Some of the knowledge based techniques developing in the field of Artificial Intelligence looked like a close fit with our needs. By February 1987, a design had been finalized for a knowledge based system which would be used to build new member design applications. The system would use the rule paradigm for its knowledge representation, have an inference engine based upon production systems, communicate with relational data bases via SQL, and possess robust numeric capabilities. We named the system the Rule-Based Calculator.
Standards Compliance of Structural Members
temDoPar'y
q datastore
237
ptJle
table
linl erence engine~ ~1~ :1 [ ,
)poblem parser j~r]j executive "Pr'ob~/~......... file
,
(
)
Fig. 1. Schematic of the Rule-Based Calculator.
The engineering knowledge for each application using the Rule-Based Calculator is contained in external ASCII files of production rules. Their syntax is designed to be as English-like as possible. A rule contains a text string label for internal documentation. A paragraph of text with each rule explains the rule and can be printed during execution to provide a simple explanation facility. Variable names in the rules are unlimited strings of characters. Required key words are English words, the usual mathematical symbols, and mathematical function names similar to those in a programming language. Each of these parts can be seen in the following rule pulled from the knowledge base for designing steel beams and columns : RULE "Stress reduction factor, Qs, AISC equation C2-3" IF wfbf/(2 • wftf) > 95/SQRT(Fy) AND wfbf/(2 • wftf) < 176/SQRT(Fy) THEN Qs = 1.415-0.00437 * (wfbf, SQRT(Fy))/(2 * wftf) TEXT "The stress reduction factor Qs is computed directly from AISC equation C2-3 if the width-to-thickness ratio is less than 176 over the square root of the yield stress." This syntax results in a self documenting knowledge base which can be modified with standard text editors. The system design diagram of the Rule-Based Calculator is included as Fig. 1. The heavier black line indi-
cates the execution path. Lighter lines indicate the flow of data in the system. Heavier rectangles are modules of the program while the lighter ones are the key internal data structures. By providing for two files to contain the knowledge base and imposing a precedence system which considers which file each rule comes from, a two-tier model of the engineering knowledge is created. The file of lowest precedence, termed the Standards Definition File, contains rules which embody the requirements of the governing standard (e.g. AISC or ACI). Higher precedence is given to a Procedure Definition File which contains the rules defining procedures and heuristics. This design permits the engineer to supplement or override considerations of the standard without modifying the standards rules themselves. A problem input file contains simple assignment statements for any variables in the knowledge base to be used. Values entered here have the highest precedence. In addition to normal design operations, this provides the engineer with the same "what if" capability a spreadsheet has. The effects of any intermediate values can be studied by simply assigning the desired value and running the problem. The inference engine is backward chaining and goal
238
P. M. Erans
driven. Goals arc defined in the knowledge base. A typical goal might be proof that none of the allowable stresses is exceeded for any load case applied to a column. The inference engine searches for equations and values to support the goal in the same manner that a student would chain backward through the equations of the steel manual to determine what calculations he/she must do. The output from the inference process is defined by the author of the rules. The right hand side of rules can include instructions to write a template of output text. These text templates are also defined within the rule base files and can contain references to numeric variables. The references are replaced with the current value of the named variable when written. Data from relational data bases can be accessed or updated by including SQL commands in the right hand sides of the rules. For example, a set of relational tables stores standard rolled steel shapes. These are then accessed by a rule such as this : RULE "Selects wide flange characteristics from data base" IF true THEN SQL "'SELECTDISTINCT wfa, wfd, wftw, wfbf,wftf, wft, wfixx, wfsxx, wfrxx, wfiyy,wfsyy, wfryy FROM uswfnu WHERE wfnomd=rbcval(wfnomd) AND wfnomwgt= rbcval(wfnomwgt)" TEXT "The characteristics of the particular wide flangeshape are obtained from an SQL data base table of steel shapes." The basic graphics system provides similar capabilities and other SOM applications make extensive use of relational data bases. The system operates in either batch or interactive modes. Batch mode can be used for processing large numbers of members. The interactive mode provides an environment for testing new rules or studying standards or procedures. When used under X-windows, the system has a multiple window interface with pop-up menus and interactive forms. Final output and trace output can be reviewed in scrollable text windows. A series of graphing options permits the user to see line plots, histograms, dials, or bar graphs which reflect the changing status of knowledge base variables.
BUILDING THE RULE-BASED CALCULATOR
The detailed design of the Rule-Based Calculator had been specified in February. A technical specification was prepared and production coding began in April of 1987. One programmer worked full time to code the system in the "C" language. A parallel "fast track" approach to the rule production was also underway in order to make rules available for testing as soon as possible when the Rule-Based Calculator became operational. This approach turned out to be very valuable when it pointed out deficiencies in the system design early in the coding phase, instead of during the later testing phases. In two distinct phases, substantial additional capabilities were added to the scope of the Rule-Based Calculator. Without discovering these deficiencies during the coding phase, the project would have been far behind schedule. The revisions required of the Rule-Based Calculator, even as extensive as they were, could reasonably be expected of new software that implements a new
approach. The design of beams and columns, on the other hand, is seen as a much more mature and defined science. It was tfierelbre quite surprising to discover the amount of time required to define the essential engineering knowledge that was to be implemented in the design applications. IMPLEMENTING THE FIRST KNOWLEDGE BASES
In the initial round, five member-design applications were planned. These included steel beams and columns, steel base plates, steel panel zone connections, concrete beams, and concrete columns. We wanted to utilize the same development process l\~r the engineering design that we would use for our software. This meant developing a written technical specification before writing the final rules. A team of structural engineers would produce the detailed paper. Structural programmers would translate the equations and procedures of this position paper into the production rule format of the Rule-Based Calculator. This would be our form of "'knowledge engineering" for the first applications. In December of 1986, a team of six structural engineers began discussing the design procedures to be included. As coding of the Rule-Based Calculator began, the problem areas within each of the design procedures and various approaches to their solution had bccn identified. Additional outside experts were contracted in the spring and the group was collectively producing the detailed papers documenting their design requirements for each application. In our fast track approach, a structural programmer began writing the corresponding rules while the design papers were still in progress. Even though the Rule-Based Calculator was not yet functional as he began, the specifications had defined the syntax and capabilities. His task was to perform a fairly straightforward translation of the design position papers into production rule form. As he did so, he discovered areas where the paper was logically incomplete or contradictory. In these cases, he acted in the more typical role of the knowledge engineer and interacted with the structural engineering team to obtain more information. The engineers completed first drafts of the design position papers in the months of June and July seven months after beginning them. The design position papers were never expected to take even this long and yet debates continued over some major sections. The first round of extensive modifications to the Rule-Based Calculator was completed later in the summer. October was the next milestone. By the middle of the month, we had designed the second set of revisions to the Rule-Based Calculator and were beginning to code them. The engineering team had set a deadline for finishing up final versions of the design papers at the end of the month. Winter saw continuing changes to the design position papers and a complete replacement of the staff assigned to writing the rules. The original rule programmer left the firm and the rules were started over from scratch. As the Spring of 1988 approached, there was a dramatic increase in productivity. The multiple window
Standards Compliance of Structural Members interface and trace options of the substantially completed Rule-Based Calculator provided a very good development environment for the rules. The new rule authors had previous experience with rule based civil applications and, as a team, we had six months of experience in the art of rule writing. Because the design position papers were to be included in the final documentation, the documentation staff set a new deadline of 1 April for final changes. Changes to the engineering requirements continue and the author is now convinced that the engineering documents will continue to be revised until they go to the printers. At this point (July 1988), the Rule-Based Calculator and the rule bases for all five applications are in the hands of practising engineers for testing. Now that the applications are producing correct answers, what observations can be made about the success of the project and the knowledge-based approach? WHY ISN'T EVERYONE HAPPY? First, from a technical standpoint, the project has been a success. The design of the Rule-Based Calculator grew through the implementation and became far more powerful than its initial scope. The project has demonstrated that it is possible to do real engineering design with this approach. In one case, the rule base produces answers that are correct, but are from 1% to 10% offthe optimum solution. In this case, the engineers have been unable to provide a heuristic for their refinement of the design. Their hand calcs use a brute force, trial and error method that is not suited to rules. But the success of an effort like this cannot be judged on technical merit alone. Here, in the real world of a design practice, the most critical measure of success is whether the system gains acceptance and use by the user community. It is still too early to make this assessment, but one can learn from the results thus far. The most important observation to make is that the engineers who should be using the system are not very happy with it at this point. They agree that it is technically correct and producing sound answers. (Bugs are still being found, but are being fixed as fast as they are found.) Their critical concern is the runtime performance of the system. The system runs the simplest of problems, such as base plates or panel zones, in less than 50 s. Steel beams and columns require from 2 to 6 min for most cases, up to 20 rain for ill-formed problems with a very poor initial section guess. Concrete column design requires upwards of 10 rain and increases linearly with the number of bars required in the cross section. Obviously, these times are going to disappoint someone who is used to traditional design programs running in less than 1 or 2 s, However, those engineers who have been involved in the development effort quickly point out that these rules are doing far more extensive design than the old programs were. For example, the steel rules consider 18 load combinations and the concrete rules consider 24 load combinations. The concrete column rules compute interaction diagrams based on exact bar stresses for each bar and about each axis. These times are accurate as of the end of the first testing phase. Little effort has gone into optimizing the runtime 8AE ~5:3-D
239
performance of the Rule-Based Calculator itself at this time. We believe that it is more important to make a system work completely and accurately first, before putting effort into its optimization. Improvements by a factor of two to four times are not uncommon in our work. In the particularly large set of rules for concrete column design, an effort has been made to optimize the rules themselves, resulting in threefold improvements. On the other hand, the computer side of the development team has been quite frustrated with the engineering progress. Though the programming staff have engineering or architecture degrees, they cannot understand how engineers could require 16-18 months to describe design processes for members that they must design every day. In fact, the engineers perceived their assignment in the position papers to be a complete and thorough dissertation on all possible design circumstances. Months were spent on aspects of the problems that would not be considered in manual calculations. We have discovered in many past debates that there are two schools of thought among structural engineers when they consider automating some design process. One position holds that you merely translate whatever you did by hand into the computer application. If it was good enough for hand calcs, it is equally valid for the machine, just faster. The opposite position says that if you are going to go to the trouble of programming it, program the most exact and detailed solution--take full advantage of the machine. Knowledge based systems are well suited to the first approach. They thrive on heuristics and short-cuts. The second position is much more amenable to the conventional algorithmic compiled language approach. Lastly, there is some concern that the maintainability issue that we were trying to resolve may not be as well addressed by the Rule-Based Calculator as we had wished. The extensive revisions which we referred to in the Rule-Based Calculator involved adding an extensive capability for dealing with vector variables. This capability allowed us to use variables with attached instance lists to represent multiple instances of an item or situation in the knowledge base (e.g. load combinations or reinforcing bars). We could then write rules containing vector variables which were really a shorthand for multiple rules or cases where looping constructs were needed. In some cases, there are complex relationships between multiple vector variables. In such cases, the rule syntax can become obscure or "control" variables may be required in order to force the proper firing of rules. It is not clear that these constructs will be easier to maintain than the equivalent high level language code. Currently, the programmer familiar with the set of rules can make changes or additions very quickly, faster than if it were in a compiled language. However, because of these relatively complex constructs, an unfamiliar programmer may not realize the potential side effects of changing portions of these rules. Our worst fear is that it takes as much effort to discover how one of the most complex sets of rules work as it does to investigate the equivalent high level language. Again, it is too early to make this evaluation. Some experience with maintenance of older rules is needed.
240
P . M . Erans CONCLUSIONS
We have demonstrated the technical feasibility o1" applying the rule based programming paradigm to the problems of structural member design and standards compliance checking. The aim of the approach was to enhance flexibility, adaptability, and maintainabilityover the traditional compiled high level language applications. The new system is far more flexible, permitting end users or third parties to author their own rule bases, or adapt existing ones, to their own needs. Their own design procedure is then integrated with the modelling and analysis portions of the complete structural software package. Though first impressions are favorable, the degree to which maintainability has been improved remains to be judged as the first applications age. It was noted that some complex relations within the engineering procedures required adding considerable capabilities to the Rule-Based Calculator beyond the initial system design. The nature o1" the engineering procedures pushes the limits of the rule paradigm. The syntax added to accommodate these needs led to some obscurity and some concern about the maintainability of the resulting rules. Whether calculating by hand or using any programming method, a thorough detailed design considering all possible complications and their checks will take longer than one where heuristics and problem specific knowledge are applied. This is the difference between the engineer who translates his manual methods into software and the one who develops an algorithm or a checklist to consider all possible complications. Because they order the solution at runtime instead of during the coding, knowledge-based systems run perhaps two orders of magnitude slower than compiled languages in today's hardware environment. Therefore, a procedure that is three times longer will hardly be noticed in compiled languages, but will be intolerable in a knowledge-based system. This leads to a discussion that is critical to the success of a knowledge-based project. The project will only be successful when the persons involved understand that
they need deal only with the variables (fl the problem domain and the relationships between them. A programmer or engineer who has experience in compiled languages (engineers are taught conventional programming in most curriculums) will try to stay in the algorithmic mode. If so, he:she will find rule based programming a source of great frustration and probably give up. If he/she doesn't give up, he/she will Force the rules into stepwisc procedures by adding lots of "'control'" wtriables and logic. This resuhs in nothing more than a slow algorithm that is no more adaptable or flexible than compiled languages. Our first rule author struggled along with his/her algorithmic mindset lbr nine months and had bits and pieces of the applications running. The second rule author had previous experience with rule based programming and produced a full set of rules t)r base plate design in three weeks. Fhc same mindset problem manifests itseff in the experts who are the source of the application knowledge. In trying to be as helpful as possible, the engineering team kept answering questions and describing the engineering solutions in algorithmic terms, even going so far as to speak of"do-loops'" and "big if statements". The tremendous value of a good knowledge engineer lies in his ability to extract the essential relationships of the problem domain from these abstract explanations of the expert. Despite the difficulties we lhce, poor runtime performance and the algorithmic mindset, thc project has been an important step in the right direction. The essential element of knowledge based systems is critical to the success of those engineering applications which are intended for a very large audience. That user community has more difl'ering needs and procedures than can be anticipated by the developer of a single piece of software. It is not my intention to say thai the rule based paradigm is the only or best answer. Rather, that the Artificial Intelligence way of looking at applications knowledge as data, external and changeablc in the end user environment needs to be adopted more widely in AEC industry software, It is essential l\)r any package that intends to address the non-graphic design needs of more than a few installations.
REFERENCES 1. American Concrete Institute. Buihling Code Requiremenm [i," Rein[orced ('oncren' (ACI 318-83). Detroit, Michigan (1983). 2. American Institute of Steel Construction, Inc.. Manual o[Steel Construction, 8a~edn. Chicago, Illinois (1980).
0360-1323/90 $3.00+0.00 © 1990 Pergamon Press ple.
Rule-Based Applications for Checking Standards Compliance of Structural Members PAUL M A R K EVANS* The Computer Group of Skidmore, Owings & Merrill began investigating the use of knowledge based systems in 1986. The structural programmers saw a great need for more extensibility, flexibility, and maintainability in programs for designing and checking code compliance of structural members. The resulting development effort brought about the design and implementation of a shell known as the Rule-Based Calculator. Five member design applications have been built with the Rule-Based Calculator. These include steel beam/columns, steel base plates, steel panel zone connections, concrete beams, and concrete columns. At the time of writing, these five applications near the end of testing and will soon be released for general use in the design studios. Herein, we document the reasons for this approach and our observations on the implementation process and its results.
of load combinations different than those specified by the ACI standard.
INTRODUCTION THERE WAS no single date or event which marked the decision to pursue knowledge-based systems in SOM structural computer applications. Instead, it was an evolving response to the problems of providing member design software for seven structural engineering offices designing some of the most challenging of building projects for sites around the world. It is worth noting that the source code for member design amounted to less than 5% of the total code for all structural applications. Despite its relatively small volume, it became apparent that we could never provide member design capabilities with the same level of quality and flexibility through traditional programming methods.
(2) Design standards are revised periodically. The major codes, such as ACI and AISC [2], undergo major revision at regular six year intervals, with minor annual ones. For those writing software of commercial quality, there is much more involved than reading the new standard, editing a few lines of F O R T R A N , and recompiling it. First, the revised code may not be adopted by governing jurisdictions for a substantial period of time, and may not be adopted at all by others. A developer faces critical and difficult decisions about the timing and number of upgrades to be released. Secondly, the changes to the standard and their side effects must be discovered. These effects usually fall into one of two categories. They are either subtle but far reaching, or drastic changes from the previous standard. Far reaching changes must be located throughout a large body of source code. Some will always be missed and can only be found through extensive testing. More drastic changes may require complete rewrites of parts of the source code. Inevitably, this work is performed by someone other than the original programmer and new errors are introduced.
THE NATURE OF THE BEAST Though smaller, member design applications present far more complex problems than either structural modelling, analysis, or data management. The difficulty lies not in their implementation but in the very nature of the beast. The characteristics of the problem which cause the most difficulty can be summarized as follows. (1) Materials, methods and standards of design differ from site to site. On the whole, the ACI 318-83 Building Code Requirements for Reinforced Concrete [1] are widely accepted. However, regional differences do exist. Our Los Angeles office, for example, has often been required to provide calculations for a set
(3) Despite their best efforts to be unambiguous, the standards are subject to multiple interpretations, often within a particular office. Section 10.8.4 of the ACI concrete standard is a good example of this. For column design, it permits a reduction of the computed gross area if it is much larger than the loads require. This paragraph is valuable because if effectively permits a reduction of the minimum reinforcement requirement from 1% to 0.5%. However, the ACI standard does not specify where the
* Formerly an Associate with the Computer Group of Skidmore, Owings & Merrill, Mr. Evans has now founded his own consulting group and can be contacted at Evans Software Consulting, Inc., P.O. Box 10511, Chicago, Illinois 60610, U.S.A. 235
236
P. M. Evans reduction in section is to be taken when computing its bending strength. In our Chicago office alone, several interpretations existed. As a result, two versions of the concrete column design program were implemented with two different interpretations.
(4) In some situations, the standards are incomplete and opinions about the unspecified areas differ from one engineer to another. Such gaps are often filled by "current practice" or advanced theories. These solutions vary from practice to practice and are subject to change more often than the accepted standards. For example, application of the AISC interaction equations to columns in unbraced building frames is problematic where the restrictions of the effective length nomograph are not exactly satisfied. Substantial theories have been advanced and most major offices have a procedure for dealing with the situation. However, because they do not want to set a precedent, our engineering staff would not include any such procedure in software that will be distributed outside of the firm. (5) The documentation requirement for member design programs is significantly greater than that of other engineering software. In our own experience, our inability to satisfy the engineering user's need for very detailed documentation forced us to spend a great deal of time fielding user questions. Often, it has been necessary for a member of the programming staff to spend hours reading FORTRAN source code to determine how an intermediate value was computed or whether a specific requirement was addressed. While these characteristics seem obvious to the practising structural engineer, they are frustrating and unacceptable to the software developer. On the other hand, the engineering user looks at the software that he has traditionally been given and sees unacceptably low levels of flexibility, extensibility, and maintainability. The licensed user of a purchased design program can neither fix known bugs nor extend the functionality or applicability of the program. The program author embeds individual interpretations or assumptions that remain hidden from the engineer. Even if they are fully documented, the end user cannot change them. Other than tricking the program by doctoring his input values, the engineer cannot adapt a program to his own practice. Traditional design programs rarely offer the flexibility to be used under multiple jurisdictions or standards. When used by multiple design offices, or even multiple engineers, the programs cannot accommodate differences in interpretations or varying serviceability requirements. Unfortunately, there is a very close match between the characteristics of the member design problem and the shortcomings of the traditional high level compiled language applications environment. Maintenance or enhancement is restricted to the owner of the source code, and then at considerable delay. Secondly, the strategies, heuristics, and assumptions upon which the software is based are not explicitly stated even in the source code.
They are only partially stated in the documentation or other material external to the program. IS T H E R E A B E T T E R WAY? We became constantly aware of the need for a better solution to this problem. We needed an automation technique that somehow managed to put the engineering aspects of the problem back into the hands of the end user. We wanted to give the user the ability to study and add to or modify the engineering embodied in the program so that it could accommodate his needs. Even if making such changes required a sophisticated user, it would be a strong step in the right direction. In addition, we believed that the end user would be willing to sacrifice significant runtime performance if his engineering needs were better accommodated. Our beliefs were reinforced by computing activity in the structural engineering group. Long ago, we installed personal computers in the structural studios. Each was installed with a group of software packages including our member design programs, a communications package, and a spreadsheet. On their own, the engineers soon learned how to utilize the communications package to download files of forces and geometry from the modelling systems on the VAX or the IBM RT workstations and load them into spreadsheets. Soon, they had developed spreadsheets for selecting governing members and formatting the information into input files for the member design programs. The next step was obvious to them. They formulated spreadsheets to perform their own member designs. The spreadsheets became common tools, passed around and modified from project to project. It seemed apparent to us that the engineers valued the ability to control their own design procedures more than the convenience and speed of integrated design software running on faster hardware. The spreadsheet environment provided them with the desired flexibility and extensibility, but it clearly did not address the issues of documentation, user support, nor maintainability. Complicated spreadsheet formulae, with little potential for mnemonic variable naming, would prove to be even harder to maintain and support in the long term. We needed a system that was as flexible and open as spreadsheets; had appropriate "hooks" to permit integration with the modelling, analysis, and data management tools ; was self documenting ; and was as fast and reliable as traditional compiled programs. WE PROPOSE A SOLUTION Some of the knowledge based techniques developing in the field of Artificial Intelligence looked like a close fit with our needs. By February 1987, a design had been finalized for a knowledge based system which would be used to build new member design applications. The system would use the rule paradigm for its knowledge representation, have an inference engine based upon production systems, communicate with relational data bases via SQL, and possess robust numeric capabilities. We named the system the Rule-Based Calculator.
Standards Compliance of Structural Members
temDoPar'y
q datastore
237
ptJle
table
linl erence engine~ ~1~ :1 [ ,
)poblem parser j~r]j executive "Pr'ob~/~......... file
,
(
)
Fig. 1. Schematic of the Rule-Based Calculator.
The engineering knowledge for each application using the Rule-Based Calculator is contained in external ASCII files of production rules. Their syntax is designed to be as English-like as possible. A rule contains a text string label for internal documentation. A paragraph of text with each rule explains the rule and can be printed during execution to provide a simple explanation facility. Variable names in the rules are unlimited strings of characters. Required key words are English words, the usual mathematical symbols, and mathematical function names similar to those in a programming language. Each of these parts can be seen in the following rule pulled from the knowledge base for designing steel beams and columns : RULE "Stress reduction factor, Qs, AISC equation C2-3" IF wfbf/(2 • wftf) > 95/SQRT(Fy) AND wfbf/(2 • wftf) < 176/SQRT(Fy) THEN Qs = 1.415-0.00437 * (wfbf, SQRT(Fy))/(2 * wftf) TEXT "The stress reduction factor Qs is computed directly from AISC equation C2-3 if the width-to-thickness ratio is less than 176 over the square root of the yield stress." This syntax results in a self documenting knowledge base which can be modified with standard text editors. The system design diagram of the Rule-Based Calculator is included as Fig. 1. The heavier black line indi-
cates the execution path. Lighter lines indicate the flow of data in the system. Heavier rectangles are modules of the program while the lighter ones are the key internal data structures. By providing for two files to contain the knowledge base and imposing a precedence system which considers which file each rule comes from, a two-tier model of the engineering knowledge is created. The file of lowest precedence, termed the Standards Definition File, contains rules which embody the requirements of the governing standard (e.g. AISC or ACI). Higher precedence is given to a Procedure Definition File which contains the rules defining procedures and heuristics. This design permits the engineer to supplement or override considerations of the standard without modifying the standards rules themselves. A problem input file contains simple assignment statements for any variables in the knowledge base to be used. Values entered here have the highest precedence. In addition to normal design operations, this provides the engineer with the same "what if" capability a spreadsheet has. The effects of any intermediate values can be studied by simply assigning the desired value and running the problem. The inference engine is backward chaining and goal
238
P. M. Erans
driven. Goals arc defined in the knowledge base. A typical goal might be proof that none of the allowable stresses is exceeded for any load case applied to a column. The inference engine searches for equations and values to support the goal in the same manner that a student would chain backward through the equations of the steel manual to determine what calculations he/she must do. The output from the inference process is defined by the author of the rules. The right hand side of rules can include instructions to write a template of output text. These text templates are also defined within the rule base files and can contain references to numeric variables. The references are replaced with the current value of the named variable when written. Data from relational data bases can be accessed or updated by including SQL commands in the right hand sides of the rules. For example, a set of relational tables stores standard rolled steel shapes. These are then accessed by a rule such as this : RULE "Selects wide flange characteristics from data base" IF true THEN SQL "'SELECTDISTINCT wfa, wfd, wftw, wfbf,wftf, wft, wfixx, wfsxx, wfrxx, wfiyy,wfsyy, wfryy FROM uswfnu WHERE wfnomd=rbcval(wfnomd) AND wfnomwgt= rbcval(wfnomwgt)" TEXT "The characteristics of the particular wide flangeshape are obtained from an SQL data base table of steel shapes." The basic graphics system provides similar capabilities and other SOM applications make extensive use of relational data bases. The system operates in either batch or interactive modes. Batch mode can be used for processing large numbers of members. The interactive mode provides an environment for testing new rules or studying standards or procedures. When used under X-windows, the system has a multiple window interface with pop-up menus and interactive forms. Final output and trace output can be reviewed in scrollable text windows. A series of graphing options permits the user to see line plots, histograms, dials, or bar graphs which reflect the changing status of knowledge base variables.
BUILDING THE RULE-BASED CALCULATOR
The detailed design of the Rule-Based Calculator had been specified in February. A technical specification was prepared and production coding began in April of 1987. One programmer worked full time to code the system in the "C" language. A parallel "fast track" approach to the rule production was also underway in order to make rules available for testing as soon as possible when the Rule-Based Calculator became operational. This approach turned out to be very valuable when it pointed out deficiencies in the system design early in the coding phase, instead of during the later testing phases. In two distinct phases, substantial additional capabilities were added to the scope of the Rule-Based Calculator. Without discovering these deficiencies during the coding phase, the project would have been far behind schedule. The revisions required of the Rule-Based Calculator, even as extensive as they were, could reasonably be expected of new software that implements a new
approach. The design of beams and columns, on the other hand, is seen as a much more mature and defined science. It was tfierelbre quite surprising to discover the amount of time required to define the essential engineering knowledge that was to be implemented in the design applications. IMPLEMENTING THE FIRST KNOWLEDGE BASES
In the initial round, five member-design applications were planned. These included steel beams and columns, steel base plates, steel panel zone connections, concrete beams, and concrete columns. We wanted to utilize the same development process l\~r the engineering design that we would use for our software. This meant developing a written technical specification before writing the final rules. A team of structural engineers would produce the detailed paper. Structural programmers would translate the equations and procedures of this position paper into the production rule format of the Rule-Based Calculator. This would be our form of "'knowledge engineering" for the first applications. In December of 1986, a team of six structural engineers began discussing the design procedures to be included. As coding of the Rule-Based Calculator began, the problem areas within each of the design procedures and various approaches to their solution had bccn identified. Additional outside experts were contracted in the spring and the group was collectively producing the detailed papers documenting their design requirements for each application. In our fast track approach, a structural programmer began writing the corresponding rules while the design papers were still in progress. Even though the Rule-Based Calculator was not yet functional as he began, the specifications had defined the syntax and capabilities. His task was to perform a fairly straightforward translation of the design position papers into production rule form. As he did so, he discovered areas where the paper was logically incomplete or contradictory. In these cases, he acted in the more typical role of the knowledge engineer and interacted with the structural engineering team to obtain more information. The engineers completed first drafts of the design position papers in the months of June and July seven months after beginning them. The design position papers were never expected to take even this long and yet debates continued over some major sections. The first round of extensive modifications to the Rule-Based Calculator was completed later in the summer. October was the next milestone. By the middle of the month, we had designed the second set of revisions to the Rule-Based Calculator and were beginning to code them. The engineering team had set a deadline for finishing up final versions of the design papers at the end of the month. Winter saw continuing changes to the design position papers and a complete replacement of the staff assigned to writing the rules. The original rule programmer left the firm and the rules were started over from scratch. As the Spring of 1988 approached, there was a dramatic increase in productivity. The multiple window
Standards Compliance of Structural Members interface and trace options of the substantially completed Rule-Based Calculator provided a very good development environment for the rules. The new rule authors had previous experience with rule based civil applications and, as a team, we had six months of experience in the art of rule writing. Because the design position papers were to be included in the final documentation, the documentation staff set a new deadline of 1 April for final changes. Changes to the engineering requirements continue and the author is now convinced that the engineering documents will continue to be revised until they go to the printers. At this point (July 1988), the Rule-Based Calculator and the rule bases for all five applications are in the hands of practising engineers for testing. Now that the applications are producing correct answers, what observations can be made about the success of the project and the knowledge-based approach? WHY ISN'T EVERYONE HAPPY? First, from a technical standpoint, the project has been a success. The design of the Rule-Based Calculator grew through the implementation and became far more powerful than its initial scope. The project has demonstrated that it is possible to do real engineering design with this approach. In one case, the rule base produces answers that are correct, but are from 1% to 10% offthe optimum solution. In this case, the engineers have been unable to provide a heuristic for their refinement of the design. Their hand calcs use a brute force, trial and error method that is not suited to rules. But the success of an effort like this cannot be judged on technical merit alone. Here, in the real world of a design practice, the most critical measure of success is whether the system gains acceptance and use by the user community. It is still too early to make this assessment, but one can learn from the results thus far. The most important observation to make is that the engineers who should be using the system are not very happy with it at this point. They agree that it is technically correct and producing sound answers. (Bugs are still being found, but are being fixed as fast as they are found.) Their critical concern is the runtime performance of the system. The system runs the simplest of problems, such as base plates or panel zones, in less than 50 s. Steel beams and columns require from 2 to 6 min for most cases, up to 20 rain for ill-formed problems with a very poor initial section guess. Concrete column design requires upwards of 10 rain and increases linearly with the number of bars required in the cross section. Obviously, these times are going to disappoint someone who is used to traditional design programs running in less than 1 or 2 s, However, those engineers who have been involved in the development effort quickly point out that these rules are doing far more extensive design than the old programs were. For example, the steel rules consider 18 load combinations and the concrete rules consider 24 load combinations. The concrete column rules compute interaction diagrams based on exact bar stresses for each bar and about each axis. These times are accurate as of the end of the first testing phase. Little effort has gone into optimizing the runtime 8AE ~5:3-D
239
performance of the Rule-Based Calculator itself at this time. We believe that it is more important to make a system work completely and accurately first, before putting effort into its optimization. Improvements by a factor of two to four times are not uncommon in our work. In the particularly large set of rules for concrete column design, an effort has been made to optimize the rules themselves, resulting in threefold improvements. On the other hand, the computer side of the development team has been quite frustrated with the engineering progress. Though the programming staff have engineering or architecture degrees, they cannot understand how engineers could require 16-18 months to describe design processes for members that they must design every day. In fact, the engineers perceived their assignment in the position papers to be a complete and thorough dissertation on all possible design circumstances. Months were spent on aspects of the problems that would not be considered in manual calculations. We have discovered in many past debates that there are two schools of thought among structural engineers when they consider automating some design process. One position holds that you merely translate whatever you did by hand into the computer application. If it was good enough for hand calcs, it is equally valid for the machine, just faster. The opposite position says that if you are going to go to the trouble of programming it, program the most exact and detailed solution--take full advantage of the machine. Knowledge based systems are well suited to the first approach. They thrive on heuristics and short-cuts. The second position is much more amenable to the conventional algorithmic compiled language approach. Lastly, there is some concern that the maintainability issue that we were trying to resolve may not be as well addressed by the Rule-Based Calculator as we had wished. The extensive revisions which we referred to in the Rule-Based Calculator involved adding an extensive capability for dealing with vector variables. This capability allowed us to use variables with attached instance lists to represent multiple instances of an item or situation in the knowledge base (e.g. load combinations or reinforcing bars). We could then write rules containing vector variables which were really a shorthand for multiple rules or cases where looping constructs were needed. In some cases, there are complex relationships between multiple vector variables. In such cases, the rule syntax can become obscure or "control" variables may be required in order to force the proper firing of rules. It is not clear that these constructs will be easier to maintain than the equivalent high level language code. Currently, the programmer familiar with the set of rules can make changes or additions very quickly, faster than if it were in a compiled language. However, because of these relatively complex constructs, an unfamiliar programmer may not realize the potential side effects of changing portions of these rules. Our worst fear is that it takes as much effort to discover how one of the most complex sets of rules work as it does to investigate the equivalent high level language. Again, it is too early to make this evaluation. Some experience with maintenance of older rules is needed.
240
P . M . Erans CONCLUSIONS
We have demonstrated the technical feasibility o1" applying the rule based programming paradigm to the problems of structural member design and standards compliance checking. The aim of the approach was to enhance flexibility, adaptability, and maintainabilityover the traditional compiled high level language applications. The new system is far more flexible, permitting end users or third parties to author their own rule bases, or adapt existing ones, to their own needs. Their own design procedure is then integrated with the modelling and analysis portions of the complete structural software package. Though first impressions are favorable, the degree to which maintainability has been improved remains to be judged as the first applications age. It was noted that some complex relations within the engineering procedures required adding considerable capabilities to the Rule-Based Calculator beyond the initial system design. The nature o1" the engineering procedures pushes the limits of the rule paradigm. The syntax added to accommodate these needs led to some obscurity and some concern about the maintainability of the resulting rules. Whether calculating by hand or using any programming method, a thorough detailed design considering all possible complications and their checks will take longer than one where heuristics and problem specific knowledge are applied. This is the difference between the engineer who translates his manual methods into software and the one who develops an algorithm or a checklist to consider all possible complications. Because they order the solution at runtime instead of during the coding, knowledge-based systems run perhaps two orders of magnitude slower than compiled languages in today's hardware environment. Therefore, a procedure that is three times longer will hardly be noticed in compiled languages, but will be intolerable in a knowledge-based system. This leads to a discussion that is critical to the success of a knowledge-based project. The project will only be successful when the persons involved understand that
they need deal only with the variables (fl the problem domain and the relationships between them. A programmer or engineer who has experience in compiled languages (engineers are taught conventional programming in most curriculums) will try to stay in the algorithmic mode. If so, he:she will find rule based programming a source of great frustration and probably give up. If he/she doesn't give up, he/she will Force the rules into stepwisc procedures by adding lots of "'control'" wtriables and logic. This resuhs in nothing more than a slow algorithm that is no more adaptable or flexible than compiled languages. Our first rule author struggled along with his/her algorithmic mindset lbr nine months and had bits and pieces of the applications running. The second rule author had previous experience with rule based programming and produced a full set of rules t)r base plate design in three weeks. Fhc same mindset problem manifests itseff in the experts who are the source of the application knowledge. In trying to be as helpful as possible, the engineering team kept answering questions and describing the engineering solutions in algorithmic terms, even going so far as to speak of"do-loops'" and "big if statements". The tremendous value of a good knowledge engineer lies in his ability to extract the essential relationships of the problem domain from these abstract explanations of the expert. Despite the difficulties we lhce, poor runtime performance and the algorithmic mindset, thc project has been an important step in the right direction. The essential element of knowledge based systems is critical to the success of those engineering applications which are intended for a very large audience. That user community has more difl'ering needs and procedures than can be anticipated by the developer of a single piece of software. It is not my intention to say thai the rule based paradigm is the only or best answer. Rather, that the Artificial Intelligence way of looking at applications knowledge as data, external and changeablc in the end user environment needs to be adopted more widely in AEC industry software, It is essential l\)r any package that intends to address the non-graphic design needs of more than a few installations.
REFERENCES 1. American Concrete Institute. Buihling Code Requiremenm [i," Rein[orced ('oncren' (ACI 318-83). Detroit, Michigan (1983). 2. American Institute of Steel Construction, Inc.. Manual o[Steel Construction, 8a~edn. Chicago, Illinois (1980).