- Safety Engineering Tools

Safety engineers use a variety of tools to solve various safety problems ranging from identifying hazards inherent in a product to analyzing accidents occurring during the product use and monitoring safety performance during the product life cycle This chapter presents many of the widely used tools The chapter begins with various hazard identification and risk-reduction tools such as hazard analysis, failure modes and effects analysis (FMEA), and fault tree analysis (FTA) These tools help in reducing potential occurrences of accidents during product uses After accidents occur, they are investigated and the collected data are entered in accident databases The data in the accident databases can be sorted, tabulated, and analyzed to understand occurrence rates and causal factors of certain types of accidents The causes are further studied to determine countermeasures to reduce future accidents Cost-benefit analyses help in selecting one or more countermeasures The effectiveness of any of the countermeasures can be analyzed by maintaining control charts on occurrences of accidents and determining whether the accident rates are reduced

This chapter also presents some approaches for improving product reliability by studying the effects of series, parallel, and hybrid product configurations Additional material is also included on the reliability engineer’s role in product development and tasks in relation to the systems engineering process

A hazard can be defined as an unsafe situation that can cause injuries and losses if allowed to remain without the removal of underlying causes of its occurrence The occurrence probability of an unsafe situation can be generally estimated from historic information or by interviewing experts who have experienced or studied similar situations Hazard analysis can be defined as a systematic method used by safety engineers to study the causation of an unsafe situation by identifying its characteristics such as unsafe conditions, unsafe acts or actions committed by people, or combinations of unsafe acts and conditions and determining their probabilities of occurrence Many safety researchers such as Heinrich et al (1980), Tarrants (1980), and Brown (1976) have suggested different formats for documentation of hazard analysis with differing levels of details

Brown (1976) suggested a simple hazard analysis involving a general hazard analysis card This card can be filled out by anyone involved or familiar with a process or a situation that can involve a hazard The person filling out the card is required to provide the following information: (1) hazard description, (2) location of the hazard in the workplace, (3) severity level (nuisance, marginal, critical, or catastrophic), (4) probability of accident (unlikely, probable, considerable, or imminent), and (5) possible costs due to an accident resulting from the hazard (prohibitive, extreme, significant, or nominal) The cards are then reviewed by a safety professional who categorizes each card into the following actions: defer, need more analysis, or immediate action needed

Hazard analysis thus involves an overall look at the system under consideration to identify the safety problems that require more detailed analysis The sources of inputs for general hazard analysis include the following: (1) obvious hazards due to the nature of the process (eg, likelihood of a fire in processes involving flammable fluids and of electrocution hazards with electrical systems involving high voltages), (2) hard recordkeeping data required by law or organizational policies (eg, accident reports and injury records, violation of safety practices), and (3) other investigations that stress the cooperation of the line and staff personnel

A detailed hazard analysis generally involves breaking down a task or a process into a series of steps (or subtasks) that may contain one or more hazards A detailed hazard analysis is documented by creating a matrix The steps are listed as rows and the hazards are listed as columns of the matrix The matrix is usually created by a safety professional The cells of the matrix where a particular hazard element is present in each step are identified by entering “X” marks The safety professionals evaluate each X-marked cell to determine one or more possible countermeasures that could be applied to avoid the hazard The effect of each countermeasure on all possible hazards in all rows (steps) are rated in terms of the following: (1) Ri = the hazard can be reduced by the countermeasure to a degree indicated by the subscript i, (2) E = the hazard in the step can be eliminated, (3) I = the hazard would increase by the countermeasure, or (4) X = the hazard still exists in the step The aforementioned ratings are placed in the corresponding cells to understand the effect of each countermeasure The analysis is usually performed by applying combinations of different countermeasures to select the best set of countermeasures In addition, a cost-benefit analysis can be performed on each alternative (or countermeasure) to determine the most cost-effective alternative that produces the highest benefits-to-costs ratio The benefits can be defined as the reduction in costs due to the elimination or reduction of the accidents The costs are defined by adding all costs involved in the implementation of the countermeasures

