Task dependent tools for intelligent automation

Task dependent tools for intelligent automation Roy Leitch Intelligent Automation Laboratory, Electrical & Electronic Engineering Department, Heriot-Watt University, 31-35 Grassmarket, Edinburgh EHI 2HT, Scotland

Alberto Stefanini Advanced Information Processing, CISE Tecnologie Innovative S.p.A., via Reggio Emilia, 39, Segrate, Milan, Italy This paper describes the development of a composite software environment, termed Toolkit, for supporting the design and development of Knowledge Based Systems in the domain of Industrial Automation. It presents the design of the tools and the motivation behind them, and the supporting methodology that allows generic problems to be associated with the functionality provided by the respective tools. The Toolkit allows both empirical and theoretical knowledge to be represented, the latter by an implementation of qualitative modelling techniques based on a component-centred ontology. Further, languages are provided for representing (empirical) knowledge in either a declarative or a procedural format. The Toolkit is organized as a task-dependent architecture consisting of five conceptual layers: strategic, tactical, teleological, functional and object. The tools are defined by a systematic task classification and are constructed from a set of tool components consisting of the representation languages and their associated inference mechanisms. In addition, other tool components include the provision of truth maintenance and causal ordering. An overview of the representation languages is given together with a description of the current tools of the Toolkit. An example is given of using two of the tools to build a model-based diagnostic reasoner, using the component based language, and constraint propagation and assumptionbased truth maintenance. Finally, a discussion of the current work on the Toolkit is presented. Key Words: automation, fault diagnosis, control, qualitative reasoning, fuzzy logic, event graphs, task-specific architectures, toolkit.

1. INTRODUCTION People are not only Homo Sapiens - creatures capable of forming abstract ideas and reasoning - but also Homo Faber - makers of tools. Apart from minor exceptions, man alone has the propensity for making tools to aid in the pursuit of happiness and a comfortable existence. The stone axe of primitive man, the use of metals and the invention of the wheel are vivid examples of tools developed in the beginning of civilization. This process was accelerated through the development of mechanical power during the Industrial Revolution, providing new technologies with which to construct labour saving machines and further develop the tools available to mankind. Most notably, the internal-combustion engine and electricity generators provide significant mechanical advantage; they are mechanically driven tools with humans supplying the control but not providing the motive power. Within the second half of the present century we have seen rapid developments in mechanization coupled with an increasing move towards the automation of such systems. Spurred on by the Second World War, Paper acceptedin final form March 1989.Discussionends November 1989.

significant advances in the techniques for automatic control of machines and processes have been made and resulted in spectacular achievements, particularly in the exploration of space. This has led to the present 'so-called' Information Technology Revolution where the digital computer is, arguably, the most significant tool yet developed. The enormous computational power of these machines provides significant opportunity to develop information processing tools capable of controlling and interacting with today's complex industrial processes, thereby further enhancing the automation of our production processes. During the last decade or so attempts to automate the other distinguishing feature of man - the ability to abstract and reason on data obtained from observations, has also been progressing, resulting in the rapidly developing area of Artificial Intelligence. In particular, the significant advances in the area of Expert Systems, reflected in the establishment of this journal, have led to the considerable interest in developing techniques for extending the range of automation systems to include some of the techniques which currently can only be undertaken by people. Such 'Intelligent Automation' systems have the potential to improve the efficiency, safety and reliability of industrial processes. The crucial aspect is

© 1989Computational Mechanics Publications 126 Artificial Intelligence in Engineering, 1989, Vol. 4, No. 3

Task dependent tools for intelligent automation: R. Leitch and A. Stefanini the ability of the system to abstract the important information from the data and obtai¢ an 'understanding' of the situation and to decide on an action and react accordingly. Substantial world-wide interest is now developing in this area of so-called Real-Time Knowledge Based Systems, and Laffey1 has reported a review of current activities (mainly North American). This paper reports work towards the next step in this progression- the development of tools for automating the development of intelligent automation systems, thereby combining the abilities of humans to reason with abstract information with the provision of tools to enable the efficient building of complex information processing systems for applications in industrial automation. The work described herein was performed as part of a collaborative project partly funded by the European Strategic Programme in Information Technology (ESPRIT Project No. 820): Design and Experimentation of a Real-Time Knowledge Based System Toolkit for Process Control Applications. The consortium consists of seven partners over four countries: CISE (Italy), who are the prime contractors, Ansaldo Impianti (Italy), Aerospatiale (France), Cap Sogeti Innovation (France), F. L. Smidth (Denmark), Framentec (France) and Heriot-Watt University (United Kingdom). The authors gratefully acknowledge the contribution of all the partners to the development and realization of the project. The project has developed a kernel of the toolkit, now called the QUIC (QUalitative Industrial Control) TOOLKIT which is currently being validated on three important demonstrator applications relevant to industrial control and diagnosis problems. This paper reports on the motivations which led to the design of the kernel toolkit, its overall architecture and the design methodology it is intended to enforce. An overview of the knowledge representation languages and of the tools composing the toolkit is provided. An example of a diagnostic system built using the toolkit is given. This is one of the systems validated on demonstrator applications; the scenarios and the results of the validation phase are briefly overviewed. Finally, we outline the main directions of the future work. 1.1. Motivation With the clarity of hindsight, the QUIC project has four main motivations:

applications. Also, the development, implementation and validation of Qualitative Modelling techniques for large scale industrial processes provides a thorough investigation of important concepts and techniques previously restricted to small scale laboratory apparatus or simulations. 1.2. Toolkit concept The traditional approach to the development of KBSs has been essentially experimental. However, for large scale industrial applications a more systematic and methodological approach is essential if effective, reliable and safe systems are to be constructed. Further, such complex applications require a design methodology so that applications can be built from standard modules within time and cost constraints. In the context of QUIC, this requires that the various generic problems within Industrial Automation be supported by the tools of the Toolkit, and that the tools themselves are decomposable into identifiable functional units. In developing a KBS architecture for Industrial Control applications, the intended scope must be very carefully considered; a highly specific KBS would not generate a sufficient user base to justify its development, whereas an extremely general system would be expensive to develop and would require extensive customization for a given application project. This trade-off is evident in KBSs in general. A useful x,isualization of this problem is given in Fig. 1 where the 'scope' or range of application is given as the angular parameter and 'power', in terms of rapid development and utility of the representation, is given as the radial parameter. The most general and also least powerful for a specific application is a high-level language. Within this category is included AI languages, e.g. Common Lisp and Prolog; these are very general purpose and are not specific to a particular domain. These languages must be used to generate both the knowledge representation and the reasoning mechanism to be used, unless, that is, the backward chaining mechanism provided by Prolog is sufficient. By providing a knowledge representation mechanism and an inference engine, expert system shells bring more power to applications but limit the scope to those applications for which the representation and inference are adequate. Realising this restriction,

(1) The development of a powerful but general Toolkit for an extended range of applications within Industrial Automation. (2) The recognition of the respective advantages of theoretical (scientific) knowledge and experiential knowledge, and to support reasoning with both sources. (3) The development and application of ideas and concepts emerging from recent work on Qualitative Modelling 2. (4) The validation of the tools supported by the Toolkit on realistic industrial case studies provided by our industrial partners. Each of these motivations represents a topical and substantial development of the field of the 'Intelligent Automation' of industrial systems. In particular the combination of different knowledge sources and types within a general architecture provides a general and powerful set of tools for a wide range of industrial

TOOLKIT

/

~

~

- . ~ R .,~/'/

EXPERT

.....7HELLs

i ~ ~ /' F~/

I'I~GHLEVEL ~ LANGUAGE

R ffi 'Power' 0 = 'Scope'

Fig. 1. Relationship architectures

of

Toolkit

to

other

Artificial Intelligence in Engineering, 1989,, Vol. 4, No. 3

KBS

127

Task dependent tools for intelligent automation: R. Leitch and A. Stefanini knowledge engineering environments have been produced, e.g. KEE and ART a, that provide multiple representations and inference strategies that can be chosen for a specified application. Such systems extend the scope of applications and also slightly increase the effectiveness of the system with respect to a given problem within the prescribed scope. More recently, attempts have been focusing on developing specialized 'toolkits'. These attempt to provide a restricted set of representations and control mechanisms (tools) for a particular application domain. In addition, these 'toolkits' may provide additional domain dependent facilities such as graphic capabilities, interfaces, etc. From the diagram it is suggested that these reduce the scope, compared with environments, but significantly increase the power for that domain. Different tools are chosen and combined for various tasks within the target domain. Consistent with the general trend, we have developed a number of 'high level' tools designed to solve a range of problems in Industrial Automation applications and utilizing different types and sources of knowledge. This approach allows the KBS designer, for a given application, to directly encode his knowledge using primitives that naturally describe the problem to be solved rather than focusing on implementation details. Compared to conventional KBS shells, the Toolkit approach provides a much more powerful functionality at the expense of generality. In the case of the QUIC Toolkit the scope of the application domain has been a priori restricted to Industrial Automation, and hence powerful tools have been developed for this specific but large and economically important domain. The large spectrum and specific nature of the targetted application domain in this project, and the different approaches to knowledge representation required in modelling dynamic physical systems, led to the decision to develop a specific KBS building environment following the Toolkit approach. This provides a much more flexible and specialized working environment, enabling the KBS designer to build a target application by selecting from the appropriate toolkit modules. It also allows 'tools' to be included that are optimized to provide a specific functionality for a generic task, e.g. fault diagnosis. A crucial development, therefore, has been the definition of primitive tasks to be performed by the tools and the identification of the functional 'building blocks' of the tools. This has resulted in a new task classification of KBSs in Industrial Automation 4 and the development of the QUIC Toolkit Architecture to be discussed in a subsequent section. In general, a toolkit comprises: •

