Simulation-based automatic generation of risk scenarios

Journal of Systems Engineering and Electronics Vol. 22, No. 3, June 2011, pp. 437–444

Available online at www.jseepub.com

Simulation-based automatic generation of risk scenarios

Jinghui Li1, 2, Rui Kang1, ∗, Ali Mosleh2, and Xing Pan1

1. School of Reliability and Systems Engineering, Beihang University, Beijing 100191, P. R. China;2. Center for Risk and Reliability, University of Maryland, College Park, MD 20742, USA

Abstract: A methodology for automatically generating risk scenar-ios is presented. Its main idea is to let the system model “expressitself” through simulation. This is achieved by having the simula-tion model driven by an elaborated simulation engine, which: (i)manipulates the generation of branch points, i.e. event occurrencetimes; (ii) employs a depth-first systematic exploration strategy tocover all possible branch paths at each branch point. In addition,a backtracking technique, as an extension, is implemented to re-cover some missed risk scenarios. A widely discussed dynamicreliability example (a holdup tank) is used to aid in the explanationof and to demonstrate the effectiveness of the proposed method-ology.

Keywords: risk scenario, automatic generation, simulation, riskassessment, dynamic reliability.

DOI: 10.3969/j.issn.1004-4132.2011.03.011

1. Introduction

Many modern systems, such as airplanes, spacecrafts, andnuclear power plants, are safety critical and subject to reli-ability and risk assessment. In the process of assessing therisk associated with these systems, it involves answeringthree major questions [1]:

(i) What can go wrong? [Scenarios](ii) How likely is each scenario? [Probabilities](iii) What is the consequence of each scenario? [Conse-

quences]A host of risk assessment methodologies have been de-

veloped over the past decades (see for example [2–4] fora review of these methods). Most often, research interestsare dedicated to the second question, namely probabilityevaluation. In contrast, less attention has been paid to thefirst question, i.e. scenario information. Most methodolo-gies do not provide explicit scenario results (the classicalevent tree/fault tree approach and the event sequence dia-gram method are two exceptions). For Monte Carlo (MC)

Manuscript received November 1, 2010.*Corresponding author.This work was supported by the National Natural Science Foundation

of China (70901004) and the Fundamental Research Funds for the Cen-tral Universities (YWF-10-01-A12).

simulation and discrete dynamic event tree (DDET) [5–8],for instance, a significant effort is still needed for retriev-ing scenario information in the post-processing stage [4].Some recent works in this direction can be found in [9–11].

Nevertheless, scenario information is also a very impor-tant part of a risk assessment. Based on the knowledgeof how unsafe end states can be reached, risk analysts andmanagers can make proper decisions concerning, e.g.,

• what risk scenarios mostly need to be avoided;• how they can be mitigated;• priorities for actions that can be taken in system de-

sign, operation, diagnostics, and maintenance.Another important application of scenario information

is that, as described in [12], it can be used to guide thesimulation to achieve fast convergence (to tackle the noto-rious slow-convergence problem of MC simulation). Thisis an important and direct motivation for the current work.

Typically, the burden of identifying possible risk sce-narios falls completely on the analyst in most existing re-liability and risk analysis methods, such as failure modesand effects analysis (FMEA), hazard and operations anal-ysis (HAZOP), event trees (ET), fault trees (FT), event se-quence diagrams (ESD) [13,14], anticipatory failure deter-mination (AFD) [15], and hierarchical holographic mod-eling (HHM) [16–18]. In these methods, the analyst isrequired to enumerate possible risk scenarios. For large,complex, and highly dynamic systems, this is often a com-plicated and tedious task. And the quality of the result isstrongly analyst dependent. There is scope for erroneouslyneglecting some relevant dynamic behaviors or collapsingtogether risk scenarios which are actually different and re-sult in different end states.

It is appealing if some automation can be achieved in thescenario identification process. An attempt along this linehas been made in [19], which offers a method to capturedifferent types of engineering knowledge and use them toautomatically generate risk scenarios. The method was ini-tially motivated by the need of providing plans for guidingthe simulation within the framework of SimPRA, a soft-

438 Journal of Systems Engineering and Electronics Vol. 22, No. 3, June 2011