A methods safety analysis is also a hazard analysis technique that involves breaking down a task or a process into a series of steps Application of this technique involves a safety professional to analyze each step of the process (usually by discussing each

step with the team members involved in the process) to identify possible hazards in each step and the causes of the hazards and propose improvements in the steps to eliminate the hazards The improvements are incorporated in the process, and a new improved method is developed Thereafter, the team members are trained to follow the newly developed process This technique is referred to as methods safety analysis because it is similar to the traditional methods analysis (or operations analysis) technique used by industrial engineers In methods analysis, an industrial engineer analyzes the method involved in performing a task or an operation by systematically breaking down each step (or work motion) and then improving each step by asking questions such as can the step be eliminated, combined, or made more efficient by reducing unnecessary motions In methods safety analysis, the emphasis is on improving safety Thus, methods safety analysis is primarily concerned with investigating hazards involved in the methods of an operation The fundamentals of methods safety analysis are the same as those of methods analysis The steps in methods safety analysis are as follows: (1) breaking down the job or operation into its elemental tasks, (1) listing them in proper order, (3) examining them critically to find opportunities to eliminate the hazards, and (4) developing a new safer and more efficient method

The advantages of methods safety analysis are as follows:

1 It maps out all the details of an operation so that they can be studied and restudied

2 It is quick, simple, factual, and objective 3 It permits the comparison of current and proposed methods 4 It presents a picture of the effect on production by the safety improvements 5 It aids management in reviewing the benefits 6 It permits the engineer to improve productivity 7 It facilitates analysis of the safety potential of an operation before an acci-

dent occurs, that is, it is proactive 8 It assists in thorough investigations of methods or operations involved in the

accident where the causes are obscured

Determining causes for hazards and developing countermeasures require specialized safety professionals with experience and knowledge in hazard recognition and accident causation theories (see Chapter 11) The hazard recognition abilities can be enhanced by the creation of hazards checklists For example, Hammer (1980) provided a comprehensive set of checklists to analyze product designs Hammer’s checklists included the following categories of hazards: (1) acceleration (eg, does the product contain any spring-loaded or cantilevered object or device that could be affected by acceleration or deceleration?), (2) chemical reaction (eg, is there any material present that will react with the oxygen in the air to produce a toxic, corrosive, or flammable material or one that will ignite spontaneously?), (3) electrical shock (eg, are the voltages and amperages high enough to cause arcing or sparking, which can ignite a flammable gas or combustible material?), (4) explosives and explosions, (5) flammability and fires, (6) heat and temperatures, (7) mechanical items (eg, sharp points and edges), (8) pressure

(eg, high-pressure lines and vessels), (9) radiation, (10) toxic materials, (11) vibration and noise, and (12) other miscellaneous hazards Product designers should construct specialized checklists containing issues related to hazards inherent in their product and use the checklists to identify all possible hazards

Risk analysis is a methodology used to compute the level of risk in a given product, process, or situation The level of risk is generally expressed in terms of a risk priority number called the RPN The computation of an RPN is similar to the approach used in FMEA (see the following section and Chapter 13), which consists of the multiplication of three rating values, namely, severity rating (S), occurrence rating (O), and hazard detection rating (D) Thus, RPN = S × O × D Many models of RPN with differing scales are used in the industry and also by government agencies for risk analysis

Figure 161 presents an example of a nomograph (also called nomogram) used to illustrate risk assessment Three situations S1, S2, and S3 are shown by joining points on the three scales through a tie line between the first two scales The first situation S1 involves a situation with moderate potential for injury, highly probable hazard occurrence, and improbable hazard recognition resulting in extremely high risk The second situation S2 involves minor potential for injury, probable hazard occurrence, and highly improbable hazard recognition resulting in remote to virtually nonexistent risk The third situation S3 involves minor potential of injury, highly probable hazard occurrence, and improbable hazard recognition resulting in extremely low risk

The problems with the RPN computation methodology are as follows: (1) the selection of values of the ratings is based on subjective judgments of the analyst, (2) lack of objective data to determine values of the ratings, and (3) assumptions are made about consumer or user behavior Thus, RPN-based risk analysis models are not precise But they can be used as guides along with other sources of information such as recommendations from multiple experts and discussions between decision makers and experts

FMEA is a commonly recognized tool in the industry Its applications to study a process (P for process) or a product design (D for design) are commonly referred to as PFEMA and DFEMA, respectively FMEA is a proactive and qualitative tool used by quality, safety, and product/process engineers to improve the reliability of products or processes (by reducing or eliminating failures, thus improving quality, ie, customer satisfaction) It seeks to identify (1) possible failure modes and mechanisms, (2) the effects or consequences that the failures may have on performance of the product or process, (3) methods of detecting the identified failure modes, and (4) possible means for prevention It is very effective when performed early in product/process development and by experienced multifunctional teams

