Common use of Modelling Phase Clause in Contracts

Modelling Phase. HiP-HOP studies can be performed on any model of a system that identifies components and the material, energy or data transactions among components. Such models can be hierarchically arranged, to manage complexity, if necessary. The basic idea of HiP-HOP is that an output failure of a component can either be caused by an input failure, an internal failure, or some combination of both. The local component output deviations and topology information are used to determine the relation between local deviations and top events. For the purpose of the analysis, each component in the model must have its own local failure data, which describes how the component itself fails and how it responds to failures propagated by other components in the vicinity. Essentially, this information specifies the local effects that internally generated or propagated failures have on the component’s outputs. This is achieved by annotating the model with a set of failure expressions showing how deviations in the component outputs (output deviations) can be caused either by internal failures of that component or corresponding deviations in the component’s inputs. Such deviations include unexpected omission of output or unintended commission of output, or more subtle failures such as incorrect output values or the output being too early or late. This logical information explains all possible deviations of all outputs of a component, and so provides a description of how that component fails and reacts to failures elsewhere. At the same time, numerical data can be entered for the component, detailing the probability of internal failures occurring and the severity of output deviations. This data will then be used during the analysis phase to arrive at a figure for the unavailability of each top event. Once done, the component can then be stored together with the failure data in a library, so that other components of the same type can use the same failure data or this type of component can be re- used in other models with the same failure data. This avoids the designer having to enter the same information many times. For the specification of the components' failure modes (which are the effects by which the component failures are observed), a generic and abstract language was developed. There are different ways of classifying failure modes, e.g. by relating them to the function of the component, or by classifying according to the degree of failure – complete, partial, intermittent etc. In general, however, the failure of a component will have adverse local effects on the outputs of the component, which, in turn, may cause further effects travelling though the system on material, energy or data exchanged with other components. Therefore in HiP-HOPS, effects are generally classified into one of three main classes of failure, all equally applicable to material, energy or data outputs. These are: the omission of an output, i.e. the failure to provide the output; a commission of an output, i.e. a condition in which the output is provided inadvertently and in the wrong context of operation; and an output malfunction, a general condition in which the output is provided but at a level which deviates from the design intention. Since this classification adopts a functional viewpoint which is independent of technology, it could provide a common basis for describing component failures and their local effects. However, HiP-HOPS can work with any classification of failure modes as long as it is consistent from one component to the next. Components do not only cause failures; they also detect and respond to failures caused by other components or transfer failures of other components. In addition to generating, mitigating, or propagating failures, they may also transform input failures to different types of output failure. For instance, a controller may be designed to respond to detected sensor failures by omitting any further output to ensure that hazardous control action is avoided. In this case, malfunctions at the input are intentionally transformed into omission failures. To capture those general patterns of behaviour of a component in the failure domain, manual analysis is performed at component level and focuses on the output ports through which a component provides services to other components in the system. In the course of the analysis, each output port is systematically examined for potential deviations of parameters of the port from the intended normal behaviour, which generally fall into the following three classes of failure: (a) Omission: failure to provide the intended output at the given port (b) Commission: unintended provision of output (c) Malfunction: output provided, but not according to design intention. Within the general class of malfunctions, analysts may decide to examine more specific deviations of the given output which, in most applications, will include conditions such as the output being delivered at a higher or lower level, or earlier or later than expected. As an example, Figure 16 shows the analysis of a two-way computer controlled valve. The figure shows the valve as it would typically be illustrated in a plant diagram and records the results of the local safety analysis of the component in two tables that define valve malfunctions and output deviations respectively. Valve Malfunctions a control b blocked e.g. by debris 1e-6 partiallyBlocked e.g. by debris 5e-5 stuckClosed Mechanically stuck 1.5e-6

Modelling Phase. HiP-HOP HOPs studies can be performed on any model of a system that identifies components and the material, energy or data transactions among components. Such models can be hierarchically arranged, to manage complexity, if necessary. The basic idea of HiP-HOP HOPs is that an output failure of a component can either be caused by an input failure, an internal failure, or some combination of both. The local component output deviations and topology information are used to determine the relation between local deviations and top events. For the purpose of the analysis, each component in the model must have its own local failure data, which describes how the component itself fails and how it responds to failures propagated by other components in the vicinity. Essentially, this information specifies the local effects that internally generated or propagated failures have on the component’s outputs. This is achieved by annotating the model with a set of failure expressions showing how deviations in the component outputs (output deviations) can be caused either by internal failures of that component or corresponding deviations in the component’s inputs. Such deviations include unexpected omission of output or unintended commission of output, or more subtle failures such as incorrect output values or the output being too early or late. This logical information explains all possible deviations of all outputs of a component, and so provides a description of how that component fails and reacts to failures elsewhere. At the same time, numerical data can be entered for the component, detailing the probability of internal failures occurring and the severity of output deviations. This data will then be used during the analysis phase to arrive at a figure for the unavailability of each top event. Once done, the component can then be stored together with the failure data in a library, so that other components of the same type can use the same failure data or this type of component can be re- used in other models with the same failure data. This avoids the designer having to enter the same information many times. For the specification of the components' failure modes (which are the effects by which the component failures are observed), a generic and abstract language was developed. There are different ways of classifying failure modes, e.g. by relating them to the function of the component, or by classifying according to the degree of failure – complete, partial, intermittent etc. In general, however, the failure of a component will have adverse local effects on the outputs of the component, which, in turn, may cause further effects travelling though through the system on material, energy or data exchanged with other components. Therefore in HiP-HOPS, effects are generally classified into one of three main classes of failure, all equally applicable to material, energy or data outputs. These are: the omission of an output, i.e. the failure to provide the output; a commission of an output, i.e. a condition in which the output is provided inadvertently and in the wrong context of operation; and an output malfunction, a general condition in which the output is provided but at a level which deviates from the design intention. Since this classification adopts a functional viewpoint which is independent of technology, it could provide a common basis for describing component failures and their local effects. However, HiP-HOPS can work with any classification of failure modes as long as it is consistent from one component to the next. Components do not only cause failures; they also detect and respond to failures caused by other components or transfer failures of other components. In addition to generating, mitigating, or propagating failures, they may also transform input failures to different types of output failure. For instance, a controller may be designed to respond to detected sensor failures by omitting any further output to ensure that hazardous control action is avoided. In this case, malfunctions at the input are intentionally transformed into omission failures. To capture those general patterns of behaviour of a component in the failure domain, manual analysis is performed at component level and focuses on the output ports through which a component provides services to other components in the system. In the course of the analysis, each output port is systematically examined for potential deviations of parameters of the port from the intended normal behaviour, which generally fall into the following three classes of failure: (a) Omission: failure to provide the intended output at the given port (b) Commission: unintended provision of output (c) Malfunction: output provided, but not according to design intention. Within the general class of malfunctions, analysts may decide to examine more specific deviations of the given output which, in most applications, will include conditions such as the output being delivered at a higher or lower level, or earlier or later than expected. As an example, Figure 16 15 shows the analysis of a two-way computer controlled valve. The figure shows the valve as it would typically be illustrated in a plant diagram and records the results of the local safety analysis of the component in two tables that define valve malfunctions and output deviations respectively. Valve Malfunctions a control b blocked e.g. by debris 1e-6 partiallyBlocked e.g. by debris 5e-5 stuckClosed Mechanically stuck 1.5e-6