Knowledge Acquisition and Knowledge Structure for the Safety First Expert System

Carlos A. Vargas and Fabian C. Hadipriono

Department of Civil Engineering

Ohio State University

Columbus, Ohio

Introduction

In the United States, construction fall accidents have been identified as a leading cause of construction injuries and deaths. Furthermore, OSHA has found that falls make up about 33 % of all construction-related fatalities [Korman et al. 19901. This trend has prevailed despite attempts by government regulatory agencies and industry-related groups to reverse it.

The first step in solving this problem is the identification of the causes of these fall accidents. Once this is done, both construction companies and government agencies will be able to focus their attention on the "weak links" (problem areas) of construction sites and take the corresponding safety measures to prevent their occurrence. As a consequence, the number of disabling and fatal injuries in construction sites may be reduced substantially.

Unfortunately, the causes of construction falls are seldom discussed in detail in the existing literature. In addition, experts' knowledge and experience are too rarely used in investigating the causes of construction falls. Both of these factors prompted the development of SAFETY FIRST, an expert system whose objective is to assist in the determination of the causes of fall accidents. This work is based on an earlier study used to develop FTES FALL, a fault tree expert system prototype developed for falls investigation [Hadipriono 1992]. The earlier and most important stages in developing this system are the identification of the causes of fall accidents in the construction industry (i.e., knowledge acquisition) and the representation of this knowledge in the form of fault tree structures (i.e., knowledge representation). Although these~stages are the focus of this paper, a discussion of the architecture of SAFETY FIRST is essential to illustrate their importance to the development process.

The Architecture of Safety First

The SAFETY FIRST expert system has two main functions: to determine the cause(s) of a fall accident that has already occurred and to identify potential problem areas (weak links) regarding fall safety in a construction site. To perform these tasks, the system consists of five main components: the knowledge base, the inference engine, the user interface, the external files interface, and the external files (Figure 1). The first four components are all contained within the Level 5 Object expert shell selected to develop the system. This shell was selected because it provides all the necessary facilities to assist the developer in the construction of the knowledge base, and, fiuther more, it allows for the development of a user-friendly program.

The knowledge base contains all the knowledge obtain from the experts regarding the causes of construction fall and the process they follow to identify these causes (mainly heuristic knowledge). This knowledge is represented b using fault tree structures which can be represented in the system's knowledge base by a combination of production rules and objects.

All of the events and causes in the fault tree knowledge structure are represented as either classes, attributes, or instances in the knowledge base, while the logical or empirical relationships among these events or causes are represented in the knowledge base by using production rules.

In order to reach a conclusion (causes of a fall accident or weak links in a construction site), the system needs to know the conditions in the construction site at the time the fall occurred or the current safety conditions in the site being evaluated. This is the main task of the user interface r mechanism: prompting the user for the information required to solve a problem. Other tasks of this component are to provide help to the user, to explain why a given conclusion has been reached, and to provide recommendations on how to avoid future fall occurrences. To do this, the user interface has to be able to interact with all the other modules of the system. It interacts with the inference engine and the knowledge base to determine what information should be required from the user. Finally, it interacts with external files to provide a more user-friendly system, including help statements and multimedia capabilities.

Finally, Level 5 Object also allows the system to read the external files needed during a consultation. The inference engine determines which of these files should be called depending on the information provided or requested by the system's user. The SAFETY FIRST system will use the windows help compiler to provide users with clear and friendly explanation facilities. In addition, the system will retrieve text files containing conclusions and recommendations, and bitmap files containing graphic samples of conditions in a construction site. Finally, in order to make the system even more user-friendly, we take advantage of multimedia facilities like video (using Microsoft Video), sound (using Microsoft Sound), and animation (using 3D Studio). Fall accidents are rarely captured on video, and pictures cannot give a user an accurate idea of the mechanisms involved in a fall. This is the reason for the use of the animation package. It provides the user with a simple simulation of the ways in which a fall from a given structural component may occur.

In order to construct the knowledge base of SAFETY FIRST as described above, the knowledge to be used had to be acquired. This was mainly done during the knowledge acquisition and representation tasks which are the focus of the rest of this paper.

Knowledge Acquisition for “Safety First”

Generally, knowledge acquisition is defined as "the process of eliciting and enumerating the knowledge of an expert in a particular field (domain) so that this expertise can be coded into an expert system" [Bride and Blount 1989]. During this stage most of the knowledge required to create a decision support system is acquired, analyzed, and organized. This section includes a general description of the knowledge acquisition process for the SAFETY FIRST project.

In general, three parties play an important role in the success of the knowledge acquisition process: the knowledge elicitors, the knowledge programmers, and the experts. The knowledge elicitors are in charge of interviewing the experts and trying to elicit knowledge from them. They also plan the topics to be covered during the interviews and lead the flow of the conversation so as to maximize the amount of useful information obtained. The knowledge programmers, sometimes called software engineers, are in charge of taking the knowledge elicited from the experts and converting it into structures and codes that can be used in the computer. Both the knowledge elicitors and the software engineers are also known as knowledge engineers. Finally, the experts are the people whose knowledge or experience in a given domain is going to be represented by an expert system. The experts also verify the applicability and correctness of the expert system and indicate whether or not changes are necessary.

The knowledge acquisition process is generally subdivided into four phases: the preliminary, intermediate, advanced, and organization phases. The preliminary phase of the knowledge acquisition process involved several activities, including reading articles and any other literature available on the subject, selecting the professionals who qualify as experts in the field, and finally, meeting the chosen experts and asking them to participate in our project. The authors performed the function of knowledge elicitors and knowledge programmers.

For the preliminary selection of the experts, three points were considered. First, the expert had to be recognized by people in the industry as knowledgeable in the general area of safety and, specifically, in the construction falls area. Second, the expert had to live within our proximity so that he/she would be easy to reach at all times. A final consideration was the amount of time the expert was willing to give to this project. All of the experts chosen were willing to dedicate a reasonable amount of time, given the constraints of their jobs.

After the experts were selected, the first interview with each of them was conducted. The main objective was to make the experts and the knowledge elicitors feel at ease with each other. During this interview, there was a preliminary discussion about the project, the characteristics of the research process, and the goals of the project. At that time, the objectives of the project and the process required to develop an expert system were explained to the experts. Finally, the knowledge elicitors and the experts decided on the best place and time to meet for future interviews and any other rules to be considered (e.g., whether or not the expert(s) would allow the knowledge elicitor to record their conversations).

At the beginning of the first interviews, the experts seemed to be hesitant about the project and its objectives. For example, when the knowledge elicitors asked one of the experts if their conversation could be taped, the expert's reservations about the project were evident. The immediate response was "no." The expert cited legal problems to explain his answer. In the interview, Any questions the experts had about the project or expert systems over all were answered. Finally, during this discussion the participants got a chance to know each other and to lay a good foundation for future interviews.

Next, in the intermediate phase, the objective was to focus the experts' attention on the subject matter. To do this, we created a questionnaire which served as the second interview with each of the experts. The focus of this questionnaire was on construction falls from high elevations and it was developed to try to get each expert to think about construction falls, first generally, and then in more specific terms. After these interviews, the knowledge acquired was reviewed and the topics of the next interviews were determined. These topics included areas that had not been fully explored, or which were still not clear to the knowledge elicitors after review. Finally, by the end of the intermediate phase, we had developed preliminary fault tree models for all of the building components considered significant enough to be included in this project (e.g., a roof, a floor opening, etc.).

Once the interview process reached the advanced and organization phases, the interview topics concentrated on specific details regarding construction falls from the selected components. The experts also checked the preliminary fault trees and suggested changes to them (as needed). In addition, any disagreements among the experts were settled by providing them with more specific explanations of the variables and parameters involved in the subject at hand. For example, for a sloped roof component, there was disagreement on whether or not devices like crawling boards, roofing brackets, and the so-called chicken ladders could prevent falls. Some of the experts seemed to think so, while others disagreed. In this case, after further discussions, we agreed that those devices are useful tools that help a worker perform his/her job on a sloped roof, but they, by themselves, cannot prevent the worker from falling and/or protect him/her from injuries if a fall occurs.

All of the interviews were summarized and kept on record in order to be used later in the knowledge representation phase. These summaries contain the most significant information acquired and, depending on whether the expert allowed taping, they were obtained after careful review of the interview tapes or from the notes taken by the knowledge elicitor during the interviews.

As mentioned before, the knowledge acquisition and the knowledge representation tasks occurred simultaneously starting from the intermediate phase. The knowledge was represented through fault tree structures. In the next two sections, we discuss the fault tree development process: first, by providing a brief introduction to fault tree analysis and, second, by explaining the development process for one of the structural components studied during this project.

Fault Tree Development for Safety First

There are two types of analytical processes that can be used to analyze a system: inductive or deductive. For a system failure analysis, inductive techniques would attempt to find out what would happen if some fault occurred in the system and all the possible failures that may result as a consequence. For example, if we take the fault "the worker is intoxicated in the construction site," there are several failures (accidents) that may result as a consequence (e.g., the worker may fall, be electrocuted, or be caught-in between some equipment). Therefore, through this method we can evaluate the importance of avoiding the occurrence of certain events (faults) in the system.

The deductive method takes a different reasoning approach going from a given failure mode (consequence) to the specific causes that may lead to it. In this case, we consider a given type of system failure (e.g., worker fall) and try to determine what specific faults (e.g., worker has health problems or worker is hit by something) may cause or contribute to its occurrence. The fact that we can focus on one failure mode and determine how it can occur is the main reason why this type of analysis is used in this project. The focus of this project is in the causes that may lead to a fall accident. The significance of a given cause regarding other failure modes is not within the scope of our study.

Fault tree analysis is a typical deductive analysis method which seeks to identify all of the failure modes that can cause a system failure (top undesired event). In the Fault Tree Handbook, Roberts et al. [19811 defined a fault tree as a graphic model that shows "all the various parallel and sequential combinations of faults that will result in the occurrence of the pre-defined undesired event." The objective of a fault tree is to identify all the possible ways (paths) in which the top undesired event may occur. Through this method the analyst can also identify potential "weak links" in the system being studied and, as a consequence, prevent serious problems or accidents. It is important to note that the fault tree model is limited in that it only depicts the events or combination of events that in the analyst's opinion can lead to the top event's occurrence. Therefore, the scope and limitations of the analysis must be carefully defined and all the assumptions clearly stated. Otherwise, there is a chance that the analyst may omit important input causes.

The events contributing to the occurrence of the top undesired event are determined through the use of logic gates, which show the events or combination of events needed for the occurrence of a higher event. Given a specific gate, the higher event is the output of the gate and the lower events are the inputs to the gate [Roberts et al. 1981]. The relationship among the input events is defined by the type of gate used to connect them. There are several types of events and gates symbols However here we will only discuss those used for this project. We will employ the symbols used in the Fault Tree Handbook published by the National Technical Information Service [Roberts et al. 1981 ].

Three types of gates are used in this paper's fault trees: OR, INHIBIT, and TRANSFER gates (Figure 2). The OR gate indicates a situation in which if at least one of the input events occurs, then the output event happens. Next, the INHIBIT gate is used if a basic or primary event occurs simultaneously with a conditioning event, leading to the output event. In this case, the top event happens if a basic fault occurs in the presence of an conditioning (restrictive) cause. Finally, the TRANSFER gate allows the user to develop a fault tree while avoiding excessive use of symbols on one sheet. The tree can be broken into several branches depicted on different pages. In addition, this symbol precludes having to re-draw the branches of the tree that are identical in several places.

The symbols of all the events in this study are shown in Figure 3. The rectangle defines an "intermediate event," which is a fault event resulting from the input causes acting through a logic gate. Next, the circle defines a "basic event," which is a cause that requires no further development. It is also referred to as a primary or generic failure [Barlow et al. 1975]. Further, the ellipse is used to represent a "conditioning event," which is an event that includes any restrictions or conditions to the INHIBIT gate. Finally, the diamond represents an event that is not developed further, or an "undeveloped event." The reason an event is left undeveloped is either there is a lack of information or, as in our case, the event is outside the scope of the study.

The fault tree system was chosen to represent the acquired knowledge because it simulates the way experts determine the cause(s) of a tall accident that has already happened. Several fault trees for several structural components were developed once the knowledge acquisition from the experts and the literature was completed and the main causes of falls were identified. The final objective of these fault trees was to show the causes or combinations of causes that can lead to a construction fall accident from a given surface. Therefore, the top undesired event of all the developed fault trees is "worker falls from a [predetermined surface]." Given this event, the primary and secondary causes contributing to the fall are determined through the use of logic gates.

For SAFETY FIRST, the study has been limited to developing the fault trees to determine the causes off alls from seven elevated surfaces (floor edge, floor opening, roof, top of wall, wall opening, steel beam, and ladder), from the same level, and slips. Furthermore, we are only concerned with falls that occur during vertical operations, such as the construction of buildings or residential homes. Events like falls during bridge construction and trench operations and falls from utility poles are excluded. In addition, we have focused on the causes of falls over which workers had a certain degree of control or which acted upon workers and caused their falls. Causes of falls related to structural components supporting the workers have been identified in other studies. They will be mentioned but not elaborated on since their analysis would require a comprehensive structural engineering background, a field of expertise which is not within the domain of our current experts.

The first step in developing the knowledge representation structures (fault trees) was the determination of the causes of falls for each of the structural components studied. This was done during the knowledge acquisition phase of the project. As this task progressed, the relationships among the causes and the top event of the fault tree (worker fall) became more evident, and we were able to represent them by using preliminary fault tree structures. Later, as the details about the relationships among causes became even more clear, these preliminary trees were further refined and organized in a more accurate structure.