Non-specific faults

This process definition covers faults which, though not common, are known to occur in chemical processing. Examples are agitator failure, loss of plant cooling, leaks of cooling liquid into the batch, and process maloperation. Malopera-tion covers over- and under-charging of reactants, solvents or catalysts. Non-specific faults are so called because they are not specific to individual processes and the effect of them can be included in the hazard assessment without additional process description. 

Unless the plant has been designed to eliminate them, then the effect of non-specific faults on process stability, and the consequences of any subsequent runaway situation, have to be included in the hazard assessment. 

For most processes a hazard assessment based on a process definition that includes non-specific faults (Section 2.4.3, page 18) is the minimum standard that leads to an acceptable level of safety. 

Loss of agitation is a non-specific fault (that is, it can happen to any reaction), which can lead to reduced cooling and may lead to accumulation (see Section 4.4.6, page 75). 

First, the system is divided into sections, each section has the capabUity to effect a system process variable and contains a sensor that monitors the functioning of the variable of interest. The possible trends of the monitored variable are smdied and these are correlated to the states of the section. In this way, specific patterns are identified for each possible section failed state. Non-coherent Fault Trees (FTs) are then built to represent the causality relations between the failed state of the sections and the component failures (Hurdle et al., 2005 and 2007). The FTs are converted into BNs and these are finally coimected together in a unique network that represents aU system scenarios. The trends observed in the sensors are also included in the strucmre of the BN so that evidence can he introduced in the networks when the sensor are observed. Posterior probability is calculated for the component failure events in all scenarios and the list of component failures whose posterior prohahihty has increased with respect to their prior prohahUity is derived. This gives the lists of possible causes for all system scenarios. 

It has been argued by several authors (Sibson et al., 1975 Kerrich, 1986 Burley et al., 1989) that cement seals are important features in faulted sedimentary sequences. This may be correct for specific tectonic settings, but is considered unlikely to be important for structures which cut poorly or non-cemented... 

The international working group that prepared lEC 61508 considered the above factors and specified the extent of fault tolerance required in lEC 61508-2. In preparing this sector-specific standard for the process sector it was considered that the requirements for fault tolerance of field devices and non PE logic solver could be simplified and the requirements in lEC 61511-1 ANSI/ISA-84.00.01-2004 Part 1 (lEC 61511-1 Mod) could be applied as an alternative. It should be noted that subsystem designs may require more component redundancy than what is stated in Tables 5 and 6 in order to satisfy availability requirements. 

Because it is well known, that results from thermal-hydraulics or integral codes may be fraught with rmcertainty because of diverse rmcertainty sources included in their calculation, it must consequently be assumed that also the minimum requirements derived from application of the respective codes may be subject to a non-negligible uncertainty. Uncertainty on minimum requirements induces imcertainty on the specification of function events and on top events. Uncertainty on top events means imcertainty on the structure of the respective fault tree model. That means, the uncertainty on the results from the application of thermal-hydraulics or integral codes propagates through the fault-tree and event-tree models and finally contributes to the uncertainty on the PSA-results. 

Information about deterministic or non-random failures may be difficult to extract from accident or incident scenario analyses. Unhke random hardware failures, deterministic faults maybe present from the outset and will not necessarily reveal themselves until a particular set of circumstances occurs. Apphcation software specification and implementation errors (bugs) are typical examples of faults that may remain unrevealed for years. In this context, a fault is the loss of capability to perform a function, while a failure would mean that the function has not been performed at all, when cahed upon to do so. 

Software failures chronically occur and in most cases do not cause damage. However, a system is called critical when failures result in environmental damage (safety-critical), in a non-achieved goal compromising the system (mission-criticat) or in financial losses (business-criticat). Avizienis et al. [1] cleverly identified the fault-error-failure chain to support specification of intricacies occurring in critical systems. 

It may also be able to justify less fault tolerance than required by Table 6, when the dangerous failure modes of the SIF devices and associated process interfaces are well understood. Clause 11.4.4 states that if the selection of a device is based on prior use, then, under specific conditions, the fault tolerance for sensors, final control elements, and non-PE logic solvers can be reduced by 1. The reduction of fault tolerance is acceptable, since prior use establishes the field application data, which includes the random hardware failures for the device itself and the random failures due to the process and field device interfaces. 

The control arrangements should be part of the written health and safety policy. Performance standards will need to be agreed and objectives set which link the outputs required to specific tasks and activities for which individuals are responsible. For example, the objective could be to carry out a workplace inspection once a week to an agreed checklist and rectify faults within three working days. The periodic, say annual, audit would check to see if this was being achieved and if not the reasons for non-compliance with the objective. 

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. 

Given this situation, the aim of this research work is to provide a modeling and simulation environment for dependable Time-Triggered HW/SW systems based on SystemC. The main contribution of this paper is the presentation of a testing and simulated fault injection framework for the Platform Specific Time-Triggered Model (PS-TTM) approach [2], which enables reproducible non-intrusive SFI at different stages of the development for the early assessment of fault-tolerance mechanisms. 

The detection of sensor faults is modelled by the new event Pre-Processing. An excerpt from the specification of this event, shown in Fig. 5, illustrates detection of the sensor fault Value is out of range . The event Pre-Processing also introduces an implicit modelling of the effect of software faults by non-deterministic update of the variable unit-status. 

---