7.6 Object oriented methodologies and expert systems: CEES

CEES, [De la Rosa J.Ll, 1994], (C++ Embedded Expert System Shell) was firstly conceived for supporting co-operative ES. From that time on, CEES was subject to many modifications and extensions in order to make it useful in industrial process supervision. Several efforts have been done in the context of this thesis; see for example [Sàbat, 1996] and [Martinez, 1997]. This effort has resulted in a new version of this shell, CEES 2.0. It has been developed in the scope of this thesis following two parallel and complementary lines. The first one was to achieve a stand-alone application with external communication capabilities and graphical user interface for assisting the definition of knowledge through the development of production rules. This version has been called LabCEES. The second, and more interesting from the point of view of this thesis, consists in embedding the CEES 2.0 inference engine into a framework with other tools for assisting the design of supervisory systems. It is called SimCEES. With the same goal as previous presented tools, ALCMEN and abstraction tools, SimCEES has been embedded in MATLAB/Simulink to assist supervisory systems design in a friendly to use framework (CASSD). The use of a graphical block representation for an ES representation facilitates the comprehension and use of this tool. The goal is to use the stand-alone application, LabCEES, for the final application and the CASSD framework in the developing time. The benefit of this redundant implementation of the ES is that rule bases could be directly used by either.

CEES features. Advantages and drawbacks.

Object-oriented approach/methodology constitutes the core of this shell (CEES) because it is intended to exhibit capabilities of encapsulation of information, polymorphism of methods and data abstraction. Four basic classes were defined to deal with variables, facts, inference engines and simulators. Deductions are performed by inference engines through reasoning about its input facts, but they also have the capability of asking for information to other inference engines (facts) or simulators (variables). In the new version (LabCEES and SimCEES) some of these classes have disappeared and only remains the classes inference-engine and facts. CEES main capabilities are pointed here :
 

• Facts are the kind of data supplied to the ES to perform some reasoning. Facts are objects embedding both, numerical and/or qualitative data and subjective information about this. For example certainty is used to represent doubt about source of information and fuzzy sets can be build around numerical data to perform fuzzy comparisons.
• CEES is a rule-based system with specific syntax and forward chaining inference mechanism.
• Co-operation among ES is performed by exchanging information (encapsulated as objects representing facts) between inference engines and asking simulators about numeric variables.
• Qualitative values are defined in terms of orders of magnitude. Simple operators were added to deal with them. Methods and qualitative fields are encapsulated in the same object associated to numeric variables.
• Reasoning with temporal windows. Data history is stored in CEES variables in temporal sliding windows for making inference about trends of process variables in the temporal window.
• Fuzzy reasoning is incorporated in CEES on the base of logical comparison of variables by means of the equal, lower and greater operators.


Mainly, due to the fact that CEES is based on C++ objects, some advantages turn into shortcomings at the moment of developing the ES application. Some of these points are highlighted below:
The main advantages are :
 

• CEES is a flexible open shell subject to continuous evolution. Addition of methods or objects to solve specific situations is allowed.
• CEES variables are conceived as objects with encapsulation of data and methods similarly to the object-variable structure described in the previous sections.
• The implementation of facts used in CEES is directly applied as a higher level data structure of object-variables. Thus, expert reasoning about object-variables is accomplished directly.


Some drawbacks can also be pointed:
 

• The current version of CEES is not user-friendly. The user must be familiarised with C/C++ programming and a training period is needed before starting the development of ES applications.
• The use of C++ objects, with complex structure, in the definition of systems (simulator and inference engines) and variables (variables and facts) makes the interpretation of global architecture of ES difficult.
• No external interface is provided with CEES. Despite of this drawback, DDE- Dynamic Data Exchange and any C/C++ library can be directly used.


New version, CEES 2.0 has been developed in this thesis to avoid this drawbacks. This is CEES 2.0 and the implementation has been designed for two platforms : LabCEES, directly under Windows and SimCEES under Simulink. CEES has evolved towards two separated and complementary products (LabCEES and SimCEES), especially conceived to be used by process engineers :
 

• LabCEES is a stand-alone shell running under Windows. A friendly user interface has been added to assist in configuring ESs architecture. This is, the number of inference engines, rule bases, facts bases and related parameters. A graphical user interface assist user in these tasks.
• SimCEES, is conceived to run under Simulink as a block. A SimCEES ESs are conceived to deal with facts. Thus, both, input and output are facts. Output is obtained as deduced facts from reasoning about input facts. Any ES block is defined according to the structure of a rule-based knowledge. Multiple architectures could be defined by adding or moving ES blocks.


An additional feature of CEES 2.0 is the exportability of rule bases between SimCEES and LabCEES. This increases the flexibility to test and compare different structures and knowledge bases before the final implementation. Modularity is present in both implementations.

SimCEES : Implementation of an ES in MATLAB/ Simulink.

Simulink has been chosen to develop a set of ToolBoxes to deal with the design of expert knowledge Supervisory systems. In previous sections abstraction tools have been presented to process numerical information and to interface with qualitative representation of process variables. ALCMEN has been introduced as a mechanism for representing simple relationships between qualitative data. When more complex knowledge structures are needed to represent special expertise, as is the case of expert supervision applications, then ESs are used. Therefore, the implementation of an ES ToolBox for Simulink is needed to complete the framework for supervisory systems design.

