Control Engineering and  Intelligent Systems Group

Description and Features

LabCEES  is a component-based framework to develop communicating expert systems under control of execution programs, which are jointed as modules of ESSs. It provides an architecture, methodology and user-environment to develop applications.

The main benefits of LabCEES are:
 

• A modular way to supervise industrial processes: expert systems should accomplish supervision tasks in order to supervise sub-processes (of a process), whose interactions should permit to supervise the global process.
• A way to treat the process information and structure it as knowledge for expert systems: Data and situations should be described in terms of facts and rules using pre-defined structures. LabCEES provides pre-defined types to define facts and the so-called “LabCEES grammar”  to write rules. LabCEES grammar specifies the structure of the knowledge of expert systems, and the structure of communications between expert systems, with processes and other software applications.
• A component-based structure to develop ESSs: expert systems (and the other components, see the definition of LabCEES components) are self-defined entities to deal with the multiplicity/sharing of tasks and information. Facts and rules could be shared in multiple knowledge bases. That means, multiple expert systems with smaller knowledge bases should compose ESSs. Expert systems (and the other components) are easier to understand, to build and to maintain than huge ESSs.
• Problem-solving focused components: all process information (data and situations) is not needed for solving every task in a supervision procedure. Expert systems should be designed and developed in a way that is more appropriated to results.
• Data interface: LabCEES has a pre-defined mechanism (based on DDE ) for inputting/outputting data from processes. It also constitutes interface between software applications and expert systems.
• Shared components: different expert systems could use data from a same fact base, from a same extern (see the structure of LabCEES components). Also, they could use a same interface to communicate with processes or other software applications.
• Tasks/information sharing: none of expert systems in an application should have global view of the solutions. They should share information (facts, partial results and so on) to arrive to global solutions.
• Flexibility/reusability of components: an application can be defined or modified by adding or removing components, whether facts, rules, fact bases and so on. Also, once a set of components have been constructed for an LabCEES application, it should be possible to construct new ones that use these components.
• Evolution/maintenance: if a process changes, the modifications on the LabCEES application must be done only on the components where the changes are involved. Also, it should possible to replace and/or to add components to modify the application structure according to process configurations.
• Openness: LabCEES applications could be integrated with other software applications in different supervisory control environments. So, implementations of data interfaces might be adapted as part of those applications.

Definition of LabCEES Components

LabCEES application is defined as an “application composed of interactive expert systems for reasoning (detecting and diagnosing faults) about the process behaviour in order to propose appropriated actions to maintain the normal operating conditions in case of faults”.

The process constitutes the environment with which expert systems interact. The process provides data to expert systems, which decide actions on it. Variable measurements (and additional information from them) constitute facts. Set point changes, parameter re-tunes and so on constitute actions to execute on the process. Messages to humans, e.g., showing messages on screen and so on constitute also actions.

The behaviour (the way of act) of expert systems is not prefixed to support determined service; any expert system could deal with data and situations and could interact with process and humans. Mappings of situations as LabCEES rules constitute knowledge of expert systems.

Six kinds of components so-called data interfaces, fact bases, rule bases, expert systems, externs and mains are defined. The behaviour of a component is determined by the services that it must support to a LabCEES application for treating information and for interacting with processes (and non-LabCEES applications). Predetermined charges of those components are:
 

• Data interfaces constitute interfaces with processes and other software applications. They are mechanisms for inputting/outputting data via DDE.
• Fact bases are stores of (updated and historical) variable data as facts. That information indicates to expert systems how process evolves through time.
• Rule bases are stores of situations as rules. Fact bases and rule bases constitute knowledge of expert systems.
• Expert systems are in charge of reasoning on process data and situations. Fault detection, fault diagnosis and reconfiguration are tasks associated those components. Actions are transmitted through data interfaces.
• Externs are in charge of performing support operations for expert systems, e.g. mathematical operations.
• Mains are in charge of running the expert systems.

Operation Cycle among LabCEES Components

LabCEES application is intended to work on-line with variable data according to a sampling period. Variable measures are updated every sampling time through data interfaces. Fact bases store that information. Subsequently, the main executes expert systems. Then, they apply their knowledge on data; rules on facts are evaluated to deduce actions. So, they detect and diagnose possible faults. They take decisions to cope with the detected faults (if exist). At that time, an expert system could request tasks/partial results to one other expert system (if needed). Then and depending on the decisions, expert systems send actions through data interfaces (or messages to humans). At any time, any expert system could request operations to externs (in case of necessity).

