ML19322C354

Nasa Safety Manual.Vol 3

ML19322C354
Person / Time
Site:	Crane
Issue date:	03/06/1970
From:	Hayes D NATIONAL AERONAUTICS & SPACE ADMINISTRATION
To:
References
TASK-TF, TASK-TMR NHB-1700.1, NHB-1700.1(V3), NUDOCS 8001160891
Download: ML19322C354 (48)

Text

_

.aig J

v

.,. ~

8 r

- l

~

~

p.

e, 4

9

' ' e 9i _

- *,;~

-+

v g

b,

. y t

e-s' s

c

, q.

t -

g.

R r.

~

v i

t-l y

l 4f b'

h m

y 9

.x

'- ~ <

' ?

y

=-

e e

~_.

a-a a

=

,. AF'

~

'l f-

=

+

4 g

q A

a.

,y

.)

J

+.

{

A M

y

+

~

zg

. s&

A s

s

',T c.

.g

,s

.v

.v

=.

y l

4 '

4

's 4

,l

~ -

'g

., g --

H y

3 z

8 3

r

~

e.

m 7*

s

. g f

,W A,

7 a

l r

=

1' l

d

,9,

., ~ '

_y f '

3

.1 4

4 g

g

.-o.

p 6

p 4

4

+,

v'

- ^~

a 4

+

-4 k

- ;!g b

e-y

- i.

g

,.,g.

- t i

^;'

. w :.

~

-t.

-,. ; u-n.

a g

z.

.l e

s N.

• s'-

g_

,' -., - 4

+_

+

.3 g -

+,

4_

c, k

( -

5 t

4t)".

.{

• i l

' 1 g

.e s.

( ;'. )

l 8

~

( 3 g

4

- +

g

. I g

s

. x y.

• e t

• z

?*

. 6' '

'... ',, ;,..,., ~

'9 4.'

~

)*

s s

y n

s g

' g s

'?

. g e

1

.. +'

,e, '

.e.-

9 i,

~

{}:

. l 4

~

g.

1 p

.l.-

f.

$+

• =,.

.4 '

,"#y 1

j 7,

- a y,, ?,

s.

,g a

s.

=f g,

)

r

+

s,,.,,

m

,z.

j ,

R' 4r

[

p t t

NHB 1700.1 (V3)

PREFACE DATE: March 6,1970 This Volume 3 of the NASA Safety Manual sets forth the basic elements and techniques for managing a system safety program and the technical methods recommended for use in developing a riskevaluationp ogram that is oriented to:

The identification of hazards in aerospace hardware systems.

a.

b. The development of residual risk management information for the program manager that is based on the hazards identified.

The methods and techniques described in this volume are in consonance with the requirements set forth in NHB 1700.1 (VI), Chapter 3.

This volume and future volumes of the NASA Safety Manual shall not be re-written, reprinted or reproduced in any manner. Installation implementing procedures, if necessary, shall be inserted as page supplements in accordance with the provisions of Appendix A.

No portion of this volume or future volumes of the NASA Safety Manual shall be invoked in contracts.

Comments and questions concerning the contents of this publication should be referred to the National Aeronautics and Space Administration (NASA Safety Office, Code DY), Washington, D.C.

20546.

k j

h ld Og -)

NASA Acting Director of Safety DISTRIBUTION:

SDL 1(SIQ) i I

ORGANIZATION OF THE NASA SAFETY MANUAL OVERALL COVERAGE The NASA Safety Manual will be issued in several volumes, by major safety subject breakdowns. The following list shows the initial plan for publishing the individual volumes:

Assigned Volume Title No.

1 Basic Safety Requirements 1700.1(VI) 2 Reserved 3

System Safety 1700,1(V3)

DOCUMENT REFERENCING Each volume is assigned its ownidentificationnumberwithin the basic classi-fication code. The alpha-numeric suffix within a parenthesis identifies the volume of the manual; e.g., NHB 1700,1(V3): this number indicates that tMs is the third volume.

When a volume is revised, the suffix identification will be changed to indicate the revision number such as NHB 1700.l(V3-A).

In referencing or requesting any volume of the NASA Safety Manual, the com-plete, specific NHB number must be used.

PARAGRAPH REFERENCING 1.

Within the NASA Safety Manual. The following shows the general paragraph numbering system applicable to all volumes:

3 3

01 la(1)(a) a L

n a

Volume 3 Chapter 3 Paragraoh 301 Subparagraphs This system provide s for referencing any paragraph or complete volume requirement in any other volume.of the NASA Safety Manual without the need for identifying the NHB number and title.

2 In Other NASA Documents. When it is necessary to reference any para-graph in any otherNASAdocument, the specific NHB number and paragraph number must be used together as follows: "NHB 1700,1(V1,, par.1103-la (1)(a)," or " paragraph 1103-la(1)(a) of NHB 1700.1(V1)." Whenit is neces-sary to reference any complete volume in any other NASA document, the specific NHB number (which also identifies the volume) must be used, l

iii

i TABLE OF CONTENTS Page Par.

CHAPTER 1: MANAGEMENT TECHNIQUES 1-1 3100 Int r o du c tion..................................

1-1 3101 Purpo s e and Sc ope.............................

1-1 3102 Ris k Evaluation...............................

1-1 3103 System Safety Program Elements...................

1-2 3104 P l a nnin g....................................

1-4 3105 O r g ani z ati on.................................

1-6 3106 C o nt r a c t in g..................................

1-7 3107 Inte rface / Coordination..........................

1-11 3108 C r it e ri a '....................................

1-12 3109 Analy s i s....................................

1-14 3110 R e p o r t ing...................................

1-14 3111 E va lua t io n...................................

1-17 3112 Data Ret e ntion................................

CHAPTER 2: TECHNICAL METHODS 2-1 3200 Int r odu c t io n..................................

2-1 3201 P u rpo s e and S c op e.............................

2-2 3202 Ha za rd Analys e s..............................

2-2 3203 P r elimina ry Ha z a rd Analys i s......................

2-4 3204 F ault Ha zard Analysis...........................

2-12 3205 L o gic Dia g ram Analys is.........................

2-18 3206 P ro c e du r e s Analys i s...........................

2-19 3207 Re quire ments Ve rific ation........................

APPENDIXES A: Installation SupplementalInstructions and Requirements a-1 b-1 B: System Safety References c-1 C: Training Courses V

r CH APTER 1: MANAGEMENT TECHNIQUES

/

3100 INTRODUCTION There is direct relationship between the degree of safety achiqvec in a NASA aerospace system and the management emphasis placeLon the safety of the system being designed, manufactured, tested,and operated.

This chapter of the safety manual describes the tasks that should be accomplished and the working relationships that shouldbe established to formalize the system safety effort into a discipline, to the end that the program manager will have maximum visibility into the risks he is as suming.

3101 PURPOSE AND SCOPE This chapter provides functional safety managers with an outline of the techniques that are useful in the planning, implementation, and admin-istration of a system safety program. The management techniques de-scribed are applicable to any size or type of NASA hardware develop-ment program and throughout the entire system life cycle. These, methods should be i m p1 e m e n t e d to the extent that the evolving system safety effort fully supports the unique needs of the hardware i

program. This Volume is intended to be evoluntionary in nature and therefore subject to continuous upgrading and change as new methods are developed and have been proven satisfactory for NASA application, f

1 3102 RISK EVALUATION i

1. The program manager of an aerospace system must assume certain i

risks that are attendant to the design, manufacture, test, and opera-tion of the hardware system to effectively accomplish the mission for which the system was developed. The acceptance of these risks should be based on thorough visibility as to the nature of hazards and risks that are in existence and the options and alternatives to the acceptance of the risks.

2 The decision on whether to as sume a risk is clearly a program management responsibility. This decision is no better than the quality of the risk data that serves as a basis for the decision. Ac-cordingly, the development of hazard and risk data should be as-responsbility to professionals whose training and signed as a orientation cause them to search out and find the hazards in the system before these hazards manife st themselves in terms of damaged or destroyed hardware.

3103 SYSTEM SAFETY PRO 7 RAM ELEMENTS 1

Each functional system safety program has nine basic elements which include:

a. Planning,

b. Organization, c.

Contracting, 1-1

p 1

Interface / Coordination, g

Criteria, f.

' Analysis, j

g. Reporting,

h. Evaluation, i

i. Data Retention.

2. Each of the above elements and the related activities are described in the ensuing paragraphs. All of these elements are oriented toward an overall approach to risk evaluation by:

a. Identifying the hazards in the system,

b. Determining corrective actions that may be implementedto either remove, or control, the hazard or to provide alternatives, Recommending corrective action or alternatives to the appro-c.

priate management level for a decision to either resolve the l

hazard or assume the risk.

d. Documenting those areas in which a decision has been made to assume the risk, including the rationale for the risk assumption.

3.- The detail with which each of the nine safety program elements set forth in subparagraph 1. is developed and implemented is dependent upon the complexity and mission of the hardware system being de-veloped.

3104 PLANNING

1. PRELIMINARY SAFETY TASKS It is anticipated that, in most cases, formal planning of the safety I

offort for support of the system feasibility studies would not be initiated. There are, however, severaltypical safetytasks that should be completed during these activities. These tasks then become the i

foundation for the planning of system safetyefforts during the system definition, design, manufacture, test, and operation. These include:

A review of pertinent historical safetydatafrom similar systems.

a.

l

b. A ontinuing review of the gross hardware requirements and con-cepo, to maintain an understanding of the evolving system.

t A rev ew of the proposed mission objectives, c.

d. Completion of the planning for follow-on safety activities,

e. The completion of preliminary hazard analyses to identify potentially hazardous systems and to develop initial safety re-quirements and criteria, j

1-2

f.

Participation in trade studies with the result of the preliminary hazard analyses identifying highly hazardous areas, with recom-mendations as to the alternatives.

g. Identification of the requirement for special contractor safety studies that may be required during system efinition or design,

h. Estimation of gross resource requirements for the system safety program during the complete system life cycle.

1 Preparation of an index document that identifies all pcirtinent safety data developed during the life cycle of the system, such as the results of analyses, the criteria and requirements imple-mented, the results of special studies and the yplicable his-torical data. This index is updated at the conclusion of each major increment of the system development or as determined by pro-gram milestone dates.

2 GOALS AND ODJECTIVES a.

Any planning exercise requires that certain basic decisions be made. Safety goals and objectives should be established, and the type of system safety input that is to be furnished to the overall program should be determined prior to initiating the planning effort. Goals should be measurable in every case and should state what system safety would intend to accomplish as a result of having performed the various safety tasks.

b. Once these safety goals and objectives have been established and agreed upon by appropriate program management level, the planner can begin to become familiar withboththe evolving hard-ware system and the environment withinwhichthe safety program is to be conducted. Having equated the safety goals to the needs

(

of the system being developed, the planner considers all the alternative methods and analyses that can be used to meet these

^

safety goals and objectives. The optimum methods are selected from these alternatives and the planning is begun. It should be noted that these goals must be structured such that safety tasks can be selected that will accomplish the goals and when the tasks have been completed the result of the effort will clearly demon-strate that the goals have been met.

3 PLAN CONTENTS The Safety Plan should include:

a. A description of the initial safety tasks initiatedduring the feasi-bility studies, system definition, design, manufacture, test or operation that are to be continuedthroughoutthe forseeable future of the system life cycle.

i l

b. Additional tasks that are to be initiated during ensuing program activities that evolve from the list of safety elements described in paragraph 3103 1-3

f l

f 1

c. The development of requirements for contractor safety effort, m

d. An estimate of numbers and types of personnel equired for the safety effort.

e. A description of the methods that will be used to perform these safety tasks, control the effort and accomplish the objectives.

f.

Scheduling the safety effort including milestone identification, program activities, phasing, and integration.

g. Identification of the safety output that will result from the effort, the expected application of the output, with provisions for the documentation of specific results of the safety effort, A typical safety plan outline is shown u Figure 1.

4 PLAN REVISIONS

a. It should be noted that if the planned safety program is to have sufficient flexibility, the individual plan must be revised as re-i quired to satisfy the changing needs of the program, although the plan should nos be revised for the sake of change alone. Further, I

it can readily be seen that a plan may vary in size from one page in length to a detailedmulti-page document, depending on the size, j

complexity and needs of the system.

i

b. The planning tends to be an iterative process in that the plan is T

refined and expanded as milestones of the system development

)

are accomplished. Emphases are realigned, nonproductive tasks are abandoned and new tasks developed as required to accomplish the safety goals. Analysis methods are evaluated against pro-j gram needs and specific techniques are selected andimplemented, as required to provide a sufficient depth of safety / risk evaluation visibility.

3105 ORGANIZATION 1

The organization of the functi'onal system safety effort is developed to accomplish the tasks set forth in the safety plan. Safety may be part of the system engineering organization or part of a systems effectiveness organization, collocated with the reliability, quality or maintainability organizations. As a general rule, to maintain objec-tivity and the check and balance system, it is preferable that system safety not be part of the design engineering organization.

2 The major safety tasks to be accomplished are broken down into subtasks and responsibilities assigned that will support accomplish-ment of the safety goals. The ongoing activities, together with the quantity and complexity of the safety tasks scheduledfor completion, dictate the size and technical depth.of the safety organization. For example, a safety organization may vary from only one man who spends part of his time accomplishing the safety tasks to an organi-zation of 20 or more people supported by an extensive contracted effort. Obviously good staffing practices should be followed, and the greatest possible technical professionalism developed.

j 1-4

CHECKLIST OF REQUIREMENTS FOR A SYSTEM SAFETY PLAN 1.0 PURPOSE AND SCOPE 2.0 APPLICABLE DOCUMENTS (Reference only documents cited in the plan text) 3.0 SAFETY ORGANIZATION 3.1 Relationship to total organization 3.2 Organizational array 3.3 Responsibilities 3.4 Interfaces 4.0 SAFETY TASKS TO BE COMPLETED 4.1 Criteria development 4.2 Analyses 4.3 Design / program review participation 4.4 Contractor / subcontractor requirements 4.5 Reporting 4.6 Documentation 4.7 Planning 4.8 Evaluations 5.0 METHODS FOR ACCOMPLISHING SAFETY TASKS 5.1 Criteria - development, documentation and monitoring 5.2 Analysis technique 5.3 Other program activities 6.0 SCHEDULE FOR TASK COMPLETION (Keyed to major program milestones)

Figure 1 1-5

3. Irrespective of the relative size of the safety organization, it should s

be placed in the reporting chain at a point which allows the risk evaluation output resulting from the safety effort to flow directly to the appropriate level of management in support of risk management decisions.

3106 CONTRACTING

1. TWO FORMS Contracting of a system safety effort maytake one of two forms. The effort may be contracted in a separate contract, such as a special safety study during the early development, or may be part of the total system procurement package. In either case, unless the re-quirements being contracted are carefully prepared so that the cen-tractor clearly understands what he is expected to accomplish, the contractor cannot provide the engineering and management services being sought. The fundamental elements of the two forms of pro-curement mentioned above are essentially the same and follow a well-defined procurement system (see NASA Procurement Regula-tion, Subpart 52 - SAFETY).

2 THE REQUEST FOR PROPOSAL (RFP)

The RFP must state in clear, concise terms:

a.

The scope of the effort.

S

b. The specific tasks the contractor is expected to perform.

)

c. The reporting requirements,

d. The program milestones that must be met, e.

That the contractor is expected to provide a system safety plan as part of his bid package, which is in consonance with para-graph 3104. This contractor plan should include a listing of the system safety tasks he plans to complete and include a descrip-tion of:

(1) The methods he plans to use in accomplishing these tasks.

(2) The output or product that will be produced by the safety effort.

(3) The use that will be madc of the safety output.

(4) The organization that will be developed to complete the task.

(5) The deliverables.

(6) The reporting of safety problems, activities, and accomplish-ments.

(7) The sub-tier schedule of activities leading to task completion s

in support of major program milestones, y

l l6 l

3 PROPOSAL EVALUATIONS FOR SOURCE SELECTION The safety manager should participate in the proposal evaluation activities and rate each proposal on the basis of the contractor's demonstrated understanding of the RFP requirements reflected in his plan as well as the cost history and the history of the contrac-tor's past performance.

4.

THE STATEMENT OF WORK The evaluation of the proposal should also leadto the decision on the suitability of the contractor's system e afety plan for use as a seg-ment of the overall statement of work. Normally a separate segment of the statement of work covering the system safety requirements, included in the contract schedule, is preferable to negotiation of the contractor's safety plan since the contractor's plan is his blueprint for meeting the requirements. This segment oiwork may be based on the original RFP and the safety data submitted by the contractor as part of his bid package.

3107 INTERFACE / COORDINATION

1. GENERAL The effectiveness of the functional system saf.J~ effortis determined by the quality and quantity of the ottput anc how that output is ap-plied. The development of the output is dependentupon the interfaces established, the currentness and quality of the data safety personnel have to work with, and the technical competence within the safety organization.

2. INTERFACE ESTABLISHhiENT Working interfaces should be established at the earliest possible time in the system development and should be postured on the basis that system safety has a valuable service toprovide the other organi-zations in the program. As each interface is established, the safety manager should strive to reach an understanding with his counter-parts as to:

a. The type of data that is to be produced by each organization.

b. The amount of this data that will be needed by safety personnel and a schedule for its availability.

c. The use safety personnel will make of this data,

d. The output of the safetyeffortincluding the format and availability s chedule,

e. The safety data or effort that may be required by the interfacing organizations.

Typical interfaces and data flows are pictured in Figure 2, which shows the safety activity set apart on the left in order to better describe the data exchange.

1-7 I

I

SAFETY INTERFACES AND TYPICAL DATA FLOW

~

M INPUT p

DRAWINGS, TEST REQUIREMENTS, Off RATIONS OUINT Q

& RED LINES R

N ENGINEERING SYSTEM DESIGNED FOR MISSION SAFETY CRITERIA, DESIGN & PROCEDURE ANALYSES, O

HARDWARE CHANGES, RECOMMENDATIONS Y

<MTBF-FMEA DATA, CRITICAllTY LISTS R-SYSTEM HAS CERTAIN PROB-R S

ABILITY OF SUCCESS T

R & QA SAFETY ANALYSES, SAFETY INSPECTION A

REQUIREMENTS QA. SYSTEM MANUFACTURED & TESTED PER ENGINEERING REQUIREMENTS M

n PROPOSED HARDWARE CHANGE CONFIGURATION AS DESIGNED M

7

{

MANAGEMENT CONFIGURATION 00 IMPACT OF CHANGES ON SAFETY A

l N

^

\\ UNUSUAL MANUFACTURING ACTIVITIES A

MANUFACTURING SYSTEM MANUFACTURED AS DESIGN INPUT TO MANUFACTURING PLANNING G

E E

T TEST PROCEDURES, TEST SYSTEM DRAWINGS SYSTEMS TEST SYSTEM OPERATION VAllDATED M

Y PROCEDURES & TEST EQUIPMENT ANALYSES E

< OPERATIONS PROCEDURES N

OPERATIONS SYSTEM OPERATED WITHIN DESIGN

& MISSION PARAMETERS T

OPERATIONS PROCEDURES ANALYSES RISK EVALUATION DATA FOR RISK MANAGEMENT DECISIONS j

4 u

a

)

3 THE SAFETY-ENGINEERING INTERFACE The interface with engineering is especially important. This working relationship should be developed during the early part of the system development and continued throughout the life cycle to the conclusion of the program. System safety personnel work closelywitn engineer-ing personnel in developing safety criteria, and, based on the safety analysis, recommend methods of reducing risks, coordirate on the design of safety devices and recommend hardware changes to remove or control hazards. Safety personnel provide close support and assistance to the engineering staff during design and program re-views, and, as the result of having performed a thorough technical safety effort, should be able to make a significant contribution dur-ing these reviews in terms of visibility into the risk assumption status.

4 THE SAFETY-R & QA INTERFACE

a. The system safety-reliability and qualityinterface is of particular interest because the two areas can provide effective support to each other when properly conducted. Much of the data developed by the reliability program finds use bythe functional safety effort in the preparation of the Safety Analyses, and there are com-mon interests between the two programs indesign review, failure reporting and human error areas. It is therefore important that the two areas coordinate closely with one another in program planning and execution to ensure that each provides appropriate support to the other and that duplication is eliminated,

b. The safety effort should provide the quality assurance organiza-tion with inspection requirements for safety items and informa-tion on safety critical characteristics. A rapid flow communica-tion channel should be established and maintained to assure that the safety staff receives quick notification of safety discrepan-cies, parts failures and assembly errors.

5 THE SAFETY-CONFIGURATION MANAGEMENT INTERFACE The safety-configuration management interface should be estab-lished as soon as the design of tae system is sufficiently well de-fined to be controlled by a configuration management activity. Safety personnel should review all changes for their potentialimpact on the 4

safety of the system. Safety changes especially should be reviewed to determine that they do improve the safety and reduce the risk suf-ficiently to merit implementir.g the change. The safety organization also should participate in all proposal and committing change board activities when safety changes are being exercised.

6. THE SAFETY-MANUFACTURING INTERFACE a.

The system safety-industrial safety working relationship is established in the manufacturing, test and operations areas. The system safety-manufacturing relationship can best be charac-terized as advisory in nature, depending largely on the relative effectiveness of the industrial safety program.

1-9

b. The system safety organization should review the manufacturing planning of critical activities to assure that a fabrication or as-O sembly process does not exist that can result in residual damage being incorporated into the system as part of the manufacturing

process,

c. Major reliance is also placed on the qualif.y control activities during the manufacture of the system. Requirements for special inspection of safety critical items and activities should be in-cluded on the proper drawings. The se safety items are then inspected by the quality people as part of their regular inspection and buy-off activities with failure and rejection reports providing a rich source of useful safety data.

7 THE SAFETY-SYSTEMS TEST INTERFACE

a. The system safety staff works closely with the test organization.

Test procedures are reviewed to assure that hazardous tests are identified as such and that the procedures, prepared to operate the system under test, contain shutdown and backout capability as well as cautions and warning notes,

b. Test systems are analyzed to assure that hazards have been fully considered and that the risks are minimized wherever possible.

Safety representatives should occasionally witness the accom-plishment of hazardous testing to measure the validity of the safety input to the test procedures and to gain a better under-standing of the test activities.

8 THE SAFETY-OPERATIONS INTERFACE The safety activities completed during operation of the system a.

include staff support during system final assembly, checkout and validation, maintenance and operation. Hazardous tasks per-formed as part of the checkout and launch are identified as such, and the supporting contingency planning is reviewed thoroughly to assure that exposure is minimized and recovery is well organized and planned,

b. Operating procedures are reviewed to assure that backout or shutdown provisions, warning and caution notes have been in-

cluded, i

l

c. Special attention is devoted to system interfaces since hazards l

recognize neither contract nor mechanical boundaries. The safety

[

staff can make a major contribution to the system integration ac-tivities as a result of having completed the normal safety tasks.

l l

d.

The participation of safety personnel in system operations should be on an active basis, to measure the validity of the safety input to the operations procedures and to become more familiar with the operational program.

x

\\

.)

l~

1-10

9. SYSTEM SAFETY-PROGRAM MANAGEMENT INTERFACE

a. The effectiveness of the system safetyeffortis measured in terms of the safety impact on the system from the standpoint of reduced risks. One of the principal avenues available to er.ert this in-fluence on the system is through the program manager's deci-sions. Accordingly, the safety manager must establish an effec-tive interface with the program manager so that the program manager will understand what kind of an output can be expected from the system safety effort, when this output will be received, and how it will be useful to him. Next, safety personnel must mount a competent effort to produce a technicallyaccurate output which is acceptable to both engineering and the program manager from a technical standpoint.

b.

The provision of this safety output, in the main, should be sched-uled to the major program decision points such as the Prelimi-nary Design Review (PDR), First Article ConfigurationInspection (FACI), Design Certification Review (DCR), Flight Readiness,

Review (FRR) and any other special reviews. The safety output should be expressed as a total risk profile with sufficient sup-porting data to enable the program manager to decide whether to:

(1) Assume the risks; (2) Change the hardware to reduce the risks; or (3) Revise the mission to reduce the exposure of the hardware and thereby reduce the risks, or by imposing constraints at control exposure to high risks,

c. The safety manager should evaluate the output produced by the effort performed in the name of safety on a continuing basis to assure that it is useful, and that it is being used. This provides a valuable control function to delete nonessential tasks from the on-going safety activities.

10. OTHER INTERFACES Where more than one field installation is involved in conducting the system development and operation, it is vital that interinstallation safety coordination meetings be held on a regularly scheduled basis and that communication channels be opened and encouraged for the expedited flow of safety data. This same type of safety data exchange system should be used in the case where more than one prime con-tractor is used by an individual field installation.

3108 CRITERIA 1

GENERAL The second method by which the system may be influenced in addi-tion to "through the decision process" (see paragraph 3107-9) is by means of the criteria and requirements specified for the design, development and operation of the system. Accordingly, special at.

tention should be devoted tothe system criteria development process.

1-11 l

I

2 DEVELOPMENT 3

Criteria are originated from the results of the safety analyses and from the experience gained from other programs using similar sys-tems. The process is described in Figure 3 and is repetitive in nature to the extent that the criteria are evolved, imposed, and then evaluated for effectiveness on an iterative basis. Any requirement for which several waiver requests are received should be evaluated to determine the practicality of relaxing the requirement.Otherwise, waivers should be granted on a one-time-only basis. When a waiver is granted, the information should be documented as a matter of permanent record, with the reason or the justification for granting the deviation also recorded. It cannot be emphasized too strongly that each waiver may constitute an increase in the risk being as-sumed and each deviation must be evaluated on its own merits. In any case, waivers should be kept to a minimum.

3 DOCUMENTATION All safety criteria and safety-related criteria should be recorded in document which is maintained on an up to-date basis to show one how the requirements were developed and their current state of im-plementation. Also, the waiver system should be maintained on a very formal basis with each waiver and the circumstances of its issuance fully documented.

3109 ANALYSIS 3

)