•

128

A general system architecture that serves as a common reference framework. The architecture specifies the basic function of the main modules. These include: knowledge bases, external interfaces, working memories and inference operators. The architecture specifies how the modules interact and defines the flow of communication information between them. A set of special-purpose building tools that are tailored and assembled together to construct a complete KBS application system. This set will include all tools necessary for the implementation of the inference mechanisms and special facilities (e.g. explanation and justification) specified in the reference architecture. Artificial Intelligence in Engineering, 1989, Vol. 4, No. 3

•

•

•

A set of engineering support tools to aid the system designer in the construction of the knowledge bases (i.e. editing, debugging, refining, and updating the represented knowledge). A set of specifications for the construction of external interfaces to traditional programming environments (e.g. DBMS, simulation packages, etc.) and towards the industrial process (data acquisition, sensors, instrumentation actuators, etc.). A KBS analysis and design methodology for supporting the correct and effective use of the toolkit over the range of tasks covered by the aplication domain.

The paradigm of the toolkit allows high flexibility to explore different architectures for structured and efficient knowledge organization, and still retains the classical advantages of openness of the KBS approach. The toolkit concept embodies the proper compromise between the contrasting exigencies of generality and specific, effective usability. 1.3. Knowledge sources A significant aspect of the QUIC Toolkit is the recognition of the various sources of knowledge available to the designer of automation systems. In addition to the experiential knowledge of process operators and engineers, industrial designers utilize theoretical knowledge of the scientific principles underlying the operation of a physical system. We term the former experiential knowledge empirical, and the latter theoretical knowledge ontological. The conventional way to build an expert system is to rely on a knowledge engineer to capture the experience of the expert (process operator) in the form of patterndecision pairs, typical of production rule systems. This approach is sometimes referred to as 'shallow knowledge' because the knowledge base records only aspects of the experience acquired from the process operator (expert); it does not provide a model of the domain about which the system is supposed to be an expert. Shallow, or surface, knowledge can be thought of as 'compiled' knowledge giving working instructions without the underlying mechanism from which the instructions have been obtained. In this way it represents what to do without recording why that action is appropriate. This aspect makes the expert system efficient, and it can be highly tuned for a given application. However, the system is also extremely 'brittle' in that it cannot reason about problems even slightly out of its range of experience. A shallow system will require re-engineering of its knowledge base whenever there is a change in the domain. For time-varying systems this can be a real problem. Explanation mechanisms for such systems are also shallow, in that what is reported is simply the sequence of rules used to determine an action; the system has no knowledge on which to base a justification for a particular action. This is important as explanation is usually quoted as a major attribute of expert systems, and is particularly relevant to the application of KBSs to safety critical systems. A system that cannot explain its actions or recommendations in terms of more fundamental principles will have credibility problems and will not be used. To counter these criticisms, an alternative 'deep knowledge' approach has been developing. In this

Task dependent tools for intelligent automation: R. Leitch and A. Stefanini approach the internal mechanism of the system is represented explicitly. The deep-level approach complements the weakness of the shallow-level approach because of its potential to derive solutions for unanticipated situations. This approach is particularly advantageous in engineering domains where knowledge of the internal structure already exists, and is typically represented in various forms of knowledge representation: Piping and Instrument diagrams, process flow sheets, mimic diagrams, etc. This internal representation extends the range of operability of a K B S , although the reasoning process is considerably more complicated, and therefore slower. Essentially, this deep-level approach attempts to define an internal structure of a given system which, in turn, defines internal variables (states) that can be used for reasoning about the behaviour of the mechanism. A deep model has the advantage that it is not task specific and as such it can be used for a number of tasks. To increase efficiency, it may also be used to generate multiple compiled 'shallow' representations for different tasks. In comparison with conventional control theory, the shallow approach relates to the input/output approach where systems are modelled by scalar differential equations or their complex domain counterparts. The deep approach corresponds to state-space theory where by defining the internal state variables, a structure, either real or abstract, is imposed on the system. There is, however, no general agreement on how these deeper knowledge structures should be generated. The problem is that, as defined, deep knowledge is relative, i.e. it is deep only with respect to a particular shallow description and can itself be shallow with respect to a deeper model. There appears to be no significant characteristic of a representation that qualifies for the description 'deep'. In order to avoid this confusion we prefer to focus on two different types of knowledge: empirical and ontological. This dichotomy reflects the way in which the knowledge is generated. Empirical knowledge is induced from observations whereas ontological knowledge is deduced from theoretical principles. Empirical knowledge is that used in the classical expert systems paradigm. It is obtained by experience based on observations of the relationships between the observable events. Essentially, it takes the world as we find it, examines the various systems that exist in it and then infers relationships and regularities about the observations that can be made. This method is essentially empirical, intuitive and inductive. It has the basic advantage that it remains close to reality and that the models are readily accessible and understood by people. On the other hand, it lacks deductive strength, and can appear unsystematic. Models obtained by empirical observation are specialized, and often lack generality. However, when applicable, empirical knowledge can be extremely efficient. The similarity between empirical and shallow knowledge is obvious. The essential difference is that empirical knowledge describes a source of knowledge whereas shallow knowledge is a characteristic of a knowledge representation. This distinction should be clear from the fact that we can have deep empirical models. Such models are called causal models 5 as they attempt to provide a representation for the internal causal structure of a system. However, this representation is still obtained empirically, by experience, rather than by application of theoretical principles. This highlights the

problem of the meaning of 'deep' in that shallow models may also model the perceived causality in the system. The other approach is that of ontological or analytic modelling. Instead of studying a particular system, the analytic approach considers the set of all conceivable systems that share common properties, usually in the form of fundamental physical principles. Equivalence classes are thus formed and used to classify the particular system under study. Once a system is assumed to belong to a given class, it inherits the properties of that class. This approach is deductive in that it starts with a set of theoretical principles and establishes, or assumes, that the system satisfies them. Ontological knowledge is not the same as deep knowledge; ontology refers to the source of the knowledge whereas deep refers to the level of resolution used to represent the observable phenomena. The characteristics of both types of knowledge are different. Because ontological knowledge is rooted in a theoretical approach the knowledge is more easily transferred to other domains, whereas deep empirical knowledge is heavily domain dependent (but less so than shallow empirical knowledge). A number of different theories are currently under development for expressing this ontological knowledge in physical domains. They all share the same objective: of providing a methodology for the qualitative representation of physical systems that maintains the characteristics essential to performing a task without requiring the precision of real-valued functions. In the QUIC Toolkit, tools based on the above distinction have been developed. Three representation languages have been specified and implemented; two for expressing empirical knowledge and one for representing ontological knowledge.

1.4 Qualitative modelling The area of Qualitative Modelling is currently attracting much interest from the A.I. community. Such models attempt to capture the crucial distinctions in the behavior of physical systems without invoking unnecessary detail. Of course, what is unnecessary is dependent upon the task for which the model is to be used. However, for many tasks, such as fault diagnosis and explanation, a qualitative representation of behaviour may suffice. A number of distinct motivations exist for the various approaches to Qualitative Modelling. Some workers are attempting to develop computational mechanisms that are simpler than the classical methods. In this case, a classical model exists but a process of abstraction to qualitative variables is made; the qualitative model allowing a simplified behaviour generating mechanism. For others, including the present authors, the motivation is in developing models of physical systems for which there does not exist a reliable classical model. In this case, resort is made to an empirical, or combined ontological and empirical, models; qualitative models provide a formal mechanism for representing complex or ill-defined systems at a qualitative level. A further motivation is to provide a representation that accords with our 'common sense' understanding of the operation of such systems. A common characteristic, however, is to improve the human-computer interaction aspects of the modelling of complex systems. There are, at present, three main approaches to Qualitative Modelling: component centered, process centered, and constraint centered la. In the component

Artificial Intelligence in Engineering, 1989,, Vol. 4, No. 3

129