Structure of LabCEES Components

LabCEES provides the basic structures for fact bases, rule bases, data interfaces, expert systems, externs and mains. They are software patterns that span the LabCEES components. They will permit developers focus on the task-solving more than on the design of components.

The LabCEES structure has features as:
 

Expert systems share a basic structure consisting of a fact base and a rule base, which constitute knowledge base. They share information by means of the defined method “ask_review_deduce”. The expert system that makes the solicitation to invokes the mentioned method. Then, the target expert system executes its rules based on the sent data.

The fact base consists of a set of facts. Facts share a basic structure consisting of an object that embeds both variable values (measurements, estimations, indices and so on) and parameters (threshold, landmarks, ranges and so on), and methods for obtaining an adequate description of the variable behaviour (signal processing and so on).

The rule base consists of a set of rules which situations that determine the process behaviour are mapped on. Developers use the “LabCEES grammar” to write rules. C++ language code can be combined with rules.

The main is a C++ language program. That program runs expert systems. The content is made of instructions in LabCEES grammar and/or C++ code.

The extern is a C++ language program. The operations are made of instructions in LabCEES grammar and/or C++ functions.

Data interface is a DEE-based mechanism. The identification and type of variable measurements are defined in those interfaces. Expert systems and non-LabCEES applications use those mechanisms for interchanging data.

LabCEES Development Methodology

LabCEES methodology is a set of guidelines to apply the basic structures of components and communication mechanisms in the design and development of applications. It specifies how to treat the process information and to structure it as knowledge for expert systems. It also specifies how to treat interactions among expert systems and with process (and other software applications) . It is mainly focused on the organisation of process variables and situations as facts and rules.

LabCEES development methodology has four phases:
 

• Analysis: refers to the process analysis. This involves a set of steps:
• Identification of process variables: focused on “what and how many” variables.
• Extraction of behaviour situations: focused on “what” situations determine the process behaviour.
• Formulation of actions: focused on “what” actions, e.g. set point changes, parameter re-tunes, messages to humans and so on.
• Design: refers to the design of components. This involves a set of steps:
• Identification and definition of components: focused on “what and how many” fact bases, externs and expert systems.
• Allocation of variables into fact bases: directed to the distribution of variables into fact bases according with the decomposition of the process behaviour.
• Allocation of tasks to expert systems: focused on services that expert systems must support, whether fault detection, fault diagnosis or reconfiguration, or mix.
• Allocation of operations to externs: focused on operations that externs could support for expert systems.
• Allocation of expert systems to main: focused on the specification of an order of executing expert systems.
• Implementation: consists in the codification/develop and integration of components. For that, the LabCEES development environment can be used. A set of steps are involved:
• Development of fact bases: facts are created. For that, identification, type and additional information from them are defined. They are stored into fact bases.
• Development of expert systems:
• Rule bases are made using LabCEES grammar.
• Facts (from fact bases) and rule bases are integrated into knowledge bases of expert systems.
• Development of externs: operations are made of instructions in LabCEES grammar or C++ language functions, and integrated into files.
• Development of data interfaces: identification and type of items for interchanging data are defined.
• Development of mains: expert systems are integrated into mains. The content is made of instructions in LabCEES grammar and/or C++ code.
• Debug, link and compilation.
• Evolution/maintenance: focused on modifications of components or the application structure. That is the modification, addition or removing of components, whether facts, rules, fact bases, rule bases, facilitators or main. It involves iteration to some other phase (according to circumstances).

LabCEES Development Environment

LabCEES development environment is an user-interface under Windows to assist the design, development and maintenance of LabCEES components/applications.

LabCEES development environment has features as:
 

• It has fact editor, rule editor, data interface editor and text editor. The fact editor permits to manipulate facts and to develop fact bases. The rule editor permits to manipulate rules and to develop rules bases. The data interface editor permits to manipulate mechanisms for inputting/outputting data. The text editor permits to manipulate C++ language code and to develop mains and externs.
• It has debugging for rules and for mains and externs, i.e., for debugging code in that they should be written.
• It permits to construct LabCEES applications as software projects. That means, components could be manipulated (modified, added or removed) by developers.
• It permits to compile components and to link them as unique, whole systems.

LabCEES Software Products
 

LabCEES Development Environment (installation files)
LabCEES User Manual
LabCEES Methodology Generalities
An LabCEES example

Your questions and suggestions to orlando@eia.udg.es