ML19308B827
| ML19308B827 | |
| Person / Time | |
|---|---|
| Site: | Crane  |
| Issue date: | 02/28/1977 |
| From: | Buys J EG&G, INC. |
| To: | |
| References | |
| TASK-TF, TASK-TMR ERDA-76-45-08, ERDA-76-45-8, ERDA-76-46-08, ERDA-76-46-8, SSDC-8, NUDOCS 8001170404 | |
| Download: ML19308B827 (35) | |
Text
,
ERDA 76-45/8 SSDC-8 D
l l
STANDARDIZATION GUIDE FOR l
CONSTRUCTION AND USF OF 1
l MORT-TYPE ANALYTIC TREES SYSTEM SAFETY DEVELOPMENT CENTER D
^
l T
I I
0
&ERDA EGsG 94 EG&G Idaho, Inc.
P.O. Box 1625 Idaho Falls, Idaho 83401 FEBRUARY 1977 D
UNITED STATES ENERGY RESEARCH AND DEVELuPMENT ADMINISTRATION DIVISION OF SAFETY, STANDARDS, AND COMPLIANCE 80011704-04
G DISCLAIMER This repori. was prepared as an account of work sponsored by the United States Government.
Neitner the United States nor the United States Energy Research and Develop-ment Administration, nor any of their employees, nor any of their contractors, subcontractors, or their employees, makes any warranty, expressed or implied, or assumes any legal liability or responsibility for the accuracy, com-pleteness, or usefulness of any information, apparatus, product or process disclosed, or represents that its use would not infringe privately owned rights.
Available from:
National Technical Information Service (NTIS)
U.S. Department of Comraerce 5285 Port Royal Road Springfield, Virginia 22161 Price:
Printed Copy:
$ 4.00 Microfiche:
$ 3.00 e
i
ERDA 76-45/8 SSD C-8
}
Uc-4 i
STANDARDIZATION GUIDE FOR CONSTRUCTION AND USE OF MORT-TYPE ANALYTIC TREES Prepared By J. R. Buys D
Work Performed At EG&G IDAH0, INC.
IDAHO OPERATIONS OFFICE Under Contract No. EY-76-C-07-1570 February 1977 (SecondPrinting-April 1977)
D t-
D l
ACKNOWLEDGMENT Special acknowledgment is extended to the staff of the System Safety Development Center and to reviewers throughout the ERDA complex for their helpful suggestions and guidance, and to Della T. Kellogg for her editorial assistance.
I l
D CONTENTS Page INTRODUCTION..........................
1 ANALYTIC TREES.........................
1 S U FNA R Y................,...........
2 ANALYSIS STEPS.........................
12 TREE CONSTRUCTION Principles:
1.
Symbols.....................
14 la. E v e n ts.....................
14 lb. Logi c Ga tes...................
16 lc. Transfers....................
17 2.
Simplicity...................
18 3.
Logic 18 4.
Ga te Sel ecti on.................
19 5.
Even t Ti tl es..................
19 6.
Tier Limits...................
19 I
7.
Event Identi fication..............
20 8.
Modified Event Identification..........
20 9.
Trans fer Use..................
20 9a. Transfer Identification.............
25 9b.
Interpage Transfers...............
25 9c. Transfers In..................
25 9d.
Intrapage Transfers...............
26
- 10. Gate Identi fication...............
26 11.
Intratier Priorities..............
26 REFERENCES...........................
28 FIGURES 1.
Cross Index of Logic Symbols.............
3 2.
Analytic Tree EVENT Symbols.............
4 3.
Analytic Tree LOGIC GATE Symbols...........
5 4.
Analytic Tree TRANSFER Symbols............
6 5
Acceptable Tier Arrangements.............
7 6.
Examples of Good and Poor Tree Logic.........
8 7.
Sample Analytic Tree - Sheet 1............
10 8.
Sample Analytic Tree - Sheet 2............
11 TABLES I
Dewey Decimal Event Identification Numbers......
21 I
II Modified Dewey Decimal Event Identification Numbers.
23
INTRODUCTION Since the introduction af f10RT (Management Oversight and Risk Tree) techno-logy as a tool for evaluating the success or failure of safety management systems, there has been a proliferation of analytic trees throughout ERDA and its contractor organizations. Standard "tault tree" symbols have generally been used in logic diagram or tree construction, but new or revised symbols have also been adopted by various analysts.
Addi tionally, a variety of numbering systems have been used for event identification.
The consequent lack of standardization has caused some difficulties in interpreting the trees and following their logic.
This guide seeks to correct this problem by providing a standardized system for construction and use of analytic trees.
Future publications of the ERDA System Safety Development Center (SSDC) will adhere to this guide.
It is recommended that other ERDA organizations and contractors also adopt this system to achieve intra-ERDA uniformity in analytic tree construction.
The proposed system is the outgrowth of the SSDC's experience in developing and teaching the use and construction of MORT diagrams and other analytic trees.
It is equally applicable to both " success" or " positive" trees and " failure", " fault", or " negative" trees.
ANALYTIC TREES The use of analytic trees originated as " fault tree analysis" in the early 1960's in the aerospace industry, as an attempt to prevent over-sights, particularly at system interfaces, which had previously resulted in costly retrofits or inordinately short operational lifetimes for promising systems.
Fault tree analysis was strongly hardware-oriented, but also showed promise as an analytic tool for evaluation of systems involving a great deal of human performance. Development of the MORT concept a decade later, and its acceptance by AEC (ERDA) for agency-wide use, made application of the fault tree analysis techniques to management systems a reality.
An analytic tree is simply a graphical display of information to aid the user in conducting a deductive analysis of any system (human, hardware, or environmental) to determine critical paths to success or failure.
It identifies the details and interrelationships that must be considered to prevent oversights or omissions that lead to failures.
It enables the analyst to:
1.
Systematically identify the possible paths from base events to predicted outcome.
2.
Display a clear visual record of the analytical process.
3.
Identify management system weaknesses and strengths.
D 4.
Provide a basis for rational decision making by management.
l <
In an analytic tree, a top or major event or outcome is stated.
It may be either a desired objective or goal, or an unwanted or injurious occurrence. On the next lower tier are listed those events required to achieve the top event. Each of these is subsequently broken down into its constituents to reveal the events, causes, and sources that contribute to the occurrence of the top event.
Construction of an analytic tree, therefore, constitutes a deductive analysis of a manage-ment system or safety system, proceeding from general to specific, or outcome to source, and answering the question, "How could this happen?".
Once an analytic tree has been developed, it can be used as a tool to aid in achievement of "first-time-safe" operations; assurance of success-ful completion of a desired objective; prevention of significant accidents by foreseeing and avoiding managerial and operational oversights and omissions; and maintenance of effective total loss control.
It can also be used af ter-the-fact in investigation of injuries, property damage, programmatic degradation, etc., to identify not just the symptoms, but also the root causes and sources of these accidents and the management system weaknesses that permitted them to occur.
SUMMARY
In the following sections of this monograph, analytic tree analysis steps and construction principles will be discussed.
Both are summarized here to provide the user with a tool for rapid preview and a checklist for analytic tree-based system analysis.
A.
Analysis Steps for Analytic Tree Use 1.
Define the top event.
2.
Acquire a working knowledge of the system to be analyzed.
3.
Construct the analytic tree.
4.
Validate the analytic tree.
5.
Evaluate the analytic tree.
6.
Conduct trade-off studies (risk / benefit studies).
7.
Provide management with the recommendations and alternatives needed for informed decisions.
B.
Analytic Tree Construction Principles 1.
Use common and accepted graphic symbols for events, logic gates, and transfers.
(See Figures 1, 2, 3, and 4.
Figure 1 compares the " modified MORT" symbols recommended in this guide with " initial f10RT" and Fault Tree Analysis symbols.)
2.
Keep the analytic tree as simple as the complexity of the system allows (see Figures 5 and 6). l
i MODIFIED MORT INITIAL MORT FAULT TREE ANALYSIS Gate Output or General Event i
Base Event Undeveloped Tenninal Event Normally N
Expected Event N
i Sat M actory NONE
+
+
AND Gate AND
^
^
AND Conditional
- trT-Gate or or OR E
NONE AND i
Basic Transfer l
1 Transfer from B
Another Page p2 p2 t
Assumed Risk h
R NONE Transfer Figure 1.
Cross Index of Logic Symbols l
RECTANGLE A general event or_ a gate output event resulting from the logical combination of contributory events acting through a logic gate.
I CIRCLE A base event requiring no further development.
It is an independent vent used only as a logic gate DIAMOND An undeveloped terminal event not developed to its cause.
Terminated for lack of information, resources or risks, or to avoid redundancy of analysis.
SCROLL A normally expected event that should occur naturally during normal func-tioning of the system.
STRETCHED CIRCLE I
A satisfactory event that exists noncommittally in the system as a logic gate output and is used to show completion of a logical analysis.
Figure 2.
Analytic Tree EVENT Symbols l
AND Gate AND A logic gate that produces an output only when all input events occur.
Contains l
the identifying word "AND".
OR Gate A logic gate that produces an output when OR one or more of the input events occur.
9 Contains the identifying word "0R".
CONSTRAINT A conditional event that applies conditions or constraints to a basic logic gate or out-put event.
Imposed condition is written in the ELLIPSE.
CONDITIONAL AND Gate Input produces the output provided the conditions written in the ELLIPSE are AND satisfied.
(Example: PRIORITY AND gate g
specifying order of input event occurrence.)
g CONDITIONAL OR Gate Input produces output provided the constraint OR conditions are met.
(Example:
EXCLUSIVE OR gate enabling an output to occur only if a single input is present.)
SUMMATION Gate A special logic gate which requires that an acceptable combination of input events be present to produce an output.
Inputs can be present in varying proportions, as long AND as the sum of the inputs is adequate to generate an output.
Figure 3.
Analytic Tree LOGIC GATE Symbols I
TRIANGLE _
The basic transfer operator represents the exact repetition'of a tree section found elsewhere on the tree below an identical triangle.
Intrabranch TRANSFER 3
Transfers substructure within a branch.
Has identifying lower case letter.
Interbranch /Interpage TRANSFER Transfers substructure from another branch or another page.
Has an identifying capital letter.
OUT-TRANSFER, Same Page g
Horizontal arrow away from symbol shows transfer U
of substructure to another location on the same page in the direction the arrow points.
IN-TRANSFER, Same Page b
Horizontal arrow toward symbol shows transfer from direction of arrow on the same page.
IN-TRANSFER, Uther Page
[
Vertical arrow toward base of symbol indicates
^ p7 transfer from branch on designated page.
r- - - 1 r--i OUT-TRANSFER, Other Page L-g
'] g2
" Recipient events" from other pages in broken lines above oversized triangle indicate transfer of substructure to recipient event locations on designated pages.
SMALL OVAL Assumed risk transfer is used to transfer an assumed risk from any tree location to the assumed risk event (a SCROLL).
The number of R1 the assumed risk is indicated inside the symbol as shown.
It normally originates at a DIAMOND (undeveloped terminal event).
Figure 4.
Analytic Tree TRANSFER Symbols I
. i
9 (a)
TOP EVENT b
AND s
l I
> Tier 1 OR P
y Tier 2 s
(b)
TOP EVENT (c)
AND AND I
i i
i i
I
)
y Tier 1 <
' OR s
-s OR T
I I
y Tier 2 <
'J b
Figure 5.
Acceptable Tier Arrangements -
2 e
Human (a)
TOP EVENT i
Senses AND l
j l
l 3
Sight Touch Smell Hearing Taste gTier This example exhibits good logic because all of the recognized senses are listed, but no extraneous detail is included on Tier 1.
(b)
TOP EVENT e
s AND I
s l
I I
l l
Sight Smell Sweet Salt Tier Touch Hearing Sour Bitter f
i Poor logic has been used here, for detailed constituents of taste are listed on the same tier as the other four senses.
If this level of detail is desired, the contributory events should be listed on Tier 2 under the appropriate sense.
Figure 6.
Examples of Good and Poor Logic [3][4]
l 3.
Keep the analytic tree logical and expect no miraculous occurrences. Use only those contributory events which are "necessary and sufficient" to produce the output event.
4.
Select the logic gates and constraints (conditional ever.ts) which best describe true system functioning.
5.
Select event titles or descriptions which are simple, clear, and concise. Avoid those which are abstract or are not readily understood by the intended users.
6.
When constructing complex trees, limit the number of tiers on a single page to nominally four or five tiers (see Figure 7).
7.
Use the Dewey decimal system for numbering events below the top event on the first page of the analytic tree.
Locate the event identification above the upper right corner of the event symbol (see Figure 7).
8.
Use a modified decimal system for identifying events below transfer symbols beginning)with the letter designation of the transfer (see Figure 8.
9.
Use transfers to avoid duplication of identical branches I
or segments of the tree, and to reduce single-page-tree complexity (see Figures 7 and 8).
a.
Identify "intrabranch" transfers by lower case letter designations and " interbranch" or " inter-j page" transfers by capital letter designations, i
1.e., d and d, respectively, b.
Show transfers into a branch of the analytic tree by an arrow pointing toward the transfer symbol from the general direction of transfer; horizontal for transfers on the same page and vertical for those from another page (see Figures 7 and 8).
c.
Show transfers out of a branch to another location on the same page by an arrow pointing away from the transfer symbol in the direction of transfer (see Figures 7 and 8).
d.
For transfer of a branch to another page, list the
" recipient events" in broken lines above an "over-sized" transfer symbol on the page where the transfer originates. The page to which the substructure is to be transferred is specified below the lower right corner of the recipient event. A similar notation at the transfer symbol on the receiving page shows j
the orig'n page of the transferred branch (see Figures 7 and 8, transfer "A").
!l ll lI I
lltII 7,
4, p
B l
/
4 2
l
^
DnA
)
4,
_ N 1
tee h
2 S
B 3
2 1
1 Ap.
2.
ee 3
r 2
T 2
D c
l B
N I
i A
t T
0 y
N E
I AA l
1 a
E 2
l V
D N
n 8
O l
A P
T e
lp 2
2 m
2 a
2 S
R 2
l O
1 7
2 e
0 r
a 1
I ug i
F 1
2 g
2 R
1 a
C 1
2 l
Ay.
2 p
1 a
I y'
l
3 b
- 3. l 2-J1 3
2 A
2 p
D b
l t
Il t
{
b l
A ee h
I L._
S e
e r
T c
i 2
1 t
APll b
a y
j b
A l
n A
e lpma S
l 8
J-e 1
l 1
r 2
u
~
E-l b
i A
g F
L
10.
Do not number or letter logic gates.
They are adequately identified by the input events which operate through them and the resulting output events.
11.
Follow the convention of indicating order of performance or time sequencing from left-to-right, for related events on a single tier.
ANALYSIS STEPS The basic steps in analyzing any system through use of an analytic tree are:
1.
Define the top event. That which you desire to achieve, or which you desire to prevent from happening is the top event. flake it as specific as you can so that contribu-tory events can be clearly and accurately recognized and defined.
2.
Acquire a comprehensive understanding of the management system or safety system to be analyzed. Only by fully understanding the system, its constituents and details, and their interrelationships and interfaces can a logical and complete analysis be performed, which identifies and j
considers all those events which are necessary and suffi-cient to produce the top event or outcome.
It is often necessary and desirable, particularly with success trees, to:
- Define the " ideal" management system or safety system.
- Compare the existing system with it.
- Incorporate those events and logic gates in the analytic tree that are required to bring the present system up to the ideal.
3.
Construct the analytic tree. With the top event defined and a thorough understanding of the system acquired, the analyst then constructs the analytic tree, using appro-priate logic gates and standardized event symbols and transfers. Specifics of tree construction will be dis-cussed later.
G L
Proper logic is followed to assure that 411 events meet the "necessary and sufficient" criterion, i.e., those events are specified which are the minimum necessary, and no more than is sufficient, to immediately produce the logic gate output event. Each event is essential to the tree logic (necessary) and no oth information is needed (sufficient) to achieve the stawd output. All other events are either excluded as being extraneous, or are relegated to a supportive and more detailed lower tier.
Steps 2 and 3 ordinarily are not separate and distinct as suggested here, but rather more about the system is often discovered and applied as tree construction develops.
4.
Validate the analytic tree. Once construction of the analytic tree has been completed, one or more knowledge-able persons should review the tree events and logic for accuracy and completeness - for omissions and oversights.
The purpose of this validation rev.iew is to confirm that:
- The tree meets its intended objectives.
- The system and its functioning are fully and clearly described.
- Inputs to logic gates are necessary and suffi-
)
cient to logically produce the stated output events.
Validation by other persons has proven time and again to be essential to produce useful, error-free analytic trees, which identify system weaknesses and strengths and lead to proper assessment of identifiable risks. Often, consulta-tion with others to validate the tree begins before construc-tion is complete, so steps 3 and 4 sometimes overlap.
5.
Evaluate the analytic tree. Following validation of the tree, it is evaluated to identify critical paths to achieve-ment of the top event. Thorough study of the elements and interrelationships in the tree will enable the analyst to identify oversights and omissions in the safety / management system, and to assure that identifiable risks are presented to the proper management levels for acceptance or resolution.
As the analyst evaluates the failure or success paths from base events to the top event, paths or chains of varying importance and system impact will emerge. The relevance to system output of these paths, and the events of which they are comprised, must be carefully weighed and major emphasis placed on those of greatest significance.
(This, of course, will require value judgments by the analyst, but they should be based realistically on what the analysis reveals.) Management must not only be informed of the risks
}
involved, but also of their relative significance, if they are to make the best risk-related decisions.
6.
Conduct trade-off studies. Trade-off, cost-benefit, or risk-benefit studies are needed to determine which risks should be assumed, which risks cannot be assumed, and where controls can most effectively be applied to achieve the desired objec-tive or prevent the undesired occurrence.
7.
Management makes rational and informed decisions concerning the safety / management system.
The results of analytic tree evaluation and subsequent trade-off studies lead logically to recommendations and alternative solutions, from which management can select in making knowledgeable and informed decisions on system control and repair, and risk assumption.
TREE CONSTRUCTION Analytic tree construction is a logical development of the top event, using deductive reasoning to progress through successively more specific events to basic events or causes, from which sequential chains of success or failure begin. The various levels of tree development are tiers and branches of contributory events that are sequentially linked by logic gates.
Each tier of tree development contains those events which, when processed through the logic gate, are necessary and sufficient to lead directly to the success ar failure of the event on the next higher tier.
Branching occurs when any of the multiple events, which may operate through a logic gate to produce a common higher event, have substructures of their
{
own.
Usc of the standardized ar.proach for analytic tree construction and iden-tification requires adhet ence to eleven b7 ic principles:
1.
Use common and accepted graphic symbols. Analytic tree symbols may be categorized into three groups:
(a) events, (b) logic gates, and (c) transfers.
Although an ERDA-approved MORT template currently does not exist, logic symbol templates that can aid the analyst in tree construc-tion are available from several commercial sources.
a.
Events An event is a possible condition or state of a system element or function.
It may be a long-lived condition, or it may arise spontaneously l
or gradually from a dynamic change of state.
If it results in a desirable or intended occurrence, it is a success or normal event.
If it results in system degradation or failure, or an abncemal occurrence, it is a failur-or fault event.
The i
same common symbols are used as components of both success trees and fault trees.
l l
Event symbols are of five basic types, each of which represents a different kind of event (see Figure 2).
j (1) The RECTANGLE is the general event symbol and is used extensively in all trees, but prticularly in success trees.
It is also used to represent a gate output event, resulting from the logical operation of contributory events acting through a logic gate.
(2) The CIRCLE represents a base event that requires no further development.
It is an independent event that defines an inherent system element fault or a base-level success, and is used only as an input to a logic gate.
(3) The DIAMOND represents an undeveloped terminal event, which is not developed further because of:
(a) Low relevance or low risk, i.e., a JSA (Job Safety Analysis) is not performed on a particular task, because it has a low potential for accident, and the low risk is assumed.
I (b) Lack of adequate information or resources for solution, i.e., the nearest hospital is 40 miles from the work site, and cost is prohibitive to move nearer, therefore, event development is terminated and the distance risk is assumed.
(c) Redundancy avoidance when another ana-lytic tree gives the needed information, i.e., in developing a detailed use readi-ness tree for a new complex facility, the safety criteria event should be c DIAMOND, and reference made to the
" Occupancy-Use Readiness Manual - Safety Considerations"[33, where the safety criteria tree is already developed.
(d)
Influence on the scope of the tree, but not necessary to the development of the analytical logic, i.e., safety considera-tions only are ana}yzed in the Occupancy-Use Peadiness TreeL3], but undeveloped interfacing events with other organiza-tions are shown because they influence tree scope, even though they are not
}
necessary to logic development.
In cases (a) and (b), the event logically I
becomes an " assumed risk".
In case (c),
a footnoted reference identifies the supple-mentary analysis.
In case (d), " fringe area" events are identified which do not contribute significantly to development of the final system outcome, but which should be included on the tree to indicate that their influence on the extent or depth of system analysis has been considered.
Like base event circles, terminal event diamonds represent base-level events which are used only as logic gate inputs.
(4) The SCROLL represents a normally expected event, which is expected to occur naturally during normal functioning of the system.
It has the same meaning as the " house" in Fault Tree Analysis symbolism.
Assumption of some risks in any major operation is normally expected, so the " assumed risk" event would be a SCROLL.
Likewise, in assessing deviations in personnel perfor-mance, normal variability among workers would be expected and should be depicted
{
as a SCROLL.
(5) The STRETCHED CIRCLE is a satisfactory event, which simply exists in the system but is neither fault-oriented nor success-oriented.
It is a logic gate output event which is most often used to show completion of logical analysis.
It covers such events as the presence of personnel or objects in an energy channel because they are needed there to perform a functional task.
b.
Logic Gates A logic gate performs a discrete operation upon contri-butory events to produce a logical output event.
The fundamental logic gates for analytic tree construction are the AND gate and the OR gate. Many analytic trees can be constructed using only these basic logic gates.
If a CONSTRAINT symbol is added to a basic logic gate to modify it or impose special conditions on its opera-tion, greater flexibility is added.
Furthei addition of a StJMMATION gate should provide the analyst with all the logic gates he needs for thorough analysis of the system (see Figure 3). The AND gate produces an output only if all required input events coexist.
l D
In other words, all contributory events must occur for an AND gate to produce an output event.
The OR gate produces an output event when one or more of the contributory events occur.
The addition of a CONSTRAINT symbol (an ELLIPSE) to the side of a basic logic gate applies conditions or constraints to the basic gate to create a CONDITIONAL gate, which inhibits or prevents an output until the specified condition is met. Typical of a CONDITIONAL gate are the PRIORITY AND gate, which requires a particular input event sequence to cause occurrence of the output event, and the EXCLUSIVE OR gate, which enables the output event to occur if one, and only one, of the input events is present.
The SUMMATION gate is a special logic gate which requires that an acceptable combination of the input events occur to produce an output.
This allows for contributory events to be present in varying propor-tions, as long as the composite contribution is suffi-cient to produce occurrence of the output event; that is, a deficiency in one or more input events can be f
compensated by greater contributions by the other input events. Unlike the Fault Tree Analysis " basic and/or" gate logic, which requires each input event to be either present or absent (a strict binary logic),
the SUMMATION gate allows any contributory event to be present to any degree from 0 to 100%, as long as the total input from all events can generate the output event.
For example, in the Behavioral Change Tree [l], four input events operate through a SUMMA-TION gate to produce the output event, " Select Means for Introducir.g Behavioral Change".
Deficiencies in input 1, " Control Selection and Placement",. can be compensated by improved performance on input events 2, 3, and 4, " Control Training", " Control Factors That Influence Attitudes", and " Control Organizational Psychology Factors", respectively.
This provides a satisfactory combination of events for introducing the desired behavioral change.
c.
Transfers A TRANSFER symbol indicates that an event, a series of events, or a complete branch of the analytic tree is transferred from one location on the tree to another.
Rather than duplicating that portion of the tree in the second location, a transfer TRIANGLE is used to indicate an exact repetition of that tree section at j
the second, third, etc., location. Use of a special SMALL OVAL to represent transfer of an " assumed risk" s y p
event is peculiar to MORT [2].
Both TRANSFER symbols,
{
the tree-section transfer TRIANGLE, and the " assumed risk" transfer SMALL OVAL are used to avoid repetition, conserve space, and simplify tree construction (see Figure 4). Additional information on use of TRANSFER symbols will be provided as other tree construction principles are discussed.
2.
Keep the analytic tree as simple as the complexity of the system allows. When the analyst has gained a thorough under-standing of the system to be analyzed, he begins to lay down its logical progression from the top event to base events.
He should be ready to get additional system information as the tree reveals that need. However, he should be selective in determining the depth of analysis, and should use the undeveloped termination event DIAMOND when further develop-ment is clearly not justified. This usually occurs when all the relevant dependencies and the.necessary and suffi-cient input events have been identified.
Normally, the i
analyst will clean up and further simplify the analytic tree that he has used as an analysis tool, before pre-senting it to management for their use in making risk assumption and risk resolution decisions.
3.
Keep the tree logical and expect no miraculous occurrences.
Deductive analysis, using an analytic tree as a logic aid, should proceed logically from the top event to base events.
Related events at the same level of logic and detail are entered on a single tier and are joined by a line before being processed through a logic gate.
A vertical line and a logic gate join a gate output event on one tier with its more detailed contributory events on the next lower tier.
Ideally, all events on the same tier will be on the same horizontal level [ Figure 5(a)], however, because of space limitations and page-fitting problems during tree construction, they are often joined to a common horizo;. cal line by vertical extensions of varying lengths [ Figure 5(b)], or they are joined to a single vertical line and listed ladder-like, one below the other
[ Figure 5(c)]. Any of the tier arrangements in Figure 5 are acceptable.
Figure 6 displays examples of good and poor logic in placement of events in analytic tree tiers.
Expect no miracles, either good or bad. The analytic tree cannot do the work for the analyst.
It is simply a tool for his use in organizing and systematizing his thinking to help him find right answers.
Its output can be no better than the quality and organization of its inputs.
Be reasonable, logical, and practical, and expect logical and rational sequences to develop through logic gates, as identifiable events interrelate and interact.
Lower tier input events should be only those which are neces-sary and sufficient to produce the gate output event.
l -
Do not struggle to develop outlandish or irrational events which would require a miracle for occurrence, such as postulating simultaneous occurrence of a buildin fire, bomb threat, severe winter storm, tornado, earth-quake, and an impending nuclear attack in analyzing an Emergency Response System.
4.
Select the logic gates and constraints (conditional events) which best describe true system functioning.
The basic AND, OR, and SUMMATION logic gates, modified as necessary by CONSTRAINTS, provide sufficient flexibility to accurately describe the logical processing of cor.tributory input events, and produce the defined output events at each level of the analytic tree. Proper selection and use of logic gates will
. establish a logical progression of identifiable event inter-actions through the tree to tie the top event to its root contributors at the base event level, and to. accurately describe the way the system really works.
5.
Select event descriptions that are simple, clear, and concise.
Event descriptions should be sufficiently descriptive and understandable that the analytic tree user can grasp their meaning and follow the analytic process without having to refer to explanatory data found somewhere else.
Analysts should particularly avoid event descriptions which are l
abstract, or which contain terms with which the intended user is unfamiliar. Additionally, event descriptions for systems with considerable people-involvement should include active verbs ("do" verbs), such as " plan", " prepare",
" control", " implement", etc., to convey the precise nature of input events which are necessary and sufficient to generate the output events and, ultimately, the top event.
6.
When constructing complex trees, limit the number of tiers on a single page to nominally four or five tiers. There are two basic reasons for imposing such a limitation:
a.
Most trees are reproduced on 8-1/2"x11" or 11"x17" sheets for inclusion in a document or for convenient use on the job. The complexity of branches of the analytic tree will cause some variance in the number of tiers that may appeer on a single page, but nor-mally more than four or five tiers cannot be repro-duced legibly or read without magnification.
b.
Use of the Dewey decimal system for event identifi-cation (discussed in principle 7) becomes cumbersome and difficult to manage beyond five digits (five tiers). A modified decimal system restores the simplicity of event identification below TRANSFER symbols (see principle 8).
l 7.
Use the Dewey decimal system for numbering events below the top event on the first page of the analytic tree.
Each event is uniquely identified by a Dewey decimal number located above the upper right corner of the event symbol.
The number of nonzero digits in the Dewey decimal event numbering system corresponds to the tier on which the event is located, i.e, the third tier contains 3 digit event numbers. Table I gives representative Dewey decimal numbers for various tiers.
A Dewey decimal event identification number not only uniquely describes an event, but it also systematically traces its development through subbranches and branches to its progen-itor event on the first tier.
Each successively higher level event can be identified by dropping the last digit from the number as shown below:
Top Event 1.0 First Tier 1.1 Second Tier 1.1.1 Third Tier 1.1.1.1 Fourth Tier 1.1.1.1.1 Fifth Tier Example 1 shows another numeric progression in tree format.
8.
Use a modified decimal system for numbering events below transfer symbols beginning with the letter designation of the transfer, i.e., A.l.3.2 or a. l.3.
Numbering progresses through succeeding subtiers in the same way as the pure numerical Dewey decimal system, ac shown in Table II and the accompanying examples.
Alphanumeric progression from the fourth subtier to the TRANSFER is shown below:
D TRANSFER D.2 First Subtier D.2.2 Second Subtier I
D.2.2.1 Third Subtier i
D.2.2.1.2 Fourth Subtier l
Example 2 shows the same progression in tree format.
I 9.
Use transfers to avoid duplication of identical branches or I
segments of the tree and to reduce single page tree complexity.
l Whenever two or more gate output events have identical details in the substructures contributing to their occurrence, that substructure should be constructed under only one of the output events, and then transferred to the others through the use of TRANSFER symbols (see Figure 7, TRANSFERS "a" and "B").
Be careful to avoid the inclination to force a j
i l
L 1
TABLE I DEWEY DECIt%L EVENT IDENTIFICATION NUMBERS Tier Number Designation Top Event Unitumbered First 1.0, 2.0, 3.0, 4.0...n.0 Second 1.1, 1.2, 1. 3.. 2.1, 2. 2, 2. 3... n.m Third 1.1.1, 1.1. 2, 1.1. 3.. 2.1.1, 2.1. 2... n.m. p l
Fourth 1.1.1.1, 1.1.1. 2.. 2.1. 3.1, 2.1. 3. 2... n.m. p.q Fifth 1.1. 3. 2.1, 1.1. 3. 2. 2.. 2.1. 4. 2.1... n.m. p. q. r D i
l TOP EVENT AND l 1.0 2.0 l 3.0 b
AND I
l l 2. 2 b
AND I 2.2.1 l
l OR em I
l l2.2.1.3 l
l AND l
l 12.2.1.3.1 l
EXAf1PLE 2 (Also See Figure 7)
{
l l
l D
TABLE II MODIFIED DEWEY DECIMAL EVENT IDENTIFICATION NUMBERS fra$
Number Designation bt er Transfer A, B, C...N I
First A.1, A.2, A.3...N.m 1
Second A.1.1, A.1. 2... A. 2.1, A.2. 2... N.m. p Third A.1.1.1, A.l.1.2, A.l.1.3...N.m.p.q Etc.
'l J
A AtlD I
I D.1 l D.2 b
AND I
/
l lD.2.2 AND I
l D. 2. 2.1 l
l i
l lD.2.2.1.2 EXAMPLE 2 (Also See Figure 8) l 1 i
l l
substructure that "almost fits", but has basic differences, into a " transferable" structure. TRANSFERS should be used also below the bottom tier events on a page to indicate continuance of subbranches of those events on other pages.
l Additionally, whenever there is insufficient space on a page to develop a branch below an event _at any level, a TRANSFER immediately below that event indicates that the branch is developed on another page (see Figures 7 and 8, TRANSFER"A").
1 a.
Identify "intrabranch" transfers by lower case letter dcsignations, and " interbranch" or " inter-page" transfers.by capital letter designations,
)
i.e., /a\\ and A, beginning with "a" and "A",
respectively, and proceeding logically.
Refer to l
f Figures 6 and 7 where TRANSFERS "a" and "b" trans-fer substructures within a branch (are intrabranch transfers); TRANSFER "A" is the transfer of a branch between pages (interpage transfer), and TRANSFER "B" is a substructure transfer from one branch to another (interbranch transfer).
b.
Show transfers into a branch of the analytic tree by an arrow pointing toward the transfer symbol.
For transfers from a branch on the same page, the arrow points to the side of the TRANSFER symbol from thp direction in which the transfer is made, 1.e., l_y- (see Figures 7 and 8, TRANSFERS "a",
a l
l "b", and "B").
For transfers from another page, the arrow points to the base of the TRANSFER triangle, and the so ce page is listed adjacent to the arrow, i.e.,
(see Figure 7, TRANSFER "A").
c.
Show transfers out of a branch to another location on the same page by an arrow pointing away from the transfer symbol in the direction of the transfer, i. e., Ah->.
(See Figures 7 and 8, TRANSFERS "a",
l "b",and"B".)
Remember, transfers out are away from the symbol and transfers in are toward the symbol; also, arrows point in the general direction i
of the transfer, horizontal for transfers on the l
l same page and vertical for transfers from another page.
D.
d.
For transfer of a branch to another page, list the
" recipient events" in " broken" lines above an "over-sized" transfer symbol on the page where the transfer originates. Also, specify the ) age or pages to which the branch will be transferred
)y listing the appro-priate page number below the lower right corner of the recipient event.
(See Figure 8, TRANSFER "A".
Note that the "A" structure transfers to two locations on page 1, event 2.1 and event 2.3.)
On a multipage tree, it is conceivable that there could be several recipient events fed by a single transfer structure, and that they might be located on different pages, i.e., one recipient event on page 3, another on page 4, still another on page 6, etc.
In such a case, all the recipient events should be identified by " broken lines" (dashed lines) above the TRANSFER triangle on the transfer originating page, and each recipient event be further identified by its page location, i.e., p.3, p.4, p.6, etc. When a multi-page analytic tree with many transfers is compiled onto a single, oversized " fold sheet", such as the universal MORT diagram, the page designations of transfer and recipient event locations can be replaced by coordinate area designations. The coordinate system could be based on an unlined cartesian grid with a numbered ordinate (vertical) and a lettered abscissa (horizontal) to give such event locations as la, 4c, 7f, etc.
10.
Do not number or letter logic gates, use numeric and alpha-numeric decimal identification designations only for events.
Logic gates are defined by the input events that operate through them and the specific output events that occur.
Therefore, it is not necessary to assign specific identi-fication numbers to logic gates, for they are fully defined by the events they serve.
11.
Follow the convention of indicating time sequencing or order of performance from left-to-right for related events on a single tier.
It should also be apparent that a higher tier event has greater significance (more impact on the top event) and occurs later than the more detailed contributory events located on lower tiers within its branch.
Construction and use of an analytic tree involves deductive analysis beginning with a stated top event, and then pro-ceeding through the immediate causal events, intermediate events, and detailed events to the base events, which originate the sequential chains that lead to top event occurrence.
If the analyst has done his job well, the G
- U. S. GOVERNMENT PRDf7 dig OFFICE :1,77 240-,79/16
D l
events will occur in the logical sequence displayed on the analytic tree. Critical paths to success or failure can then be discerned by the user, and appropriate fixes applied at the proper event level to assure the desired success or prevent the predicted failure.
The user's task will be made simpler, more logical, and more orderly if he knows that the analytic tree author has also established a left-to-right sequencing of occur-rence among events on a single tier. The analytic tree is a tool for use in system analysis; anything that con-tributes greater simplicity, order, and logic to it enhances its usefulness.
0 REFERENCES
[1] Nertney, R. J. and Buys, J. R., Training As Related to Behavioral Change, ERDA-76-45-6, SSDC-6, June 1976
[2] Johnson, W. G., MORT - The Management Oversight and Risk Tree, SAN 821-2, February 12, 1973
[3] Nertney, R. J., Clark, J. L., and Eicher, R. W., Occupancy-Use Reafiness Manual - Safety Considerations, ERDA-76-45-1, SSDC-1, September 1975
[4] Knox, N. W. and Eicher, R. W., MORT User's fianual, ERDA-76/45-4, SSDC-4 (Rev.1), March 1976
[5] Lambert, H.
E., System Sa aty Analysis and Fault Tree Analysis, UCID-16238, May 9, 1973 l
I l
D 1
Other SSDC Publications in This Series SSDC-1 Occupancy-Use Readiness Manual SSDC-2 Human Factors in Design SSDC-3 A Contractor Guide to Advance Preparation for Accident Investigation SSDC-4 MORT User's Manual SSDC-5 Reported Significant Observation (RS0) Studies SSDC-6 Training as Related to Behavioral Change SSDC-7 ERDA Guide to the Classification of Occupational Injuries and Illnesses j
.