NASA TECHNICAL MEMORANDUM

THE SYSTEMS SAFETY PROGRAM FOR A TOTAL SPACE LAUNCH VEHl CLE GENERAL REQUIREMENTS

By Preston T. Farish, Ph.D. Industrial Operations

C

NASA TM X- 53612

May 23, 1967

NASA

George C. Marshull Space Flight Ce nter, I

Hzlntsuille, ALabamd

https://ntrs.nasa.gov/search.jsp?R=19670029065 2020-06-19T04:05:06+00:00Z

TECHNICAL MEMORANDUM X-53623

THE SYSTEMS SAFETY PROGRAM FOR A TOTAL SPACE LAUNCH VEHICLE GENERAL REQUIREMENTS

Preston T. Farish , Ph.D.

George C. Marshall Space Flight Center Huntsville, Alabama

ABSTRACT

This report sets forth the requirements for a Systems Safety Program for a total space launch vehicle system. It defines the elements of such a program necessary to assure maximum safety and establishes the requirements for the accomplishment of those elements. shall be applied through all phases of the space launch vehicle system develop- ment including system definition, design, manufacture handling, storage , transportation, test, checkout and operation.

The principles described herein

I

NASA-GEORGE C , MARSHALL SPACE FLIGHT CENTER

NASA-GEORGE C. MARSHALL SPACE FLIGHT CENTER

~ ~~~~

TECHNICAL MEMORANDUM X- 53623

THE SYSTEMS SAFETY PROGRAM FOR A TOTAL SPACE B U N C H VEHICLE GENERAL REQUIREMENTS

BY

Preston T. Farish, Ph.D.

.. INDUSTRLAL OPERATIONS

TABLE OF CONTENTS

Page

SUMMARY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I

. .

INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I

DEFINITIONS ......................................... 1

THE SYSTEMS SAFETY PLAN (SSP) ......................... 2

Approval of the SSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Integrating SSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Systems Safety Program Elements ...................... 4

1. I K a U t 3 OLUUlGb I V l D y D w ~ l l UWLIUICIUU . . . . . . . . . . . . . 4 2. Systems Safety Criteria Development . . . . . . . . . . . . . 4 3. Systems Safety Analysis. ..................... 4 4. Procedures Review . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Activities During Manufacturing . . . . . . . . . . . . . . . . 4 6. Hardware Change Review ..................... 5 7. Activities During Testing. .................... 5 8. Analysis of Failed Components . . . . . . . . . . . . . . . . . 5

Other Activities. .................................. 5 I. Technical Interchange ....................... 5 2. Accident-Incident Investigations . . . . . . . . . . . . . . . . 5 3. Tra in ing . . .............................. 5

Relationships With Industrial Safety ..................... 5 Systems Safety Plan Approval. ......................... 6

I. Contractor Suh i t t a l ........................ 6 2. Plan Approval ............................ 6

A m - - - - 1 - O A - - ~ ; - - sa- o---L.- n-g:..:+:-..

APPENDIX. FAULTTREE ANALYSIS ....................... 7 8 g

10 ANDGa te............................ 10 PRIORITYAND Gate .................... 11 INHIBIT Gates ........................ 11 INHIBIT Gate . . . . . . . . . . . . . . . . . . . . . . . . . I1 RANDOM INHIBIT OR G a t e . . .............. 12 EXCLUSIVE OR Gate . . . . . . . . . . . . . . . . . . . 13 Othersymbols ........................ 13 Typical Fault Tree. ..................... 15

Step I - Define the Undesired Event . . . . . . . . . . . . . . . . Step 2 - Acquire Understanding of the System . . . . . . . . . . Step 3 - Construct the Fault Tree . . . . . . . . . . . . . . . . . .

iii

TABLE OF CONTENTS (CONCLUDED)

Page

Step 4 - Collect Quantitative Data . . . . . . . . . . . . . . . . Step 5 - Symbolize the Fault Tree Algebraically . . . . . . Step 6 - Solve the Algebraic Equations to Determine

16 16

18 the Level of Safety ....................

LIST OF ILLUSTRATIONS

Figure Title Page

