ENGINEERING FARM KNOWLEDGE FOR A
SEAMLESS DECISION SUPPORT SYSTEM
A DISSERTATION PRESENTED TO THE GRADUATE SCHOOL
OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT
OF THE REQUIREMENTS FOR THE DEGREE OF
DOCTOR OF PHILOSOPHY
UNIVERSITY OF FLORIDA
the Farming Community of the World
I would like to express my deep hearted gratitude to Dr.
R. M. Peart, Graduate Research Professor of Agricultural
Engineering, for serving as a chairman for my dissertation
work. The efforts of Dr. W. D. Shoup of the Department of
Agricultural Engineering in formalizing the project and
serving as cochairman on my supervisory committee are highly
appreciated. The financial support for the studies and the
dissertation was provided by International Benchmark Sites
for Agrotechnology Transfer (IBSNAT). Dr. J. W. Jones, also
from Agricultural Engineering Department, played a key role
in arranging this support and helping me in structuring and
conceptualizing different aspects of the dissertation. I
specially thank him for his efforts and guidance. I would
also like to thank Dr. Peter Hildebrand from the Food and
Resource Economics Department and Dr. D. Dankel from the
Department of Computer and Information Sciences, who provided
a unique blend of expertise in farming systems and knowledge-
based systems needed for the dissertation.
Mr. Jerry Davis and his wife from Santa Rosa County in
North Florida provided the details about their farm setting
for operational verification of the dissertation work. They
deserve my special thanks for sparing their time and valuable
information. I also thank all participants of the
miniconference on Knowledge-based Decision Systems using Logic
Programming who spared time from their busy schedule to come
to Gainesville and help us evaluate and qualify FARMSYS.
The patience and moral support of my wife Chitra, who
kept my morale high all through the study period, deserves
special appreciation. I would also like to thank my three
daughters Bhawana, Monika and Prerna who found their dad busy
with his studies whenever they wanted him to play with them.
I would also like to register my thanks for Dr. P. N.
Sharma, my friend and my old time college and professional
colleague, who inspired me to return to school after a
professional career of 13 years.
Last but not the least, I would like to acknowledge the
efforts of my parents, brothers and sisters whose hard work
constituted the foundation work for my higher studies and
ultimately this dissertation.
TABLE OF CONTENTS
I INTRODUCTION.................................... 1
II REVIEW OF LITERATURE.......................... 7
Conventional Decision-aid Tools................. 7
Machinery Management Applications............ 9
Knowledge Engineering Concepts and Applications 16
Knowledge Classification.................... 17
Knowledge-Based Decision Systems............ 18
III SYSTEM DESIGN AND IMPLEMENTATION............... 33
Object-Oriented Simulation..................... 37
Farm as a System .... ....................... 40
Knowledge Representation.................... 46
Model Description........................... 47
Simulation in PROLOG........................ 53
Expert Simulation Analysis..................... 65
Operations Analysis Report.................. 69
Machinery Usage Report...................... 83
Accumulated Work Report..................... 90
Knowledge-Based Yield Estimation............... 93
Crop Yield Knowledge-Bases.................. 95
Expert Search System........................ 97
An Intelligent Information Management System... 102
Characteristics....................... ...... 108
Components and their Functions.............. 109
Knowledge-Bases Utilized and Generated....... 114
IV TESTING AND EVALUATION......................... 130
Professional Qualification...................... 131
Structured Response Analysis................ 142
Non-Structured Responses.................... 144
Role of Mini-Conference in Evaluating
Knowledge-based Systems.................. 145
Operational Level Verification................. 146
Description of the Test Farm................. 148
Setting up Farm Knowledge for
Simulation Runs.......................... 148
Operations Simulation Reports............... 153
Expert Analysis System....................... 161
Test Runs with FARMSYS...................... 172
Yield Estimation System..................... 180
Integrated Decision System.................. 182
V CONCLUSIONS AND RECOMMENDATIONS................ 186
I KNOWLEDGE-BASES.... .............................. 192
II MINI-CONFERENCE FOR FARMSYS QUALIFICATION......... 198
REFERENCES..... ......... ............................... 212
BIOGRAPHICAL SKETCH... ................................ 225
Abstract of Dissertation Presented to the Graduate School
of the University of Florida in Partial Fulfillment of the
Requirements for the Degree of Doctor of Philosophy
ENGINEERING FARM KNOWLEDGE FOR A
SEAMLESS DECISION SUPPORT SYSTEM
Chairman: Dr. R. M. Peart
Major Department: Agricultural Engineering
Farm operational knowledge including dynamic processes
as well as heuristics for expert planning and management for
machinery, labor and other resources has been represented and
manipulated utilizing knowledge engineering concepts of
artificial intelligence (AI) in logic programming (PROLOG).
The new approach permitted integration of simulation, expert
systems and databases under one single environment, thus
leading to a seamless decision support system. It also
enabled imparting some of the "intelligent" functions of
simulation processes, generally performed by human experts,
to computers, thus facilitating their usage by non-experts.
A decision support system (FARMSYS) with four components,
namely, object-oriented simulation, logic-based expert system,
knowledge-based yield estimation system and intelligent
information system, has been designed, constructed and
evaluated. A team of experts evaluated professional
qualifications of FARMSYS and found its structure excellent
with a comprehensive framework for a variety of applications.
All its components functioned correctly, intelligently, and
in harmony with one another, using knowledge from an
operational farm in north Florida.
The Operations Simulator successfully simulated field
operations for complete cropping season and responded
correctly to scheduled work hours and to the withdrawal of
machinery and laborer. The Expert Analysis component
successfully imitated the behavior of machinery management
expertss. Its recommendations and other support were
effective, and demonstrated the possibility of reducing the
machinery and labor force from the test farm without
significantly affecting the timeliness of the majority of farm
operations. The Yield Estimation system responded to
different work hours during critical operations showing their
effects on crop yields and profits. The Information
Management System expedited the development and updating
process of the farm knowledge-bases to carry out different
tests with FARMSYS, thus demonstrating its successful
functioning as an integrated decision support system.
PROLOG facilitated simulating field operations in an
object-oriented manner, a new AI method of programming. Its
inferencing capabilities have been utilized to incorporate
several expert systems within and outside the simulation and
other components of FARMSYS. The object-oriented approach
allowed for the modelling of aspects of the system that are
typically ignored or difficult to model when using
The stochastic nature of weather and complexity of other
endogenous and exogenous factors responsible for crop
production makes the job of the farmer much more complex and
challenging in comparison to industrial production systems.
Machinery and labor constitute a major component of
capital outlay for crop production in an operational farm
system. They control the operational behavior of the farm
systems. Farmers are generally faced with the problem of
selecting appropriate machinery (size and mix), scheduling
the correct amount of labor, deciding acreage for each crop
along with its cropping calendar, and selecting methods for
various operations (amount of tillage, number of cultivations,
combining pesticide applications with other operations, etc.).
A number of farm-scale models have been developed to
facilitate machinery and labor planning and management
decision-making process by farmers under conflicting, complex
and multiple choice situations. These models have been
classified into six categories: linear programming models,
simulation models, discount cash flow models, computerized
budgeting models, machinery replacement models and machinery
cost and utilization records (Nelson and Bowers, 1968). Among
all these categories, the simulation models capture the
dynamic behavior of operational farm systems (Peart and
Barrett, 1979). The ability of these models to duplicate the
real world system depends upon their formulation and
incorporation of factors responsible for their control in as
realistic manner as possible (Elderen, 1981; Elderen, 1987).
The conventional approach to simulation is characterized
as algorithmic or procedural. In this approach an algorithm
or a procedure is first defined to solve the problem at hand.
A computer program is then written using one of the procedural
languages such as FORTRAN, BASIC or PASCAL to implement the
algorithm. One of the major limitation of this approach of
simulation is its inability to model intelligent behavior of
the system. Often simple approximations are used instead. The
path of activities that a customer takes in a service
simulation (for example a simulation of the shop) is modelled
by probabilities determined by prior observations and
sampling, rather than by modelling the decision mechanism of
the customer (O'Keefe and Roach, 1987).
In addition, the simulation does not provide solutions
to the problems. It mainly shows the values of a set of
variables over a period of time given certain assumptions.
The interpretation of these values and drawing inferences from
them lies beyond the scope and intent of the simulation
program itself. Simulation cannot guide the user through the
decision-making process of recommending appropriate managerial
actions which could improve the productivity of the system.
This is completely left to the user's capabilities and
The results from simulation are often complex and remain
within an exclusive domain of the experts for their
interpretation. The scarcity and the cost of expert advice
for output interpretation creates a serious bottleneck and
can even nullify the advantages of simulation as a management
and/or planning tool (Khuri et al., 1988).
Knowledge-based decision systems are integrated packages
which combine the capability of expert systems and
simulation, including necessary data bases (Peart et al.,
1985; Peart et al., 1988). They can intelligently apply
analytical tools to deal with real world problems. They are
developed using modern Artificial Intelligence (AI) languages
such as PROLOG, LISP, SmallTalk or specialized development
programs called shells. They have the capability of handling
qualitative knowledge in addition to quantitative and
procedural knowledge. The knowledge representation techniques
of these languages can be utilized to maintain farm and
regional knowledge separate from the computer code of the
model, thus making them versatile and flexible.
The inferencing capability of AI languages can allow for
the modelling of aspects of the system that are typically
ignored or are difficult to model when using conventional
approach: for instance, adaptive behavior, where the activity
attempted next is determined by some perception of the present
state of the system (O'Keefe and Roach, 1987). Simple
decision rules (for instance, always join the shortest queue),
frequently inadequately captured in conventional simulation
technique, can be better apprehended using AI techniques. It
can also help incorporate expert systems as an integral
component of the simulation to facilitate analysis and
interpretation of their results.
In recent years there have been some attempts in using
the above approach for developing models for an operational
farm decision support system. However, there is no reference
in the literature to an agricultural expert decision system
with simulation and databases that has been developed using
a single programming environment.
The general object is to represent and manipulate farm
operational knowledge, including dynamic processes as well as
heuristics for expert planning and management for machinery,
labor and other resources utilizing knowledge engineering
concepts of artificial intelligence.
The specific objectives are as follows:
1) to construct a semantic representation of farm
operational knowledge for crop production systems;
2) to manipulate farm operational knowledge for
simulating field operations for a complete cropping calendar
using object-oriented approach;
3) to design and implement an expert analysis system to
analyze the simulation results in the context of the farm
knowledge to study labor and machinery utilization, and to
develop appropriate recommendations for efficient planning
and management of farm operations;
4) to develop a mechanism of utilizing crop growth
simulation models and/or knowledge of regional crop experts
for predicting crop yields in the context of farm knowledge
and simulated dates of operations and
5) to integrate the simulation and expert knowledge into
a decision-aid tool with an interactive user interface, and
to verify its professional qualifications and operational
capabilities as an expert planning tool for multi-crop
The remainder of this dissertation is organized as four
more chapters. The review of literature in Chapter II deals
with the decision-aid tools developed utilizing algorithmic
and procedural approaches, and concepts and applications of
knowledge engineering in the field of agriculture.
The design and implementation of the decision system
consisting of an object-oriented field operations simulation,
an expert analysis system of the simulation reports, a
knowledge-based crop yield estimation and an intelligent
information system are discussed in chapter III. This chapter
also describes briefly how PROgramming in LOGic (PROLOG) has
been utilized for writing the simulation, the first
application of logic-based simulation in agriculture. Chapter
IV reports the procedure and results of the evaluation and
testing used to qualify FARMSYS as an integrated decision
system for multi-crop production. The professional
qualification of the system was carried out by letting a team
of experts evaluate and critique the system, and the
operational verification of its different components was
conducted utilizing real farm data from north Florida.
Finally, Chapter V presents conclusions and the
recommendations for future work for farm-scale knowledge-based
systems in general and FARMSYS in particular.
REVIEW OF LITERATURE
Conventional Decision-aid Tools
The crop production process can be described as a system
of n-stage decision problems. These n-stages are
differentiated by weather, the state of the crops and/or
fields and availability of inputs, labor and machinery. At
each decision-making moment the farmer selects some person
and machine to perform certain operations) on fields and/or
crops. They (the field and/or crop) have to be ready with
appropriate soil moisture, ripeness, etc. to receive the
services. The operations) on the fields are performed with
available or selected labor and machines. The process
transforms the current stage of the system into the next one
with a new set of characteristics for the crop(s) and the
fieldss. This new state then becomes the next challenge for
the farmer to make a decision and this process goes on until
all the tasks of the production process are terminated.
The stochastic nature of the weather and complexity of
other factors responsible for crop production, both endogenous
and exogenous, makes the job of the farmer much more complex
and challenging in comparison to other industrial production
systems. Farmers are always concerned about appropriate
selection, efficient utilization and management of the
resources at their disposal in order to have better control
over the production process at different problem stages.
Agricultural scientists have been developing computer
models to facilitate the decision-making process by farmers
under conflicting, complex and multiple-choice situations
(Jones et al., 1988; Tsai et al., 1987; Chen and McClendon,
1985). These models, both analytical and simulation, can be
broadly classified into 1) plant-scale models, 2) field-scale
models and 3) farm-scale models.
The plant-scale models study the behavior of individual
plant and extrapolate the results for the whole field.
Examples of such models are the crop growth simulation models
(Jones et al., 1988) designed to study the physiological
development and growth of plants. These models have been
commonly used to better understand the development process of
the plant. However, in recent years there have been some
attempts to use them as decision-aid tools (Boggess and
Amerling, 1983; Boote and Jones, 1986; Hoogenboom et al.,
1987; Meyer and Curry, 1986).
The field-scale models study the behavior of an
individual field in terms of its adaptability to different
cropping systems for its environmental and soil
characteristics. These models generally do not consider the
operational constraints (machinery and labor requirements) to
implement the candidate or the selected cropping systems (Tsai
et al., 1987).
The farm-scale models capture the behavior of the farm
as a whole. They consider the operational constraints of the
farm and can help farmers make strategic planning and/or
tactical management decisions. Both quantitative techniques
such as linear programming and simulation, and analytical
mathematical models have been used to develop such models.
All three types of models, discussed above, are important
in developing decision-aid tools for a farm setting. They
should be considered as complementary rather than competitor
or substitutes for one another. The plant-based models should
serve as the basic tools for developing field-scale models.
The field scale models can then serve as a starting point for
Machinery Management Applications
The machinery and labor constitute a major component of
capital outlay in an operational farm system. In addition to
climatic and soil factors on which farmer has little or no
direct control, the machinery and labor control the
operational behavior of a farm system. Therefore, a large
number of farm-scale models have been developed to deal with
machinery and labor management aspects of farming operations.
These models serve as decision-aid tools for selecting an
appropriate mix for the machinery set, scheduling various
field operations, and estimating the cost of owning and
operating these machinery sets for a given farm setting. The
six categories of these types of models, namely linear
programming, simulation models, discount cash flow models,
computerized budgeting models, machinery replacement models
and machinery cost and utilization records (Nelson and Bowers,
1968), can be broadly divided into two groups: 1) the
analytical models and 2) the simulation models.
Analytical models are designed mainly for selecting and
pricing the machinery operations based upon the given cropping
calendars, cost of timeliness and other related factors. Most
of these models employ similar algorithms in selecting and
scheduling the machinery for different operations. They first
estimate available times (hours) to complete each operation
based upon available workable days and number of work hours
per working day. The models then estimate actual times
(hours) needed for each operation based upon machinery
capacity. The actual working times are added to the beginning
times of different operations to determine their completion
The actual start and finish times for critical operations
such as planting and harvesting are utilized to estimate
timeliness cost (Hetz & Esmay, undated; Burrows and Siemens,
1974; Ozkan and Edwards, 1986a; Sowell et al., 1988; Gui and
Siemens, 1986; Siemens et al., 1988). Some researchers have
utilized this algorithm in a reverse order to estimate the
machinery size to complete the operation within optimum time
period (Edwards and Michael, 1980; Ozkan et al., 1984; Chen,
1986; Siemens et al., 1988).
In all these applications, the machinery and labor time,
and timeliness of operations are converted in economic terms
to estimate the net returns from crop production activity by
using different machinery sets. In addition, some researchers
have developed software for estimating machinery capacities
and their cost of operations with no consideration to
timeliness factors (Ozkan and Edwards, 1986a; Lal and Frerie,
There is a wide variation in application of simulation
techniques for machinery management related problems. It
ranges from simulating one single operation for one crop to
simulating complete growing season with mono-crop or multi-
crop. The single operation models have mainly been developed
for harvesting operations. Glunz (1985) and Thai and Wilson
(1988) used discrete event simulation approach (Pritsker and
Pegden, 1979) for simulating harvesting operations for citrus
and peaches, respectively. On the other hand, Miles and Tsai
(1987) and Labiadh and Frisby (1987) used a discrete process-
oriented approach for simulating grain and hay harvesting
The models for a complete cropping season for a farm
setting have been developed using the activity network
technique (Link and Bockhop, 1964; Link, 1967; Von Bargen and
Peart, 1969), linear programming technique (Nagarajan et al.,
1985; Bender, 1984; Candler, 1968; Waund and Mundell, 1968;
Geyer et al., 1963), simulation approach (Tsai et al., 1987;
Chen and McClendon, 1985; Smith, 1985) and database management
concept (Gauthier and Kok, 1988).
Activity network analysis
In this approach the complete production system is
represented as a set of activities and events which are then
analyzed using standard operations research techniques such
as PERT (Project Evaluation and Review Technique) or CPM
(Critical Path Method) as explained by Link (1967).
The preference for one activity over another in case of
a conflicting situations and overlapping of timings for
different activities are some of the factors for which it is
difficult to account in this approach of simulation.
Linear programming approach
In this approach the n-stages of crop production are
represented by n-periods during which available time is
allocated to different activities to attain an optimum
allocation strategy. In this case the problem is solved using
a procedure (simplex algorithm) which optimizes the solution
by considering all the periods simultaneously. But the stages
in crop production are sequential, dynamic and interdependent.
This means that decisions at each stage would depend upon what
was achieved during earlier stagess. In addition, the basic
assumptions such as 1) additivity of resources and activities,
2) linearity of objective function, 3) divisibility of
resources and activities, and 4) single valued expectations
of the linear program restrict its capability in modelling
whole farm systems accurately. In addition, the linear
programming technique has to use an average weather year and
other values of operational coefficients. It cannot account
for nonlinear effects of bad weather, for example.
Integer Programming (Brown, 1974) and integration of
linear programming with simulation (Bender, 1984; Konaka,
1987) are some of the approaches which have been tried to
overcome the limitations of the linear programming approach.
Simulation has been utilized to study both continuous
and discrete systems. Continuous systems are characterized
by smooth uninterrupted changes in their state variables.
The rates of the state variables in such systems are
represented by differential or difference equations. In case
of discrete systems, the state of the system changes in
distinct stages, such as queuing models (Pritsker, 1984).
There exists great a variation among different farm scale
simulation models in terms of their approaches to development.
Tsai et al., 1987 used a systems approach for optimizing
multiple cropping systems employing a deterministic activity
network approach which combines simulation and optimization
techniques. Their model can be characterized as a field-scale
model. They assumed that the farm is well equipped with all
necessary machinery for the crops considered and there are no
constraints on scheduling of different field operations.
Chen and McClendon (1985) and Smith (1985) have developed
simulation models for handling double crop systems (two crops
in one year). Chen and McClendon's simulation model is
designed for soybean and wheat as double cropping. On the
other hand, Smith's model (CROP-PLAN) handles a variety of
single crops and is developed to work on an electronic spread
sheet package such as Lotus 1-2-3.
To add to the general constraints of the conventional
approach to simulation discussed in Chapter I, the farm-scale
simulation models reviewed and discussed above have been found
having the following limitations.
1. The farm-and-region specific knowledge is generally
"hard wired" in their computer code. This makes them very
location specific and inappropriate for other locations with
a different type of farm setting.
2. They permit assigning of only one tractor to an
implement. Farmers with more than one tractor at their
disposal in real world situation can operate the same
implement with different tractors based upon their
availability. They also have a set of priorities for
assigning different tractors to different implements.
3. The available work hours for different operations are
estimated using uniform rules for all operations based upon
the soil moisture characteristics and/or historic workable
days data (Bender, 1984; Rumsey et al., 1986). In most
situations, farmers use heuristics for deciding daily working
hours specific to each crop and each operation. For example,
different amounts of rain make farmers stop different
operations. Certain operations such as land preparation could
be stopped even with slight rains. On the other hand,
critical operations such as planting or baling dry hay could
be continued till the heavy rains make it impossible for the
farmer to work in the field.
4. They do not allow for irrigation days which make the
field non-available for other operations. This results in an
over-estimation of available time for plant protection
5. They are generally designed with limited interfaces
that require laborious entry of data files and study of many
pages of detailed output. This restricts their ability to
interact with the user as decision-aid tools. Even though it
has been long recognized by machinery management experts
themselves that the computer models with no support to teach
or guide the user on how to utilize its results would find
limited success (Eisgruber, 1968).
Knowledge Engineering Concepts and Applications
Knowledge engineering includes the task of acquiring
knowledge, and designing and building knowledge-based systems.
It deals with the representation and use of knowledge in
electronic form to solve problems that normally require human
intelligence or attention. Users can refer to knowledge-based
systems in much the same way as they might refer to an expert,
consultant and advisor. These systems intend to alleviate
man-computer communication problems.
In knowledge-based systems (popularly known as expert
systems) "knowledge" rather than "data" is the essential raw
material to be processed. The data are "facts and figures
from which a conclusion can be inferred." On the other hand,
knowledge is "a clear and certain perception of some thing,
the act, fact or state of knowing and understanding" (Webster,
1979, page 1007). In artificial intelligence knowledge-base
is a body of facts, rules and heuristics which form the basis
of knowledge systems. The information about other information
in a knowledge-base or knowledge about knowledge is referred
to as meta-knowledge (Williamson, 1985). Different
individuals can derive different knowledge from the same data
set depending upon their level of expertise and meta-
Knowledge has been classified differently by different
authors. Addis characterizes knowledge in three groups:
asserted knowledge, heuristic knowledge and mode of inference
(Addis, 1985). Williamson (1985) classified it as 1)
descriptive knowledge, 2) prescriptive knowledge and 3)
The knowledge required to represent a dynamic system and
to predict its operational behavior, as mentioned in Chapter
I, can also be classified into three broad categories: 1)
quantitative knowledge, 2) qualitative knowledge and 3)
Quantitative knowledge can be expressed in terms of
numbers and mathematical equations. A typical example of such
knowledge for an operational farm system could be the rate
equation which governs the work capacity of a machinery set
based upon its operational parameters.
Qualitative knowledge, generally difficult to express in
numeric form, consists of a set of heuristics and rules of
thumb governing the system. The preference of the farmer for
one field over another in allocating available machinery for
an operation is a typical example of this type of knowledge
for a farm system.
Procedural knowledge, also referred to as prescriptive
knowledge by Williamson (1985), deals with prescribing a
course of action in the presence of certain conditions. A
set of conditions to be checked prior to starting an operation
on a field is a typical example of this knowledge type.
Knowledge-Based Decision Systems
Knowledge-based decision systems are integrated systems
which combine simulation and knowledge systems and necessary
databases (Shannon, 1984). The main idea behind these systems
is to impart a component of "intelligent" functions in the
simulation process, generally performed by human experts, to
the computers. Such programs are reported to have high
acceptability by agricultural computer users (Smith et al.,
In a knowledge-based decision system, simulation provides
a model of the world which can be used to test ideas before
they are tried in the real world. The knowledge system, on
the other hand, provides a model of an expert which can be
used to discuss ideas before they are tried in real world.
Thus, the integrated system can be used for discussing
possible results of a problem without trying them in the real
world (Gaines and Shaw, 1986). The integration could also
provide a media which would be a two-way interaction between
a computer and its user (IntelliCorp, 1988).
Approaches to development
The approaches to developing knowledge-based decision
systems can be broadly classified as hybrid approach and
knowledge-based simulation approach (Moser, 1986; Beck and
Jones, 1988; 0' Keefe, 1986; Umphress and Pooch, 1987; Shaw
and Gaines, 1987).
Hybrid approach is the most popular form of integrating
simulation and knowledge systems. In this approach, the
knowledge systems and simulation models, developed separately,
are combined to work together. The simulation models
available for the system and/or specially developed for the
purpose are written using one of the procedural languages such
as FORTRAN, BASIC or PASCAL. The knowledge systems are
written in one of the artificial intelligence languages or
specialized shells. In this combination the simulation model
provides the knowledge about the system for the defined set
of circumstances and knowledge system interprets it for the
Most agricultural decision systems, discussed later in
the chapter, have been developed utilizing the hybrid
approach. One problem of this approach is incompatibility of
languages used for the two components, the simulation model
and the expert systems. This increases the resource (both
software and hardware) and time requirements for their
In the knowledge-based simulation approach the simulation
and knowledge systems are written using one single environment
thus providing a seamless system. In this approach,
components of many models may be organized into a model-base
(Reddy et al., 1986). The model-base acts as a library which
can be consulted for developing a specific model to address
a particular problem. The artificial intelligence techniques
are used to organize the model-base and also to identify those
models needed for a specific goal and design. In addition,
models can be integrated with databases and other application
The concept of modelling in knowledge-based simulation
approach is fundamentally altered (Oren and Zeigler, 1979;
Oren, 1986). The artificial intelligence techniques capture
knowledge about models themselves (meta-knowledge) in addition
to knowledge of biological and physical processes captured
within the models.
Languages for development
The computer programs written in conventional programming
languages speak in an imperative mode. They say, "do this,
then do this." The programmer has to define every step the
computer should go through in order to attain the objective.
The knowledge-based systems needs to represent the system in
more descriptive rather than in an imperative mode. The
programmer, known as knowledge engineer, in this case
describes the system in the form of knowledge-bases. He needs
to describe more clearly what to do rather than how to do.
This makes most conventional computer languages less suitable
for developing such systems. Specialized languages and shells
used to facilitate their implementation are discussed below.
Object-oriented programming (OOP). In these languages
and environments (various versions of SmallTalk (Stefik and
Bobrow, 1986)), the "objects" become the principal focus of
attention. The whole world of interest is expressed as a
collection of objects grouped into different classes referredd
to as object-class in this dissertation) and with a mechanism
by which they can communicate with each other and generate new
objects (Stefik and Bobrow, 1986; Lal et al., 1987; Pascoe,
1986). A specific instance of an object-class referredd to as
object-item in this dissertation) is generated when unique
values are allocated to different attributes of an object-
class. The representation of knowledge in different classes
and subclasses in an hierarchical manner facilitates the
development, utilization and maintenance of knowledge-based
systems. However, PC-based systems are not yet sufficiently
powerful to handle operational scale applications using this
PROqramming in LOGic (PROLOG). PROLOG is one of the
most widely used language for writing knowledge systems in
Japan and Europe. It is considered as a development tool.
It contains a basic scheme for representing knowledge (a
common characteristics of a programming language) and also
has a built-in inference engine which conducts its searches
to achieve its goal.
A program in this language is a collection of facts and
rules about different object-classes and their items of the
world of interest. From this collection, PROLOG derives
solutions to the questions by searching for clauses that are
true. The symbol and list processing capabilities, and
recursion in PROLOG facilitate handling qualitative knowledge
in addition to quantitative knowledge.
In recent years, there have been a few attempts to
develop simulation programs and simulation languages using
PROLOG as a base language (Adelsberger, 1984; Futo and
Gergely, 1986; Kornecki, 1986; Yokoi, 1986). Efforts have
also been made to develop object-oriented programming
languages using PROLOG (Futo and Gergely, 1987; Fan and
Sackett, 1988). The simulations in PROLOG have also been
referred to as goal-oriented simulation or logic-based
PROLOG provides a unique environment for developing
seamless knowledge-based systems (Shintani et al., 1986;
Walker et al., 1987) and was also selected for this
dissertation work. Both simulation and knowledge systems can
be developed under one single environment. In addition, it
provides the following advantages for writing simulation: 1)
It allows specification of the system in a much more
descriptive manner than most procedural languages.
2) It provides a convenient design facility. It permits
natural-language-like sentences which facilitate better
understanding of program logic.
3) The inferencing capability of PROLOG can be utilized
to diagnose causes for poor performance of the real system.
The system can then help the user in the process of designing
an improved plan for operations.
LISt Processing (LISP). LISP is the second oldest
computer language. It has two data structures: atoms and
lists. An atom is an element which cannot be divided further.
A list may be made up of atoms and of other lists. Lists are
separated from each other by parentheses. People who find it
difficult to keep track of the proper combination of
parentheses call LISP "Lot of Irritating Silly Parentheses"
(Williamson, 1985, Page 63).
LISP works by manipulating lists. It can also handle
recursive procedures. The data and procedure in LISP take
exactly the same form. Both are written as lists, what is a
procedure in one program can be data in another.
The LISP programs are also very demanding of computer
memory. The microcomputers generally run out of memory before
LISP can perform any significant task. Therefore, specialized
LISP machines have been developed to handle LISP programs.
Specialized development shells. The specialized
development shells accommodate the "synthesis" concept of
problem solving. It is an intermediatory concept between
"thesis" and "antithesis" (Walker et al., 1987).
The concept of thesis states that the general methods of
expert problem solving can be found, made computational, and
applied to many different problems (Newell and Simon, 1963).
On the other hand, the theory of antithesis put forward
by Fiegenbaum (Feigenbaum and McCorduck, 1983) states that
rather than generality, we should set out empirically to
capture human knowledge and procedures for each specific task.
Intelligence and reasoning power alone are not enough,
knowledge is needed for each specific problem. It means that
we should be willing to write a new program for each task.
The theory of synthesis essentially takes the middle
ground. The idea is that many tasks have requirements in
common, and these requirements can be met by knowledge systems
These shells are knowledge-less problem solver tools to
which the knowledge about particular tasks can be added. They
consist of a knowledge representation scheme, an inference or
search mechanism, a means of describing the problem and a way
to determine the status of the problem while it is being
solved (Citrenbaum et al., 1987).
There are a large number of commercial shells available
in the market. They range from interpreters of relatively
simple languages to very elaborate development environments
The selection of an appropriate tool for developing
knowledge-based systems depends upon factors such as cost,
availability of hardware, and type and specification of
problem domains (Elmaghraby and Jagannathan, 1986). Engel et
al. (1988) provide comparative evaluation of different
knowledge systems shells available on the market and a
procedure for selecting the most appropriate for the specific
Steps in development
The steps in development of knowledge-based systems can
be broadly divided into 1) problem identification and
conceptualization, 2) knowledge acquisition, representation
and manipulation, and 3) verification and qualification of
the system (Waterman, 1986; Hayes-Roth et al., 1983; Halterman
et al., 1986). All of these stages are interrelated and
interdependent. They need continuous recycling until the
system consistently produces the correct solutions.
The problem identification for knowledge-based system is
a critical step in its development process. Some of the
criteria for identifying candidate problems are 1) recognized
experts) exist and can solve the problem significantly faster
and/or more accurately than non-experts, 2) experts are
available to work on the project, 3) the problem solving task
routinely needs to be taught to others, 4) the problem is
well-bounded, 5) solutions can be validated and 6) the impact
of the system can be measured (IntelliCorp, 1988).
The successful implementation of a knowledge-based system
for an appropriate problem depends upon acquiring the
knowledge from domain experts) and representing it for
manipulation within the framework of the selected tool. A
great amount of work is being done in developing efficient
means for acquiring knowledge from domain experts (Jones et
al., 1986; Prerau, 1987). However, a new trend is for the
experts to write their own knowledge systems utilizing their
own knowledge (Ogilvie, 1988, Personal Communication).
Finally, the development of a knowledge-based system is
not complete until it has been verified for its functionality.
In general, the model testing can be divided into verification
and validation. However, in case of the knowledge systems,
the validation has been termed as "qualification" (Wildberger,
The qualification process of knowledge-based system
involves letting a team of peers evaluate and critique the
system in terms of its knowledge, logic, functioning, user-
interface, etc. It is analogous to a procedure used to
certify a human expert for his expertise. A knowledge system
designed to identify crop insects) and to make recommendation
on their control should be subjected to the same kind of the
qualification tests as an entomologist.
The verification and qualification of knowledge systems
may never end as they are never complete. Like human experts,
they should grow and adapt to additional knowledge as it is
gained. However, researchers are working on algorithms to
verify the consistency and completeness of knowledge-bases and
the recommendations developed by such systems (Nguyen et al.,
Applications of knowledge-based systems can be found
virtually in every walk of human life. They range from making
financial investment and marketing decisions (Thieme et al.,
1985; Bulkeley, 1986; Phillips and Harsh, 1987), to better
management of resources (Coulson, 1987; Davis and Nanninga,
1985), to factory design and industrial research (Fisher,
1986; Moralee, 1986).
Some of the earlier, more popular and commonly cited
knowledge systems (Morrison, 1985) are DENDRAL (for
identification of chemical structure of compounds), MACSYMA
(for complex symbolic mathematics), MYCIN (for diagnosing
bacterial infection and suggesting treatments), XCON (for
designing microcomputer configuration) and PROSPECTOR (for
identifying potential locations of mineral deposits). Most
of these applications are pure rule-based with no integration
of simulation or any other type of models.
The agricultural applications of knowledge-based systems
can be broadly divided into two categories namely 1) pure
rule-based systems and 2) knowledge-based decision systems.
Most of the pure rule-based applications are built using
development shells on microcomputers. They do not operate any
external programs or access any data produced by them. Their
applications range for selecting a particular type of
machinery (Gibson et al., 1986; Negahban et al., 1988), for
identifying pests and diseases and recommending appropriate
control remedies (Jones et al., 1986b, Donahue et al., 1988;
Gibson et al., 1986), for irrigation design, planning and
control of soil erosion (Thomson and Peart, 1986; Bennett et
al., 1988; Engel et al., 1988a), for controlling and managing
green houses (Jones and Haldman, 1986), to forest road
planning (Thieme et al., 1986), for managing animal waste,
weed growth in soybean and other crop production related
problems (Smith et al., 1985; Ruckman, 1986; Kalkar and
Goodrich, 1986; Nagarajan et al., 1987; Rettinger et al.,
1987), and for determining bottlenecks in on-farm grain
processing systems (Loewer et al., 1988). Role of such systems
in technology transfer, education and research has also been
emphasized by many researchers (Barrett et al., 1985; Jones
and Hoelscher, 1987; Lal et al., 1987; Slocombe, 1986).
The knowledge-based decision systems for agricultural
applications have been developed using both hybrid and
knowledge-base simulation approach (Beck and Jones, 1988).
The typical examples of the hybrid approach are the
systems reported by Jones et al. (1987), Batchelor et al.
(1987), Lemmon (1986), Kline et al. (1987), Khuri et al.
(1988) and Yost et al. (1986). Jones et al., 1987 describe
a system that recommends insecticide applications for the
soybean crop. A built-in economic model determines treatment
thresholds based upon market value of the crop, cost of
insecticide, stage of crop growth and expected yield. It then
utilizes the built-in heuristics to select the appropriate
The soybean pest management system (SMARTSOY) of
Batchelor et al. (1987) uses scouting data and expert
knowledge to project insect population for a week in the crop.
The estimates of damage potential by the insects in the field
are computed and are then used as input to the SOYGRO a
soybean crop growth model (Jones et al., 1988) to estimate
yield losses if control actions are not taken. The system
then recommends the type of insecticide to apply depending
upon the yield loss and grower sensitivity to risk. The
knowledge system is written in Level5 and the simulation model
is in FORTRAN.
The COMAX/GOSSYM (McKinion and Lemmon, 1985a; McKinion
and Lemmon, 1985b; Lemmon, 1986) works on a concept similar
to SMARTSOY. It recommends optimum scheduling of
fertilization, irrigation and harvesting for cotton crop.
GOSSYM is a cotton growth simulation model written in FORTRAN
and COMAX is the knowledge system part written in common LISP.
A system for analyzing the results of a linear
programming model aimed at selecting optimum combinations of
machinery systems for a crop production have reported by Kline
et al. (1986, 1987).
Citrus Harvest Expert Simulation System (CHESS),
developed by Khuri et al. (1988), interprets the results of
Citrus Harvesting Simulation Model (MACH II) written in the
SLAM II simulation language (Pritsker, 1984) and recommends
to the user how the harvesting operation can be improved.
The system developed by Yost et al. (1986) recommends
the appropriate dosage of lime for crop production for
tropical soils. It uses a set of equations to compute the
lime requirement and the relative yield loss without lime
application based upon crop, location and its soil type. Te
system checks the preconditions and qualifications which must
be evaluated in order to use these equations properly.
Agricultural applications using the knowledge-based
simulation approach are rather few and most of them are in
their initial stages of development.
COTFLEX is a farm level decision support system for
individual crops (Stone et al., 1986; Helms et al., 1987).
The frame based representation of farm knowledge allows to
store the attributes of the object-classes in their slots.
The values for these slots can come from one of four possible
sources namely 1) a simulation, 2) an expert system, 3) a data
base or 4) the user himself.
CALEX is a farm level decision system which consists of
an executive program which provides and controls the access
to data files, the knowledge systems and the simulations.
Facilities are provided by which the expert system can call
a simulation and vice-versa. It stresses the record keeping
aspect of farm management decisions (Plant and Wilson, 1986;
Plant et al., 1987).
POMME is a decision support system for apple orchards
(Roach and Virkar, 1986) which can advice on various
production practices including pest control recommendations.
An ADaptive Assembler for Models (ADAM) organizes
equations for calculating parameter values when several
alternative equations may be available (Whittaker et al.,
1987). It has been applied to the domain of soil erosion
modelling. It can help identify the erosion equation
appropriate for a particular situation.
The WHeAt Modelling expert system (WHAM) also uses
heuristic rules to assemble model components from a model-
base into a simulation to answer user's question (Rimmington
et al., 1987). In operation, the user specifies a set of
output variables to be predicted by the model. The model-
base is then activated to locate and assemble models which
can satisfy this goal.
Some of the most recent developments of integrating
knowledge engineering concepts with data processing techniques
as applied to agriculture were presented and are compiled in
the proceeding of a conference on "Integration of expert
systems with conventional problem solving techniques in
agriculture" (AAAI and ASAE, 1988).
SYSTEM DESIGN AND IMPLEMENTATION
An integrated decision support system should interact
with the user to collect information about the system, analyze
it utilizing the knowledge (both procedural and heuristics)
captured within itself, and provide the user with expert help
to improve the productivity of the system in the context of
the input knowledge as depicted in Figure 3.1.
A decision support system consisting of four components:
Operations Simulator, Expert Analysis System, Yield Estimation
System and Information Management System has been designed and
implemented using knowledge engineering concepts of Artificial
Intelligence. The integrated system has been referred to as
FARMSYS and discussed in this chapter.
The Operations Simulator simulates the field operations
for the complete cropping season with a one-day time step.
The Expert Analysis component examines the simulation reports
and makes recommendations for planning decisions of an
operational farm. The Yield Estimation component estimates
the crop yields and profits from different fields, crops and
the whole farm, and the Information Management System is an
intelligent user-interface to gather information from the user
Figure 3.1 Functioning of an integrated decision support
and to let him make changes in the existing farm knowledge.
The hierarchical representation of these components of FARMSYS
is presented in Figure 3.2.
The overall of goal of such a system is to provide a
planning and/or management tool for researchers, educators,
perhaps farmers, to "test" combinations of resources such as
equipment, crop mixes, labor, procedures (no-till, minimum
till, etc.) and weather for timeliness, yields and efficiency
of utilization of resources. It can be utilized for
evaluating the performance of different farms for a particular
weather year or to evaluate the performance of the same farm
over different weather years with different combinations of
labor, machinery and crop combinations.
The languages and development shells explored for the
dissertation work are SmallTalk V (Digitalk, 1986), VP
Planner and VP Expert, a combination of spread sheet and
expert system shell (Paperback Software International, 1985)
and Turbo PROLOG (Borland, 1986). And the Turbo PROLOG was
selected for the final implementation of the system, because
it provided an environment for simulating field operations in
an object-oriented manner, an efficient depth-first search
mechanism for the expert systems inferencing and an
appropriate frame work for representing farm, regional and
expert knowledge in the format of semantic nets, a popular AI
knowledge representation technique.
x < -4
0 -- -
Simulation in an object-oriented manner implies
representation and manipulation of farm knowledge as a
collection of objects along with a mechanism by which they
interact with each other and with the environment over time.
This approach enabled modelling the decision behavior of the
farm manager in a more realistic fashion than is generally
captured in the conventional approach to simulation in
In addition, PROLOG also permits compiling the final
program in the format of a executable file which can be
distributed to users with no obligations of any run-time
The model simulates field operations for an operational
farm system with given machinery, labor, crop combinations,
work schedule and other farm specific parameters. The process
of simulating agricultural field operations involves both
discrete events and continuous processes comprising of many
activities and numerous state variables.
The decision about the earliest start and latest finish
times for different operations in a cropping sequence is a
typical example of discrete events. The scheduling of these
operations within their agronomic work windows and allocating
the machinery as well as labor to different fields to carry
out these operations are the examples of event happenings.
On the other hand, once an operation starts its execution
is then controlled by a continuous rate process depending upon
the machinery capacity, climatic and other management factors.
The general sequencing of the operation types for crop
production is land preparation, fertilizer application and
planting, plant protection and harvesting. Each of these
could contain one or more operations and are the processes of
the system which are controlled by their state variables which
change dynamically with time.
All these factors make the task of developing a model
which would emulate the behavior of an operational farm system
very complex and challenging.
The inputs for the model for a farm can come either from
its present mode of activities or from a representative farm
of the region. The initial cropping systems for a farm can
be selected from the ones most appropriate for the region
which depend upon climate, government policies and other
market information about the region as depicted in Figure 3.3.
Farmers goals and his preferences, irrigation facilities at
his disposal, and his financial situation play key role in
making selection of cropping systems for his farm situation.
The selected cropping systems along with machinery and labor,
agronomical inputs and management decisions when applied to
farm fields result in crop production for the market and/or
CLIMATE POLICIES INFO
INDV. PREF. REGIONAL IRRIGATION FINANCE/
AND GOALS CROPPING FACILITY BANKS
AGRONOMI- SELECTED MACHINERY MANAGE-
CAL INPUTS CROPPING AND MENT DE-
SYSTEMS LABOR CISIONS
Objects and environment of an operational farm
system with crop production activity.
The inferencing capability of logic programming (PROLOG)
employed for writing the simulation facilitated to incorporate
several expert systems within the simulation to make heuristic
decisions and other types of searches at various stages of the
Farm as a System
The farm is a complex system and is considered as an
intermediate level in hierarchical representation of an
agricultural system (Hart, 1984). It contains many subsystems
and sub-subsystems. Each of these systems contain many
object-classes and object-items along with their attributes
and values. Table 3.1 presents the object-classes with their
attributes needed for simulating field operations for an
operational farm system, and the specific items of each type
of these object-classes with their attributes are depicted in
Figure 3.4 for the Davis farm used as a test farm for the
operational verification of the model discussed in chapter IV.
The interrelationship between different farm object-
classes in the form of the semantic nets is shown in Figure
3.5 and discussed below.
The farm has a name, location, total area, cultivated
area, a principal activity and an extension code name for
storing its (farm) information. It possesses fields, crops,
implements, tractors, laborers and a work schedule.
fieldi("Field 1", fielddl, 20, "SandyLoam",
["Cotton", "Wheat"],["DPL41", "FL302"],
[150, 165], ["Fertilized", "Fertilized"],
"NotIrrigated", "NotNeeded", [750,125],
operations("PlantFertiOps", "Planting", "Soybeans",
136, 182, [[0,3,1],[3,8,0.5]], ["Planter_77"],
Figure 3.4 Examples of items of different object-classes
of Davis farm in the format of dynamic databases
0 E UJ _
0 a: < 0O~ O
f Lu o E D
U 3 F
0 F (0
cc Q 0 0
(D t I 0 a 4-)
QI In1 In 4-)
W 0 0 ( L l Il F
o j D
0 LL L I a)
a: cc c L (-)
"I I I CO D
Farm Objects and their Attributes
Farm Name, Location, Total Area, Cultivated Area,
Principal Activity, Farm Code
Number, Name, Sex, Functions, Availability
Model, Hp, Operators List, Availability
Number, Type, Name, Tractors/Operator List,
Width, Speed, Availability
Number, Specification, Capacity, Operators
Number, Name, Operations List
Number, Identification, Area, Soil Type, Crop
List, Variety List, Maturity Days List,
Fertilizer Type List, Irrigation Type,
Production Cost List, Sale Price List,
Operation Type, Operation Name, Crop, Earliest
Start Time, Latest Finish Time, Work Hours
Conditions List, Implement List, Efficiency
Work Hours Month, Schedules Daily Working Hours
A laborer has his/her name, sex, functions and
availability status. The number of laborers available on a
farm could depend upon its size, mechanization level and
A tractor has a number, make and model, horse power, a
list of operators and its availability status. The horse
power of the tractor controls the type of implement it can
operate. The operators list contains the names of the farm
laborers who can operate the tractor.
Irrigation equipment, similar to a tractor, has a number,
specification, capacity, list of operators and its
availability status. If the equipment does not need any
operator during its operation, then its operator list could
An implement is characterized by its type, name, working
width, speed of operation and a list of tractors or operators
needed to operate it. For a self-propelled and manually
operated implements, the list contains the names of the
laborers who can operate the implement. In case of the
implement which needs a separate power unit for its operation,
this list consists of tractors or animals needed to power the
implement. For completing the machinery system for such an
implement, the laborer needed to operate the implement is
selected from the list of laborers attached to the selected
power unit for use with the implement.
A crop has a number, its name and a list of operations
needed to grow it. In addition, the variety, number of days
for maturity after planting, the fertilization level, the
production cost and the sale price associated with the crop
are also assigned to the field on which it is grown.
A field has a number, its name, the area, the soil type,
irrigation facility, etc. It can be utilized to grow two
crops in a year. A farm could have any number of fields as
long as the sum total of the fields' area does not exceed the
cultivated area of the farm.
An operation has a type, name, earliest start time,
latest finish time, work hour conditions, efficiency and an
implement list. The earliest start time is the time before
which the operation cannot start, and the latest finish time
is the time after which the operation should no longer be
continued. The work hour conditions associated with an
operation are a set of conditions which define how many hours
the operation should be carried out depending upon the
rainfall and the scheduled work hours for the day. The
implement list contains implement names which could be
utilized for the operation.
The scheduled work hours are daily working hours for each
month of the year. It is utilized to estimate the actual work
hours for different operations based upon their work hours
conditions and rainfall of the day.
In addition to the farm objects, the simulator also needs
local weather and evapo-transpiration data and crop irrigation
requirements for scheduling irrigations.
The information about different farm objects for the
simulation is stored in the form of relational tables
(referred as dynamic databases for Turbo PROLOG). It is a
special feature of the logic programming environment which
facilitates representing facts about the objects and their
relationships within the system. It can include qualitative
knowledge, in addition to quantitative and procedural
knowledge, which would have been difficult to do in
conventional programming environments.
The preference of the farmer for selecting operators out
of his labor crew for a tractor and assigning an order of
priority for each of them is a typical example of qualitative
knowledge. It has been captured in PROLOG by representing the
selected operators in a list and attaching it to a tractor.
The search for an operator to work with the tractor is carried
from left to right. So, the laborers in this list should be
listed in order of preference to operate the tractor. Similar
logic applies to the list of the tractors for an implement and
to the list of the implements for an operation. In addition,
this representation also provides the facility of listing
backup implements for an operation which are generally ignored
in conventional programming models of simulation.
The simulation model is structured in two distinct
components: a) farm and region specific knowledge, and b)
procedural simulation knowledge. The farm and the regional
knowledge needed as an input to the simulation is maintained
separate from its procedural knowledge. This has made the
model a versatile and flexible. It can be utilized for
different kinds of farm settings with little or no
Farm specific knowledge consists of a number of ASCII
files containing information about the different objects of
the farm system in the form of dynamic databases of PROLOG
(Figure 3.4 and Appendix I). This component needs to be
developed by the user for his specific farm setting utilizing
Intelligent Information System discussed later in this
Procedural simulation knowledge is a PROLOG program
consisting of several predicates and clauses (discussed later
in this chapter). It carries out the actual simulation. The
compiled version of the program cannot be accessed by the user
for any modification. The execution of the simulation goes
through the following steps in sequence as depicted in Figure
GET FARM, WEATHER
FIND CROPPING SEASON
SELECT FIRST DAY AS
FOR THE CURRENT DAY
MAKE ALL FIELDS, LABOR
AND MACHINERY AVAILABLE
WORK ON FIELDS) READY
UPDATE CURRENT DAY
LAST CROPPING DAY
Flow chart of execution of the operations
Step 1. Get farm name and consult all related files.
Step 2. Let the user select weather year and allow him
to adjust work schedules, if he so desires.
Step 3. Simulate the operations for the cropping season.
This step finds out the first and last day of the cropping
season and carries out the following during this time
I. Make the first day of the cropping season as the
current day and carry out the simulation for the current day
using following sub-steps.
1. Make all fields, labor and machinery available for
2. Pick up the first field from the field file and carry
out the checks and the actions listed in Figure 3.7 for
scheduling irrigation and other field operations.
3. Repeat the above procedure for all fields of the farm.
II. Update the current day by one day.
III. Check if new day is greater than the last day of the
cropping season, if not repeat the above process, else
terminate the simulation.
Step 4. Preparation of simulation reports.
The simulator prepares five reports. Specific contents
of these reports are listed in Table 3.2. The user can access
any of them by use of any editor to analyze the simulation
results. However, the summary report is automatically
displayed on the screen on completion of the simulation.
1) Calculate soil moisture of the day based upon
yesterday's ET, rain and irrigation, if any.
2) Check if the field has a irrigation facility
and if so find out the irrigation equipment used
on the field.
3) Check the availabilities of irrigation equipment
and any operators needed to operate the equipment.
4) Check number and amount of pending irrigations
5) Irrigate the field, if soil moisture is below
threshold, number or amount of pending
irrigations is not zero and irrigation equipment
and operator are available.
6) Make the field, the equipment and the operator
associated with the irrigation non-available for
the day, else do not change their status. Update
the soil moisture status of the field irrespective
of decision about the irrigation.
7) If the field is not being irrigated, get the
list of operations associated with the crop being
grown on the field.
8) If the operations list is not empty, pick up
first operation from the list.
Figure 3.7 Tasks performed by the Operations Simulator for
scheduling irrigation and other field operations
for a field on daily basis.
9) Check if the operation is the type of operation
being tried now.
10) Get details for the operation such as
agronomical work window, implement list, etc.
11) Check suitability of the "current day" for the
operation with respect to its agronomical work
window. The "current day" should be within the work
window of the operation.
12) Check the availability of the required machinery
set for the operation; the implement and the
operator in case of self-propelled implements, and
the implement, the tractor (power unit) and the
operator in the case of other types of implements.
13) If all the above conditions are satisfied carry
out the operation based upon the implement
characteristics; working width, speed of operation
and actual work hours and operation efficiency.
14) Record the work and no work as applicable and
remove the operation from the list, if it has been
completed or its latest finish time has passed.
15) Make the machinery set (Implement, Tractor and
Operator) and the field not available for the day.
Simulation Reports and their Contents
Report Description Contents
Work Report for Julian day, field name, irrigation
Irrigation applied (mm of water), irrigation
equipment and operator used, day's
soil moisture, pending number of
irrigations and their amount.
Work Report for
No-Work Report for
No-Work Report for
Julian day, month, field, crop,
operation, total area, accumulated
done area, day's work, implement,
tractor, operator, and number of
Julian day, month, field, crop,
irrigation equipment and its
availability report, operator and
its availability report.
Julian day, month, field, crop and
operation, total area, done area,
reason of no-work, implement list
and its availability report, operator
list and its availability report,
tractor list and its availability
Summary Report for Field, crop, operation, scheduled
Field Operations start and finish times, actual start
and finish times, number of days and
hours worked, total done area, number
of non-working days.
- - - - - - - - - - - - - - - - - - - - - -
In the process of the simulation the fields are served
on a first-come first-serve basis. The user should enter them
in order of the priority that he wants them to be checked for
The priority for different operations is built-in the
program code. Irrigation, if the field has irrigation
facility, is given the highest priority followed by
harvesting, plant protection, planting and land preparation
operations. However, the structure of the simulator permits
one changing the priority to suit specific cases.
Machinery and labor present on the farm are assumed to
be available for work for the complete duration of scheduled
work hours. They are also assumed to have 100% reliability
within the operational efficiency defined for the operation
they are assigned to perform.
Simulation in PROLOG
PROLOG is an AI language which has been utilized for
developing knowledge systems. The use of this language for
simulation is rather recent and limited. Therefore, this
section explains how PROLOG has been utilized for carrying
out the present simulation.
A program in Turbo PROLOG consists of five sections
namely domains, databases, predicates, clauses and a goal.
The sections of predicates and clauses are the principal ones.
A predicate is declared by stating its name and the domains
of its arguments. A clause is either a fact or a rule
corresponding to one of the declared predicates. Borland
(1986) describes the contents of each section in detail.
PROLOG has a built-in inference engine which searches
through the knowledge-base in a backward chaining manner. In
this mode, a goal to be achieved is pursued by searching
through the true clauses. It includes a pattern matcher,
which retrieves stored (known) information by matching answers
to the questions. The information supplied to PROLOG (the
facts about the objects of the system and rules governing
their actions and behavior) become the finite set of knowledge
to work on.
In addition to logically finding answers to questions,
PROLOG can deal with alternatives and find all possible
solutions rather than only one. Instead of proceeding from
the beginning of the program to the end, PROLOG can actually
back up and look for more than one way of solving each part
of the problem. This process of backing up is known as "back
tracking" and can be achieved by various ways as discussed by
Flowers (1988). The process of "back tracking" has been
utilized for simulation in PROLOG to develop an effect similar
to looping in conventional procedural languages.
A simplified version of the actual program code of the
simulator is presented in Figure 3.8. The given code consists
of three principal predicates, "doSimulation",
getFarmKnowledge(labor, field, equipment,
crop,irrigate, operation, tractor,
Figure 3.8 Simplified code of operations simulation in
OpsList,,_,_,_ _, _),
OpsList,_,_ _, ,_,_),
__I__i__ _/_) ,
"simulateSeason" and "simulateADay" which work in an
hierarchical order. They can be thought of as subroutines in
The predicate "doSimulation" creates the necessary
conditions for the simulation by bringing the farm as well as
other knowledge to the memory using predicates
"getFarmKnowledge" and "getOtherKnowledge." It then calls
"simulateSeason" and writes reports on successful completion
of the seasons's simulation.
The "simulateSeason" predicate has two arguments: start
day (SDay) and finish day (FDay). The Turbo PROLOG predicate
"asserta" puts "SDay" into the dynamic database "currentday."
Then it collects the same day value by use of the database
predicate "currentday(SimDay)." Then it calls "simulateADay"
five times with the current day and different operation types.
The order of calling this predicate with different operation
types determine their priority over one another. Under the
current format irrigation gets the highest priority followed
by harvesting, plant protection, planting and fertilizer
application, and land preparation operations.
On the successful completion of the one-day simulation,
the current day is updated by one day (Sdayl=Sday+l), and the
content of the "currentday" database is changed by the use of
predicate "changeDay." Finally, a check is made to see if the
updated day is greater than the last day for the simulation
(Sdayl>Fday). This condition is satisfied when the simulation
for the whole period is completed, otherwise the condition
fails and backtracking begins.
The backtracking proceeds up through different predicates
until it encounters "repeat." The "repeat" predicate is a
non-deterministic clause which always reverses the
backtracking process. On the reversal of the process, PROLOG
finds the content of the "currentday" database changed and
picks it up for further actions of calling the "simulateADay"
predicate with the new day. The process is repeated with one
day increments until (Sdayl>Fday) becomes true and the
execution of the predicate "simulateSeason" is successfully
The "simulateADay" predicate is designed to carry out
one day simulation for the current day (Sday) and the given
operation type (OpsType). The dynamic database fieldd"
consists of entries of all the fields with the crop being
grown on them. These entries are made in order of priorities
of the fields to be served by the simulator. During execution
of this predicate, the first field (FieldN) and the crop
(CropN) being grown on it are given to predicate
"chkCondAndWork" to carry out its task.
The predicate "chkCondAndWork" checks various conditions
and carries out different actions as listed in Figure 3.8 for
the simulation. It also calculates the amount of work done
based upon the available machinery set and prepares different
On successful completion of the task of "chkCondAndWork"
for the current field, crop and operation type, the predicate
"fail" causes the clause to fail and forces it to backtrack.
In this case, the backtracking occurs up to database
predicate fieldd" which acts like a non-deterministic clause.
At this stage PROLOG picks the contents (FieldN and CropN) of
the next entry in the database and repeats the steps of this
clause in hope of succeeding. However because of the "fail"
predicate, it fails again. The process is repeated until all
the entries of the fieldd" database have been tried. Having
worked on all the entries of the database fielddc, the clause
fails even prior to calling predicate "chkCondAndWork." Then,
PROLOG searches for an alternative "simulateADay" clause or
rule, and finds "simulateADay(_,_):-!.", which always succeeds
for any value of SDay and OpsType, thus successfully
completing the task of simulation for the instantiated values
of the operation type and current day for all fields on the
farm. The same process is repeated for all the operation
The simulation checks the possibility of carrying out all
types of operations on every field daily throughout the
cropping season. The predicate "chkCondAndWork" does this
task very efficiently. Its structure and sequencing avoids
deep level searches for the operations on the fields not yet
ready to receive them. It is so structured that the actual
time for a day's simulation decreases as the work on different
fields is completed and the operations lists associated with
them become empty.
The "chkCondAndWork" is a multi-clause predicate and it
makes use of many other PROLOG user-defined predicates
detailed in Table 3.3. The tasks performed by different
clauses in order of their listing (Figure 3.8) are as follows.
The first clause checks if the current operation list is
empty (OpsList=). If this condition fails, which means that
there are still some pending operations for the field, PROLOG
goes on to the next clause; else, it assumes that the work for
a particular call of the predicate is done and returns that
message to its user clause ("simulateADay"). The second
clause determines if the operation being tried is of the type
intended to be examined. If this conditions succeeds, the
clause fails and control is passed on to the next clause.
Else, appropriate adjustments in the field database are made
using "adjustParameters" and "recordWork" predicates without
carrying on any further action.
The third clause takes care of the fields with sequential
cropping systems. It checks if all the operations associated
with the first crop grown on the field have been completed.
If this condition succeeds, the clause fails and passes the
control to the next clause. Else, it prepares a no-work
report with the reason determined by predicate "decideWork3"
and adjusts the field's records accordingly.
User-defined PROLOG predicates and their
description, used by different clauses of
"chkCondAndWork" of the Operations Simulator for
scheduling field operations on daily basis.
field a database predicate to control sequencing of
different fields in the simulation process.
a database predicate containing additional
information about fields not included in the
a database predicate to keep track of actual
status of fields during various stages of
checks if an object (Opsl) is a member of an
object list (OpsTypeListl).
a database predicate to store details about
operations associated with different crops.
The attributes associated with the operation-
class are listed in Table 3.1.
a predicate with three arguments. It takes
"Sday" and "FtOpera" as inputs and checks if
current day (SDay) has passed the FtOpera and
returns an answer "AnsT" (Yes or No) to that
adjust- adjusts the values of "OpsList", "Tarea",
Parameter "CUarea" and "Darea" respectively to
"OpsListl", "Tareal", "CUareal" and Dareal"
based upon the values of "AnsT" and "AnsA" (Yes
and No) which are also supplied as input. It
removes the completed operation from the
current operations list and set the done area
back to zero for the next operation based upon
the values of "AnsA" and "AnsT".
chkAreaFinish checks if "Darea" for the current operation
has equaled or exceeded the currently used area
of the field.
records the current status of the field. It
removes the old status of the field from the
database "field" and asserts a new entry with
updated parameters which are received from the
collects and records information about the work
which were attempted but could not be done
including its reasons.
three predicates: "decideWorkl","decideWork2"
and "decideWork3" are designed to decide
further course of action based upon the
instantiated values of different variables of
checks the availability the implement(s) form
the implement list "ImpList" associated with
the operation. The predicate returns the name
of the machinery set (Implement, Tractor and
Operator) and its operational parameters
(ImpWidth and Speed).
a database predicate stores the daily weather
conditions such as Rain, etc.
a database predicate stores the daily scheduled
work hours on the monthly basis.
calculate- calculates the actual working hours (WrkHrs)
HrsIndOps for the operation based its operating
conditions (OpsCondList), rainfall (Rain) and
scheduled work hours (WorkHrs) for the day.
changeOpStday changes the earliest start time for harvesting
operation based upon the planting date and the
number of days required to mature the crop.
makes the machinery set "Tractor" and
"Implement" including their operator, engaged
for an operation occupied; and not available
for any other activity for the day.
finds out the minimum value "DareaR" of two
supplied input values (TDarea and CUareaR)
finds out the maximum value "CUareaR" of two
supplied input values (CUarea and DareaR).
takes various parameters of the day's work
and asserts them to the daily work report.
The fourth clause makes sure, before passing command to
fifth clause, that the field being worked upon is available
for receiving the services and is not engaged in any other
operation, such as irrigation.
The fifth clause, the heart of this predicate, carries
out the actual task once it receives the command. It makes
a few additional checks prior to carrying out the actual task.
It checks if the current day is within the operation's work
window, searches for the machinery needed for the operation
and determines its operational parameters, estimates the
actual work hours for the operation for the day and calculates
the day's work and accumulated area done by the operation.
It adjusts field databases, records work or no-work reports,
and makes the machinery and labor utilized in the operation
occupied and not available for any other operation for the
The sixth clause is the terminating clause which always
succeeds to continue the process if all the above five clauses
fail due to some reason or other.
Expert Simulation Analysis
The foremost question in analyzing farming operations
is, was a particular operation started and/or completed on
time? If an answer to such a question is negative, then the
next logical question is, what factors are responsible for
the delays, and how they can be overcome?
Farm managers also need to know how different farm
implements, power sources and labor performed on his farm
during the cropping season. They want to identify under-
utilized and/or over-burdened machinery and labor in order to
better plan their operations for the next season. They may
like to arrange supplementary units for the most needed
machines or withdraw under utilized machines and labor, if
The reports on the performance of any selected
combination of items for different farm object-classes can be
of great help to farm managers. These reports can be utilized
for preparing budgets of different activities either for their
own records or for tax purposes.
Answers to all above queries are available but hidden in
the reports produced by the operations simulation discussed
in earlier in this chapter. The output reports produced by
the simulation are bulky and complex. Their complexity
increases as the farm size (number of fields, crops and
machinery resource) increases. Interpretation of these
reports in the context of the available machinery and labor
resources to respond to above queries is the most critical
step in engineering farm knowledge for the decision support
An expert analysis system is designed and implemented in
PROLOG to answer to the above queries based the simulation
reports. It is designed to implement a logical reasoning
approach which characterizes delays in operations based upon
the built-in or user-supplied heuristics, studies labor and
machinery utilization on the farm during the cropping season,
and makes recommendations for their efficient planning and
The expert analysis system consists of three components:
1) Operation Analysis Report, 2) Machinery Usage Report and
3) Accumulated Work Report. All these components are
structured to work independently but in harmony with one
another. The user can work with them in any sequence he
desires. In addition, they work in an interactive and
repetitive mode as depicted in Figure 3.9. The user can
utilize them to prepare as many reports as he desires. On
the completion of each report, the user has the option to quit
the program or to get another report for a different set of
The Operations Analysis Report analyzes different
operations for their timeliness in start and/or completion.
It identifies factors responsible for the delays, if any, and
presents them to the user along with the recommendations for
their remedies in a cost effective manner.
The Machinery Usage Report provides the user with the
seasonal and monthly utilization of items of different farm
object-classes such as implements, laborers and tractors. It
identifies the most and the least utilized items of the
29 O O O
0 0oZ cr co
-- 1- X
S. -- W ]
o o a O ,
D- 0 (D 0 l 0 i 4 >:
w co wI u:
co W 0 "- : wr
0 0 m Q OZ J
z W C.)
w -J w uj w ( o9 I-I
w CC 0 _^
Co i- a n
w I- 5
w w w ,
C Co r-- 0
w co W 0o
co Co I- w Co
z I 0: ^-- 0 < Q o)
Co_ z z 7
<0 W0 wC -- <
0 Co o
< C3 w i_ -
Sz cc Z co Wo
0 w cc < z < co :5
w C CL 0
QL co 1
selected class and recommends either to withdraw or to keep
the least utilized item based upon its utilization level and
its allocation strategy for different jobs supplied by the
user for his farm.
The Accumulated Work Report provides the user with an
aggregate work summary for any combination of the items of
different farm object-classes for the desired time interval.
Utilizing this report, the user can get answer to questions
such as how many hours "Laborerl" worked with "Tractor_2"
for "Soybeans" fields during January 1 to June 30?
The Operations Analysis and Machinery Utilization reports
work in a competitive manner with each other. The Operations
Analysis report identifies bottlenecks in the farm system and
always attempts to recommends for increasing the machinery
capacities. On the other hand, the Machinery Utilization
report identifies under-utilized machines and laborers, and
attempts to recommend their withdrawal from the farm.
Therefore, these two reports in conjunction with the
Accumulated Work report can be a very effective means of
arriving at an appropriate level of machinery and labor for
a given farm system.
Operations Analysis Report
The delays in critical operations such as planting, plant
protection and harvesting in crop production can cause serious
damage to crop yields. These delays could be due to lower
working hours put in during the operation and/or insufficient
working capacity of the machinery utilized. In addition, the
delay in one operation may cause holdups in subsequent
operations because of their sequential nature. The present
report is prepared by utilizing the work summary report of the
field operations simulator discussed earlier in this chapter,
and it makes use of built-in or user-supplied heuristics to
develop various recommendations. Figure 3.10 presents the
flow chart of functioning of the report and its development
process. For preparing this report, the system goes through
a decision process of characterization of the delays,
identification of operations) to be analyzed and the problems
causing these delays, and development of appropriate
recommendations. The steps involved in this decision process
are discussed below.
Characterization of delays
An operation is said to be delayed if it is not carried
out within a critical time period. This period for an
operation could depend upon its type, location, crop and soil
characteristics. It is not possible to develop any global
rule set that would be applicable uniformly for all types of
agricultural operations. However, for the sake of the
demonstrating the functions of the analyzer, a rule set
depicted in Figure 3.11 and stated in Table 3.4 has been built
into the system. According to this set, an operation is
t USER'S SUPPLIED
Flow chart of functioning and decision
process in the Operations Analysis Report
SCHEDULED Good Start and Good Finish
Actual n Actual
START Start Finish
Good Start and Bad Finish
Bad Start and Good Finish
Start and Bad Finish
Schematic representation of built-in heuristics
for the Operations Analysis report of the Expert
Rule set for qualifying delays in an operation
based upon its actual start and finish times
within its agronomical work window using the one-
The operation starts
within first one-third and
finishes before last one-
third of the operational
The operation starts within
first one-third and finishes
during last one-third time
of the operational window.
The operation starts after
first one-third and finishes
before last one-third of the
Good Start and Good Finish
Good Start and Bad Finish
Bad Start and Good Finish
The operation starts after
first one-third and finishes
during last one-third of the
operational window. Bad Start and Bad Finish
considered as delayed start if it commences after one-third
of its agronomic window, and is characterized as delayed
finish if it continues in the last one-third of the window.
A second version of the analyzer permits the user to
define the critical window within the agronomic window for
each operation individually.
Operations) to be analyzed
The delay in an earlier operation on a field could holdup
the start of the current operation. For such a situation, the
system need to analyze the earlier operation either by itself
or in combination with the current operation for identifying
causes of delays in the current operation. This leads to
three following combinations to be analyzed: 1) earlier
operation only ("LastOpsOnly"), 2) current operation only
("CurrentOpsOnly") and 3) both operations ("BothOps") as shown
in Figure 3.10. The system identifies such situations by
looking at the actual completion of earlier operation and
comparing it with the actual start of the current operation.
Actual done area for the operation ("DoneArea") is also
considered in making these decisions. Table 3.5 presents
these criteria in the form of induction rules and Figure 3.12
shows some examples of converting the entries from this table
into actual rules. The Example Rule 3 in Figure 3.12 states
that the earlier operation (LastOpsOnly) need to be analyzed
Example Rule 1 (Entry No. 1)
IF Good Start and Good Finish
And Done Area=Cult. Area
THEN Every thing as required
Example Rule 2 (Entry No. 2)
IF Good Start and Good Finish
AND Done Area
THEN Analyze the CurrentOpsOnly.
Example Rule 3 (Entry No 4)
IF Bad Start
AND Good Finish
AND Cult.Area=Done Area
AND The current operation started
immediately after completion
of last operation
THEN Analyze the LastOpsOnly.
Example Rule 4 (Entry No. 5)
IF Bad Start
AND Good Finish
AND Cult.Area>Done Area
AND The current operation started
immediately after completion
of last operation
THEN Analyze BothOps.
Figure 3.12 Examples of a rule set for identifying operations
to be analyzed for delays in the current
operation based upon the Table 5.2
Table 3.5 Induction table for developing rules for
identifying the operations) to be analyzed for
the delays in the current operation.
No. Good Good Operations to
Start Spec. Cond. Finish DoneArea be Analyzed
1 Yes Yes =Cult.Area "Every Thing OK"
2 Yes Yes
3 No (StCA=FnAL+l) Yes =Cult.Area "LastOpsOnly"
4 No (StCA>FnAL+l) Yes =Cult.Area "CurrentOpsOnly"
5 No (StCA=FnAL+l) Yes
6 No (StCA>FnAL+l) Yes
7 Yes No =Cult.Area "CurrentOpsOnly"
8 Yes No
9 No (FnAL>=StCS) No 0.0 "LastOpsOnly"
11 No (FnAL
12 No No 0.0 "MisMatchedImp"
13 No No =Cult.Area "BothOps"
14 No No
StCA Actual start of current operation
StCS Scheduled start of current operation
FnAL Actual finish of last operation
FnCS Scheduled finish of current operation
Cult.Area- Cultivated Area
LastOpsOnly Only last operation responsible for delay
CurrentOpsOnly-Only current operation responsible for
BothOps Both operations (current and last) responsible
if the operation had delayed start, timely finish and it
started immediately after completion of the earlier operation.
Identification of problem
The delays in an operation can be caused because of
shorter working hours and/or low working capacity of the
machinery utilized. The low machinery capacity can be further
attributed to either low working speed and/or to its size in
general. The system is designed to identify all these factors
using the following procedure.
1) The system estimates average work hours for the
operation and compares them with the recommended daily work
hours stored in an expert file. The average work hours for
an operation is calculated by dividing total work hours by
number of its working days. The recommendation is made to
increase the working hours during the period of agronomic
window of the operation, if the average work hours are less
than the recommended work hour for the operation type.
2) In case there is no possibility of increasing work
hours for the operation, the system analyzes the implements
associated with the operations) in order to identify their
(implements) operational parameters for improving timeliness
of the operation.
The implement list(s) attached to the operations) being
analyzed is(are) divided into three sub-lists of different
implements types namely self-propelled, perfectly-matched and
under-sized implements. The self-propelled implements have
their own built-in power source. On the other hand the
perfectly-matched and under-sized implements are those which
need a separate power unit for their operation.
An implement is considered as a perfect match to a power
unit if the power available from the unit almost equals the
power required by the implement. The implement is classified
as perfect match to a list of power units if more than 50% of
the power units have perfect match to the implement
individually. The implements which fail to meet these tests
are classified as under-sized implements.
Development of recommendations
The system makes one or more of the following
recommendations in order to reduce the delays in an operation:
1) Increase working hours during the operation window,
2) Increase speed of operation or working width of under-
3) Increase operational capacity of self-propelled
4) Increase operational capacity of perfectly matched
The system uses the following steps to develop the
1) It identifies the operations) to be analyzed and
their problems using the criteria discussed earlier.
2) It recommends increasing daily work hours in case it
is considered as a problem. Else, it analysis the implements
associated with the operation and makes recommendations to
adjust their operational parameters.
For perfectly-matched implements, it recommends
increasing the size of the implements and their associated
For the under-sized and self-propelled implements, the
system compares the speed at which the implement is being
operated to the recommended speed for the operation type. If
it is lower than the recommended speed for the operation type,
it recommends increasing it within allowable limits for the
operation type. In case of under-sized implements, it
calculates the possible increment in implement speed to match
up its power units (not exceeding the recommended speed) and
advises accordingly. Else, it recommends a bigger size
implement and the associated power units, if applicable.
For a single operation case ("CurrentOpsOnly" and
"LastOpsOnly", Table 3.5), it is either a "WrkHrsProb" or
"ImpProb" (Table 3.6a). However, for both operations case
("BothOps", Table 3.5), it could be any combination of the
two types of problems (Table 3.6b). The expert analyzer can
handle all these situations.
Induction table for identifying the actual
problems) with the operations) to be analyzed
for the delays in the current operation. a) case
of one operation being analyzed, b) case of both
operations (current and previous operations being
Induction table for identifying the actual
problems) with the operations) to be analyzed
for the delays in the current operation. a) case
of one operation being analyzed, b) case of both
operations (current and previous operations
Current Operation Last Operation FurtherAction
AvgWrkHr>WrkReco AvgWrkHrs>=WrkReco ImpBoth
AvgWrkHrs- Calculated average work hours for the operation
WrkReco- Recommended work hours for the operation
WrkHrsBoth- Recommend increased work hours for both operations
Check implement list for the current operation
and recommend increased work hours for the last
Recommend increased work hours for the current
operation and check implement list for the last
WrkHrsProb- Work hours problem for the operation being
analyzed and recommend increasing them
ImpProb- Problem with implement used for the operation,
check the implement list of the operation being
The two versions of the analyzer (with a built-in
heuristics and user-supplied heuristic) make the same types
of recommendations and use similar development process with
slightly different execution procedures.
The analyzer with the built-in heuristics automatically
studies all the operations carried out by the simulation model
and separates those which are considered having delays in
their start and/or completion. It identifies the causes for
the delays and remedies to overcome them, and stores this
information in a separate file for presentation of the
The reports are presented using the screen layout shown
in Figure 3.13. The user selects the field, the crop and the
operation from the pop-up menus for which he wants the
system's analysis and recommendations. The report and the
recommendations are then presented in the lower half of the
screen (Figure 3.13) which contains 1) Problem type, 2)
Operations) analyzed for the delays, 3) Possible remedies.
The second version of the analyzer carries out its
execution in following steps.
1) Similar to version 1, it lets the user select the
crop, the field and the operation, for which he wants the
2) It presents to the user the agronomic work window of
the selected combination.
* FARMSYS-A Decision Support System for Multi-Crop *
* Production Systems *
* Expert Advisor-Operations Analysis Report *
Press to Select Items of Farm Objects
Field O Crop A S Operation WEO
OPERATIONS ANALYSIS REPORT
Figure 3.13 Screen layout for the Operations Analysis report
with the built-in heuristics.
3) It gets the heuristic from the user to characterize
4) It then analyzes the operation based upon the supplied
heuristics and presents the user with the reports using the
steps discussed for earlier version of the analyzer with
The modified screen layout utilized for second version
of the analyzer is presented in Figure 3.14.
Machinery Usage Report
In an operational farm system, the machinery and labor
constitutes a major component of the capital outlay in the
production cost of different crops. Farm managers attempt to
make maximum utilization of the available machinery (tractors
and implements) and labor on the farm to keep production cost
low without sacrificing the product quality. They can
increase the utilization level of this valuable resource-base
by increasing the cultivated area, adjusting and changing the
crop mixes or by withdrawing under-utilized machinery and
labor from their farm.
This report analyzes the usage of machinery and labor
for the given farm system based upon the work report of the
operations simulation. It also identifies the least utilized
item for an object-class and analyzes its usage and allocation
strategies in order to withdraw it from the farm, if possible.
The criteria utilized for recommending withdrawal of an
* FARMSYS-A Decision Support System for Multi-Crop *
* Production Systems *
* Expert Advisor-Operations Analysis Report *
Press to Select Items of Farm Objects
Field Crop i Operation :
Work Windows Earliest Start
Initially Supplied E-" 0
dered Delayed If
OPERATION ANALYSIS REPORT
Figure 3.14 Screen layout for the Operations Analysis report
with the user-supplied heuristics.
object-item, and development and execution process of the
Criteria for withdrawal
In addition to an overall utilization of an object-item,
the decision to withdraw it from the farm could depend upon
factors such as the importance of the item for the farm, and
the effect of its withdrawal on other items of the same
object-class. In addition, every farm could also have a
minimum acceptable utilization level of a machinery unit not
to warrant its withdrawal. Many commercial farms own
machinery (both implements and tractors) more than what they
generally require to complete their operations timely and
efficiently during a normal year of cropping season. However,
extra pieces of equipment are maintained to serve as a backups
to most needed machinery to meet unwarranted situations for
The present analysis system recommends withdrawal of an
item if it is utilized less than 20% of the maximum utilized
item of the same object-class as detailed in Figure 3.15a.
If the 20% test condition succeeds, the second level search
is made for the object-item in different knowledge-bases
(Table 3.7) to evaluate its importance for the current farming
system. The search aims to find out the total number of
places the object-item, being considered for withdrawal,
appears as a possible candidate for any work. This number is
IF Amt of Most Util Item = Amt. of Least Util Item
THEN Recommend not to withdraw the Least Utilized Item,
BECAUSE Farm has only one item of this type,
OR Items are being utilized evenly.
IF Amt of Least Util Item = 0.0
THEN Recommend to withdraw of the Item,
BECAUSE Farm is not using this Item at all.
IF Amt of Least Util Item>=0.20*Amt of Most Util Item,
THEN Recommend not to withdraw of the item,
BECAUSE Farm has its reasonably balanced usage.
IF Amt of Least Util Item<0.20*Amt of Most Util Items,
AND Amount of Least Utilized Item >0.0,
THEN Go for Further Analysis.
Figure 3.15a Rules for recommending withdrawal of the least
utilized item of farm objects (machinery and
labor). a) based upon the actual utilization of
the items of farm object class, b) based upon the
allocation strategy for the least utilized item.
Knowledge-bases searched for different object-
classes to find out the number of places the item
appears as possible candidate for a job on the
Entity Type Knowledge-bases searched
Implements-- -- - -- -- -- - -- -- -
Operators Tractors, Implement and
further divided into 1) number of places it appears as a
unique candidate for the job and 2) number of places it has
one or more complementary units which could assume the task
of the least utilized object-item after its withdrawal.
Based upon the second level search, the rule set
presented in Figure 3.15b decides and recommends for the
withdrawal, if appropriate.
Development and execution process
The report is prepared utilizing the work report for the
operations simulation and the other information related to the
object-item supplied by the user. The system separates
entries from the work report for the selected object-class.
Actual work hours and days worked in by different items of the
object-class are added to find out their seasonal utilization.
The utilization levels, both in terms of working hours and
work days, of the least and the most utilized object-items are
then categorized up on a monthly basis.
The seasonal work report of the least and the most
utilized object-items is presented to the user to give him a
global idea about their performance. The user can also assess
the monthly breakup of utilization of these items, if he
desires, in order to study the variation in their usage over
the cropping season. Finally, the system analyzes and
presents its report on the least utilized item of the selected
AND NumUnq = NumTot,
THEN Recommend not to withdraw the Item,
BECAUSE Item is allocated alone everywhere,
AND It has no complimentary unit on farm.
AND NumUnq = 0.0,
THEN Recommend strongly to withdraw the Item,
BECAUSE Item has a complimentary unit everywhere
it is allocated.
THEN Recommend to withdraw the Item,
BECAUSE More than 50% times the Item has
a complimentary unit.
THEN Recommend not to withdraw the Item,
BECAUSE Less than 50% times the Item has
a complimentary unit.
Rules for recommending withdrawal of the least
utilized item of farm objects (machinery and
labor). a) based upon the actual utilization of
the items of an object class, b) based upon the
allocation strategy for the least utilized item.
Total number of places the item appears as a
possible candidate for a job.
Number of places the item appears as a unique
candidate for a job.
Number of places the item has at least one
complimentary unit which can be utilized for
the job if the item being analyzed is not