1 System safety ar.

ss are performed for the purpose of identifying hazards and establishing risk levels. Furthey examination will re-veal that in support of this concept, the analyses perform five basic functions:

Provide the foundation for the development of safety criteria and a.

requirem ent s.

b. Determine both whether and how the safety criteria and require-ments provided to engineering have been included in the design.

Determine whether the safety criteria and requirements created c.

for that design have provided adequate safety for the system.

d. Provide part of the means for meeting pre-established safety goals.

Provide a means of demonstrating that safety goals have been met.

e.

2 A very strong case can be made for the performance of safety analy-ses on any system, and all too often the decision on undertaking the effort is resolved down to a matter of economics. It is always neces-sary to be prudent in the allocationof rc::curces for any effort. From the standpoint of safety analyses, economy should be based on the selection of the appropriate analysis techniques to be used, based on l

the requirements of the system, and the need for risk visibility.

Economy should never be based on the performance of no safety

)

analyses since the absence of analyses results in very little visibility for the program manager as to the actual risk assumption status.

_j, 1-12

SYSTEM SAFETY ACTIVITIES FUNCTIONAL FLOW IDEALIZED FUNCTIONS FOR NEW PROJECTS To other programs t

Perform safety Identify energy Identify areas Reconsnend Prepare SAR analysis of sources, and the having inadequate corrective documenting components design features, control of energy action to risks being subsystems and safety devices and sources.