Task dependent tools for intelligent automation: R. Leitch and A. Stefanini centered approach, modelling of the physical system is achieved in terms of the identifiable subsystems (components) and their interconnections. Each component is represented by confluences that describe the relationships between the variables (time-dependent parameters), usually in the form of qualitative differential equations. The values of the set of variables is called the system state and is determined using constraint propagation and generate and test techniques. In qualitative process theory, the basic modelling primitive is taken as a process that directly relates objects that influence each other through a distinct process. For example, the process 'heat-flow' describes how energy flows between a source and destination under certain preconditions. Again constraint satisfaction and generate and test are used to generate the behavior from the model. The third approach is more formal and takes its description as a qualitative abstraction of an underlying differential equation representation. The qualitative model is represented in terms of a set of qualitative constraints. The behavior of a system can be viewed as a qualitative state diagram where each state describes the qualitative value of each state variable in the system. The behavior of the system over time can then be represented as a particular path through a state diagram, also known as a history. The process of generating a history is called qualitative simulation. Each state along the path represents an interval of time over which the system's state variables maintain their values. The duration of this interval is determined using principles of continuity and rates of change. In the QUIC project, a component based approach has been adopted, largely because of the ease of identifying physically meaningful subsystems, and also because this approach accords with the traditional engineering view of complex process systems. However, the constraint based approach to qualitative simulation has also been investigated for reasoning about dynamic systems, and forms the basis of current development in generating a predictive engine based on explicit temporal propagation techniques. 1.5. Toolkit validation The preceding sections have reviewed the technical motivation for the project. A further objective has been to validate the approach and the tools developed on realistic demonstrators provided by the industrial members of the project consortium. The project encompasses three large demonstrators relevant to these application areas: -

-

-

malfunction detection and diagnosis in the thermal cycle of a power plant (DEM-1); data interpretation and control of a spacecraft, including misposition/attitude detection and diagnosis, and assistance to correction manoeuvres (DEM-2); startup, on-line monitoring, and control of the main subsystems (the kiln and the mill) of a cement manufacturing plant (DEM-3).

The project workplan provided for the definition of these demonstrator applications during the phase of tool development. To speed up the development process, the tools were 'coupled' to a specific demonstrator application. This allowed the tool developers to focus on a specific problem while ensuring that design decisions were

as general as possible. The tools were then implemented and have undergone a 'primary' validation on their associated demonstrators. A 'secondary' validation is currently in progress where the tools are being applied to similar tasks but on different demonstrators. 2. TOOLKIT ARCHITECTURE From the beginning, one of the main motivations for this project has been the development of a KBS architecture supporting a number of'high level' tools designed to solve a range of problems in Industrial Control. This approach allows the KBS designer, for a given application, to directly encode his knowledge by using primitives that naturally describe the problem to be solved rather than focusing on implementation details. The traditional approach to the development of KBSs has been essentially experimental. However, the development of KBSs for complex applications, e.g. industrial control requires a more systematic or structured approach. This is required if a software methodology for KBS is to be developed such that systems can be built within time and cost constraints. However from our perspective, a structured approach is essential to 'bridging the gap' between problem solving knowledge as expressed by the domain expert and the knowledge representation formalisms used to encode such knowledge. What is required is a methodology for mapping problems onto 'standard' solutions. This approach relies on being able to decompose a system, in this case a software system, into a number of weakly interconnected activities 6. In general, this is a difficult problem, and requires an assumption of 'nearly decomposable' systems. In the domain of Industrial Control, recognition of the basic problems and tasks to be undertaken provides a mechanism for decomposition. This can take place in both a 'horizontal direction' by defining primitive elements, based on a discrimination criterion, existing at a given level, and in a 'vertical direction' by abstraction, based on the purpose of the representations. This results in a layered architecture, the layers corresponding to the various conceptual distinctions (abstractions) defined in the architecture and the primitive constructs derived from an analysis of the basic tasks to be performed by the KBS. Within the QUIC Toolkit architecture five conceptual abstractions or layers have been defined: Strategic, Tactical, Teleological, Functional and Object The Strategic and Tactical levels are composed, from the Toolkit, by the KBS Builder for a given application. The Teleological, Functional and Object levels exist within the QUIC Toolkit and represent various aggregations of software modules. The boundary between the Toolkit (Teleological level) and the Application KBS (Tactical level) was determined by an analysis of the realistic level of KBS tools that could be provided to the KBS Builder. The set of such tools needs to be general enough to support a wide range of tasks whilst allowing different techniques and sources of knowledge to be incorporated. This distinction is made by defining systems at the Tactical level and tools at the Teleological level of the Toolkit. Systems correspond to the range of problems usually associated with Industrial Automation, e.g. diagnosis, feedback control, monitoring and simulation. Tools are defined through an analysis of the primitive tasks required of KBSs in Industrial applications. The separation of systems and tools is required because a system can be

130 Artificial Intelligence in Engineering, 1989, Vol. 4, No. 3

Task dependent tools for intelligent automation: R. Leitch and A. Stefanini implemented in a number of different ways using a number of different techniques and utilizing knowledge from different sources. This provides a flexible architecture that allows, for example, different approaches to fault diagnosis to be integrated within a general diagnostic problem solver. It also allows the integration of empirical knowledge gained from experience and ontological knowledge based on scientific laws. This integration is done by the KBS architect using direct knowledge of the application, rather than in an ad hoc manner within a 'so-called' general algorithm. Fig. 2 summarizes the levels defined within the QUIC architecture and the generic terms of the software entities existing at that level.

Strategic level This represents the 'top' level of the Toolkit and provides the control and coordination between the various sytems constructed from the Toolkit. The goal of this level is to satisfy the overall objective of the application. For example, in this project the overall strategic goals are: (1) Demonstrator 1: maintenance of the thermal efficiency of a power plant (2) Demonstrator 2: complete in-flight control of a satellite. (3) Demonstrator 3: complete operational control of a cement plant. It is assumed that the strategic goals for a given application do not change within the life-time of the operational KBS.

Tactical level This is the main level at which systems to satisfy clearly defined sub-problems are constructed. This directly corresponds to the systems developed as compositions of

STRATEGIC

TACTICAL

~

~

the primitive tasks supported by the Toolkit. Systems can be realized by an interconnection of tools; the utilized tools being dependent upon the application domain and the approach chosen. It is envisaged that this level will incorporate a fixed control strategy amongst the systems. The strategy being designed by the systems builder. Alternatively, the strategy may be manually supervised.

Teleological level This corresponds to the interface level between the application and the Toolkit. As such, the tools are defined by the primitive tasks and represent the basic problem description language provided to the KBS builder to develop his application. This allows the builder to analyse the problem independently from implementational issues. The tasks, to be presented in the following section, are defined from a 'systems theoretic' perspective giving fundamental distinctions between tasks. This provides a purpose or teleology for the tools generated within the Toolkit, and is the basic raison d'etre for the task classification. From the user's perspective the Toolkit apears as a set of tools each implementing one of the specified primitive tasks. However, each task can have a number of tools developed from different principles, e.g. ontologic and empiric knowledge. Tools are, therefore, constructed by the tool builder to realize a specific task in a particular way. Alternatively, these tasks are the basic primitives that the KBS builder uses to define the application problem. Functional level A further level of decomposition is provided inside the Toolkit based on identifying generic information processing functionalities that are used to construct the tools. This functional decomposition is used to define a set of tool-components that may be used to construct different tools, i.e. a given tool-component can be used to construct different tools. Examples of tool-components are knowledge representation language interpreters and inference mechanisms. Control of the tool-components is explicit to each tool and is determined by the tool-builder.

APPLICATION KBS

SYSTEMS

TELEOLOGICAL

~

TOOLS

FUNCTIONAL

--)

TOOL-COMPONENTS

OBJECT

~

LANGUAGES

Fig. 2. Functional architecture of QUIC Toolkit

Object level The final layer represents the implementation of the various tool-components and provides access to the various programming languages and environments utilized in developing the software. It is the level where the major software development effort is expended. 2.1. Task classification for industrial automation In the domain of process control a classification of tasks is possible by recognizing that we are dealing with dynamic physical systems that evolve over time. Such systems must incorporate models, either explicitly or implicitly, of the system they are reasoning about. These reasoning mechanisms, therefore, fundamentally involve reasoning about the behavior of the system state as a function of time: past, present or future. Reasoning with time can, therefore, be used as the basic criterion on which to base a useful classification of process control tasks. This, in fact, accords with the classification used in conventional automation systems. However, many more tasks are possible using KBS technology resulting in a considerable generalization of conventional techniques. We have defined five such tasks: Artificial Intelligence in Engineering, 1989,, Vol. 4, No. 3

131

