This section lists the software tools and architectures used to implement expert systems for chromatography.
13.1 Software Languages and Expert System Shells and Tools
Table 2 shows which expert systems for chromatography used which languages 5 and the
aspects of the each system for which a language was used. The table shows that those systems in which the coding was not in one language alone, the AI languages were mostly used for reasoning, and never for numerical processing, where as conventional languages were mostly used for numerical processing and never for reasoning. This reects the strengths of the AI languages: they make it possible to represent knowledge quickly and conveniently p95 of 87] making it easier to code reasoning. The way in which the conventional languages were used also reects one of their strengths: they usually provide better facilities than the AI languages for numerical processing.
The aim of Table 3 is to show which expert system shells and tools were used in the development of the systems. 6
5Prolog and LISP are referred to as articial intelligence (AI) languages. Third generation languages, such
as BASIC, FORTRAN, C and Pascal, will be referred to as conventional languages.
6It does not try to review the shells and tools used or to classify them they are presented in alphabetical
order. No description of the shells and tools is given because of the dierences between the various versions used for dierent chromatography systems.
13.2 Hypermedia
The developers of CRISEBOOK 30] discussed three problems with `traditional' expert systems development software:{
1. Updating and maintaining systems based on this type of software is dicult. \With the conventional present shells it is dicult for the User to make changes owing to the way rules are connected ...Adding or changing rules could have repercussions all over the system."
30]
2. To use some of this software requires advanced skills of knowledge engineering. 3. Systems based on this type of software often have a poor User interface.
The developers of CRISEBOOK investigated whether Hypermedia could be used as an alternative to conventional expert systems development software. \Hypermedia is the combination of multimedia and hypertext. In a hypertext document the User does not have to read all information in a sequential way, but is guided by his needs and interests by pieces of information that are linked to each other. Multimedia is a collection of tools producing graphics, sound, and animation, to present data in a more exible way." 30].
The work on CRISEBOOK did not show whether Hypermedia would make update and maintenance of expert systems easier. The work was inconclusive as to whether advanced skills would be needed to build expert systems with Hypermedia, although the developers of CRISEBOOK reported that the `scripts' that are developed for Hypermedia are \...entirely readable even for those unfamiliar with programming." 30] CRISEBOOK suggested that Hypermedia would enable better interfaces to be produced because data can be presented in a more exible manner and because much of the programming associated with interfaces is already present in Hypermedia.
Problems with expert system development software can not be considered independently. Changing the development software to ease one problem may aect the severity of others or even create new ones. Although CRISEBOOK showed that Hypermedia could help to ease two of the afore mentioned problems, it did not prove that Hypermedia would be a better alternative overall to `traditional' expert systems development software.
13.3 Spreadsheets
Two systems were developed by combining expert systems development software and spread- sheets packages.
In REPS spreadsheets were programmed to produce the necessary statistics. The spread- sheet package used was Lotus 1-2-3 (1986) (Lotus Development Corporation, Cambridge, MA, USA) the expert system tool used, Goldworks, was able to communicate with this. Rules, dened using Goldworks, set up spreadsheets into which the analyst input data, and the rules then interpreted the data processed in the spreadsheet. 36]
In CRIPES VP-Exert communicated with spreadsheets written in VP-Planner (Paper- back Software) 50].
13.4 Architectures
It was vital for the proposed integration of the ESCA repeatability and ruggedness systems that all the modules of the integrated system used the same concepts as the basis for reasoning so that exible communication was possible. Simple transfer of les between modules would have been insucient for two reasons 34]:{
1. Most of the facts produced by one module had to be available to all other modules. 2. The modules were not to be consulted in a standard sequence. Trying to implement
all possible consultation sequences would have become unrealistically complex. It was decided to merge all the existing concepts in one common data structure that formed the basis for all the systems. \The blackboard architecture was chosen7 because it
allows integration of modules which use dierent interfacing or problem solving techniques" 34].
\Blackboards are well known articial intelligence techniques for the integration of expert systems" 34]. They allow several modules to communicate with each other via a common data structure, the blackboard. In a blackboard architecture \...the knowledge sources trigger themselves when the state of the blackboard is such that they can contribute to the solution of the problem. ...In an ideal situation several knowledge sources can be activated at the same time. The blackboard architecture oers the possibility for parallel processing." 34]
The ESCA integrated system did not utilise the possibility for parallel processing oered by a blackboard. In fact all but one of the expert systems were designed for serial processing. The exception was ESP which was implemented as two concurrent processes. The interface, implemented in C, was a parent process and the `intelligence' of the system, the Prolog
7The architecture used for the ESCA integrated system varied slightly from a traditional blackboard in that
code, was the child process. Calls to the UNIX operating system kernel allowed concurrent processes to execute, communicating through UNIX pipes. 49]
13.5 Expert Planners
Some of the systems can be thought of as planners. For example PPA was a planner that planned a purication process from the original source to the nal product. Thus it was a deductive planner as opposed to a reactive planner. Reactive planners, such as P8, immediately respond (without much deduction) to input without forming a complete plan on how the goal should be reached. A deductive planner was developed because reactive planners are \faster but in many senses `dumber' than deductive planners" 68]. A deductive planner had the advantage that it was possible to plan in advance and, where possible, optimise the plan, and the ability to deal with unanticipated purication tasks by reasoning from general rules. However the designers of the system were aware of the major drawback of deductive planners: they can not provide dynamic responses to dierent outcomes of applied operations. P8 was designed as a reactive planner because reactive planners do not have this drawback. \Armed with a certain amount of knowledge ...one can devise a separation plan in advance. The eciency of the plan will depend on the actual outcome of the individual steps. When the results are known, one is better equipped to plan subsequent steps" 69].