- Email: [email protected]
Knowledge-based safety training system (KBSTS)— A prototype implementation
COMPUTERSIN INDUSTRY ELSEVIER
Computers in Industry 25 (1994) 145-157
Knowledge-Based Safety Training System (KBSTS) A prototype implementation V. S h a n k a r a r a m a n ~'* B.S. L e e b ~'Department of Computer Studies, Napier Uniuersity, 219 Colinton Road, Edinburgh EH14 1DJ, UK b University of Strathclyde, Glasgow, UK Received 18 October 1993; accepted in revised form 15 August 1994
Abstract
A computer-based safety training system for process operators must be able to make effective presentation of textual material, test the trainee's understanding through quizzes and facilitate plant simulation. The general framework of such a system is presented in an earlier paper (Computers in Industry, Vol. 17, 1991, pp. 349-358). In this paper, we discuss the development and implementation of a prototype Knowledge-Based Safety Training System based on the framework. The design philosophy, system architecture and the plant modelling methodology are described.
Keywords." Process operator safety training; Knowledge-based system; Hypertext; Qualitative plant simulation
1. Introduction
Safety training is one of the important functions of safety management. The aim of such training is to increase self awareness, impart knowledge and skills and increase motivation. Within the offshore industry a number of safety training methods have been used which include non-formal methods, formal instruction, interactive videos, practical sessions and computer-based methods. Each of these methods has its own limitations and capabilities as to the type and extent of knowledge and skill they can impart [1]. In general, safety knowledge comprises a number of different elements, such as description,
* Corresponding author.
procedure, concepts and principles. In particular, the knowledge required by a process plant operator includes process understanding, plant layout and component functions. Additional knowledge is required to handle abnormal situations which includes component fault states and fault propagation through the plant. For proper acquisition of this knowledge it must be read, understood and memorised and, above all, practical experience on a simulated plant model is imperative. The training system must be able, therefore, to make effective presentation of textual material, test the trainee's understanding through quizzes and facilitate plant simulation. A number of training strategies or lesson styles are, therefore, required to impart effectively the safety knowledge required by a process operator. The integration of expert system and hypertext
0166-3615/94/$07.00 © 1994 Elsevier Science B.V. All rights reserved SSDI 0 1 6 6 - 3 6 1 5 ( 9 4 ) 0 0 0 2 2 - 0
146
K Shankararaman, B.S. Lee / Computers in Industry 25 (1994) 145-157
within a computer-based training system facilitates this approach. The general framework of a K n o w l e d g e - B a s e d Safety T r a i n i n g System (KBSTS) based on this philosophy has been formalised, see for example [1]. In this paper the prototype KBSTS developed and implemented based on this framework is described. The prototype uses a qualitative simulation of the plant system. It allows the instructor to develop both the plant models and the training lessons without the need for any programming. The design philosophy behind the development is discussed, followed by the selection of a suitable development tool for the prototype. The functional elements of the prototype KBSTS and the modelling methodology are then described, Two sample screens are presented to highlight the facilities of the training system.
Table 2 Tasks taxonomy Tasks
Command or menu options Authoring mode
Fuloring mode
File management
Create, Load, Quil. Save
lx)ad, Quit, Save
Drawing functions
Line, Ellipse, Circle. etc.
Not required
Editing
Undo, Delete, Insert. Move, Copy, etc.
Not required
Plant model status monitoring
Check (check state i Stboard (display stale of all components)
( iheck. Stboard
Activationof plant model
Action (open or close a valve) Sim (start simulationi
Action,Sire
Others
Lesson (develop a lesson) Itelp, Describe
i,esscm tusc a lesson) Help, Describe
2. Design philosophy The design of the training system is based on a number of principal aspects as follows: 2.1. Interaction modes
The chosen approach consists of two different users: the training instructor and the trainee. Each of them can interact with the KBSTS depending on their intentions as shown in Table 1. From the table it is clear that the intentions of both users is distinctly different and, therefore, it is essential to have two different modes, viz. the authoring mode and the training mode,
Table 1 Interaction intentions Mode User Authoring
Author (training instructor)
Tutoring
Trainee
Intentions Develop plant models and training lessons Observe and understand plant models through using the training lessons
2.2. Interaction interface
The interaction of both the author and the trainee with the KBSTS belongs to the domain of u s e r - c o m p u t e r interaction. The aim of the design of a h u m a n - c o m p u t e r interface is to increase the usability of the training software. The usability of the software is a measure of the speed and accuracy with which the author and trainee can perform their functions with it. Referring back to the interaction modes, the taxonomy of tasks for the two modes, developed on a similar basis to [2], is shown in Table 2. The types of interaction which can be found in current software are: command language, menu selection, direct manipulation and natural language. Interviews with the training instructors from several oil companies have shown that menu selection and direct manipulation methods are the most appropriate means of interaction. However, it was found necessary to have some data input through typing (particularly in the authoring mode). The command language and natural language methods were discarded, based on the argument
ld Shankararaman, B.S. Lee/Computers in Industry 25 (1994) 145-157
that the author and, in particular, the trainee are easily put off by computer-based training systems that involve a lot of keyboard typing. Further, the mouse was selected as the main means of interaction between the user and the plant model. For example, selecting a particular choice from the menu and clicking on the component causes the component property to change (e.g. pump state changes from 'on' to 'off'). Such an interface is known to increase trainee's motivation and also enable him to spend more time on understanding the plant model rather than the use of the software. However, some of the final issues on the interface design and implementation are limited by the choice of hardware and software. 2.3. Shell-based approach
The principal aim of providing the authoring mode is to enable the training instructor to develop plant models and training lessons. This can be achieved by providing a kind of authoring language with which specific plant models and courseware can be programmed. This has the obvious attraction in that the system itself will be relatively simple, whilst allowing much flexibility. However, this approach calls for programming skills on the part of the instructors, and any modification to the plant model or the courseware will be rather difficult. These drawbacks were the main reasons which have greatly retarded the use of such simulation-based software within the oil industry. In view of this, it was decided that the KBSTS should be a shell with a powerful authoring system which does not call for any programming. The authoring system was designed so that a number of desirable qualities could be made possible as follows: - The author should be able to define the plant model and the training lessons by interacting with the system by using menus, a mouse pointer and keyboard input where necessary. - The inference mechanism for simulating the plant model should be built into the training system as general knowledge. - The knowledge acquisition process should be structured in such a way that the author is able
147
to obtain a better understanding of the process plant as it is being modelled. - In order to make modification and update of the plant models easier still, the knowledge bases should be partitioned into general and specific knowledge. However, it is very difficult to develop a general purpose shell that could encompass all possible components used in process plants. Even though it may be possible to develop qualitative component models for all the different components, the general knowledge specifying their interaction becomes enormous and cumbersome to handle. A possible solution is to classify components into local groups and model the interaction for that particular group. In this case, general knowledge pertaining to the interaction between the various groups may be defined. For the sake of simplicity in developing the prototype, only components pertaining to one such group are modelled, i.e. the flow system. The components in this group include reservoir tanks, valves, pumps, indicators and flow elements. 2.4. Simplified trainee model
No effective training is possible without certain understanding of the trainee. In formal training methods this is achieved by the human tutor. Within the computerised training environment, the trainee is represented by a model, often referred to as the trainee or student model. Most conventional CBT systems have a very shallow trainee model in the form of pre-defined control structures. For example, the next module to be presented to the student may depend on his answers to the questions posed in the current module. The next generation of computer tutors, or the so-called intelligent tutors, use deeper trainee models. Such deeper models enable a dynamic representation of the state of the student's knowledge on the subject being taught. They are then used to assess the trainee's understanding and misconceptions of the subject, and determine which material to present next, which to recapitulate, how to fix the misconceptions (or bugs) and so on. The main advantage of using these deep models is that they enhance the edu-
148
~ Shankararaman, B.S. Lee~Computers in Industry 25 (1994) 145-157
cational effectiveness of the tutoring process. However, their application is inhibited due to the following main drawbacks - Developing deep models is computationally intensive, particularly for domain-independent applications. - Development of deep models calls for support from cognitive psychologists. - A survey of existing intelligent tutoring systems using deep models reveals that they are practicable in only specific domains (e.g. S O P H I E I, II, III in the domain of electronic trouble shooting [3], W H Y in the domain of rainfall [4], etc.) and a general purpose student model is far from reality. In view of the above drawbacks, the trainee model implemented in the prototype training system takes a mid-stance between the shallow and deep models.
3. Selection o f the d e v e l o p m e n t tool
3.1. Hardware selection A number of hardware options ranging from IRIS workstations, main frames and personal computers were examined. Finally, it was decided to develop and implement the prototype KBSTS on a personal computer compatible with IBM PC. This choice of hardware was based on the following reasons:
Portability One of the areas of possible application of the KBSTS is on-site training on platforms where the supervisors can themselves develop the plant models and corresponding training lessons. MSDOS computers are easily compatible with each other and are easily installed.
Display capability The display features of the hardware have a very notable effect on capturing the trainee's attention and stimulating motivation. Even though the PC may not offer the best display features, the graphics facilities are reasonably good and sufficient for developing the prototype IzJ3STS.
Cost The cost of the KBSTS depends naturally on the hardware on which it is to be implemented. Using a PC-based system has a direct effect in reducing the initial cost compared to the workstations or main frames.
3.2. Software selection Since the hardware choice was a PC, only software tools applicable to PCs were evaluated, the following three main approaches were examined
(i) Expert system shells Using Yazadani's analogy [5], shells are like pre-built houses, where you need to choose the one most suitable to your needs. Shells offer a simple way of representing knowledge (both production rules and frames) and usually have a fixed inference strategy for controlling the reasoning process. A number of PC-based shells were considered (e.g, Leonardo, Crystal, Xi Plus and Nexpert Object). In general these shells impose a design methodology that is not suited for the problem, namely, developing the training system based on plant models. Another serious limitation is that the shells determine a user interface which is not very suitable for the training system.
(ii) Tool kits Tool kits are like prefabricated house parts from which you can build your house. They provide less ready-made solutions and consequently more possibilities for developing a knowledgebased system. They offer a number of representation methods and control mechanisms. The versatility and flexibility offered is, however, limited by the large computing resources required as evidenced by the fact that most tool kits run on workstations. Since the choice of hardware was already made to be a PC, the tool kits were not considered any further.
(iii) Programming languages The final choice was to select a suitable programming language. They are like general building materials which are more flexible and offer a
149
v. Shankararaman, B.S. Lee/Computers in Industry 25 (1994) 145-157
greater room for creativity. Procedural languages such as Fortran, Basic, Pascal, C, etc. usually need more time to program a knowledge-based software than compared to symbolic languages such as Lisp and Prolog. Further, gaining from past experience in using Prolog for a tutoring system within the Marine Technology Centre [6], it was decided to implement the prototype training system using LPA Prolog Ver 3.0 [7].
4. S y s t e m d e s c r i p t i o n
The general architecture of the training system is shown in Fig. 1. The training system is divided into the Authoring Module and the Training Module, each corresponding to their respective modes. The author can access the authoring manager through the authoring interface and by this means create a compiled knowledge base. The two-way arrow between the authoring manager and the compiled knowledge base suggests that the author can always edit or modify an existing
AUTHORING MODULE
TRAINING MODULE _~
TRAINING MANAGER
AUTHORING MANAGER
I l
I l
TRAINEE n~'gRFACE
AUTHOR INTERFACE
T
l
TRAINEE
AUTHOR
COMPILED KB PLANT MODEL
LESSONS
T GENERAL KNOWLEDGE Fig. 1. KBSTS architecture.
COMPONENT ~ MODELS
T
PLANT FLOWSIIEET
T
GENERAL KNOWLEDGE MODEL BUILDER
Fig. 2. Authoring module. (1) Model instantiation: (2) linkage; (3) lesson modelling.
knowledge base and then recompile it. The training manager uses the compiled knowledge base to tutor the trainee. The trainee can access the training manager through the trainee interface. The compiled knowledge base itself consists of a specific plant model along with the training lessons pertaining to that plant model. Besides this compiled knowledge, there is also an underlying general knowledge (e.g. schema to propagate the faults in the pipe elements) to guide the tutoring. Due to time constraint, it was decided that this general knowledge should be implemented at the source code level in Prolog. 4.1. Authoring module
Fig. 2 gives a finer description of the two functional elements within the authoring module: the model builder and the lesson builder. (i) Model builder The model builder assists the author in creating and maintaining the qualitative models of the process plant. This is achieved through the following five steps: - create icons for components and store them in an icon library; - load and position icons; - define component specifications for each icon; - link the component models using pipe or cable elements; - compile the flowsheet knowledge base. (ii) Lesson builder This functional element of the authoring module assists the author to develop lessons based on the compiled plant knowledge base (KB). A num-
150
V. Shankararaman, B.S. Lee/Computers in Industry 25 (1994) 145-157
bet of lessons may be developed for each plant model. In general, these lessons may be of the following types: Topics, Functions, Modes and Fault diagnosis. The lesson type 'Topics' is used to impart the theoretical knowledge on the concepts and principles pertaining to safe operation of the plant. It can be compared to an electronic book, where the trainee can move from one page to another or from one topic to another, by pressing a key button. The modelling of this lesson type is based on the hypertext approach. The lesson type 'Functions' enables the trainee to understand the layout of the plant and the functional significance of each component within the plant. The lesson type 'Modes' allows the trainee to understand and practise the various procedures for a particular mode of operation of the plant. These modes can be either operating modes, such as start up, shut down, etc., or emergency modes, such as emergency shut down. For each mode the instructor is required to give an introduction, define the goal(s) to be achieved and execute a set of procedures. In 'Fault diagnosis' a random fault is generated by the system and the trainee is required to identify the fault. It is also possible for the trainee to set a fault intentionally and observe the effects on the plant model.
4.2. Training module During the training session, the training module consults the compiled plant knowledge base and the lessons developed. The trainee interacts with the module by using a mouse pointer. The main functional elements of the training module are shown in Fig. 3. It comprises the qualitative reasoner, trainee model and the dialogue generator. The actual functioning of these elements depend on the particular lesson type being learnt in operation.
(i) Qualitative reasoner (QR) The qualitative reasoner is used only for the 'Modes' and 'Fault diagnosis' lesson types. It is responsible for running the qualitative simulation
l "~°N~'R I i Fig. 3. Training module
of the plant model. If any abnormality is observed in the plant model during the simulation, an 'abnormal' flag is set and the training system proceeds to identify the cause for the abnormality and then propagates its consequence (fault propagation) through the entire plant model. If no abnormality is observed, then a 'normal' flag is set.
(ii) Trainee model (TM) As mentioned in the design philosophy, the trainee model is a compromise between shallow and deep models. The trainee model for the topics and functions is based on checking the correctness of the answers given by the trainee. That is, the answers of the trainee are compared with those of the instructor. For matching answers, a 'success' flag is set and for wrong answers a 'reteach' flag is set up. All the reteach flags are entered into the trainee file and later he is required to redo the respective questions. A reteach flag is permanently removed from the trainee file only if he is able to answer the erred question correctly. Unlike the above, the trainee modelling used for the teach session of lesson type 'Modes'. is implemented using the 'cognitive apprenticeship' training style. The trainee has to perform a randomly selected set of procedures and the modelling is based on the comparison of his definitions of actions and preconditions with those defined by the instructor. If the match is perfect, then a 'match' flag is set. Otherwise, the corresponding error is identified, which may be an incorrect action, improper priority or incorrect precondition. The trainee may then either ask to
v. Shankararaman, B.S. Lee/Computers in Industry 25 (1994) 145-157 be retaught or decide to repeat the action, precondition or the whole procedure depending on his error. In the perform session of lesson type 'Modes', the trainee modelling is mainly based on comparing the final goal(s) achieved by the trainee with those defined by the instructor. It is necessary to note that, in this case, less emphasis is laid on his actions which enable him to achieve the goal(s). If the trainee succeeds in achieving the goal(s) by using a different set of actions and preconditions to that defined by the instructor, his solution is entered into the trainee file for manual verification by the instructor. It is possible that the trainee has found a novel solution.
(iii) Dialogue generator (DG) The function of the dialogue generator is to generate the suitable dialogues for the trainee based on the flag set by the trainee model and the qualitative reasoner. This dialogue depends on the lesson type and can be a comment (e.g. 'your action is correct'), an answer (e.g. ' T h e answer is p l and not p2'), or a menu from which the trainee may select an option. Mostly, some parts of these dialogues are pre-stored and others obtained by variable bindings according to the situation. For example, in the answer 'The answer is pl and not p2', 'The answer is' and 'and not' are pre-stored and 'pl' and 'p2' are bound variables. In addition to the above, each lesson type has its own dialogue mechanism to present the lesson and examine the trainee's understanding.
5. Plant modelling The plant modelling is based on a qualitative approach. Qualitative reasoning forms a substantial part of our everyday experience. For example, based on a news report of high oil prices we anticipate an increase in petrol prices. The exact form of functional relations is not necessary to predict the direction of the price movement. A number of researchers have used qualitative reasoning for diverse reasoning tasks, such as simulating some processes [8-10], diagnosis [11], mod-
151
elling qualitative equations and states and deducing functionality of devices [12]. The main advantages of using qualitative plant models for a training system are as follows: - It helps the trainee to obtain a conceptual understanding of the plant without having to go into numerical details. - The methodical representation of information in such models makes them easier to understand and update than average rule-based systems or numerical models. - Such models offer more scope for explanation facilities, which is a vital characteristic for a training system. - Qualitative models can reason correctly even when no numerical values are available. - Furthermore, this approach is related to the Hazop analysis, where a model of the plant is used to study the way possible hazards can arise on the plant [13]. The four main steps involved in applying the qualitative approach to plant modelling within the KBSTS are as follows:
5.1. Component modelling The component forms one of the basic unit of the plant, the other being the linking element. The two main steps necessary to model the component are hierarchical definition and functional definition.
(i) Hierarchical definition In the component hierarchy, components are classified into different classes depending upon their behaviour and function (properties). This classification can be carried out at various levels depending on the type of components and the number of levels required. The hierarchy uses three main types, i.e. class, subclass and primitives. Class refers to the topmost node in the hierarchy. A class may contain one or more subclasses. A subclass in turn can contain one or more subclasses. Primitives are subclasses which do not have any child nodes (leaves of the tree structure). Fig. 4 shows a possible classification hierarchy for the component 'tank'. The hierarchies described above provide a
V. Shankararaman, B.S. Lee/Computers in Industry 25 (1994) 145-157
152
TANK
STORAGE
INFLOW
MIXING
CLASS
pump
SUBCLASS
all
STATE C H A N G E
:
i n s t r u c t o r and trainee
STATE DISPLAY
only state
W O R K I N G STATES :
on, off
FAULTY STATES
:
low output, high o u t p u t
INPUT-OUTPUT
:
OUTFLOW
Fig. 4. Hierarchy for the component 'tank'. For state 'on'
structure by which elements down in the hierarchy may inherit attributes from those higher in the hierarchy. For example, 'inflow tanks' inherit the properties of 'storage tanks' which in turn inherit the properties of the class 'tank'.
If inflow is low~ high or normal
(ii) Functional definition
Then outflow is nil, low a n d low
Then outflow is low, high or
normal
For state 'low o u t p u t ~ If inflow is low, n o r m a l or high
Having classified the components, the next step is to define the behaviour and functions (properties) of the components. In order to define the component functions a frame-based representation is used. A component frame is basically a structure for holding various types of knowledge associated with functioning of the component. The knowledge is stored in the various slots of the frame. A typical frame for a pump is shown in Fig. 5. The corresponding Prolog representation is shown in Fig. 6. The number and type of slots used in the frame are the same for different components, but the slot values differ between components.
Class definition. This slot allows the definition of the class to which the component belongs, e.g. the class slot value can be 'valve', 'pump', 'tank', etc.
Subclass definition. This slot allows the definition of the subclass hierarchy within the particular class. The subclass definition contains a trace through the hierarchy tree to the primitive, e.g. [storage,inflow] (see Fig. 4).
State change definition. This slot defines the possibility of changing the state of the component and the user (instructor or trainee) who can effect this change. States of some components cannot be changed, e.g. the
For all s t a t e s If inflow is nil Then outflow is nil Local effect
:
Type
=
Name =
condition overheating
It p u m p is in 'on' state and inflow is nil Then pump overheats
Fig. 5. A simplified p u m p frame.
gen__ prop(classt_prop(pump), suh_prop([aU]),
showstate( [state] ), work([lstate(on), in( [low,normal,high ]),out~ l) ow,nor real J~dgh] ),
locaLeff([])], [state(on), in([nil], out([hill). locaLeff(([type(condiUon), name(overheatlng).
cause([type(inout),Input([nfll ))] ). fanlt~[fgmode(low_ o u t p u t ), In([low,normal,h/gh]),out([low,low,low] ),
IooaLeff([])l])). Fig. 6. Simplified p u m p frame in Prolog~
1AShankararaman, B.S. Lee/Computers in Industry 25 (1994) 145-157 state of an inflow tank is entirely dependent on the inflow to the tank and neither the instructor nor the trainee can directly cause a change in the tank level.
State display definition. This slot defines the state or the p a r a m e t e r that must be displayed when the state of the component is checked.
Behaviour definition. The behaviour of a component is defined in terms of its state, input and output parameters and the local effect on the component. The state refers to either a working state or a fault state. A component may have a number of distinct possible working or fault states. For each state, the corresponding input and output parameters and the local effect are to be defined. The local effect describes the local behaviour of the component for a particular state and input combination.
153
- checking the state of a component (e.g. 'check valve'); - setting a fault mode for a component (e.g. 'set valve to stuck closed'). All these intentions may be carried out by clicking the mouse pointer on the respective icons.
5.4. Quafitatit'e simulation The previous steps enable static modelling of the individual components and flow elements. Qualitative simulation enables the modelling of the dynamic interaction between the various components which are connected by the flow elements and their effects on each other and the plant parameters. For every run of the simulation, the final product is a new set of state values for the components and a new set of parameter values for the flow elements. The simulation begins at the source and terminates at the sink.
5.2. Component linkage
6. S i t u a t i o n - b a s e d r e a s o n i n g (SBR)
The modelled components are to interact with each other when they are linked. The linking mechanisms enable propagation of the process (both normal and abnormal) through the whole plant. The two main linking elements are fluid flow elements (pipes) and current flow elements (cables). The modelling methodology for both these elements is essentially the same. For simplicity, the prototype deals with fluid flow system and consequently the only linking elements which appear in the current study are pipe elements. Functional definition for a pipe follows the frame representation used by the components, but only the behaviour definition is sufficient. In addition to this the pipe elements have a schema representation that is used to propagate a fault through the system.
If any fault is purposefully set or inadvertently caused by trainee action, then the system must be able to locate the fault, identify the root cause and propagate the fault through the entire plant model. The situation-based reasoning enables all of these functions. For simplicity, in the prototype, the SBR can handle only one component fault mode at a time, so multiple faults cannot be set in the plant model. In order to understand the mechanism behind SBR let us consider the plant model shown in Fig. 7. Tank tl is the source tank and the fluid is p u m p e d to the inflow tank t2 by p u m p pul. Valves vl and u2 control the flow. The situationbased reasoning is performed by the following steps:
5.3. Intentions modelling This refers to the intentions of either the instructor or trainee to observe or modify the plant status. These intentions include: - changing the working state of a component (e.g. 'open valve');
Step 1. Fault identification and classification Once the qualitative simulation is performed, the resulting state for every component and pipe element are examined. In general, the system classifies the fault into two main types: mismatch faults and condition faults. Components and pipes
154
K Shankararaman, B.S. Lee/Computers in Indus'try 25 (1994) 145-157
p4
is worked out by the qualitative simulation as 'nil'. The effect of the fault at ~,l is then propagated downstream. In order to propagate the effect upstream a new algorithm is used. In contrast to the above, the output of the faulty component or pipe is used to work out its input. Subsequently, the input of the components upstream are obtained from their output and state value. For the example in Fig. 7, since the outflow from the stuck closed valve vl is 'nil', the inflow to valve vI is changed to 'nil' and subsequently, the inflow to pipe pl is obtained from its outflow which is 'nil' (note that inflow to r'l has already been established to be 'nil'). Finally, the level in tank tl returns to value 'no change'.
7. Discussion
Fig. 7. A simple water flow system.
which are found to have a fault are examined further. A mismatch fault is one where the input and output values for parameter do not match. For example the component may have inflow value 'high' and outflow value 'low', indicating a fault or a pipe may have inflow 'normal' and outflow 'low' indicating a leak or partial blockage. A condition fault is one that arises due to a unique combination of the component state and the input to it. For example, a pump may have a condition fault of 'overheating', when in the 'on' state and inflow is 'nil'.
Step 2. Fault propagation Once the fault has been identified, the next step is to propagate the effects to the upstream and the downstream end of the plant, from the point of origin of the fault. The qualitative simulation algorithm allows fault to be propagated along the downstream end. For the example shown in Fig. 7, if the valve vl is closed stuck, then the input to the pump pul and the tank t2
The prototype system uses a shell-based approach which allows the instructor to develop the plant schematic and textual lessons without having to program. There is no doubt that this increases the efficiency and effectiveness of courseware generation very much. A significant feature of the prototype is the use of qualitative modelling methods to model process plants instead of numerical simulation. Such models are close to human reasoning and. therefore, contribute towards improving trainee's understanding. The prototype has shown that it is practically feasible to develop and simulate such plant models from component models using a 'building block' approach. It has also demonstrated the application of such models to training, particularly, in the lesson styles 'Modes' and 'Fault Diagnosis'. Integration of the expert system and hypertext approach has been achieved in the prototype training system. The qualitative modelling and simulation of the plant is done through expert system approach and the textual presentation of courseware is done through the hypertext approach. Both of these approaches are combined into the various lesson styles. The expert system approach does not use a
V. Shankarararnan, B.S. Lee/Computers in Industry 25 (1994) 145-157
rule-based methodology, but a model-based reasoning method. The results of using models are quite encouraging. The clear advantage is in the authoring. Specific plant models can be developed from linking generic definitions of components and flow elements. Furthermore, the tedious process of writing rules for every faultsymptom is avoided.
155
Research in using qualitative models is still in its infancy and there is much ground to cover [14]. The prototype in its present form has some limitations in this regard. As a result, the lesson styles 'Modes' and 'Fault diagnosis' are not entirely generic and are limited to only certain plant models. This limitation is due to the difficulty in developing a generic qualitative reasoning mecha-
a
pipe cable
[]
[] ½ []
b
!
~ l l [ l l 11 I i I ! [.~]m [ B I l l
.I.
Fig. 8. (a) Icons being positioned and defined. (b) Indicating the root cause identified as the closed state of valve t'l caused by operator error.
156
V. Shankararaman, B.S. Lee / Computers in Industry 25 (1994) 145-157
nism applicable to any component. Extending this knowledge base to include more components is very important for any future development. It has been found, however, that qualitative modelling alone may not be enough for complex plants. One possible way of overcoming this limitation is to carry out the simulation quantitatively, interpret the results and derive qualitative explanations. Another possibility is to simplify the plant by subdividing into small recognisable blocks such as main block, valve block, control block and so on.
8. Conclusions By way of conclusions the main benefits of the KBSTS prototype are summarised as follows: - a flexible authoring tool for developing plant models and corresponding training lessons without need for programming - an interactive training environment which uses a number of training strategies to cope with the diverse types of safety knowledge - use of qualitative models with a scope for providing better explanations. Two sample screens are presented in Fig. 8 to highlight the facilities of the training system.
Acknowledgements The authors gratefully acknowledge the financial support of the Overseas Research Studentship administered by University of Strathclyde and Stanley Gray Scholarship of the Institute of Marine Engineers.
References [1] B.S. Lee and S. Venkataramanan, "Knowledge-based systems approach for offshore safety training", Computers in Industry, Vol. 17, 1991, pp, 349-358.
[2] M. Rudisill and D.J. Gillan, Space station information system human computer interface guide, NASA Report, Use 1000, V2.0, May I988. [3] LS. Brown, R.R. Burton and J. De Kleer, "Pedagogical, natural language and knowledge engineering techniques in SOPHIE 1,II and 1II", in: D. Sleeman and J.S. Brown (eds3, Intelligent Tutoring Systems, Academic Press, New York, 1982, pp. 227-282. [4] J.W. Rickel, "Intelligent computer-aided instruction: A survey organised around system components", IEEE Trans. Syst. Man Cybern., Vol, I(5. No 1, January/ February 1989. [5] M. Yazdani, Expert Systems User, January 1989, pp. 13-14; 16] B.S. Lee, C. Kuo and Y. Sanusi, "A flexible authoring system for knowledge-based tutoring of engineering students", in: Proc. 7th Int. Conf. on Technology and Education, Brussels, 1990. [7] LPA Prolog Professional, User Guide, LPA Associates Ltd., London, 1988. [8] K.D. Forbus, "Qualitative process theory", Artil: Intell., Vol. 24, 1984, pp. 85-168. [9] B. Kuipers, "Qualitative simulation", Art(]: hTtell., VoI. 29, 1986, pp. 289-338. [10] B.C. Williams, "Qualitative analysis of MOS circuits". Artif IntelL, Vol. 24, 1984, pp. 28t .-346. [11] M.R. Genersereth, "The use of design descriptions in automated diagnosis", Artif. lntelL, Vol. 24. 1984, pp. 411-436. [12] J. De Kleer and J.S. Brown, - A qualitative physics based on confluences", Artif. Intell., Vol. 24, 1984, pp. 7-83. [13] T.A. Kletz, "Hazop and Hazan: Identification and assessing process industry hazards", Institution of Chemical Engineers, UK, 1992. [14] W. Horn, Causal AI Models: Steps towards applications, Hemisphere, 1990. V. Shankararaman graduated with a B.Tech degree in Naval Architecture and Ship building from Cochin University of Science and Technology, lndia, in 1987 and then worked for a brief period with the Design Department of Mazagon Docks Ltd, Bombay, India. He obtained his PhD from the University of Strathclyde in November 1992 and worked as a research fellow for one year at the Department of Computing Science, University of Paisley. He then joined the academic staff of the Department of Computer Studies, Napier University, Edin burgh in 1993. His current research interests include application of knowledge-based systems in engineering and casebased reasoning for reuse of object-oriented software
V. Shankararaman, B.S. Lee/Computers in Industry 25 (1994) 145-157 B.S. Lee, a Senior Lecturer at the University of Strathclyde, graduated from Seoul National University with a BSc in Naval Architecture in 1970. After a brief period with Korea Institute of Science and Technology as a research assistant, he obtained his MSc in Ship Production Technology and PhD in Marine Technology from the University of Strathclyde in 1976 and 1983 respectiv61y. He then joined the academic staff of the Department of Ship and Marine Technology of the same University in 1983. His current research interest is in various fields of offshore engineering and application of information technology in the marine industry.
157
Computers in Industry 25 (1994) 145-157
Knowledge-Based Safety Training System (KBSTS) A prototype implementation V. S h a n k a r a r a m a n ~'* B.S. L e e b ~'Department of Computer Studies, Napier Uniuersity, 219 Colinton Road, Edinburgh EH14 1DJ, UK b University of Strathclyde, Glasgow, UK Received 18 October 1993; accepted in revised form 15 August 1994
Abstract
A computer-based safety training system for process operators must be able to make effective presentation of textual material, test the trainee's understanding through quizzes and facilitate plant simulation. The general framework of such a system is presented in an earlier paper (Computers in Industry, Vol. 17, 1991, pp. 349-358). In this paper, we discuss the development and implementation of a prototype Knowledge-Based Safety Training System based on the framework. The design philosophy, system architecture and the plant modelling methodology are described.
Keywords." Process operator safety training; Knowledge-based system; Hypertext; Qualitative plant simulation
1. Introduction
Safety training is one of the important functions of safety management. The aim of such training is to increase self awareness, impart knowledge and skills and increase motivation. Within the offshore industry a number of safety training methods have been used which include non-formal methods, formal instruction, interactive videos, practical sessions and computer-based methods. Each of these methods has its own limitations and capabilities as to the type and extent of knowledge and skill they can impart [1]. In general, safety knowledge comprises a number of different elements, such as description,
* Corresponding author.
procedure, concepts and principles. In particular, the knowledge required by a process plant operator includes process understanding, plant layout and component functions. Additional knowledge is required to handle abnormal situations which includes component fault states and fault propagation through the plant. For proper acquisition of this knowledge it must be read, understood and memorised and, above all, practical experience on a simulated plant model is imperative. The training system must be able, therefore, to make effective presentation of textual material, test the trainee's understanding through quizzes and facilitate plant simulation. A number of training strategies or lesson styles are, therefore, required to impart effectively the safety knowledge required by a process operator. The integration of expert system and hypertext
0166-3615/94/$07.00 © 1994 Elsevier Science B.V. All rights reserved SSDI 0 1 6 6 - 3 6 1 5 ( 9 4 ) 0 0 0 2 2 - 0
146
K Shankararaman, B.S. Lee / Computers in Industry 25 (1994) 145-157
within a computer-based training system facilitates this approach. The general framework of a K n o w l e d g e - B a s e d Safety T r a i n i n g System (KBSTS) based on this philosophy has been formalised, see for example [1]. In this paper the prototype KBSTS developed and implemented based on this framework is described. The prototype uses a qualitative simulation of the plant system. It allows the instructor to develop both the plant models and the training lessons without the need for any programming. The design philosophy behind the development is discussed, followed by the selection of a suitable development tool for the prototype. The functional elements of the prototype KBSTS and the modelling methodology are then described, Two sample screens are presented to highlight the facilities of the training system.
Table 2 Tasks taxonomy Tasks
Command or menu options Authoring mode
Fuloring mode
File management
Create, Load, Quil. Save
lx)ad, Quit, Save
Drawing functions
Line, Ellipse, Circle. etc.
Not required
Editing
Undo, Delete, Insert. Move, Copy, etc.
Not required
Plant model status monitoring
Check (check state i Stboard (display stale of all components)
( iheck. Stboard
Activationof plant model
Action (open or close a valve) Sim (start simulationi
Action,Sire
Others
Lesson (develop a lesson) Itelp, Describe
i,esscm tusc a lesson) Help, Describe
2. Design philosophy The design of the training system is based on a number of principal aspects as follows: 2.1. Interaction modes
The chosen approach consists of two different users: the training instructor and the trainee. Each of them can interact with the KBSTS depending on their intentions as shown in Table 1. From the table it is clear that the intentions of both users is distinctly different and, therefore, it is essential to have two different modes, viz. the authoring mode and the training mode,
Table 1 Interaction intentions Mode User Authoring
Author (training instructor)
Tutoring
Trainee
Intentions Develop plant models and training lessons Observe and understand plant models through using the training lessons
2.2. Interaction interface
The interaction of both the author and the trainee with the KBSTS belongs to the domain of u s e r - c o m p u t e r interaction. The aim of the design of a h u m a n - c o m p u t e r interface is to increase the usability of the training software. The usability of the software is a measure of the speed and accuracy with which the author and trainee can perform their functions with it. Referring back to the interaction modes, the taxonomy of tasks for the two modes, developed on a similar basis to [2], is shown in Table 2. The types of interaction which can be found in current software are: command language, menu selection, direct manipulation and natural language. Interviews with the training instructors from several oil companies have shown that menu selection and direct manipulation methods are the most appropriate means of interaction. However, it was found necessary to have some data input through typing (particularly in the authoring mode). The command language and natural language methods were discarded, based on the argument
ld Shankararaman, B.S. Lee/Computers in Industry 25 (1994) 145-157
that the author and, in particular, the trainee are easily put off by computer-based training systems that involve a lot of keyboard typing. Further, the mouse was selected as the main means of interaction between the user and the plant model. For example, selecting a particular choice from the menu and clicking on the component causes the component property to change (e.g. pump state changes from 'on' to 'off'). Such an interface is known to increase trainee's motivation and also enable him to spend more time on understanding the plant model rather than the use of the software. However, some of the final issues on the interface design and implementation are limited by the choice of hardware and software. 2.3. Shell-based approach
The principal aim of providing the authoring mode is to enable the training instructor to develop plant models and training lessons. This can be achieved by providing a kind of authoring language with which specific plant models and courseware can be programmed. This has the obvious attraction in that the system itself will be relatively simple, whilst allowing much flexibility. However, this approach calls for programming skills on the part of the instructors, and any modification to the plant model or the courseware will be rather difficult. These drawbacks were the main reasons which have greatly retarded the use of such simulation-based software within the oil industry. In view of this, it was decided that the KBSTS should be a shell with a powerful authoring system which does not call for any programming. The authoring system was designed so that a number of desirable qualities could be made possible as follows: - The author should be able to define the plant model and the training lessons by interacting with the system by using menus, a mouse pointer and keyboard input where necessary. - The inference mechanism for simulating the plant model should be built into the training system as general knowledge. - The knowledge acquisition process should be structured in such a way that the author is able
147
to obtain a better understanding of the process plant as it is being modelled. - In order to make modification and update of the plant models easier still, the knowledge bases should be partitioned into general and specific knowledge. However, it is very difficult to develop a general purpose shell that could encompass all possible components used in process plants. Even though it may be possible to develop qualitative component models for all the different components, the general knowledge specifying their interaction becomes enormous and cumbersome to handle. A possible solution is to classify components into local groups and model the interaction for that particular group. In this case, general knowledge pertaining to the interaction between the various groups may be defined. For the sake of simplicity in developing the prototype, only components pertaining to one such group are modelled, i.e. the flow system. The components in this group include reservoir tanks, valves, pumps, indicators and flow elements. 2.4. Simplified trainee model
No effective training is possible without certain understanding of the trainee. In formal training methods this is achieved by the human tutor. Within the computerised training environment, the trainee is represented by a model, often referred to as the trainee or student model. Most conventional CBT systems have a very shallow trainee model in the form of pre-defined control structures. For example, the next module to be presented to the student may depend on his answers to the questions posed in the current module. The next generation of computer tutors, or the so-called intelligent tutors, use deeper trainee models. Such deeper models enable a dynamic representation of the state of the student's knowledge on the subject being taught. They are then used to assess the trainee's understanding and misconceptions of the subject, and determine which material to present next, which to recapitulate, how to fix the misconceptions (or bugs) and so on. The main advantage of using these deep models is that they enhance the edu-
148
~ Shankararaman, B.S. Lee~Computers in Industry 25 (1994) 145-157
cational effectiveness of the tutoring process. However, their application is inhibited due to the following main drawbacks - Developing deep models is computationally intensive, particularly for domain-independent applications. - Development of deep models calls for support from cognitive psychologists. - A survey of existing intelligent tutoring systems using deep models reveals that they are practicable in only specific domains (e.g. S O P H I E I, II, III in the domain of electronic trouble shooting [3], W H Y in the domain of rainfall [4], etc.) and a general purpose student model is far from reality. In view of the above drawbacks, the trainee model implemented in the prototype training system takes a mid-stance between the shallow and deep models.
3. Selection o f the d e v e l o p m e n t tool
3.1. Hardware selection A number of hardware options ranging from IRIS workstations, main frames and personal computers were examined. Finally, it was decided to develop and implement the prototype KBSTS on a personal computer compatible with IBM PC. This choice of hardware was based on the following reasons:
Portability One of the areas of possible application of the KBSTS is on-site training on platforms where the supervisors can themselves develop the plant models and corresponding training lessons. MSDOS computers are easily compatible with each other and are easily installed.
Display capability The display features of the hardware have a very notable effect on capturing the trainee's attention and stimulating motivation. Even though the PC may not offer the best display features, the graphics facilities are reasonably good and sufficient for developing the prototype IzJ3STS.
Cost The cost of the KBSTS depends naturally on the hardware on which it is to be implemented. Using a PC-based system has a direct effect in reducing the initial cost compared to the workstations or main frames.
3.2. Software selection Since the hardware choice was a PC, only software tools applicable to PCs were evaluated, the following three main approaches were examined
(i) Expert system shells Using Yazadani's analogy [5], shells are like pre-built houses, where you need to choose the one most suitable to your needs. Shells offer a simple way of representing knowledge (both production rules and frames) and usually have a fixed inference strategy for controlling the reasoning process. A number of PC-based shells were considered (e.g, Leonardo, Crystal, Xi Plus and Nexpert Object). In general these shells impose a design methodology that is not suited for the problem, namely, developing the training system based on plant models. Another serious limitation is that the shells determine a user interface which is not very suitable for the training system.
(ii) Tool kits Tool kits are like prefabricated house parts from which you can build your house. They provide less ready-made solutions and consequently more possibilities for developing a knowledgebased system. They offer a number of representation methods and control mechanisms. The versatility and flexibility offered is, however, limited by the large computing resources required as evidenced by the fact that most tool kits run on workstations. Since the choice of hardware was already made to be a PC, the tool kits were not considered any further.
(iii) Programming languages The final choice was to select a suitable programming language. They are like general building materials which are more flexible and offer a
149
v. Shankararaman, B.S. Lee/Computers in Industry 25 (1994) 145-157
greater room for creativity. Procedural languages such as Fortran, Basic, Pascal, C, etc. usually need more time to program a knowledge-based software than compared to symbolic languages such as Lisp and Prolog. Further, gaining from past experience in using Prolog for a tutoring system within the Marine Technology Centre [6], it was decided to implement the prototype training system using LPA Prolog Ver 3.0 [7].
4. S y s t e m d e s c r i p t i o n
The general architecture of the training system is shown in Fig. 1. The training system is divided into the Authoring Module and the Training Module, each corresponding to their respective modes. The author can access the authoring manager through the authoring interface and by this means create a compiled knowledge base. The two-way arrow between the authoring manager and the compiled knowledge base suggests that the author can always edit or modify an existing
AUTHORING MODULE
TRAINING MODULE _~
TRAINING MANAGER
AUTHORING MANAGER
I l
I l
TRAINEE n~'gRFACE
AUTHOR INTERFACE
T
l
TRAINEE
AUTHOR
COMPILED KB PLANT MODEL
LESSONS
T GENERAL KNOWLEDGE Fig. 1. KBSTS architecture.
COMPONENT ~ MODELS
T
PLANT FLOWSIIEET
T
GENERAL KNOWLEDGE MODEL BUILDER
Fig. 2. Authoring module. (1) Model instantiation: (2) linkage; (3) lesson modelling.
knowledge base and then recompile it. The training manager uses the compiled knowledge base to tutor the trainee. The trainee can access the training manager through the trainee interface. The compiled knowledge base itself consists of a specific plant model along with the training lessons pertaining to that plant model. Besides this compiled knowledge, there is also an underlying general knowledge (e.g. schema to propagate the faults in the pipe elements) to guide the tutoring. Due to time constraint, it was decided that this general knowledge should be implemented at the source code level in Prolog. 4.1. Authoring module
Fig. 2 gives a finer description of the two functional elements within the authoring module: the model builder and the lesson builder. (i) Model builder The model builder assists the author in creating and maintaining the qualitative models of the process plant. This is achieved through the following five steps: - create icons for components and store them in an icon library; - load and position icons; - define component specifications for each icon; - link the component models using pipe or cable elements; - compile the flowsheet knowledge base. (ii) Lesson builder This functional element of the authoring module assists the author to develop lessons based on the compiled plant knowledge base (KB). A num-
150
V. Shankararaman, B.S. Lee/Computers in Industry 25 (1994) 145-157
bet of lessons may be developed for each plant model. In general, these lessons may be of the following types: Topics, Functions, Modes and Fault diagnosis. The lesson type 'Topics' is used to impart the theoretical knowledge on the concepts and principles pertaining to safe operation of the plant. It can be compared to an electronic book, where the trainee can move from one page to another or from one topic to another, by pressing a key button. The modelling of this lesson type is based on the hypertext approach. The lesson type 'Functions' enables the trainee to understand the layout of the plant and the functional significance of each component within the plant. The lesson type 'Modes' allows the trainee to understand and practise the various procedures for a particular mode of operation of the plant. These modes can be either operating modes, such as start up, shut down, etc., or emergency modes, such as emergency shut down. For each mode the instructor is required to give an introduction, define the goal(s) to be achieved and execute a set of procedures. In 'Fault diagnosis' a random fault is generated by the system and the trainee is required to identify the fault. It is also possible for the trainee to set a fault intentionally and observe the effects on the plant model.
4.2. Training module During the training session, the training module consults the compiled plant knowledge base and the lessons developed. The trainee interacts with the module by using a mouse pointer. The main functional elements of the training module are shown in Fig. 3. It comprises the qualitative reasoner, trainee model and the dialogue generator. The actual functioning of these elements depend on the particular lesson type being learnt in operation.
(i) Qualitative reasoner (QR) The qualitative reasoner is used only for the 'Modes' and 'Fault diagnosis' lesson types. It is responsible for running the qualitative simulation
l "~°N~'R I i Fig. 3. Training module
of the plant model. If any abnormality is observed in the plant model during the simulation, an 'abnormal' flag is set and the training system proceeds to identify the cause for the abnormality and then propagates its consequence (fault propagation) through the entire plant model. If no abnormality is observed, then a 'normal' flag is set.
(ii) Trainee model (TM) As mentioned in the design philosophy, the trainee model is a compromise between shallow and deep models. The trainee model for the topics and functions is based on checking the correctness of the answers given by the trainee. That is, the answers of the trainee are compared with those of the instructor. For matching answers, a 'success' flag is set and for wrong answers a 'reteach' flag is set up. All the reteach flags are entered into the trainee file and later he is required to redo the respective questions. A reteach flag is permanently removed from the trainee file only if he is able to answer the erred question correctly. Unlike the above, the trainee modelling used for the teach session of lesson type 'Modes'. is implemented using the 'cognitive apprenticeship' training style. The trainee has to perform a randomly selected set of procedures and the modelling is based on the comparison of his definitions of actions and preconditions with those defined by the instructor. If the match is perfect, then a 'match' flag is set. Otherwise, the corresponding error is identified, which may be an incorrect action, improper priority or incorrect precondition. The trainee may then either ask to
v. Shankararaman, B.S. Lee/Computers in Industry 25 (1994) 145-157 be retaught or decide to repeat the action, precondition or the whole procedure depending on his error. In the perform session of lesson type 'Modes', the trainee modelling is mainly based on comparing the final goal(s) achieved by the trainee with those defined by the instructor. It is necessary to note that, in this case, less emphasis is laid on his actions which enable him to achieve the goal(s). If the trainee succeeds in achieving the goal(s) by using a different set of actions and preconditions to that defined by the instructor, his solution is entered into the trainee file for manual verification by the instructor. It is possible that the trainee has found a novel solution.
(iii) Dialogue generator (DG) The function of the dialogue generator is to generate the suitable dialogues for the trainee based on the flag set by the trainee model and the qualitative reasoner. This dialogue depends on the lesson type and can be a comment (e.g. 'your action is correct'), an answer (e.g. ' T h e answer is p l and not p2'), or a menu from which the trainee may select an option. Mostly, some parts of these dialogues are pre-stored and others obtained by variable bindings according to the situation. For example, in the answer 'The answer is pl and not p2', 'The answer is' and 'and not' are pre-stored and 'pl' and 'p2' are bound variables. In addition to the above, each lesson type has its own dialogue mechanism to present the lesson and examine the trainee's understanding.
5. Plant modelling The plant modelling is based on a qualitative approach. Qualitative reasoning forms a substantial part of our everyday experience. For example, based on a news report of high oil prices we anticipate an increase in petrol prices. The exact form of functional relations is not necessary to predict the direction of the price movement. A number of researchers have used qualitative reasoning for diverse reasoning tasks, such as simulating some processes [8-10], diagnosis [11], mod-
151
elling qualitative equations and states and deducing functionality of devices [12]. The main advantages of using qualitative plant models for a training system are as follows: - It helps the trainee to obtain a conceptual understanding of the plant without having to go into numerical details. - The methodical representation of information in such models makes them easier to understand and update than average rule-based systems or numerical models. - Such models offer more scope for explanation facilities, which is a vital characteristic for a training system. - Qualitative models can reason correctly even when no numerical values are available. - Furthermore, this approach is related to the Hazop analysis, where a model of the plant is used to study the way possible hazards can arise on the plant [13]. The four main steps involved in applying the qualitative approach to plant modelling within the KBSTS are as follows:
5.1. Component modelling The component forms one of the basic unit of the plant, the other being the linking element. The two main steps necessary to model the component are hierarchical definition and functional definition.
(i) Hierarchical definition In the component hierarchy, components are classified into different classes depending upon their behaviour and function (properties). This classification can be carried out at various levels depending on the type of components and the number of levels required. The hierarchy uses three main types, i.e. class, subclass and primitives. Class refers to the topmost node in the hierarchy. A class may contain one or more subclasses. A subclass in turn can contain one or more subclasses. Primitives are subclasses which do not have any child nodes (leaves of the tree structure). Fig. 4 shows a possible classification hierarchy for the component 'tank'. The hierarchies described above provide a
V. Shankararaman, B.S. Lee/Computers in Industry 25 (1994) 145-157
152
TANK
STORAGE
INFLOW
MIXING
CLASS
pump
SUBCLASS
all
STATE C H A N G E
:
i n s t r u c t o r and trainee
STATE DISPLAY
only state
W O R K I N G STATES :
on, off
FAULTY STATES
:
low output, high o u t p u t
INPUT-OUTPUT
:
OUTFLOW
Fig. 4. Hierarchy for the component 'tank'. For state 'on'
structure by which elements down in the hierarchy may inherit attributes from those higher in the hierarchy. For example, 'inflow tanks' inherit the properties of 'storage tanks' which in turn inherit the properties of the class 'tank'.
If inflow is low~ high or normal
(ii) Functional definition
Then outflow is nil, low a n d low
Then outflow is low, high or
normal
For state 'low o u t p u t ~ If inflow is low, n o r m a l or high
Having classified the components, the next step is to define the behaviour and functions (properties) of the components. In order to define the component functions a frame-based representation is used. A component frame is basically a structure for holding various types of knowledge associated with functioning of the component. The knowledge is stored in the various slots of the frame. A typical frame for a pump is shown in Fig. 5. The corresponding Prolog representation is shown in Fig. 6. The number and type of slots used in the frame are the same for different components, but the slot values differ between components.
Class definition. This slot allows the definition of the class to which the component belongs, e.g. the class slot value can be 'valve', 'pump', 'tank', etc.
Subclass definition. This slot allows the definition of the subclass hierarchy within the particular class. The subclass definition contains a trace through the hierarchy tree to the primitive, e.g. [storage,inflow] (see Fig. 4).
State change definition. This slot defines the possibility of changing the state of the component and the user (instructor or trainee) who can effect this change. States of some components cannot be changed, e.g. the
For all s t a t e s If inflow is nil Then outflow is nil Local effect
:
Type
=
Name =
condition overheating
It p u m p is in 'on' state and inflow is nil Then pump overheats
Fig. 5. A simplified p u m p frame.
gen__ prop(classt_prop(pump), suh_prop([aU]),
showstate( [state] ), work([lstate(on), in( [low,normal,high ]),out~ l) ow,nor real J~dgh] ),
locaLeff([])], [state(on), in([nil], out([hill). locaLeff(([type(condiUon), name(overheatlng).
cause([type(inout),Input([nfll ))] ). fanlt~[fgmode(low_ o u t p u t ), In([low,normal,h/gh]),out([low,low,low] ),
IooaLeff([])l])). Fig. 6. Simplified p u m p frame in Prolog~
1AShankararaman, B.S. Lee/Computers in Industry 25 (1994) 145-157 state of an inflow tank is entirely dependent on the inflow to the tank and neither the instructor nor the trainee can directly cause a change in the tank level.
State display definition. This slot defines the state or the p a r a m e t e r that must be displayed when the state of the component is checked.
Behaviour definition. The behaviour of a component is defined in terms of its state, input and output parameters and the local effect on the component. The state refers to either a working state or a fault state. A component may have a number of distinct possible working or fault states. For each state, the corresponding input and output parameters and the local effect are to be defined. The local effect describes the local behaviour of the component for a particular state and input combination.
153
- checking the state of a component (e.g. 'check valve'); - setting a fault mode for a component (e.g. 'set valve to stuck closed'). All these intentions may be carried out by clicking the mouse pointer on the respective icons.
5.4. Quafitatit'e simulation The previous steps enable static modelling of the individual components and flow elements. Qualitative simulation enables the modelling of the dynamic interaction between the various components which are connected by the flow elements and their effects on each other and the plant parameters. For every run of the simulation, the final product is a new set of state values for the components and a new set of parameter values for the flow elements. The simulation begins at the source and terminates at the sink.
5.2. Component linkage
6. S i t u a t i o n - b a s e d r e a s o n i n g (SBR)
The modelled components are to interact with each other when they are linked. The linking mechanisms enable propagation of the process (both normal and abnormal) through the whole plant. The two main linking elements are fluid flow elements (pipes) and current flow elements (cables). The modelling methodology for both these elements is essentially the same. For simplicity, the prototype deals with fluid flow system and consequently the only linking elements which appear in the current study are pipe elements. Functional definition for a pipe follows the frame representation used by the components, but only the behaviour definition is sufficient. In addition to this the pipe elements have a schema representation that is used to propagate a fault through the system.
If any fault is purposefully set or inadvertently caused by trainee action, then the system must be able to locate the fault, identify the root cause and propagate the fault through the entire plant model. The situation-based reasoning enables all of these functions. For simplicity, in the prototype, the SBR can handle only one component fault mode at a time, so multiple faults cannot be set in the plant model. In order to understand the mechanism behind SBR let us consider the plant model shown in Fig. 7. Tank tl is the source tank and the fluid is p u m p e d to the inflow tank t2 by p u m p pul. Valves vl and u2 control the flow. The situationbased reasoning is performed by the following steps:
5.3. Intentions modelling This refers to the intentions of either the instructor or trainee to observe or modify the plant status. These intentions include: - changing the working state of a component (e.g. 'open valve');
Step 1. Fault identification and classification Once the qualitative simulation is performed, the resulting state for every component and pipe element are examined. In general, the system classifies the fault into two main types: mismatch faults and condition faults. Components and pipes
154
K Shankararaman, B.S. Lee/Computers in Indus'try 25 (1994) 145-157
p4
is worked out by the qualitative simulation as 'nil'. The effect of the fault at ~,l is then propagated downstream. In order to propagate the effect upstream a new algorithm is used. In contrast to the above, the output of the faulty component or pipe is used to work out its input. Subsequently, the input of the components upstream are obtained from their output and state value. For the example in Fig. 7, since the outflow from the stuck closed valve vl is 'nil', the inflow to valve vI is changed to 'nil' and subsequently, the inflow to pipe pl is obtained from its outflow which is 'nil' (note that inflow to r'l has already been established to be 'nil'). Finally, the level in tank tl returns to value 'no change'.
7. Discussion
Fig. 7. A simple water flow system.
which are found to have a fault are examined further. A mismatch fault is one where the input and output values for parameter do not match. For example the component may have inflow value 'high' and outflow value 'low', indicating a fault or a pipe may have inflow 'normal' and outflow 'low' indicating a leak or partial blockage. A condition fault is one that arises due to a unique combination of the component state and the input to it. For example, a pump may have a condition fault of 'overheating', when in the 'on' state and inflow is 'nil'.
Step 2. Fault propagation Once the fault has been identified, the next step is to propagate the effects to the upstream and the downstream end of the plant, from the point of origin of the fault. The qualitative simulation algorithm allows fault to be propagated along the downstream end. For the example shown in Fig. 7, if the valve vl is closed stuck, then the input to the pump pul and the tank t2
The prototype system uses a shell-based approach which allows the instructor to develop the plant schematic and textual lessons without having to program. There is no doubt that this increases the efficiency and effectiveness of courseware generation very much. A significant feature of the prototype is the use of qualitative modelling methods to model process plants instead of numerical simulation. Such models are close to human reasoning and. therefore, contribute towards improving trainee's understanding. The prototype has shown that it is practically feasible to develop and simulate such plant models from component models using a 'building block' approach. It has also demonstrated the application of such models to training, particularly, in the lesson styles 'Modes' and 'Fault Diagnosis'. Integration of the expert system and hypertext approach has been achieved in the prototype training system. The qualitative modelling and simulation of the plant is done through expert system approach and the textual presentation of courseware is done through the hypertext approach. Both of these approaches are combined into the various lesson styles. The expert system approach does not use a
V. Shankarararnan, B.S. Lee/Computers in Industry 25 (1994) 145-157
rule-based methodology, but a model-based reasoning method. The results of using models are quite encouraging. The clear advantage is in the authoring. Specific plant models can be developed from linking generic definitions of components and flow elements. Furthermore, the tedious process of writing rules for every faultsymptom is avoided.
155
Research in using qualitative models is still in its infancy and there is much ground to cover [14]. The prototype in its present form has some limitations in this regard. As a result, the lesson styles 'Modes' and 'Fault diagnosis' are not entirely generic and are limited to only certain plant models. This limitation is due to the difficulty in developing a generic qualitative reasoning mecha-
a
pipe cable
[]
[] ½ []
b
!
~ l l [ l l 11 I i I ! [.~]m [ B I l l
.I.
Fig. 8. (a) Icons being positioned and defined. (b) Indicating the root cause identified as the closed state of valve t'l caused by operator error.
156
V. Shankararaman, B.S. Lee / Computers in Industry 25 (1994) 145-157
nism applicable to any component. Extending this knowledge base to include more components is very important for any future development. It has been found, however, that qualitative modelling alone may not be enough for complex plants. One possible way of overcoming this limitation is to carry out the simulation quantitatively, interpret the results and derive qualitative explanations. Another possibility is to simplify the plant by subdividing into small recognisable blocks such as main block, valve block, control block and so on.
8. Conclusions By way of conclusions the main benefits of the KBSTS prototype are summarised as follows: - a flexible authoring tool for developing plant models and corresponding training lessons without need for programming - an interactive training environment which uses a number of training strategies to cope with the diverse types of safety knowledge - use of qualitative models with a scope for providing better explanations. Two sample screens are presented in Fig. 8 to highlight the facilities of the training system.
Acknowledgements The authors gratefully acknowledge the financial support of the Overseas Research Studentship administered by University of Strathclyde and Stanley Gray Scholarship of the Institute of Marine Engineers.
References [1] B.S. Lee and S. Venkataramanan, "Knowledge-based systems approach for offshore safety training", Computers in Industry, Vol. 17, 1991, pp, 349-358.
[2] M. Rudisill and D.J. Gillan, Space station information system human computer interface guide, NASA Report, Use 1000, V2.0, May I988. [3] LS. Brown, R.R. Burton and J. De Kleer, "Pedagogical, natural language and knowledge engineering techniques in SOPHIE 1,II and 1II", in: D. Sleeman and J.S. Brown (eds3, Intelligent Tutoring Systems, Academic Press, New York, 1982, pp. 227-282. [4] J.W. Rickel, "Intelligent computer-aided instruction: A survey organised around system components", IEEE Trans. Syst. Man Cybern., Vol, I(5. No 1, January/ February 1989. [5] M. Yazdani, Expert Systems User, January 1989, pp. 13-14; 16] B.S. Lee, C. Kuo and Y. Sanusi, "A flexible authoring system for knowledge-based tutoring of engineering students", in: Proc. 7th Int. Conf. on Technology and Education, Brussels, 1990. [7] LPA Prolog Professional, User Guide, LPA Associates Ltd., London, 1988. [8] K.D. Forbus, "Qualitative process theory", Artil: Intell., Vol. 24, 1984, pp. 85-168. [9] B. Kuipers, "Qualitative simulation", Art(]: hTtell., VoI. 29, 1986, pp. 289-338. [10] B.C. Williams, "Qualitative analysis of MOS circuits". Artif IntelL, Vol. 24, 1984, pp. 28t .-346. [11] M.R. Genersereth, "The use of design descriptions in automated diagnosis", Artif. lntelL, Vol. 24. 1984, pp. 411-436. [12] J. De Kleer and J.S. Brown, - A qualitative physics based on confluences", Artif. Intell., Vol. 24, 1984, pp. 7-83. [13] T.A. Kletz, "Hazop and Hazan: Identification and assessing process industry hazards", Institution of Chemical Engineers, UK, 1992. [14] W. Horn, Causal AI Models: Steps towards applications, Hemisphere, 1990. V. Shankararaman graduated with a B.Tech degree in Naval Architecture and Ship building from Cochin University of Science and Technology, lndia, in 1987 and then worked for a brief period with the Design Department of Mazagon Docks Ltd, Bombay, India. He obtained his PhD from the University of Strathclyde in November 1992 and worked as a research fellow for one year at the Department of Computing Science, University of Paisley. He then joined the academic staff of the Department of Computer Studies, Napier University, Edin burgh in 1993. His current research interests include application of knowledge-based systems in engineering and casebased reasoning for reuse of object-oriented software
V. Shankararaman, B.S. Lee/Computers in Industry 25 (1994) 145-157 B.S. Lee, a Senior Lecturer at the University of Strathclyde, graduated from Seoul National University with a BSc in Naval Architecture in 1970. After a brief period with Korea Institute of Science and Technology as a research assistant, he obtained his MSc in Ship Production Technology and PhD in Marine Technology from the University of Strathclyde in 1976 and 1983 respectiv61y. He then joined the academic staff of the Department of Ship and Marine Technology of the same University in 1983. His current research interest is in various fields of offshore engineering and application of information technology in the marine industry.
157