Task dependent tools for intelligent automation: R. Leitch and A. Stefanini INTERPRETATION: The transformation of observed data into the adopted state representation. EXECUTION: The transformation of decisions represented in the adopted knowledge representation into data suitable for action. DECISION: The decision making process whereby the known or computed complete state is used to construct conclusions (hypotheses) at the same time. PREDICTION: The generation of predicted future states from known or assumed present states. IDENTIFICATION: The determination of (unknown) past states from known or assumed present states.

Decision, prediction and identification concern the direction of the reasoning process over time, and are necessary to allow the partial observed state to be expanded to include the unobservable states, thereby obtaining a complete description of the system. The prediction and identification tasks normally utilize an explicit model of the process, and are fundamental to model-based reasoning, whereas decision is used to relate observations directly to conclusions, and does not include an explicit model of the physical process being reasoned about. Interpretation and execution concern the transformation of data between knowledge representations. Formal definitions of these tasks are given in Reference 4. The relationships between these tasks are shown in the schematic of Fig. 3.

2.2. Industrial automation systems Based on the preceding classification of 'primitive' industrial control tasks we can now develop a range of

~rvations

past state

time

time

present state

r

state

PREDICTION

IDENTIFICATION

DECISION

© means

ecommendat ion EXECU~ON

Display to user

Fig. 3. Relationship between primitive tasks 132 Artificial Intelligence in Engineering, 1989, Vol. 4, No. 3

ctions

future

Task dependent tools for intelligent automation: R. Leitch and A. Stefanini systems for industrial control problems. It is crucial to recognize that these are not the same as the task descriptions previously presented, and to enforce this distinction we use the term 'system'. A particular system can be realized by a number of different compositions of the primitive tasks. This is, in fact, the main reason for separating system from task. For example, two types of diagnostic systems can be identified: classification and model-based. Diagnostic sytems have been the major focus of development for KBSs in industrial environments and indeed represent a major motivation for this project. However, diagnostic systems can be implemented in a number of fundamentally different ways. Hierarchical classification, developed for medical applications by Chandrasekaran 19 implements diagnosis as one of identifying a malfunction (patient case description) as a node in a fault (disease) hierarchy. In this case the fault hierarchy is obtained from pre-compiled knowledge and represents a decision process. A similar approach, known as heuristic classification, has been developed as a generalization of the MYCIN expert system. Such classification systems can be represented in terms of the primitive tasks of interpretation and decision, as shown in Fig. 4(a). An alternative approach to diagnostic systems and one that is receiving much attention, is model based diagnosis. In this case, an explicit model of the system (to be diagnosed) is represented and used to generate hypotheses which are matched against the current state until there is no discrepancy, or, at least, the discrepancy

~

~ observed data

~

observed data

INTERPRETATION I

~

DECISION

(1) A model-based diagnostic system that utilizes theoretical knowledge of a steam condensing plant (DEM-1), and which is augmented by specific empirically based knowledge to produce a general diagnostic system 17. The primitive tasks for this system are shown in Fig. 5. (2) A regulatory feedback control system, that uses domain specific empirical information, obtained from process operators, to maintain the state of a rotary cement kiln (DEM-3) within a desired operating region. The task decomposition for this system is given in Fig. 6. (3) A condition monitoring system for anomaly detection of misattitude positioning of a satellite (DEM-2). This can be represented in terms of the primitive tasks as shown in Fig. 7. The monitoring

observed data

current state

current state

|

is minimized. In this case the model generating that behavior represents the fault model and the cause of the malfunction can be deduced. In terms of the primitive tasks, model-based diagnostic systems can be represented as an interpretation task to generate the current state and the identification task to generate faults from matching with the current state, Fig. 4(b). This representation of different approaches to diagnostic reasoning is fundamental to this classification of tasks. A futher reason why this separation has been made is that it allows ontological and empirical knowledge to be integrated at the system level. For example, ontological diagnostic reasoning must often be complemented by empirical knowledge in order to generate appropriate fault models. Based on the architecture, and its associated decomposition method, we have developed three Industrial Automation Systems:

I,

INTERPRETATION

IDENTIFICATION ~ complete state

I ii

]

fauIts

I °

I

I

IDENTIFICATION (ONTOLOGICAL)

]

I ~ complete state DECISION

faults

(a)

DECISION

vn'mCAL)[

~ current state