ware platform for dynamic probabilistic risk assessment(PRA) purposes developed at the University of Maryland[19–21]. This new method, however, still requires signif-icant efforts from the analyst (in inputting relevant infor-mation prior to the automation part). And for some in-puts (e.g., functionalities), it is not very clear how to definethem appropriately.

In this work, we propose a simulation-based approach toautomatic generation of risk scenarios. It takes advantageof the current SimPRA framework and the readily availablesimulation model (which has been built for probability es-timation), and requires no extra inputs from the analyst.

2. Example—a holdup tank

The holdup tank example has been extensively studied in[2,7,12,20,22–24], and a number of variants exist. The sys-tem configuration considered here is the same as in [12].For completeness of the information in this paper, somerelevant descriptions of the system are repeated here.

As shown in Fig. 1, the system consists of:

Fig. 1 Diagram of holdup tank example system

• a tank containing a chemical fluid;• two pumps supplying fluid;• a valve discharging fluid;

• a control system detecting the fluid level and acting onthe two pumps and the valve.

Initially, the system is under its nominal conditions: thefluid level is at 0 m and all the components are workingnormally, with Pump 1 on, Pump 2 off and Valve on. Theflow rates of Pump 1, Pump 2 and Valve are all 0.6 m/h.As for the failure logic, it is assumed that if a componentfails, it goes to the opposite state to the normal one. Andthe components will be stuck in their failed states after theyfail (either in operation or on demand). Repair is not con-sidered here, i.e. failed components can not be repaired.The control law of the control system is given in Table 1.

Table 1 Control law of the holdup tank

Pump 1 Pump 2 ValveOn L < +1 L � −1.5 L > −1

Off L � +1 L > −1.5 L � −1

Apart from failures in operation of Pump 1, Pump 2 andValve, failures on demand of the control system are alsoconsidered. In the case that the control system fails to actas demanded, the state (on/off) of Pump 1, Pump 2 andValve will not change. The above two types of failuresmay bring the system out of control. When the fluid levelgoes beyond +3 or –3, system failure overflow or dryoutoccurs. The mission time is 100 h.

3. SimPRA framework

In this section, we give a brief overview of the SimPRAframework, which our proposed methodology is based onand implemented in.

SimPRA is a software platform implementing a newguided simulation methodology for dynamic PRA. Onekey idea of the SimPRA environment is to exploit use-ful knowledge and information of the system to guide thesimulation in an efficient and targeted way. The Sim-PRA framework consists of three major elements (Fig. 2):planner (map supplier), scheduler (simulation engine), andsimulator (simulation model).

Fig. 2 SimPRA framework

Jinghui Li et al.: Simulation-based automatic generation of risk scenarios 439

The role of the planner is to provide the system’s riskscenarios of interest (called “plan”). This plan serves asa map to guide the simulation. The task of guidance ismainly carried out by the scheduler. The scheduler man-ages the simulation process by controlling the timings andoccurrences of stochastic events within the system (bothtransitions in operation and transitions on demand). When-ever a branch point is reached, the simulator makes abranching request to the scheduler. The scheduler thenretrieves relevant information from the map, and selectswhich branch to visit from all possible ones. The decisionmade by the scheduler, or the exploration command willthen be sent back to the simulator to be executed. This pro-cess continues until an end state (system failure or end ofthe mission time) is reached. For more information aboutSimPRA, the reader is referred to [19–21].

4. Proposed methodology

4.1 Overview

The main idea of the proposed methodology is inspired bythe fact that each life history simulated by MC-style sim-ulation actually exhibits and represents a certain behavior(scenario) of the system. Thus, risk scenarios can be ob-tained from simulation.

As an example, among simulated life historiesof the holdup tank, some are of the followingform: <Pump1 F@t1, VSwitch S@t2, Pump2 F@t3,VSwitch F@t4, Overflow@t5> with a specific set of val-ues of t1, t2, t3, t4, t5 for each specific life history,where “ S” and “ F” mean “success” and “failure”, respec-tively. By ignoring the specific occurrence times and keep-ing only the events in the order of their occurrence, wecan group all these histories into the following accidentscenario: <Pump1 F, VSwitch S, Pump2 F, VSwitch F,Overflow>.