proper assumed with the system; procedure constraints management the r.ationale 21 the test and established to control decision for each major

-L j operations these energy sources

levels, engineering w

procedures.

during the Life cycle review and w

of the system.

Develop new or mission.

improved safety

/

criteria and requirements.

Obtain engineering Review of Safety Revice existing or management approval data and experience create new safety for release.

Participate in from other programs, requirements and design and criteria that will program reviews.

support the changing needs of the Evaluate the erfective-evolving system.

ness and adequacy of all safety requirements and criteria.

1

3110 REPORTING m

1 DEFINITION OF REQUIREMENTS The requirements fur reporting of progress, hazards and activities should be defined in :ne various safety plans and/or contracts.

2. GENERAL REPORTING General reporting covers progress of the effort, milestones attained, and significant accomplishments such as hazards identified and re-solved. This type of reporting generally flows in consonance with overall program reporting channels.

3 PROGRAM REVIEWS Safety inputs to orogram reviews relative tothe risks being assumed and the status or hazard resolution are usuallyconstrued as a type of reporting. This type of reporting is formalized around the individual program review format.

4 SAFETY ANALYSES REPORT (SAR)

The SAR, or an input to the SAR, should be prepared in su'pport of each major engineering review and prior to beginning each mission.

The requirements for the SAR are contained in paragraph 1310, and include such things as:

a. Risk levels, in 1,erms of risks being assumed.

b. Rationale for the assumption of these risks and the alternative considered, Waivers to safety criteria that have been granted.

c.

d. System safety activities that are behind schedule and have not been completed.

These SAR's serve as a total record of the risks assumed in order to complete each mission.

3111 EVALUATION 1

PURPOSE The evaluation of a system safety program is performed in order to determine that:

a. The safety management system is properly structured,

b. There is good access to both the system data and the proper management reporting level.

l c.

The safety goals are being met and the planned tasks are being i

accomplished and are on schedule.

j

d. There is an output resulting from the system safety effort,

e. Effective use is being made of safety output, j

1-14 l

2 METHOD

a. The evaluation of a safety program is begun by planning the re-view. The system safety requirements that have been imposed on the organization are determined and a copy of the organization's safety plan is obtained. In general,the most satisfactory approach is to measure the performance of the effort (what is being accom-plished) against the approved plan (what was intended to be ac-complished). Also an evaluation should be made as to whether the plan itself is current and still responsive to program needs.

b. A checklist similar to the one shown in Figure 4 is a valuable tool for recording the relative acceptability of the various parts of the program. The numbers on the left of the checklist refer to chapters in NHB 1700.l(V1). Special attention should be devoted to areas of effort receiving inadequate attention or the accom-plishment of nonproductive or redundant effort.

c.

The evaluation should include a discussion with the program manager to assess:

(1) The quality of the output from the safety effort that reaches the program manager.

(2) Whether this output arrives intime tobe useful to the program manage r.

(3) How the program manager uses this safety input.

(4) How the safety output can be improved and made more useful to the program manager.

d. Upon completionof planning,the organizationthatis to be reviewed should be notified of the forthcoming evaluation and what is to be covered in the assessment sufficiently well in advance so that proper preparations and coordination can be completed. The evaluation begins with an initial briefing to the appropriate man-agement level that introduces the review team, covers the pur-pose of the review, identifies what is to be evaluated and assures a debriefing at the conclusion of the review,

e. The review is completed according to plan and the debriefing is completed whenever possible with the same management people as participated in the entrance briefing. The purpose of this de-briefing is to come to an understanding of both the good things that were found and the areas requiring increased emphasis or improvement.

f.

The report of the evaluation is coordinated with the reviewed.

organization prior to publishing it, so that any discrepancies, misunderstandings, or inaccurcies can be resolved.

1-15

3. SCHEDULING Reviews should be completed on a regularly scheduled basis, usually once a year. More frequent evaluations should be scheduled only when the review indicates a problem of major proportions that cannot be resolved with less emphasis than the forcing function of a major review.

3112 DATA RETENTION As a result of having performed the safety activities described in 1.

this volume, extensive system safety data will have been developed, including:

a.

Criteria and requirements,

b. Safety study reports.

Other reports, progress / activity.

c.

d. Safety analysis reports.

e.

Analys e s.

f.

Hazards reports,

g. Accident reports.

2.

These items are valuable safety data that may have application to other systems that are presently being developed, or will be devel-oped in the future, and as such these data should be documented for retention as they are prepared.

3.

An up-to-date index of these data should be maintained for each program that identifies this information by report number, title, date of final issue, location, and a pertinent summary abstract so that the data are readily available for use when needed.

1 l-17

\\

CHAPTER 2: TECHNICAL METHODS 3200 INTRODUCTION The formalization of the system safety activities in the hardware /

softwa re development programs of NASA requires as a prerequisite the selection of certain technical methods that are generally accepted as the tools of that specific technology. It is recognized that only a cer-tain amount of basic data evolves as a hardware system is developed.

These are the approved engineering drawings and specifications, together with hardware test results, and it is from these basic data that all an-cillary data are created. It therefore becomes a matter of major impor-tance as to how these basic data are used and in what manner the data are processed by the various supporting disciplines to accomplish their respective missions. This chapter contains a brief description of those methods that experience has proven to be most effective for use in processing the basic engineering data and applicable ancillary data into risk evaluation information.

3201 PURPOSE AND SCOPE

1. This chapter describes in broad terms the technical system safety methods that are available to a NASA program or system safety manager for use in accomplishing a risk evaluation program. The methods have been described in sufficient detail to provide under-standing of the techniques and permit an evaluation of the analysis r e s ult s. This document does not provide detailed instructions on these methods sufficient to permit the use of this Handbook alone to perform these analyses. Hazard analysis reference publications and j

training courses are set forth in Appendixes B and C, fespectively.

1 1

2.

The methods described herein are applicable to all NASA hardware systems. The analysis methods may be expanded, reducedor altered l

as required to suit the specific needs of any separate program, or initiated during any time in the system development, thus assuring I

maximum flexibility. Furthe r, these methods are not restricted exclusively to system safety and should be considered for appli-cability to the industrial, public, and aviation safety activities.

I 3.

The reason for undertaking a program of safety analysis is to iden-tify the hazards in a system. Once identified, these hazards are e valuated, first in terms of the relative severity of the hazard, which is the effect the hazardous event would have on the system should the event occur and cause the system or an energy source to go out of control. Secondly, the hazards are evaluated in terms of the exposure of the total system or the time interval during which the hazardous event can affect the system, considering also the location of the hazard in the system. Thirdly, the hazard is evaluated in terms of the likelihood that this event will occur, and, if deter-mined quantitatively, may be expressed by means of probability calculations.

E;Q%I 2-1 YT@ V7; 8W n

n-

\\

JVjOU

4. The safety analyses are then reapplied to systematically search for the alternatives to assuming excessively high risks during the testing or operation of the system.

3202 HAZARD ANALYSES

1. The following analytical techniques are described in their logical order of application during the system development life cycle, as shown in Figure 5.

The first method is the Preliminary Hazard Analysis, which is used in the early phases of the development to identify the energy sources being considered for use in the evolving system, together with the methods selected for the control of these energy sources.

2. As the system becomes better defined and more detailed design data evolve, the Fault Hazard Analysis can be undertaken. This analysis addresses the system down to the piece-part level,if necessary, and should include such items as mechanical linkages, wiring and ducting which connect the critical system elements or components.

3. The final analysis recommended for the more complex systems is the Logic Diagram Analysis which is used to identify critical failure paths. This analysis may be made quantitative using the Fault Tree Technique should the program manager require this amount of visibility.

4. Finally, manufacturing, test and operating procedures should be re-viewed (Procedures Analysis) to assure that they are fully annotated with cautions and warning notes and that their use does not initiate any out-of-sequence events.

3203 PRELIMINARY HAZARD ANALYSIS