[

(b) Fig. 4. (a) Classification based diagnosis, and (b) modelbased diagnosis

Fig. 5. Co-operating empiric and ontologic knowledge sources in a general diagnostic system (DEM-I)

Artificial Intelligence in Engineering, 1989,, Vol. 4, No. 3

133

Task dependent tools for intelligent automation: R. Leitch and A. Stefanini

~ ~

general architecture is shown in Fig. 8. The following sections present the tools and the tool-components provided by the current kernel of the Quic Toolkit, beginning with an overview of representation languages.

observed

data

INTP/~R~TATION

I

3. REPRESENTATION LANGUAGES The domain of Industrial Automation differs from other domains for KBSs applications in that there exists various sources of established knowledge and such knowledge is often codified and used in different formats. Accordingly, three representation languages are provided within the Toolkit: one to represent ontologic models of physical systems based on a component or device centered approach to Qualitative Modelling, and two languages to represent empiric knowledge in either a declarative or procedural formalism. This section provides a short overview of these representation languages.

current state

DECISION

~

control decision

3.1. The Component Based Language

EXECUTION

Fig. 6. Regulatory feedback control system (DEM-3)

observed data

INTERPRETATION I" current state

Fig. 7.

J

~ external commands

I PREDICTION state

satellite

invalid

anomaly

commands

The monitoring system of DEM-2

system compares the predicted reference (ideal) state with the interpreted observed state to detect malfunctioning, and then uses a decision primitive to generate the satellite anomalies. A decision procedure is also used to detect invalid telecommands. This separation of system from primitive task is essential to providing a Toolkit architecture capable of providing generality whilst allowing the flexibility to incorporate specific techniques based on different knowledge sources to be realized within the Toolkit. The

The basic concept of the Component Based Language (CBL) is that a physical system can be specified by describing its structure as a set of interconnected components; a model is defined for each component which allows the component's behaviour to be inferred, and hence the behaviour of the whole system. Thus the CBL provides a definition section, for defining abstract models of components and a declaration section, for describing an actual system in terms of a set of component instances, and their interconnections. A component type, i.e. an abstract model of a component, features a finite number of relationships, variables, parameters and terminals. Terminals are ports through which components are to be interconnected; a terminal type is a structure whose elements are scalar variables representing measurable quantities. For instance, electrical components such as resistors, capacitors, inductors, etc., are connected through terminals representing voltage and current intensity as scalar elements. The component model is provided as a set of equations constraining the terminal variables, and some component specific information. Equations may be interpreted either in quantitative or in qualitative domains using pre-specified definitions. However, some domains are predefined in the language, in particular the (quantitative) domain of real numbers, and a qualitative domain allowing a set of three values, which represent the qualitative change of a variable with respect to a reference value: increasing, decreasing or steady. Each component description may be partitioned according to different views of the underlying physical process (e.g. the electrical and thermal view of a resistor) each of which may be considered as a model of the process in a specific situation. A mechanism to provide default models to be used instead of specific views is also provided. The CBL declaration section allows the user to describe a particular physical system by declaring its components as instances of component types provided by means of the definition section, and to state the connections between these. Particular views of component behavior may also be instanced, and it is possible to activate different views at run-time, i.e. when the model is being used. A choice of pre-specified domains or 'quantity spaces' is available, allowing the derivation of qualitative and quantitative

134 Artificial Intelligence in Engineering, 1989, Vol. 4, No. 3

Task dependent tools for intelligent automation: R. Leitch and A. Stefanini

I

STRATEGIC

TACTICAL

SYSTEM1 I

TARGET KBS

[

SYSTEM2

APPUCATION i

KBS

TELEOLOGY

.............. FUNCTIONAL

OBJECT

LANGUAGE

ENVIRONMENT

]

,

Fig. 8.

Architecture of the QUIC Toolkit

descriptions of behavior. The declaration section is also used to provide the initial parameters of the description.

3.2. Fuzzy Rule-Based Representation Language Over the last decade rule-based languages have attracted much attention as a practical solution for expressing human knowledge. Most KBSs, and almost all of the available KBS development environments, use production rules as the basic representational formalism. Hence, a rule-based language for expressing empirical knowledge in a declarative way is provided within the Toolkit. Our approach to the definition of a Toolkit rule-based language has been pragmatic. We have chosen to adopt the solution provided by the environment adopted for developing the kernel toolkit - KEE a. This is an object oriented environment with units as the basic structure and slots in the units as the information carrier. Rule units belong to the rule class units. Rule class units can again belong to other rule class units. In this way a hierarchical structure can be generated. Slot information can be inherited through the rule class units to the rule units. A particular requirement in modelling physical processes from a human perspective, is the representation of the essential vagueness of human knowledge. It is apparent that many Industrial Automation problems that defy formal analysis are rather easily controlled by human operators using their empirically derived knowledge. This knowledge is often expressed in vague terms. Fuzzy logic is an approach to the representation of human expertise as mentioned above. Natural language terms, such as low, high, etc., are used as labels for membership of variables

defined on a universe of discourse. Membership is expressed as vague or gradual transition between terms, in contrast to the precision of binary logic where the transition between non membership and full membership is crisp or abrupt. These observations led to the decision to incorporate a language capable of representing such vague knowledge using the fuzzy logic approach. It will be hereinafter referred as the Fuzzy Rule-Based Language, while the general purpose production rule formalism will be called the Binary Rule-Based Language. A fuzzy rule is implemented as a slot value of a fuzzy rule unit. A fuzzy rule unit is a member of one or more fuzzy rule classes. A set of fuzzy rule units belonging to the same fuzzy rule class is implemented in Lisp. The fuzzy inference mechanism is attached to the rule class as a method.

3.3. The Event-Graph Language It is recognized that knowledge relevant to many of the tasks in automation systems is often expressed and manipulated in a procedural form. For instance, knowledge used to perform diagnosis involves description of procedures, sequences of testing and repairing actions as well as sequences of physical components to verify, connect or disconnect. It may also include descriptions of possible evolutions of a physical system, whether these behaviors are normal or abnormal. The evolutions, which may be concurrent, need to be checked, recognized and tracked. A similar need arises in sequential control, where it is necessary to order and to link together several actions (e.g. start-up and shut-down procedures). The use of

Artificial Intelligence in Engineering, 1989,, Vol. 4, No. 3

135

Task dependent tools for intelligent automation: R. Leitch and A. Stefanini procedural and declarative knowledge in general automation systems has previously been investigated and reported by Gallanti eal. 8 and Leitch and Kraft 9. The language adopted in the kernel toolkit for representing procedural knowledge is based on EventGraphs and shares several features with Petri nets. An event-graph is a directed graph with two types of nodes: places and events, and a marking concept. Places are graphically represented as circles and events as boxes. Directed arcs can only connect nodes of different types. Events are labelled with two expressions, specifying a condition and an action respectively. A place can contain a mark. An event-graph can have any arbitrary number of marks. The set of all marked places defines the current marking of the event-graph. An initial marking is defined for each event-graph. An event is enabled if all its ancestor places, called the input places, are marked. An event can fire, i.e. it is active, if it is enabled and its condition is true. We define the current condition of an event-graph as the set of conditions labelling the enabled events. An event-graph is active (enabled) if at least one of its events is active (enabled). Firing an event means unmarking its input places and marking all its successor places, called output places. Firing an event also causes the execution of the action specified in the event. Current marking thus evolves by means of event firing. The concept of event-graph embodies a static and a dynamic part. The static, i.e. the definition of places, arcs and events with conditions and actions (plus the initial marking) represents the code of a chunk of procedural knowledge. The dynamic behavior of an event-graph is represented by the sequence of current markings that the event-graph goes through as a consequence of successive events firing. Thus, the static part of an event-graph may be activated in different contexts and produce several images corresponding to different current markings, similar to a re-entrant procedure which can be executed several times in parallel with different parameters.

component re-usability, and thus introduce tool components, and show how they have been used for assembling specific tools. In this description, we conform to this latter approach as we believe that, especially for this first set of tool components, specified for the kernel Toolkit, generality prevails upon specificity. Further, this complies with the way in which the design of the Toolkit took place: -

-

-

The tool components that are actually part of the kernel toolkit have been designed with the aim of providing support to the representation languages described in the previous section. Thus they may be quite naturally divided into three sets relevant to the CBL, the FRBL, and the Event Graphs; however, as we will argue, some of them- namely the constraint propagator and the assumption-based truth maintenance system - provide a basic reasoning functionality and have, therefore, a broader range of application. 4.1. Tool components supporting the Component Based Language The main tool components supporting the CBL are: -

4. TOOL COMPONENTS OF THE KERNEL TOOLKIT The toolkit includes two classes of software packages: -

tool components, providing a specific, well defined, but basic software functionality; tools, providing full support for performing a primitive domain task.

One may argue that tools and tool components are specified by individuals having a different role in the development of the Toolkit. Tools are specified by a methodologist - a toolkit architect, or designer - in order to perform a definite domain task using well identified knowledge sources and problem solving strategies. To this aim, the Toolkit designer may either use already available tool components, or commit to a software designer the construction of a component performing a definite function which is required in the overall design of the tool. Accordingly, tool components range in a spectrum between extreme generality and re-usability, and extreme specificity. Therefore one may choose, in describing the toolkit, to stress the rationality of the overall design and overview top-down tools first, and then introduce tool components in the frame of each single tool. On the other hand, one may choose to stress tool

136

In a first phase, mainly from background experience in the Consortium, the Toolkit representation languages were identified and defined; Immediately after, we started specification of a basic set of software modules (later identified as tool components), mostly aimed at providing basic facilities (editing, compilation, interpretation and inference) for the languages we had designed; Identification of the tools, i.e. of the proper interface of the Toolkit, required a broader analysis, and this was possible only after the experience gathered experimenting with the demonstrators was rationalized and abstracted in such a way as to allow the identification of primitive tasks, and hence to the specification of the appropriate tools.

-

-

the the the the

CBL compiler, causal ordering system, constraint propagator, and assumption-based truth maintenance system.

These are briefly overviewed hereinafter. The CBL compiler is a standard compiler translating CBL descriptions into an internal representation based on an object oriented language (KEE Units). This latter language is used within the Toolkit as a protocol for exchanging information between software modules at any level of the software architecture. Units are suitable for translating into CBL descriptions and declarations, because information relevant to the main language primitives is already divided in separate subsets associated with each keyword. Association between these subsets and a slot of a unit is then straightforward. For instance, a CBL componentclass definition is translated into a unit where three different slots are associated with terminals, parameters, and relations. The CBL compiler adopts a top-down parsing strategy implemented by a predictive parser. For using this kind of parser the original CBL grammar has been modified to obtain an equivalent LL(1) grammar. LL(1) grammars can be parsed in a deterministic manner by looking at the next input symbol in the input string to be parsed. The advantage in using this class of grammars is that the parsing algorithm is efficient (its performance is a linear

Artificial Intelligence in Engineering, 1989, Vol. 4, No. 3

Task dependent tools for intelligent automation: R. Leitch and A. Stefanini function of the input string length), and can be easily implemented because the parsing table it uses is directly obtained from the grammar rules. The Causal Ordering System analyzes a CBL model and provides a partial ordering between the variables referred to in the set of equations t°. This ordering reflects the causal dependencies between the variables of the model. This is defined once one establishes which variables of the model are exogenous, i.e. their values are assumed to be determined by the system environment and not by other internal (endogenous) variables. Once these have been identified, the causal ordering method performs an analysis (i.e. independent from a specific set of values) of the equations set in order to identify a unique ordering between the variables. The affected variables are said to be 'caused' by the former ones. The exogenous variables are considered as the 'primary causes' that drive the system. In summary, causal ordering permits a causal interpretation of a mathematical model. Mathematical models do not contain causal information: for instance, the equation

c=a+b can be interpreted procedurally to compute either variable 'a' given 'b' and 'c' or variable 'c' given 'b', or 'b' given 'a' and 'c'. Determining causal ordering on a model means to select only one intepretation among all the possible ones. It has recently been argued by Iwasaki x~ that if the model is in terms of dynamic equations then the ordering obtained corresponds to our intuition of causality. Constraint Propagation is a simple way of interpreting a set of equations represented by a constraint net. It consists of cells each of which represents a system variable; each cell participates in one or more constraint expressions (or constraint devices as defined by Sussman and SteelC 2) each of which is a relation among the cell values; each equation is represented by one or more constraint expressions. Each cell may have a value, which may come from the user or may be deduced from other values using constraint expressions. When a cell is assigned a value, each constraint it participates in is considered to determine if enough information is available to deduce a value for another cell. Discovering a new value may thus allow many other values to be determined thus 'propagating the constraints'. Basically, constraint propagation is a technique for solving systems of equations. It has some advantages over traditional techniques, in that it applies when the equations are nonlinear and redundant, and it is efficient even when the equations are extremely sparse. Another advantage, with respect to techniques based on algebraic manipulation, is that constraint propagation may work when the operators do not define a mathematical field as it is the case for the operators used in Qualitative Physics. Two features of constraint propagation are relevant here: -

-

the simplicity of the propagation algorithm. Different from many classical analytical and numerical methods for solving a set of equations, constraint propagation is so simple and natural that it can be said to mimic the simplest reasoning process one may use for inferring values based on a set of equations. The direction of propagation is not fixed. In other words, propagation is not committed to solve for a particular predetermined set of unknowns, nor is it

commitedto use a particular constraint expression in a predetermined way. This powerful feature is useful when the equations representing a physical situation are independent on how they will be used for a particular task. Constraint propaghtion is therefore one way to use the same description for different purposes. The simplicity of the basic constraint propagation algorithm has a drawback: the local nature of the propagation strategy sometimes does not produce a solution to the simultaneous equations. In those cases, the propagator has to be augmented by domain specific heuristics or coupled to a symbolic manipulation capability on algebraic expressions, in order to overcome the resulting propagation stuck condition. Perhaps the main advantage of constraint propagation is that the algorithm is simple, so that it is relatively easy to keep track and show the user the process that generated a given result. In fact, if this result is not clear or perhaps wrong, the structure of the process that derived it may be used to analyze the problem. Therefore, often programs implementing constraint propagation keep track of the reason for their computation process from the start. A truth maintenance system (TMS) is ordinarily used to record the propagation history: each time the constraint propagator computes a value, it sends the TMS the constraint device rule used to compute that value (justification) and the arguments to which the rule was applied. Following the justification chains, it is possible to explain why a variable has a particular value. The constraint propagator provided by the kernel toolkit is coupled to an assumption-based truth maintenance system allowing multiple quasi-concurrent propagation in the net. In a diagnostic problem solver, each propagation may simulate the system behavior in presence of a given fault. This diagnostic strategy is adopted in the Ontological Identification Tool we overview in a following section. The kernel Toolkit provides, as a tool component, an Assumption-based Truth Maintenance System (ATMS) la. Conventional, justification-based, TMSs such as the one by DoylC 4 associate a state of in (believed) or out (not believed) to each problem solver datum. The entire set of in data defines the current problem solver context. The task of the TMS is to keep consistent the data base, adding and removing data from the in and out lists at each inference made from the problem solver. In conventional TMSs the notion of context under which a datum is believed is implicit, as there is only one in list. The ATMS removes this limitation of conventional TMSs, as each datum is labeled with the set of assumptions, i.e. the context, under which it is believed. The basic idea is that the assumptions are the primitive data from which all other data are derived, thus they can be manipulated more conveniently than the data sets they represent. There is no necessity that the overall data base be consistent: it is easy to refer to contexts and to move to a different point of the search space. Adoption of a TMS forces a dean distinction in a problem solving architecture, between a component solely concerned with the domain knowledge (the proper problem solver), and a component solely concerned with recording the current state of the search (the TMS). This problem solving schema is particularly suitable to those tasks where there is a great deal of similarity among the points in the search

Artificial Intelligence in Engineering, 1989,, Vol. 4, No. 3

137

Task dependent tools for intelligent automation: R. Leitch and A. Stefanini space: results obtained in a region of the search space can be carried to other regions, without giving up coherency or exhaustiveness of the search. The functionality provided by an ATMS is general enough to envisage its use in a variety of tools. ATMS allows problem solving architectures where multiple potential solutions are explored simultaneously. These architectures are particularly suitable for tasks where a reasonable fraction of the search space is explored. Therefore an ATMS can be used as the basic building block for solving synthesis (planning) problems; and for designing powerful control schemes where various knowledge sources (for instance, ontological and empirical) contribute to solving a given problem. Currently, the main task that the ATMS has been used for (indeed, the application ATMS was designed for) is diagnosis, especially under the assumption that multiple faults can be present. In particular, the General Diagnostic Engine (GDE) by De Kleer and Williams 15 represents the most advanced example of diagnostic problem solving using constraint propagation coupled to an ATMS.

the GS, activating other graphs when an initial condition (expressed within the manager graph) is satisfied. The kernel toolkit provides two tool components related to Event Graphs: (1) the Graph Manager, which is basically a syntaxoriented graph editor. It provides functions for displaying, editing, parsing and translating a graph into an internal representation; (2) the Graph Set Manager, which provides functions for defining, activating and interpreting a Graph Set. We will overview hereinafter some distinctive features of the GS manager, in particular those relevant to interpretation, which will clarify the GS semantics. The GS is associated with a condition representing the goal the GS should reach. The GS interpreter can be represented by the following loop: LOOP (1) if the condition-to-prove is evaluated TRUE, stop the GS interpretation and return PROVED. (2) identify the list of enabled transitions. (3) if this list is empty, stop the interpretation and return BLOCKED. (4) identify the list of fireable transitions. (5) if this list is empty, stop the interpretation and return STEADY. (6) choose a set of transitions in that list. (7) fire these transitions. END LOOP

4.2. Tool components supporting the event-graph language The Event-Graph language is suitable for representing procedures of various degrees of complexity. It is also suitable for expressing concurrency between different events and actions being represented in a single graph. The Event-Graph interpreter of the kernel Toolkit, the Graph Set Manager, embodies several enhancements to the basic Event-Graph language. It is well known how useful it is to introduce modularity concepts into procedural languages. In particular it allows:

A main point affecting the Event Graph semantics is the conflict resolution strategy of step 6. The GS manager makes available three strategies: -

(a) procedural refinement, and (b) parallelism among a set of separate procedural actors. In the Event-Graph language, procedural refinement has been achieved by introducing a graph as a specialization of a place of another graph. This feature implies that the refining graph has a single input place and a single output place. The refining graph, i.e. the procedure, is invoked when the place being refined is marked. When this happens the mark is passed to the input place of the refining graph (the called), and the interpretation of the graph being refined (the caller) is suspended until the mark has reached the output place of the refining graph. Parallelism and concurrency can be expressed through the concept of a Graph Set (GS). This is a set of event graphs interpreted together in order to achieve a complex task (monitoring, diagnosis, control, etc.). For instance, in monitoring it is useful to associate a graph with each hypothesis giving an explanation of the data to be interpreted. Each hypothesis implies an interpretation, i.e., a given sequence of observations and tests to be performed; this sequence is represented by the associated Event Graph. The different possible interpretations are run in parallel, each one trying to validate or reject the relevant hypothesis. The management of such concurrent hypotheses Can be achieved through another graph, in charge of activating and possibly de=activating single interpretations. This uses a comparison between the state reached by different interpretations, which is represented by the current marking of the relevant graph. In such a schema, the manager graph appears to be as the root o f

-

-

138 Artificial Intelligence in Engineering, 1989, Vol. 4, No. 3

The first strategy is to fire only one transition in a cycle, whatever graph it belongs to. Here, no management of concurrency is made by the interpreter. That means that the user has to explicitly represent the coordination of the execution of the set of graphs. For example, one graph can be designed in order to control the interpretation of the others. Moreover, if no explicit control is designed, the graphs are not independent. Indeed, as an action in a graph can change the value of the condition of a transition in another graph, the evolution of the internal state of each graph is dependent on the implementation of the interpreter. Thus, the set of actions taken during an interpretation of the GS cannot be determined by the user. Note that this strategy is useful precisely when actions are independent, i.e. if the sub-processes represented by several graphs are totally independent (each involves a completely different set of variables). In the second strategy, one transition is fired in each active graph. Thus, in each cycle of the loop, every graph progresses. This can be the case, for instance, if several graphs are activated at the same time to solve the same problem in different ways. Each time the stop condition is tested, each graph has evolved. The third strategy enables the firing of all possible transitions. In that case, the process represented by the GS is considered as a state process. The stop condition is evaluated only when the GS has reached a state where all possible actions have been undertaken.

The general philosophy behind this quite wide set of options is to provide the user with a tool flexible enough

Task dependent tools for intelligent automation: R. Leitch and A. Stefanini to be adapted to specific requirements. Similarly, the language currently does not impose any particular limitation about the visibility and modifiability of the marking of one graph in the set from another (i.e., the way a graph can control and influence other graphs). In this respect, a possible solution would be to define a graph hierarchy within the GS. The GS would have a root graph (started when the GS is activated). The root graph would be able to activate, modify, and deactivate a set of children graphs, which in turn may be allowed to activate their children set. Communication/Synchronization among graphs at the same level in the hierarchy can be obtained giving to each graph visibility, but no capability of modification, upon the marking of other graphs in the set.

4.3. Tool components supporting the Fuzzy Rule-Based Language Regulatory feedback control is the best known application of fuzzy logic. Therefore the design of the toolcomponent supporting interpretation of the FRBL has mainly been undertaken with this application in mind, basically supporting a decision task. It is believed that the tool-component is general enough to be used as the basis for other systems, e.g. classification-based diagnostic systems. In control applications, operator knowledge mainly refers to decisions about what to do in a given situation based on actual and historical information about the process. This kind of knowledge is typically gained through experience, and thus is often referred to as 'compiled knowledge'. The fact that the knowledge is compiled makes it efficient (the search space is minimized), but the application area of the knowledge is highly specialized, e.g. changes in control strategy means re-engineering of the knowlege base. As the primary application envisaged for the Fuzzy Rule Interpreter is regulatory feedback control, it is implemented as a forward interpreter. The structure of the problem knowledge base is considered as a class with descendent classes terminating with member objects representing fuzzy rules. A fuzzy rule can be a member of one or more classes. This structure is reflected by the interface of the tool-component. In fact, the tool-component is implemented as an object, only accessible through methods (functions). The methods thus define the interface of the tool-component. Besides the default methods to handle the loading process, the main methods attached to the tool-component allows the interpretation of a single rule, or a rule class, or of the whole knowledge base, and allows testing of the grade of fulfilment of a rule premise and the maximum grade of fulfilment of a rule class and of a knowledge base. Furthermore, the toolcomponent provides methods for editing, storing, and retrieving fuzzy knowledge bases. 5. TOOLS OF THE KERNEL TOOLKIT Although the above tool components have been designed as part of a specific tool they are sufficiently general to be used in a number of tools developed for different tasks to be incorporated into problem solving systems. The range of possible tools is given by the set of primitive tasks (five), the sources of knowledge: ontological and empirical, and the choice of procedural or declarative representations. Thus, 20 separate tools are possible by utilizing the modularity of the Functional level of the Toolkit and the

task classification of the Teleological level. During the first phase of the project five of these tools have been implemented and validated on the demonstrator applications. Figure 9 summarizes the current state of the kernel Toolkit, in tabular form. A short description of each of these is now given.

5.1. The ontologic interpretation tool This tool is basically designed to translate a set of input data (ideally taken from sensor readings) into the actual state, according to a given model represented by the CBL, of the artifact which is being monitored. Thus the tool performs the interpretation primitive using an ontologic model. To this aim, the tool is built around the constraint propagator tailored for propagating real values. The tool also embodies: -

-

the CBL compiler, for translaing the CBL source model into an internal representation suitable for processing by the causal and constraint net generators; the ATMS (for checking consistency of potential solutions generated when a loop is encountered).

In addition to its basic function, the tool also computes and stores a reference state from given reference values of a subset of the state variables; and computes the qualitative variation between the actual and the reference state.

5.2. The ontologic identification tool This tool identifies an unknown state of a system, whose ontologic model is represented with CBL, by comparing its actual state with the state variation caused by each one of a set of fault mechanisms. The state identification is actually done using a qualitative representation based on vectors that represent the qualitative variation of the actual state with respect to a reference state; this is compared with the qualitative variations which are induced by each fault mechanism. Fault mechanisms, in turn, are represented as the qualitative variation (with respect to its reference value) of a parameter being directly affected by the fault cause. For instance, a fault in a hydraulic circuit induced by crusting of the inner wall of a tube is represented as a qualitative decrease of the cross-section of the tube. The tool uses the constraint propagator for propagating the effects of the fault mechanisms over the qualitative model of the system, and makes intensive use of the ATMS coupled with the constraint propagator for checking consistency of the qualitative variations associated with each fault with the state variation actually observed. In this way, the tool implements the primitive task of identification to establish the particular fault mechanism that is generating the observed misbehavior. The causal ordering system is also embodied within the tool, in order to discriminate between sources of 'propagation stuck' conditions in the constraint propagator. Essentially, this allows the detection of 'loops', due to simultaneous equations, from ambiguities generated by the indeterminacy of the qualitative algebra. 5.3. The empiric decision tool This tool is designed to determine the value of a set of output variables based on values taken by a set of input variables. These input variables are assumed to be expressed in the form of the adopted state representation, thereby assuming that its input is taken from another tool

Artificial Intelligence in Engineering, 1989,, Vol. 4, No. 3

139

Task dependent tools for intelligent automation: R. Leitch and A. Stefanini

LEVEL

GENERIC TERM PRIMITIVE

QUIC TOOLKIT

STRATEGIC

Human

A_N.Otl~r

Ol~ragor Engineer

TACTICAL

System

Diagnosis

Ontologic

Control

Fuzzy

Diag. Control

System System

Simulation Monitming

TELEOLOGICAL

FUNCTIONAL

Task

Co~t

Im~xe=aon

Onmlogic

Prediction

Ontologic

Idenlificzfim

Onlalogic

Decision

Empidc

F.xecudon

Empiric Interp. Tool

Knowledge Pep.

Component Based Language

Inference

Iamrp.

Tool

Prediction Tool Ideal Decision

Tool Tool

Fuzzy

Rule-based

Lang.

Event

Graph

Lang.

Constraint

Propagator

ATMS

OBJECT

Softwar~

De~la. to Proc. Tans.

Causal Net Generator.

I.~guage

Common-Lisp

Environment Fig. 9. Existing facilities within the Kernel Toolkit

performing the appropriate interpretation task. Decision is based on a set of fuzzy rules, representing an empiric model. Input variables are referred to by the fuzzy predicates composing the rule premises: output variables are referred to in the rule conclusions. The tool is built around the FRBL interpreter. It may contain, in addition to a fuzzy knowledge base, possibly organized as several rule classes, the binary rule based language as a conflict resolution and focusing mechanism to control activation of the fuzzy rule classes. The tool is designed to be the core of a regulatory feedback control system based on an empiric knowledge base; in this application, fuzzy rules are used to represent the control heuristics of plant operators, and binary rules may be used to represent meta-knowledge relevant to

140 Artificial Intelligence in Engineering, 1989, Vol. 4, No. 3

KEE

activation and deactivation of specific sections of empiric knowledge according to particular conditions (e.g. different configurations and different states of operation of the plant).

5.4. The procedural decision tool This tool provides the functionality of the Event Graph Language and its interpreter for representing and reasoning with procedural knowledge in a graphical format. In particular it has been developed for expressing control knowledge used in sequencing the procedures for changing the state of a physical system, e.g. misattitude correction of a satellite or start-up and shut-down procedures of a rotary cement kiln. It performs the primitive task of decision in that the

Task dependent tools for intelligent automation: R. Leitch and A. Stefanini current state, as held in the set of activated nodes of the graph, is used to determine the next step in the execution procedure. Within the second phase of the project, the procedural decision tool and the empirical decison tool will be combined within a general system for the complete control of system behavior, i.e. change of system state and state regulation, known as servo-mechanism and regulatory control, respectively.

5.5. The empiric interpretation tool The secondary validation of the Fuzzy Rule-Based Language developed a tool for the interpretation of imprecise and uncertain data - known as sensory data validation. This allows domain specific knowledge to be used in attaching a degree of uncertainty to measurements based on previous experience or on the results of previous decision processes. In addition the Empirical Interpretation Tool can be used to obtain a partial matching between the actual state of the system and the desired or anticipated state, thereby allowing a degree of performance degradation to be allowed before a fault diagnosis system is activated. This ability to attach a degree of uncertainty to measurements and interpretations is a crucial aspect in reasoning with complex dynamic systems; further processing will only be as accurate as the data it has to reason with. 6. A SYSTEM BUILT USING THE TOOLKIT: THE ODS The ODS (Ontologic Diagnostic System) 17 is one of the most complex systems built during the first phase of the project in compliance with the requirements of one of the demonstrators. The ODS is designed to perform model-based diagnosis: this diagnostic approach differs from the heuristic classification techniques which have been adopted up to now in a wide majority of diagnostic expert systems. The ODS reasons on an explicit model of the artifact for identifying the cause(s) of a fault. In the ODS, the artifact model is based on ontologic (design) knowledge, and is represented by the CBL. The ODS is designed to be the core of an automated plant monitoring system: it detects a fault condition when it occurs, through interpretation of sensor readings, and successively determines the fault cause based on state identification. Both these basic tasks are performed on the same CBL model of the artifact, using the Ontologic Interpretation and Identification Tools, respectively. These two tools are the core of the ODS processing structure, shown in Fig. 10 below. Once the system is initialized (i.e., the CBL model is compiled, the causal net generated, and the Interpretation and Identification tools given the quantitative and qualitative constraint nets built from the CBL model, respectively) continuous operation of the Interpretation Tool over samples of available sensor readings detects those system state variations which correspond to a malfunction. When a malfunction is detected, the Identification Tool is activated, resulting in the identification of a subset of the faults associated with the plant model as likely causes of malfunctions. Identification is generally incomplete because the actual state of the plant is partly unknown. In fact, the ODS has been designed to cope with situations where the measurements which can be taken on the plant have different costs and reliabilities. Thus, it first pro-

cesses the set of measurements having minimum cost and maximum reliability (in practice, a set of measurements which are always available through the standard monitoring equipment of the plant). When these are not sufficient to single out the malfunction cause, a new measurement is selected and initiated, and the Interpretation Tool restarted to expand the actual state. The selection procedure takes into account heurstic information (e.g., measurement cost and reliability), but it mainly relies on the plant model, as the new measurement selected, among the ones having the same cost and reliability, is the one which has the higher discriminating power with respect to the likely faults. Note that this • selection procedure is the main part of a decision block, within the ODS, formally equivalent to a third tool for Decision. Actually, this block has not been implemented as a standard tool of the kernel, because the decision logic was felt too dependent of the specific diagnostic regimen required by the demonstrator application, and its functionality relies on functions made available by the Interpretation and Identification tools. 7. CONCLUSION AND FUTURE WORK From the motivations given in the introduction and the material presented herein, it is clear that substantial progress towards the project objectives has been achieved. In particular, a set of high level tools has been developed that perform generic tasks within the domain of Industrial Automation. These tools are based on a task classification for KBSs in automation that provides a systematic approach to the development and choice of tools for a given application. This classification and the associated QUIC toolkit architecture provides the basis for an applications methodology that allows designers to identify the tools with the aspects of a particular application. This is a substantial improvement over former approaches. Furthermore, the adoption of the task classification within the project has resulted in an improved cross-fertilization between the demonstrator applications, with a mutual understanding gained through the use of a common vocabulary. The distinction between ontologic and empirical knowledge has been endorsed by the industrial partners and by the experience of the validation exercise. In particular, the provision of separate tools for both knowledge sources which are integrated at the systems level, by the KBS designer, provides a powerful diagnostic system that combines the advantages of both sources of knowledge. In fact, it was gratifying to learn that one industrial partner recognized the distinction in the human expertise within the company and that these sources were functionally, and geographically, separate within the organization. The ODS can be seen as combining these separate sources into a general diagnostic system. Primary validation of the kernel of the Toolkit is now complete. The results justify the general approach taken in this project and have shown that the multi-level architecture provides a consistent decomposition for the range of tasks undertaken by the demonstrators. It has allowed a thorough testing of the main tools and toolcomponents, and has pinpointed several inadequacies. Phase II of the project, currently underway, is augmenting the Toolkit in a number of ways: relevant to the CBL, several minor extensions to the language are required, and the operation of the

Artificial Intelligence in Engineering, 1989,, Vol. 4, No. 3

141

Task dependent tools for intelligent automation: R. Leitch and A. Stefanini

Data Acquisition

CBL sensor N data

Plant Model

Oualitatb#e Plant model

Ontologic. I Interpretatl°nl ~c

[

NextWait I Sample

= actual state] - reference stale

.

System

yes

]