The shell CEES has been chosen to be integrated into Simulink as a new block. As a result, this shell has evolved to SimCEES (CEES 2.0) especially conceived to work under the block representation. The object structure of CEES has been simplified for this purpose. The simulator class has been suppressed because this facility is supported by Simulink (for numerical simulation) and ALCMEN (for qualitative simulation). The class variable has evolved to object-variable definition to preserve the integration mechanism. Then, only facts and inference engines remain as SimCEES classes. Facts are the objects supplied to the ES at its input and deduced and available at the output. Inference engine include the reasoning mechanism used for these ES. Facts are basically objects encapsulating object-variables and other attributes (certainty and landmark, for instance) and methods needed for the inference engine mechanism.

The Simulink implementation of SimCEES is represented in Fig. 5.25. Any Simulink block used to represent a knowledge base is formed by an inference engine and a rule-based. In execution time, facts base is created and actualised according to deductions performed.

Fig. .25 Simulink block implementation of an ES

SimCEES is intended to work on-line with process variables (object-variables), encapsulated as input facts. Consequently, it works as a discrete system according to a sampling period. The input facts encapsulate the information related to process variables, object-variables is actualised each sampling time. Consequently the rules base must be evaluated, by the inference engine, at any actualisation of input data to deduce new facts. Results are also given as facts and the outputs are selected from these deductions. The benefit of working with facts only, at input and output, gives the possibility of connecting directly to another ES blocks at the output, as depicted in Fig. 5.26.

The main benefit of modular block representation, supported by Simulink, when dealing with ES is the distributed knowledge representation because of:

Modularity : The partition of large KB into smaller KBs.

Specialisation and reusability of knowledge bases. Supervisory systems should be designed to reuse knowledge, especially in distributed AI systems where the same KB can be applied in solving similar problems in the same process. For example, expert tuning of PID is a domain where the same KB can be reused for several purposes. These KB can be reinforced by process knowledge declared in other KB although basic rules are preserved.

Flexibility, in designing and testing ES-based architectures. Modifications in the architecture of the whole ES can be performed by simply moving a block.

The implementation and easy testing and comparison of special architectures based on redundancy, competition, reinforcement or co-operation.

Some problems are inherent to the choice of using Simulink interface instead of developing a new one for SimCEES. Despite the graphical support for manipulating ES as a single block used in Simulink for representing an ES, there is no support for editing rules. The user must use a standard editor for this purpose.

Expert Reasoning with SimCEES.

In the previous section the benefits of modularity of SimCEES have been introduced. The graphical support of Simulink by means of block representation permits an easy reconfiguration of the ES associating a block to each KB. When working with large and complex problems, the solution is easier if it is divided into sub-problems, because small knowledge bases are better structured. Modularity in SimCEES is possible because a single structure for data representation is used. All available information in object-variables (numeric, qualitative, symbolic or logic) coming form process variables is embedded together with attributes and methods needed for the ES inference engine into a new object structure called facts. These facts preserve the same structure for any ES input and output. Consequently, inference engines must reason about evolution of input facts, firing the appropriate rules in the knowledge base to deduce about these input facts or other previously defined in the knowledge base. ES outputs are selected from deduced facts base at each sampling time.

Fig. .26 Input and Output of ES blocks are facts.

In practice, output can provide not only deduced facts, but also input facts to facilitate the flow of facts among ES blocks, avoiding an unnecessary amount of lines connecting blocks. Facts declared in a knowledge base cannot be supplied as output, except when they have been deduced. When using parallel configurations of ESs blocks (the output of these ESs, see Esii and ESiii in Fig. 5.26, are supplied to the same ES, ESiv in Fig. 5.26) there exists the possibility that the same fact will be supplied, at the same sample time by two or more different blocks as input of another ES block. In such cases there exists a possibility to differentiate those facts or use only one of them. In case of the second option is chosen, priority is given by graphical connection order.

An example of how this mechanism works with facts is depicted in Fig. 5.26. In this figure, facts are represented by symbols as , , , , , ,  and . The evolution of these facts is represented in a sampling time, showing the facts supplied for four interconnected ES blocks. For instance, ESi deduces , while at the same time it can also supply input facts to be processed by the next block. On the other hand, ESii can only supply deduced facts. It can be observed that some deductions are from external input, , while other are defined in the same ES, . A different situation is presented in ESiv. In this case, not all deduced facts are supplied at the output (See fact ). A reason for this, could be that this deduction causes a message to be printed; therefore, it is not needed at the output.

Fig. .27 Example of rules based knowledge declaration in SimCEES.

 

A simplified example of how rules are described in SimCEES and declaration of input and output facts is shown in Fig. 5.27. This could be the rule base associated to ESiii, where output facts are selected from input (-"input1", -"input2", -"input3") and deduced (-"difer" and  -"input2"). Facts are used at input and output to provide a fact flow. This is needed when working with dynamic systems and facts represent some abstracted feature of this behaviour. The final goal is to use the facts to close the supervisory loop.

Exportability of rules. LabCEES, the stand-alone application.

The new version of CEES (CEES 2.0) has a double implementation. The first, SimCEES, is described in the previous subsection and runs under Simulink. The second, LabCEES , is complementary to the first one, and is conceived as a Windows based stand-alone application. LabCEES is still under development, but the goal is to provide this shell with a graphical user interface for assisting ES configuration and rules production. LabCEES is an open system with communication capabilities for interfacing the application with monitoring systems and other Windows based programmes using dynamic data exchange (DDE).

LabCEES is prepared for dealing with modular ES, structured in more than one inference engines. To achieve this goal, inference engines are provided with communication mechanisms to interchange deduced information (facts) according to their own rule base. This approach permits to reuse rule base in SimCEES, building identical structures representing the inference engine as independent Simulink blocks.