1. Usually the first analysis technique applied in a typical system development program is a preliminary hazard analysis based on descriptions of mission functions or events to be achieved. A pre-limina ry analysis is performed by applying data obtained on pre-vious programs from systems analogous to those defined gener-ically from the descriptions of subsystems considered for use in ac complishing mission functions. The purpose of this analysis is to identify safety critical areas and the hazards involved in the mission (s) under consideration and provide management with risk visibility during either feasibility studies or system definition activ-ities. This preliminary analysis provides a comprehensive listing of hazards commensurate with the generic system (s) defined. The com-parative data utilized from analogous systems in previous programs reflect the results of potential haz&rds identified from analyses and experience with those hardware systems, with emphasis on all as-pects of these systems and their usage.

{

2.

The preliminary hazards analysis should include:

I

a. A re view _of all pertinent safety data produced by other NASA systems to take advantage of previous safety experience.

)

J 2-2 p rM PCdlbk Nsg < u %m e

SAFETY ANALYSIS - fxOGRAM ACTIVITY RELATIONSHIP Preliminary System Definition

System Design

Manufacture, Test and Analysis Operations Feasibility Studies Generel Safety Studies Preliminary 2?

Hazard Analysis N

1 b

Fault Hazard Analysis Logic Diagram Analysis With or Without Quantification f

Procedures Analysis (Test Operations)

b. A review of all pertinent data related to the evolving system as m

a means of learning the system.

c. A listing of all energy sources such as:

(1) Electrical (2) Mechanical (3) Chemical (4) Nuclear i

d. Determining the design features or procedures that have been developed to control the energy sources listed in subparagraph c.

e. Identifying energy sources for which inadequate controls have been adopted, or high risk areas.

f. Identifying safety requirement s and criteria incorporated or needed to assure control of the energy sources and documenting them for future program application.

g.

Making recommendations to the program manager in cases where inadequate controls exist.

h. Reiterating the process as frequently as required to support major program changes.

i. The use of this information as applicable for an input into trade studier and program reviews.

3. In performing a preliminary hazard analysis, a chronological listing of functions or events provides a basis for defining generic systems.

An example listing of mission functions or events with generic sys-tems 'to perform those functions on an unmanned space vehicle is presented in Figure 6.

4.

The next step in the preliminary hazard analysis is to determine the hazards involved with each of the defined generic systems. The haz-ard determination is based on data and experience from previous programs. For brevity in this hazard analysis example, the listing of hazards for only one of the mission functions is presented. Un-l desired events and their causes for the generic systems defined from a launch-boost function are presented in Figure 7 together with identified safety features and inadequate controls as a means of determining areas needing further consideration.

3204 FAULT HAZARD ANALYSIS

1. This analysis technique is the second in the series, with increased complexity over the Preliminary Hazards Analysis. A more com-pletely defined system and greater system knowledge are required

)

j 2-4

I UNMANNED MISSION FUNCTION LISTING EXAMPLE MISSION EVENTS GENERIC SYSTEMS LAUNCH-BOOS T Guidance, Fuel, Engines, Destruct Staging, Oxidizer, Fli g h t Control, Electrical, Telemetry FAIRING SEPARATION Separation, Electrical ORBITAL INJECTION Engine Shutdown, Payload Separation, Dectrical, Guidance SOLAR PANEL DEPLOYMENT Squib, Unfolding, Electrical ATTITUDE POSITIONING Reaction Control, Electrical, Navi-gation ORBIT CORR ECTION Propulsion, C o m p u t e r, Electrical.

Navigation DATA ACQUISITION Antenna, Tele, metry, Computer, Elec-trical MID-COURSE CORRECTION Propulsion, C o m p u t e r, Navigation, Dectrical STAR ACQUISITION Navigation, Reaction Control, Com-puter, Dectrical DATA ACQUISITION AND Sensing, Data Storage, Telemetry, TRANSMISSION Dectrical Figure 6

+

l 4

2-5

i s

i EXAMPLE LISTING OF IIAZARDS FROM PRELIMINARY ANALYSIS l

MISSION GENERIC UNDESIRED IIAZARDOUS SAFE"fY INADEQUATE FUNCTION SYSTDAS EVENTS CONDITION FEATURES CONTROIS IAUNCH-BOOST ENGINES Loss of total stage Loss of one engine Destruct system No redundancy thrust - vehicle thrust, engine loss explosion FLIGilT CONTROL Loss of thrust Eydraulic actuator Redundancy No vectoring - vehicle leak or seizure, loss erroneous signal FUEL Engine shutdown -

Pressure switch fails Fuel vent valves Yes vehicle loss to actuate, fuel leak OXIDIZER Engine shutdown Lox leak None Yes

& {3 STAGING (Rocket) Ioss of staging -

Ibtor case rupture Destruct system No redundancy u

vehicle loss u

GUIDANCE Loss of flight Receiver or trans-Destruct system Yes control - vehicle mitter malfunction loss ELECTRICAL Loss of flight Open circuit, short Some redundancy Yes control, guidance -

circuit source or vehicle loss control malfunction DESTRUCT Inss of thrust -

Inadvertent actuation S & A switch Yes vehicle loss with redundancy TELBIETHY Loss of parameter Sensor malfunction None Yes i

monitoring -

mission degradation Loss of space vehicle Transmitter mal-None No status monitoring -

function loss of mission G

)

i I

for this analysis since the emphasis is oriented to the appropriate system element level, rather than toward a systems approach. The analysis provides greatly increased visibility from the standpoint of primary and secondary failures, as wdl as sequential failures, and may be performed either as an extension of the Failure Modes and Effects Analysis (FMEA) or independently from the FMEA. In the event that FMEA's have not been accomplished, a comparable set of data must be developed by the safety analyst before the Fault Hazard Analysis can be completed.

2 The data required for this analysis include up-to-date:

a. Drawings, specifications and hardware (system) descriptions.

[

b.

Mission time lines (projected).

.c.

Failure modes and effects analyses.

d.

Historical data including test results.

3.

The Fault Hazard Analysis (FHA) is used to define the effects of various subsystem component or piece-part failure modes, to evalu-ate these effects on system equipment or personnel, and to determine which subsystem effects should be further analyzed during subse-quent safety analysis. The FHA considers all these system elements in the subsystem and, therefore, all the interface effects resulting from internal failures. Analyzing at the appropriate system ele-ment level allows the identifiable hazards to be found, because, in the FHA, each hazardous event must terminateina subsystem major component.

4. The format shown in Figure 8, which is an extension of the normal FMEA, may be used in performing the Fault Hazard Analysis. The

]

following subparagraphs provide information onthe use of this format by reference to column heading:

a.

Component. Components are defined, at the discretion of the analyst, by their physical or functional significance to the subsystem or its design concept, or in accordance with NHB 5300.4(IA), Reliability Program Provisions for Space System Contracto rs. The following guide for defining the major com-ponents is included to facilitate understanding of the types of natural separations to consider. Itis notintended to be exhaustive.

(1) Electronic Logic Circuits. Many components are made up from a small 5 umber of basic circuit designs which perform an identifiable purpose. These are used as building blocks for larger circuits designed to perform the required logic func-tions to the subsystem. To minimize the analysis required, the basic circuits can be defined as major components, and an analysis made of each logic function.

(2) Mechanical Devices. Mechanical devices can be either a single part or an assembly of parts which perform one function. For a Fault Hazard Analysis, a major mechanical component can be defined as either of these. The use in the circuit will dictate 2-7

--w

,_,,4, y

m.

TYPICAL FM&EA DATA SHEET REVISED FAULT HAZARD ANALYSIS COMPONENT COMPONENI COMPONENT SYSTEM EFFECT OF FACTORS THAT UPSTREAM FUEIHER REMARKS FAILURE FAILURE OPERATIONAL PRIMARY MAY CAUSE COMPONENTS OR ANALYSIS MODE RATE MODE COMPONENT SECONDARY INPUTS THAT REQUIRED (PRIMARY)

FAILURE ON COMPONENT MAY CAUSE SUBSYSTEM FAILURE SEQUENTIAL FAILURES A

B C

D E

F G

H I

2!

Y

?:,

=

STANDARD FM&EA ANALYSIS DATA SYSTEM SAFETY FAULT HAZARD AMALYSIS DATA y,

v

).

to what level of detail mechanical parts should be considered.

Single parts which might be considered major components are:

solid drive shafts, engine blocks, primary structure, etc. The majority of mechanical devices will be assemblies of many parts and it is more reasonable to treat the assemblies as major components. For example: relays, pumps, motors, mechanical safety devices, and other similar devices. This permits the majority of vendor supplied mechanical de-vices to be analyzed as major components, thus avoiding the requirement for vendors to provide Fault Hazard Analyses of their subsystems.

(3) Electrical Systems. Major components can be basic compo-nents of a circuit or combinations of components (such as amplifiers, rectifiers, or regulators) used to perform one single function. The level of analysis should be based on the importance of the part as a functional element in the design.

(4) Chemical Systems. In systems containing chemical compounds, the chemicals sho.ld be considered as majer components if these compounds can cause failures of other components through chemical reaction or release of chemical energy.

