From the Mist

Paper submitted for the Western Multiconference on Computer Simulation January 17-20, 1993, San Diego, California

Authors:

• Rob Vens
• dr. A.C.M.A. Rutges

ABSTRACT

Sometimes decision makers are overwhelmed by a huge amount of information, data and possible solutions. They know all of them but don’t know how to evaluate or how to manage them in order to find a satisfactory solution. Finding solutions for problems can be supported by tools for the management of information resources. Managing these information resources demands an adequate decision support system that integrates all relevant aspects in a realistic model with a transparent, understandable user interface. The problem we are studying is located in the agricultural sector.

In the agricultural sector the apiculture in Europe and North America is threatened by a serious disease, the varroa mite. There are several chemical poisons developed to eliminate the mites, but the expectation is that the remedy in the long run will be worse than the disease. Therefore researchers are searching for effective biotechnical methods, which are more friendly for the environment. They need a decision support system that

• integrates the relevant problems in a dynamic model, that can be used for the evaluation of the effectiveness of the suggested method
• can compare the methods with each other
• has an understandable interface for the experts who only have knowledge of the apicultural problems, but not necessarily of working with computers
• is open to change, since knowledge of system behaviour constantly changes
• can model complex systems in a straightforward manner

In this paper a description will be given of the simulation part of a DSS-tool, the Beehive Simulator, that has been developed for the management of specific information resources. The simulation is developed using object-oriented techniques in the analysis, design and implementation phase, and intends to show that these techniques are particularly well suited to build computer models of complex systems like ecological systems, in order to meet the demands of a DSS-tool in this area.

I. INTRODUCTION

The Beehive Simulator simulates a complex, dynamic, real-world system: the development of one or more bee colonies in hives interacting with their environment, with the beekeeper (acting through the user interface), and with their diseases. The user can manipulate the hives through an animation screen in order to investigate the effects of the biotechnical methods. The computer model automatically traces these manipulations. A successful technique can be saved in a logfile that can be sent to an experimental frame for more testing.

We start with a general description of the problem, define the research goal and outline the research method in section 2. In section 3 a description will be given of the most important parts of the beehive simulator, such as the model, the animation screen and the experimental frame.

We finish with some concluding remarks, indicating further lines of research and development, and problems encountered.

2. RESEARCH PROBLEM

2 1 A short description of the problem area

The most important parts of the specific problem field we have chosen as an example arc beehives, populated with bees and varroa mites, an environment and a beekeeper. This represents a real-world system modelled as an ecological system, representative of many other systems: farms, factories, villages etc.

A beehive may contain a colony of honeybees: a queen, house bees, field bees, drones, eggs, larvae and pupae. The characteristics of the population will change during the seasons. Somewhere in the development the population will swarm and reproduce itself. Without the intervention of the beekeeper the population has little chance to survive. There are several serious threats: diseases, enemies, a capricious climate, agrarian poisons, lack of food, and particularly the mismanagement of the beekeeper himself. A beekeeper aims at having a healthy population. He tries to control the swarming moment and maximise the honey yield. He can achieve this by manipulating the colonies at the right time, in the right way.

Nowadays, beekeepers all over the world are confronted with a serious bee disease, the varroa mite. Several methods are developed to eliminate the mites. They vary from the use of chemical poisons to the so called biotechnical methods, which are more environmental friendly. Although the majority of the beekeepers prefers the use of biotechnical methods and distrust the effectiveness of tbe chemical remedies, most research has been directed at the development of new chemical remedies. There is a demand for biotechnical methods, which combine the possibility co eliminate diseases like the varroa-mite with the possibility to control the swarming time without losing the amount of yield.

2 2 The research goal

Problems such as those described above are very difficult to solve with real time experiments. The large number of biotechnical methods that has to be evaluated, generates a number of experiments that is impossible to handle. Also the loss of bee population will be too high. So what the experts need is a model in which all relevant knowledge is integrated, with the possibility to evaluate the effects of the biotechnical methods without prior knowledge of computers. Therefore we decided to create a Beehive Simulator with three main components:

