The di-agnostics inference engine contains diagnostic charts and queries relating to failure characteristics, failure conditions, equipment criticality, performance measures, and operati
Trang 1754 5 Safety and Risk in Engineering Design
Fig 5.107 ANN NeuralExpert network complexity
(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 equipassess-ment 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 user (designer)
asks structured questions until the expert system has reached an optimal solution in
Trang 25.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 equipment 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
Trang 3756 5 Safety and Risk in Engineering Design
Fig 5.109 Determining the conditions 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 performed in 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 of 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
Trang 45.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 equipment condition knowledge base include:
identifi-cation of potential design-related failure modes at system/sub-system/component level; identification of important 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 of failure on the system as a whole, in
a systems-level failure 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
Trang 5758 5 Safety and Risk in 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 common 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 priority for a comcom-ponent 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
Trang 65.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, ment function specifications, failure characteristics and failure conditions, equip-ment fault diagnostics, equipequip-ment criticality, equipequip-ment 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 functionality (cf Fig 5.96) and to design parameters (cf Fig 5.97) These questions serve to
define the rules in a rule-based expert system The questions are multiple-choice
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 progress in its use
Trang 7760 5 Safety and Risk in 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 can sup-port this process by providing 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 selection 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 being able to represent relations is that a given frame can inherit properties (attributes and/or values) from the frames to which it is related
Trang 85.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 descriptive 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 funcques-tions, 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
predetermined data types A collection of nodes and 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 valval-ues or relevant qval-uestions of attributes or other objects
Trang 9762 5 Safety and Risk in Engineering Design
Fig 5.115 Knowledge base facts frame in the AIB blackboard
that the object is related 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 inheritance 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
Trang 105.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 ExSysc 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 define 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-choice 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 a value.