Initilize

no, malfunction Ontologic Identificatior qualit . . . . . . _ _ and fault models

ult causes Select

New Measurement

yes

yes no

Empiric decision Fig. 10. Structure of the Ontological Diagnostic System

-

-

diagnostic system in its current version is too slow for practical applications; the Event-Graph language has been extended, in order to allow a goal-oriented invocation of graphs; a revised version of the interpreter has been designed providing several conflict resolution strategies; the FBRL proved to be globally adequate for decision making in regulatory control. However the language requires integration with other formalisms (eg. Event Graphs) for representing control policies over the knowledge base in a clean way.

In secondary validation, currently in progress, the languages and tools of the kernel are tested on a case taken from a different demonstrator, namely: -

142

the FBRL on a problem of sensory data interpretation in DEM-1; the CBL for diagnosing an electrical on-board equipment in DEM-2, and simulating the kiln behavior in DEM-3;

Artificial Intelligence in Engineering, 1989, Vol. 4, No. 3

-

Event-Graphs for keeping track of and controlling procedures during kiln start-up and shut-down in DEM-3; In conclusion the basic architecture appears sound; the set of tools that has been developed has opened up a range of applications for possible further experimentation, and the modular approach to defining tool components has allowed the re-use of components in other tools. For the future, the project intends to further experiment with the existing tools by (1) improving the communications between tool components, (2) integrating tools together to provide further extensive systems, (3) investigating the coupling of two systems together to develop a complete application KBS. In addition, new tools are foreseen. The research activity within the current phase has focused on the development of a tool component for reasoning with