Formulating a scenario as a sequence of events orderedin time as above is natural. It is consistent with how hu-man beings think and how accidents actually happen in re-ality. So we will use scenario to refer to a sequence ofevents ordered in time but without detailed time specifica-tions. Note also that we will use event sequence to denotea sequence of events with their specific occurrence timesgiven, which can identify a specific system trajectory orlife history. Hence, an event sequence can be viewed as aspecific time realization of a scenario, and all possible sce-narios form a partition of the system event sequence space.An illustration of the relationship between scenarios andevent sequences is given in Fig. 3.

Fig. 3 Scenarios versus event sequences

One can see that each simulated event sequence actu-ally touches a certain scenario. Thus, risk scenarios canbe extracted from simulated event sequences. However, itis apparently inefficient to extract risk scenarios from theusual MC simulation.

To facilitate scenario generation, a special simulationscheme is devised in this work based on the indirectsystem-based MC simulation [25]. The generation ofbranch points (i.e. event occurrence times) is managed infavor of touching accident scenarios. Besides, the schemeutilizes a systematic exploration strategy. Instead of touch-ing only one branch at each branch point as in usual MCsimulation, the proposed methodology covers all possiblebranches at all branch points in an exhaustive manner as inDDET [6,8]. The scheme is implemented in the schedulermodule of SimPRA. With the proper drive of the simula-tion engine, the simulation model “expresses itself” andproduces possible risk scenarios. To get a more clear ideaof the proposed methodology, we depict separately thescheduler and the simulator below in Fig. 4, highlightingsome features related to scenario generation.

Fig. 4 Overview of the proposed methodology

The following Section 4.2 and Section 4.3 are dedicatedto the part of simulation model and simulation engine, re-spectively.


4.2 Simulation model

The role of the simulation model is to represent the phys-ical system in simulation and emulate its relevant behav-iors. The SimPRA framework uses MATLAB/Simulink tobuild the simulation model to take advantage of its strongmodeling and computing capabilities.

In dynamic PRA problems, the system typically con-sists of a continuous, deterministic world and a discrete,stochastic world. The first world is the system’s underly-ing process dynamics (process variables such as tempera-ture, level, and pressure); The second world is the system’sconfiguration (the states of its components). The evolutionof process variables in a given system configuration is gov-erned by some deterministic physical laws, which usuallycan be represented by a set of differential equations. Themodel of the first world is similar to the ones used by con-trol and many other engineers to design systems. For thesecond world, the system configuration changes from oneto another due to the failures (and repairs if relevant) of thedifferent components of the system. To model componentfailure behaviors, the possible failure modes of each com-ponent need to be identified. FMEA, if already performed,can provide this information. Another important issue isthe coupling of the two worlds. To this end, an analysisof how the different failure modes of a component affectits dynamic behaviors needs to be carried out. Further, byintroducing the more general concept of “operation mode”(both the nominal operation mode and all different failuremodes can be viewed as a specific operation mode of thecomponent), normal behaviors and faulty behaviors can bemodeled in a unified fashion.

The evolution of the system is tracked by solving thecontinuous world between branch points and updating thediscrete world’s state at branch points. During the courseof simulation, whenever a branch point is reached, thecontinuous-world simulation pauses, and the simulationmodel makes a request to the scheduler regarding how toadvance the simulation next. The scheduler makes its de-cision and sends the corresponding exploration commandback to the simulation model. The simulation model thenexecutes the received command (changes the state of thediscrete world). For example, the command may be to leta pump fail, the simulator then change the pump’s statefrom operating to failed. The continuous-world simula-tion then resumes, according to a different physical modelcorresponding to the new state of the discrete world. Thisprocess continues until some stopping criterion is met.

Aside from blocks modeling system behaviors, someextra blocks that serve as the interface between the sched-uler and the simulator are also contained in the simulation

model. The role of these blocks is to take care of the com-munications between the simulation engine and the simu-lation model:

• on the one hand, the simulator proposes all possiblebranches to the scheduler at each branch point, and notifythe scheduler of the end state that is reached at the end ofeach history;

• on the other hand, the scheduler tells the simulatorwhat to do next at each branch point and at the end of ahistory.

