Logic trees development

In general, the companies surveyed use one of two main methodologies to determine root causes. The first involves timeline construction followed by logic tree development. The second involves timeline construction, identification of causal factors, followed by the use of predefined trees or checklists. These two approaches are discussed in detail in Chapter 9. 

Timeline construction followed by logic tree development. 

After the most likely scenario has been identified and the logic tree developed, the incident investigation team now reaches the stage of searching out the system-related multiple causes. An accompanying challenge is deciding when to stop further development of each branch of the tree. 

The fictitious process safety incident contained in Appendix D can he used to illustrate the application of how a fact/hypothesis matrix can he used during logic tree development. Extensive details of the incident appear in the appendix hut a basic summary would be ... 

The disciplines of engineering and quality control have long recognized the principles of root cause analysis. Some process safety tools for root cause analysis have been borrowed from these disciplines. For example, fault tree analysis was developed as an engineering tool, but its logic tree structure has been adapted to meet process safety requirements. 

Examples of logic trees—fault, event, causal, and why—are discussed below in order of increasing rigor. Chapter 9 contains detailed information on developing logic trees. 

AVhile some methods use checklists as the logic analysis step, an understanding of the logic tree approach is still helpful because checklists are developed from logic trees. Checklists are especially helpful when related to human factor issues. A sample checklist is included in Chapter 6 as Figure 6-6 (page 94). 

Next the team develops a chronology of events based on the available known times and sequences. This document is usually referred to as a timeline. (See the detailed description of timeline development in Section 9.3.) Unconfirmed assumptions regarding chronology should be clearly identified as unconfirmed, and action should be initiated to verify assumptions. Many investigators use relatively simple timelines (instead of sequence diagrams) with the logic tree methods because the logic tree itself shows the interactions of events and conditions. 

After the initial facts have been listed and the initial timeline developed, the logic tree diagram can be constructed. The tree diagram is a dynamic document it continues to expand and may even rearrange as additional information becomes available or when new information changes the understanding of the original facts. 

In the opening segment the facilitator should discuss the importance of and methods for choosing the top event and any preestablished and existing boundaries of the investigation. If multiple events are involved, it is best to start with the last event in the time sequence. It may be appropriate, depending on the nature of the occurrence, to formally review the rules and symbols used in logic tree or fault tree development or whichever other formal method will be used. 

At this point, the logic tree structure is examined to ensure the tree is logically consistent and compatible with the known facts. In some instances, there may be inconsistencies and application of the fact/hypoth-esis matrix will be appropriate. This powerful tool is described in more detail later in this chapter. Inconsistencies found at this point require further tree development or rearrangement. 

After the tree is developed, and before moving on to the recommendations and deliberations, the team should ask, Are there any other causes that anyone had in mind at the beginning of this meeting that are not included in the tree If additional causes are identified, the team adds them to the tree if there is logic to support them. Some team members may have specific concerns that the logic tree has not adequately resolved. This is the point at which remaining issues are surfaced and addressed. 

To put it simply, a logic tree is developed by repeatedly asking Why and organizing the results of the answers. 

Advanced investigators can use the following frequently used logic tree symbols however, adequate logic trees can be developed without using them. 

Unlike the procedure followed in developing logic trees, the investigation team does not construct the tree. Rather they apply each causal factor to each branch of the predefined tree in turn, and those branches that are not relevant to the incident are discarded. This prescriptive approach offers consistency and repeatability by presenting different investigators with the same standard set of possible root causes for each incident. 

The use of checklists to supplement another root cause analysis method can be a very powerful technique, for example, human factors checklist(s) may be used in conjunction with logic trees. The checklist may be used as a guide during development of a logic tree, or as a check after the tree has been developed. The checklist essentially acts as a memory jogger to direct the investigation team. This is especially helpful if the team lacks previous experience in the subject matter. 

The team developed logic trees to describe the events. To reduce the complexity of the trees, the team chose to treat the operator fatality, the contractor injury and the injuries to the fire brigade as a separate tree. Since explosion at the catalyst storage tanks resulted from the spread of the fire... 

The local site effects play an important role in the evaluation of seismic hazard. The proper evaluation of the local site effects will help in evaluating the amplification factors for different locations. This article deals with the evaluation of peak ground acceleration and response spectra based on the local site effects for the study area. The seismic hazard analysis was done based on a probabilistic logic tree approach and the peak horizontal acceleration (PHA) values at the bed rock level were evaluated. Different methods of site classification have been reviewed in the present work. The surface level peak ground acceleration (PGA) values were evaluatedfor the entire study area for four different site classes based on NEHRP site classification. The uniform hazard response spectrum (UHRS) has been developed for the city of Bangalore and the details are presented in this work. 

Fault tree analysis is a technique by which the system safety engineer can rigorously evaluate specific hazardous events. It is a type of logic tree that is developed by deductive logic from a top undesired event to all subevents that must occur to cause it. It is primarily used as a qualitative technique for studying hazardous events in systems, subsystems, components, or operations involving command paths. It can also be used for quantitatively evaluating the probability of the top event and all subevent occurrences when sufficient and accurate data are available. Quantitative analyses shall be performed only when it is reasonably certain that the data for part/component failures and human errors for the operational environment exist. 

NORSAR (Norway) and the University of Alicante (Spain) have developed a Matlab based tool named SELENA (Seismic Loss Estimation using a Logic Tree Approach) (Molina-Palacios Lindholm, 2006). SELENA, uses probabilistic or deterministic seismic hazard information and estimates the ground motion at a specific site using 1997 NEHRP provisions. The software computes building damages based on capacity-spectrum method of Hazus (1999). 

---