Task dependent tools f o r intelligent automation: R. Leitch and A. Stefanini

dynamic models of physical systems. This has resulted in a prototype of a 'predictive engine' tool component that utilizes temporal constraint propagation techniques 16. This prototype will provide the basis for a full implementation during the second phase of the project. The predictive engine tool component will be coupled to the CBL to provide an Ontologic Prediction Tool (OPT) that can be used within a number of systems but most obviously in a simulation system. The availability of this tool greatly extends the functionality of the toolkit and allows all of the generic tasks to be supported. The realization of an advanced set of KBS tools and the development of an applications methodology has resulted in significant progress towards a systematic approach to the development of sophisticated automation systems for complex industrial applications.

4

5 6 7 8

9

8. A C K N O W L E D G E M E N T S

10

This paper describes developments partly undertaken within E S P R I T project P820, partly funded by the Commission of the European Communities within the E S P R I T programme. Project P820 consists of a consortium composed of CISE, Aerospatiale, Ansaldo, C A P Sogeti Innovation, F. L. Smidth, Framentec, and HeriotWatt University. The authors want to acknowledge here the contribution of all the members of the project team to the ideas expressed in this paper, while taking full responsibility for the form in which these ideas are expressed. The authors would also like to thank the reviewers of the original manuscript of this paper for their helpful clarifications and comments.