These interface blocks have been included in a cus-tomized library called SimPRA, which also collects someother customized blocks useful for risk and reliability anal-ysis.

4.3 Simulation engine

It is the simulation engine’s task to drive the simulationmodel to generate risk scenarios. To fulfill this task, thefollowing two issues are managed with care in the simula-tion engine:

• branch point generation;

• strategy of exploring the possible branches at branchpoints.

4.3.1 Branch point generation

In system-based MC simulation, the next transition times(i.e. branch points) are sampled for the whole systemrather than individual components [25–27]. In this work,branch points will also be generated for the whole system.

For risk assessment, we are more interested in accidentscenarios (i.e. sequences of events that can lead to unde-sired situations) rather than success ones. And obviouslyin order for the system to reach unsafe conditions, enoughbranch points need to be generated within the mission time.To this end, we generate branch points in the followingway: each branch point is placed between the last branchpoint along the current path (Tlast) and the end of the mis-sion time (Tmission), namely in the interval (Tlast, Tmission)(and (0, Tmission) for the first branch point); several strate-gies could be used to determine the exact position of eachbranch point in the above interval, for example, simplerandom sampling (i.e. have branch points uniformly dis-tributed over the interval), or simply taking the midpointof the interval, or some other strategies, depending on thespecific problem at hand. The above scheme ensures thatfurther branch points will be generated before the missiontime is out, if the system has not yet reached unsafe endstates. This idea is a little similar to that of the forced tran-sition technique in [26]. As such, the methodology favorsto touch accident scenarios as desired. Finally, it is worth


pointing out that the above branch point generation schemeis only for transitions in operation; while for transitions ondemand, there is no need to intervene. Their branch pointswill be automatically generated by the simulation modelitself when some criterion is satisfied (e.g., when a certainprocess variable crosses a preset control threshold).

4.3.2 Systematic exploration

As stated earlier, the second issue is how to explore thepossible branches at each branch point. A systematic ex-ploration strategy is employed to achieve a full coverageof the system’s risk scenarios. As is well known, thereare two basic algorithms to conduct a systematic explo-ration, namely breadth-first and depth-first. Here, we adoptthe depth-first approach, which is more effective and lessmemory-consuming in our case. In addition, we use a stackto support dynamic memory allocation (referred to as theevent stack hereafter).

Each time it arrives at a new branch point, the simula-tor pauses the continuous-world simulation and proposesall possible branches to the scheduler. The scheduler firstadds all the branches/nodes as children to the current fa-ther node in the scenario tree, then pushes all the branches(with all relevant information) into the event stack, andlastly sends a stop command to the simulator. On receivingthe stop command, the simulator saves the current state ofthe simulation model and stops the simulation. The mainprogram then re-initializes the simulation. And initializa-tion will be performed both on the part of the scheduler andthe simulator. The scheduler pops out the topmost item ofthe event stack and makes the corresponding event as thenew current father node, as well as tells the simulator whatthe popped branch is. On the part of the simulator, it firstretrieves the state information that was saved earlier, andmodifies accordingly the state of the component that cor-responds to the popped branch. The finally obtained stateis then taken as the initial state of the simulation model.

After finishing the initialization, a new run of simulationstarts. This process continues until there is no branch leftunexplored in the event stack (the whole process is coun-tered as one round of simulation, which consists of mul-tiple runs of simulation). Note that end states can also beviewed as events, but they will only be added to the sce-nario tree while not pushed into the event stack.

Fig. 5 illustrates part of the exploration process for theholdup tank example.

The branch point indicated with a circle in Fig. 5 givesan example branch point for transitions on demand. Itis encountered along the path that follows the “Valve F”branch (“Valve F” is popped out of the event stack (Fig.5(a)) and followed by the simulator). This branch pointis generated automatically by the simulation model it-self when the level crosses the control setpoint of Pump2, which is demanded to switch. At this branch point,the simulator proposes to the scheduler the two possiblebranches “P2Switch S” and “P2Switch F”. The schedulerthen adds these two branches as children to the current fa-ther node “Valve F” in the scenario tree (Fig. 5(c)), andpushes them into the event stack (Fig. 5(b)). The simu-lation then stops and is re-initialized. The topmost item“P2Switch F” is taken out of the event stack and followedfirst in the next run of simulation.