• a simulation model for the description of the development of bees and varroa-mites and
• an interactive animation model that gives the user the possibility of executing all beekeepers tasks with the help of the computer mouse only and
• an experimental frame for more thoroughly testing of the results.

2 3 The research method

To evaluate the realisation of the research goal the structure and dynamics of the system under study will be described according to the process interaction method. It demands a decomposition of the system in relevant components and for each component an overview of its characteristics and behaviour.

The problem area can be decomposed into three main components: the beehive, the beekeeper and the environment. Figure 1 shows the decomposition of each of these components.

The beehive system consists of a hive and a population. The hive is build from one or more supers (placed on top of each other). Each super can have one or more frames and each frame contains a number of cells. The population contains again its own components: a bee queen, eggs, larvae, pupae, house bees, field bees, drones and mites. The behaviour and characteristics of these components are described.

Because the queen lays eggs in the cells on the frames and the bees put their products (the gathered honey and pollen) in cells too, the bee population (with their brood and products) will be distributed over the frames in the supers of the hive. The mile population, feeding themselves at the cost of the larvae of the bees, is also distributed over the cells and the frames in the supers.

All factors, having impact on the system while not belonging to the system proper, are included in the component environment. It deals with factors like climate and weather, temperature, nectartlow and other diseases.

The beekeeper treats the hives according to a time schedule to optimize his goals.

Treating a bee population according to a biotechnical method implies manipulating the frames, the contents of the cells and even sometimes the supers of the hives. It means that the beekeeper can be seen as a user who needs some facilities to manipulate the simulated hives. Therefore a user interface is developed by which a user can interactively manipulate one or more bee hives and ask for information from the simulation components.

This way the simulation model and user interface together can be used to evaluate all sorts of biotcchnical methods.

So far the Beehive Simulator can be used for exploration and even teaching goals. But when a biotechnical method has been found with some promising results, there is an opportunity for this simulation package to test the method.

3 DESCRIPTION OF THE SIMULATOR

3, 1 Requirements

The components as already mentioned have something in common that can be described by an abstract object model. Abstract in the sense that we want to capture general statements about the system as mentioned, without producing statements that are particular for any real system. This abstract object model will be produced by an object-oriented analysis of the problem spaces mentioned, supported by object-oriented design techniques.

This capturing of generality is an important issue in the project, because we feel that there are many areas where a vast amount of knowledge is to be utilised in practical ways. The problem of how to make this knowledge manageable, available, is very real. Not only the issue of availability, but also the issue of knowledge integration is of great importance.

We want to define (in the context of general requirements) four major goals in the development of a simulation framework for the management of agricultural resources:

1. Interactive
2. Open to validation
3. General
4. Flexible

Le! us expand on these points some more.

1. ‘l’he simulation framework has to he interactive

In order to be truly interactive the simulation has to fulfil several standards, especially with respect to the user interface.

a. Pictures, icons etc. must he linked to simulation objects or actors

This way the user will be able to easily distinguish objects participating in the simulation.

b. It should be possible to stop the simulation at any moment

This is also a matter of interactivity, but it is an important part of the simulation being close to the real world. In reality, the user (or manager, or beekeeper) can at any moment access the system. So this is an important requirement. We implemented several possibilities for the user to interact with the model after halting the system. The user can halt the simulation to:

• save the simulation
• save a part of the simulation (i.e. one of its static components)
• introduce new actors or simulation objects (dynamic components)
• change the static simulation structure in the sense of manipulating static components, adding or removing components
• remove dynamic components from the simulation
• inspect the proceeding, i.e. produce statistics and other output

c. Definable structure of components

This is to define the internal structure of components. This structure can be from a simple on-top-of-each-other structure to a complex matrix structure. Also, during the simulation, many structures can and probably will change, in which case it is necessary to be able to describe the way this dynamic behaviour is animated on the screen. There are two components in this issue of definable structure:

• static components (aggregation)
• dynamic components (animation)

More about the factoring in static and dynamic components will be found in section 3.1.

