semi合集-English.pdf - 第6823页

SEMI S2-0703a E © SEMI 1991, 2004 52  Identificat ion of subsy stem, component, soft ware safety activities as well as integrated system level activities (i.e., design analyses, tests, an d demonstrations) applicable to…

SEMI S2-0703a

and other sources of design guidance for applicability to

the design of the system. The supplier should establish

EPS design criteria derived from applicable data

including the preliminary hazard analyses. These

criteria should be the basis for developing system

specification EPS requirements. The supplier should

continue to expand the criteria and requirements for

inclusion in development specification during the

subsequent program phases.

R1-5 Detailed Guidelines

R1-5.1 The purpose of the EPS program is to ensure

that the equipment or product is designed and

documented in a manner that reduces the safety risk

associated with that equipment or product to a level that

is acceptable to the customer. This consideration

applies to all life cycle phases of the equipment or

product. The following sections include detailed

elements of a formal EPS program. Management should

select or tailor the elements appropriate to their needs.

R1-5.2 EPS Program Plan (EPSPP) — The purpose of

a EPS Program Plan (EPSPP) is to describe the tasks

and activities of EPS management and engineering

required to identify, evaluate, and eliminate/control

hazards, or reduce the associated risk to an acceptable

level throughout the system life cycle. The plan

provides a basis of understanding of how to organize

and execute an effective EPS program.

R1-5.2.1 EPS Program Scope and Objectives — Each

EPSPP should describe, as a minimum, the following

four elements of an effective EPS program:

 a planned approach for task accomplishment,

 qualified people to accomplish tasks,

 authority to implement tasks through all levels of

management, and

 appropriate commitment of resources (both staffing

and funding) to assure tasks are completed.

 The scope and objectives should:

 Describe the scope of the overall program and the

related EPS program.

 Identify the tasks and activities of EPS

management and engineering functions. Describe

the interrelationships between EPS and other

functional elements of the program. Identify the

other program requirements and tasks applicable to

EPS.

 Account for major required EPS tasks and

responsibilities.

R1-5.2.2 EPS Function — The EPSPP should

describe:

R1-5.2.2.1 The EPS function within the organization of

the total program, including organizational and

functional relationships, and lines of communication.

Other functional elements that are responsible for tasks

that impact the EPS program should be included. This

description should include the integration/management

of associate suppliers, subcontractors and engineering

firms. Review and approval authority of applicable

tasks by EPS should be described.

R1-5.2.2.2 The responsibility and authority of EPS

personnel, other supplier organizational elements

involved in the EPS effort, subcontractors, and EPS

groups. Identify the organizational unit responsible for

executing each task and the authority in regard to

resolution of identified hazards.

R1-5.2.2.2.1

One highly effective organizational

approach to hazard resolution authority is through the

use of a EPS Working Group (EPSWG). The activities

of the EPSWG could include:

 Identifying safety deficiencies of the program and

providing recommendations for corrective actions

or prevention of reoccurrence.

 Reviewing and evaluating the hazard analyses to

develop agreement that the hazards have been

properly identified and controlled.

 Provide recommendations to the proper level of

management concerning the need for additional

hazard controls and the acceptability of residual

risks.

 The staffing of the EPS function.

 The procedures by which the supplier will integrate

and coordinate the EPS efforts.

 The process through which supplier management

decisions will be made.

 Details of how resolution and action relative to

EPS will be effected at the program management

level possessing resolution and acceptance

authority.

R1-5.2.3 EPS Program Milestones — The EPSPP

should include:

 Identification of the major EPS program

milestones. These should be related to major

program milestones, program element

responsibility, and required inputs and outputs.

 A program schedule of EPS tasks, including start

and completion dates, reports, and reviews.

SEMI S2-0703a

 Identification of subsystem, component, software

safety activities as well as integrated system level

activities (i.e., design analyses, tests, and

demonstrations) applicable to the EPS program but

specified in other engineering studies and

development efforts to preclude duplication.

R1-5.2.4 General EPS Guidelines and Criteria — The

EPSPP should:

 Describe general engineering requirements and

design criteria for safety.

 Describe the risk assessment procedures (see SEMI

S10). The hazard severity categories, hazard

likelihood categories, and the EPS precedence that

should be followed to satisfy the safety

requirements of the program.

 Describe closed-loop procedures for taking action

to resolve identified unacceptable risks including

those involving non-developmental items.

R1-5.2.5 Hazard Analysis — The EPSPP should

describe:

 The analysis techniques and formats to be used to

identify hazards, their causes and effects, hazard

elimination, or risk reduction requirements and

how those requirements are met.

 Recommended techniques for identification of

hazards and hazard scenarios include Preliminary

Hazard Lists, Preliminary Hazard Analysis,