11 12 13 14 15 16

17 9. R E F E R E N C E S

1

Laffey,T. J., Cox, P. A., Read, J. Y., Kao, S. M. and Schmidt, J. L. Real-time Knowledge Based Systems, The A1 Magazine,

2 3

1988, 9(1), 27-45 Bobrow,D. J. and Hayes, P. J. (Eds). Qualitative Reasoning about Physical Systems, Artificial Intelligence Special Volume, 1984, 24, I-3 Laurent,J. et al. Comparative Evaluation of Three Expert

18 19

System Development Tools: KEE, Knowledge Craft and ART, The Knowledge Engineering Review, 1986 Leitch,R. R. Task Classification for Knowledge Based Systems in Industrial Control, ESPRIT Project 820, Internal Report IR2.10, 1987, Heriot-Watt University, Intelligent Automation Laboratory. Also, submitted to IEEE Trans. Systems, Man and Cybernetics Frances,J. C. and Leitch, R. R. A Real Time Shell for Intelligent Feedback Control, Control and Development in Expert Systems, M. A. Iramer (Ed.), 1986,CambridgeUniversity Press, 151-163 Chandrasekaran,B. Towards a Functional Architecture Based on Generic Information Processing Tasks., Proc. International Joint Conference on Artificial lntell~ence, 1987, 1183-1192 Zadeh,L. A. Outline of a New Approach to the Analysis of Complex Systems and Decision Processes, IEEE Trans. Sys., Man and Cybernetics, MC-3, 1973, 22-24 Gallanti,M. , Guida, G., Spampinato, L. and Stefanini, A. Representing Procedural Knowledge in Expert Systems: An Application to Process Control., Proc. Int. Joint Conf. on Artificial Intelligence, 1985, 1, 345-353 Leitch, R. R. and Kraft, R. A Real-Time Knowledge Based System for Product Quality Control. Proc. lEE Int. Conf. Control, 1988, 882 Iwasaki,Y. and Simon, H. A. Causality in Device Behaviour, Artificial Intelligence, 1986, 29, 3-33 Iwasaki,Y. Causal Ordering in a Mixed Structure, Proceedings of the National Conference On Artificial Intelligence, 1988,313-318 Sussman,G. J. and Steele, G. Constraints - a Language for Expressing Almost Hierarchical Descriptions., Artificial Intelligence, 1980, 14, 1-40 de Klecr, J. An Assumption Based Truth Maintenance System, Artificial Intelligence, 1986, 28, 127-162 Doyle,J. A Truth Maintenance System, Artificial Intelligence, 1979, 12(3), 231-272 de Kleer, J. and Williams, B. C. Reasoning about Multiple Faults, Proceedings of the National Conference On Artificial Intelligence, 1986, 132-139 Wiegand,M. E. and Leitch, R. R. Developmentof a Predictive Engine for the Qualitative Simulation of Dynamic Systems. To be presented at the Fourth Inter. Conf. on Artificial Intelligence in Engineering, Cambridge, UK, July 1989 Stefanini,A., Cavanna, A., Gallanti, M. and Guida, G. Integrating Empirical and OntologicalKnowledgein an Expert System for Diagnosigofa Steam Condenser. Proc. IEEE International Workshop on Al for Industrial Applications, 1988, 173-178 Bobrow,D. (ed.) Qualitative Reasoning of Physical Systems, Artificial Intelligence, Special Issue, 1984, 24 Chandrasekaran, B. Towards a Functional Architecture for Intelligence Based on Information Processing Tables. Proc. International Joint Conference on Artificial Intelligence, Milan, 1987, 1183-1192

Artificial Intelligence in Engineering, 1 9 8 9 , Vol. 4, N o . 3

143