2. The simulation must be open to validation

Actually this is a very complex matter, and a well known problem area in the field of simulations. We want to do the best we can by being able to link monitors to every object in the simulation, be it static or dynamic, and by being able to define which part of the behaviour of the monitored object we want to monitor. The following elements of the Beehive Simulator can be used for validation:

• log files
• monitors
• saving simulations
• saving parts of the simulation structure
• statistical analysis tools

3. The simulation framework must be general

Since we want to design a framework which is reusable in the sense that it should be also able to simulate other agricultural systems, or rather ecological systems in the general sense, the issue of generality is an important one. This design goal has been reached by implementing the abstract class hierarchies of simulation objects and containers. This is the classical model of the client-server, but implemented in a general and reusable way. More about this in the object descriptions which follow.

4. The framework must be flexible, open to changes

It is in the nature of developing object-oriented simulations that it is an iterative process. We want to be able to produce in the early stages of development a working implementation of a simple model of the system, which can be refined and which can grow without having to start from scratch every time we have to introduce a major change in requirements. Also, as we have experienced in the short time we were building this model, there is the problem of changes in knowledge about the system that is modelled and built. As will probably always be the case, experts disagree on many issues, and this can bring about major changes in modelling the behaviour of the system. This problem can never be solved completely by using object-oriented technology, but we have found the use of general class hierarchies very rewarding, because it was never necessary to change anything on the abstract levels. So flexibility is also a result of generality.

Another design decision which enabled us to build a flexible model, was the use of factorised behaviour algorithms. The behaviour of dynamic components was modelled in such a way that critical behaviour methods (algorithms) were isolated. Because they were deliberately isolated, changing them was relatively easy.

We found the need for a general object model very real. If you are able to build a general framework of the problem area under consideration, the problem of flexibility can be solved to a large extent,

More specific requirements

A specific requirement for a less general simulation requirement in our case is the accessible user-interface. It is a development in all areas of computer software to offer the customer a extensive user-interface. But this is not just a fashion. To be able to work with the complex computer programs that are becoming available today, it is very much a necessity to guide the users how to make use of the program.

For our simulation this is no different. The simulation program must have a low threshold for computer-novices who want or need to work with it. For this reason we decided to pay much attention to an extensive user-interface, trying not to lose our objective of generality from sight. This led to the implementation of many so-called windows, with the necessary models to serve as a model for these windows. The contents of these windows should in some cases show a representation of the real system as close as possible. For more information on the user interface see section 3.3.

3 2 Simulation model

As we have explained, the simulation model is factorised in a dynamic and a static part. The static part is associated with the aggregation structure of the hive components, the passive simulation entities. The dynamic part is associated with the dynamics of the beehive population and the diseases, the active simulation entities. The dynamic part is mapped to the static part in a classical client-server relationship [Bézivin, 1987], where the static part plays the role of the server, and the dynamic parts constantly interact with the static parts as clients. This can be seen in the following illustrations in the instance variables or slots of the components (the second or middle part of each object card). For example, the class definition of BeehiveSimulationObject in Smalltalk is as follows:

SimulationObject subclass: #BeehiveSimulationObject instanceVariableNames: ‘conceptionDate quantity container’

The class definition of PopulationContainer is as follows:

Container subclass: #PopulationContainer instanceVariableNames: ‘population’

Both these classes are abstract classes. Abstract classes are classes that do not generate instances of themselves. This is done by their subclasses. The instance variables show the mapping of static and dynamic parts. The instance variable population in the static abstract class PopulationContainer actually will be associated with dynamic population cohorts, generated during the simulation. The instance variable container in the dynamic abstract class BeehiveSimulationObject will actually be filled with static components.

For an example of the interaction between these two simulation objects (i.e. the dynamics of the client-server model), we will investigate the behaviour of a queen in the hive. The queen is an active simulation object. She is present somewhere in the hive, situated on one of the frames. She performs tasks, which are constantly being redefined according to the conditions of her environment. One of her tasks, in relation to the frame on which she situated, is laying eggs. In order to perform these tasks she asks a frame whether there is space (in the form of empty cells). The frame passively investigates its own condition, and answers the queen. Suppose the answer is affirmative, then the queen enters the frame. She tells the frame so, and lays one or more eggs in its cells. These eggs for themselves are the starting point of many more active simulation objects.