. . . . . . . . . . . . . . . . . . . . . . . . . . . . A- I Typical Fault Tree . 17

A-2 Interfunctional Relationships ...................... 19

iv

TECHNICAL MEMORANDUM X-53623

THE SYSTEMS SAFETY PROGRAM FOR A TOTAL SPACE LAUNCH VEH I CLE GENERAL REQU I REMENTS

SUMMARY

This report sets forth the requirements for a Systems Safety Program for a total space launch vehicle system. It defines the elements of such a program necessary to assure maximum safety and establishes the requirements for the accomplis'hmeni or" i.hose elements. shall be applied through all phases of the space launch vehicle system develop- ment including system definition, design, manufacture handling, storage, transportation, test, checkout and operation.

Tne principles described herein

I NTRODU CT ION

The Systems Safety Program for a space launch vehicle system is not intended as an inhibiting activity. It is, conversely, an enabling activity which employs sound scientific engineering and management practices to support all phases of the product development, resulting in the safest possible system for accomplishment of the mission. The Systems Safety Program has as its objectives the provision of the greatest possible management visibility concern- ing total system safety, the provision of preventive and/or corrective actions that can be used to ensure astronaut safety and mission success, the assurance that safety considerations are made a basic part of the total space launch vehicle system.

DEF IN IT IONS

Safety - is the freedom from those conditions which can cause injury o r death to personnel and damage to, or loss of, equipment, property, o r the mission .

System - A s applied to this specification is defined as the total launch vehicle system including ground support equipment.

Systems Safety - is a systems engineering oriented discipline which functions to provide the greatest possible freedom from the occurrence of abnormal, o r out-of-sequence, events that could, by their occurrence, cause the loss of the crew, the system, o r the mission.

THE SYSTEMS SAFETY PLAN (SSP)

Each prime contractor or producer of a major system shall prepare a systems safety plan that is in consonance with the phase of development of his respective system. This plan shall include an identification of the applicable major system safety program elements described herein. It shall include a detailed description of the management and technical methods that will be used to accomplish these program elements and how they will function, together with a schedule for their completion, keyed to major program milestones. The SSP shall include but is not limited to the following:

I. Introduction and Scope

11. Objectives

III. Management Techniques

A. The Systems Safety Organizational Structure

B. The reporting lines

C. The responsibility and authority

D. The contractor interfaces

E. The functional relationships with other disciplines such as Reliability and Maintainability and with the manufacture and testing organizations

F. Data management - retention, distribution and effective use

G. Unique management methods and the advantages

H. Subcontractor systems safety management

I. Training and development of technical competence

J. Resource applications

K. Progress reporting

2

IV. Technical Methods

A. Trade-off study participation

B. Analysis Techniques

C . Criteria development

D. Support of design reviews

E. Procedures review, including manufacturing, handling, storage, transportation, checkout, test and operation

F. Accident - Incident investigation support including planning

G. Hardware change assessment

