Handbook of Reliability, Availability, Maintainability and Safety in Engineering Design - Part 78 pot

754 5 Safety and Risk i n Engineering Design Fig. 5.107 ANN NeuralExpert network comple xity (PFD) of a plant to access specific details of any object shown on the PFD, as well as the object’s detailed specifications, diagnostics or performance measures. The di- agnostics inference engine contains diagnostic charts and queries relating to failure characteristics, failure conditions, equipment criticality, performance measures, and operating and maintenance strategies. The knowledge base consists of facts and functions relating to all the techni- cal data pertaining to process definition, systems definition, performance assess- ment and analysis, conditions and constraints relating to equipment failure modes and effects, the level of risk and mitigating maintenance procedures, as well as an assessment of the required resources. Figure 5.108 illustrates the AIB blackboard knowledge base user interface to access the various expert systems with their rules and goals. A knowledge-based expert system emulates the interaction a group of multi- discipline design engineers will have in solving a design problem. The decision trees or rules used in a knowledge-based expert system contain the knowledge of the hu- man specialist(s) in a particular field. The inference engine makes use of these rules to solve a problem in achieving set goals (design criteria). The end u ser (designer) asks structured questions until the expert system has reached an optimal solution in 5.4 Application Modelling of Safety and Risk in Engineering Design 755 Fig. 5. 108 Expert systems functional overview in the AIB blackboard knowledge base meeting the specific design criteria, and gives information on how they were arrived at, and why. As previously indicated, the diagnostics inference engine contains diagnostic charts and queries relating to equipment failure characteristics and failure condi- tions. Figure 5.109 illustrates a user’s access to the AIB blackboard’s diagnostics inference engine selection menu for assessment of equipment conditions, risk and criticality, as well as operating and maintenance costs and strategies and logistic support. The first step in diagnostics of eq uipment condition is finding the failure effect on a process by determining the impact of an isolated failure on neighbouring and dependent components. This is the basic precursor to establishing a failure modes and effects analysis (FMEA). FMEA is a powerful design tool to analyse engineer- ing systems, and may simply be described as an analysis of each potential failure mode in the system and examination of the results or effects of such failure modes on the system. The strength of FMEA is that it can be applied at different systems hierarchy lev- els. In the specific case illustrated in Fig. 5.110, it is applied to determine the perfor- mance characteristics of the gas cleaning process, the functional failure probability of its critical systems, such as the halide tower, the failure-on-demand probability 756 5 Safety and Risk i n Engineering Design Fig. 5.109 Determining the condi tions of a process of the duty of a single pump assembly, namely the halide pump no. 1, down to an evaluation of the failure mechanisms (or failure modes) such as ‘failure to open’, failure effects and causes associated with a control valve component. By the analysis of individual failure modes, the effect of each failure can be determined on the physical condition and operational functionality of the relevant systems hierarchy level, up to the consequence on the overall process. In preparation for establishing an expert system knowledge base pertaining to the diagnostics of equipment condition, the FMEA is performedin several steps, which are as follows: • Identify the relevant hierarchical levels, and define systems and equipment. • Establish ground rules and assumptions, i.e. operational phases. • Describe systems and equipment functions and associated functional blocks. • Identify and describe possible failure modes and their associated effects. • Determine the effect of each item’s failure for every possible failure mode. • Determine the consequence o f each item’s failure on system performance. • Determine the cause of each item’s failure for every possible failure mode. In this way, a knowledge base is built up of the conditions and constraints relating to failure characteristics and failure conditions. 5.4 Application Modelling of Safety and Risk in Engineering Design 757 Fig. 5. 110 Determining the failure effect on a process The advantages of performing a design-level failure modes and effects analysis (FMEA) in building up an equipmen t condition knowledge base include: identifi- cation of potential design-related failure modes at system/sub-system/component level; identification of impor tant characteristics of a given design; documentation of the rationale for design changes to guide the development of future designs; help in the design requirement objective evaluation; assessment of design alternatives during the preliminary and detail phases of the engineering design process; and es- tablishing priority for design improvement actions during the preliminary design phase. Furthermore, a design-level FMEA is a systematic approach to reduce risk and criticality, when the FMEA is extended to classify each potential failure effect according to its severity and consequence o f failure on the system as a whole, in asystems-levelfailure mode effects and criticality analysis (FMECA). The risk of common failure mode is influenced by stress and time. As both stress and the time-at-stress increase, the risk increases. The point of maximum common failure mode risk occurs when both stress and time are at a maximum. However,this risk cannot be evaluated by either reliability analysis or high-stress exposure tests alone, and it becomes necessary to review design criteria conditions to evaluate risk in a design-level FMEA. The intention of this type of FMEA is to validate the 758 5 Safety and Risk i n Engineering Design Fig. 5.111 Determining the risk of failure on a process design parameters chosen for a specified functional performance requirement where the risk of commo n failure mode is at a maximum. The risk evaluation of the common failure mode ‘fail to open’, associated with the example control valve, is illustrated in Fig. 5.111. Several risk categories are shown, specifically: a risk rating (value of 6 out of 10); a risk classification of a low risk value of MC–MHR (medium cost, and medium to high production risk); the grouping of the common failure mode risk into a risk category (medium criticality). Thus, for making an assessment of equipment criticality, particularly at the com- ponent level, the p riority for a component failure mode is calculated using three factors: • Failure effect severity. • Failure consequence likelihood. • Failure mode occurrence probability. Figure 5.112 illustrates the further development of an expert system knowledge base pertaining to the diagnostics of equipment condition, with the inclusion of determin- ing the criticality of failure on a process. The objective of criticality assessment is to prioritise the failure modes identified during the FMEA on the basis of the severity 5.4 Application Modelling of Safety and Risk in Engineering Design 759 Fig. 5. 112 Determining the criticality of consequences of failure of their effects and consequences, and the likelihood of occurrence, i.e. the risk, as well as the estimated failure rate. The assessment of decision logic in design problem solutions is to determine the required operating, maintenance and logistic strategies based on specific criteria related to system and equipment specifications, such as equipment techni- cal specifications, process functional specifications, operating specifications, equip- ment function specifications, failure characteristics and failure conditions, equip- ment fault diagnostics, equipment criticality, equipment performance measures, operating and maintenance tasks, operating procedures, maintenance procedures, process cost models, critical spares, and spares logistic requirements. Figure 5.113 illustrates decision logic assessment questions for building up a knowledge base of design problems pertaining to process functio nality (cf. Fig. 5.96) and to design p arameters (cf. Fig. 5.97). These questions serve to define the rules in a rule-based expert system. The questions are multiple-c hoice entries that are typically text and can contain several values. As an aid to the de- cision logic assessment, the FMECA results of the component under scrutiny are displayed. Applying AI methodology to engineering design Aside from the use of in- telligence in system components, there has been significant p rogress in its use 760 5 Safety and Risk i n Engineering Design Fig. 5.113 Assessment of design problem decision logic during design and evaluation of safety-related systems. Intelligent systems provide the safety engineer with valuable knowledge-based tools; the use of expert systems for verification and validation, or for use in FMEA studies, are typical examples. However, some deterministic systems have become so complex and sensitive to triv- ial input changes that complete analysis becomes a virtual impossibility. AI cansup- port this process by p roviding experiential analysis of the system outputs, thereby eliminating false logical paths and reducing the amount of analysis required. There is also a move towards analysis whereby only a system’s interface performance is assessed against benchmarks provided by an ‘acceptable’ system. Figure 5.114 illustrates the options selectio n menu with ‘expert systems’ high- lighted, which appears by clicking on a selected PEM in the PFD. This accesses the internal AIB blackboard knowledge-based expert systems. A facts frame is a structure that represents a concept in knowledge-based expert systems. It can have any number of attributes or properties attached to it, some of which can be relationships. An attribute may have any number of values (i.e. no value, one value, several values, etc.). The types of relationships among frames include hierarchical, classification relations, time precedence, and resource depen- dent. The importance of b eing able to represent relations is that a given frame can inherit properties (attributes and/or values) from the frames to which it is related. 5.4 Application Modelling of Safety and Risk in Engineering Design 761 Fig. 5. 114 AIB blackboard knowledge-based expert systems Facts frames are a convenient and natural way to represent d escriptive informa- tion, related objects, their properties and their relationships. They also represent the information carried in hierarchically structured domains. Relationship frames con- tain a number of slots representing attributes or relationships with the relevant ques- tions, topic, class, problem statement and solution hypotheses relating to functions, conditions and consequences, as illustrated in Fig. 5.115. These frames represent the knowledge-based information of the design integrity of the equipment. Frames are also known as schemata and scripts, and are abstractions of semantic network knowledge representation. As a result, frames are effective in expectation- driven processing, a technique often used in architecture and engineering design, where a knowledge-based expert system looks for expected data, based on context. Frames may inherit information from other frames. Frames are similar to forms that have a title (frame name) and a number of slots (frame slots) that accept only predetermineddata types. Acollection of nodesand links, or slots, together describe an object or event. A frame is thus a format for expressing declarative knowledge, in which an ob- ject is represented by a data structure containing a number of slots (representing attributes or relationships of the object), with each slot filled with one or more val- ues (representing specific values or relevant questions of attributes or other objects 762 5 Safety and Risk i n Engineering Design Fig. 5.115 Knowledge base facts frame in the AIB blackboard that the object is re lated to). Figure 5.116 illustrates a typical frame slot representing attributes or relationships with relevant questions pertaining only to condition. The system/assembly/component selection capability of a system breakdown structure (SBS) relates hierarchical systems data to a particular hierarchical frame. Hierarchical frames provide the means to efficiently represent certain types of data that have a hierarchical structure, such as engineering systems. Hierarchical frames allow for complex search criteria with Boolean operators in design optimisation. The data in such a frame can be read or updated by the expert system. These frames provide inheritan ce that allows a hierarchical set of frames to be created with data in ‘parent’ frames available to lower-level frames. The use of hierarchical frames provides a means for the AIB blackboard to manage hierarchically related data that are portable and maintainable in multiple expert systems. Figure 5.117 illustrates the system breakdown structure (SBS) tab as part of a set of tabs (references, facts, functions, conditions, consequences, rules and goals) that contain various instructions in accessing data from the expert system knowledge database for application in an expert system user interface. The AIB blackboard provides flexible use of multiple expert systems, and other knowledge source applications, to store and retrieve data for use by multi-disciplin- ary groups of design engineers in a collaborative design environment. The data are 5.4 Application Modelling of Safety and Risk in Engineering Design 763 Fig. 5. 116 Knowledge base conditions frame slot shared among multiple knowledge-based expert systems as well as other knowledge sources. A set of blackboard commands enables designers to access specific frames to read or write design data to the blackboard. The blackboard files can be jointly read or created by the knowledge-based expert systems that automatically identify inappropriate design data or conflicting design specifications. Figure 5.118 illustrates the ‘goals’ option tab of the imbedded ExSys c  Expert System (ExSys 2000). Goals are the design criteria among which the expert sys- tems will decide. An expert system is required to find solutions to a design problem subject to design criteria. A goal may be assigned a confidence value to determine its relative likelihood. Goals can be used only in the THEN part of trees, which are considered later. Factors are text or numeric data items that are used to d efine the rules in a rule- based expert system (or the nodes of a decision tree). There are two types of factors: ‘questions’ and ‘variables’. Questions are multiple- c hoice lists that are typically text and can contain several values. A question condition is a statement in the rule (or tree) made up of the starting question text and several associated choices. Questions can be used in the IF part of a rule to test a value, or in the THEN part to assign avalue. . identified during the FMEA on the basis of the severity 5.4 Application Modelling of Safety and Risk in Engineering Design 759 Fig. 5. 112 Determining the criticality of consequences of failure of their. the design requirement objective evaluation; assessment of design alternatives during the preliminary and detail phases of the engineering design process; and es- tablishing priority for design. the conditions and constraints relating to failure characteristics and failure conditions. 5.4 Application Modelling of Safety and Risk in Engineering Design 757 Fig. 5. 110 Determining the failure