Examples of chemical components are: fuels, pressurants, coolants, and preservatives.

(5) Safety Devices. Safety devices should always be considered major components since they are used primarily to protect against undesired events.

(6) Wiring. Interconnecting wiring of major components may be considered a major component. Internal wiring can be con-sidered as a part of a major component. Physical characteris-tics of cables which circumvent failurer between wires should be stated in the cable analysis.

b. Component Failure Mode. Failures of major components consist-ing of one part require a listing of the modes in which that part may fail. Failures of major components consisting of more than one part will require a failure mode and effects reliability analy-sis to determine how the failure modes of each part will affect the components' output. These effects will be the failure modes of the major component listed in the Fault Hazard Analysis. All fail-ure modes of the component must be listed.

c. Component Failure Rate. The predicted reliability or the failure rate computed from the best available data of primary failures should be tabulated in this column for each major component in each of its modes of failure. These data can be used in evaluating probability of the fault event or in selecting which critical or catastrophic events should be analyzed if the decisionis made not to analyze all events so classified. These data also serve as a data barx for future reference when the need arises to analyze other undesired events as a result of system changes.

2-9

d. System Operational Mode. Many major components are only recurrently activated during the system's operational life. The level of stress of these compenents will change from one system mode to another. The effect of a failure in each mode can be dif-ferent; for example, components supplied with power only during a test can create a fault hazard only while a test is performed.

Failures existing in one mode of system operations can also adversely affect the system when the mode is changed. Therefore, i

- each major component failure mode must be analyzed for possible effects on all system operational modes.

Effect of Primary Component Failure on Subsystem. The effect of e.

the component's abnormal output on the operation is listed in this 6

column. The effect will be of the immediate functional output on the most proximate downstream components. No secondary con-siderations are necessary. A description of the functional effect on normal subsystem operation will supply the required infor-mation. Some failures can initiate a normalchainof events within the subsystem. Those sequences that are inherent to the design can also be reported as a primary effect. The description cf the subsystem effect shculd be identified by its particular oriented function and also by form and magnitude of output energy. This information is necessary when using the completed Fault Hazard Analysis for construction of the Logic Diagram Analysis. Once an undesired event has been defined, all primary failure modes can be found by scanning this column.

f.

Factors That May Cause Secondary Component Failure (1) Any major component operating in a system is subject to out-of-tolerance or abnormal inputs. There may be no source of such conditions within the subsystem under analysis, but once integrated into a system, abnormalities can arise. To insure detection of the hazardous secondary conditions which can cause equipment failure, the limits beyond which failure oc-curs will be listed. This infere.ation is very significant, be-cause a failure causing an out-of-tolerance condition can affect many critical system f.tnctions rimultaneously and may degrade the system's safety.

(2) The following information, where applicable, should be included in this colunan:

(a) Effect of power reversals.

(b) Effect of high and low power.

(c) Temperature and moisture limits.

(d) Shock limits.

(e) Vibration limits.

(f) RFI limits.

2-10 1

(g) Electromagnetic limits.

(h) Transient effects.

(i) Chemical effects (including corrosion).

(j) Any other source of energy which, if supplied in sufficient quantity, will cause the primary failure rate to increase.

g.

Upstream Components or Input s that May Cause Sequential Failures. The analysis cannot be continued unless it is known how the out-of-sequence event could occur due to the power functioning of the component. It was shown ebove that a fault effect on a sub-system may be caused by a primary or secondary failure on a component. This column shows how the fault effect on the sub-system may be caused by the component as the result of having improper input signals applied. This is termed a " sequential failure" and describes the specific subsystem oriented functions and their energy level required to cause the out-of-sequence failure mode. Improper outputs of the most proximate upstream components should be listed.

h. Further Analysis Required. Having completed the analyses nec-essary to fill out the preceding columns, the analyst is prepared to make recommendations on the necessityfor additionalanalyses or corrective action. The basis for these recommendations is the result of reviewing the data developed against the risk factors of s eve rity, exposure and probability of occurrence as cited pre-viously, and a yes or no decision is reached which is entered in Column h with appropriate remarks added to Column i.

i. R ema rks (1) This column is used to include additional information needed to clarify or verify information in the other columns, or to provide a permanent note of recommended future action. A few examples of usage are given below:

(a) Describe the number and type of monitors on this major component failure mode, if known.

(b) Show the recommendations for further system analysis or corrective action as a permanent note.

(c) Explanation of a major component definition in doubtful Cases.

(d) A coding to show data source and validity of the primary failure rates.

(e) A discussion of sequential failure events is entered in Column g.

(f) When applicable, a statement that the major component is an interface compencat and requires an input from another subsystem or can provide the abnormal output in Column e.

2-11

(2) When the decision is made not to proceed into the logic dia-m gram analysis, the product of the Fault Hazard Analysis --

which is included in Columns g and h of the tabulation -- may be used as follows:

(a) To provide visibility as to the relative safety at the sub-system level.

1 (b) To establish the need for additional design requirements, safety devices, control procedures or mission constraints (red line values).

t (c) As background safety data for support of design reviews to assure that safety requirements have been met.

(d) As the basis for safety support of trade-off studies.

3205 LOGIC DIAGRAM ANALYSIS 1

GENERAL The logic diagram analys

<:hnique is the finalprogressive step in the series of safety analya

. the effort et Se undertaken in incre-ments as the major subsystem configurations are defined; however, the complete system configuration must be established before the i

total analysis can be accomplished. The analysis is flexible and pro-vides maximum visibility for the total system viewpoint by clearly showing the critical fault paths that existinthe system, which are not D

revealed by the previously described analytical techniques.

)

2. MET IOD r

A logic diagram is a graphic representation of the vs.rious; parallel and series combinations of subsystem failures which can result in a predetermined system failure. The accomplishment of a Logic Diagram Analysis is undertaken in the following series of steps:

a. Definition of the Undesired Event. Every system developed has one or more events which that system cannot tolerate, such as a catastrophic loss of a system, loss of a crew, or loss of a mission. It follows then that these are the events which must be prevented from occurring; and, in turn, preventionof these events becomes the objective of the logic diagram analysis. The initial step in the performance of a logic diagram analysis is the defi-nition of the event which must be kept from happening. While the definition of these undesired events may originate from within the functional safety organization, senior management concurrence should be obtained as a prerequisite to begin the analysis.

l

b. Obtain Data That Describes the System and Its Planned Use:

(1) Update the data obtained for the Fault Hazard Analysis to the current baseline.

(2) Develop cognizance of all significant changes to the system l

ba s eline, 3j 2-12 1

c.

Develop the Logic Diagram. Once the predetermined event has been established as described in subparagraph a above, deter-mine the necessary parallel and series events which will cause the end event to occur. This process is continued through the sub-system level to the appropriate component or piece-part level.

In cases of safety critical components, as defined in the Fault Hazard Analysis, the process is always continued to the piece-part level. These seri6s and parallel events are connected by use of the following graphic symbols:

(1) Events. The varioua kinds of events used in a logic diagram are represented by the following symbols:

Output (a) The RECTANGLE identifies an e -A that results from a combination of fault events.

Output (b) The CIRCLE identifies a ba-sic failure of a component.

I Output (c) The HOUSEindicat an event which is normal for the sys-

)

t e m.

i Output (d) The DIAMOND identifies a failure which has not been fully developed due to lack of information or significance.

(2) Lonic Ooerators. The logic op-erators required to develop the logic diagram are defined and symbolized as follows:

Output (a) The ANDGATEdescribes the logical operation which re-quires the coexistence of all inputs to cause the output.

i i

Irputa 2-13

u put (b) The PRIORITY AND GATE performs the same function as the AND GATEexcept that f

the inputs must occur in the

/

Priority sequence stipulated.

scription i

Inputs (c) The C O NS T A N T REPAIR performs the same function as the AND GATEexcept that the repair time of the output event is not dependent on the Repair

~

Times repair times of the inputs.

Inputs Output (d) The OR GATE describes the logical operation whereby the j

output is caused by the oc-currence of any of the. inputs.

n

)