It can be seen that, from the perspective of theevent stack, the process consists repeatedly of new childbranches being pushed in and the topmost branch beingpopped out and explored first. While from the perspectiveof the scenario tree, the process is very similar to the depth-first search in graph theory. Each time a branch point is hit,the scheduler chooses one branch among all possible onesto follow. When an end state putting an end to the currentpath is entered, the scheduler goes one step back to the pre-vious branch point, and continues to explore other possiblebranches. When all possible branches at a branch point

Fig. 5 Illustration of the depth-first systematic exploration process


have been touched, the scheduler brings the simulator onemore step back. This process continues until there is nobranch remaining to be explored. In Fig. 5(c), the order ofthe bottom part of the scenario tree being explored is illus-trated by the arrows, and the order of all seven scenariosbeing generated is shown by the numbers.

Fig. 6 displays the scenarios generated in one roundof simulation for the holdup tank example (not includingthose dashed-lined scenarios, which will be generated bythe backtracking technique presented in the next section;for ease of reference, we will refer to the solid-line part ofFig. 6 as Fig. 6 (solid) below). Note also that the success

Fig. 6 Risk scenarios for the holdup tank example

scenarios were chosen not to be generated in Fig. 6.

4.3.3 An extension: backtracking

As can be seen from Fig. 6, for the holdup tank exam-ple, one round of simulation was able to generate mostimportant scenarios. Still, there are some risk scenariosmissing in Fig. 6 (solid). For example, theoretically afterPump 1 fails, Pump 2 and/or Valve might fail before thefluid level reaches the valve’s setpoint. Those scenariosoriginating from this possibility were not touched. Fromthe perspective of probability, those scenarios might be ex-tremely improbable due to the fact that the transient times

for the fluid level to reach the control thresholds are rela-tively short. Hence, those scenarios might be ignorable forprobability estimation. Nevertheless, for scenario genera-tion, in general we hope to have all possible risk scenariosideally.

The reason why some scenarios were missed in the pre-vious round of simulation is the timing factor (i.e. theoccurrence times of the events). One possible remedy isto run multiple rounds of simulation (with simple randomsampling to determine the exact position of each branchpoint). This method, although quite simple, may not be sat-isfactorily efficient. In the following, we propose a back-


tracking technique.

The above-mentioned issue (i.e. Pump 2 and/or Valvefails before or after the fluid level reaches the valve’s set-point in the holdup tank example) actually represents animportant class of dynamic behaviors existing extensivelyin dynamic systems. That is, transitions in operation oc-curring before or after some critical time points (e.g. whenprocess variables cross control thresholds or safety bound-aries) often lead to different scenarios. It is desirable,therefore, to cover both of the two cases (i.e., before andafter) at the same time. This is the main idea that inspiresthe following backtracking technique.

In the methodology presented before this section,only one case (either before or after) will be coveredin one round of simulation. In Fig. 6 (solid), following“Pump1 F”, Pump2 and/or Valve failing after the switch ofthe Valve was explored, while the before case was missed.The proposed backtracking technique then works as fol-lows: after pushing the two branches “VSwitch S” and“VSwitch F” into the event stack, the scheduler bringsthe simulator one step back to the previous branch point(the one before “Pump1 F”), and follows the “Pump1 F”branch path once again, but with a different next branchpoint this time. The new next branch point is placed beforethat of the valve switch (e.g., one can put it at the mid-point between the time of “Pump1 F” and that of the valveswitch). In this way, the missed before case will also beexplored now. A similar procedure can be applied to cir-cumstances where the before case is covered in the originalsimulation while the after case is missed. The risk scenar-ios that were additionally generated by the backtrackingtechnique are shown in dashed line in Fig. 6.

Supplemented by the above backtracking technique, themethodology produced all the scenarios in Fig. 6 for theholdup tank example in one round of simulation, whichtook less than 15 s on a personal desktop (Dell OptiPlexGX270 with a 3.00 GHz Pentium 4 CPU).

5. Conclusion