Object description of static components

The static components of the simulation can be modelled in two ways. In the simulation all active objects perform their tasks concurrently, and we have to deal with the mutual exclusion problem of more than one client accessing (and possibly changing) a server object. The first solution is to let the active simulation objects (the clients) have access to the passive simulation objects (the servers) through some kind of serialiser, in order to prevent multi-client access to the same server. The second is to lock each passive simulation object with a mutual exclusion semaphore [Bézivin, 1987] to enable all active simulation objects to perform their tanks concurrently.

We have chosen for the first approach, and activate all active objects through a serialiser. This is more like the simulation framework published in the blue book [Goldberg, 1989], which is strongly based on DEMOS [Birtwistle, 1979]. The second approach is presently being investigated.

The illustration shows what is called a class diagram. It contains a hierarchical view of the main classes in the static components structure of the model. These classes consist of an abstract layer and a manifest layer.

The abstract layer consists of classes which are not meant to create instances themselves, but serve as a framework for the design of manifest classes who implement specific simulation models. In Figure 2 this hierarchical structure is shown using Coad & Yourdon’s object cards [Coad and Yourdon, 1990]. The specific instance variables added to the manifest classes reveal their specialised functions. For example, a frame has the instance variable contents, which serves as a repository for honey and pollen gathered by the flying bees, and stored in the cells of the frame.

The factorizing of static or passive simulation objects can be as fine-grained as necessary. In our case we decided to model the frames, but not the cells on the frames. For our present purposes the frames were able to process all behaviour we needed.

Object Description of dynamic components

The dynamic components perform their tasks concurrently. That is, those tasks that are scheduled to be performed on the same virtual (simulation) time. As mentioned, these tasks are led through a serialiser, located in a special instance of class Simulation. This instance maintains an active process protected by a semaphore to prevent more than one process being active. This construction also guarantees that each tasks will be finished before the next.

Also in this class diagram (see Figure 3) abstract and manifest layers are to be observed. Here the classes are found who create instances of dynamic objects, actively participating in the simulation.

The active simulation objects are the ones actually performing tasks and thus dynamically change internal conditions of the hives. The diagram shows the hierarchical structure of these simulation objects. They can be roughly divided into bees and mites, and external factors such as weather and nectar-flow.

There are more simulation-specific objects modelled as active simulation objects.

The tracers are actual simulation objects performing tasks. These tasks can be defined by the user, and thus they provide an extremely flexible tracing mechanism that can access the static simulation structure like inter-planetary probes, and produce reports that can be used for simulation evaluations and statistical analysis.

Object description of support components

The analysis of the support area for the simulation proved to be a very stimulating one, because here we encountered an area of special interest for the issue of reusable class libraries. Classes for statistical analysis, display of statistical information, modelling of monitors and file organisation, are to be found in this important component of the package. Also these classes form the interface to other applications, for example spreadsheets to analyse the statistical output of the simulation. We show no object diagram of this part.

3 3 User interface

The user-interface is a keyword of this project. In order to be useful for research purposes it is clear that it has to be as accessible as possible. We stipulated above that the use of object-oriented technology, and the Objectworks\Smalltalk-environment in particular, has made this relatively easy.

The simulation is accessible through one main window, from which all other windows can be spawned. This window is called the Beehive Simulator Control Window (see Figures 4 and 5). This window is composed of several sub-views:

• a graphical view of the apiary, with the hives that are present in the apiary. The objects in this view are accessible through mouse-clicks and through pop-up menu’s
• views that show the current state of some important external factors such as nectar-flow and temperature
• a view that shows the most important quantities of the products of a selected hive in the form of bar charts
• a menu bar, which pops up menu’s when clicked with the mouse
• a view with some icons and buttons for additional activities with the apiary