Inputs Output (e') The EXCLUSIVE OR GATE performs the same function as the OR GATE except that Restriction specified inputs cannot co-

exist, n

Inputs Output (f) The CONSTANT REPAIR OR GATE performs the same I

function as the OR GATE ex-epair cept that the repair time of the output event is not de-pendent on the repair times A

of the input.

Inputs l

2-14

/

(g) The INHIBIT GATE describes Output a situation in which a certain condition of the system must exist before one failure pro-Random duces another. The inhibit condition condition may be either nor-mal to the system or be the result of equipment failures.

Input Output Functional

~

Condition Input (h) The MATRIX GATE is used Output to describe a situation in which an output event is pro-duced for certain combina-tions of events at the inputs.

A matrix showing the event combinations that produce the Input output event will accompany each usage of this symbol.

(3) Special Symbols. Special s "n-bols are used in order to staa-plify the graphic repres enta-tion of fault tree construction.

These special symbols are shown below:

Output l

I (a) The TRANSF % symbol is used to shew continuity be-tween twr, parts of the tree.

A line into the side of the triangle transfers everything

(

below to another area identi-r#

fied by the triangle with a

.)

line drawn from the apex.

Input 2-15 l

i I

(b) An ELLIPSE with a ime ex-tending out along the major Output i

7 axis is used when a compo-nent appears several times at the same place (e.g., at 10 stage counter). Only one of the inputs is drawnandthe ellipse is drawn to encompas s i

the output. This indicates i

that the failure rate of that event is to be multiplied by the given factor for an OR GATE or raised to a given power for an AND GATE.

J Input

d. Critical Fault Path Identification (1) A critical fault path is that chain of events which is the most likely to result in a particular predetermined event or poten-tial accident. There may be several chains of various degrees of dominance. These chains and their associated degrees of dominance are most clearly identified in the system safety model (logic diagram). Critical fault path (s) and their relative degree of dominance are determined either by event weighting (inspection) or mathematical solution of the model.

(2) Since the most critical fault path is the most likely avenue along which predetermined event (s) can occur, the most effec-tive approach is to concentrate the initial corrective action in this area. It may be necessary to consider other paths within

),

/:

the model, in a descending order of dominance, in order to achieve an acceptable level of risk for the occurrence of a particular predetermined event or potential accident.

j (3) The steps required to provide effective use of the identification of critical fault paths are as follows:

(a) Assure that the system safety model for a given predeter-mined event or potential accident has been developedto the i

extent necessary to identify critical fault paths. As a mini-mum the logic diagram development must encompass all these safety features and devices which have beendesigned into the system which may be extracted from the previous analyses. This assures that adequate consideration has been given to those areas of the system which contain the greatest risk. Safety features and devices are normally placed where there exists the greatest risk of an undesired event occurring.

(b) By logical inspection or mathematical process, determine the degree of dominance for those criticalfaultpaths of the model which contribute the most to the risk. Logical in-spection is the logical thought process of a trained and experienced analyst being applied through examination of the model. This process, associated with whatever mental l

weighting factors he may consider during the examination J

2-16

~

to determine which events "look to be" more probable than others, would lead to the resulting statement by the ana-lyst: "the s e events (identified) and critical fault path (s) look to be the most probable." The term " mathematical I

process" can be a solution of the model by any of several methods. Since the purpose of the quantitative evaluationof a diagram is to evaluate the critical fault paths and estab-

)

lish their relative significance, the diagramis usually sim-plified by inspection to minimize the logic diagram struc-ture to be evaluated. This inspection results in elimination of those events and branches which are obviously insig-c nificant compared to others which are inputs to the same gate.

[

(c) Evaluate the dominant critical fault paths by accompli-hing the following steps:

(i) Establish a predetermined limit within which the initial path selection is bounded. This involves the identifi-cation of those paths which are computed to be above any established limit for the system. If the paths are near or below the limit, then they are selected by pick-ing those which are within an " order of magnitude" or l

so of the limit, or are of the same type.

1 (ii) The initial selection must be divided into groups for which a set of predetermined 1imits has been established for each grouping. The grouping of paths is accom-plished by selecting those within an order of magnitude of each other or those which have an apparent com-monality within the system.

(iii) Determine whether a common point of departure exists among the paths of each group. This evaluationinvolves l

determining whether there are common faults among the paths. Recommended changes to the system at these common points provide the est effective way to elimi-nate critical fault paths, or at least reduce them to an acceptable level of risk.

(iv) Convert the logic diagram dominant critical fault paths by grouping events at logical summary points. Conver-sion of the logic diagram critical fault paths involves making a listing of those events which when "ored" result in an interim event. The method is to convert each path to a simplified alternating "and", "or", "an 1",

)

"or", etc., relationship, j

(v) Simplify the logic diagram of the dominant criticalfault l

path by logically re-diagramming.

1 (vi) Determine those events for which a design change or the development of a procedure will best and most cost-effectively reduce the probability of occurrence of an undesired event to an acceptable level of risk.

l 2-17 l

l

(vii) System safety trade-off studies may be made byinsert-

^

ing alternative solutions' as derivedby subparagraphs (i) through (vi) and repeating the process until an accept-able level of risk is obtained. This stepinvolves working with designers and selecting several alternative system changes to reduce the probability of occurrence of each path. For each alternative to be evaluated the logic i

diagram is changed to renect the change and the dia-gram is re-computed to determine the change impact.

Care r.ust be exercised to assure that other paths or branches of the diagram which have the same event or fault sequence are also changed to reflect the change being evaluated.

(viii) Advise appropriate level of management of findings and recommendations.

(ix) Diagnostic analyses also may be performed by the use of this technique. The analyst sets the accident that ac-tually happened as his undesired event and develops the diagrams as described in subparagraphs a through c above.

3206 PROCEDURES ANALYSIS 1.

GENERAL The purpose of the procedures analysis is to identify and/or imple-ment the safety requirements that should be met to assure safe test or operation of the system. The data requiredfor the performance of these analyses include:

a.

Drawingc, specifications and hardware (system) descriptions.

b. Mission time lines or test requirements.

Results of all safety analyses previously performed.

c.

d. Historical data from previously performed tests on similar systems.

2.

THE SAFETY-PROCEDURES INTERFACE The safety-procedures interface is established in three steps as follows:

a. Working with the engineering organization, establish specific safety requirements and insert them'into the test or operations requirements documentation.

b.

Review the test or operations procedures when they have been l

prepared to verify that the safety requirements included in the l

test or operations requirements documentationhave beenincluded in the procedures. Special attention should be devoted to backout and shutdown capability and to assure the procedures include end-to-end verification.

y 2-18

c. Monitor the actual test or operation to assure the adequacy of the safety impact to the procedures and to assure that the re-quirements are followed.

Test procedures include developmental, qualification, acceptance and system validation. Operating procedure includes handling, storage, transportation, maintenance, operation and emergency.

3. METHOD

a. This analysis technique involves the review of all operating pro-i cedures associated with the program. Emphasis is placed on the completeness of the procedures, including all cautions to be exer-cised regarding inadvertant out-of-sequence operations, and the inclusion in the procedures of adequate recycle and backout in-structions to counter potential emergency situations. Documenta-tion of identified hazards involved with operational and remedial procedures will provide management visibility of the risks in-volved and corrective action needed for avoiding or reducing the hazards.

b. Analyo;s consistie.g, of reviews of prepared procedures for the following nonoperational activities in a system development pro-gram should include:

(1) Manufacturing (2) Personnel Skill Certification (3) Test (4) Transportation (5) Storage (6) Pre-Operation Checkout (7) Maintenance

c. Figures 9 and 10 are typical checklists that contain hazard examples that may benefit the safety analyst in performing pro-cedures analyses.

3207 REQUIREMENTS VERIFICATION 1

The product of the analytical safety effort consists of safety visi-bility used in support of risk managenent decisions and safety re-quiremente used to influence design or procedures that test or oper-ate the system. It is necessary not only to establish the initial safety requirements and criteria, but to evaluate these requirements and criteria on an iterative basis to assure they accomplish the intent for which they were originated. Moreover, new requirements may be developed or existing requirements changed in order to maintain the i

i established safety level of the system.

2-19

TYPICAL TEST CIIECKLIST INDUSTRIAL POTENTIAL PROCEDURAL IIAZARD SAFETY POTENTIAL EFFECT INTERFACE PERSONNEL (OPERATOR) IIAZARDS Procedures in error.

Unmeasurable product integrity from deviations?

improvisions.

Procedures omissions (steps and condi-Unmeasurable product integrity from deviatiore/

tions).

improvisions.

Procedures out of sequence.

Unmeasurable product integrity from deviations /

improvisions.

Procedures warnings and cautions in-Undetectable product effects from exceeding adequate.

process limits.

Procedures permissible alternative Undocumented conditions / product integrity.

sequences.

Procedures sketches, diagrams, test Undisclosed product integrity from invalid