In this work, we have investigated a simulation-based ap-proach to automatically generating risk scenarios. It sim-ply uses the simulation model of the system and requiresno extra inputs from the analyst. With a simple click andin an encouragingly short time, as demonstrated by theholdup tank example, most of the major risk scenarios ofthe system can be obtained. Although it may not produceall theoretically possible risk scenarios, and guarantee thatall scenarios it generates will be completely correct (someextra efforts might still be needed from risk analysts to re-fine produced scenario results), the methodology can ease

the burden on risk analysts significantly.It is also worth mentioning that the methodology can

be applied to other types of systems as well as dynamicreliability ones. The reason why emphasis is placed on dy-namic reliability problems in this work is that such prob-lems often involve complex interactions among differentelements of the system (hardware, software, human, pro-cess variables, and protection/control devices). The bur-den of identifying possible risk scenarios for such prob-lems on the analyst might be extremely heavy. Thus, thevalue of the proposed methodology becomes particularlyprominent in such situations.

For the studied holdup tank example, the presentedmethodology has handled it satisfactorily. But for somehighly dynamic systems, it may be insufficient. The dy-namic degree of the timing of events in the holdup tank ex-ample is still limited in the sense that it just results in twodifferent cases (before or after). Varying the exact timesof occurrence of the events does not make a difference aslong as they do not change from the before/after case to theafter/before case. In some highly dynamic systems, manydifferent risk scenarios may arise depending on the exactoccurrence times of events. It can be seen that the currentmethodology in its basic form only touches one specific setof event occurrence times in one round of simulation. Onepossible remedy is to run multiple rounds of simulation.An important issue here is how to manage the exact timingsof events. The simple random sampling scheme may notbe satisfactorily efficient, and a more sophisticated branchpoint generation scheme is needed. Research in this direc-tion is currently underway.

Acknowledgment

The authors thank Dr. Yunwei Hu, Dr. Seyed HamedNejad-Hosseinian, and Dr. Dongfeng Zhu for their contri-bution to and help with the SimPRA software platform.This work was done while the first author was visiting theUniversity of Maryland, College Park, and the visit wassupported by China Scholarship Council.

References[1] S. Kaplan, B. J. Garrick. On the quantitative definition of risk.

Risk Analysis, 1981, 1(1): 11–27.[2] N. Siu. Risk assessment for dynamic systems: an overview.

Reliability Engineering and System Safety, 1994, 43(1):43–73.

[3] J. Devooght. Dynamic reliability. J. Lewins, M. Becker. Ad-vances in nuclear science and technology. New York: PlenumPress, 1997: 215–278.

[4] P. E. Labeau, C. Smidts, S. Swaminathan. Dynamic reliabil-ity: towards an integrated platform for probabilistic risk as-sessment. Reliability Engineering and System Safety, 2000,68(3): 219–254.

[5] C. Acosta, N. Siu. Dynamic event trees in accident sequence


analysis: application to steam generator tube rupture. Relia-bility Engineering and System Safety, 1993, 41(2): 135–154.

[6] G. Cojazzi, P. C. Cacciabue, P. Parisi. DYLAM-3: a dynamicmethodology for reliability analysis and consequences evalu-ation in industrial plants, theory and how to use. EUR 15625(EN), 1993.

[7] G. Cojazzi. The DYLAM approach for dynamic reliabil-ity analysis of systems. Reliability Engineering and SystemSafety, 1996, 52(3): 279–296.

[8] K. S. Hsueh, A. Mosleh. The development and application ofthe accident dynamic simulator for dynamic probabilistic riskassessment of nuclear power plants. Reliability Engineeringand System Safety, 1996, 52(3): 297–314.

[9] E. Zio, F. D. Maio. Processing dynamic scenarios from a relia-bility analysis of a nuclear power plant digital instrumentationand control system. Annals of Nuclear Energy, 2009, 36(9):1386–1399.

[10] D. Mercurio, L. Podofillini, E. Zio, et al. Identification andclassification of dynamic event tree scenarios via possibilis-tic clustering: application to a steam generator tube rup-ture event. Accident Analysis and Prevention, 2009, 41(6):1180–1191.

[11] L. Podofillini, E. Zio, D. Mercurio, et al. Dynamic safety as-sessment: scenario identification via a possibilistic clusteringapproach. Reliability Engineering and System Safety, 2010,95(5): 534–549.