Figure 4 shows the window as it appears when starting up. There are no hives.

The hierarchical menu you see is popped-up by clicking with the mouse on the Apiary button on the menu bar.

Figure 5 shows the situation after running for several months simulated time.

Now we see three hives. The third hive has one opened super, the bottom one, which is opened fur inspection by double-clicking on it. The black rectangle around thc eighth frame in this super shows how elements can be accessed in this view: by selection with the mouse. By clicking with the mouse on one element it is selected. This is shown by drawing a red rectangle around the object (or black on monochrome monitors). Each element can be selected, be it hive, super or frame. and subsequently manipulated through the menu’s. The selected frame for example can be inserted in or moved to another super by moving the mouse point to another opened super, asking for a menu by clicking the middle mouse button. The program analyses the situation and deduces that the user may want co move the selected object, and offers this possibility (possibly with others) in the pop-up menu that appears.

The bar charts to the bottom right of the window show the quantities of the most important products of the third hive. This bar chart view can be opened on any of the tracers that the user may want to attach to any of the apiary components. An apiary component is any of the static or passive simulation objects which are created in the simulation run. A tracer is a standard probe-like object, whose behaviour can be refined by the user, and who is attached to one of these static components. It stores its gathered information, reports this to a dynamic view, or writes to a file.

Using a colour monitor each product has its own specific colour, which is also used in other views. This makes identification of products easy. Of course these colours can be defined by the user and changed at any moment.

There are many more windows. Many of them arc so-called Browsers. A Browser is an application that accesses complex data structures using list selections. The Apiary Browser is such a browser (Figure 6). The third hive is selected in the top left list view. This makes this hive’s components, the supers, appear in the middle list view. In this view the first super is selected, which in turn shows the frames in this super in the right list view. No frame is selected, which lets the text subview (the bottom view) show important data on the selected super.

The tracers that arc defined by the user and trace the quantities of the products of the hive write their reports to a file. The file format can be defined by the user, for example a format can be chosen for import into a spreadsheet application. The Statistics View shows the quantities of the hive products in a more graphical way (Figure 7). By clicking the appropriate button the traced quantities are shown in their representative colours. The quantities can be represented using bars, which is more in line with the discrete nature of the data (these tracers collect numerical data for their targets every day), or with lines, which makes it easier to compare data in one view. These views and their underlying models are nice examples of support components that can easily be re-used.

Figure 8 shows a dialogue view that is used to start a varroa infection. Starting parameters can be entered using stochastic parameters. These stochastic parameters can be entered to use one of the many probability distributions available in the system. There is an in theory limitless quantity of Random number generators.

The bar chart subview, like many other subviews of the Beehive Simulator Window, can be opened separately (Figure 9). This is necessary to make the available information better accessible.

If the active simulation objects need to be inspected a Population Browser can be opened (Figure 10). This browser is also used to assess the infection rate of the diseases that are present. An important feature is the possibility to attach tracers to each active simulation object. These tracers can be used to write their observations to a transcript (for immediate evaluation during the simulation run), or to a file for later inspection. Each container can be inspected, in which case a Pie Chart View shows the contents (Figure 11 ). This pie chart view is an intermediate representation of the contents of a frame, since we want to represent the contents of the frame in a more realistic way through a scanned photograph of a frame with corresponding characteristics. This is for the future however, but it illustrates that extending the simulator can be done relatively easy.

Many windows, notably the Beehive Simulator Control Window, the Statistics View, and the Bar Charts View, can print their graphical contents to a printer. Other views, such as the different browsers, print their contents in a textual format.

3 4 Experimental frame

This module consists of classes who enable the user to set up experiments with the apiary. To make use of the experimental frame a few steps must be made in advance.