{

points in error, test data.

N N

3 O

e TEST EQUIPMENT HAZARDS Shutdown procedures inadequate (normal X

Unmeasurable product / test equipment degradation.

and emergr cy).

Indicating / warning devices ineffective.

Unmeasurable product / test equipnent degradation.

Maintenance / calibration reqmts/ schedule Invalid test compliance / qual. and reliability b

uncontrolled.

integrity.

Automatic corrective devices malfunction.

Unmeasurable product degradatior/ operational tg-limits exceeded.

Inadequate interlocks for sequential Unmeasurable product degradatior/ operational events.

g limits exceeded.

9 Inadequate protection for product:

N liigh voltage.

X Unmeasurable product / test equipnent degradation S

by overexposure.

Electromagnetic and radio frequence X

c=

p interference.

(M J"

X-ray, nuclear radiation.

X Heat.

X I?"

Acoustic noise, vibration, shock.

X Pressure or vacuum.

X Cryogenics.

X

()

)

TYPICAL MANUFACTURING CHECKLIST INDUSTRIAL PorENTIAL PROCEDURAL HAZARD SAFETY PorENTIAL ErTECT INTERFACE PERSONNEL (OPERATOR) HAZARDS Procedures omissions (steps and Unmeasurable product integrity from deviations /

conditions).

improvisions.

Procedures out of sequence.

Undetectable structural / operational integrity.

Procedures inadequate warnings and Unmeasurable product integrity from exceeding cautional limits.

Procedures omitted back-out or emergency X

Unmeasurable product integrity from process procedures.

inTrovisions.

MANAGBIElfr RELATED HAZARDS Use of non-certified personnel.

Invalid poduct qual. and reliability assurance.

? Insufficient supervision and inspection.

Unmeasurable product integrity / deviations and

?.

improvisions.

O h Inadequate critical incident reporting.

X Untraceable events and conditions negate cor-rective action.

MANUFACTURING EQUIPMENT HAZARDS Devices and instruments not calibrated.

Unmeasurable product effectc/ process parameters in error.

Q Special tooling / equipment not provided.

Unmeasurable product effect/ deviation and g

improvisions.

mc' '

E!WIRONMENTAL HAZARDS Inadequate environment control:

h_q Presence of corrosive gases, X

Undetectable product exposure and degradation.

gid particulate matter.

cf Temperat,ure extremes.

X Undetectable product exposure and degradation.

Eb Humidity extremes.

X Undetectable product exposure and degradation.

gg$

Excessive noise, vibration, shock X

Undetectable product exposure and degradation.

c3m levels.

L7D

2. OriE nal safety requirements and criteria stem from data extracted i

3 from experience gained on similar systems, standard system safety technology and the preliminary hazards analysis. More detailed safety analysis such as the fault hazard analysis and the logic dia-gram analysis will yield requirements that are unique to the evolving system.

3. Concurrently with the performance of these analyses, the original safety criteria should be assessed to verify that these requirements correctly continue to influence the design as it evolves. It is essen-tial, as these safety requirements are developedor refined, that they be documented and that this documentation be maintained on an up-to-date basis for design use.

9 e

o 9

l 2-22 l

i i

l APPENDlX A: INSTALLATION SUPPLEMENTAL INSTRUCTIONS AND REQUIREMENTS l

1.

In order that all regulations concerning various aspects of the NASA Safety Program (i.e., agency and installation) are maintained in one pub-lication, the volumes of the NASA Safety Manual have been designed so that installation supplements will be issued and filed with the basic regu-lations.

~

2.

Installations will is sue, as Supplements to each volume, their implement-ing instructions in a format similar to that indicated in Exhibit A of this Appendix. The installation Supplements will be issued as page inserts to those paragraphs needing implementation and will be filed as near to the implemented paragraph as possible. The implementing instructions willbe printed on col.or paper stock.

3. The Cover Sheet for each Supplement will be in a format similar to that indicated in Exhibit B and will contain the following information:

a. A list of the basic paragraphs being implemented.

b. A synopsis, if helpful, of the new implementing instructions.

c. A statement that basic paragraphs should be annotated "See Sup.

4.

In the sample formats in Exhibits A and B, the abbreviation "NHQ" desig-nates " NASA Hea dqua rt e rs."

Field installations should use individual designations (e.g., "MSC" for Manned Spacecraft Center, "FRC"for Flight Research Center). Headquarters Supplements will be printed on green paper.

5.

In no case will this vclume be reproduced or reprinted in any manner.

a-1

NHQ Sup.1.

Effective Date:

NASA HEADQUARTERS SUPPLEMENT 1 to NASA Safety Manual (NHB 1700 l(V3))

1.

NHO 3302-Za(2)(c)(i)

(Include installation supplemental procedures only) p.

-w NHQ Sup.1.

(Page Number)

EXHIBIT A--SUPPLEMENT NHOSUPPLEMENTI to NASA Safety Manual (NHB 1700.l(V3)

Issue Date:

This Supplement contains NASA Headquarters (NHQ) implementation of basic paragraphs 1302, 3401 and 3504. These paragraphs should be annotated "See NHQ Sup.1."

NHQ 3032 Requires processing of NHQ. Form 00 through Code BN.

f:?:

K w

FILING INSTRUCTIONS i

1.

(Include appropriate instructions for filing.)

f:

.:p p:

A-

__ W EXHIBIT B--COVER SHEET a-3

~

APPENDIX B: SYSTEM SAFETY REFERENCES NASA SAFETY PROGRAM SYSTEM SAFETY REQUIR EMENTS FOR MANNED DIRECTIVE NO.1 SPACE FLIGHT, OMSF, WASHINGTON, D.C.

NASA TM-X 53282 LAUNCH VEHICLE SAFETY ENGINEERING FOR STANDARD PAYLOAD MODULE, OCTOBER 20,1965, MSFC NASA TM-X 53612 THE SYSTEMS SAFETY PROGRAM FOR A TOTAL SPACE LAUNCH V EHICLE GENERAL REQUIRE-MENTS, MAY 23,1967, MSFC NASA TM-X 53305 STANDARD PAYLOAD MODULE SYSTEM ANALYSid PROCEDURES FOR SYSTEM DEFINITION, JULY 26, 1965, MSFC NASA TM-X 53664 SYSTEMS SAFETY CRITERIA FOR USE IN PREPA- '

RATION OR R EVIEW OF PROC EDUR ES, OCTO-BER 17,1967, MSFC NASA TM-X 53563 SYSTEM SAFETY HANDBOOK, JANUARY 6,1967, MSFC NASA TM-X 53388 SATURN V SYSTEM SAFETY PROGRAM ADEQUACY EVALUATION, FEBRUARY 1,1966, MSFC NHB 5300.4(1A)

RELIABILITY PROGRAM PROVISIONS FOR SPACE SYSTEM CONTBIACTORS, R&QA, CODE KR, WASH-INGTON, D.C.

SP 6506 AN INTRODUCTION TO THE ASSURANCE OF HUMAN PERFORMANCE IN SPACE SYSTEMS, R&QA, CODE KR, WASHINGTON, D.C.

DOD AFSC DH 1-1 DESIGN HANDBOOK AFSC DH 1-6 DESIGN HANDBOOK, " SYSTEM SAFETY" (Also ref-erence listed herein.)

AFSCM 127-1 SYSTEM SAFETY MANAGEMENT AMCP 385-23 MANAGEMENT SYSTEM SAFETY MIL-STD 882 SYSTEM SAFETY PROGRAM FOR SYSTEMS, AND ASSOCIATED SUBSYSTEMS AND EQUIPMENT: Gen-eral Requirernents for b-1 I

j

AFETRM 127-1 RANGE SAFETY MANUAL (VOLUME 1)

AFSCM 127-1 SAFETY, SYSTEM SAFETY MANAGEMENT, AIR FORCE SYSTEMS COMMAND SAMSOM 127-1 SAFETY, PLANS, PROGRAMS AND PROCEDURES (VolumeIV), SYSTEM SAFETY ENGINEERING, SPACE AND SYSTEMS ORGANIZATION MANUAL, USAF EXHIBIT 68-8 WEAPONS SYSTEMS SAFETY ANALYSIS REQUIRE-MENTS, SAMSO-AFSC, LOS ANGELES, CALIFORNIA, NOVEMBER 1968 SAMSO SYSTEM SAFETY ENGINEERING, HAZARD ANALYSIS R EQUIR EMENTS, SAFETY OFFICE (SMW) SAMSO-AFSC, LOS ANG ELES, CALIFORNIA, JULY 1968 (MAJOR P. J. STACK)

GOFTRACTOR D2-117018-1 APOLLO LOGIC DIAGRAM ANALYSIS GUIDELINES, THE BOEING COMPANY, SEATTLE, JUNE 1968 D2-84303-1 SYSTEMS SAFETY ENGINEERING ANALYSES TECH-NIQUES, THE BOEING COMPANY, SEATTLE, FEB-RUARY 1963

)

D2-119062-1 SYSTEM SAFETY ENGINEERING ANALYSIS HAND-BOOK, THE BO EING COMPANY, COCOA BEACH, FLORIDA, JUNE 1969 O

o 0

.J b-2

APPENDIX C: TRAINING COURSES COURSE NO. TITLE SCHOOL b ? RATION 104 System Safety George Washington Univ. 2 weeks Washington, D.C.

System Safety Analysis University of Washington 2 weeks Seattle, Washington ASM 576 Fundamentals of University of Southern 3 weeks System Safety California, Los Angeles ASM 577 Aeronautical Systems University of Southern 3 weeks Safety California, Los Angeles ASM 578 Missile and Space University of Southern 3 weeks Vehicle Systems Safety California, Los Angeles ASM 579 System Safety University of Southern 3 weeks Technology California, Los Angeles Advanced Safety University of Southern 3 weeks Program Management California, Los Angeles 4

C=1 W 88'*57 3 l