FMEA encourages the systematic evaluation of a product or process at the specified levels of system complexity (defined by RPN) It postulates single-point failures,

identification of possible failure mechanisms, examination of associated effects, likelihood of occurrence, and preventive measures It also creates systematic documentation (in a tabular format) of potential product or process nonperformance The FMEA technique is described in detail in Chapter 13 An example of FMEA is provided in Chapter 13, Table 137

Products designed using DFEMA principles should have higher quality and reliability than those developed using traditional design methods (eg, design reviews) DFEMA also ensures that the transition from the design phase to the production phase is as smooth and rapid as possible

Purpose The purpose of a fault tree is to fully describe the occurrence of an event placed on top of the fault tree diagram The event is called the “head event” Another purpose of the fault tree is to determine the probability of occurrence of the head event

Description In a fault tree, all possible combinations of events that can cause the head event to occur are described as branches underneath the head event The relationships between all events can be described in terms of a series of Boolean algebraic equations The equations can be used to analyze occurrences of any of the events in the tree The Boolean expressions can be used to determine the probability of occurrence of any of the events by using the probabilities of terminating events under each of the branches

Fault tree is a logical tree diagram showing how an event shown at the top of the tree (head event) can occur It describes all possible events that can lead to the occurrence of the head event A fault tree has only one head event It is generally an “undesired” event Various events that can lead to an event are shown by using logical operators called “gates” “AND” and “OR” gates (and other gates) are used to show how an event described on the top of the gate can occur due to the occurrences of events shown below the gate

Application of Boolean Algebra Boolean algebra can be used to provide the logical description of a fault tree and its branches

It can also help in performing computational analyses for large, complex fault trees using computers A given Boolean expression defining the same head (output) event can be rewritten in various equivalent expressions for (1) restricting the tree, (2) equation simplifications of the tree, and (3) determination of mutually exclusive branches or events The probability of a head event can be computed from its Boolean expression defining the event The fault trees of product failures can also be constructed in configurations involving different product design alternatives or countermeasures, and comparisons of quantitative evaluations of the alternative configurations of fault trees can be made to reduce the occurrences of undesired events and to determine the effectiveness of the countermeasures The basics of Boolean algebra are described below

Let us assume that X, Y, Z, A, B, C, D, … are Boolean algebra variables (ie, logical variables) Each Boolean variable defines an event Variable X can be defined to convey that the event X exists, that is, X is true Then X (ie, X bar) denotes that the event X does not exist or X is not true, that is, X is false

The primary logical operators are as follows: (1) + (plus), which denotes OR gate situation, and (2) · (dot), which denotes AND gate situation

Therefore, Boolean equations can be written as follows:

X X X+ =

X X+ = 1

X X X⋅ =

X X 0⋅ =

where 0 = null (no event exists) and 1 = all events coexist (ie, the universe) Figure 162 illustrates AND, OR, and inhibit gates All the events above, below,

and within the gates are defined by Boolean variables Figure 162 thus illustrates the following:

1 The AND gate illustrates that A = B1 · B2 · B3· … · Bn 2 The OR gate illustrates that C = D1 + D2 + D3+ … + Dm 3 The inhibit gate illustrates that X = W · Y

The events denoted by Boolean variables are shown in the fault tree diagram by using different shaped boxes The notations used for different types of events are shown in Figure 163 The description of each event is written inside the box in words or in terms of its Boolean variable (such as G, F, E, and H in Figure 163) The output of any event box is on the top side, and the input is on the bottom side

AND Gate Assume that events A and B are required to be present simultaneously to generate event X Then, the Boolean (logical) expression can be written as follows: X = A · B

The probability of X = P(X) can be defined as follows:

P(X) = P(A) ⋅ P(B|A) (if A and B are not independent events) = P(B) ⋅ P(A|B)

Otherwise, P(X) = P(A) ⋅ P(B) (if A and B are independent events)

OR Gate Assume that an event A or B is required to generate the event Y Then, the Boolean (logical) expression can be written as follows: Y = A + B

The probability of Y = P(Y) can be defined as follows:

P(Y) = P(A) + P(B) − P(AB) (if A and B are not mutually exclusive events)