HAZOPs, FMEA, FTA, “what if?” and process

control analyses. Other types of hazard analysis

techniques are discussed in a variety of sources,

such as EN 1050, Annex B. No single method is

the best for all types of systems, subsystems,

subsystem interaction or facilities. A combination

of techniques may be most appropriate.

 The integration of subcontractor or supplier hazard

analyses and safety data with overall system hazard

analyses.

 Efforts to identify and control hazards associated

with materials used during the system’s life cycle.

R1-5.2.6 System Safety Data — The EPSPP should

describe the approach for collecting and processing

pertinent historical hazard, incident, and safety lessons

learned, data.

R1-5.2.7 Safety Verification — The EPSPP should

describe:

 The verification (test, analysis, inspection, etc.)

methods to be used for making sure that safety is

adequately demonstrated. Identify any

requirements for safety certification, safety devices

or other special safety verification or

documentation requirements.

 Procedures for transmitting safety-related

verification information to the customer or others

for review and analysis.

R1-5.2.8 Audit Program — The EPSPP should

describe the techniques and procedures to be employed

to make sure the objectives and requirements of the

EPS program are being accomplished.

R1-5.2.9 Incident Reporting — The supplier should

describe in the EPSPP the incident alerting/notification,

investigation and reporting process including

notification of the customer.

R1-5.2.10 EPS Interfaces — The EPSPP should

identify:



The interface between EPS and all other applicable

safety disciplines.

 The interface between EPS, systems engineering,

and all other support disciplines such as:

maintainability, quality control, reliability,

software development, human factors engineering,

and others as appropriate.

 The interface between EPS and product design,

integration and test disciplines.

R1-5.3 Hazard Analysis Documentation

The hazard analysis process is used to identify hazards

and their controls. This information should be

documented in a closed loop tracking system to track

the implementation of the controls and may also be

required for presentation to management, the customer

and others. The safety documentation could include a

system description, the identification of hazards and

their residual risks, as well as special procedures and

precautions necessary for safety.

The documentation should include the following:

R1-5.3.1 System Description — This should consist of

summary descriptions of the physical and functional

characteristics of the system and its components.

Reference to more detailed system and component

descriptions, including specifications and detailed

review documentation should be supplied when such

documentation is available. The capabilities, limitations

and interdependence of these components should be

expressed in terms relevant to safety. The system and

components should be addressed in relation to its

function and its operational environment. System block

diagrams or functional flow diagrams may be used to

clarify system descriptions. Software and its role(s)

should be included in this description.

SEMI S2-0703a

R1-5.3.2 Data — This should consist of summaries of

data used to determine the safety aspects of design

features.

R1-5.3.3 Hazard Analysis Results — This should

consist of a summary or a total listing of the results of

the hazard analysis. Contents and formats may vary

according to the individual requirements of the

program. The following data elements may be used for

documenting the results of hazard analyses:

R1-5.3.3.1 System/Subsystem/Unit — The particular

part of the system that is the concern in this part of the

analysis. This is generally a description of the location

of the component being considered.

R1-5.3.3.2 Component/Phase — The particular

phase/component with which the analysis is concerned.

This could be a system, subsystem, component,

software, operating/maintenance procedure or

environmental condition.

R1-5.3.3.3 Hazard Scenario Description — A

description of the potential/actual hazards inherent in

the item being analyzed, or resulting from normal

actions or equipment failure, or handling of hazardous

materials.

R1-5.3.3.4 Effect of Hazard — The detrimental effects

that could be inflicted on the subsystem, system, other

equipment, facilities or personnel, resulting from this

hazard. Possible upstream and downstream effects can

also be described.

R1-5.3.3.5 Recommended Action(s) — The

recommended action(s) that are necessary and sufficient

to eliminate or control the hazard. Sufficient technical

detail is required in order to permit the design engineers

and the customer to adequately develop and assess

design criteria resulting from the analysis. Include

alternative designs and life cycle cost impact where

appropriate.

R1-5.3.3.6 Risk Assessment — A risk assessment for

each hazard (classification of severity and likelihood).

This may include an assessment of the risk prior to

taking any action(s) to eliminate or control the hazard

and a separate assessment of the risk following

implementation of the Recommended Action(s). (See

SEMI S10.)

R1-5.3.3.7 Remarks — Any information relating to the

hazard not covered in other blocks; for example,

applicable documents, previous failure data on similar

systems, or administrative directions.

R1-5.3.3.8 Status — The status of actions to

implement the recommended control, or other, hazard

controls. The status should include not only an

indication of “open” or “closed,” but also reference to

the drawing(s), specification(s), procedure(s), etc., that

support closure of the particular hazard. The person(s)

or organization(s) responsible for implementation of the

control should also be recorded.