• defining a problem that can be investigated using the simulator
• playing around with the simulator to get a more or less specific understanding of how to implement this problem statement in the simulator
• setting up global starting conditions: ecological zones or climate conditions, specific locations (for example out in the open or in the city) etc.
• setting up hive-specific starting conditions (quality of hives as to warmth-insulation for example)
• setting up scheduled events, such as the outbreak of certain diseases, or other external events influencing the hives
• setting up environment schedules: standard weather conditions, food plants configurations etc. These can also be inserted into an event-scheduler (for example the scheduling of a cold spell in the summer)
• running and re-running the simulator, starting from the same starting condition, but each series of runs changing one of the factors of the simulation (environment, beekeeping method, diseases etc.).
• evaluating the information generated during these runs

Many of the set-up parameters can be stochastic or fixed, depending on the nature of the problem.

A necessary foundation of the module is the ability to save a simulation. At any moment the user can decide to save the simulation. This means that the present state of the simulation is saved, the present time, as well as its history (including all tracing information). It is through a simple option on a pop-up menu that this saved simulation can be opened in the Beehive Simulator Control Window. Subsequently the user can run the simulation one or many times, with pre-defined parameters-or stochastic variables changing. This way the most correct result will be obtained from the simulation runs.

Apart from saving simulations, also apiary components can be saved. For example the user can decide to save an entire hive to a file, in order to re-introduce this same hive in an other simulation. In this case saving the apiary component means that the static and dynamic parts are saved, but not their history or the global simulation conditions such as the time. Upon being re-introduced the dynamic simulation objects re-assess their situation and redefine their tasks accordingly.

This is a point that needs to be stressed some more perhaps. In order for the simulation to be as flexible as it is, it is necessary that a11 dynamic simulation objects do not schedule their tasks over long periods of time. It is very well conceivable that the event scheduled cannot take place because the environment has changed. Therefore we decided to factor the scheduling of events. The granularity of all scheduling is never more than one day. This means that every day all active objects reassess their situation, and perform their tasks based on the environment they find themselves in. The time for the tasks themselves is considered to be infinitely small. Furthermore, the user-interface events are scheduled in a different time-queue, with differing priorities. This way we implement a specialised case of an event-driven simulation, which makes a high degree of interactivity possible.

4 CONCLUDING REMARKS

Although we are in an early phase of the project, we are able to say that the Beehive Simulator has proven to be an adequate tool for the evaluation of biotechnical methods. The level of complexity is potentially very high, but maps very neatly to the problem domain. Extension of the model is very well possible, for example by incorporating more intelligent behaviour of the active simulation objects, or using a finer-grained time unit. Extension of the user-interface is also very easy. This was proven by the radical change in the Objectworks\Smalltalk interface and graphical libraries from version 2.5 to release 4. The port to the new release was finished in two weeks and implied no change at all for the model part of the implementation.

We envision the planned integration of the simulation framework in the next phase of the project with a knowledge base (to model the behaviour of the active simulation objects, to model the various beekeeping methods, and to model a diagnostics system for the evaluation of diseases, ad-hoe beekeeping and other problems) and a database management system (to keep persistent objects to be used by the simulation and the knowledge base).

It is also useful for training purposes in an educational setting. Logfiles makes it particularly easy for teachers to set up problem situations, which can be investigated by students. At the moment we are implementing a knowledge base to augment this, and to support the teachers and researchers. For the future projects are planned to gather the necessary real-time information in order to get a robust knowledge base and behaviour algorithms.

Also we foresee a possible demand for this class of systems for the management of other information resources, especially in the agricultural and ecological areas. We advocate building these systems using object-oriented techniques for the reasons mentioned above.

ACKNOWLEDGEMENTS

The authors wish to thank Marco Gerbrandy, who was responsible for extensive testing of the implementation, and who designed the first knowledge base for diagnosing bee diseases.

REFERENCES

1. Bézivin, Jean. 1987. “Some experiments in Object Oriented Simulations.” In Oopsla’87 Conference Proceedings, p.394-405
2. Birtwistle, Graham M. 1979. A System for Discrete Event Modelling on Simula. MacMillan, London.
3. Coad, Peter & Edward Yourdon. 1990. Object-Oriented Analysis. Prentice Hall, New York
4. Goldberg, Adele and David Robson. 1983. Smalltalk-80; The Language. Addison Wesley, New York