P Y P A P B( ) ( ) ( )= − ⋅1

Otherwise, P(Y) = P(A) + P(B) (if A and B are mutually exclusive events)

If P(AB) = 0, events A and B cannot coexist Thus, A and B are mutually exclusive Therefore, P(A + B) = P(A) + P(B) This mutually exclusive reasoning can be applied and generalized for any n mutually exclusive events (A1 to An), and the probability of occurrence of any one or more of the events (A1 to An) can be written as follows:

P A A A A P An

+ + + + = =

∑…

The examples in the following subsections will help illustrate the independent and mutually exclusive events

An Example: Two-Engine Aircraft Let us assume that a twin-engine airplane has two identical engines The probability that an engine will work in the flight is 099 Compute the probabilities that at least one engine will work in the flight and that both the engines will work in the flight Assume that the two engines are independent (ie, operation of one engine does not affect the other engine)

The first part of the problem can be solved by considering an OR gate where at least engine A or B will work The second problem is solved by considering an AND gate (see Figure 164)

Fault Tree Development Rules Brown (1976) has provided three rules for fault tree development (discussed in the following subsections) These rules allow the systematic development of a fault tree by using OR gates first (at the top and every subsequent event) and organizing conditional events to reduce errors in computations of the probabilities

Rule 1: Fault Tree Development Rule For any event that requires further development, analyze all possible OR input events first prior to the analysis for AND inputs This will hold for the head event or any subsequent event that needs further development

This rule is based on data collection completeness (think about all reasons for an occurrence of each event first) and probability considerations leading to an event An OR gate should be used just below the head event

Rule 2: OR-Gate Event Rules The input events to an OR gate must be defined such that together they constitute all possible ways that the output event can occur In addition, each event must include the occurrence of the output event

This rule is based on the inclusion of all possible causes for completeness Otherwise, the probability estimate will be underestimated All events placed under an OR gate must collectively exhaust all possible events leading to the event above the OR gate Thus, use an event (in a diamond-shaped box; Figure 163, second event from top) to include events occurring due to “all other” reasons (allows for future inclusions or expansions) (An example of this situation is shown in Figure 165;

see event G) If all the events leading to an OR gate are mutually exclusive (ie, the events do not overlap), then their probabilities can be simply added

Rule 3: AND-Gate Event Rule The input events to an AND gate must be defined such that the second event is conditioned on the first, the third event is conditioned on the first and the second, and

so on, and the last is conditioned on all others In addition, at least one of the events must include the occurrence of the output event

This rule is based on the reduction of uncertainty related to the independence of events under the AND gate and on accuracy in quantitative analysis

Fault Tree Example: Printer Fails to Print Figure 165 illustrates a fault tree drawn for the following head event: printer fails to print a report The head event is labeled as A The head event can occur due to any of the events B, C, D, E, F, and G shown below the OR gate under the head event (see rule 1) Note that event G is defined to satisfy rule 2

Thus, using Boolean algebra, A can be defined as follows:

A B C D E F G= + + + + +

Similarly, other events can be defined as follows:

B H I J= + +

C L K= +

D M N= +

E P Q R= + +

The probability of occurrence of the head event can be computed by using the following equations:

P A P B P C P D P E P F P G

P B

( ) [ ( ) ( ) ( ) ( ) ( ) ( )]

(

= − ⋅ ⋅ ⋅ ⋅ ⋅1 0

) [ ( ) ( ) ( )]

( ) [ ( ) ( )]

= − ⋅ ⋅

= − ⋅

1 0

1 0

P H P I P J

P C P L P K

P D P M P N

P E P P P Q P

( ) [ ( ) ( )]

( ) [ ( ) ( ) (

= − ⋅

= − ⋅ ⋅

1 0

1 0 R)]

The probability of the head event can be computed by using the probabilities of the ending events H, I, J, K, L, M, N, P, Q, R and G. It is assumed that the numeric values of the probabilities of each of the ending events are given (from estimates of experts or assumptions)

Advantages of Fault Tree Analysis The advantages of using FTA are as follows: (1) it allows better understanding of the system through causal relationships of events, (2) it helps in communicating issues among design team members, (3) it provides quantitative estimates for better decision making, and (4) it points out critical paths (branches in the fault tree with high probabilities of undesired events) and improvements in branches (or events in the branches) that can reduce the probability of occurrence of the undesired event

