We present the current status of a recipe planner for bioprocesses. This case-based ... (1993) pointed out, with CBR one preserves most of a successful solution, so CBR ..... Proceedings of the 2nd Industrial Engineering Research Conference, ... Machine Learning Methods for Planning, Minton, S. (ed), Morgan Kaufmann.
Proc 3rd European Workshop on Case-Based Reasoning, EWCBR-96, Lausanne, Switzerland, November 1996. Lecture Notes in Artificial Intelligence 1168 (1996), 16-27 © 1996 Springer-Verlag
Towards CBR for Bioprocess Planning Robert J. Aarts and Juho Rousu VTT Biotechnology and Food Research P.O. Box 1500, FIN–02044 VTT, Finland {Robert.Aarts, Juho.Rousu}@vtt.fi Abstract. We present the current status of a recipe planner for bioprocesses. This case-based reasoner adapts previously successful recipes for each batch of the process. In this domain, recipe planning is difficult as actual numerical values of recipe parameters are crucial but quantitative information is scarce. However, adaptation, although far from trivial, is less complicated than planning from scratch. Like other case-based reasoners the system learns from experience, whenever the casebase grows. Therefore we expect that planners will automatically tune themselves to different plants. Case adaptation is fully automatic; process operators were never trained for this task. For adaptation, the case-based reasoner calls upon a semi-qualitative model of the process. The model, casebase and index are integrated and allow for indexing on inferences made by the model. All the software is implemented in an object-oriented framework that can be rapidly instantiated for different processes.
1. Introduction Biotechnical process industries have a need for tools that support the implementation of modern manufacturing practice. Flexible production strategies and total quality management require efficient planning of process recipes. In this context planning is the process of selecting appropriate values for those process parameters that need to be decided before every batch of the process. Examples of such parameters are the choice and amounts of ingredients, setpoint profiles, process start and finish times, etc. The set of planned parameters has often been called the process recipe. Current practice is to modify recipes only when several, consecutive, batches yield unsatisfactory results. Planning of bioprocess recipes is very difficult, and recipe modification is perceived as risky. A minor change in one parameter of the recipe might prevent a particular problem, but may simultaneously cause several others. In other words, bioprocess planning problems are hard to decompose and therefore difficult. However, it is expected that batchwise adaptation of recipes will reduce product quality variations, allow more flexible policies for the purchase of raw materials and will increase overall plant productivity. Moreover it is expected that process efficiency increases, to be reflected in a reduction of waste (raw material, energy). Some of these expectations originate from the development of a prototype planner for mashing temperature programmes developed at VTT (Aarts, 1992). Mashing is the first process step in the production of beer and the temperature programme the most important part of the recipe. That prototype was based on a constraint satisfaction approach and was successfully tested in laboratory and pilot scale (Aarts et al., 1993).
However, it had two notable shortcomings. First, that system needed tuning of the rules and fuzzy sets that were used to infer the constraints. Second, this prototype planned only the temperature program used for mashing. Although this is the most important element of the recipe, it was thought that planning of additional recipe parameters could be beneficial. Fortunately, the prototype clearly demonstrated the possible benefits of recipe planning and construction of a new prototype was started, around the case-based reasoning (CBR) paradigm. As it was expected that recipe planning could be beneficial for a number of different processes, the new system was constructed as a generic bioprocess recipe planner that could be specialised. This paper will describe the different parts of the system, using the new planner for mashing as an example. First we will motivate the use of CBR and give an outline of the system. Next, we will describe and motivate the use of a qualitative model in indexing and adaptation of cases. Related work and some of the problems encountered during development will be discussed and the nature of the various types of knowledge in this domain will be analysed. Finally, we will present some ideas for additional futures, some of which may provide some challenges for the CBR community.
2. System 2.1 Problem Description and Motivation for Using CBR In our system a complete case typically consists of a product specification, a product analysis, a list of ingredients, a vessel, and a recipe. The planner should construct a recipe given the product specification, and possibly (some of) the ingredients and the vessel. As stated above, such planning problems are hard to decompose. As Kolodner (1993) pointed out, with CBR one preserves most of a successful solution, so CBR was thought to enable planning of complete recipes, including setpoint profiles, ingredients and perhaps scheduling aspects. This as opposed to constructing only a temperature programme. Another reason to venture into CBR was the desire to have a learning system, i.e. a planner that would benefit and learn from feedback and adapt itself to a particular plant for a process. Upon closer examination, the domain lends itself quite naturally to a CBR approach. A single batch is a quite clearly defined case. Each batch has a goal, the product specification. As a case, a batch has a context formed by the (quality of the) ingredients available, the vessel or other resources to be used, or the current production schedule. In most processes the product specification is rather constant; the most common reason for recipe modification is variation in the quality of the raw materials. Batches for the same product, made from very similar quality ingredients, are made using the same standard recipe; cases with a similar context have a similar solution. Finally, batches with an exceptional context, and causing severe problems, are usually remembered as cases by plant personnel. To our disadvantage, knowledge about recipe adaptation is usually scarce, as the industry only rarely modifies recipes. On the other hand, ample experience is available; most processes run many batches per year or even per week. In addition, a large body of, mainly qualitative, biotechnological knowledge is valid for many
processes. The idea then, was to combine somehow that qualitative process knowledge with the quantitative information that is implicit in the experience from many batches. Although the system can be easily specialised for different bioprocesses, we will focus on one such specialisation, the planner for mashing. Most of the software is rather generic, mashing specific parts will be indicated. 2.2 Case Representation A case is represented as a quite large, hierarchical, object. The product specification is represented as a set of constraints that the product analysis should satisfy. Product analyses, ingredients and vessels are represented as objects, i.e. as instances of predefined classes. All these objects are created by the system from standard database tables that usually reside in the production management system of the plant. The recipe is represented as a, possibly non-linear, action based plan. Some of the actions that may be included are: addition of an ingredient, adjunct, or additive; and heating or cooking steps. A mashing temperature programme consists of rests (keeping the mash at a constant temperature), interleaved with rises (Fig 1). Each rest has a temperature and a length. Rises have a start temperature, slope and end temperature. Most often, the rises are completely determined by the rests; the temperature of the mash is increased as fast as possible. The temperature of the mash is always increased, never decreased. A large number of classes for case representation were implemented, many of which are abstract superclasses that can be subclassed for particular (kinds of) processes. Some examples are: a Mash ⇒ (is a kind of) Bioprocess ⇒ Case;
Figure 1. A limited view on one case, a Mash. The temperature program with rest and rises is shown as well as some of the features of the case.
MashTun ⇒ Vessel ⇒ Resource; Enzyme ⇒ Protein ⇒ MacroMolecule ⇒ Chemical ⇒ Component. As in any object oriented system instances of subclasses inherit the variables and behaviour defined for superclasses. Cases are stored in a casebase. Currently cases are not generalised in any way. This may be necessary, and desirable in the mashing planner, as one brewhouse typically produces 7-8 mashes per day. A meaningful casebase would include several years of experience, that is thousands of cases. Our current solution is to rely on the external relational database for the complete case description and construct the case objects as needed on the fly. So when the casebase is saved each Case is replaced by a degenerate StoredCase that only contains the ID of the mash. Pointers from the index to Cases are made to point to the StoredCases (see also section 2.4). 2.3 Qualitative Model A substantial part of the process knowledge is represented in a (semi-) qualitative model. This model is process specific and has to be created for each application. The model should be able to guide adaptation of recipes. The representation used for this model is based upon Qualitative Process Theory (Forbus, 1984). Within a bioprocess there are active (QPT) processes that may influence process variables. Processes are only active when certain conditions are met. In our representation, variables again may influence the activity of processes. Hence, the model can be viewed as an influence graph, not unlike the representation used (for cases!) in CADET (Sycara et al., 1992). Processes have a degree of activity and influences may have weights. The absolute value of these weights is of little importance, their sole purpose is to indicate that one influence may be more important than another (Fig. 2). This kind of model is a very effective way to represent a large amount of knowledge. A network of processes, influences, conditions and other nodes, represents the paths between causes and effects. It can be traversed forward to predict, and backwards to find means to an end. Naturally, model construction is a significant effort. To facilitate this task a library of building blocks for the model is provided, again as a class library. In this library the more abstract classes provide the functionality to integrate model based reasoning with case based reasoning. The subclasses specialise the kinds of links that can be made from one model node to another. This “construction-set” approach may facilitate future implementation of a module for learning of the model from the cases.
Figure 2. The model editor showing one node of the model. This node represents an EnzymaticReaction, a kind of FunctionalProcess. This reaction only takes place when the conditions are satisfied. If there is α-amylase activity the amount of starch will decrease and the concentrations of the sugars maltose and dextrin will increase. The influences of α-amylase activity on gelatinised starch and dextrin are more pronounced.
2.4 Case Indexing and Retrieval The system maintains an index in the form of a tree. Root nodes in the tree represent a statement that can be made about the case. Evaluation of the statement for a particular case results in a truth value. If this value exceeds a threshold, children of the node are evaluated recursively. The recursion bottoms out at leaf nodes. Leaf nodes point to all cases for which the leaf node evaluated to ‘true’ when the case was added to the case base. The link from a leaf node to a case records the truth of the leaf node for that particular case. If the current case activates a leaf node then, that leaf node activates all the cases that once activated that same leaf node. The index can perhaps been viewed as a “spreading activation” network. When the index is given a target case, the cases in the case base are ordered on their degree of activation. The entries or items in the index are not given a priori, but originate from the cases. Subclasses of Case implement methods that will return index entries in a hierarchical fashion just like the index itself. Most often the case will return an index that reflects its object structure. The planner itself may compute additional entries. The mashing planner for instance, uses the model to infer activities of processes during various plan steps, provided the case was completed (has a plan). Similar use of a process model for indexing was employed in CASEY (Koton, 1989). Any time a case is added to the case base the whole set of entries is compared to the current index. Novel entries are added to the index, whereas (active leave nodes of) entries that are already in the index are made to point to the new case.
Further flexibility is provided by selectors. Selectors are used to represent different points of view for retrieval. For instance, cases with a similar ‘goal’ can quickly be found by activating only the ‘goal’ selector. Each selector activates some of the links from index leaves to cases. These links only activate a case if both the leaf node and at least one of its selectors are activated. Special selectors may be defined for different processes or configurations. Our current mashing system uses selectors for ‘goal’, ‘situation’, ‘plan’ and ‘observations’. The selectors for ‘goal’ and ‘situation’ are activated when a new target case is given. This ensures that case with a similar product specification and context will be highly activated. When the product analysis becomes available and problems such as specification violations were encountered, it may be beneficial to activate the selectors for ‘situation’ and ‘plan’ in order to find cases with similar contexts and recipes. If this kind of problems are important and frequent one could define a selector for ‘specification violations’. An interesting alternative would be to activate the selector for ‘observations’. When feedback is available, the model is used to generate explanations for observed results and problems. These explanations are added to the index, under control of the selector for observations. Activation of this selector will then retrieve cases where problems occurred for similar reasons. The explanations for problems can be used to guide future adaptation. 2.5 Adaptation When the mash planner is given a new target case without a plan, it first indexes the case using the selectors ‘goal’ and ‘situation’. The previous batches in the case base have then been ranked in order of similarity as described above. Initially the recipe of the most similar case is then used as a template, i.e. is copied into the target case. Next the target case and the template case are analysed for their differences. This is done by comparison of the activation of index leaf nodes by the target and template. If there is a different activation, the cases must be different in the aspect represented by the leaf node. Such a leaf node returns an instance of CaseDifference. This is another abstract superclass with subclasses such as: AimIncrement and PropertyDecrement. After construction of the differences, potential pitfalls of the copied plan are fetched. The problems, if any, that were observed for the template are analysed. If observed ConstraintViolations hold for the target they are added to the pitfalls, as are all other observed problems. Once the differences and pitfalls are constructed the actual adaptation starts. The model is asked to construct an AdaptationGoal for each difference and pitfall. Relevant nodes for the kind of CaseDifference are selected, then the net is traversed along the influences up to process nodes that can be influenced by such a difference, or influence an outcome. Each AdaptationGoal is given an importance, based upon the size of the difference or the severity of the pitfall. Identical goals are then combined; each AdaptationGoal has one or more
justifications, one for each difference or pitfall that may be taken care of when the goal can be met. Next, the model is asked to construct Adaptations for each AdaptationGoal. This is done by another search trough the model network; in backward fashion towards nodes that are linked to an Action (e.g. to a rest by a Measurement of the temperature). Next, the obtained list of possible adaptations is processed. If some adaptation makes another adaptation redundant, the later is not made. On the other hand, if some adaptation introduces a constraint violation it is undone. 2.6 Interfaces The user interface of the system is, once again, provided as a class library. This library implements a number of editors and viewers. Some of these can be specialised for a particular application, but most can be used as is, as long as process specific classes implement some user-interface related methods. A significant part of the user interface is provided as hypertext that is generated on-the-fly by the various objects mentioned above and by explanations. The qualitative model and object oriented representation of cases enable rather decent explanation facilities. The model can construct Explanations for e.g. a particular Adaptation. Explanations, Observations, and most other objects can provide short hypertext fragments that so far have been perceived as quite informative. Apart from a user interface, the system has an interface to the production management system used. Nowadays production management and material flow systems are often realised as a relational database. The system should be linked to such databases but of course, that link has to be configured for each specific database. 2.7 Implementation and Current Status The system was implemented in Visual Smalltalk (Parcplace-Digitalk) for Windows NT. It consists of a large number of related class libraries. The major goal of this high degree of object orientation is to facilitate rapid development of process or plant specific applications. The set of all the classes for case and model based reasoning, explanations, the user interface, etc., forms a framework (Johnsson & Russo, 1991) for bioprocess planning. It is our intention to expand the libraries for case representation and model construction into a serious ontology (Gruber, 1991) for bioprocesses, not unlike other recent ontologies for manufacturing (Fox et al., 1993) and design (Alberts, 1993). Our current class libraries cover mashing. In order to get a feel for the effort needed for specialisation of the framework to another process, a prototype planner for production of rye-bread was developed. At a slight level of abstraction, this process is quite similar; the structure of rye-bread production batches is virtually identical to those of mashes. But the material and product analyses are all different. After a morning session with two domain experts, it was possible to construct a reasonable process model, using the existing model construction blocks, in the afternoon of the same day. Another half day was needed to write the subclasses necessary for
construction of cases from a database. Once these were available an, admittedly primitive but working, prototype was ready for testing. This exercise clearly demonstrated the power a framework approach. It also brought out some minor flaws in the design of the libraries; code that actually is generic had been defined in process specific (mashing) classes. The mashing planner is currently being tested in a large pilot plant. The earlier (constraint-based) mash planner was tested in our laboratory and smaller pilot plant (Aarts et al., 1993). Computer generated recipes were used to make three different worts from five different malts. Analysis of the worts revealed that the prototype planner worked surprisingly well. These earlier tests have been used as (28) cases for the new planner. Some of the test cases were included in the casebase and the planner was asked to construct a recipe for one or more of the other tested situations. In all trials the case-based planner constructs very similar, but not always identical, recipes as the earlier prototype for all situations; even when a casebase with only a few cases is used. For some situations the new planner constructed slightly different recipes than the earlier prototype. Some of these modified recipes are an attempt to improve the wort quality, whereas in some other cases the new recipe seems a viable alternative to an earlier successful recipe (in such a case that successful recipe was of course not included in the casebase, otherwise it would have been used as is). In addition the planner was used to construct recipes for malts not used in previous tests and for blends of malts. These recipes seem valid and were not rejected by human experts. However, only actual production of the wort, and subsequent fermentation of the wort to beer, will validate the planner. The confidence in the current planner is illustrated by the fact that it is tested directly in a pilot plant with a working volume of several thousand litre, whereas the constraint-based prototype was tested only at 50 litre scale. Although the planner works quite satisfactorily, there are various parts of the reasoning system that could most likely be improved. In addition, the library of bioprocess components could be extended enormously, this would enable the construction of more sophisticated models.
3. Discussion This system offers several advantages. First, such a planner enables a radically different, but attractive, way of operating a bioprocess. As recipe planning is such a “revolution” there are no human experts; so perhaps the quality of plans does not have to be extremely high. On the other hand, the recipe has to yield a satisfying product, of course. It is very likely that a recipe is not unique; i.e. more than one recipe would yield an acceptable product. We learned that funding and fielding an AI application that enables a novel mode of operation is definitely easier and more interesting than working on an application that tries to replace humans. A second advantage, is that the planner indeed is able to adapt previous solutions all by itself. The inclusion of a qualitative process model into the system was crucial for this purpose. Perhaps adaptation knowledge for a particular process can be represented in rules, but in this domain it would be very hard to acquire such rules. A qualitative model can relatively easily be obtained from literature and experts, and the library of model components facilitates the implementation of such a model.
Aamodt (1994) pointed at the likelihood of power from integration of case- and model-based reasoning. Although the presented model representation is somewhat inconsistent, and perhaps even clumsy, its integration with the case-based reasoning system certainly works. Overall adaptation is somewhat complex, but still relatively fast. More importantly, no specific adaptation knowledge has to be defined for a specific planner. The qualitative model, that describes the process, has the adaptation knowledge in an implicit form. The division of adaptation into the construction of adaptation goals, followed by the construction of adaptations that meet these goals, was very effective. Direct construction of adaptations would require a much more global form of model-based reasoning with an accompanying requirement for process specific adaptation knowledge apart from the model per se. The mechanism for adaptation was recently improved by using adaptation cost as a criterion for solution evaluation (Rousu & Aarts, 1996). The currently used representation of the model knowledge fits the domain of bioprocess planning very well. Although we have not used the system in other domains, it can be expected that the same, or a very similar representation can be used in other domains, where processes can be identified, such as medicine or chemical industry. In other domains, e.g. electronics, a device oriented representation such as used in CADET (Sycara et al., 1992) and IDEAL (Bhatta et al., 1994) may be more suitable. CADET uses a simpler form of influences but an otherwise very similar kind of graph for model representation. Within IDEAL a rich structure-behaviour-function representation is used. A crucial difference is that both CADET and IDEAL have devices as cases with specific qualitative models for each case, whereas our system has a single, but quite large model (approx. 50 nodes), that should explain all the cases (batches). Note that IDEAL also employs small global models for principles, such as laws of thermodynamics. Naturally, when the task of the system centres around devices, it is useful to represent those devices explicitly. In our system the task is focused on process recipes; a brewhouse produces several batches per day whereas the devices (vessels) within a particular plant last for decades. The examination of pitfalls was found to be very effective. With a model or other causal knowledge available it certainly is worthwhile to record problems. As in CHEF (Hammond, 1990) and IDEAL (Bhatta et al., 1994), the causal knowledge of the model in our system can be used to generate explanations for observed problems. These explanations directly hint at possible adaptations of the recipe. Unlike CHEF, our system does not revise a recipe when negative feedback becomes available, only when that recipe is being used as a ball-park solution. There seems to be an interesting relation between the knowledge contained in cases and model knowledge. Good case representations should perhaps explicitly represent those aspects that can not (yet) be captured in a model. Cases could be viewed as exceptions to the general “theory” represented by the model. Think of our planner with an empty case base but with a qualitative model. It reminds us of a fresh graduate, it has an up-to-date theory of the domain but no experience. Experience in the form of actual cases provides quantitative information and brings about the limits of the theory. For bioprocesses at least this seems to be the case, but similar issues
may be important in recent work on pest management (Hastings et al., 1995) and fruit treatment (Verdenius, 1997). Another reason for the interest in this kind of planners is that no other tools for bioprocess recipe planning are available to the biotechnical industry. However, many bioprocesses are very sensitive to their history; erroneous process states can normally not be corrected. This makes it essential to design a correct process recipe a priori (a planning approach) instead of adjusting process setpoints after recognition of deviations and problems (on–line control). However, in some processes it may be possible, and indeed effective, to adjust the recipe (plan) during the course of the process. This has been referred to as an agent approach (Hammond et al., 1993) to planning; the planner is an agent taking care of the process. The application for ryebread production, briefly mentioned before, should be such an agent. In practice industrial production of rye-bread is a continuous, not a batch process. Here, a solution (and extension of the framework), would be to regard observed deviations and problems together with their solution, current situation and process history as a case. The system should then come up with a remedy for the problem; the output is no longer a recipe but a recipe modification. An interesting challenge is to develop a system for a process consisting of a combination of batch and continuous unit operations.
4. Possibilities and Challenges Having a model also enables computation of interesting aspects to index on, although the current system does not yet makes much use of this. One obvious possibility lies in using the planner for additional tasks, such as diagnosis. The system could retrieve cases that could be expected to have a similar behaviour as a target case, and then compare such cases with the target case that resulted in an actual problem. A similar situation exists when product analysis becomes available. Because of the model, explanations for a variety of aspects are easy to construct. A very interesting extension would be to use cases to learn the model. Pioneering work by DeJong (1994) hints at how this could be achieved. The model would be asked to construct explanations for the observed result (product analysis) of the case, given the plan and the situation, that is. If the model can indeed explain all the observations, the model is valid. If however, the model cannot explain an observation, it obviously need to be revised. Another reason to revise the model could be rejection of a proposed recipe by the user. DeJong (1994) worked with very simple models where it was possible to search the space of possible model extensions and select the simplest model that could explain all observations. In a real application, that does not seem feasible, perhaps model revision can be done by a case-based reasoner, or actually by the machinery already in the planner. A planner, such as the mashing planner described here, may have other functions than just planning a recipe for every batch. The planner could also be used in production development, especially if model learning is available. The specification and perhaps ingredients for a novel product would be unlike any other case. However if the product is not too different, the planner could construct a, probably poor, recipe. Execution of the recipe however results in an additional case and possibly in an
improved model. Again a recipe for the same new product could be planned but now the system has one case and a better model to rely on. Another role of such a planner could be in training. A planner that has been in use for a while builds a kind of “corporate” memory, a useful asset as such. This idea could be extended even further; a large company could have a central planner that is used by its many plants. The planner would effectively transfer experience from one plant to another.
References Aamodt, A. (1994). Explanation-driven case-based reasoning, In S. Wess, K. Althoff, M. Richter (eds.): Topics in Case-based reasoning. Springer Verlag, pp 274-288. Aarts, R. J. (1992). Knowledge-based systems for bioprocesses. Technical Research Centre of Finland, Publications 120, 116 p. Aarts, R. J., Sjöholm, K., Home, S. & Pietilä, K. (1993). Computer-planned mashing. Proc. of the European Brewery Convention Congress, Oslo, 1993, pp. 655–662. Alberts, L. K. (1993). YMIR: an ontology for engineering design, PhD-thesis, ISBN 90-9006128-2. Bhatta, S., Goel, A. & Prabhakar, S. (1994). Innovation in Analogical Design: A Model-Based Approach. Proc. of the Third International Conference on AI in Design, Aug. 1994, Lausanne, Switzerland. DeJong, G. F. (1994). Learning to plan in continuous domains. Artificial Intelligence 65: 71–141. Forbus. K.D. (1984). Qualitative Process Theory. Artificial Intelligence 24: 85–168. Fox, M., Chionglo, J.F., & Fadel, F.G. (1993). A Common Sense Model of the Enterprise. Proceedings of the 2nd Industrial Engineering Research Conference, Norcross GA: Institute for Industrial Engineers, pp. 425–429. Gruber, T. R. (1991). The Role of Common Ontology in Achieving Sharable, Reusable Knowledge Bases. Principles of Knowledge Representation and Reasoning: Proceedings of the Second International Conference, Cambridge, MA, Morgan Kaufmann Publishers Inc., pp. 601–602. Hammond, K. (1990). Explaining and Repairing Plans That Fail. Artificial Intelligence, 45:173–228. Hammond, K., Converse, T. & Marks, M. (1993). Toward a Theory of Agency. In: Machine Learning Methods for Planning, Minton, S. (ed), Morgan Kaufmann Publishers Inc., San Diego, pp. 351–396.
Hastings, J.D., Branting, L.K. & Lockwood, J.A. (1995), Case Adaptation Using an Incomplete Causal Model. In: Veloso, M. & Aamodt, A. (Eds.): Case-based reasoning research and development: 1st Intl. Conf. ICCBR-95, Sesimbra, Portugal, Oct. 1995, Springer, pp. 181–192. Johnson, R. E. & Russo, V. F. (1991) Reusing Object Oriented Designs. University of Illinois tech. report UIUCDCS 91–1696. Kolodner, J. (1993). Case-Based Reasoning. Morgan-Kaufmann Publishers, Inc., San Mateo CA, 668 p. Koton, P. (1989). Using experience in learning and problem solving. Massachusetts Institute of Technology, Laboratory of Computer Science (Ph.D. diss., October 1988), MIT/LCS/TR-441. Rousu, J. & Aarts, R.J. (1996). Adaptation Cost as a Criterion for Solution Evaluation. In this volume. Sycara, K., Guttal, R., Koning, J., Narasimhan, S. & Navinchandra, D. (1992) CADET: a Case-based Synthesis Tool for Engineering Design, Intl. J. Expert Systems, 4:2. Verdenius, F. (1997). Managing Product Inherent Variance During Treatment. Accepted for publication in: Computers & Electronics in Agriculture.
