Fault Propagation Result Analysis

Physical Equipm ent Class (PEC) Normal/ Abnormal Situation (NAS) Process Variable (PV) Fluid (FED) Operati on (OPR) Position in Process Equipment (POS) 

From the above analysis, we can define the ontology model of the fault propagation based on NAS, PEC, PV, FED, OPR, and POS, as in figure 3-25. 

The above analysis and model is useful to enable us to draw the structure of the database of the failure data group and to automate the hazard evaluation practice. But in order to do that it is essential to define the fault propagation model and its representation in the plant design model using the above analysis results. 

Fault propagation model elements (FPMEs) are as stated earlier PEC, PV, NAS, POS, FLD, and OPR. These elements can be mapped to the plant object oriented model (POOM) as per table 3-6. 

---

The MBSA is a multi-aspect analysis, since it analyzes a functional implementation model and injects faults, described in the safety aspect. Figure 1 describes the principal relation between a safety contract, the malfunctions of a system and the result of the MBSA on the example of a simple fault propagation contract... 

Using result by HAZOP system, the fault propagation scenario is created. The information of propagation is stored to the data base in the system. The analysis result shows the cause of propagation and identifies the hazards by the database. From this data base, it can remove the necessary information to create scenario tree. The proposed system creates the scenario tree of fault propagation automatically. This scenario tree system is developed to calculate automatically the accident frequency quantitatively. The model of the fault propagation scenario is created from many results of HAZOP system. It is shown in Figure 3. EiO is... 

In this paper, we have investigated the use of different frameworks for uncertainty representation and propagation in fault tree analysis. The frameworks considered are the probabihstic (Bayesian) and possi-bilistic frameworks, as well as an integratedprobabihs-tic/possibilistic computational framework, referred to as a hybrid approach. The tailoring of the integrated computational framework to the fault tree setting is the main contribution of the paper. Interpretations for the results obtained within the different approaches are provided, as well as a discussion of the approaches in relation to a specific case. However, a direct comparison of the actual results obtained for the different approaches has not been made, as no efforts have been made to make the probabihty and possibility distributions used as input coherent. In future work, we intend to make this comparison based on coherent probability-possibility transforms presented in the literature and to extend the computational procedures in the hybrid approach to produce uncertainty statements about the top event of the fault tree. 

Statistically, a gross error is an error whose occurrence as realisation of a random variable is highly unlikely. It can arise out of inattention, a fault in the measuring instrument, erroneous calculation, or some other unforeseen event. The presence of a gross error corrupts also the results of other measurements and estimates, due to the propagation of errors in the reconciliation and unmeasured variables estimation. A detailed analysis lies beyond the scope of the present book. Let us only summarize the theoretical possibilities for detection and identification of gross errors. See further for instance Madron (1992). 

The results of this propagation are formulated through Fault Trees. In case of modification of the system or software model, Safety Architect is able to perform an impact analysis that reduces the rework costs that can be very high for a FMEA. For example, the addition or modification of a function or component can be analysed for safety concern with the reuse of the previous analysis. 

Functional specification and functional realization are the functional views of a component. These views are models that describe the desired data flow through a component on different levels of abstraction. Other functional and non-functional properties of a component, such as resource consumption, quality of services, or dependability, are modeled and separated by additional views (models). For example, the propagation of failures through a component is modeled by a failure specification and a failure realization view. The view concept helps to focus on a single property of a component and thus helps to handle complexity. In this paper, we focus only on the functional views and on the failure views already explained above, which are the results of fault tree analysis of the component. This analysis, the resulting failure specification and failure realization, as well as the relationship between both views will be discussed in the remainder of this paper. 

---