The purpose of accident data collection is to get all the relevant facts about one or more accidents such as how, when, and what happened, and who caused it to understand the factors and causes associated with the accidents The ultimate goal is to reduce such accidents by developing accident prevention programs and to monitor the effectiveness of implemented countermeasures for evaluating the state of safety The collected accident data can also be compared with the accident data from past time intervals and the accident data available from other organizations or situations

Accident data originate from the accident reports that are generally prepared by the supervisor, the police officer, the medical staff, or the persons involved in the accident The accident reports are collected and entered into summary sheets and databases by data entry personnel A completed accident report form contains information such as date and time of the accident, persons involved, location of the accident, description of injuries, equipment involved, description of the loss, the situation and the environment present at the time of the accident, accounts of how the accident occurred, diagram/map with the locations of various objects, and movements of the equipment/vehicles Some accidents are investigated at a greater detail by accident investigators or multidisciplinary teams (involving researchers, engineers, medical personnel, lawyers, and other experts) and the data are entered into databases Their report is called the “accident-analysis report”

Accident researchers and statisticians analyze the data by sorting, summarizing in tabular and other formats (eg, pie charts and tree diagrams), and conducting statistical analyses to determine significant effects or differences due to certain variables For example, the accidents can be sorted by conditions (eg, day vs night), situations (eg, normal vs emergency), before versus after the implementation of countermeasures, equipment used (eg make, model, and brand of equipment involved in the accidents), operator characteristics (eg, young vs old), and so on

All accidents have some type of reporting threshold, that is, when an accident report must be filed The thresholds are typically based on the level of severity of the injury or property damage over a certain amount Unfortunately, the thresholds vary between different organizations For example, police-recordable accidents are defined based on the occurrence of a personal injury or property damage over $100-$200 The workplace-recordable accidents defined by the Occupational Safety and Health Administration are more severe than just first-aid injuries and involve loss of time or a doctor’s judgment Thus, what is reported can vary based on the accident location and the judgment of the person treating the injured or filing the report

The primary reason for investigating an accident is not to identify a scapegoat but to determine causes of the accident by gathering factual information about the details that led to the accident

Generally, an accident report (supervisor or police reported) does not answer the why question (It answers who, what, where, and when related to the accident) Thus, the purpose of accident investigation is to understand why the accident occurred and how it occurred so that future accidents of this type can be prevented

Ideally, accidents should be investigated as soon as all emergency procedures have been accomplished The accidents can be investigated by the supervisor, an investigative team, or an outside specialist to collect facts that led to causation of the accident During the investigation, the accident scene is isolated to maintain the conditions that existed at the time of the accident and all the evidences (eg, photographs and/or video of the accident scene and interviews of witnesses) are gathered Later, simulations may be created to understand and determine the series of events in the accident and, finally, a report is prepared

Accident reports can be categorized by their sources Typical sources of accident reports are as follows: private organizations (eg, companies, manufacturers, service providers, insurance companies, and health-care providers), public institutions (eg, universities), law enforcement organizations (eg, police in city, county, or state), state accident databases, and databases created by federal agencies

The US Consumer Products Safety Commission (CPSC) maintains a nationallevel accident database called the National Electronic Injury Surveillance System (NEISS) It represents a national probability sample of hospitals in the United States and its territories Patient information is collected from each NEISS hospital for every emergency visit involving an injury associated with consumer products (CPSC, 2012) The National Highway Traffic Safety Administration (NHTSA) (US Department of Transportation) created the Fatality Analysis Reporting System (FARS) in 1975 (NHTSA, 2012) This accident data system was conceived, designed, and developed by the National Center for Statistics and Analysis to assist the traffic safety community in identifying traffic safety problems and evaluating both motor vehicle safety standards and highway safety initiatives

Accident data files store data on a number of parameters obtained from the accident reports and the accident investigations Typically, the parameters include the following: accident case number, location of the accident (eg city, county, or state), date and time of the accident, characteristics of each injured person (eg, age, gender, driver’s license number, and address), nature of injury (eg, severity level and body parts injured), details of equipment involved in the accident (eg, vehicles, model number, manufacturer, and vehicle identification number), safety equipment used

(eg seat belts, hard hats, and guards), narrative of how the accident occurred, nature of property damage, and so forth

