764 5 Safety and Risk i n Engineering Design Fig. 5.117 Knowledge base hierarchical data frame Figure 5.119 illustrates the ‘questions’ option tab of the imbedded E xSys c  Ex- pert System (ExSys 2000). In the illustration, one question relates to temperature, which refers to the expert system goal and is a design criteria constraint. Another question relates to a pressure constraint, where both constraints need to be consid- ered concurrently, as the one impacts upon the other in a particular system design. Figure 5.120 illustrates a multiple-choice question editor for application in the rule-based expert system. The multiple-choice question editor is used in establishing lists for questions relating to both temperature and pressure for application in the same rule-based expert system. The values of these variables are divided into ranges defined by the logical break points in the decision-making process (i.e. too low, within or exceeding specification, too high or critical). Variables are both numeric or string variables, including expressions, parenthe- sis, Boolean operators, trig functions and exponential functions. A numeric variable may have any value between its upper and lower bounds. For the purposes of defin- ing IF–THEN expert system rules, the value of the variable is divided into ranges defined by the logical break points in the decision-making process. For example, an IF part test expression might be the rule: IF (([X]<[Z]) AND (SIN([X]/2)>0.4)). The more standard MIN, MAX conditionalassignment operatorsare also supported, as well as an approximately equal operator to handle round-off error problems. 5.4 Application Modelling of Safety and Risk in Engineering Design 765 Fig. 5. 118 The Expert System blackboard and goals A tree,orbranched decision tree, represents all or a portion of the decision- making instructions for input into a particular design scenario. Tree representation can be used for any design problem that involves a selection from among a definable group of goals (design criteria), where the decision is based on logical steps that can be described as a set of tree diagrams. The trees can involve relative probabilities of a goal being correct. Trees can also be used to derive data needed by other trees or rules. Individualrules are added to represent specific facts that cannot be represented as trees (usually rules requiring an ELSE part, or specific facts that are not part of an overall structure of information). Figure 5.121 illustrates the ‘trees’ option tab of the imbedded ExSy s c  Expert System (ExSys 2000). The branched decision tree in the illustration relates to a pro- cess adjustment for the design criteria constraint of temperature for establishing decision-making instructions as input into a particular design scenario. A branched decision tree is made up of nodes that represent decision branch points, and those that are assignments of value, as illustrated in Fig. 5.122. These correspond to IF and THEN conditions in a rule. The IF node has two or more values that are joined together in a blo ck. The node values can be multiple-choice text items, ranges of a numeric variable or true/false tests of a math ematical expres- sion. THEN nodes have a single value and assign a value to the goal of the expert 766 5 Safety and Risk in Engineering Design Fig. 5.119 Expert System questions factor—temperature system, assign text or numeric data, or annotate the tree. Trees can assign values in their THEN part. If other tree nodes require these choices, the appropriate rules will automatically be called through backward chaining. The ability to add nodes or automatically expand the tree, to consider all pos- sible combinations of input, allows rules to be built very rapidly. The designer is prompted to consider all possible cases, which guarantees system completeness. In most applications there would be multiple trees, each representing a different aspect of the decision-making process. Knowledge-based expert systems deal with knowledge, rather than data, and the files they use are often referred to as knowledge bases. This knowledge is repre- sented as rules, as illustrated in Fig. 5.123. A rule is made up of a list of IF condi- tions (normal semantic sentences or algebraic expressions that can be tested to be TRUE or FALSE), and a list of THEN conditions (also semantic sentences or alge- braic expressions) or statements about the probability of whether a particular value is the appropriate solution to the design problem. If the expert system determines that all IF conditions in a rule are true, it adds the rule’s THEN conditions to what it knows to be true. The ability of an expert system to derive information, rather than prompting the user, enables the expert system to combine many small pieces of knowledgeto arrive 5.4 Application Modelling of Safety and Risk in Engineering Design 767 Fig. 5. 120 Expert System multiple-choice question editor at logical conclusions about complex problems. In this way, the expert system can manage the rules in a knowledgebase from the pointof view of conflicting meanings or values. Although the use of decision trees are an ideal way to rapidly develop most systems, the logic of some complex systems cannot be described as trees. These systems require that individual rules be defined. A rule editor is provided for th is ability. The expert system’s rule editor is a powerful and flexible tool for knowledge- based expert system development, and enables the designer to rapidly write rules using the same data elements as the trees. As each rule is input, it is compiled to the knowledge base. This means that the rule editor has access to the logic of the rules already entered. Thus, if a rule is potentially in conflict with an existing rule, the editor will immediately highlight the conflict and give the designer the opportunity to correct it. Figure 5.124 illustrates the rule editor of the imbedded ExSys c  Expert System (ExSys 2000). Rules entered in an editor window are divided into three main parts: an IF part, a THEN part, an optional ELSE part, with an optional NOTE, and an optional REFERENCE. 768 5 Safety and Risk in Engineering Design Fig. 5.121 Expert System branched decision tree The basic structure of a rule has the following format: IF – conditions THEN – conditions and goals ELSE – conditions and goals. The IF part is simply a series of tests, expressed as semantic sentences or algebraic expressions. The IF conditionsare tested against the data provided by the knowledge base, information that can be derived from other rules, or data obtained from other knowledge sources. In the IF part, the tests can be combined with either AND or OR. Boolean operators can also be used to build complex logical tests. The THEN part can contain conditions similar to those of the IF part. However, in the THEN part, they are not tests but statements of fact. In the IF part, a statement would be a test that might be true or false. The same statement in the THEN part would be considered to be a valid fact, if the IF conditions in the rule were true. When the IF conditions in a rule are determined to be true, the expert system as- sumes the THEN part is true and adds any facts in the THEN conditions to what it knows. The THEN part can also contain the possible goals that the expert system will decide among, along with their assigned p robability values. The expert system keeps track of the value each goal receives, and calculates a final confidence value 5.4 Application Modelling of Safety and Risk in Engineering Design 769 Fig. 5. 122 Expert System branched decision tree: nodes for each of the choices. The THEN conditions may also include statements that assign a value to a numeric or string variable. This allows values to be calculated during a run and displayed at the end. The ELSE part is the same as the THEN p art and is applied if any of the IF conditions are FALSE. The ELSE part is optional and not needed in most rules. (Rules built in tree structures have only IF and THEN parts.) In some cases, it is d esirable to add a NOTE to a rule to provide some special information to the knowledge base. If there is a NOTE added, it will be displayed with the rule. The NOTES from rules that fired (i.e. are activated) can also be applied as information output, using the reportgenerator.The expert system knowledge base may also include a REFERENCE for a rule. This is intended to assist in finding the source of the knowledge contained within a rule, or for more information relating to the rule. As with the NOTE, the REFERENCE is optional and only for containing information. It has no effect on the running of the program. The difference between the NOTE an d the REFERENCE is that the NOTE is displayed whenever the rule is displayed. The REFERENCE is displayed only if it is requested. The REFERENCES from rules that fired can also be applied as output using the report g enerator. Both NOTE and REFERENCE elements can contain 770 5 Safety and Risk in Engineering Design Fig. 5.123 Expert System rules of the knowledge base links to other blackboards, which is useful to display different parts of a complex design. Backward chaining is a term used to describe running the rules in a goal-driven manner.In backwardchaining, if an item of informationis needed, the expertsystem will automatically check all of the rules to see if there is a ru le that could provide the needed information. The system will then ‘chain’ to this new rule before completing the first rule. This new rule may require information that can be found in yet another rule. The expert system will then again automatically test this new rule. The logical reasoning of why the information is needed goes backwards through the chain of rules. The called rules can be anywhere in the expert system. It is not necessary to specify which rules apply to which information. Backward chaining simplifies the development of the expert system. Each rule can simply state an individual fact. Unlike some expert system models, the relationshipsbetween rules do not have to be explicitly assigned in the blackboard. Expert systems incorporated in theblackboard will automatically find the relevant rules and use these. In a backward chaining system, the rules can be in any o rder. As new facts are added to the design, rules are simply added and the expert system will automatically determine when and how to use the new items of information. 5.4 Application Modelling of Safety and Risk in Engineering Design 771 Fig. 5. 124 Expert System rule editor Forward chaining is a data-driven method of running the rules (unlike the goal- driven approach of backward chaining), and is an alternative to backward chaining. In backward chaining, there is always a goal to be satisfied and a specific reason why rules are tested. In pure forward chaining, rules are simply tested in the order they occur based on available data. If information is needed, other rules are not invoked— instead, the designer is asked for the information. Consequently, forward chaining systems are more dependent on rule order. However, since time is not spent deter- mining if information can be derived from other rules, forward chaining is much faster. The blackboard expert system also provides a hybrid between backward and forward chaining, where the basic approach is data-driven but information needed by rules is derived through backward chaining. Another technique is to divide an expert system into subsets of rules and run some in forward chaining and some in backward chaining with procedural command language. Testing and validating a knowledge-based expert system must be a major part of any expert system development project. It is important to make sure that end users will get valid answers to any input. The automatic validation function greatly simplifies and automates this process. The expert system automatically tests the design application, unattended, for a variety of errors. There are two methods of validation testing, namely systematic and random testing. Systematic testing allows 772 5 Safety and Risk in Engineering Design Fig. 5.125 Testing and validating Expert System rules all possible combinations of input to be tested for a variety of possible errors. If the expert system is very large and systematic testing of the entire system would take too long, testing of portions of the system, or random testing of the entire system, can be performed. The blackboard system has built-in functions to automatically validate a particular design application, and to check for a variety of common errors. Figure 5.125 illustrates the validation test facility of the imbedded ExSys c  Ex- pert System (ExSys 2000). A validation test run is illustrated of the example HIPS system with specific temperature and pressure design constraints. Confidence methods for managing uncertain data The AIB blackboard expert system provides several ways to manage uncertain data, and the confidence or prob- ability factors within each expert system. The different systems are designed to pro- vide a range from simple and intuitive confidence systems, to complex methods of assessing and evaluating confidence. These confidence methods are: YES/NO system If the system does not require any estimate of probability, the YES/NO (0/1) system is the easiest to apply. This confidence system is very easy to use, since the first rule that fires for a choice sets the value to 1 for ‘yes’, or 0 for ‘no’. No intermediate values are assigned. This confidence system is good for selecting choices from a list, an automated questionnaire, or other systems where the choices used by such systems are ‘yes’ or ‘no’. 5.4 Application Modelling of Safety and Risk in Engineering Design 773 0–10 system The 0–10 system provides confidence values on a scale of 0–10. This is often quite compatible with the intuitive knowledge used in the development of an expert system. A value of 0 locks the value for the goal at 0 (no—not possible) and a value of 10 locks the valuefor the goal at 10 (yes—definitelyselected). Confidence values between 1 and 9 are averaged to give a relative likelihood. This system can positively select or reject a goal (with a value of 10 or 0) but can also allow intermediate values to indicate goals that may also be appropriate. When obtaining a designer’s intuitive recommendation in an event, a 0–10 scale is often easy to use. Unless valid statistical data are available, precision higher than 0–10 is difficult to obtain from intuitive knowledge, especially for conceptual de- sign. Despite its simplistic calculations, the 0–10 system is quite suitable for many expert systems and has been used to build thousands of real-world applications. –100 to 100 system Values can be assigned to goals in the range of −100 to 100. This provides greater resolution than the 0–10 system. However, there is no value that locks the value at ‘yes’ or ‘no’, and values of 0, 100 and −100 are treated like any other value. There are three methods of combining the confidence values— average, depende nt probabilities, or independent probabilities. The system is effec- tive if the nature of the problem requires that the confidence factors be combined as dependent or independent probabilities. Fuzzy logic is a very powerful technique that enables the expert systems to ma- nipulate imprecise data (i.e. the temperature is too high) and more closely reflect the real world. In the fuzzy logic confidence mode, fuzzy membership functions are defined that assign confidence to items based on the value o f a variable. These confidence values are propagated through the rules to the confidence assigned to the goals. Specific values can be defuzzified out of the results, to have the expert system give precise recommendations. Figure 5.126 illustrates the ap plication of f uzzy logic for managing uncertainty concerning the d esign constraint of temperature, and can similarly be done for the pressure design constraint. The fuzzy membership functions are representedby a tri- angular distribution mapping (t-norm), established by input of membership func- tions against specific confidence levels. The resulting rules developed with fuzzy logic inference are similar in construct to Fig. 5.124, except with < or  notation. Plant analysis, with specific reference to the integrity of engineering design, fo- cuses on equipment functional failure, their causes and effects, and the overall con- sequences that affect safety, operations, quality and the environment. It includes the identification of critical equipment with regard to safety, risk, operations down- time, product quality and environmental impact, as well as costs of downtime. The outcome of plant analysis determines maintenance procedures, plant isolation pro- cedures (with the establishment of statutory requirements), plant shutdown proce- dures (shutdown and start-up), standard work instructions, maintenance and oper- ating resource requirements, and logistical spares requirements, for the effective care of plant and equipment to ensure safety, operational performance, production output, product quality and environmental protection. Figure 5.127 illustrates the plant analysis functional overview option in the AIB blackboard. It also provides . are two methods of validation testing, namely systematic and random testing. Systematic testing allows 772 5 Safety and Risk in Engineering Design Fig. 5.125 Testing and validating Expert System. the design, rules are simply added and the expert system will automatically determine when and how to use the new items of information. 5.4 Application Modelling of Safety and Risk in Engineering. Modelling of Safety and Risk in Engineering Design 765 Fig. 5. 118 The Expert System blackboard and goals A tree,orbranched decision tree, represents all or a portion of the decision- making instructions