[12] J. H. Li, A. Mosleh, R. Kang. From blind to guided simula-tion: biased Monte Carlo based on entropy and zero variancefor dynamic PSA applications. Proc. of the 10th InternationalProbabilistic Safety Assessment & Management Conference,2010.

[13] S. Swaminathan, C. Smidts. The event sequence diagramframework for dynamic PRA. Reliability Engineering and Sys-tem Safety, 1999, 63(1): 73–90.

[14] S. Swaminathan. Dynamic probabilistic risk assessment usingevent sequence diagrams. College Park, USA: University ofMaryland, 1999.

[15] S. Kaplan, S. Visnepolschi, B. Zlotin, et al. New tools for fail-ure and risk analysis: an introduction to anticipatory failuredetermination (AFD) and the theory of scenario structuring.Southfield: Ideation International Inc, 1999.

[16] Y. Y. Haimes. Hierarchical holographic modeling. IEEETrans. on Systems, Man, and Cybernetics, 1981, 11(9): 606–617.

[17] Y. Y. Haimes. Risk modeling, assessment, and management.2nd ed. Hoboken: Wiley, 2004.

[18] S. Kaplan, Y. Y. Haimes, B. J. Garrick. Fitting hierarchicalholographic modeling into the theory of scenario structuringand a resulting refinement to the quantitative definition of risk.Risk Analysis, 2001, 21(5): 807–819.

[19] S. H. Nejad-Hosseinian. Automatic generation of general-ized event sequence diagrams for guiding simulation based dy-namic probabilistic risk assessments of complex systems. Col-lege Park, USA: University of Maryland, 2007.

[20] Y. W. Hu. A guided simulation methodology for dynamicprobabilistic risk assessment of complex systems. CollegePark, USA: University of Maryland, 2005.

[21] D. F. Zhu. Integrating software behavior into dynamic prob-abilistic risk assessment. College Park, USA: University ofMaryland, 2005.

[22] T. Aldemir. Computer-assisted Markov failure modeling of

process control systems. IEEE Trans. on Reliability, 1987,36(1): 133–144.

[23] M. Marseguerra, E. Zio. Monte Carlo approach to PSA fordynamic process systems. Reliability Engineering and SystemSafety, 1996, 52(3): 227–241.

[24] Y. Dutuit, E. Chatelet, J. P. Signoret, et al. Dependability mod-elling and evaluation by using stochastic Petri nets: applicationto two test cases. Reliability Engineering and System Safety,1997, 55(2):117–124.

[25] P. E. Labeau, E. Zio. Procedures of Monte Carlo transportsimulation for applications in system engineering. ReliabilityEngineering and System Safety, 2002, 77(3): 217–228.

[26] E. E. Lewis, F. Bohm. Monte Carlo simulation of Markovunreliability models. Nuclear Engineering and Design, 1984,77(1): 49–62.

[27] C. Smidts, J. Devooght. Probabilistic reactor dynamics II: aMonte Carlo study of a fast reactor transient. Nuclear Scienceand Engineering, 1992, 111(3): 241–256.

BiographiesJinghui Li was born in 1984. He is currentlya Ph.D. candidate in School of Reliability andSystems Engineering, Beihang University. Hisresearch interests now are in the areas of risk andsafety assessment, and reliability engineering.E-mail: [email protected]

Rui Kang was born in 1966. He is currentlychair professor in School of Reliability and Sys-tems Engineering, Beihang University. His re-search interests include reliability design and ex-periment based on physics of failure, prognosticsand health management, logistics support, sys-tems engineering, and network reliability.E-mail: [email protected]

Ali Mosleh is currently a professor of Mechan-ical Engineering at the University of Maryland,College Park, USA. He is a member of the U.S.National Academy of Engineering. His researchinterests include risk and safety assessment, reli-ability analysis, and decision analysis.E-mail: [email protected]

Xing Pan was born in 1979. He receivedhis Ph.D. degree from Beihang University. Heis currently an associate professor in Schoolof Reliability and Systems Engineering, Bei-hang University. His research interests includeknowledge systems engineering and system riskanalysis.E-mail: [email protected]

Documents

Simulation-based automatic generation of risk scenarios