The primary purposes of accident data analyses are as follows: (1) to estimate the magnitude of the accident problem, frequencies, and rates by accident types or categories and (2) to understand causes to develop prevention countermeasures to reduce accidents The accident data are used by many decision makers such as company management personnel (eg, to determine state of safety in their products, operations, costs, and countermeasures), government officials (eg, for standards development, recalls, and public notices), safety researchers (eg, to analyze, evaluate, and propose countermeasures), lawyers and legal professionals (eg, to establish evidence, link accidents to design, or manufacturing defects of products, errors, and negligence), and insurance company researchers (eg, to determine incident rates, severity, costs, and insurance premiums)

In many situations requiring the measurement of safety performance, nonaccident events (eg, unsafe acts, unsafe conditions, and near accidents) can be measured instead of waiting for accidents to occur Critical incident technique (CIT) and behavioral sampling are two commonly used techniques in the non-accidentbased safety performance measurement area CIT involves interviewing a preselected group of individuals to recall details about predefined critical incidents (eg, potential or actual accidents) Behavioral sampling involves the traditional “occurrence sampling” or “work sampling” application by observing and recording unsafe acts and unsafe conditions in a workplace The collected information is used to monitor safety performance

CIT is a method of identifying errors and unsafe conditions that contribute to both potential and actual injurious accidents within a given population by means of a stratified random sample of participant-observer selected within the population Quantitative information (eg, frequencies and proportion of unsafe behaviors) obtained from the questions asked during the interviews can be used to measure safety performance (Tarrants, 1980)

One of the oldest and famous applications of CIT was by Fitts and Jones (1961a,b) to study pilot errors to help design better aircraft controls and displays Soon after World War II, the air force launched a systematic study of errors made by pilots in situations where accidents and near accidents occurred The pilots were asked to recall incidents in which they almost lost an airplane or witnessed a copilot make an error in reading aircraft displays or operating controls From the analyses of the data gathered from these critical incidents, Fitts and Jones found that practically all the

pilots, regardless of experience or skill, reported making errors in using cockpit controls and instruments They also concluded that it should be possible to eliminate or reduce most of these pilot errors by designing equipment in accordance with human requirements Similarly, driver errors in using displays and controls can be reduced if they are designed in accordance with the human engineering criteria

The steps involved in conducting CIT are as follows:

1 Define the objectives of the study, for example, to solve a safety problem by identifying causes of certain type of accidents and/or measuring the level of safety (frequency or rates of unsafe occurrences) in a given situation

2 Determine sample characteristics of participant-observer (their locations, representation)

3 Develop questions to ask and obtain (1) descriptions of situations related to the errors or unsafe conditions, (2) descriptions of the errors and unsafe conditions, (3) wordings of probe questions to assist in recalling incidents related to each particular type of error and unsafe condition

4 Carefully select a representative sample of participant-observer based on valid stratification criteria (eg, stratification by shift, locations of product uses)

5 Conduct preliminary interviews (to facilitate recall) with each participantobserver (about 24 hours before the data collection interview) to inform them about the purpose of the study, explain the type of information desired, and explain the procedure

6 Conduct interview with each participant-respondent separately for about 45 minutes Record the interview for subsequent data retrieval

7 Replay the audio recording and extract details of each incident (when, where, how it occurred, who, and possible cause), classify the mentioned unsafe acts and conditions, and keep records on their counts (frequency) and data

8 Prepare a table of frequencies of unsafe acts and conditions 9 Conduct statistical analyses: (1) to determine the distribution of unsafe acts

and conditions (eg, by types, occurrence time and locations), (2) to compare with past data, and (3) to maintain control charts of frequency (C or U charts) and rates or proportion of unsafe acts

10 Document and present conclusions to management

During interviews (in step 6), the interviewer first starts with open-ended questions Some examples of open-ended questions are as follows: (1) would you describe as fully as you can the last time you saw an unsafe human error or unsafe condition in your department and (2) would you please describe as fully as you can other unsafe human errors or conditions in your department during the past 2 years? Next, the interviewer probes systematically for other incidents that they may have forgotten Examples of questions used here are as follows: (1) Have you ever seen anyone cleaning a machine or removing a part while the machine was in motion? (2) Have you ever seen anyone speeding or any other improper handling of a power truck? (3) Have you ever seen anyone “beating” or “cheating” a machine guard?