H. Component failure analyses (UCR's)

V. Schedules

Showing accomplishment of safety program elements keyed to

major program milestones or such schedule requirements as

may be imposed by NASA to support systems safety integration.

Approval of the SSP

Each contractor's SSP shall be submitted to the NASA Center Technical Manager for Systems Safety for approval, and when approved shall constitute the contractor's systems safety work statement. All changes to the SSP also shall require approval by the Technical Manager for Systems Safety. The approved plan shall be used by the procuring activity to measure the contractor performance in systems safety.

Integrating SSP

An SSP shall be prepared by the integrating contractor in the case of a system being developed by two o r more prime contractors with a separate integration effort. This SSP shall describe the major integration program elements, the management and technical methods to be used and the schedule of completion. This SSP also requires approval by the NASA Center Technical Manager for systems safety.

3

Systems Safety Program Elements

The Systems Safety Program Elements, listed in chronological order without regard for phase definition are as follows.

I. Trade Studies for System Definition. The Contractor's Systems Safety organization shall participate in trade studies leading to system definition. Analyses shall be performed as required to ensure that hazards are not inad- vertently incorporated into the system during definition.

2. Systems Safety Criteria Development. The Contractor's Systems Safety organization shall review data and experience gathered from all similar systems as a basis for safety criteria furnished in support of the design activities.

3. Systems Safety Analysis. The contractor will perform a system safety analysis of his system using the technique described in the appendix of this specification o r equivalent. In the event that the contractor's product is one o r more subsystems of a total system, he will support the integration of his analysis into a total system safety analysis as performed by the integrating contractor in accordance with schedules established by the Center 's Technical Manager for Systems Safety.

The analyses will be updated in accordance with established schedules to include each subsequent system in the series.

Analysis applications. The contractor's systems safety organization will support all design and flight readiness reviews of the system as required by the NASA Center Technical Manager for systems safety using the completed safety analyses as a means of demonstrating the safety of the system.

4. Procedures Review. The systems safety organization will review all manufacturing, handling, transportation, storage, maintenance, testing, and operating procedures to ensure that they do not set up out-of-sequence events o r otherwise create hazards to the system by their use. Criteria wil l be established as a basis for identifying test o r operations that are hazardous. Those tests o r operations that are hazardous will be given special attention including the development of back out o r emergency planning and procedures.

5. Activities During Manufacturing. The systems safety organization will coordinate wi th manufacturing and with Quality Control at frequent intervals to provide system safety support to those efforts.

4

6. Hardware Charge Review. The systems safety organization will review and/or analyze all proposed changes to the system prior to incorporation to ensure that safety levels established for the system are not compromised by changes.

7. Activities During Testing. The systems safety organization will provide close support to the test activities, including participation in the test program, to ensure that the safely of the system is considered in all decisions made during the performance of the tests.

8. Analvsis of Failed Components. All components failing during test o r system checkout, as reported in the UCR system, will be analyzed to determine the potential impact of that failure on the safety of the operational system.

Other Activities

i. Technical Interchange. The contractor will support the interchange of system safety information, analyses and data with other contractors and the cognizant NASA Center through meetings and other means as set forth by the Technical Manager for Systems Safety.

2. Accident-Incident Investimtioos. The systems safety organization will complete a plan for participation in accident-incident investigations. This plan will designate key personnel and describe their activities during the investigation. It will include provisions for the performance of diagnostic analyses as required to identify the causes of the event.

3. Training. The contractor will provide his personnel with training both in the systems he is developing and in the systems safety discipline such that he develops a high level of skill and technical compentence.

Relationships With Industrial Safety

The contractor will review his system safety organizations activities and responsibilities at frequent intervals in conjunction with the industrial safety activities to ensure that there are no voids in the interface between the two organizations and that the full spectrum of safety is receiving the proper effort.

5

Systems Safety Plan Approval

I. Contractor Submittal. The contractor's system safety plan will be submitted to the Center's Technical Manager for Systems Safety (one original and six copies) five weeks following implementation of this specification.

2. Plan Approval. The Center's Technical Manager for Systems Safety will review this plan and return it to the contractor within three weeks as approved o r approved subject to required revisions o r disapproved subject to required revisions.

6

APPENDIX

FAULT TREE ANALYSIS

The systems safety analysis, when completed, must be a useful tool and must be fully program effective. The technique employed should have sufficient versatility to encompass the complete system. It should provide management visibility as to the safety of the system in terms of a quantification of the safety; and it should identify critical fault paths, treating cascading faults, and interfunctional relationships. The analysis should be sufficiently flexible to measure the impact of both large and small system changes.

Development of fault tree analysis techniques began in 1962 a t Bell Telephone Laboratories ( BTL) . BTL performed a ballistic missile system safety study using a method of mathematical analysis applicable to probability combinations in a fault tree format.

This technique is now expanding throughout the aerospace industry be- cause it possesses many unique capabilities:

a - It allows the quantitative measurement of the safety of any given system.

b - It can be used to assess the safety impact of any change to that system.

c - It can locate and identify all of the critical paths and the possible failures which yield a given set of failure symptoms.

d - It can accommodate Interfunctional Relationships and cascading faults.

The following steps are required in fault tree analysis:

I - Define the undesired event.

2 - Acquire understanding of the system.

7

3 - Construct the fault tree.

4 - Collect quantitative data.

5 - Symbolize the fault tree algebraically.

6 - Solve the algebraic equations to determine the level of safety.

Step 1 - Define The Undesired Event

The objective of a fault tree analysis is to identify all hazardous potentials (failures, malfunctions, o r human errors) within a system, determine the level of safety of the system, and indicate those areas where additional effort would be most fruitful in improving the safety level.

The measurement of the level of safety for an operational product, requires initially the definition of the most undesired event, i. e. , the event which must be kept from happening.

Definition of the most undesired event is not always as simple a s it might appear from a superficial view of the system. The undesired event may not be the final result of a malfunction o r incorrect procedure, but rather the final single action that inevitably leads to catastrophe. Consider the rotary lawn mower for example. The possibility of injury to the operator might appear to be the most undesired event to a lawnmower manufacturer. On the other hand, because of possible lawsuits, he should also be concerned with the possi- bility of his product throwing a blade o r some other object and injuring a passerby.

It is impossible to construct a fault tree with more than one "most undesired event"; yet it is possible to isolate several events that must be prevented from occurring. This situation makes it mandatory to establish terminology for the event that will encompass the lesser events individually o r collectively.

A s will be shown, fault tree analysis is a team effort. A tremendous amount of "brainstorming" and carefully considered inputs from many sources are required to make the analysis truly valid.

8

Step 2 - Acquire Understanding of the System

The safety of any system must be measured from a specific time interval and type of activity. For this reason, the systems safety analyst must thoroughly understand the system and its intended use.

The calculation of exposure to operational environments requires the systems analyst to consider two variables: duration of operation and the stress levels. The length of projected missions will have a direct bearing on exposure to known hazards and, therefore, may be assigned a specific numerical value in fault tree construction. The stress level will vary with each segment of the mission, i. e. , countdown liftoff, boost, orbit, etc.

The construction of a fault tree for a given system o r operational procedure necessitates that the analyst consider controlled premature termina- tion of a specific event. For instance, an engine malfunction o r failure may be compensated for by immediate abort action, still, the possibility of failure to react o r incorrect reaction on the part of the astronaut must be considered. Conversely, a reasonable probability must be assigned for occurrence of the proper action.

The analyst must also consider the possibility of inability to initiate controlled termination during certain segments of the analysis. Once the Lunar Module has returned from the lunar surface, for example, the Apollo system is committed to follow its normal mission profile and any inflight failures must be accepted as additional events in fault tree construction.

The principal objective of the system safety analyst is to determine how the system, considering the crew as an integral part, could fail and cause the undesired event. The myriad details the engineer can develop to determine all the probable ways a system can fail depends on his understanding of the system. A space vehicle has so many subsystems it is obvious that the systems safety analyst cannot possibly have a thorough working knowledge of each. Thus, in addition to his basic skill he must have broad experience with subsystems in general and must understand the basic concepts of the various system functions involved. Accordingly, a complete Fault Tree analysis can be developed cooperatively only by a group of engineers having all of these required skills.

9

Step 3 - Construct The Fault Tree

A fault tree is a graphical representation of the sequential relation- ships of basic system fault events which can contribute to the occurrence of the end fault condition defined by the tree.

The development of a particular fault tree is accomplished in an order- ly manner and begins with definition of the end system fault condition o r unde- sired event for which a determination of probability of occurrence must be made. Once definition of the end fault event is made, the system is analyzed and all possible sequences of events are determined which, upon occurrence, result in the undesired event. Such analysis is entirely dependent upon a thorough knowledge of the system functions and equipment. Each of these contributing fault events is further analyzed to determine the logical relation- ships of system fault events which may cause them. In this manner, a fYreell of logical relationships among fault events is developed. The development is continued until all fault events on the tree are defined in terms of basic, identi- fiable faults which may be assigned known probability values. The connections between the events are depicted in the fault trees as a progression of events through logic gates. Two basic logic gates are used in constructing a fault tree: The AND and the OR gate. These and several variations of them which are occasionally used are described in the following paragraphs.

AND Gate. The logical AND function is symbolized as follows:

X

This symbol is understood to represent the logic operation whereby a r'truel' output exists at X when inputs El through E are simultaneously present in

their "true" state. Otherwise X is in a "false1' stage. n

i o

PRIORITY AND Gate. The PRIORITY AND Gate performs the same function as an AND Gate with the additional stipulation that one event must precede the other.

1

De scription of

Condition

INHIBIT Gates. The INHIBIT Gates describe a causal relationship between one fault and another. The input event directly produces the output event if the indicated condition is satisfied. The conditional input defines a state of the system that permits the fault sequence to occur, and may be either normal to the system o r the result of equipment failures. It is represented by an oval if it describes a specific failure mode, o r a rectangle if it describes

a condition which may exist for the life of the system.

INHIBIT Gate. The INHIBIT Gate provides a means of applying conditional probabilities to the fault sequence. If the input event occurs and the condition is satisfied, a lltruelf output will be generated at X.

X

Input Event

11

RANDOM INHIBIT Gate. The RANDOM INHIBIT Gate is functionally the same as the INHIBIT Gate. However, in this case the conditional input is a variable.

X

Input Event

Al l of the above gates are basically AND Gates. The following two gates are OR Gates.

OR Gate.

This symbol represents the logic operation whereby a "truet1 output exists at X when any one o r more of the inputs E i and E are present in their "true"

state. The output X is "falset7 only when all inputs E, through En are 'Yalse" simultaneously. N o order requirements exist at OR Gates.

n

12

EXCLUSIVE OR Gate. The EXCLUSIVE OR Gate performs the logical OR function but will not respond to the co-existence of two o r more specified inputs.

X

Other Symbols. In addition to the gates, several other symbols are used in the construction of fault trees.

The rectangle identifies an event, usually a malfunction, that results from the combination of fault events through the logic gates. The rectangle is also used to describe conditional inputs to INHIBIT gates. In this use it indicates a condition that is presumed to exist for the life of the system.

The circle describes a basic fault event that requires no further development. This category includes component failures whose frequency and mode of failure are derived through laboratory testing.

0 13

The diamond describes a fault event that is considered basic in a given fault tree; however, the causes of the event have not been developed usually be- cause the event is of insufficient consequence.

The oval is used to record the conditional input to an inhibit gate. It defines the state of the system that permits an event sequence to occur, and may be either normal to the system o r be the result of equipment failures.

The house indicates an event that is normally expected to occur.

3 14

The triangles indicate transfer symbols. A line from the apex of the triangles indicates that data from another part of the tree is also to be input at this point. A line from the side of triangle denotes that this portion of the tree is also to be transferred to some other place in the tree.

"he double diam-nnd is uged b the sLm-plification of the fault tree for numerical evaluation. The event described results from causes that have been developed but are not shown on a particular version of the fault tree.

The term lfeventll represents that situation whereby an input to a gate or an output from a gate goes from an unfailed o r "false" state to a state of failure o r "trueT1 condition. This "event" represents a system failure, whether it be a basic hardware fault or a gate output resulting from input events. The "event1' will remain %xetl until the conditions for its existence are no longer satisfied; i. e. , either repair of a hardware failure is accomplished, thereby removing the failure from the system, or the input conditions required for a gate output are no longer satisfied due to some change in the system.

Typical Fault Tree. A typical fault tree for a simple system is illustrated in Figure A-I. Fault trees representing more complex systems are much larger and more involved, but the relationships are the same. The num- bers and letters on the tree are only to facilitate discussion and do not represent actual designations.

by the letters A through K. The logical relationships among the events are represented by AND and OR gates and are given number designations i through

The basic fault events are represented by circles and are designated

15

7. The output events a re represented by rectangles and are designated by Xi through X,.

The overall effect of this representation is to present a working model of the inter-relationships of basic system failure events as they contribute to a major system failure.

Step 4 - Collect Quantitative Data

After having constructed the fault tree in sufficient depth such that the inputs are specified in terms of component failure, the next step is to deter- mine the probability of failure of each of the components. This type of data is available from such sources as the Failure Rate Data Program o r the Relia- bility Group within one's organization.

Step 5 - Symbolize the Fault Tree Algebraically

Examining the sample tree in Figure A-1, it is seen that the event Qi (represented by a true output from gate i) is equivalent to the "true" state of both events X2 and X3. In similar fashion X2 is equivalent to the true state of either event A or event X4 o r both. The logical AND is represented by the symbol ( ) and the logical OR by the symbol (+) . Each gate can then be represented as follows:

The total tree can then be represented by a single equation (by simple substitution) as follows:

= ( A + B * C D} ( [ J + (X7+I)] . K}

= ( A + B C D } * ( [ J + ( E * F . G . H ) + I I K }

= [A+BDCl [ K ( I + J + E F G H ) ] .

16

Figure A - i . Typical Fault Tree

17

This equation is a Boolean representation of the fault tree. It is to be noted that the gates in the tree establish the relationships of the events in the end expression and that the output of the tree is expressed in terms of the basic input events.

Another sample tree, Figure A-2 shows how interfunctional relati- ships are handled. For example, failure event W has an effect on gates 6, 8, 9, and 10 or ultimately gates 2, 3, 4, and 5; thus it can be seen that event W and any one of four other events provide a straight path to Q. The equation which represents the tree (using the substitution technique described above) is:

Q i = ( C + D ) ( V + W + X Y Z ) + B ( V + W + X ) + A ( V + W + Z ) +

+ E ( W + Y).

The probabilities of failure can now be utilized in the equation for the fault tree. By using normal relationships for the combination of probabilities and converting the equation from a Boolean expression to a normal algebraic expression, the equation will yield the probability of occurrence of each of the major branches to that probability. If the probability of occurrence of the undesired event is determined to be too high, the branch which is the major contributor can be identified and efforts to increase the safety can be applied to the most promising branch.

Step 6 - Solve the Algebraic Equations to Determine the Level of Safety

In the simplest of fault trees the solution of the equation consists of simply applying Boolean techniques to the equation originally derived from the fault tree to reduce the equation to the simplest possible form. The proba- bilities of the failures are then substituted into the equation and the equation is algebraically solved to yield the overall probability of the undesired event. Few trees are small and simple enough to solve in this manner and the solution is usually obtained by computer. The computer procedure is the same as the manual method except that the computer is given the output of each gate as a function of the gate inputs and the computer not only develops the equation but removes the redundancies and calculates the probabilities.

The computer method offers many other advantages in cases where simulation is required o r where "Repairf1 is considered. The simulation is conducted by generating random life length and repair times, according to the

18

I I 1 > I Q2 Q, Q C Qs

Figure A-2. Interfunctional Relationships

19

probability distribution given for each input. This is done by pseudo-random number generations on the computer. These random numbers provide data for a computer analog of the fault-tree. At the occurrence of a failure of any input the fault tree logic stored in the machine is checked to see if the undesired or the time period of interest, T, has elapsed. A t this time, all of the inputs are recycles to an llupff state and a new trial begins. After a predetermined num- ber of trials have been considered, an estimate is computed for the probability of the undesired event occurring within that time period from the formula:

where n = number of times the undesired event has occurred out of N trials.

It can be seen that after all of the above steps have been accomplished, a quantitative measure of the safety of the system can be established; the contribution of each event to the "unsafe" condition can be determined; and the safety impact of any change to that system can be assessed. Therefore the "promise" of a suggested change toward increasing the overall safety of the system can be assessed.

George C. Marshall Space Flight Center National Aeronautics and Space Administration

Huntsville, Alabama, June 28, 1967

20

APPROVAL

THE SYSTEMS SAFETY PROGRAM FOR A TOTAL SPACE LAUNCH VEHICLE GENERAL REQUIREMENTS

By Preston T. Farish, Ph .D .

The information in this report has been reviewed for security classifica- tion. Review of any information concerning Department of Defense or Atomic Energy Commission programs has been made by the MSFC Security Classifica- tion Officer. This report, in its entirety, has been determined to be unclassified.

This document has also been reviewed and approved for technical accuracy.

'.

W. A. Mrazek Assistant Director for Engineering Industrial Operations

21