A systemic approach to process

download A systemic approach to process

of 13

  • date post

    02-Jun-2018
  • Category

    Documents

  • view

    212
  • download

    0

Embed Size (px)

Transcript of A systemic approach to process

  • 8/10/2019 A systemic approach to process safety.pdf

    1/13

  • 8/10/2019 A systemic approach to process safety.pdf

    2/13

    inspired view and approach for the engineering of safe proc-esses, which is detailed in the section A Control-InspiredEngineering Approach to Process Safety.

    It is the authors expectation/hope that academics and

    industrial practitioners of process systems engineering (PSE)will nd the system-theoretic, control-inspired view andapproach to process safety, proposed in this Perspective, anatural setting for thinking of process safety in new andmore effective ways. It is also the authors conviction thatthe proposed framework may offer an attractive venue for the deployment of numerous methodologies and techniquesthat have been signicantly advanced in other areas of PSE(Stephanopoulos and Reklaitis, 2011), such as computer-aided modeling and simulation of large and complex proc-esses, model-predictive multivariable control and optimiza-tion, large-scale monitoring and diagnosis, planning andscheduling of process operations, all of which would have amaterial effect in advancing the state-of-the-art in process

    safety.

    The Prevailing Premise: Accident CausationModels and Their Shortcomings

    In process safety the prevailing assumption is: Accidents are caused by chains of directly related failureevents .

    This assumption implies that working backward from theloss event and identifying directly related predecessor events(usually failures of process components, or human errors)will identify the root cause for the loss. Using this infor-mation, either the root cause event is eliminated or anattempt is made to stop the propagation of events by addingbarriers between events, by preventing individual failureevents in the chain, or by redesigning the system so thatmultiple failures are required before propagation can occur (putting and gates into the event chain). Figure 1 shows atypical chain-of-events model for a tank rupture. The eventsare annotated in the gure with standard engineering xesto eliminate the event.

    Accident causation models constitute the foundationalpiece on which many of the process safety methodologiesand engineering tools, such as event-trees, fault-trees analy-sis (Lapp and Powers, 1977; Erickson, 2011), Hazard andOperability Analysis (HAZOP) (Kletz, 1999; Venkatasubra-

    manian et al., 2000), risk analysis (AIChE/CCPS, 2009),have been constructed and deployed. However, this modelhas several serious drawbacks, such as the following:

    Oversimplies Causality and the Accident Process.Whether in the process design mode (i.e., when safety con-siderations are taken into account for the design of a safer process), or the postmortem accident analysis mode, theapplication of the chain-of-events model is based on theclassical assumption that cause and effect must be directlyrelated. Consequently, these models are limited in that theyare unable to go beyond the designers or investigators col-lective current knowledge, i.e., they cannot nd causes thatthey do not already know.

    Furthermore, most current accident models and accidentanalysis techniques suffer from the limitation of consideringonly the events underlying an accident and not the entireaccident process . Accidents are often viewed as some unfor-tunate coincidence of factors that come together at one par-ticular point in time and lead to the loss. This belief arisesfrom too narrow a view of the causal time line. However,processing systems are not static. Rather than accidentsbeing a chance occurrence of multiple independent events,they tend to involve a migration to a state of increasing risk over time . A point is reached where an accident is inevitable(unless the high risk is detected and reduced) and the partic-ular events involved are somewhat irrelevant: if those eventshad not occurred, something else would have led to the loss.This concept is reected in the common observation that aloss was an accident waiting to happen .

    Understanding and preventing or detecting system migra-tion to states of higher risk requires that our accident models

    consider the processes involved in accidents and not simplythe events and conditions: Processes control a sequence of events and describe system and human behavior as itchanges and adapts over time (perhaps as a result of feed-back or a changing environment), rather than individualevents and human actions.

    Excludes Many of the Systemic Factors in Accidents and Indirect or Nonlinear Interactions Among Events. Accidentcausation models oversimplify the causality because theyexclude systemic factors, which have only an indirect rela-tionship to the events and conditions in the chain of events.A few attempts have been made to include systemic factors,

    Figure 1. An example chain-of-events model for a tank rupture (Leveson, 2012).

    AIChE Journal January 2014 Vol. 60, No. 1 Published on behalf of the AIChE DOI 10.1002/aic 3

  • 8/10/2019 A systemic approach to process safety.pdf

    3/13

    but they turned out to be severely limited in achieving their goals. In accident causation models no account is made for common causes of the failures of the barriers or the other types of events in the chains. These systemic accidentcauses can defeat multiple barriers and other design techni-ques that are assumed to be independent. In such cases, thepopular Swiss Cheese model (Reason, 1990) is totally inad-

    equate to capture the propagation of events leading to anaccident.

    It Does Not Account for the Hierarchical Interaction of Proc-esses-Management-Regulation-Legislation. Accident causa-tion is a complex process involving the entiresociotechnical system including legislators, government reg-ulatory agencies, industry associations and insurance com-panies, company management, technical and engineeringpersonnel, operators, etc. To understand why an accidenthas occurred, the entire process needs to be examined, not just the proximate events in the event chain. Otherwise,only symptoms will be identied and xed, and accidentswill continue to recur.

    It Does Not Provide Effective Ttreatment for CommonCauses. Migration to higher-risk states may occur as aresult of a single common cause, e.g., competitive or nan-cial pressures that force people to cut corners or to behavein more risky ways (Rasmussen , 1997). As an example,consider the Bhopal accident. None of the safety devices, for example, the vent scrubber, are tower, water spouts, refrig-eration system, alarms, and monitoring instruments workedat the time of the accident. At rst glance, the failure of allthese devices at the same time appears to be an event of extremely small probability or likelihood. However, thesefailure events were far from independent. Financial andother pressures led to reduced maintenance of the safetydevices, turning off safety devices such as refrigeration to

    save money, hiring less qualied staff, and taking short cutsto increase productivity. An audit 2 years before the accidentnoted many of the factors involved, such as nonoperationalsafety devices and unsafe practices, but nothing was done tox them.

    A system-theoretic view of process safety

    More effective process safety analysis methodologiesand techniques that avoid the limitations of those based onchain-of-events models are possible, if they are groundedon systems thinking and systems theory. Systems theorydates from the 1930s and 1940s and was a response to thelimitations of the classic analysis techniques in coping withthe increasingly complex systems being built (Checkland,1981). Systems theory is also the theoretical basis for sys-tem engineering and process systems engineering (PSE), aspracticed extensively by chemical engineers (Stephanopou-los and Reklaitis, 2011).

    In the traditional analytic reductionist approach of classi-cal chemical engineering science, processing systems arebroken into distinct unit operations and other operating com-ponents, such as the elements of control loops, and safetydevices. The behavior of the individual physical elementscan be modeled and analyzed separately and their behavior is decomposed into events over time. Then, the behavior of the whole system is described by the behavior of the individ-

    ual elements and the interactions among these elements. Aset of underlying assumptions assures that this is a reasona-ble approach for designing and analyzing the behavior of many processing systems and has been in practice for a longtime. The underlying assumptions are: (a) Separation of theprocess into its components is feasible, i.e., each componentor subsystem operates independently and analysis results are

    not distorted when these components are considered sepa-rately. (b) Processing components or behavioral events arenot subject to feedback loops and other nonlinear interac-tions, and that the behavior of the components is the samewhen examined singly as when they are playing their part inthe whole. Note that the elements of a feedback loop (i.e.,sensor, actuator, and controller) are viewed as componentsof the overall processing system, not as constituents of aprocessing component. (c) The principles governing theassembly of the components into the whole are straightfor-ward, that is, the interactions among the subsystems are sim-ple enough that they can be considered separate from thebehavior of the subsystems themselves.

    In contrast to the above, the system approach focuses on

    the processing system as a whole, and does not decomposeits behavior into events over time. It assumes that someproperties of the processing system can only be treatedadequately in their entirety, taking into account all facetsrelated not only to the technical and physical-chemicalunderpinnings of the processing operations, but also thehuman, socia